LLM-as-a-judge: prompts libres, puntuación con rúbrica o un juez tipado con abstención

LLM-as-a-judge es un patrón de evaluación: un modelo lee una tarea, la salida del sistema evaluado y a veces una respuesta de referencia, y devuelve una nota. La investigación que dio nombre al patrón (Zheng et al., 2023, “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”) describe tres formas: comparación por pares, calificación de una sola respuesta y calificación guiada por referencia. Sea cual sea la forma, un juez mide la concordancia con los criterios que escribiste, interpretados por otro modelo. No mide verdad, satisfacción del usuario ni resultado de negocio salvo que tus criterios y labels humanos se conecten con ello. Por eso el juez debe evaluarse como cualquier clasificador. Esta página trata de juzgar otras salidas de IA—respuestas de chatbot, resúmenes, respuestas RAG, pasos de agentes. Para evaluar un workflow de JevModel con labels, ver evaluation.

Las tres opciones difieren sobre todo en la estabilidad de la salida y en si la incertidumbre es visible. Los prompts libres arrancan rápido; las rúbricas hacen comparables las notas entre ejecuciones; un juez tipado añade un schema fijo y probabilidades con umbral. La comparación trata de compromisos de ingeniería, no de un ranking de modelos juez.

Zheng et al. (2023) describen tres sesgos que conviene prever en el diseño. Sesgo de posición: en la comparación por pares el veredicto puede invertirse al intercambiar las respuestas, así que ejecuta cada par en ambos órdenes y cuenta una victoria solo si coinciden; si no, registra empate. Sesgo de verbosidad: el juez puede preferir la respuesta más larga aunque la longitud extra no aporte nada, así que escribe criterios que premien cumplir el requisito, no la cobertura, e incluye respuestas cortas y correctas en tus fixtures. Sesgo de autofavorecimiento: un juez puede favorecer salidas parecidas a las suyas, así que no dejes que el modelo evaluado se califique a sí mismo y oculta qué sistema produjo cada respuesta. Dos hábitos más ayudan: califica un criterio por pregunta en lugar de una nota global de “calidad” y, en tareas factuales, da al juez una respuesta de referencia, porque puede dejarse llevar por una respuesta incorrecta pero segura que él mismo habría resuelto.

Toma una muestra de salidas reales, incluidas las difíciles, y haz que dos personas las etiqueten a ciegas con los mismos criterios escritos. Si discrepan a menudo, arregla los criterios antes de culpar al juez: si las personas no coinciden, el juez no tiene nada estable que imitar. Después ejecuta el juez sobre los mismos ítems y reporta la concordancia por clase, no solo global: un juez que aprueba todo parece preciso cuando la mayoría de salidas están bien. Una tabla de confusión juez vs humano, más un estadístico corregido por azar como el kappa de Cohen si tu equipo lo usa, muestra dónde falla. Luego revisa bandas de probabilidad: entre los ítems que el juez marca con alta probabilidad, ¿cuántos marcaron igual las personas? Elige con esa tabla una banda de aceptación automática y otra de revisión. Congela la muestra como set de regresión y vuelve a ejecutarla cuando cambien el prompt del juez, los criterios o el modelo. Console → Batch de JevModel puede ejecutar una pregunta de juez fija sobre filas subidas y exportar las respuestas para este cruce.

Pon en state la tarea, una referencia opcional y una salida candidata, y haz una pregunta por criterio. En JevModel, Noul es una pregunta sí/no que devuelve una probabilidad de 0 a 1, adecuada para comprobaciones binarias como “¿cada afirmación está respaldada por el contexto dado?”. Score acepta 2–10 descripciones de niveles ordenados y devuelve un valor en esa escala, que puede caer entre niveles; sirve para criterios graduales como la utilidad, pero no es una probabilidad 0–1, así que define tus propias bandas. Una petición admite 1–8 preguntas con nombre, y el state serializado y la petición completa deben caber cada uno en 8.000 caracteres, por lo que las respuestas largas o pasajes recuperados deben extractarse. Para comparación por pares, envía dos peticiones con los candidatos en orden inverso y acepta solo resultados consistentes. Una probabilidad Noul cerca del medio, o un Score que cae entre tus niveles de aprobado y suspenso, es tu señal de abstención: envía esos ítems a una persona en lugar de contarlos. Las llamadas van a POST /api/v1/systemone con el modelo fijo typesafe/jev-1.13 vía OpenRouter.

{
  "state": {
    "task": "Answer the customer using only the help-center context.",
    "context": "Refunds are available within 30 days of purchase for annual plans.",
    "candidate_answer": "You can get a refund within 30 days if you are on an annual plan."
  },
  "questions": {
    "grounded": {
      "type": "noul",
      "instructions": "Is every factual claim in candidate_answer supported by the context?",
      "criteria": {
        "true": "All claims appear in or follow directly from the context.",
        "false": "At least one claim is missing from or contradicts the context."
      }
    },
    "helpfulness": {
      "type": "score",
      "instructions": "How well does candidate_answer resolve the task? Do not reward length.",
      "criteria": [
        "Does not address the task or is misleading.",
        "Addresses part of the task or needs a follow-up.",
        "Fully resolves the task in the needed detail."
      ]
    }
  }
}

Prescinde del juez cuando el código puede comprobar la respuesta: JSON válido, coincidencia exacta con un label esperado, un test unitario que pasa, una consulta SQL que devuelve las filas correctas. Las comprobaciones deterministas son más baratas y no derivan. No uses un juez como única aprobación en decisiones legales, médicas, financieras o de seguridad; úsalo para priorizar la revisión humana. No confíes en un juez que nunca comparaste con labels humanos, ni dejes que un modelo califique sus propias salidas. Ten cuidado con matemáticas, corrección de código y razonamiento de varios pasos, donde el juez puede dejarse engañar por la respuesta que califica; prefiere respuestas de referencia o tests basados en ejecución. JevModel en concreto es un modelo de decisión para texto y JSON: no ejecuta código, no navega ni lee imágenes, así que juzga lo que está escrito en state, no lo que pasa al ejecutar la salida. No es open source, y las cuentas gratuitas verificadas tienen 5 ejecuciones exitosas por día UTC: suficiente para probar un juez, no para calificar a diario un set de evaluación grande.