La IA no es determinista. Dos ejecuciones con la misma entrada pueden dar respuestas distintas. Por eso no basta con probar a mano: necesitas evals.
Qué es una eval
Una eval es una prueba con una entrada, una salida y una forma de puntuarla. En un sistema de IA, la entrada puede ser una pregunta, una llamada, un documento o una tarea con varias herramientas. La salida puede ser un texto, una reserva, una etiqueta o una llamada a una API. La eval comprueba si esa salida cumple el criterio que tú has definido.
La diferencia con un test tradicional está en la variabilidad. El mismo prompt puede producir respuestas diferentes. Por eso conviene ejecutar cada eval muchas veces, con casos distintos, y mirar la distribución de resultados. Un caso que pasa una vez no demuestra nada. Un conjunto que pasa de forma consistente, sí.
Los componentes
Una eval tiene una tarea, un evaluador y un resultado. La tarea es el caso concreto: el cliente pide cambiar una reserva, el sistema tiene que consultar el calendario y confirmar. El evaluador es la lógica que decide si la respuesta es correcta. El resultado es lo que queda al final: una reserva modificada, una derivación, una respuesta con el dato correcto.
Además, necesitas la traza completa. No basta con la respuesta final. Qué contexto se recuperó, qué herramienta se llamó, con qué argumentos, cuántos turnos se usaron y cuánto costó. Sin la traza, sabes que falló, pero no por qué.
Tres tipos de evaluador
Los evaluadores de código son los más baratos y fiables. Comprueban una etiqueta, un formato, una llamada a una herramienta o el estado final de una base de datos. No entienden de matices y solo son fiables si la regla y los datos de prueba están bien construidos.
Los evaluadores de modelo usan otro modelo para puntuar. Sirven para respuestas abiertas, tono, calidad de una síntesis o comparaciones entre dos salidas. Son más flexibles y más caros, y necesitan calibración humana. Un juez que puntúa sin criterio claro produce números que parecen rigurosos y no significan nada.
Los evaluadores humanos son el patrón de referencia. Se usan para calibrar a los otros dos, para casos delicados y para definir qué es un buen resultado. No escalan solos, pero sin ellos no sabes si tu juez automático está midiendo lo que crees.
Capacidad y regresión
Hay dos preguntas distintas. La primera es qué puede hacer el sistema: casos difíciles, casos nuevos, casos que todavía fallan. La segunda es si sigue haciendo bien lo que ya hacía. La primera es una eval de capacidad. La segunda es una eval de regresión.
Las dos importan. Si solo mides capacidad, puedes romper algo que funcionaba. Si solo mides regresión, no mejoras. La suite tiene que crecer con el sistema y con los fallos que aparecen en producción.
Cómo empezar sin montar un laboratorio
No necesitas cien casos el primer día. Anthropic recomienda empezar con 20 o 50 tareas sacadas de fallos reales. OpenAI dice algo parecido: empieza por lo que ya pruebas a mano y conviértelo en casos repetibles. Un puñado de casos bien elegidos vale más que un benchmark genérico que no se parece a tu trabajo.
Elige casos normales, casos límite y casos adversariales. Un cliente que cambia de tema, una herramienta que devuelve un error, un documento incompleto, una petición que el sistema no debe aceptar. Si solo pruebas el camino feliz, la eval te va a decir que todo va bien hasta que llegue un cliente real.
El juez modelo
Si usas un modelo como juez, pídele una decisión concreta: pasa o no pasa, A o B, una puntuación con una rúbrica clara. Los jueces funcionan mejor comparando que generando una nota libre. También conviene darles una salida para decir «no lo sé» cuando no tienen información suficiente.
Calibra el juez con personas. Haz que varias personas puntúen los mismos casos y compara sus decisiones con las del modelo. Si el juez discrepa mucho, el problema puede estar en la rúbrica, en los casos o en el propio juez. No lo dejes pasar.
La eval no termina en desarrollo
En producción aparecen casos que no habías imaginado. La eval tiene que alimentarse de ellos. Revisa las trazas, guarda los fallos y añádelos a la suite. Así la suite de evals crece con el trabajo real sin depender de que alguien se acuerde de añadir casos.
La eval sirve para decidir. Sirve para saber si un cambio mejora, si un modelo nuevo aguanta o si el sistema está listo para más volumen. Si no cambia ninguna decisión, es un informe. Y los informes no mejoran el producto.
Sigue leyendo