LLM-as-judge: el corrector de oposiciones que evalúa a otros modelos sin convertirse en oráculo

Wed, 27 May 2026 08:30:00 +0200

Este post profundiza la sección de Evals para LLMs sobre judges. Allí estaba como una pieza del tribunal mixto; aquí entramos a por qué funciona, dónde se rompe y cómo se mide su calibración antes de aceptarlo en CI.

TL;DR

Un judge LLM no es “un GPT-4 al que le preguntas si la respuesta es buena”. Es un corrector formado: tiene una rúbrica escrita por adelantado, se le pide razonamiento explícito antes del veredicto, su score se calcula como expectativa ponderada por las probabilidades de los tokens (no como el primer token que escupe), y antes de aceptarlo en producción se calibra contra una muestra de ~50 ejemplos anotados por humanos hasta lograr κ ≥ 0.5 (Cohen’s kappa). El estado del arte en mayo de 2026 son tres patrones —G-Eval, Prometheus 2 y panel of judges—, cada uno respondiendo a un trade-off distinto entre coste, calidad y reproducibilidad. Todos comparten cuatro sesgos documentados: position, verbosity, self-preference y narcissism. Este post explica cómo se construye un judge real, cómo se mide si miente, y cuándo conviene cada patrón.

Estás aquí: EVAL

La analogía: el corrector de oposiciones

Una oposición pública tiene miles de exámenes. Imposible que el tribunal senior los corrija todos. La solución del sistema español lleva décadas siendo la misma: correctores formados. Personas que no son catedráticos, pero que reciben:

Una plantilla de corrección escrita por adelantado: qué se valora, cuántos puntos vale cada apartado, qué descuenta.
Un entrenamiento previo con una muestra de exámenes ya corregidos por el tribunal senior, hasta que sus correcciones coinciden razonablemente.
Una auditoría continua: una fracción de sus correcciones se re-corrige por el tribunal senior para verificar que el corrector no se desvía.

Un judge LLM bien construido es exactamente eso. No es un oráculo, es un corrector formado:

La rúbrica son las criterios explícitos en el prompt (qué es faithfulness, qué es relevancy, etc.).
El entrenamiento es la calibración contra ~50 ejemplos anotados por humanos.
La auditoría continua es el muestreo semanal donde un humano re-evalúa una fracción del tráfico que el judge ha juzgado.

Y, como con el corrector humano, el judge tiene sesgos sistemáticos que la oposición pública ha aprendido a vigilar: prefieren ciertos formatos de letra, ciertas longitudes, ciertas estructuras. Lo mismo le pasa al judge. El resto del post desmonta exactamente cuáles y cómo se miden.

Por qué existe LLM-as-judge

La razón directa: dinero y tiempo. Una anotación humana profesional cuesta del orden de 0.50 € a 5 € por ejemplo (según complejidad y dominio), y tarda 30 segundos a varios minutos. Un juicio de GPT-4 cuesta ~0.01-0.05 € y tarda ~2 segundos. Para un golden dataset de 500 ejemplos evaluados continuamente sobre 10 candidatos al día, la diferencia es entre 2 500 € al día y 50 € al día. Y la diferencia de wall-clock es entre días y minutos.

La razón menos directa pero más relevante: escalabilidad metodológica. Un golden dataset de 500 ejemplos es relativamente fácil de anotar una vez. Lo que pasa después es lo difícil:

Cada vez que sale un adapter candidato hay que re-evaluar los 500.
Cada vez que se actualiza el dataset (porque entró un incidente nuevo) hay que re-evaluar.
Cada vez que cambia el system prompt hay que re-evaluar.

Sin un judge automatizable y barato, la batería de eval deja de correr y el sistema se vuelve ciego entre release y release. Eso es lo que de verdad justifica el patrón.

Los tres patrones canónicos en 2026

1 · G-Eval

Publicado por Liu et al. (2023). La idea base es tan simple que se entiende en una frase: dale al judge una rúbrica detallada, pídele que razone antes de puntuar, y léelo como expectativa ponderada en vez de como primer token. Las tres palancas:

Rúbrica: prompt con criterio explícito (ej. “Faithfulness: el grado en que la respuesta se apoya únicamente en el contexto, sin inventar datos. Score 1 = inventa todo, 5 = todo apoyado en el contexto”), idealmente con uno o dos ejemplos por valor del extremo.

Chain-of-thought + form-filling: se le pide primero “razona brevemente sobre cada criterio” y luego “rellena este formulario JSON”. Eso fuerza al modelo a no escupir un número arbitrario.

Probability-weighted scoring: en lugar de leer el primer token después del campo score:, se mira la distribución de probabilidades del modelo sobre los tokens 1, 2, 3, 4, 5 y se calcula:

$$\hat{s} = \sum_{i=1}^{5} i \cdot \frac{p(\text{token}=i)}{\sum_{j=1}^{5} p(\text{token}=j)}$$

Esto convierte un score discreto en uno continuo. La justificación: si el judge “dudaba” entre 4 y 5 (probabilidades 0.4 y 0.5 sobre 4 y 5), el score real es 4.55, no 5. Esto reduce drásticamente la varianza entre runs del mismo prompt, y captura información que la decodificación greedy descarta.

Limitaciones de G-Eval: necesita acceso a logprobs del modelo. Los modelos closed-source han ido limitando este acceso (Claude no lo expone, GPT-4 lo expone pero sólo top-5). En 2026 G-Eval con probability weighting estricto sólo es práctico contra modelos open source que sirvas tú mismo (vLLM lo expone) o contra GPT-4 con logprobs=true.

2 · Prometheus 2

Publicado por Kim et al. (KAIST, 2024). El insight es complementario a G-Eval: ¿y si en vez de pedirle a un judge generalista que evalúe, fine-tuneamos un judge específico?

Prometheus 2 es un Mistral 8×7B (MoE, ~47 GB en BF16, ~24 GB en INT4) fine-tuneado sobre 100k+ ejemplos de evaluación con rúbricas variadas. La métrica que se publicó en el paper: 0.897 de correlación Pearson con GPT-4-as-judge sobre el Vicuna Bench y similares. Eso es relevante porque significa que se puede sustituir a GPT-4 como judge a un coste de inferencia local sin perder casi nada de calidad.

Por qué importa en producción on-premise:

No salen datos del perímetro. Para clientes ENS/NIS2 estrictos esto no es preferencia, es requisito. Un judge que viaja por API externa no es opcional ahí.
Coste marginal cero. Cuando el judge corre on-prem, evaluar 50 000 casos al día no añade factura externa.
Latencia controlada. La eval continua sobre tráfico real puede correr en paralelo sin saturar rate limits de un proveedor externo.

El precio: hay que mantener un servicio de inferencia más (Prometheus 2 corriendo en su propio vLLM), y el judge no se “actualiza” salvo que se re-fine-tunee.

3 · Panel of Judges

Verga et al. (Cohere, 2024) lo formalizaron: en vez de un único judge, usar 3-5 jueces heterogéneos —diferentes modelos, diferentes prompts, diferentes temperaturas— y agregar sus juicios.

Mecanismos de agregación habituales:

Mediana para scores continuos. Robusta a outliers.
Voto mayoritario para juicios pairwise (chosen vs rejected). Si 3 de 5 prefieren A, el ganador es A.
Media ponderada por calibración: pesar cada judge según su κ contra humanos en la calibración. Los judges más fiables votan más.

Lo que el panel da y un single judge no:

Reducción del self-preference (sesgo de un judge a preferir outputs estilísticamente similares a los suyos): si los jueces son de proveedores distintos, la suma se cancela.
Medida de la dificultad del caso: si los 5 jueces coinciden, el caso es fácil; si están repartidos, el caso es ambiguo y conviene escalarlo a humano. Esto convierte al panel en un sistema de triaging automático para anotación humana.
Varianza menor: el ruido de cada judge se promedia.

El coste: 3-5× la factura de un single judge. Por eso el panel se reserva habitualmente para eval gates críticos (¿este adapter se promociona o no?), no para eval continuo sobre tráfico.

Cómo se mide si el judge miente: Cohen’s kappa

Aceptar al judge en producción sin medir su acuerdo con humanos es lo mismo que aceptar un termómetro sin calibrar. La métrica estándar para inter-rater agreement con escalas discretas u ordinales es Cohen’s kappa:

$$\kappa = \frac{p_o - p_e}{1 - p_e}$$

Donde p_o es la proporción de acuerdo observado (qué porcentaje de los ejemplos coincide judge-humano) y p_e es la proporción de acuerdo esperado por azar (lo que esperarías si ambos puntuaran al azar respetando las marginales de cada uno).

La intuición: si p_o = 0.9 pero p_e = 0.85 (porque los dos puntúan casi siempre “4 ó 5”), el acuerdo es 90 % bruto pero κ = 0.33: la mayor parte del acuerdo viene de que ambos puntúan alto, no de que se entiendan. κ corrige por ese baseline.

Escala interpretativa habitual (Landis y Koch 1977, todavía referencia):

κ	Interpretación	Threshold productivo
< 0.20	Pobre	Inservible
0.21–0.40	Justo	Sólo señal débil
0.41–0.60	Moderado	Mínimo aceptable en 2026
0.61–0.80	Sustancial	Estado del arte para judges open source
0.81–1.00	Casi perfecto	Judges humanos entre sí raramente llegan

Punto importante que el campo aprendió por las malas: los humanos entre sí rara vez superan κ = 0.70 en tareas LLM (faithfulness, relevancy). Eso es el techo realista del judge LLM. Buscar κ = 0.9 contra humanos es perseguir un fantasma: ni siquiera dos anotadores humanos llegan ahí.

Kappa ponderada para escalas ordinales

Para scores 1-5, el desacuerdo “judge dice 4, humano dice 5” no es lo mismo que “judge dice 1, humano dice 5”. La kappa estándar trata ambos como un fallo idéntico. La kappa ponderada lineal o cuadrática asigna peso a la magnitud del desacuerdo:

$$\kappa_w = 1 - \frac{\sum_{i,j} w_{ij} , o_{ij}}{\sum_{i,j} w_{ij} , e_{ij}}, \quad w_{ij}^{(\text{lin})} = \frac{|i-j|}{k-1}, \quad w_{ij}^{(\text{quad})} = \frac{(i-j)^2}{(k-1)^2}.$$

En G-Eval con scores 1-5, lo habitual es publicar κ_quad porque penaliza más los desacuerdos grandes y se acerca mejor a la intuición humana.

Ejemplo numérico de calibración

Imagina un golden set de 50 ejemplos puntuados por humano y por el judge, ambos en escala 1-5. La matriz de confusión:

	Hum 1	Hum 2	Hum 3	Hum 4	Hum 5	Total judge
Judge 1	3	1	0	0	0	4
Judge 2	1	4	2	0	0	7
Judge 3	0	1	6	2	0	9
Judge 4	0	0	1	12	3	16
Judge 5	0	0	0	2	12	14
Total humano	4	6	9	16	15	50

Diagonal (acuerdos exactos): 3+4+6+12+12 = 37 → p_o = 0.74.

p_e se calcula como Σ_i (n_judge_i · n_hum_i) / n² = (4·4 + 7·6 + 9·9 + 16·16 + 14·15) / 50² = (16+42+81+256+210) / 2500 = 605/2500 ≈ 0.242.

$$\kappa = \frac{0.74 - 0.242}{1 - 0.242} = \frac{0.498}{0.758} \approx 0.66$$

Sustancial. Aceptable. Si quisiéramos κ ponderada cuadrática, los desacuerdos próximos (Judge 4 vs Hum 5) pesan menos que los lejanos (Judge 2 vs Hum 4), y el κ_quad típicamente sale 0.05-0.10 por encima del lineal.

Los cuatro sesgos del judge

Position bias

Documentado primero por Wang et al. (2023). Si presentas dos respuestas A y B al judge en pairwise, prefiere A más a menudo que B —del orden de 55-65 % cuando A y B son objetivamente equivalentes, con jueces típicos 2023-2024—. En 2026 los jueces frontier (GPT-5, Claude 4.5, Llama 4 Judge) lo tienen bastante mitigado, pero sigue siendo medible.

Cómo medirlo formalmente: correr el dataset dos veces, una con (A, B) y otra con (B, A). Si el judge es consistente, debe haber acuerdo entre pasadas. La fracción de casos donde el veredicto cambia es la position-bias rate. Threshold aceptado en 2026: < 10 %.

Mitigación canónica: ejecutar siempre dos pasadas con el orden invertido y promediar. Frameworks como Promptfoo e Inspect AI lo hacen por defecto.

Verbosity bias

Documentado por Saito et al. y Dubois et al. en 2024. Para tareas abiertas (faithfulness, helpfulness), el judge tiende a dar mayor score a respuestas más largas. La correlación Pearson típica entre score y longitud en respuestas con calidad humana equivalente puede subir hasta 0.4-0.5 sin mitigación.

Cómo medirlo: correlación Pearson entre el score del judge y la longitud de la respuesta, calculada sobre un subset donde los humanos han confirmado calidad equivalente. Si la correlación es > 0.3 en ese subset controlado, hay verbosity bias significativo.

Mitigación: rúbrica explícitamente neutral en longitud (“la respuesta debe ser apropiadamente concisa para la pregunta; longitud no es un criterio”) y few-shot con ejemplos donde una respuesta corta supera a una larga. AlpacaEval 2.0 incorpora una corrección por longitud directamente en la métrica.

Self-preference bias

Documentado por Panickssery et al. (Anthropic, 2024). Un judge GPT-4 prefiere outputs de GPT-4. Un judge Claude prefiere outputs de Claude. No por una conspiración, sino porque los modelos comparten patrones estilísticos con sus parientes cercanos (estructura de párrafos, uso de bullet points, tono).

Cómo medirlo: sobre un golden set, comparar los scores de 3 judges distintos (ej. GPT-4, Claude, Llama 4 Judge). Si para un mismo candidato hay > 15 % de divergencia sistemática vinculable a la identidad del candidato, hay self-preference.

Mitigación: panel of judges con proveedores heterogéneos. Si se va a usar un único judge, no debe ser del mismo proveedor que el modelo evaluado.

Narcissism

Caso extremo del self-preference: el judge es exactamente el mismo modelo que el candidato. Esto pasa más de lo que parece: un equipo entrena un Llama 3 8B con LoRA y lo evalúa con Llama 3 8B como judge porque “es lo que tienen on-prem”. Es metodológicamente inválido. El delta entre score humano y score judge crece de forma medible.

Mitigación: judge de arquitectura distinta al candidato. Si tu candidato es Llama 3, tu judge debería ser Mistral, Qwen o un Prometheus 2 (que aunque está basado en Mistral, fue fine-tuneado específicamente para evaluación).

El judge como bisagra del pipeline

El judge no es sólo “la pieza de eval”. Es la bisagra que conecta tres etapas del pipeline:

Hacia TUNE: el judge genera los pares (chosen, rejected) para DPO sin necesidad de etiquetadores humanos. Esa cadena es lo que hace que el fine-tuning continuo funcione sin un equipo de anotación dedicado.

Hacia EVAL gate: el judge da el score que se compara contra el threshold del CI. Si el adapter no supera 0.85 en faithfulness, no merge.

Hacia EVAL continuo: sobre una muestra del tráfico real (1-5 %), el judge calcula scores y los persiste. Eso permite detectar regresiones que aparecen días después del deploy y que el CI no veía porque su golden set no las cubría.

Hacia RETRAIN: los casos donde el judge da score bajo son candidatos automáticos para el siguiente dataset de retraining. El judge actúa como triage del flujo de incidentes.

Implicaciones en hardware on-premise

Los números siguientes son indicativos para escenarios típicos en mayo de 2026.

En una RTX 4090 (24 GB)

Judge	¿Cabe?	Throughput aproximado	Notas
GPT-4o (API)	n/a	~50-100 juicios/min	Coste externo, no es local
Prometheus 2 (8×7B INT4)	Sí, justo	~40-80 juicios/min	Q4_K_M GGUF, llama.cpp
Llama 3.1 8B fine-tuned judge	Sí, holgado	~150-250 juicios/min	Default razonable on-prem
Mistral Small Judge 22B	No directo, requiere offload	~10-20 juicios/min	Demasiado para 24 GB en BF16

Conclusión: en una sola 4090, un judge open source 8B fine-tuneado para evaluación (o Prometheus 2 cuantizado) es el sweet spot.

En un cluster genérico 4×H100 SXM (320 GB, NVLink)

Judge	Configuración	Throughput aproximado	Notas
Prometheus 2 BF16	TP=2	~400-700 juicios/min	Cabe holgadamente, latencia baja
Llama 3.3 70B Instruct	TP=4	~150-300 juicios/min	Si se usa como judge generalista
Panel of 3 judges en paralelo	TP=1-2 cada uno	~600-1200 juicios/min combinado	Patrón natural en cluster

En cluster NVLink lo natural es correr un panel of judges en paralelo (cada judge ocupa 1-2 GPUs) con un router LiteLLM por delante. Eso quita el coste cognitivo de “qué judge usamos” porque se usan los tres y se agrega el resultado.

Lo que no hemos cubierto (próximos artículos)

Red teaming y safety eval: cómo se evalúa robustez ante adversarial prompts. Es un patrón distinto al judge ordinal.
Eval de agentes multistep: AgentBench, TauBench, evaluación de trayectorias en lugar de outputs individuales.
Benchmark contamination: cómo detectar si el modelo evaluado vio el golden set durante pre-training, y por qué los benchmarks públicos están medio rotos.
Cost-aware judging: cuándo conviene un judge barato (Llama 8B) sobre uno caro (GPT-4o), y cómo cuantificar el trade-off calidad/coste con curvas de Pareto.

Ver también

Evals para LLMs: la capa después del tracing — el contexto completo de la etapa Eval; este post profundiza la pieza judge dentro del tribunal mixto que allí se describe.
Alignment moderno: DPO, KTO, ORPO y SimPO — los métodos de preference optimization que consumen los pares que produce el judge.
Fine-tuning continuo en producción — el ciclo Postgres + queries + hot-swap que necesita al judge como bisagra.
Prompt versioning con Langfuse y MLflow — el prompt del judge también se versiona; un cambio “menor” en la rúbrica puede invalidar la calibración.

Referencias

Liu, Y., Iter, D., Xu, Y., Wang, S., Xu, R., Zhu, C. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment (EMNLP 2023).
Kim, S., Suk, J., Longpre, S., Lin, B. Y., Shin, J., Welleck, S., Neubig, G., Lee, M., Lee, K., Seo, M. Prometheus 2: An Open Source Language Model Specialized in Evaluating Other Language Models (EMNLP 2024).
Verga, P., Hofstatter, S., Althammer, S., Su, Y., Piktus, A., Arkhangorodsky, A., Xu, M., White, N., Lewis, P. Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models (Cohere, 2024).
Panickssery, A., Bowman, S., Feng, S. LLM Evaluators Recognize and Favor Their Own Generations (Anthropic, NeurIPS 2024).
Wang, P., Li, L., Chen, L., Cai, Z., Zhu, D., Lin, B., Cao, Y., Liu, Q., Liu, T., Sui, Z. Large Language Models are Not Fair Evaluators (ACL 2024).
Dubois, Y., Galambosi, B., Liang, P., Hashimoto, T. Length-Controlled AlpacaEval: A Simple Way to Debias Automatic Evaluators (Stanford, 2024).
Cohen, J. A Coefficient of Agreement for Nominal Scales (Educational and Psychological Measurement, 1960).
Landis, J. R., Koch, G. G. The Measurement of Observer Agreement for Categorical Data (Biometrics, 1977).

G-Eval on lo0 — Blog Técnico