Evals en CI: probar lo que no es determinista

Un equipo que pone un LLM en producción descubre pronto un problema incómodo: la suite de pruebas que garantizó calidad durante años no sirve para la función nueva. Las aserciones de igualdad no funcionan cuando la salida correcta puede escribirse de diez maneras distintas.

Por qué la prueba determinista no cubre

La prueba tradicional compara la salida con un valor esperado. La salida de un LLM varía entre ejecuciones, es sensible a cambios mínimos de prompt y puede estar bien con palabras completamente distintas a las de tu fixture.

El reflejo común es renunciar a probar y validar a mano antes de cada release. Eso funciona hasta el tercer cambio de prompt, cuando ya nadie recuerda qué comportamiento era intencional y cuál fue una regresión.

La salida no es abandonar las pruebas, es cambiar la pregunta. En vez de "¿la respuesta es exactamente esta?", pregunta "¿la respuesta satisface estas propiedades?".

Tres capas, de barata a cara

Capa 1, aserciones deterministas sobre la salida. Cabe más de lo que parece: el JSON es válido y cumple el schema, la respuesta cita al menos una fuente, no excede N caracteres, no contiene PII, la llamada a herramienta usó los parámetros correctos. Es rápida, estable y atrapa la mayoría de las regresiones de integración.

Capa 2, conjunto dorado con verificación programática. De treinta a cien casos reales con propiedades verificables: contiene la cifra correcta, clasifica en la categoría correcta, rechaza cuando debería rechazar. Corre en segundos y detecta la mayoría de las roturas de calidad.

Capa 3, LLM como juez. Para lo que queda: tono, completitud, utilidad. Es la capa más cara y menos confiable, y por eso debe ser la más pequeña.

El juez tiene sesgos conocidos

Usar un modelo para evaluar a otro funciona mejor de lo que sugiere la intuición. El trabajo que popularizó la práctica midió más de 80% de concordancia entre jueces LLM fuertes y la preferencia humana, un nivel comparable al acuerdo entre dos personas.

Ese mismo trabajo documentó los sesgos, e ignorarlos invalida el resultado:

• Posición. El juez tiende a preferir la primera respuesta presentada. Mitigación: alternar el orden y correr dos veces.
• Verbosidad. Las respuestas más largas puntúan mejor aunque no aporten más. Mitigación: un criterio explícito que penalice la redundancia.
• Autopreferencia. Los modelos tienden a favorecer texto con su propio estilo. Mitigación: juzgar con una familia de modelo distinta de la que generó.

Un juez sin rúbrica explícita mide estilo. Con una rúbrica de tres a cinco criterios objetivos y escala corta, se vuelve una señal utilizable.

Qué corre en CI y qué corre fuera

La tentación es correr todo en cada push. No lo hagas: las llamadas al modelo cuestan dinero y tiempo, y una suite de diez minutos deja de ejecutarse en la práctica.

Un recorte que funciona: capas 1 y 2 en cada pull request, con modelo pequeño y temperatura cero, apuntando a menos de dos minutos. Capa 3 al hacer merge a la rama principal y antes del release, sobre una muestra. El resultado se vuelve un artefacto versionado para comparar releases.

Trata la variación como señal, no como ruido: corre los casos críticos varias veces y registra la dispersión. Una función que oscila entre 70% y 95% en el mismo conjunto no está lista, por buena que parezca la media.

Evaluación holística, no una sola nota

Iniciativas como HELM consolidaron una idea que también aplica a producto: evaluar en múltiples dimensiones y escenarios en vez de reducir todo a un número. Una precisión media alta puede esconder una falla sistemática en una categoría que es 5% del volumen y 80% del riesgo.

En la práctica, desglosa el conjunto por escenario de uso y mira el peor, no el promedio.

Qué significa esto para tu equipo

Empieza hoy por la capa 1: schema, formato, presencia de cita, ausencia de PII. No necesita framework y ya bloquea la clase de regresión más común.

Construye el conjunto dorado a partir de tráfico real, no de casos inventados. Cada vez que aparece un bug en producción, el caso entra al conjunto. En tres meses tienes una regla que refleja tu problema y no un benchmark genérico.

Solo entonces suma el juez, con rúbrica escrita y orden alternado. Y versiona los resultados: sin historial, no puedes afirmar si cambiar de modelo mejoró o empeoró tu aplicación.