Probar modelos de ML: datos, sesgo y características de calidad

Probar un modelo de machine learning significa revisar tres cosas que las pruebas de software habituales ignoran: la calidad de los datos con los que aprendió, si ha absorbido sesgo y cómo se comporta frente a características de calidad propias de la IA como la robustez y la explicabilidad. Como un modelo de ML deriva su comportamiento de los datos y no de reglas escritas a mano, la mayoría de los defectos del modelo se remontan a los datos, no al código.

¿Por qué probar un modelo de ML es diferente?

En el software tradicional la lógica la escriben los desarrolladores, así que se prueba el código contra una especificación. Un modelo de ML no tiene una regla explícita para cada salida: infiere patrones a partir de ejemplos. No hay una única respuesta correcta que afirmar, el comportamiento es probabilístico y el mismo modelo puede degradarse cuando los datos reales cambian. La prueba pasa de ¿coincide el código con la especificación? a ¿rinde el modelo lo bastante bien, con equidad y fiabilidad sobre datos que nunca ha visto? Términos como robustez y deriva siguen el glosario de ISTQB.

Empiece por la calidad de los datos

La calidad de los datos determina la calidad del modelo: basura entra, basura sale, y aquí se aplica doble, porque los datos malos no solo producen malas salidas sino que enseñan al modelo malos patrones. Antes de juzgar un modelo, pruebe el conjunto de datos en estas dimensiones:

• Exactitud — ¿los valores reflejan la realidad, con etiquetas correctas y sin registros corruptos?

• Completitud — ¿hay valores ausentes o grupos infrarrepresentados?

• Consistencia — ¿mismo formato y significado entre fuentes (unidades, codificaciones, formatos de fecha)?

• Unicidad — ¿duplicados que permitan al modelo memorizar registros o distorsionar el balance de clases?

• Vigencia — ¿son los datos lo bastante recientes para representar el problema actual?

• Relevancia — ¿las características se relacionan realmente con lo que se predice?

Divida los datos: entrenamiento, validación y test

Un conjunto de datos de ML se divide en un conjunto de entrenamiento (del que aprende el modelo), uno de validación (para ajustar los hiperparámetros) y uno de test (reservado para estimar el rendimiento real). La regla de oro: el conjunto de test debe permanecer invisible durante el entrenamiento. Si información de test o validación se filtra al entrenamiento —un defecto llamado fuga de datos— las métricas parecen excelentes en laboratorio y se desploman en producción. Una división típica ronda el 60/20/20 o el 80/10/10, pero lo prioritario es que el conjunto de test sea representativo y esté aislado.

Detecte y pruebe el sesgo

El sesgo significa que el modelo favorece o perjudica sistemáticamente a ciertos grupos o resultados. Suele entrar por los datos. Vigile:

• Sesgo de muestreo (selección) — los datos de entrenamiento no representan a la población real, por ejemplo solo fotos diurnas.

• Sesgo de etiqueta — las etiquetas humanas históricas codifican prejuicios pasados y el modelo aprende a reproducirlos.

• Sesgo algorítmico — las decisiones de características u optimización amplifican un pequeño desbalance en los datos.

• Desbalance de clases — una clase domina, así un modelo perezoso logra alta exactitud mientras falla en la clase rara.

Pruebe el sesgo evaluando métricas por subgrupo, no solo en conjunto. Un modelo con 94% de exactitud global puede ser mucho peor para un grupo minoritario: la paradoja de la exactitud. Nuestra guía sobre precisión, recall y F1 para testers explica por qué un único valor de exactitud oculta estos fallos.

Características de calidad propias de la IA

El temario ISTQB CT-AI amplía las características de calidad clásicas con otras que solo importan en sistemas de IA. Al planificar las pruebas de un modelo, asigne cobertura a:

• Robustez y adaptabilidad — ¿se mantiene el rendimiento ante entradas ruidosas, adversariales o ligeramente desplazadas?

• Autonomía y autoaprendizaje — ¿un modelo que sigue aprendiendo se mantiene dentro de límites seguros?

• Explicabilidad, interpretabilidad y transparencia — ¿pueden los interesados entender por qué se tomó una decisión?

• Equidad y ausencia de sesgo — ¿son los resultados equitativos entre grupos?

• Seguridad y efectos secundarios — ¿evita el modelo comportamientos dañinos o no deseados al optimizar su objetivo?

Técnicas para probar modelos de ML

Como rara vez se tiene una salida esperada exacta, las pruebas de ML se apoyan en técnicas que verifican relaciones en lugar de respuestas únicas:

• Pruebas metamórficas — aplicar una transformación que no debería cambiar el resultado (rotar una imagen, reformular una frase) y verificar que la salida se mantiene consistente.

• Pruebas back-to-back — comparar el nuevo modelo con una versión previa o un modelo de referencia sobre las mismas entradas.

• Pruebas A/B y lanzamientos canary — exponer una pequeña parte del tráfico real al nuevo modelo y comparar resultados antes del despliegue completo.

• Pruebas adversariales — construir entradas diseñadas para engañar al modelo y sondear su robustez.

• Métricas de rendimiento — medir precisión, recall, F1 y la matriz de confusión en el conjunto de test reservado.

Defectos comunes de ML a vigilar

Dominan dos modos de fallo. Overfitting: el modelo memoriza los datos de entrenamiento —digamos 99% de exactitud en entrenamiento— pero puntúa mucho más bajo en el test, digamos 72%; aprendió ruido, no el patrón. Deriva: el mundo cambia tras el despliegue, de modo que la deriva de concepto (cambia la relación entre entradas y salidas) o la deriva de datos (cambia la distribución de entrada) erosiona la exactitud en silencio. El overfitting se detecta antes del lanzamiento con un conjunto de test limpio; la deriva, después del lanzamiento con monitoreo continuo.

Probar modelos de ML es donde las pruebas de IA se vuelven concretas, y es una parte central de la certificación ISTQB CT-AI. Para practicar preguntas de calidad de datos, sesgo y métricas en condiciones de examen, prueba el simulacro CT-AI de ExamCaliber.