LLM-as-judge: calificar output que no tiene una sola respuesta correcta
El exact match califica un label de sentiment en una línea. No puede calificar una respuesta de soporte, un resumen, ni una respuesta conversacional — output abierto donde dos redacciones distintas son ambas correctas y no hay un string dorado contra el cual comparar. El LLM-as-judge es la movida ahí: un segundo modelo lee el output contra un rubric y devuelve un score. La mecánica — el rubric es el criterio de scoring, le pasás input más output más una reference opcional, y le pedís al juez que razone antes de calificar (Anthropic — mejora el juicio en tareas complejas). Las formas de feedback: Boolean, Categorical, Continuous. Los sesgos que hacen mentir a un juez ingenuo — posición, verbosidad, auto-preferencia — y las mitigaciones, terminando en la que más importa: calibrar el juez contra labels humanas antes de confiar en él. Y corre de las dos formas — offline sobre un eval set, u online sobre traces de producción en vivo.
Hay output que podés calificar en una línea de código. Un label de sentiment es positive, negative o neutral; la respuesta está bien o no; output == golden_answer y listo. Eso es exact match, y donde encaja es el calificador más rápido y confiable que hay. Pero la mayor parte de lo que un sistema de IA produce en producción no tiene esa forma. Una respuesta de soporte, el resumen de un documento largo, una respuesta conversacional, un email redactado — son output abierto. Dos redacciones distintas pueden ser ambas correctas, no hay un único string dorado contra el cual comparar, y el exact match califica a cada una como falla porque ninguna coincide con la reference carácter por carácter. Cuando el output no tiene una sola respuesta correcta, necesitás un calificador que juzgue significado, no que matchee texto.
Ese calificador es otro modelo. LLM-as-judge es la técnica: un segundo LLM lee el output contra un rubric que escribiste y devuelve un score. Esta página es la mecánica — qué es el rubric, qué le pasás al juez, el boost de razonamiento que lo hace más confiable, los sesgos que hacen a un juez descuidado quedar callado y equivocado, y la disciplina que tiene que venir antes de confiar en algo de esto. Es el principio 4 hecho operativo — evaluá antes de shipear — para la clase grande de output que el calificado-por-código no puede tocar.
Esta es una referencia para la técnica entre plataformas. El modelo juez de abajo es Claude (Anthropic), el harness de evaluación es el de LangSmith, y el equivalente in-platform es el Outcome test de Agentforce. Componen por dónde corre el sistema; la disciplina se transfiere, los knobs exactos son de cada vendor.
Cuándo agarrarlo
Agarrá un juez cuando lo que estás calificando es abierto y un chequeo determinístico no puede expresar "correcto". La guía de calificación de Anthropic ordena los métodos por exactamente este trade: el calificado-por-código es el más rápido y confiable pero "le falta matiz para juicios más complejos"; el calificado-por-humano es el más flexible y de mayor calidad pero "lento y caro"; el calificado-por-LLM es "rápido y flexible, escalable y apto para juicio complejo". Un juez es el reemplazo escalable del calificador humano — lo agarrás justo cuando la respuesta necesita juicio tipo humano pero tenés diez mil de ellas para calificar y no podés pagarle a una persona que lea cada una.
Así que la regla no es "usá un juez para todo". Es: si el exact match o un chequeo de string puede expresar el criterio — un label, una frase requerida, un campo parseable — usá eso, porque es más barato y nunca tiene opinión. Guardá el juez para lo que esos no alcanzan: tono, coherencia, fidelidad a una fuente, si una respuesta de texto libre de verdad responde la pregunta. Ese es el output abierto donde no hay string dorado, y es donde un juez se gana su costo.
Las formas de feedback
Un juez no devuelve solo "bueno" o "malo". La taxonomía de evaluadores de LangSmith da tres tipos de feedback, y elegir el correcto es la diferencia entre un score sobre el que podés actuar y un número que no significa nada:
| Tipo de feedback | Qué devuelve el juez | Usalo cuando |
|---|---|---|
| Boolean | True / false | El criterio es pasa/no pasa — la respuesta es fiel a la fuente, sí o no |
| Categorical | Un valor de un conjunto predefinido | El veredicto es un balde con label — correcto / parcial / incorrecto, o un modo de falla con nombre |
| Continuous | Un número dentro de un rango declarado | La calidad es un grado, no una compuerta — calificá coherencia del 1 al 5 |
Elegí la forma más gruesa que igual capture lo que te importa. El Boolean es el más fácil de accionar (es una compuerta) y el más fácil de mantener consistente para un juez; un continuo de 1 a 5 lleva más información pero el "4" y el "5" de un juez se desvían salvo que el rubric fije exactamente qué los separa. La propia guía de Anthropic se inclina igual — sé "empírico o específico", instruí al juez a devolver solo correcto o incorrecto, o a juzgar sobre una escala fija, porque "las evaluaciones puramente cualitativas son difíciles de evaluar rápido y a escala".
El rubric es el criterio de scoring
El rubric no es un agregado lindo alrededor del juez — es las instrucciones del juez. En palabras de LangSmith, la configuración de feedback "es el criterio de scoring que tu evaluador LLM-as-a-judge va a usar. Pensalo como el rubric sobre el cual tu evaluador va a calificar". Un rubric vago ("calificá la calidad") produce un score vago y desviado. Uno específico produce un score en el que podés confiar. El ejemplo de Anthropic de un buen rubric es justo así de concreto: "La respuesta debería mencionar siempre 'Acme Inc.' en la primera oración. Si no lo hace, la respuesta se califica automáticamente como 'incorrecta'".
Junto con el rubric, decidís qué ve el juez. Al evaluador se le entrega alguna combinación de tres cosas, mapeadas como variables:
- Input — la pregunta o tarea que se le dio al sistema. Necesario cuando "correcto" depende de qué se preguntó.
- Output — la cosa que se está calificando. Siempre se pasa; es el sujeto.
- Reference — una respuesta dorada o un documento fuente contra el cual calificar, cuando existe. Pasala para chequeos de fidelidad o corrección; omitila para criterios como concisión o tono que no necesitan comparación.
Pasás solo lo que el criterio requiere. Calificar concisión necesita el output solo. Calificar fidelidad necesita el output más la fuente a la que se supone que es fiel. Calificar si una respuesta responde la pregunta necesita el input más el output. Pasá el set equivocado — una reference que el rubric nunca usa, o ningún input cuando la corrección depende de él — y el juez califica sobre la información equivocada.
Pedile al juez que razone antes de calificar
La movida de mayor palanca al escribir un juez: hacé que piense antes de calificar, no después. Anthropic lo dice directo — "Fomentá el razonamiento: Pedile al LLM que piense primero antes de decidir un score de evaluación, y después descartá el razonamiento. Esto aumenta la performance de evaluación, particularmente para tareas que requieren juicio complejo". El patrón en su prompt de calificación es hacer que el modelo razone en tags <thinking> y después emita el veredicto en tags <result>, y te quedás solo con el veredicto.
La razón por la que esto funciona es la misma por la que funciona en el sistema que se está calificando: un score emitido en frío es un juicio instantáneo, y en cualquier cosa sutil un juicio instantáneo es ruidoso. Forzar el razonamiento primero hace que el juez realmente camine el rubric — chequee cada criterio, pese el output contra él — antes de comprometerse a un número. Tirás el razonamiento porque solo necesitás el score; lo pedís porque el score es mejor por haberse ganado. Sobre un Boolean simple en un caso obvio apenas importa. En "es este output de varios párrafos fiel a una fuente larga", es la diferencia entre un juez que califica y un juez que adivina.
Los sesgos — y la única mitigación que importa
Un juez es un modelo, y un modelo tiene sesgos que no tienen nada que ver con el rubric. Sin manejar, hacen al juez quedar callado y equivocado de maneras fáciles de no ver porque el score parece bien. Los conocidos y sus mitigaciones:
| Sesgo | Qué es | Mitigación |
|---|---|---|
| Sesgo de posición | Al comparar dos outputs, el juez favorece al que vino primero (o último) sin importar la calidad | Intercambiá el orden y juzgá de nuevo — o randomizá la posición a lo largo del eval set — y confiá solo en los veredictos estables al intercambio |
| Sesgo de verbosidad | El juez lee "más largo" como "mejor" y premia la longitud por sobre la sustancia | Hacé que el rubric califique la sustancia explícitamente; penalizá el relleno; no dejes que el conteo de palabras reemplace la calidad |
| Sesgo de auto-preferencia | Un juez tiende a favorecer el output escrito en el estilo de su propio modelo | Calificá con un modelo distinto del que produjo el output |
Esa última mitigación es la propia nota de trabajo de Anthropic, repetida a lo largo de sus ejemplos de evaluación: "En general es mejor práctica usar un modelo distinto para evaluar que el modelo usado para generar el output evaluado". Un modelo calificando la prosa de su propia familia es el conflicto de interés horneado en el setup más simple.
Pero conocer los sesgos no alcanza, porque no los podés ver desde adentro del juez — el score siempre parece plausible. La disciplina que los caza a todos de una es la calibración contra labels humanas: antes de confiar en un juez a escala, hacé que humanos califiquen una muestra, corré el juez sobre esa misma muestra, y chequeá que el juez coincida con los humanos. Si no coincide, arreglás el rubric — no a los humanos — y rechequeás. Solo un juez que sigue el juicio humano en casos que verificaste de verdad es un juez cuyos diez mil scores no verificados significan algo. LangSmith construye el loop de feedback adentro: te deja "recolectar correcciones humanas sobre los scores del evaluador" para "alinear mejor el evaluador LLM-as-a-judge a las preferencias humanas", plegando esas correcciones de vuelta al juez como ejemplos. Un juez que nunca calibraste es un generador de números que decidiste creer.
Offline y online: el mismo juez, dos lugares
Un juez no es solo para el laboratorio. El mismo evaluador corre en dos modos, y un sistema maduro usa los dos:
- Offline — el juez califica un eval set fijo: una colección curada de inputs con references conocidas-buenas, corrida antes de shipear un cambio de prompt o de modelo. Esta es la compuerta de regresión — te dice si el cambio que estás por deployar hizo la calidad mejor o peor, sobre casos que vos controlás, antes de que un cliente lo vea.
- Online — el juez califica traces de producción en vivo a medida que pasan. Los evaluadores online de LangSmith dan "feedback en tiempo real sobre tus traces de producción", actuando como "un sustituto escalable del juicio tipo humano" sobre tráfico que ningún eval set anticipó. Filtrás qué runs calificar y ponés un sampling rate para no calificar cada llamada, y el harness saca las variables de cada trace y se las pasa al juez.
Los dos responden preguntas distintas. El offline pregunta "¿esta versión es lo bastante buena para shipear?", contra un set congelado. El online pregunta "¿el sistema shipeado sigue siendo bueno ahora mismo?", contra tráfico real — que es cómo cazás la degradación silenciosa que un eval set, congelado por definición, nunca contiene. La mecánica del juez es idéntica; solo cambia la fuente del input.
La composición
Tres superficies, compuestas por dónde corre el sistema — no tres productos entre los que elegís:
- Claude como el modelo juez (Anthropic) — el modelo que hace la calificación, con el patrón "razoná antes de calificar" y el consejo permanente de calificar con un modelo distinto del que está bajo prueba. Este es el motor; es el mismo motor sea el harness alrededor LangSmith o tu propio script.
- El harness de evaluadores de LangSmith — el andamiaje que define el rubric, mapea input/output/reference al juez, lo corre offline sobre un dataset u online sobre traces de producción, y recolecta correcciones humanas para calibrarlo. Acá es donde vive el juez cuando el sistema está construido sobre un stack de LLM general.
- El Outcome test de Agentforce — el chequeo tipo-juez adentro de la plataforma. Un Outcome test pasa cuando el "gist" en lenguaje natural del outcome real coincide con el outcome esperado — una comparación semántica, no de string exacto, que es justo el problema de calificar output abierto del que trata toda esta página, resuelto de forma nativa para un agente construido en Agentforce.
No elegís uno. Un equipo que corre un agente de Agentforce fundamentado en Data 360 usa Outcome tests donde vive el agente; un equipo en un stack de Claude-más-LangGraph usa Claude-as-judge adentro de LangSmith; un equipo que corre los dos califica cada sistema donde corre. El juez es la misma idea en todos lados — calificación basada en significado de output abierto — y la plataforma solo decide qué harness lo sostiene.
El hilo
El LLM-as-judge es el calificador para todo lo que el exact match no alcanza: output abierto donde dos redacciones son ambas correctas y no hay string dorado. El rubric es las instrucciones del juez, así que tiene que ser específico; pasás solo el input, output y reference que el criterio necesita; y le pedís al juez que razone antes de calificar porque un veredicto ganado le gana a uno instantáneo en cualquier cosa sutil. La forma de feedback — Boolean, Categorical, Continuous — debería ser la más gruesa que igual capture lo que te importa. Los sesgos son reales e invisibles desde adentro — posición, verbosidad, auto-preferencia — y las mitigaciones ayudan, pero la que de verdad hace confiable a un juez es calibrarlo contra labels humanas antes de creerle los scores. Correlo offline como compuerta de regresión y online sobre tráfico en vivo, y el mismo juez que prueba que un cambio es seguro de shipear también caza el día en que calladamente deja de funcionar. Un juez es cómo la evaluación escala más allá de las cosas que podés calificar con == — pero solo un juez calibrado es evaluación y no un número que decidiste creer.
Related
- Principios de AI Engineering — evaluá antes de shipear (4) es el principio que esta página vuelve operativo
- Qué es el grounding — la fidelidad a una fuente recuperada es un uso top para un juez con una reference
- Calidad de retrieval — un juez es una forma de calificar si el contexto recuperado de verdad se usó
- Debuggear el grounding — cuando el juez dice que una respuesta es infiel, acá es donde rastreás por qué
- System prompts e instrucciones — el rubric es un system prompt para el juez, y aplica la misma disciplina de escritura
- Structured output — hacé que el juez emita un veredicto parseable para que el harness pueda leer el score
- Style Guide de evaluación — cuándo un juez es el calificador correcto, y el gate que alimenta
- Tracing y monitoreo — correr el juez online, sobre traces de producción en vivo
- Agentes de Agentforce — el agente cuyos outcomes califica un Outcome test
Reference: