Índice del nivel: LLM-as-judge calibrado

0.1Por qué este nivel

Un juez sin validar es otra vibe. Pedirle a un LLM que "puntúe del 1 al 10 si esta respuesta es buena" da la sensación de que ya mides calidad. No mides nada: cambiaste una corazonada por un número con decimales.

En N0 hiciste visible el agente de Aurora con trazas. En N1 miraste esas trazas, nombraste cómo falla y construiste un dataset etiquetado con su modo de fallo nº1. Ese fallo es la respuesta que no se apoya en la política que el agente recuperó (el reembolso fantasma que abrió el curso). Ahora toca medir ese fallo a escala.

Algunos fallos se miden barato y determinista: un formato de pedido inválido lo caza un regex. Otros — "¿está esta respuesta fundamentada en este contexto?" — exigen un juicio semántico que solo otro modelo puede dar a escala. Para esos construyes un LLM-as-judge. Pero un juez solo sirve si juzga como el humano cuyo criterio importa: la métrica del juez no es su score, es su acuerdo contigo. Este nivel te enseña a construir ese acuerdo y a demostrarlo con números, no a afirmarlo.

El juez que construyas aquí no se queda en N2: es el motor de groundedness de la RAG triad (N3), corre en el gate de CI (N4) y vigila producción (N5). Calíbralo bien una vez y lo reutilizas todo el curso.

0.2Lecciones

1. ¿Código o juez? Mide barato primero — los 3 niveles de coste de Husain y cuándo basta una assertion determinista frente a cuándo necesitas un juez.
2. Anatomía de un LLM-as-judge — pointwise vs pairwise, reference-free, por qué binario gana a Likert, y cómo elegir el modelo juez.
3. Validar el juez contra humanos — TPR/TNR/precision (no accuracy cruda), la matriz de confusión, y κ sobre la escala de Landis-Koch.
4. Los sesgos del juez y cómo domarlos — posición (swap-and-average), verbosidad y self-preference: mecanismo y mitigación de cada uno.
5. Alinear el juez: el bucle de iteración — el bucle baseline → distribución de errores → refinar rúbrica → re-ejecutar, como en Ragas y Honeycomb.
6. Juez calibrado: el checkpoint C2 — construyes, validas y alineas el juez del fallo nº1 de Aurora de punta a punta (checkpoint C2).

0.3El checkpoint C2 — Juez calibrado

Para el modo de fallo nº1 que descubriste en N1, decidirás medirlo con código o con juez. Si es juez: lo construirás con una rúbrica binaria (pass/fail) y lo validarás contra ≥100 etiquetas humanas reportando TPR/TNR (no accuracy cruda). Auditarás sus sesgos (posición, verbosidad, self-preference) y mitigarás al menos uno. Iterarás el prompt hasta superar el umbral de acuerdo que acuerdes. Entregable: el juez + un informe de validación con matriz de confusión, TPR/TNR, sesgos auditados y la curva de iteración.

Se evalúa por cinco dimensiones. Las tres primeras: elección código-vs-juez justificada, diseño binario con juez ≥ capacidad del evaluado, y validación con TPR/TNR y matriz interpretada. Las dos restantes: ≥1 sesgo auditado y mitigado, y una curva de mejora documentada que alcanza el umbral acordado.