El módulo 3 cerró con una tabla cuyas dos últimas filas decían “ninguno”: tono y utilidad, fidelidad al contexto. Ahí se acaba lo que un if puede verificar y empieza el territorio del LLM-as-judge — un modelo que lee la salida de tu sistema y le pone una nota. Es la técnica que hace posible medir lo que importa, y viene con un problema que se enuncia en una línea y casi nadie enfrenta: acabas de reemplazar un sistema no determinista que no sabes evaluar por dos. Este módulo trata sobre cómo salir de ese bucle, y la respuesta es un número: cuánto se parece el juez a un humano que sabe.

La tesis del módulo

Un juez LLM sin calibrar no es una métrica, es una segunda opinión automatizada. La diferencia entre las dos cosas es un número medible — el acuerdo con anotadores humanos — y hasta que no lo calculas, todo lo que optimices contra ese juez puede ser ruido con tres decimales.

Lo que ya está cubierto (y no vamos a repetir)

Antes de avanzar, dos cosas de este tema ya están tratadas a fondo en otro lugar del sitio y no tiene sentido escribirlas de nuevo.

La rúbrica del juez — cómo se escribe un prompt de evaluación que produzca señal en vez de ruido, con niveles descritos, razonamiento antes del veredicto y cita textual obligatoria — está desarrollada con el prompt completo en Evaluación de RAG, aplicada a fidelidad. La forma general la vimos además en el módulo 2 al escribir niveles: mismos principios, otra aplicación.

Los cuatro sesgos del juez — posición (prefiere la primera opción en comparaciones), longitud (premia respuestas largas), no determinismo (la misma entrada da notas distintas) y auto-preferencia (prefiere el texto de su propia familia de modelos) — están en la tabla de mitigaciones de ese mismo módulo, y en la Práctica 12 de Evaluación de agentes. Dalos por leídos: temperatura 0, juez de otra familia que el generador, promediar pasadas, evaluar en ambos órdenes, y decir explícitamente en la rúbrica si el canal exige respuestas cortas.

Lo que aquellos textos mencionan en dos frases — “calibra el juez contra humanos” — es todo lo que viene ahora. Es el paso que casi nadie da y el que decide si tu métrica significa algo.

Los tres modos de juzgar

Antes de calibrar hay que elegir qué le pides al juez, porque el modo cambia la varianza, el costo y lo que se puede concluir.

Pointwise (puntual). El juez ve un caso y le pone una nota absoluta según una rúbrica. Es el modo más natural y el más usado. Su debilidad: la escala absoluta deriva. El mismo juez, con el mismo prompt, aplicado en enero y en marzo, puede correr su noción de “4” — y como no tienes ancla externa, no lo notas.

Pairwise (por pares). El juez ve dos salidas para la misma entrada y dice cuál es mejor (o empate). Es notablemente más confiable que el pointwise, por una razón cognitiva que también aplica a humanos: comparar es más fácil que calificar. Su debilidad: no da un valor absoluto, así que no puedes poner un umbral fijo tipo ”≥ 0.85”; solo puedes decir “B le gana a A en el 61% de los casos”. Y sufre el sesgo de posición, que se mitiga corriendo cada par en los dos órdenes.

Con referencia (reference-based). El juez ve la salida y también la respuesta ideal escrita por un humano, y evalúa qué tan cerca está. Es el modo con menos varianza de los tres, porque el juez tiene un ancla concreta en vez de un criterio abstracto. Su costo está antes: alguien tiene que escribir la respuesta ideal de cada caso, que es el trabajo más caro del programa de evals.

Modo	Qué pregunta	Varianza	Costo por caso	Umbral fijo	Cuándo usarlo
Pointwise	¿Qué nota merece?	Alta	1 llamada	Sí	Gate en CI, seguimiento en el tiempo
Pairwise	¿Cuál de las dos es mejor?	Baja	2 llamadas (ambos órdenes)	No	Elegir entre dos versiones o modelos
Con referencia	¿Se acerca a la ideal?	Muy baja	1 llamada + escribir la ideal	Sí	Dominio con respuesta correcta definible

La combinación que rinde en la práctica: pairwise para decidir entre candidatos (cambio de prompt, cambio de modelo) y pointwise o con referencia para el gate que corre en cada PR, porque el gate necesita un número absoluto contra un umbral. Son dos usos distintos y no hay que forzar uno solo.

Ojo: si eliges pairwise, la comparación es siempre contra una versión ancla fija — típicamente la que está en producción — y no contra “la corrida anterior”. Si cada versión se compara con la inmediatamente previa, los errores se acumulan en cadena y en seis iteraciones puedes haber empeorado respecto al punto de partida ganando todas las comparaciones del camino.

El protocolo de calibración

Calibrar es responder una pregunta: ¿el juez está de acuerdo con un humano que sabe? Y para responderla hace falta un humano que juzgue los mismos casos. El protocolo tiene cinco pasos y se hace una vez por proyecto, más cada vez que cambias la rúbrica o el modelo del juez.

        PROTOCOLO DE CALIBRACIÓN

  ┌──────────────────────┐
  │ 1. MUESTREAR         │  50 casos
  │    estratificado     │  de tu dataset
  └──────────┬───────────┘
             ▼
  ┌──────────────────────┐
  │ 2. ANOTAR A CIEGAS   │  2 personas,
  │    2 anotadores      │  misma rúbrica
  └──────────┬───────────┘
             ▼
  ┌──────────────────────┐   bajo   ┌───────────────┐
  │ 3. ACUERDO ENTRE     │ ───────► │ la rúbrica es │
  │    HUMANOS (kappa)   │          │ ambigua: la   │
  └──────────┬───────────┘          │ reescribes    │
             │ alto                 └───────┬───────┘
             ▼                              │
  ┌──────────────────────┐                  │
  │ 4. RESOLVER EMPATES  │                  │
  │    verdad de refe-   │                  │
  │    rencia final      │                  │
  └──────────┬───────────┘                  │
             ▼                              │
  ┌──────────────────────┐   bajo           │
  │ 5. ACUERDO JUEZ vs   │ ─────────────────┘
  │    HUMANO (kappa)    │   arreglas la rúbrica
  └──────────┬───────────┘   del juez, no el modelo
             │ alto
             ▼
      juez utilizable como métrica

Fíjate en el orden, que es lo más importante del diagrama: primero se mide el acuerdo entre humanos, y solo después el acuerdo juez-humano. La razón es lógica: si dos personas expertas no se ponen de acuerdo entre ellas, no existe una verdad contra la cual medir al juez, y cualquier número que calcules después es aritmética sobre arena. El acuerdo humano-humano es el techo del acuerdo juez-humano.

Paso 1: cuántos casos anotar

El rango útil es 50 a 100 casos, y el punto es que anotar es caro en horas humanas, no en dólares.

Menos de 30: la kappa tiene un intervalo de confianza tan ancho que no permite concluir nada.
50: el número de trabajo. Son unas 2 a 3 horas por anotador para respuestas de chat.
Más de 100: la precisión mejora poco y el costo humano crece linealmente. Mejor gastar ese esfuerzo en recalibrar más seguido.

La muestra debe ser estratificada, no aleatoria. Si tomas 50 casos al azar de un sistema que funciona bien, 45 van a ser fáciles, todo el mundo va a estar de acuerdo en ellos y tu kappa va a salir alta por razones equivocadas. Lo que quieres es cubrir el rango completo: casos claramente buenos, claramente malos y — sobre todo — la zona gris, que es donde el juez de verdad se equivoca y donde vive el valor de la calibración.

Paso 2: anotar a ciegas, dos personas

Cuatro reglas que hacen que la anotación sirva:

A ciegas del juez. El anotador no ve la nota del LLM. Si la ve, se ancla a ella y el acuerdo sube artificialmente — estarías midiendo la sugestión, no la concordancia.

Independientes entre sí. Los dos anotadores no conversan mientras anotan. El acuerdo entre ellos es justamente la medida de cuán clara es la rúbrica; si se coordinan, esa medida se destruye.

Con la misma rúbrica que el juez. Literalmente el mismo texto de niveles que va en el prompt del juez. Si los humanos usan un criterio y el juez otro, el desacuerdo que midas es un artefacto tuyo.

Registrando la duda. Una columna extra donde el anotador marca “no estoy seguro”. Los casos marcados así son oro puro: apuntan exactamente a los huecos de la rúbrica.

Paso 3 y 5: por qué kappa y no porcentaje de acuerdo

Aquí está el corazón técnico del módulo. La tentación es medir el acuerdo como “en cuántos casos coincidieron”, y ese número miente cuando las clases están desbalanceadas.

Un ejemplo que lo deja obvio. Tu agente funciona bien, así que el 95% de las respuestas son aceptables. Un juez perezoso que dijera “aceptable” siempre, sin mirar nada, acertaría el 95% de las veces. ¿Es un buen juez? Es inútil: no detecta ni un solo caso malo, que es exactamente para lo que lo pusiste.

Kappa de Cohen (κ) resuelve eso descontando el acuerdo que se explica solo por azar:

κ = (p₀ − pₑ) / (1 − pₑ)

donde p₀ es el acuerdo observado (proporción de casos en que coincidieron) y pₑ es el acuerdo esperado por azar, dado cuánto usa cada anotador cada categoría.

La intuición de la fórmula: el numerador es cuánto acuerdo hay por encima del azar, y el denominador es cuánto acuerdo por encima del azar era posible como máximo. Así κ = 1 es acuerdo perfecto, κ = 0 es exactamente el acuerdo que darían dos monedas con esas frecuencias, y κ negativo es acuerdo peor que el azar.

Ejemplo numérico, paso a paso

Calibramos un juez binario (aceptable / no aceptable) sobre 50 casos. Esta es la tabla de contingencia entre el juez y la verdad humana consolidada:

	Humano: aceptable	Humano: no aceptable	Total juez
Juez: aceptable	32	8	40
Juez: no aceptable	3	7	10
Total humano	35	15	50

Paso 1 — acuerdo observado (p₀). Coincidieron en la diagonal: 32 + 7 = 39 casos de 50.

p₀ = (32 + 7) / 50 = 39 / 50 = 0.78

Un 78% de acuerdo. Suena decente. Sigamos.

Paso 2 — proporciones marginales. Cuánto usa cada uno cada categoría:

Juez dice "aceptable":     40 / 50 = 0.80
Humano dice "aceptable":   35 / 50 = 0.70
Juez dice "no aceptable":  10 / 50 = 0.20
Humano dice "no aceptable":15 / 50 = 0.30

Paso 3 — acuerdo esperado por azar (pₑ). Es la probabilidad de que coincidan por casualidad, sumando las dos formas de coincidir:

pₑ = (0.80 × 0.70) + (0.20 × 0.30)
   =     0.56      +     0.06
   = 0.62

Lee ese 0.62: dos anotadores que respondieran al azar, con esas mismas frecuencias, coincidirían en el 62% de los casos. Ese es el piso gratis que el porcentaje de acuerdo te estaba regalando.

Paso 4 — kappa.

κ = (p₀ − pₑ) / (1 − pₑ)
  = (0.78 − 0.62) / (1 − 0.62)
  = 0.16 / 0.38
  = 0.421

El resultado. Un 78% de acuerdo que parecía razonable se convierte en κ = 0.42: acuerdo moderado, en el límite bajo de lo utilizable. Ese es exactamente el valor de kappa como métrica — te quita el crédito por el acuerdo que venía de regalo.

Y el diagnóstico está en la tabla: la celda de 8 casos donde el juez dijo “aceptable” y el humano dijo “no”. El juez es demasiado permisivo, deja pasar respuestas que un experto rechaza. Si lo usaras como gate, tu agente publicaría con un 16% de respuestas malas aprobadas.

Tabla de interpretación

La escala de referencia es la de Landis y Koch (1977), que sigue siendo la convención de facto:

κ	Interpretación	Qué significa para tu juez
< 0.00	Peor que el azar	Algo está invertido: revisa el mapeo de etiquetas
0.00 – 0.20	Insignificante	El juez no mide lo que crees. No lo uses
0.21 – 0.40	Aceptable (bajo)	Sirve para ordenar tendencias, no para bloquear
0.41 – 0.60	Moderado	Utilizable con revisión humana de los casos límite
0.61 – 0.80	Sustancial	El objetivo realista para un juez de producción
0.81 – 1.00	Casi perfecto	Excelente; sospecha si la tarea era subjetiva

Dos criterios prácticos sobre esta tabla:

El objetivo es κ ≥ 0.6 con la verdad humana. Por debajo de eso, el juez ordena pero no decide: puedes usarlo para ver tendencias, no para cerrar un gate.

Y el acuerdo humano-humano tiene que ser mayor. Si dos expertos llegan a κ = 0.55 entre ellos, un juez con κ = 0.55 contra ellos ya es tan bueno como un humano y no tiene sentido exigirle 0.8. El techo lo pone la tarea, no el modelo.

Cuidado: kappa como la calculamos aquí asume categorías nominales (sin orden). Si tu rúbrica es 1–5, confundir un 4 con un 5 no es lo mismo que confundir un 5 con un 1, y kappa simple castiga los dos errores igual. Para escalas ordenadas usa kappa ponderada (weights="quadratic"), que penaliza según la distancia entre las categorías.

El código

"""calibracion.py — acuerdo inter-anotador y acuerdo juez-humano.

cohen_kappa_score viene en scikit-learn y hace exactamente la fórmula
de arriba. Lo escribimos también a mano para que se vea que no hay
nada oculto detrás.
"""
import json
from collections import Counter
from sklearn.metrics import cohen_kappa_score, confusion_matrix


def kappa_a_mano(a: list, b: list) -> float:
    """Kappa de Cohen sin librerías: (p0 - pe) / (1 - pe)."""
    n = len(a)
    # p0: proporción de casos en que coinciden
    p0 = sum(x == y for x, y in zip(a, b)) / n
    # pe: suma sobre categorías del producto de marginales
    ca, cb = Counter(a), Counter(b)
    categorias = set(a) | set(b)
    pe = sum((ca[k] / n) * (cb[k] / n) for k in categorias)
    return (p0 - pe) / (1 - pe)


# Verificación con el ejemplo del texto: 32 / 8 / 3 / 7
juez   = ["ok"] * 32 + ["ok"] * 8 + ["no"] * 3 + ["no"] * 7
humano = ["ok"] * 32 + ["no"] * 8 + ["ok"] * 3 + ["no"] * 7
print(round(kappa_a_mano(juez, humano), 3))            # 0.421
print(round(cohen_kappa_score(juez, humano), 3))       # 0.421


def calibrar(path_anotaciones: str) -> dict:
    """Cada línea: {"id", "anotador_a", "anotador_b", "juez"}.

    Orden obligatorio: primero A vs B (¿es clara la rúbrica?),
    después consolidado vs juez (¿sirve el juez?).
    """
    with open(path_anotaciones, encoding="utf-8") as f:
        filas = [json.loads(l) for l in f if l.strip()]

    a = [r["anotador_a"] for r in filas]
    b = [r["anotador_b"] for r in filas]
    k_humanos = cohen_kappa_score(a, b)

    # Los casos donde los humanos no coinciden NO entran en la
    # comparación con el juez: no hay verdad contra la cual medir.
    resueltos = [r for r in filas if r["anotador_a"] == r["anotador_b"]]
    verdad = [r["anotador_a"] for r in resueltos]
    juez_ = [r["juez"] for r in resueltos]
    k_juez = cohen_kappa_score(verdad, juez_)

    etiquetas = sorted(set(verdad) | set(juez_))
    return {
        "n_total": len(filas),
        "kappa_humano_humano": round(k_humanos, 3),
        "n_con_verdad_clara": len(resueltos),
        "kappa_juez_humano": round(k_juez, 3),
        "techo": round(k_humanos, 3),
        "matriz": confusion_matrix(verdad, juez_,
                                   labels=etiquetas).tolist(),
        "etiquetas": etiquetas,
        # Los desacuerdos son la lista de trabajo, no un residuo
        "desacuerdos": [r["id"] for r in resueltos
                        if r["anotador_a"] != r["juez"]],
    }


# Para rúbricas 1-5 (escala ORDENADA), kappa ponderada:
#   cohen_kappa_score(verdad, juez_, weights="quadratic")
# Penaliza según la distancia: confundir 4 con 5 pesa mucho
# menos que confundir 5 con 1.

La última clave devuelta es la que más se usa después: desacuerdos es la lista concreta de casos que hay que leer a mano. Cada uno de ellos es o un hueco de la rúbrica o un ejemplo que hay que agregar al prompt del juez.

Cuando la kappa sale baja

Aquí está el reflejo equivocado que hay que desarmar. Kappa 0.35, y la reacción automática es “el modelo del juez es malo, probemos con uno más grande”. Casi nunca es eso.

El orden correcto de sospechas, de más a menos probable:

1. La rúbrica es ambigua. Es la causa en la gran mayoría de los casos. El síntoma que lo confirma: el acuerdo humano-humano también es bajo. Si dos expertos no se ponen de acuerdo leyendo el mismo texto, el texto es el problema. Arreglo: reescribir los niveles hasta que cada uno se distinga por una condición observable, y agregar la regla de desempate para los casos que generaron duda.

2. La rúbrica no cubre el caso. Los anotadores marcaron “no estoy seguro” en el 30% de los casos porque la rúbrica no dice nada sobre situaciones que aparecen. Arreglo: agregar el nivel o la condición faltante, con un ejemplo real de tu dataset.

3. Falta anclaje con ejemplos. El juez entiende la rúbrica pero no dónde poner la línea. Arreglo: meter en el prompt dos o tres ejemplos anotados (few-shot) tomados de la zona gris, con su nota y la razón. Es la intervención con mejor relación esfuerzo/resultado de toda la lista.

4. El criterio es multidimensional disfrazado de uno solo. “Calidad” que en realidad son corrección, tono y completitud a la vez. El juez pondera esas tres cosas distinto que el humano y el desacuerdo es inevitable. Arreglo: partirlo en tres jueces con una dimensión cada uno. Sube el costo y sube la kappa de las tres.

5. La tarea es genuinamente subjetiva. Recién aquí. Si los humanos entre ellos dan κ = 0.3, la tarea no tiene una verdad estable y ningún juez la va a tener tampoco.

6. El modelo del juez es insuficiente. Último de la lista, y sí ocurre: modelos chicos fallan en criterios que exigen razonamiento de varios pasos. Pero cámbialo solo después de descartar los cinco anteriores, porque cambiar de modelo sobre una rúbrica ambigua te da un juez caro que sigue sin coincidir con nadie.

     ÁRBOL DE DECISIÓN: KAPPA BAJA

  κ juez-humano < 0.6
        │
        ▼
  ¿κ humano-humano ≥ 0.6?
        │
   no ──┴── sí
   │        │
   ▼        ▼
 la      ¿los humanos marcaron
 rúbrica   mucha duda?
 es          │
 ambigua no ─┴─ sí
   │      │     │
   │      ▼     ▼
   │  agregar  falta un
   │  ejemplos  nivel a
   │  few-shot  la rúbrica
   │      │     │
   └──────┴──┬──┘
             ▼
     ¿sigue baja tras
     reescribir?
             │
        no ──┴── sí
        │        │
        ▼        ▼
     listo   partir en varias
             dimensiones, y
             recién ahí cambiar
             de modelo

Ojo: cambiar el modelo del juez invalida la calibración anterior. La kappa que mediste es de ese modelo con esa rúbrica; si cambias cualquiera de los dos, hay que recalibrar. Guarda las 50 anotaciones humanas en el repo justamente para eso: la anotación es el activo caro y se reutiliza; recalcular la kappa contra un juez nuevo cuesta minutos.

Cuándo un juez LLM simplemente no sirve

Cierre honesto del módulo: hay casos donde ninguna calibración va a rescatar al juez y la salida correcta es medir otra cosa.

Cuando el criterio es una verdad externa que el juez no tiene. “¿El precio que dio es el correcto?” no es un juicio, es una consulta a la base de datos. Un juez LLM opinando sobre eso es teatro. Se verifica contra la fuente, deterministamente.

Cuando el dominio exige experticia que el modelo no tiene. Corrección clínica, cumplimiento normativo específico, cálculo de impuestos de una jurisdicción. El juez produce texto seguro y equivocado. Ahí la evaluación es revisión experta sobre una muestra, y lo que se automatiza es el muestreo, no el juicio.

Cuando el juez es más débil que el sistema evaluado. Si tu agente razona en diez pasos y el juez tiene que seguir ese razonamiento para evaluarlo, un juez menos capaz va a puntuar mal las respuestas buenas y complejas. Alternativa: descomponer en verificaciones más simples que sí quepan en el juez.

Cuando lo que quieres medir es preferencia de usuario. Ningún juez sabe qué prefiere tu usuario específico. Eso se mide con usuarios: tests A/B, señales implícitas, encuestas. El juez aproxima criterios explícitos, no gustos.

Cuando el costo no se justifica. Un juez sobre 200 casos, tres pasadas cada uno, en cada PR, es una factura recurrente. Si lo que mide ya lo cubre un checker determinista con κ implícita de 1.0, el juez es un gasto sin información nueva.

Situación	Por qué el juez falla	Qué medir en su lugar
Dato factual verificable	No tiene acceso a la fuente	Comparación contra la base de datos
Corrección clínica o legal	Falta experticia real	Revisión experta sobre muestra
Razonamiento más largo que el juez	No puede seguir la cadena	Verificaciones descompuestas por paso
Preferencia del usuario	No conoce a tu usuario	A/B test, señales implícitas
Criterio ya cubierto por código	No agrega información	El checker determinista, y punto

Errores comunes

Usar el juez sin calibrarlo nunca. Es el error central del módulo. Optimizar tres meses contra un juez que coincide con los humanos en κ = 0.3 es mejorar un número que no representa a nadie.
Medir el acuerdo como porcentaje de coincidencia. Con clases desbalanceadas, un juez que siempre dice “aceptable” saca 95%. Kappa descuenta el azar y por eso es la métrica correcta.
Calibrar contra un solo anotador. Sin el acuerdo entre dos humanos no sabes si la rúbrica es clara, y no tienes techo contra el cual comparar la kappa del juez.
Anotar viendo la nota del juez. El anotador se ancla y el acuerdo sube artificialmente. La anotación es a ciegas o no sirve.
Muestrear al azar para calibrar. Casi todos los casos van a ser fáciles y la kappa sale alta por razones equivocadas. Estratifica e incluye la zona gris.
Cambiar de modelo cuando la kappa sale baja. La causa habitual es la rúbrica, no el modelo. Reescribe los niveles y agrega ejemplos anclados antes de tocar el modelo.
Kappa simple sobre una escala 1–5. Penaliza igual confundir 4 con 5 que 5 con 1. Para escalas ordenadas, kappa ponderada cuadrática.
No recalibrar tras cambiar la rúbrica o el juez. La calibración es de esa combinación específica. Cualquier cambio la invalida, y recalcular es barato si guardaste las anotaciones.
Usar un juez para lo que un SELECT responde. Si hay una fuente de verdad accesible, la verificación es determinista, más barata y perfecta.

La frase para llevarse

“Un juez LLM sin kappa contra humanos es una opinión con tres decimales. Y cuando la kappa sale baja, el problema casi nunca es el modelo del juez: es que tu definición de ‘bueno’ nunca fue lo bastante clara como para que dos personas la aplicaran igual.”

Qué viene

Módulo 5: evaluar trayectorias, y con él empieza el bloque de agentes, que es el corazón de este curso. Todo lo que llevamos — deterministas, rúbricas, jueces calibrados — evalúa una salida. Un agente no produce una salida: produce un camino. Decide, llama herramientas, lee resultados, se corrige, reintenta, a veces da vueltas en círculo y llega igual a la respuesta correcta. Dos ejecuciones con la misma respuesta final pueden ser una excelente y otra un desastre de doce llamadas innecesarias, y ninguna métrica de salida final distingue esas dos cosas.

Los tres módulos que vienen atacan eso desde sus tres ángulos: la trayectoria completa (módulo 5), el uso de herramientas — selección, argumentos, recuperación de errores — en el módulo 6, y las conversaciones multiturno, donde el estado se arrastra y el fallo aparece cinco mensajes después de la causa, en el módulo 7. Es la parte del curso donde la evaluación deja de parecerse al testing de software y se convierte en algo propio.

Evals — Módulo 4: el juez que también hay que evaluar