Definición
Los evals son la batería de casos de prueba de un sistema con IA: un conjunto de entradas con la respuesta que esperas, que pasas cada vez que cambias algo para saber si has mejorado o has roto cosas.
Son el equivalente a los tests automáticos del software normal, con una diferencia que lo cambia todo: aquí la salida no es exacta. Un test de siempre comprueba que suma(2,2) devuelve 4. Un eval tiene que comprobar que una respuesta en lenguaje natural es correcta, y eso admite mil redacciones válidas.
Sin evals, mejorar un asistente es superstición. Cambias una frase del prompt, pruebas dos ejemplos a mano, parece que va mejor y lo subes. Tres semanas después no sabes por qué contesta peor que en marzo ni qué cambio lo causó.
Cómo se monta
1. Reunir los casos. Salen de sitios reales: conversaciones de producción, preguntas que fallaron, los casos límite que te preocupan. Empieza con 30-50 bien elegidos, no con mil regulares.
2. Definir qué es acertar. Aquí está el trabajo. Según el caso:
- Coincidencia exacta, cuando la salida es una categoría o un dato. Barato y fiable.
- Contiene / no contiene, cuando importa que aparezca un hecho o que no aparezca una palabra.
- Validación de esquema, cuando esperas JSON: ¿parsea? ¿tiene los campos?
- Modelo como juez (LLM as judge), cuando la respuesta es texto libre: otro modelo puntúa contra una rúbrica escrita.
- Persona, para lo que de verdad no se puede automatizar. Es caro; resérvalo.
3. Automatizar la ejecución. Un comando que los pasa todos y da un número.
4. Fijar una línea base y no bajar de ahí. Cada cambio se compara contra ella.
Ejemplo práctico
Cuando montamos el clasificador de gastos bancarios del CRM de IMDICA, la primera versión iba "bien" en las pruebas a ojo. Al montar los evals apareció la realidad.
Cogimos 120 movimientos reales ya categorizados a mano, tapando la categoría. El eval es trivial de evaluar: la salida es una de veinte categorías, así que es coincidencia exacta. Un for y a contar.
Resultados de la primera tanda: 71 % global. Pero lo útil no fue el 71 sino el desglose. Ocho de los diez fallos eran de dos categorías que se confundían entre sí, y siempre en la misma dirección. Eso no se ve probando cuatro ejemplos a mano: se ve cuando pasas los 120 y agrupas los fallos.
A partir de ahí, cada cambio —tocar el prompt, dar más ejemplos, cambiar de modelo— se medía contra los mismos 120. Subimos a 89 % en cuatro iteraciones, y en una de ellas el número bajó: un cambio que parecía obvio empeoró tres puntos. Sin evals lo habríamos dejado puesto.
Coste de montar aquello: una tarde. Lo recuperamos en la primera iteración.
Qué medir además del acierto
- Coste medio por petición. Un modelo que acierta dos puntos más y cuesta seis veces más puede no compensar.
- Latencia. Un asistente correcto que tarda quince segundos no se usa.
- Tasa de negativas. Cuántas veces se niega a responder algo que debería responder.
- Formato válido. Porcentaje de salidas que parsean a la primera.
- Regresiones. Casos que antes acertaba y ahora falla. Es el número que más duele y el más informativo.
Errores comunes
- Evaluar con los mismos ejemplos que metiste en el prompt. Estás midiendo si sabe copiar.
- Solo casos fáciles. Un eval que da 100 % siempre no informa de nada. Tiene que doler un poco.
- Un único número. El global esconde que fallas sistemáticamente en un tipo de caso.
- Modelo como juez sin rúbrica. "Puntúa del 1 al 10" da ruido. Hay que decirle exactamente qué se valora y qué descuenta.
- No versionar los evals. Si cambias los casos a la vez que el sistema, las comparaciones no valen.
- Montarlos al final. Se montan al principio, cuando aún duele poco.
Cuándo montarlos
En cuanto pases de "estoy probando" a "esto lo van a usar". La señal clara es esta: si te da miedo cambiar el prompt porque no sabes qué vas a romper, ya necesitabas evals hace tiempo.
Para un asistente interno, 30 casos y un script bastan. No hace falta plataforma ni herramienta de pago para empezar.
