Cómo hacer QA de una app con IA: evaluar un chatbot o un RAG sin resultados exactos

Respuesta corta: una aplicación con LLM no se prueba comparando la respuesta con un texto exacto, porque la misma pregunta puede producir respuestas distintas. Se prueba con un conjunto de casos de referencia, criterios de evaluación (rúbricas), umbrales de aceptación y ejecución continua, igual que se vigila una métrica, no como un test unitario clásico.

Por qué el testing tradicional se queda corto

En software determinista, entrada → salida es predecible y un assertEquals basta. Con un LLM:

• La misma pregunta puede dar respuestas distintas entre ejecuciones.
• Un cambio de modelo, de versión o de prompt altera el comportamiento sin tocar tu código.
• "Correcto" suele ser un juicio (¿es relevante? ¿es seguro? ¿es fiel a la fuente?), no una igualdad.

Un test que pasaba ayer puede fallar hoy sin que nadie haya cambiado nada. La respuesta no es abandonar las pruebas, sino cambiar qué se mide.

Las cinco capas de una estrategia de QA para IA

1. Un dataset de referencia ("golden set")

Reúne entre 30 y 100 casos reales: preguntas típicas, casos límite, preguntas que el sistema no debería responder y ejemplos de consultas que ya fallaron en producción. Cada caso incluye lo que se espera (la idea correcta, no el texto literal) y, si aplica, la fuente que debería respaldarla.

2. Comprobaciones deterministas primero

Antes de usar otro modelo para juzgar, valida lo que sí se puede verificar con código:

• ¿La salida respeta el formato (JSON válido, campos obligatorios)?
• ¿Está en el idioma correcto y dentro del largo esperado?
• ¿Contiene datos que no debería (correos, teléfonos, claves)?
• ¿Cita fuentes que existen en tu base de conocimiento?

Son rápidas, baratas y no tienen ambigüedad.

3. Rúbricas para lo subjetivo

Para relevancia, tono o precisión, define una rúbrica clara (por ejemplo, de 1 a 5 con descripción de cada nivel). Puedes aplicarla con revisión humana por muestreo o con un LLM como juez. Si usas un modelo como juez, trátalo como un instrumento que también puede equivocarse: calibra sus resultados contra una muestra evaluada por personas.

4. En un RAG, evalúa recuperación y generación por separado

Si la respuesta es mala, el problema puede estar en dos lugares distintos:

• Recuperación: ¿se encontraron los fragmentos correctos de tu documentación?
• Generación: ¿el modelo usó esos fragmentos con fidelidad o inventó?

Medirlos por separado te dice dónde arreglar. Herramientas de código abierto como promptfoo, Ragas o DeepEval ayudan a organizar este tipo de evaluaciones.

5. Seguridad y casos adversos

Prueba intentos de inyección de prompt, peticiones fuera de alcance, filtración de datos internos y respuestas que no deberían darse (consejos médicos o legales, por ejemplo). Estos casos van en el dataset desde el principio.

Cómo llevarlo a la práctica

1. Define umbrales por métrica (por ejemplo, "al menos el 90 % de los casos con fidelidad aceptable") en lugar de exigir 100 %.
2. Ejecuta la evaluación en cada cambio de prompt, de modelo o de base de conocimiento, como parte del CI.
3. Guarda los resultados históricos para ver tendencias y detectar regresiones.
4. Mantén el dataset vivo: cada fallo en producción se convierte en un caso nuevo.
5. Deja siempre una revisión humana en las decisiones de alto riesgo.

Un error común

Probar solo "que responda algo". Un chatbot puede responder con total seguridad y estar equivocado. La pregunta de QA no es "¿contestó?", sino "¿contestó bien, de forma segura y con la información correcta?".

Si tu equipo ya probó funcionalidades con IA y quiere estructurar este proceso, también te puede servir leer sobre IA generativa en testing: casos de uso y riesgos y cómo la IA fortalece a tu equipo de QA.

¿Estás lanzando un asistente o una función con IA y quieres una evaluación antes de salir a producción? Conversemos.