¿Quién calibra al juez? La brecha que nadie cierra

En seis entregas he recorrido cinco estrategias y cinco de las siete herramientas cuyo código he leído para la investigación que hay detrás. Hay una pregunta a la que la serie ha apuntado una y otra vez sin llegar a responderla del todo: ¿hasta qué punto es realmente fiable el juez en la tarea que ejecuta y con la rúbrica que le han dado?

Estoy construyendo AgentAnvil, un framework de pruebas guiado por contratos para agentes basados en LLM, y leer otros evaluadores me sirve para averiguar qué deberían restringir esos contratos. Las estrategias de esta serie limitan lo que el juez puede decir (partes 2 y 3), miden lo seguro que suena (parte 4), fijan lo que debe ignorar (parte 5) o prescinden de él donde bastan las comprobaciones deterministas (parte 6). Todas son honestas y funcionan, aunque cada una deja algo sin cubrir. Daba por hecho que ninguna de las cinco herramientas incluía la primitiva que mide con qué frecuencia el juez coincide con una persona en tu tarea. Al repasar el código por segunda vez he tenido que corregirme: dos de las cinco la traen. Lo que no ofrece ninguna es el flujo de trabajo que supedita el build de CI a esa concordancia, con una banda de confianza publicada que el build pueda leer.

Con esta entrada cierro la serie y trazo el mapa de la brecha, que es más estrecha de lo que creía, pero real.

La intuición

Un juez es un instrumento de medida. Si mides dos veces el mismo líquido con un termómetro, obtendrás dos lecturas. La dispersión entre ellas es la varianza del instrumento. El termómetro sirve porque, en algún momento antes de llegar a tus manos, un fabricante caracterizó su error frente a un patrón de referencia (agua hirviendo, punto de congelación, celdas con trazabilidad al NIST). Si lleva implícito un margen de error, es porque alguien pagó ese paso de calibración.

Un juez LLM no trae ese paso de serie. Escribes una rúbrica, eliges un modelo, lo lanzas sobre las trazas del agente y obtienes puntuaciones. El framework te devuelve la puntuación, pero rara vez le dice a la puerta de CI qué margen de error tiene en tu tarea. Para saberlo, tendrías que pasar los mismos ítems por uno o varios anotadores humanos, calcular la concordancia con el juez y tratar el desacuerdo restante como el error del instrumento frente a la referencia (el sesgo más el ruido que arrastre una sola pasada). El ruido del juez entre ejecuciones, por sí solo, se mide aparte volviendo a juzgar los mismos ítems. La primitiva estándar para medir esa concordancia es la κ de Cohen (Cohen, 1960, con los tramos de magnitud de Landis y Koch, 1977). Esa medida es el paso de calibración.

Cuando empecé la serie, suponía que a las herramientas de código abierto les faltaba la primitiva en sí, pero no es del todo así. Al repasar con grep los cinco repositorios, esta vez buscando términos de calibración, he visto que dos de las herramientas incluyen la κ del juez frente a las etiquetas de referencia (Ragas con validate_alignment() y TruLens con GroundTruthAggregator(true_labels=...)), que ARES trae una versión más tosca y que Inspect AI ofrece un α de concordancia entre jueces. Lo que no incluye ninguna es la puerta de calibración, el flujo de trabajo que rodea a esas primitivas: una banda de confianza publicada sobre la κ que el build de CI use como umbral para fallar, y un disparador que relance la calibración cuando cambien el modelo del juez o la rúbrica. Las primitivas existen, pero no la puerta que las envuelve. De esa brecha trata esta entrada.

El mapa de la brecha

Al final de la serie, la matriz de estrategias por herramienta queda así, ampliada con dos filas a las que no llegaron las entregas anteriores.

Las cinco primeras filas recogen lo que desgranó cada entrada. Ragas trae la restricción del alcance bien resuelta. DeepEval se encarga de la descomposición y, de pasada, roza la calibración con las probabilidades de los tokens. De ARES sale la cota de PPI, de TruLens la rúbrica negativa y de Inspect AI el reparto entre lo determinista y lo que puntúa un modelo. En total hay seis celdas llenas en cinco filas, una por estrategia salvo la calibración probabilística, que comparten DeepEval y ARES.

La sorpresa vino con la sexta fila. En el metrics/base.py de Ragas, validate_alignment() recibe tu juez y un conjunto de test etiquetado por personas y devuelve la κ de Cohen. Para las métricas discretas usa cohen_kappa_score, para las de ranking la κ ponderada y para las numéricas la r de Pearson. La guía práctica oficial («How to Align an LLM as a Judge») desarrolla la misma idea con el porcentaje bruto de concordancia, pero donde está la κ es en validate_alignment(). TruLens va más allá. En feedback/groundtruth.py, GroundTruthAggregator(true_labels=...) incluye cohens_kappa, ece (error de calibración esperado), brier_score, matthews_correlation y primitivas de correlación de rangos, todas accesibles directamente desde trulens.feedback y con sus propios tests. ARES, por su parte, da la exactitud bruta del juez frente a la referencia junto a su cota de PPI. Las primitivas ni son exóticas ni faltan. Dos de las cinco herramientas incluyen la κ del juez frente a la referencia, ARES trae una versión más tosca e Inspect AI ofrece krippendorff_alpha(), pensada para medir la concordancia entre jueces sin compararlos con la referencia.

La séptima fila sigue vacía en todas las herramientas. Ninguna de las cinco envuelve esas primitivas en una puerta de CI ligada a una banda de confianza publicada, del estilo de «haz que el build falle cuando la κ baje de 0,7 y la cota inferior de su IC del 95 % quede por debajo de 0,6». Ragas devuelve una estimación puntual de la κ, y el bootstrap te toca a ti. TruLens devuelve lo mismo, aunque es la que más ha montado a su alrededor. Su paquete de benchmark tiene AlignmentReport, CriteriaABTest (para cambios de rúbrica) y CrossModelAlignment (para cambios del modelo del juez), que comparan con un conjunto de referencia, y Run.compare() pone un intervalo de confianza por bootstrap a las diferencias de puntuación entre ejecuciones. Pero todo eso se usa a mano. Ninguna de las cinco publica una banda de confianza sobre la κ ni la conecta a una puerta del build.

ARES es la que más se acerca, y merece la pena deshacer el equívoco. Su implementación de PPI pone un intervalo de confianza alrededor de la puntuación agregada del agente, con lo que parece que debería llenar la fila de la puerta de calibración. Sin embargo, ese intervalo se calcula sobre el estadístico de la población, mientras que una puerta de calibración lo necesita sobre la concordancia con las etiquetas humanas del conjunto de test. PPI te dice que la puntuación agregada cae dentro de una banda (Angelopoulos et al., 2023), pero no le dice al build que falle cuando la concordancia entre el juez y las personas se desvía.

Así que la brecha existe, aunque es más estrecha de lo que la planteé al empezar esta entrada.

Lo que cuesta la brecha

Supongamos una puerta de CI. Una PR modifica el generador de planes de un agente, la CI lanza la batería de evaluación (veinte rúbricas de mil ítems cada una) y dos rúbricas bajan 3 puntos. ¿Es real esa bajada?

En realidad son dos preguntas. Para saber si la bajada supera el ruido no hacen falta etiquetas; basta un bootstrap pareado o un test de permutaciones sobre las diferencias por ítem en esos 1000 ítems, con las dos ejecuciones juzgadas desde cero para que la varianza del juez entre ejecuciones quede dentro de las diferencias. En cambio, solo las etiquetas pueden decir si una bajada en la escala del juez es de las que notaría una persona. Un juez que se equivoca al azar acerca a cero las diferencias reales, y uno al que sesga el propio cambio (por ejemplo, porque altera el estilo de la salida) puede inventarlas u ocultarlas.

En esta demo fijas lo fiable que es tu juez frente a una referencia oculta y ves cómo queda la banda de confianza de la κ de Cohen con distintos tamaños de muestra. Sin ser una herramienta de calibración, enseña lo que cuesta no tener una. Aunque sepas que tu juez acierta el 80 % de las veces, la banda que puedes publicar es ancha mientras no hayas anotado cientos de ítems. Por debajo de unos 100 ítems etiquetados por personas, la banda es demasiado ancha para certificar la validez del juez.

La mayoría de los equipos no llega a 100 ítems etiquetados por personas en cada rúbrica, y de hecho la mayoría no tiene ninguno. La serie ha ido documentando herramientas que funcionan bien en esa situación con estrategias que no necesitan ni una etiqueta. La brecha es lo que esas estrategias no pueden suplir.

Por qué nadie ofrece la puerta

Las primitivas son la parte fácil. Lo difícil es el flujo de la puerta de calibración que las rodea, y lo es por algo concreto que no encaja en un evaluador de código abierto de propósito general.

Un framework puede incluir un juez, plantillas de rúbrica, grafos de descomposición, lógica de reintentos y parsers de salida estructurada, todo lo que has leído en las partes 2 a 6. También puede envolver sklearn.metrics.cohen_kappa_score cuando ya hay etiquetas, que es justo lo que hace GroundTruthAggregator.cohens_kappa de TruLens en feedback/groundtruth.py. Lo que no puede traer un framework general es el umbral. La puerta de CI que falla cuando κ < 0,7 necesita saber cuál es tu 0,7, en qué rúbrica y con cuánta tolerancia a las oscilaciones ruidosas que no son regresiones reales. Nada de eso vale igual para todas las tareas, y cualquier valor por defecto sería erróneo en algún caso importante.

Esta otra demo enseña lo que cuesta en realidad producir las etiquetas. Eliges el número de ítems, el de anotadores y el tiempo de anotación por ítem, y la demo te devuelve la factura. Para una rúbrica es barata, pero se multiplica por cada rúbrica de la batería y vuelve con cada cambio de juez o de rúbrica. Por esa factura y porque, como decía arriba, cada equipo tiene que fijar su propio umbral, nadie ha empaquetado el hook de la puerta de calibración. La idea que guía el diseño de ARES («anota un conjunto pequeño y aprovéchalo bien») es la respuesta de la literatura al coste de etiquetar, aunque ARES solo la aplica a la evaluación de RAG.

Lo que queda por integrar está acotado y es concreto: un wrapper que ponga un intervalo de confianza por bootstrap a la κ que ya calculan Ragas y TruLens, una opción de configuración que diga «estos son mis umbrales, úsalos como puerta» y un hook que lance la recalibración cuando cambien el modelo del juez o la versión de la rúbrica. Las piezas ya están hechas. La estimación puntual la da sklearn.metrics.cohen_kappa_score, las bandas de confianza analíticas para la κ, el AC1 y el α de Krippendorff salen de la familia irrCAC (el paquete de Gwet para la concordancia entre anotadores) y las extensiones con varios anotadores las cubre statsmodels.stats.inter_rater. Ese wrapper es el trabajo que ninguna herramienta ha hecho de principio a fin.

Qué puedes hacer hoy

Hay tres cosas que puedes hacer este trimestre sin cambiar de herramienta.

La primera es reservar presupuesto para una muestra de calibración. Empieza con 50 ítems por rúbrica que etiquete una persona cuidadosa. El segundo juego de etiquetas lo pone tu juez, y con el par sacas una estimación puntual de la κ de Cohen. Cuando la rúbrica se estabilice, pasa a una muestra de entre 100 y 200 ítems, porque por debajo de unos 100 la banda de la κ es demasiado ancha para certificar la validez del juez (lo muestra la primera demo). Tanto si usas Ragas (validate_alignment()) como TruLens (GroundTruthAggregator) u otra herramienta, este es el único sitio donde no te libras de etiquetar. Repite la calibración una vez por trimestre, y también cada vez que cambien el modelo del juez o la rúbrica.

La segunda, calcular tú mismo el intervalo de confianza por bootstrap y escribir el umbral en la puerta. Como ni Ragas ni TruLens devuelven una banda de confianza sobre la κ, tendrás que sacarla con un bucle de bootstrap de 1000 remuestreos o con las funciones de intervalo de confianza que trae irrCAC (kappa2.table en R, irrCAC.table.CAC(table).cohen() en Python). Después, cuando la cota inferior caiga por debajo de tu umbral, haz que el build falle con un error de calibración necesaria, sin marcarlo como regresión de calidad. Vistos desde fuera, los dos fallos se parecen, pero se arreglan de forma distinta (uno editando la rúbrica, el otro corrigiendo el agente), y distinguirlos es justo lo que no puede hacer por ti un juez sin ese wrapper.

La tercera, ser honesto en el informe de evaluación sobre lo que el juez puede decirte y lo que no. No es lo mismo afirmar «La fidelidad ha bajado 3 puntos» que afirmar «En esta ejecución, el juez ha puntuado la fidelidad 3 puntos por debajo (IC del 95 % por bootstrap pareado, de 1,6 a 4,4). En un conjunto de calibración de 200 ítems, su concordancia con las personas es κ = 0,72 (IC del 95 %, de 0,62 a 0,82), así que la bajada es real en la escala del juez, y esa concordancia acota hasta qué punto refleja una regresión que notaría una persona». Lo segundo es lo que tendría que publicar una puerta de calidad para controlar la calidad de verdad.

Nada de esto exige que tu herramienta de código abierto haga más de lo que ya hace. Exige, eso sí, aceptar que el wrapper de la puerta de calibración te toca a ti y tratarlo como una tarea de ingeniería presupuestada y repetible, sin convertirlo en un proyecto de investigación.

La serie, de principio a fin

Las estrategias de esta serie se complementan sin competir entre sí. Son cinco formas distintas de atacar el mismo problema, el de estrechar lo que un juez LLM puede estropear. Un harness de evaluación maduro las combina: determinista donde puede (parte 6), con el alcance restringido donde no puede (parte 2), con descomposición estructural donde el juicio es complejo (parte 3), anclado por rúbrica donde se solapa con métricas hermanas (parte 5) y con calibración probabilística donde la salida necesita un intervalo (parte 4). Es una arquitectura plural.

Apiladas, las cinco quedan así. Si desactivas una estrategia, la barra deja al descubierto la parte que acotaba. El tramo de la derecha, el residuo que solo acotaría la puerta de calibración, no se mueve con ningún interruptor. (Los anchos de los tramos son ilustrativos.)

Estoy trabajando en esta brecha con AgentAnvil. Que la acabe cerrando AgentAnvil u otra herramienta es lo de menos; la brecha existe, tiene nombre y las estrategias de esta serie no la cierran.

Regla práctica: el juez es un instrumento de medida, y ningún build puede defender una medida que no lleve una banda de calibración publicada y vigilada por una puerta. Las cinco herramientas de esta serie estrechan la varianza, pero ninguna trae la puerta.