Evals: cómo saber si tu agente de IA funciona de verdad y no solo en la demo

Un test unitario clásico se apoya en una premisa que la IA generativa rompe: la misma entrada produce siempre la misma salida, y esa salida es correcta o incorrecta sin matices. Con un modelo de lenguaje, ninguna de las dos cosas se cumple. La misma pregunta puede devolver dos redacciones distintas y ambas ser correctas; un agente puede resolver la misma tarea por dos caminos diferentes y solo uno ser aceptable; y el mismo prompt puede funcionar hoy y degradarse mañana porque el proveedor actualizó el modelo por debajo.

La consecuencia práctica es que `assertEquals` deja de servir para la parte del sistema que decide. No puedes comparar la respuesta con una cadena esperada, porque la variación léxica no es un fallo. Necesitas comprobar propiedades: que la respuesta contenga el dato correcto, que cite una fuente real, que no invente, que respete el formato, que complete la tarea. Eso ya no es un test binario sobre una salida: es una evaluación con criterios.

La segunda diferencia es todavía más incómoda. Un test que pasa, pasa siempre. Una eval no da un sí o un no: da una distribución. Un agente que resuelve el 85 % de los casos no está "aprobado": está fallando uno de cada siete, y lo que decide si eso es viable no es la nota, sino qué pasa cuando falla y cuánto cuesta detectarlo. Por eso una eval bien planteada mide varias cosas a la vez y no se resume en un porcentaje.

Una eval es un experimento repetible. Le das al sistema un conjunto de entradas conocidas, recoges sus salidas, las puntúas con un criterio explícito y guardas el resultado para poder compararlo con la siguiente ejecución. Todo lo demás son variantes de esta idea. Sus componentes son siempre los mismos:

• Dataset de referencia: los casos sobre los que evalúas, con su entrada y, cuando existe, la respuesta o el resultado esperado.
• Sistema bajo prueba: no solo el modelo, sino el conjunto completo —prompt, herramientas, recuperación, bucle— con su configuración anotada.
• Puntuadores (scorers): las funciones que convierten una salida en una medida, desde una comprobación determinista hasta un juicio con rúbrica.
• Criterio de aceptación: qué puntuación consideras suficiente para desplegar, definido antes de mirar los resultados.
• Registro de ejecuciones: el histórico que permite comparar versiones y detectar que algo ha empeorado.
• Análisis de fallos: la revisión manual de los casos que fallan, que es de donde salen las mejoras reales.

Aquí está el cuello de botella real. Montar la infraestructura de evaluación es cuestión de días; construir un conjunto de casos que represente de verdad el trabajo que hace el sistema es lo que separa una eval útil de un decorado. Y no se resuelve pidiéndole al modelo que se invente cien ejemplos: los casos sintéticos tienden a ser fáciles, homogéneos y a parecerse sospechosamente a lo que el sistema ya sabe hacer.

Los buenos casos vienen de tres sitios. Del uso real: consultas y tareas que ya han pasado por el sistema, seleccionadas para cubrir el abanico de situaciones. De los fallos: cada incidencia que llega desde producción debería convertirse en un caso permanente de la eval, exactamente igual que un bug se convierte en un test de regresión. Y del conocimiento del negocio: los casos difíciles que un experto sabe que existen aunque todavía no hayan aparecido, incluidos los que deben terminar en "no lo sé" o en escalado a una persona.

Sobre el tamaño, la intuición habitual está mal calibrada en las dos direcciones. Con cinco casos no estás midiendo nada: la variación entre ejecuciones te dará más ruido que señal. Con miles, cada iteración se vuelve tan lenta y cara que dejas de ejecutarla. Un conjunto de unas decenas de casos bien elegidos —que cubra lo frecuente, lo difícil y lo que debe rechazarse— es mucho más valioso que cientos de casos redundantes, y sobre todo es un conjunto que el equipo ejecuta de verdad.

• Casos frecuentes: lo que el sistema resuelve todos los días. Si falla aquí, no hay proyecto.
• Casos difíciles: ambigüedades, datos incompletos, preguntas que cruzan varias fuentes.
• Casos trampa: preguntas cuya respuesta no está en tus datos y donde la respuesta correcta es reconocerlo.
• Casos de seguridad: intentos de sacar al sistema de su ámbito, de obtener datos que no corresponden o de saltarse permisos.
• Casos de regresión: todo fallo real detectado en producción, incorporado para que no vuelva a ocurrir sin avisar.

Existe una jerarquía clara de puntuadores, y la regla es sencilla: usa siempre el más barato y más objetivo que sirva para lo que quieres medir. El error habitual es ir directo al LLM como juez para todo, cuando buena parte de lo que importa se puede comprobar con código normal.

Si la salida tiene estructura —un JSON, una clasificación, un identificador, una cifra—, la comprobación es determinista y no hay discusión. Si lo que importa es que aparezca un dato concreto o que se cite una fuente existente, sigue siendo código. Solo cuando el criterio es genuinamente cualitativo —¿es una respuesta útil?, ¿el tono es adecuado?, ¿se sostiene en el contexto recuperado?— entra el juicio, y ahí puedes elegir entre un modelo actuando como juez o una persona.

El LLM como juez funciona razonablemente bien, pero solo bajo condiciones: rúbrica explícita con criterios discretos en lugar de una nota del 1 al 10, una escala corta, ejemplos de qué es bueno y qué es malo, y un modelo distinto —o al menos una llamada independiente— del que generó la respuesta. Y hay una regla que no conviene saltarse: el juez también hay que evaluarlo. Antes de fiarte de él, comprueba en una muestra que sus veredictos coinciden con los de una persona; si no lo hacen, tu métrica está midiendo el sesgo del juez, no la calidad del sistema.

Resumir la calidad de un agente en un único porcentaje es cómodo y engañoso. Un sistema que acierta el 90 % pero tarda cuarenta segundos y cuesta diez veces más que la alternativa no es viable. Uno que acierta el 95 % pero cuando falla lo hace de forma silenciosa y plausible es peor que otro con 85 % que avisa cuando no está seguro. Estas son las dimensiones que conviene medir por separado:

• Acierto: ¿resuelve la tarea completa según el criterio definido, no solo el primer paso?
• Fiabilidad: ¿lo resuelve todas las veces? Ejecutar cada caso varias veces revela la consistencia que una sola pasada esconde.
• Coste y latencia: tokens y segundos por tarea, y cómo escalan al crecer el volumen.
• Seguridad y límites: ¿respeta permisos, se mantiene en su ámbito, resiste intentos de manipulación vía contenido no confiable?
• Comportamiento ante el fallo: cuando no puede resolverlo, ¿lo reconoce y escala, o improvisa una respuesta plausible?

El tipo de sistema determina qué hay que medir, y aplicar el esquema equivocado hace que la eval señale problemas donde no están. Conviene separar tres familias, porque sus fallos característicos son distintos.

En un sistema de recuperación —un RAG sobre la base de conocimiento interna—, la mayoría de fallos no están en la generación sino en lo que se recuperó. Por eso hay que medir las dos etapas por separado: si el fragmento correcto estaba entre los recuperados, y si la respuesta se sostiene realmente en esos fragmentos sin añadir nada. Una respuesta bonita construida sobre contexto irrelevante es un fallo de recuperación, no de redacción, y arreglar el prompt no lo resuelve. Es el mismo problema que tratamos en por qué los agentes necesitan una capa de conocimiento.

En un agente con herramientas, lo que se evalúa es la trayectoria además del resultado: qué herramientas invocó, en qué orden, con qué argumentos, cuántos pasos necesitó y si se recuperó de los errores. Dos agentes pueden llegar al mismo resultado y solo uno ser aceptable, porque el otro tocó sistemas que no debía o dio doce rodeos. Y en tareas de clasificación o extracción, la evaluación se parece mucho más al aprendizaje automático clásico: matriz de confusión, y atención especial a la clase minoritaria, que suele ser justamente la que importa.

La mayoría de evals que no aportan nada fallan por las mismas razones, y ninguna es técnica: son errores de método. Merece la pena revisarlos antes de invertir semanas en construir la infraestructura.

• Evaluar sobre los casos con los que se ajustó el prompt: el sistema está afinado precisamente para esos ejemplos, así que la nota siempre sale alta y no dice nada.
• Cambiar varias cosas a la vez: si tocas prompt, modelo y recuperación en la misma iteración, la mejora o el empeoramiento no se pueden atribuir a nada.
• Definir el criterio de aceptación después de ver los resultados: la tentación de mover el listón hasta donde llegó el sistema es enorme y desactiva la eval.
• No fijar la versión del modelo: si el proveedor actualiza por debajo, estás comparando dos sistemas distintos creyendo que comparas dos prompts.
• Confiar en el juez sin calibrarlo: un juez mal ajustado convierte la eval en una métrica de su propio sesgo.
• No mirar nunca los fallos uno a uno: el porcentaje dice que algo va mal, pero la mejora sale siempre de leer los casos concretos que fallaron.

La suite offline responde a una pregunta acotada: ¿este cambio mejora el sistema sobre los casos que ya conozco? No responde a la que importa cuando el sistema ya está en manos de usuarios: ¿qué está pasando ahí fuera con las entradas que nunca imaginé? Para eso hace falta cerrar el círculo con producción.

El mecanismo es sencillo y no requiere una plataforma sofisticada. Registrar cada interacción con su entrada, su salida, las herramientas usadas, el coste y la latencia. Muestrear una fracción de ese tráfico y puntuarla con los mismos criterios de la eval offline. Recoger señales implícitas —reformulaciones, abandonos, escalados a una persona— que suelen anticipar los problemas antes que cualquier métrica explícita. Y, sobre todo, convertir cada fallo detectado en un caso nuevo del dataset. Ese bucle es lo que hace que la evaluación mejore con el tiempo en lugar de envejecer.

Hay un momento en el que todo esto deja de ser opcional: cuando cambias de modelo. Actualizar a una versión más capaz mejora la media y, con frecuencia, empeora algún caso concreto en el que tu prompt se apoyaba en un comportamiento anterior. Sin eval, ese cambio se despliega a ciegas y el fallo lo descubre un cliente. Con eval, es una comparación de veinte minutos. Es también la forma correcta de decidir entre proveedores, un asunto que tratamos en qué modelo de IA elegir para tu empresa: no por benchmarks públicos, sino por cómo rinden sobre tus propias tareas.

La objeción habitual es de calendario: "no tenemos tiempo de montar una evaluación". Casi siempre es un cálculo equivocado, porque el tiempo que se ahorra se paga después en iteraciones a ciegas y en incidencias que nadie sabe reproducir. Y la versión mínima es mucho más barata de lo que parece: no necesitas una plataforma, necesitas un conjunto de casos y un script que los ejecute.

Un orden que funciona para empezar en cuestión de días y no de meses:

• Elige una sola tarea, la más crítica del sistema, y define por escrito qué significa resolverla bien.
• Reúne entre veinte y cincuenta casos reales que cubran lo frecuente, lo difícil y lo que debe rechazarse.
• Empieza solo con puntuadores deterministas: formato, presencia del dato correcto, fuentes que existen.
• Ejecuta cada caso varias veces y mide la consistencia, no solo el acierto de una pasada.
• Fija el criterio de aceptación antes de la primera ejecución completa y déjalo por escrito.
• Integra la eval en el flujo de cambios: ningún cambio de prompt, modelo o recuperación se despliega sin pasarla.
• Añade el juez automático solo cuando los criterios deterministas se queden cortos, y calíbralo contra revisión humana.