El LLM-judge: tu evaluador no determinista

Para tareas con respuesta única, evaluás con checks deterministas (regex, JSON parse, etc.). Para tareas abiertas. generación, resumen, respuestas RAG. no hay una sola respuesta correcta. Necesitás un evaluador que entienda calidad.

El LLM-judge es eso: un LLM con un system prompt cuidadosamente diseñado que evalúa outputs de otro LLM contra criterios que vos defínís.

Es meta. Sí. Estás usando un LLM para evaluar un LLM. Funciona porque los criterios de calidad (¿está bien fundamentado? ¿cita fuentes? ¿reconoce sus límites?) son más fáciles de juzgar que de generar.

Cuándo usar LLM-judge

• Cuando no hay una sola respuesta correcta. Generación de texto, resúmenes, respuestas a preguntas abiertas.
• Cuando los criterios son legibles pero no programables. "La respuesta es coherente con los snippets" es legible pero difícil de chequear con regex.
• Cuando podés calibrar. Tomás 30-50 casos, los etiquetás manualmente, comparás los veredictos del judge con los tuyos. Si concuerda >80%, el judge sirve. Si no, refinás el system prompt.

El task

Escribí el system prompt del judge para evaluar el generate del RAG. Cuatro criterios:

• grounded. boolean. ¿La respuesta se basa en los snippets?
• cites_sources. boolean. ¿Cita las fuentes?
• acknowledges_gaps. boolean. ¿Reconoce cuando no tiene info?
• clarity. 1-5 con anchors.

Más un campo rationale explicando los veredictos.

La regla del rationale

Un judge sin rationale es una caja negra. Un judge con rationale es debugueable. Cuando calibrás contra humanos, el rationale te dice por qué falló. para que ajustés el system prompt en la dirección correcta.

Cómo se evalúa

6 criterios LLM-judge sobre tu system prompt:

1. Define grounded con criterio concreto.
2. Define cites_sources claramente.
3. Define acknowledges_gaps con la regla "si no hay info, decilo".
4. Define la escala de clarity con anchors.
5. Pide rationale en el output.
6. Instruye output JSON crudo (sin preamble, sin markdown).