Durante años el QA de software ha funcionado sobre una premisa tan sólida que nadie la cuestionaba: dado el mismo input, el sistema produce el mismo output. Esa premisa acaba de romperse.
Si tu empresa está integrando un asistente de IA, un chatbot de soporte o cualquier funcionalidad construida sobre un modelo de lenguaje, tu trabajo como QA ha cambiado. No porque hayas desaparecido, sino porque el enfoque que aprendiste ya no es suficiente por sí solo.
El problema que nadie te avisa que vas a tener
Imagina que estás testeando un chatbot de atención al cliente. El caso de prueba es claro: el usuario pregunta por el estado de su pedido y el sistema responde con la información correcta.
En testing tradicional escribirías algo así:
- Input: "¿Dónde está mi pedido #12345?"
- Expected output: "Tu pedido está en camino. Llegará el 15 de mayo."
El test pasa. Pero mañana, con el mismo input, el sistema responde: "Tu envío está en tránsito y debería llegar el próximo miércoles 15." Correcto, útil, perfectamente válido. Pero diferente. Tu assertion falla. Tu test es rojo. Y no hay ningún bug.
Este es el problema central del QA en sistemas LLM: los modelos de lenguaje son no deterministas por diseño. La misma pregunta puede generar respuestas distintas en cada ejecución, y muchas de ellas pueden ser igualmente correctas. El modelo está muestreando probabilísticamente, no ejecutando lógica determinística.
El testing exacto de strings, los assertEqual de toda la vida, simplemente no funcionan aquí.
El cambio fundamental: de verificar a evaluar
En testing clásico, la pregunta es binaria: ¿el output es exactamente el esperado? Pasa o no pasa.
En QA de sistemas LLM, la pregunta cambia: ¿el output es suficientemente bueno? Y "suficientemente bueno" tiene varias dimensiones que hay que definir antes de poder medir:
- ¿La respuesta es relevante para lo que preguntó el usuario?
- ¿La información es fiel al contexto que se le proporcionó al modelo?
- ¿Está inventando datos que no existen en el documento de referencia?
- ¿El tono es el correcto para la marca y el canal?
- ¿Hay riesgo de que exponga información sensible del sistema?
Esto es lo que en la industria se llama LLM evaluation, o simplemente evals. No son tests en el sentido clásico. Son más parecidos a una auditoría continua de la calidad de las respuestas del sistema.
La pregunta cambia de "¿es exactamente esto?" a "¿es suficientemente bueno?". Y eso implica definir qué significa bueno antes de poder medirlo. Esa definición es, en sí misma, parte del trabajo del QA.
Lo que sí sigue siendo determinístico
Antes de entrar de lleno en los evals, hay que decir algo importante: no todo desaparece. Hay una parte del comportamiento de un sistema LLM que sigue siendo perfectamente testeable de forma clásica, y que no debes abandonar.
Estas verificaciones siguen teniendo pleno sentido:
- Formato de respuesta: si el sistema debe devolver JSON válido con una estructura definida, puedes validarlo igual que siempre.
- Guardrails: si el sistema no debe responder a preguntas fuera de su dominio, puedes testear que rechace correctamente esos inputs.
- Latencia: que la respuesta llegue en menos de X segundos es una métrica completamente determinística.
- Filtros de seguridad: que el modelo no devuelva instrucciones dañinas, no filtre datos sensibles del system prompt ni revele información de otros usuarios.
- Casos críticos conocidos: si tienes un input muy específico donde el comportamiento correcto está completamente definido, puedes mantener esa prueba.
La arquitectura de testing de un sistema LLM tiene dos capas que coexisten: una capa determinística para todo lo que debe ocurrir siempre de la misma forma, y una capa evaluativa para la calidad de las respuestas en el espacio abierto.
- Formato de respuesta (JSON válido)
- Latencia por debajo del umbral
- Guardrails: rechaza inputs fuera de dominio
- No filtra datos sensibles del sistema
- Casos límite con comportamiento definido
- Faithfulness al contexto proporcionado
- Relevancia de la respuesta
- Ausencia de alucinaciones
- Coherencia y tono de marca
- Regresión entre versiones de prompt
El error más común es intentar meter toda la capa evaluativa en la capa determinística. Alguien escribe un test que compara la respuesta completa con un string hardcodeado, ese test falla al mes siguiente porque el modelo se actualizó, y el equipo pierde la confianza en la suite entera. Resultado: dejan de correrla.
Las métricas que reemplazan al assertEqual
Cuando no puedes comparar strings exactos, necesitas métricas que midan calidad de forma sistemática. Las más adoptadas en la industria son estas:
| Métrica | Qué mide | Ejemplo de fallo |
|---|---|---|
| Faithfulness | ¿La respuesta se basa en el contexto proporcionado? | El modelo inventa datos que no están en el documento |
| Answer Relevancy | ¿La respuesta responde a la pregunta del usuario? | El usuario pregunta por horarios y el modelo responde sobre precios |
| Hallucination | ¿Está fabricando información? | Cita un artículo o estudio que no existe |
| Coherence | ¿La respuesta es lógica y bien estructurada? | Responde a medias o con afirmaciones contradictorias |
| Safety / Toxicity | ¿Hay contenido dañino o inapropiado? | Responde a un prompt de jailbreak con contenido restringido |
| Context Precision | ¿Está usando el contexto relevante y descartando el irrelevante? | Responde con el documento incorrecto en un sistema RAG |
En sistemas RAG —donde el modelo busca información en documentos antes de responder— faithfulness y context precision son las métricas más críticas. En chatbots conversacionales de propósito general, answer relevancy y coherence importan más. Cuáles priorizar depende de la arquitectura del producto que estás testeando.
El patrón LLM-as-judge
Una de las cosas que hace difícil este tipo de QA es que evaluar si una respuesta es "relevante" o "fiel al contexto" requiere comprensión semántica real. Un humano lo hace bien, pero no escala: no puedes revisar manualmente miles de respuestas en cada ciclo de CI. Y una comparación de strings no puede hacerlo en absoluto.
La solución que ha adoptado la industria es usar otro LLM como juez. El flujo es el siguiente:
Es el mismo principio que una revisión por pares: un segundo experto evalúa el trabajo del primero de forma sistemática.
LLM-as-judge tiene sus propias limitaciones: los modelos juez tienen sesgos documentados —tienden a preferir respuestas más largas, por ejemplo— y evaluar con un LLM tiene coste económico. Por eso se combina con revisión humana periódica de muestras representativas. No reemplaza el criterio humano; lo hace escalable.
Cómo diseñar un eval desde cero
Si eres QA en un equipo que está empezando a trabajar con LLMs, este es el proceso mínimo para tener algo funcional antes de que lleguen los primeros problemas de producción.
1. Construye un golden dataset
Un conjunto de inputs reales —o representativos— con los criterios de calidad esperados. No necesariamente la respuesta exacta, sino lo que una respuesta correcta debe cumplir: "debe mencionar el plazo de entrega", "no debe inventar datos de producto", "debe responder en menos de 150 palabras", "debe rechazar la pregunta si está fuera del dominio". Toma logs reales de usuarios si los tienes, o crea casos representativos basados en los flujos principales del sistema.
2. Define umbrales explícitos
¿Qué puntuación mínima de faithfulness es aceptable para este producto? ¿Por debajo de qué threshold de relevancy consideras que hay un problema que bloquea el despliegue? Estos valores dependen del contexto de negocio y del riesgo asociado a errores, pero deben establecerse explícitamente antes de que ocurra la primera regresión.
3. Automatiza la ejecución
El eval debe poder correr cada vez que cambie el prompt del sistema, el modelo de base o los documentos de referencia en un RAG. Un cambio aparentemente inocente en el wording del system prompt puede afectar la calidad de las respuestas de formas no obvias. Intégralo en el pipeline de CI como lo harías con cualquier suite de tests.
4. Trata las bajadas de score como regresiones
Si tenías un score de faithfulness de 0.87 y después de un cambio baja a 0.71, algo empeoró. El proceso es exactamente el mismo que con una suite clásica: si hay regresión, investigar antes de mergear.
En la práctica, el mayor valor del golden dataset no es el score numérico que produce. Es que te obliga a tener una conversación con el equipo de producto sobre qué significa exactamente "una buena respuesta" para este sistema en este contexto. Esa conversación raramente ocurre de otra manera, y su ausencia es el origen de la mayoría de los desacuerdos sobre si el modelo "funciona bien" o no.
Herramientas que ya existen para esto
No tienes que construir la infraestructura desde cero. Hay herramientas open source y comerciales ya adoptadas en la industria:
- Promptfoo: open source, se configura en YAML, permite definir evals, correrlos en CI y comparar el comportamiento entre versiones de prompts o entre modelos. Muy adoptada para validar cambios en el system prompt antes de desplegar.
- DeepEval: librería Python con una interfaz similar a pytest. Implementa las métricas estándar —faithfulness, relevancy, hallucination— y soporta LLM-as-judge configurable con distintos modelos juez.
- RAGAS: especializada en sistemas RAG. Tiene métricas específicas para evaluar la calidad del retrieval y la generación por separado, lo que permite diagnosticar si el problema está en el paso de búsqueda o en el de generación.
- LangSmith: plataforma más amplia con observabilidad, trazas y evals integrados. Útil si el equipo ya usa LangChain en el stack del producto.
Ninguna de estas herramientas elimina la necesidad de criterio humano. Son instrumentos para hacer sistemática y escalable la parte del trabajo que puede automatizarse, no para reemplazar al QA.
Lo que esto significa para tu carrera
El QA de sistemas LLM no es un trabajo diferente al QA tradicional. Es una extensión de él. Los fundamentos no cambian: definir qué es correcto, diseñar casos que lo verifiquen, documentar lo que se encuentra, proteger la calidad del sistema en producción.
Lo que cambia es que ahora parte del trabajo requiere entender cómo funcionan los modelos de lenguaje lo suficiente para saber qué puede salir mal, definir métricas de calidad para respuestas abiertas, y trabajar con herramientas de evaluación que no existían hace dos años.
Los equipos que están construyendo productos con IA ya buscan perfiles QA con este conocimiento. No como especialistas en machine learning, sino como profesionales capaces de trasladar los principios de calidad de software al mundo no determinístico de los LLMs. Esa combinación es todavía escasa en el mercado.
Preguntas frecuentes
¿Puedo seguir usando Selenium o Playwright para testear un producto con IA?
Para la capa determinística, sí: que el campo de input exista, que la petición llegue al servidor, que la respuesta se muestre en pantalla en tiempo. Para evaluar la calidad semántica de lo que responde el modelo, no. Ahí necesitas evals específicos de LLM que midan relevancia, fidelidad al contexto o alucinaciones.
¿Qué es un golden dataset y cómo se construye?
Es un conjunto de inputs representativos junto a los criterios de calidad que debe cumplir cada respuesta. No necesariamente la respuesta exacta, sino lo que una respuesta correcta debe hacer: "debe mencionar el plazo de entrega", "no debe inventar datos", "debe rechazar preguntas fuera de dominio". Para construirlo: toma logs reales de usuarios si los tienes, define por escrito qué significa una respuesta correcta y documenta los casos problemáticos conocidos.
¿Qué es LLM-as-judge y es fiable?
Es el patrón de usar otro LLM para evaluar automáticamente si una respuesta cumple los criterios definidos. Es útil pero imperfecto: los modelos juez tienen sesgos documentados, como preferir respuestas más largas. Por eso se combina con revisión humana periódica de muestras representativas, no se usa como sustituto del criterio humano.
¿Qué métricas debo priorizar si empiezo desde cero?
Empieza con faithfulness —¿está el modelo inventando información que no aparece en el contexto?— y answer relevancy —¿responde a lo que el usuario realmente preguntó?—. Son las dos métricas que más directamente afectan a la experiencia del usuario y las que más valor aportan antes de añadir capas de evaluación más específicas.
¿Cómo sé si un cambio en el prompt ha empeorado la calidad?
Corriendo el eval antes y después del cambio sobre el mismo golden dataset. Si el score de faithfulness baja de 0.87 a 0.71 después de modificar el system prompt, algo empeoró. El proceso es exactamente el mismo que con una suite clásica: si hay regresión, investigar antes de mergear el cambio.
Aprende a testear productos con IA
QA de chatbots e integraciones con LLMs: cómo evaluar respuestas, diseñar casos de prueba y detectar alucinaciones en proyectos reales.