La mayoría de las suites de evals que leo están escritas como tests unitarios. Se afirma que la salida coincide, se cuentan los verdes y se lanza con el número. El marco está mal, y de una forma que cuesta dinero de verdad, porque un test unitario observa lo que prueba y un eval no.
No puedes ver si un modelo razona. Ves doscientas respuestas e infieres algo que nunca observas directamente. Esa inferencia es toda la disciplina de la psicometría, un campo que dedicó el siglo XX a averiguar cómo medir cosas que nadie puede señalar con el dedo: la inteligencia, la depresión, la comprensión lectora. Produjo un conjunto de resultados sobre cuándo esa medición funciona y cuándo falla sin hacer ruido.
La industria de la IA está redescubriendo esos fallos de uno en uno, entrada de blog tras entrada de blog. Benchmarks que se saturan. Puntuaciones que se mueven sin que el modelo cambie. Jueces que coinciden con los humanos de media y discrepan siguiendo un patrón. Nada de esto es nuevo. Tiene nombres, y los nombres vienen con soluciones.
Una puntuación sin error típico no es una puntuación
Ejecuta tu suite cinco veces contra el mismo modelo y los mismos prompts. El número se mueve. La temperatura de muestreo, el muestreo del propio juez, los efectos de orden dentro de la ventana de contexto, un paso de recuperación que hoy devuelve otro vecino. Cada uno de ellos es error de medida, y reportar un 87,3% a partir de una sola pasada es reportar una extracción de una distribución como si fuera la distribución.
La teoría clásica de los tests lo escribe así: la puntuación observada es la puntuación verdadera más el error. Suena trivial hasta que te tomas en serio la consecuencia: la fiabilidad es el techo de la validez. Una suite que discrepa de sí misma entre pasadas tampoco puede coincidir con nada más, incluido el resultado de producción que de verdad te importa. Las correlaciones se atenúan por la falta de fiabilidad, y ningún análisis ingenioso posterior recupera lo que el ruido se comió.
El panel izquierdo es lo que acaba pegado en las notas de versión. El derecho es lo que esas mismas pasadas sostienen de verdad.
La regla práctica es barata. Ejecuta la suite n veces, reporta la media y la dispersión, y trata cualquier mejora que caiga dentro de la banda como ninguna mejora. Prefiero ver 87,3 ± 2,1 en cinco pasadas que un 89,1 seguro de sí mismo en una, porque lo primero me dice si el número de la semana que viene significará algo.
Esto también zanja la discusión más común en un equipo de IA, la de si un cambio de prompt ayudó. Lo habitual es que la respuesta honesta sea que la suite no lo sabe decir, y saberlo vale más que el cambio.
Un número que son varias cosas
El segundo fallo es estructural. Una suite que mezcla corrección de llamadas a herramientas, cumplimiento de esquema, comportamiento de rechazo y razonamiento de varios pasos produce una puntuación compuesta, y cuando un compuesto se mueve no puedes decir qué se movió.
La medición lo llama dimensionalidad, y no es una cuestión filosófica sino empírica, una que puedes responder en una tarde. Puntúa cada ítem en todas las versiones de modelo que tengas. Correlaciona los ítems. Si se agrupan, tu número único son varios números con un abrigo puesto, y el informe honesto son subescalas.
La estructura de la izquierda es lo que asume un número único. La de la derecha suele ser lo que dicen las correlaciones.
Pasé años con exactamente este problema en otro campo. La evaluación de la dimensionalidad en estructuras bifactoriales, que es el caso en el que un factor general y varios específicos coexisten y el análisis ingenuo lo atribuye todo al general. El fallo se traslada sin modificación: un modelo que mejoró en emitir JSON válido sube un promedio de suite que un lector interpretará como mejor razonamiento, y nadie en la sala está mintiendo.
Reporta las subescalas. Si la decisión que vas a tomar depende de una de ellas, pésala de forma explícita y escribe por qué, en lugar de dejar que la aritmética de un promedio sin ponderar tome la decisión por ti.
La mayor parte de tu conjunto de evals no aporta información
El análisis de ítems es la herramienta más antigua del cajón y la que antes se paga. Cada ítem tiene una dificultad, la proporción de modelos que lo aciertan, y una discriminación, lo bien que separa a los modelos entre los que estás eligiendo.
Un ítem que todos los modelos aciertan y un ítem que todos fallan no aportan información sobre el orden. Cuestan tokens en cada pasada, inflan o deprimen la cifra principal y no contribuyen a la decisión. En una suite con un año de vida suelen ser la mayoría.
La saturación no es que los modelos se queden sin margen. Es que los ítems se quedan sin discriminación.
Esta es también la explicación real de la saturación de benchmarks, y es menos dramática que la versión habitual. Un benchmark no deja de funcionar porque los modelos sean demasiado buenos en un sentido general. Deja de funcionar porque sus ítems derivan hacia una dificultad en la que nada separa, y un test sin varianza no tiene señal. Es una propiedad del instrumento, no un hecho sobre la inteligencia.
Un juez LLM es un evaluador, y a los evaluadores se les audita
Cambiar un panel humano por un juez modelo no es una optimización de costes, es un cambio de instrumento, y trae las obligaciones que acompañan a uno.
Un evaluador te debe acuerdo con un criterio, y acuerdo significa un coeficiente que corrige por azar y no un porcentaje en bruto. Dos evaluadores que marcan igual el 90% de un conjunto en su mayoría aprobado pueden estar coincidiendo casi por completo por casualidad. Te debe estabilidad, porque el juez es un modelo y los modelos se actualizan por debajo de ti. Y te debe una respuesta sobre el comportamiento diferencial: un juez que coincide con los humanos el 90% de las veces en conjunto, y discrepa de forma sistemática en una población de candidatos, tiene un promedio que esconde el único resultado que importa.
Esto último deja de ser una preocupación académica en el momento en que el sistema toca contratación. Es también, no por casualidad, lo que pedirá un auditor, que es el punto donde el argumento de la medida y el regulatorio resultan ser el mismo argumento.
La validez es algo que se argumenta, no algo que se tiene
La última pieza es la que no tiene atajo. La validez no es una propiedad que una suite posee. Es una afirmación de que la puntuación sostiene una decisión concreta, y esa afirmación hay que hacerla y defenderla.
La versión que muerde en producción es la predictiva. Cuando la decisión viene después y tarda, una contratación, un ticket resuelto, una renovación, la validez aparente no vale nada y la única evidencia real es si la puntuación de hoy predice ese resultado meses más tarde. Lo que significa construir el vínculo a propósito: registra la puntuación del eval junto a la decisión, espera y comprueba. La mayoría de los equipos nunca cierra ese bucle y luego se pregunta por qué una victoria offline nunca apareció en el negocio.
Escribe el argumento en dos frases. Esta suite mide X. La usamos para decidir Y, y esta es la evidencia de que X predice Y. Si no puedes escribir la segunda frase, tienes un panel y no un instrumento.
Cómo se ve esto un miércoles
El stack es corriente. Promptfoo para las suites, Langfuse para las trazas, Datadog para lo que pasa después, Qwen autoalojado en AWS con vLLM para los flujos sensibles a la privacidad y APIs de frontera para el resto. Nada de eso es lo interesante.
Lo interesante son las cuatro preguntas que hago antes de dejar que un número justifique una decisión. Cuál es la dispersión entre pasadas. Si esto es un constructo o son tres. Qué ítems siguen discriminando y qué porcentaje de la suite es peso muerto. Y, si el número lo produjo un juez, cuál es su acuerdo con un criterio humano, calculado este trimestre y no el trimestre en que se validó.
Entre todas llevan una tarde. Son las preguntas que un psicómetra hace a cualquier test nuevo antes de que nadie pueda decidir nada con él.
Cierre
Hay una versión de este campo en la que todos reconstruyen la teoría de la medida desde cero, mal, durante los próximos cinco años, y publican los resultados como descubrimientos. Ya está ocurriendo, y la señal es la frecuencia con la que una entrada anuncia algo que tiene nombre en un artículo de 1951.
La alternativa es más barata. Los instrumentos son viejos, los modos de fallo están catalogados y las soluciones son en su mayoría aritmética que puedes ejecutar esta semana. Tu suite de evals es un instrumento de medida lo trates como tal o no. La única decisión es si descubres qué mide antes o después de que decida algo.