Juez calibrado: el checkpoint C2

6.1La pregunta que cierra el nivel

Es viernes. Has pasado el nivel entero construyendo un juez para el fallo nº1 de Aurora. Ese fallo: la respuesta que afirma algo sobre devoluciones o envíos que el chunk recuperado no respalda. El reembolso fantasma de N0·L1, vuelto métrica.

Tienes el prompt del juez. Lo validaste. Le quitaste un sesgo. Iteraste hasta que el acuerdo subió. Cada pieza, por separado, funciona.

Entonces una compañera te escribe: "Voy a correr tu juez sobre 100 respuestas nuevas de Aurora esta tarde. ¿Confío en su veredicto para decidir qué pasa a producción?".

Esa pregunta no se contesta con "sí, confía". Se contesta con un informe. Un informe que diga: aquí está la matriz de confusión sobre las etiquetas humanas, aquí el TPR y el TNR, aquí el sesgo que auditamos. Y aquí la curva de acuerdo que superó el umbral que acordamos. Si puedes entregar eso, tu juez deja de ser tu opinión automatizada y pasa a ser un instrumento.

Eso es lo que produces hoy. No un concepto nuevo: el checkpoint C2, que ensambla todo N2 en un solo artefacto defendible.

6.2Qué vas a poder hacer

Al terminar esta lección:

• Ensamblarás el flujo completo del nivel —decidir, diseñar, validar, auditar sesgos, iterar— en un único informe de validación C2.
• Aplicarás la rúbrica C2 de cinco dimensiones a tu propio juez y a uno ajeno, distinguiendo una dimensión cubierta de una a medias.
• Defenderás por qué tu juez merece confianza, con números, no con afirmaciones.

Necesitas saber antes:

• N2·L1: la decisión código-vs-juez y los 3 niveles de coste de Husain.
• N2·L2: las cuatro decisiones de diseño (modo, referencia, escala, modelo juez).
• N2·L3: TPR/TNR/precision, la matriz de confusión, κ y Landis-Koch.
• N2·L4: los sesgos (posición, verbosidad, self-preference) y swap-and-average.
• N2·L5: el bucle de alineación y la distribución de errores FP/FN.
• El dataset etiquetado del checkpoint C1 (N1), con el modo de fallo nº1.

Esta lección no enseña teoría nueva. Consolida e integra. Si una de las cinco piezas anteriores te quedó floja, esta práctica la expondrá —y eso es bueno: mejor descubrirlo aquí que en producción.

6.3Recupera

Antes de integrar, recupera de memoria. Mezclo las cinco piezas a propósito: recordar saltando entre temas fija más que repasar uno a uno. Responde mentalmente antes de seguir.

1. (L1) Tu agente devuelve a veces un order_id mal formado, como AUR-104 en vez de AUR-1043. ¿Código o juez? ¿Por qué?
2. (L2) Te pasan un prompt de juez que pide "puntúa del 1 al 10 la calidad de la respuesta". ¿Cuál de las cuatro decisiones de diseño está mal tomada?
3. (L3) Tu juez reporta 94% de accuracy, pero solo 12 de 200 casos eran fallos reales. ¿Por qué la accuracy no demuestra nada aquí?
4. (L4) Le das al juez el par (A, B) y dice "la primera"; le das (B, A) y vuelve a decir "la primera". ¿Qué mide en realidad y cómo lo neutralizas?
5. (L5) Tu juez marca "fail" casi siempre que la respuesta parafrasea la política con otras palabras. ¿El problema es el modelo o la rúbrica?

Las respuestas, en corto. (1) Código: un formato es verificable mecánicamente con re.match(r"^AUR-\d{4}$", arg), y corre gratis en cada commit (nivel de coste L1, Husain — corpus A.5). (2) La escala: binario pass/fail gana a Likert en accionabilidad y calibración (Husain 2024, Eugene Yan 2024 — corpus C.1). (3) En un dataset desbalanceado, un juez que dijera "pass" siempre acertaría 188/200 = 94% sin pensar (corpus C.3). (4) Mide el orden de presentación —sesgo de posición—; lo neutralizas con swap-and-average (corpus C.2). (5) La rúbrica: el juez ya está desbiasado, así que el error que queda es de criterio, no de capacidad (corpus C.4).

Si las cinco te salieron, tienes el material para integrar. Si alguna falló, vuelve a su lección antes de seguir.

6.4El concepto: las cinco piezas son una sola tubería

No hay concepto nuevo aquí. Hay un cambio de perspectiva: dejas de ver cinco lecciones sueltas. Empiezas a ver una tubería que convierte un modo de fallo en un instrumento de medición fiable.

El flujo end-to-end

Cada lección del nivel fue una etapa. Vistas juntas, encadenan así:

1fallo nº1 del C1
2   │
3   ▼
4[1] DECIDIR ───── ¿código o juez?  → juez (juicio semántico, no regla)         (L1)
5   │
6   ▼
7[2] DISEÑAR ───── pointwise · reference-free · binario · juez ≥ evaluado       (L2)
8   │
9   ▼
10[3] VALIDAR ───── ≥100 etiquetas → matriz de confusión → TPR/TNR → κ           (L3)
11   │
12   ▼
13[4] AUDITAR ───── ≥1 sesgo (posición/verbosidad/self-pref) → mitigar           (L4)
14   │
15   ▼
16[5] ITERAR ────── leer FP/FN → refinar rúbrica → re-ejecutar → curva de acuerdo (L5)
17   │
18   ▼
19juez calibrado  ──►  reutilizado en N3 (groundedness), N4 (CI), N5 (prod)

Lee la columna izquierda como verbos: decidir, diseñar, validar, auditar, iterar. Cada flecha pasa el artefacto a la siguiente etapa. La salida no es un número: es un juez más un informe que justifica confiar en él.

La idea que sostiene todo el nivel

Una frase, la misma de N2·L0: un juez sin validar es otra vibe. La métrica del juez no es su score, es su acuerdo con el humano cuyo criterio importa.

Por eso las etapas 3, 4 y 5 ocupan más que las dos primeras. Diseñar un prompt es la parte rápida de un juez. Lo que separa un instrumento de un adorno es demostrar que ese prompt juzga como tú. No como una moneda que cae bien por el desbalanceo del dataset.

El puente a N3

Cuidado con leer este checkpoint como un final. No lo es. El juez que cierras hoy mide una propiedad concreta: si cada afirmación de la respuesta está respaldada por el contexto recuperado. Esa propiedad tiene un nombre en la literatura RAG: groundedness (o faithfulness). Es que los claims de la respuesta se atribuyen al contexto, un vértice de la RAG triad de TruLens (corpus D.1).

En N3 no construyes ese grader de groundedness desde cero. Enchufas este. El juez calibrado deja de ser un experimento del nivel y pasa a ser infraestructura del resto del curso.

6.5Míralo funcionar: un informe de validación C2 ejemplar

Vamos a recorrer un informe C2 completo para el juez de groundedness de Aurora, sección por sección. Es denso: lleva número, código y estadística. Léelo entero una vez para ver la forma, y luego vuelve a cada bloque despacio.

Cada sección del informe corresponde a una dimensión de la rúbrica. Eso no es casualidad: el informe es la rúbrica, rellenada con evidencia.

Sección 1 — La decisión código-vs-juez

El fallo nº1 es "la respuesta afirma algo sobre la política que el chunk recuperado no respalda". No se reduce a buscar un literal: la respuesta puede mencionar la política correcta, estar bien escrita y aun así afirmar algo que el chunk no dice. Es un juicio semántico. Por eso lo medimos con un juez, no con un regex (corpus A.5: "mide barato y determinista primero"; el juez se reserva para fallos de generalización). Es un grader nivel L2 de coste: corre por lotes, no en cada commit.

Sección 2 — El diseño del juez

Cuatro decisiones, justificadas: pointwise (juzgamos una respuesta contra su contexto, no comparamos dos), reference-free (no tenemos respuesta gold por caso, pero usamos el chunk recuperado como ancla de verdad), binario pass/fail (accionable y más fácil de alinear que Likert), y juez ≥ capacidad del evaluado (corpus A.5).

Este es el juez binario, con la API de structured outputs del SDK de Anthropic. Pedimos la razón junto al veredicto: el modelo razona antes de decidir, lo que mejora la calidad del juicio.

1import json
2import anthropic
3
4client = anthropic.Anthropic()
5
6PROMPT_JUEZ = """Eres un evaluador del agente de soporte de Aurora.
7
8Decide si la RESPUESTA está fundamentada en el CONTEXTO recuperado.
9"Fundamentada" = cada afirmación sobre la política (devoluciones, envíos,
10reembolsos) está respaldada por el contexto. Si la respuesta afirma algo que
11el contexto no dice, es "fail" aunque suene correcto.
12
13CONTEXTO recuperado:
14{contexto}
15
16RESPUESTA del agente:
17{respuesta}
18
19Devuelve un JSON con 'verdict' ("pass" o "fail") y 'reason' (1 frase)."""
20
21def juez_groundedness(respuesta: str, contexto: str) -> dict:
22    response = client.messages.create(
23        model="claude-sonnet-4-6",   # juez >= capacidad del evaluado; ajusta a tu cuenta
24        max_tokens=256,
25        messages=[{
26            "role": "user",
27            "content": PROMPT_JUEZ.format(contexto=contexto, respuesta=respuesta),
28        }],
29        output_config={
30            "format": {
31                "type": "json_schema",
32                "schema": {
33                    "type": "object",
34                    "properties": {
35                        "verdict": {"type": "string", "enum": ["pass", "fail"]},
36                        "reason": {"type": "string"},
37                    },
38                    "required": ["verdict", "reason"],
39                    "additionalProperties": False,
40                },
41            }
42        },
43    )
44    return json.loads(response.content[0].text)

El enum: ["pass", "fail"] y el schema cierran la salida a binario estructurado. No hay "7 sobre 10" posible: el diseño hace imposible la escala Likert que el hook de N2·L2 advertía.

Sección 3 — La validación sobre 120 etiquetas humanas

Pasamos el juez sobre 120 respuestas etiquetadas a mano. Clase positiva = "fail" (no fundamentada), porque ese es el fallo que queremos cazar.

Las tasas, calculadas a mano (corpus C.3: TPR/TNR, no accuracy cruda):

1TPR (recall)  = TP / (TP + FN) = 14 / 18 = 0.78   # de los fallos reales, cazó el 78%
2TNR           = TN / (TN + FP) = 96 / 102 = 0.94   # de las buenas, dejó pasar bien el 94%
3Precision     = TP / (TP + FP) = 14 / 20 = 0.70   # de lo que marcó fail, el 70% lo era
4accuracy      = (14 + 96) / 120 = 0.917            # 91.7% — pero engaña

Lectura: la accuracy de 91.7% suena a aprobado, pero un juez que dijera "pass" siempre acertaría 102/120 = 85% sin pensar. El TPR de 0.78 dice la verdad útil: 4 fallos reales se escapan a producción (los FN). En soporte, un FN —el cliente recibe información falsa— suele doler más que un FP. Reportamos κ para corregir el acuerdo por azar: κ = 0.62, substantial en Landis-Koch, justo sobre el 0.61 que fijamos como mínimo.

Sección 4 — La auditoría de un sesgo

El juez de producción es pointwise, así que el sesgo de posición no aplica directamente. Pero al iterar comparamos versiones del prompt en modo pairwise, y ahí auditamos posición con swap-and-average (corpus C.2): corrimos 40 pares en orden (A,B) y en orden (B,A).

1def auditar_posicion(pares, juez_pairwise):
2    """Mide la consistencia del veredicto al invertir el orden."""
3    consistentes = 0
4    for a, b in pares:
5        v_ab = juez_pairwise(a, b)   # veredicto con A primero
6        v_ba = juez_pairwise(b, a)   # veredicto con B primero
7        # consistente = el ganador es el mismo respuesta, no la misma posición
8        if v_ab == v_ba:
9            consistentes += 1
10    return consistentes / len(pares)
11
12tasa = auditar_posicion(pares_validacion, juez_pairwise)
13# antes de mitigar: 0.65  -> el 35% de los veredictos cambian al invertir = sesgo
14# mitigación: contar solo los veredictos consistentes / promediar ambos órdenes

Consistencia inicial 0.65: un tercio de los veredictos cambiaba al invertir el orden. Swap-and-average no elimina el sesgo, pero neutraliza su efecto en el agregado: nos quedamos con los veredictos consistentes y promediamos el resto.

Sección 5 — La curva de iteración

Baseline κ = 0.52 (moderate), por debajo del 0.61 mínimo. Abrimos 10 FP y leímos un patrón: el juez marcaba "fail" las paráfrasis correctas de la política (las daba por no fundamentadas porque no copiaban el texto literal). No era un juez roto: era una rúbrica que no definía "fundamentado" como nosotros. Refinamos la rúbrica —"respaldada en sentido, aunque no use las mismas palabras", con un ejemplo— y re-ejecutamos.

1iteración   acuerdo (κ)   nota
2   v1          0.52        baseline, rúbrica mínima
3   v2          0.62        + definición de "fundamentado en sentido" y un ejemplo

La mejora de v1 a v2 es la misma forma que el caso Ragas documenta: baseline 75.6% (121/160, con 39 FP y 0 FN) → 86.9% (139/160) tras añadir una rúbrica de dominio, +11.3 puntos (corpus C.4). Los muchos FP / cero FN de Ragas dicen "juez demasiado estricto" —exactamente nuestro patrón—. El análisis de la distribución de errores nos dijo qué arreglar.

Auto-explicación. Antes de seguir, responde: ¿por qué leer los 10 FP fue más útil que cambiar el modelo juez por uno mayor?

Porque el problema era de criterio, no de capacidad. El juez entendía perfectamente; lo que no tenía era una definición de "fundamentado" alineada con la nuestra. Un modelo mayor habría sido igual de estricto con las paráfrasis. El corpus lo respalda: los criterios son el factor más crítico al alinear, por encima de trucos de prompting (corpus C.4, Yamauchi et al. 2025, confianza media).

6.6Hazlo tú: el checkpoint C2

Aquí la práctica es el checkpoint. No hay ejercicio de calentamiento: integras todo el nivel sobre tu propio caso.

El enunciado del checkpoint C2

Para el modo de fallo nº1 del C1, decide medirlo con código o juez. Si es juez: constrúyelo (rúbrica binaria), valídalo contra ≥100 etiquetas humanas reportando TPR/TNR (no accuracy cruda), audita position/verbosity/self-preference bias, e itera el prompt hasta ≥ umbral de acuerdo. Entregable: el juez + informe de validación (matriz de confusión, TPR/TNR, sesgos auditados, curva de iteración).

(Reproducido de la arquitectura del curso, 03-arquitectura.md.)

Andamiaje: primero el código, luego el juez

La rúbrica recompensa decidir bien código-vs-juez. Empieza demostrando que sabes cuándo no hace falta juez. Toma un fallo mecánico de tu taxonomía (un formato de ID, un idioma incorrecto) y escribe la assertion code-based que lo caza. Una línea. Esa línea es la prueba de que no saltaste al juez por defecto.

Después, construye el juez para el fallo nº1 —el semántico— siguiendo las cinco secciones del informe del §6.5. Reutiliza el dataset etiquetado del C1 como ground truth: las etiquetas humanas son la verdad contra la que mides al juez.

El bucle de iteración con Ragas (opcional, si usas el framework)

Si prefieres orquestar el bucle de alineación con Ragas en vez del SDK directo, este es el patrón del flujo align-llm-as-judge. El dataset trae una columna target con la etiqueta humana; medimos qué fracción de veredictos del juez coincide con ella.

1import os
2import pandas as pd
3from anthropic import Anthropic
4from ragas import experiment, Dataset
5from ragas.llms import llm_factory
6from ragas.metrics import DiscreteMetric
7from ragas.metrics.discrete import discrete_metric
8from ragas.metrics.result import MetricResult
9
10# 1. Dataset con etiquetas humanas (resultado del C1)
11df = pd.read_csv("datasets/aurora_etiquetado.csv")
12# columnas: response, grading_notes, target ("pass" | "fail")
13
14# 2. LLM juez (Anthropic; provider="anthropic" es REQUERIDO)
15client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
16llm = llm_factory("claude-sonnet-4-6", provider="anthropic", client=client)
17
18# 3. Juez binario baseline
19juez_v1 = DiscreteMetric(
20    name="groundedness",
21    prompt=("Decide si la respuesta está fundamentada en las notas.\n"
22            "Respuesta: {response}\nNotas: {grading_notes}\n"
23            "Responde solo 'pass' o 'fail'."),
24    allowed_values=["pass", "fail"],
25)
26
27# 4. Métrica de alineación: ¿coincide el juez con el humano?
28@discrete_metric(name="alineacion", allowed_values=["pass", "fail"])
29def alineacion(judge_label: str, human_label: str) -> MetricResult:
30    ok = judge_label.strip().lower() == human_label.strip().lower()
31    return MetricResult(value="pass" if ok else "fail",
32                        reason=f"judge={judge_label}, human={human_label}")
33
34# 5. Experimento
35@experiment()
36async def experimento_juez(row, juez, llm):
37    jr = await juez.ascore(response=row["response"],
38                           grading_notes=row["grading_notes"], llm=llm)
39    al = alineacion.score(judge_label=jr.value, human_label=row["target"])
40    return {**row, "judge_label": jr.value, "alineacion": al.value}
41
42# 6. Ejecutar y medir acuerdo baseline
43dataset = Dataset.from_pandas(df)
44results = await experimento_juez.arun(dataset, name="juez_aurora_v1",
45                                      juez=juez_v1, llm=llm)
46passed = sum(1 for r in results if r["alineacion"] == "pass")
47print(f"Alineación baseline: {passed}/{len(results)} ({passed/len(results):.1%})")
48
49# 7. Iterar: define juez_v2 con la rúbrica refinada, re-ejecuta, compara la curva

El evaluate() clásico de Ragas sigue funcionando en la 0.4.x, pero está marcado como deprecado en favor del decorador @experiment. Usamos @experiment por eso.

Una pregunta antes de cerrar el informe

Responde tú primero, antes de leer la respuesta: ¿por qué el umbral de acuerdo lo fijas tú y no lo dicta Landis-Koch?

Porque Landis-Koch (corpus C.3) da una referencia —0.61 como mínimo habitual en NLP—, no una regla universal. El umbral depende del coste del error en tu dominio. Si un FN manda información falsa a un cliente de Aurora, exiges un TPR alto y un κ más estricto. Si el coste de un fallo es bajo, toleras menos acuerdo. La escala te orienta; el coste decide.

6.7Comprueba: la rúbrica C2 con feedback por dimensión

Tu juez aprueba el checkpoint C2 cuando cubre las cinco dimensiones, con el acuerdo ≥ el umbral que tú acordaste. El umbral lo fijas según el coste del error en tu dominio; Landis-Koch da la referencia, no la regla.

Esta es la rúbrica, reproducida fiel de 03-arquitectura.md. Cada dimensión lleva feedback formativo: qué demuestra que la cubriste, qué la deja a medias y el siguiente paso.

Dimensión 1 — Elección código-vs-juez (justificada: mide barato y determinista primero).

• Cubierta: justificas por qué el fallo nº1 necesita un juez (juicio semántico irreducible a regla) y muestras al menos un fallo trivial resuelto con una assertion. Demuestras criterio, no automatismo. Importa porque montar un juez caro para algo que un if caza es desperdicio, y forzar regex sobre lo semántico es frágil.
• A medias: dices "uso un juez" sin justificar por qué un regex no basta. Siguiente paso: escribe la frase que explica por qué la respuesta puede estar bien formada y aun así no fundamentada (N2·L1).

Dimensión 2 — Diseño (binario, rúbrica clara; juez ≥ capacidad del evaluado).

• Cubierta: tu juez emite pass/fail con una rúbrica que define el criterio en términos operativos, y el modelo juez no es más débil que el evaluado. La salida es accionable: nombra la afirmación concreta que falla.
• A medias: la rúbrica usa una escala numérica, o "fundamentado" queda sin definir. Siguiente paso: reescribe la escala a binario y añade la definición operativa de tu criterio con un ejemplo (N2·L2).

Dimensión 3 — Validación (TPR/TNR, no accuracy, sobre el dataset; matriz de confusión interpretada).

• Cubierta: reportas la matriz 2×2 sobre ≥100 etiquetas, calculas TPR y TNR, y lees qué dice cada tasa para Aurora (qué fallos se escapan, qué buenas se marcan mal). Importa porque en un dataset desbalanceado la accuracy premia al juez perezoso.
• A medias: declaras victoria con la accuracy alta sin mirar TPR. Es el error más común aquí. Siguiente paso: calcula qué acertaría un juez que dijera "pass" siempre, y compáralo con tu accuracy (N2·L3).

Dimensión 4 — Sesgos (≥1 auditado y mitigado: posición con swap-and-average / verbosidad / self-preference).

• Cubierta: auditas al menos un sesgo con un mini-experimento (consistencia al invertir el orden, correlación con la longitud, o familia del modelo) y aplicas la mitigación. Si tocas self-preference, recuerdas el caveat: los autores no concluyen causalidad (corpus C.2).
• A medias: nombras los sesgos pero no mides ninguno. Siguiente paso: corre swap-and-average sobre 20-40 pares y reporta la tasa de consistencia antes y después (N2·L4).

Dimensión 5 — Iteración (curva de mejora documentada; acuerdo ≥ umbral acordado).

• Cubierta: documentas el acuerdo por iteración (al menos baseline → v2), explicas qué leíste en los FP/FN para refinar la rúbrica, y superas tu umbral. La curva es la evidencia de que el juez convergió, no de que tuviste suerte.
• A medias: cambiaste el prompt "a ojo" sin medir antes y después. Siguiente paso: registra el κ (o el % de acuerdo) de cada versión y nombra el patrón de error que motivó cada cambio (N2·L5).

Si una dimensión te quedó a medias, no es un suspenso: es un diagnóstico. El feedback te dice exactamente a qué lección volver.

6.8Conecta

Vuelve al reembolso fantasma del martes a las 9:14, el que abrió el curso en N0·L1.

Mira el arco completo. En N0 no podías ni ver ese fallo: el agente devolvía texto fluido y falso, sin excepción que atrapar. En N1 le pusiste nombre —respuesta no fundamentada— y lo contaste: era el modo de fallo nº1. Hoy, en N2, tienes un juez que lo mide a escala. Y confías en su veredicto, porque está validado contra tu criterio con números que cualquiera puede auditar.

Ese es el viaje de vibes a datos, hecho instrumento.

Y no termina aquí. El juez calibrado es la primera pieza de infraestructura del curso:

• En N3 lo enchufas como el grader de groundedness de la RAG triad, para localizar si el fallo viene del retrieval o de la generación. No lo reconstruyes: lo reutilizas.
• En N4 lo corres en el gate de CI, donde un veredicto "fail" puede bloquear un merge.
• En N5 lo pones a vigilar producción sobre tráfico real.

Calíbralo bien una vez y trabaja para ti el resto del curso. Esa es la recompensa de hacer el checkpoint C2 con rigor en vez de a ojo.

¿Dónde lo aplicarías mañana? Piensa en cualquier sistema LLM que tengas. ¿Hay una propiedad subjetiva que hoy "vigilas a ojo" —tono, fundamentación, seguridad—? Esa es tu candidata a primer juez calibrado. El método que acabas de ejecutar es transferible tal cual.

6.9Reflexiona

Tómate tres minutos. Estas preguntas consolidan más que releer el nivel.

• En una frase: ¿qué hace a un juez "calibrado" frente a uno improvisado? (Pista: no es el prompt.)
• De las cinco dimensiones, ¿cuál te costó más cubrir? Si fue la 3 (validación) o la 5 (iteración), es lo esperable: son donde el juez deja de ser una opinión y empieza a ser medible.
• ¿Qué sigue sin estar claro? Anótalo. Si es "cómo elegir el umbral", recuerda: lo fija el coste del error en tu dominio, no la tabla de Landis-Koch.
• Si construyeras un juez desde cero mañana, ¿qué harías distinto en el orden de las cinco etapas?

Referencia rápida

• Enunciado C2: decide código-vs-juez para el fallo nº1; si es juez, constrúyelo binario, valídalo contra ≥100 etiquetas humanas (TPR/TNR, no accuracy), audita ≥1 sesgo, itera hasta el umbral. Entregable: juez + informe de validación (03-arquitectura.md).
• Las cinco dimensiones: (1) elección código-vs-juez justificada; (2) diseño binario, juez ≥ evaluado; (3) validación TPR/TNR + matriz interpretada; (4) ≥1 sesgo auditado y mitigado; (5) curva de mejora hasta el umbral acordado.
• La tubería: decidir (L1) → diseñar (L2) → validar (L3) → auditar sesgos (L4) → iterar (L5) → juez calibrado.
• La idea que sostiene el nivel: un juez sin validar es otra vibe; la métrica del juez es su acuerdo con el humano cuyo criterio importa.
• Datos del corpus usados: "mide barato primero" + niveles L1/L2 de coste (A.5); binario>Likert (C.1); TPR/TNR no accuracy + κ/Landis-Koch 0.61 (C.3); swap-and-average + self-preference con caveat (C.2); bucle de alineación + Ragas 75.6→86.9% +11.3pp con 39 FP/0 FN + criterios como factor crítico (C.4); groundedness de la RAG triad (D.1).
• El umbral lo fijas tú: según el coste del error; Landis-Koch da la referencia (0.61 mínimo habitual en NLP), no la regla.
• Reutilización: este juez es el grader de groundedness de N3, el gate de N4 y el monitor de N5. Calíbralo una vez.