LLM as judge - rúbrica automatizada
LLM as judge automatiza la calificación: un modelo aplica una rúbrica (pairwise, Likert, score) sobre la salida del sistema y devuelve un veredicto escalable. Funciona cuando se calibra bien; se vuelve circularidad cuando el juez usa el mismo modelo que está juzgando.
Qué es
LLM as judge es un patrón donde un segundo LLM lee la salida del sistema (y opcionalmente un gabarito) y devuelve una nota o un veredicto. La motivación es simple: anotar mil casos con humanos cuesta semanas, y el juez de modelo cuesta centavos por caso. La pregunta es si esa nota corresponde a la humana con una correlación suficientemente buena para ser útil.
Tres formatos dominan el uso. Score continuo (0 a 1, Likert 1 a 5). Pairwise (cuál de A o B es mejor, o empate). Binario (pasa o no pasa). Cada uno tiene afinidad con métricas distintas, y la rúbrica define el resto.
Por qué calibrar contra humanos
El juez LLM tiene sesgos propios: prefiere la respuesta prolija, prefiere el primer ítem en las comparaciones, prefiere el tono didáctico. Sin calibración esos sesgos se vuelven veredicto, y el número publicado no significa nada.
La calibración es un experimento offline. Tomas de 100 a 300 casos reales anotados por humanos, corres el juez, comparas la nota del juez con la nota humana y mides la correlación (Pearson para continuo, exactitud/κ para binario). Aceptas el juez si la correlación pasa un umbral (0.7 en Pearson, 0.6 en Cohen κ es un piso razonable). Si no pasa, vuelves a la rúbrica.
Rúbrica: qué entra en el prompt
La rúbrica es el corazón del juez. Suelen bastar cuatro bloques: contexto (input del usuario, contexto recuperado, gabarito si lo hay), criterio (qué se está evaluando, en una frase), escala (cómo convertir en nota) y formato de la respuesta (un número, un JSON corto, nada de prosa libre).
Cuanto más corta la rúbrica, más innova el juez. Lo opuesto también es malo: una rúbrica gigante de 800 palabras traba al juez en burocracia. El punto justo cabe en 6 a 10 líneas y aun así cita un ejemplo positivo y uno negativo de la escala.
Sesgo de posición y cómo mitigarlo
En pairwise el juez tiende a preferir el ítem de la izquierda, y la tendencia se invierte cuando se cambia la posición. Solución: correr cada comparación en ambos órdenes (A,B y B,A), y considerar empate cuando los dos veredictos discrepan. Es lo que hizo el MT-Bench original, y se volvió estándar en cualquier benchmark serio.
En score, el sesgo es de anclaje: el juez se inclina hacia los extremos del espectro. Solución: usar una escala con referencia explícita (Likert 1-5 con un descriptor en cada nivel) en vez de un continuo libre. El continuo funciona, pero necesita más calibración.
Implementación mínima
El snippet muestra un juez binario (pasa o no pasa) con un guard-rail contra la circularidad: el juez es un modelo distinto del que está en el agente. En producción conviene cambiar el modelo por uno especializado (Prometheus, G-Eval) cuando el caso es cerrado y exige profundidad.
import { openai } from "../llm"; // juez: familia distinta a la del agente
type Verdict = { passa: boolean; motivo: string };
const RUBRICA = `Eres un juez binario.
Recibes (1) la pregunta, (2) el contexto recuperado, (3) la salida del agente y (4) el gabarito.
Responde SOLO un JSON con el formato {"passa": bool, "motivo": "<1 frase>"}.
Considera passa=true solo si la salida es fiel al gabarito Y no inventa información fuera del contexto.`;
export async function judge(input: string, contexto: string, output: string, gabarito: string): Promise<Verdict> {
const user = `Pregunta: ${input}\nContexto: ${contexto}\nSalida: ${output}\nGabarito: ${gabarito}`;
const resp = await openai.chat.completions.create({
model: "gpt-4o-mini",
response_format: { type: "json_object" },
messages: [{ role: "system", content: RUBRICA }, { role: "user", content: user }],
});
return JSON.parse(resp.choices[0].message.content);
}Cuándo NO usar LLM as judge
Cuando existe una métrica exacta disponible. Si el caso es '¿el agente resolvió la ecuación?', la respuesta es comparación de strings o ejecución de los asserts. Poner un juez LLM ahí es agregar costo y varianza sin motivo.
Cuando el dominio es cerrado y la rúbrica exigiría describir demasiados matices. En tareas muy específicas (cálculo financiero, validación de política regulatoria), el juez genérico se equivoca y el costo de calibrar supera el costo de un humano. Vuelve a la anotación humana por muestreo.
Cuando el presupuesto es corto. El juez LLM cobra por token de entrada y salida, y correr 500 casos con juez se vuelve un gasto recurrente que debe caber en el presupuesto mensual. Mide antes de escalar.
Puntos fuertes
- escala: anota mil casos en el tiempo que los humanos anotan cien, con un costo por caso mucho menor
- consistencia: los jueces humanos divergen entre sí, el juez LLM mantiene la misma rúbrica en todo caso
- trazabilidad: cada nota tiene un prompt y una respuesta, fácil de auditar y versionar
Limitaciones
- la calibración no es opcional: un juez sin calibrar se vuelve un sello que acepta cualquier cosa
- malo para tareas con gabarito exacto: la comparación de strings o los asserts son más baratos y más precisos
- costo: un juez LLM por caso en un dataset grande se vuelve un gasto recurrente que debe caber en el presupuesto
conexiones en el mapa
- LLM as judge - rúbrica automatizadaautomatiza la calificaciónEvals - calidad medida en producción
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…