Pruebas de Sistemas Basados en IA
Cubre testeabilidad de sistemas IA bloqueados/adaptativos, enfoque estadístico, oráculos, pruebas de IA generativa y LLM, red teaming, niveles de prueba para ML y prueba basada en riesgos.
4.1 Introducción a las pruebas de sistemas basados en IA
Probar IA exige combinar pruebas tradicionales con pruebas de datos, modelo, métricas, riesgo, monitoreo y comportamiento estadístico. Se evalúan entradas, salidas, distribución de datos, incertidumbre, seguridad, sesgo, robustez y operación en el tiempo.
- La prueba no termina con el despliegue: muchos riesgos aparecen en producción.
- Se necesitan conjuntos representativos y criterios medibles.
4.1.1 Sistemas IA bloqueados y adaptativos
Un sistema bloqueado no cambia su modelo después del despliegue salvo nueva versión controlada. Es más testeable y reproducible. Un sistema adaptativo puede cambiar con datos nuevos o aprendizaje continuo, por lo que necesita monitoreo, control de cambios, pruebas periódicas y límites de adaptación.
- Bloqueado: validación previa más estable.
- Adaptativo: riesgo de deriva y cambios no esperados.
4.1.2 Enfoque estadístico
Muchos sistemas IA son probabilísticos, por lo que no basta probar una entrada y esperar una salida exacta. Se requieren muestras representativas, niveles de confianza, umbrales, análisis de distribución, repetición, comparación estadística y evaluación de métricas agregadas.
- Diseñar pruebas con suficiente tamaño de muestra.
- Interpretar resultados con variabilidad e incertidumbre.
4.1.3 Oráculos de prueba para IA
El problema del oráculo aparece cuando no hay una única salida esperada o es costoso definirla. Las soluciones incluyen verdad de referencia, expertos humanos, pseudo-oráculos, comparaciones back-to-back, pruebas metamórficas, reglas de negocio, invariantes y evaluación estadística.
- La verdad de referencia debe ser confiable y trazable.
- Un pseudo-oráculo ayuda, pero también puede estar equivocado.
4.2 Pruebas de IA generativa y LLM
La IA generativa y los LLM se prueban con prompts, escenarios, límites de seguridad, exactitud, consistencia, toxicidad, sesgo, fuga de datos, resistencia a prompt injection, cumplimiento y calidad de salida. También se evalúan parámetros como temperatura y políticas de rechazo.
- No validar solo prompts felices.
- Probar jailbreaks, instrucciones contradictorias, contexto malicioso y datos sensibles.
4.2.2 Red teaming
El red teaming simula ataques o usos abusivos para descubrir fallos antes de que ocurran en producción. Incluye prompts adversarios, inyección de instrucciones, extracción de datos, bypass de filtros, abuso de herramientas, alucinaciones peligrosas y degradación de seguridad.
- K3: diseñar ataques, registrar resultado, clasificar riesgo y proponer mitigación.
- Red teaming debe tener alcance, reglas y criterios de severidad.
4.2.3 Ejercicio: prueba exploratoria de un LLM
La prueba exploratoria permite aprender sobre el comportamiento del LLM mientras se diseñan y ejecutan pruebas. Se usa un charter, se varían prompts y se documentan hallazgos, patrones, riesgos y anomalías.
- Combinar creatividad con trazabilidad.
- Guardar prompts, respuestas, parámetros y contexto.
4.3 Niveles de prueba y sistemas ML
Los niveles específicos incluyen pruebas de datos de entrada, pruebas del modelo ML, pruebas del sistema basado en IA, pruebas de integración con componentes convencionales, pruebas de aceptación y pruebas en producción/monitoreo. Cada nivel busca riesgos diferentes.
- Dato correcto no garantiza modelo correcto.
- Modelo correcto no garantiza sistema integrado correcto.
4.3.2 Prueba basada en riesgos para ML
La prueba basada en riesgos prioriza según probabilidad e impacto. En IA se consideran sesgo, seguridad, deriva, baja robustez, mal rendimiento por grupo, falta de transparencia, daños éticos y dependencia de proveedores. El esfuerzo de prueba se enfoca donde el daño potencial es mayor.
- Riesgo alto exige evidencia más fuerte y criterios más estrictos.
- El riesgo puede cambiar con nuevos datos o contexto operativo.
Términos clave
Objetivos de aprendizaje
- AI-4.1.1 · K2Comparar la testeabilidad de sistemas de IA bloqueados y adaptativos
Un sistema de IA bloqueado conserva su comportamiento tras el despliegue y es más testeable; un sistema adaptativo cambia con nuevos datos y requiere monitoreo y pruebas continuas.
- AI-4.1.2 · K2Explicar por qué suele ser necesario un enfoque estadístico al probar sistemas basados en IA
El enfoque estadístico es necesario porque muchos modelos son probabilísticos, no deterministas y deben evaluarse con muestras representativas, umbrales, intervalos y niveles de confianza.
- AI-4.1.3 · K2Explicar desafíos y soluciones relacionados con oráculos de prueba para sistemas basados en IA
El problema del oráculo aparece cuando no existe una salida esperada única; soluciones incluyen verdad de referencia, expertos, comparación estadística, pruebas metamórficas, pseudo-oráculos y pruebas comparativas.
- AI-4.2.1 · K2Explicar cómo se puede probar la IA generativa
La IA generativa se prueba variando instrucciones, parámetros y datos, evaluando reglas, seguridad, sesgo, calidad, consistencia, toxicidad, alucinación y cumplimiento, no solo coincidencia exacta de salida.
- AI-4.2.2 · K3Implementar pruebas de equipo rojo para sistemas IA generativa
Las pruebas de equipo rojo diseñan ataques y escenarios adversarios antes del despliegue para descubrir vulnerabilidades como inyección de instrucciones, sesgos, fuga de datos o generación insegura.
- AI-4.3.1 · K2Resumir los niveles de prueba usados para desarrollar sistemas de aprendizaje automático
Los niveles específicos en sistemas de aprendizaje automático incluyen pruebas de datos de entrada, pruebas del modelo de aprendizaje automático y pruebas del desarrollo/despliegue de aprendizaje automático, además de niveles convencionales cuando aplica.
- AI-4.3.2 · K2Explicar cómo se aplica la prueba basada en riesgos a sistemas de aprendizaje automático
La prueba basada en riesgos prioriza datos, modelo y desarrollo según probabilidad e impacto, incluyendo sesgo, deriva, rendimiento, seguridad, robustez y riesgos de despliegue.
Errores frecuentes
- No buscar siempre un oráculo exacto: en IA puede requerirse estadística, experto o relaciones metamórficas.
- No hacer pruebas de equipo rojo solo después de producción.
Ejemplos aplicados
- Para un LLM legal, las pruebas de equipo rojo debe cubrir inyección de instrucciones, filtración de datos, sesgo y consejos inseguros antes del despliegue.