Modelo como juez: evalúa las respuestas de tu agente IA

Para seguir este post necesitas saber qué es un agente de IA (un programa que usa un modelo de lenguaje para responder preguntas o ejecutar tareas) y tener una idea básica de cómo funcionan los modelos de lenguaje. Si esos conceptos son nuevos, te recomiendo leer primero Arquitectura de un agente empresarial.

Construiste tu primer agente de IA. Responde preguntas, devuelve resultados, parece que funciona. Pero hay un problema que no te esperabas: a veces la respuesta es excelente, a veces es mediocre, y a veces directamente incorrecta. ¿Cómo sabes si está mejorando o empeorando cuando cambias algo en el código?

La respuesta obvia es revisarlo manualmente. Haces 20 preguntas, lees las respuestas, decides si están bien. Funciona cuando tienes 20 respuestas. No funciona cuando tienes 2.000.

El patrón “modelo como juez” resuelve esto de una forma que me pareció sorprendente la primera vez: le pides a otro modelo de IA que evalúe las respuestas del tuyo.

La idea, con una analogía primero

Piénsalo como un profesor que corrige trabajos. El alumno (tu agente) hace el ejercicio. El profesor (el modelo juez) lo lee con una rúbrica en mano y asigna una nota.

Una rúbrica es simplemente una lista de criterios que define qué es una buena respuesta. Por ejemplo: “1 punto si la respuesta es inventada, 5 puntos si está basada en los datos reales y es directa”. Sin rúbrica, el juez no tiene referencia para evaluar nada, igual que un profesor que corrige sin saber qué nota merece cada respuesta.

La diferencia con un profesor humano es que el modelo juez puede revisar miles de respuestas por minuto y siempre aplica exactamente los mismos criterios. Sin cansancio. Sin días malos.

Cómo implementarlo paso a paso

El siguiente diagrama muestra el flujo completo:

Paso 1: Define la rúbrica antes de escribir código

La rúbrica —que básicamente es una escala de puntuación con reglas muy bien definidas— es la parte más importante y la que más gente se salta. Si le dices al juez “evalúa si esta respuesta es buena” sin darle estos criterios concretos, vas a obtener evaluaciones inconsistentes.

La rúbrica debe responder: ¿qué significa exactamente una buena respuesta en tu caso? Una rúbrica concreta podría ser:

• 1: La respuesta contiene información inventada o incorrecta

• 2: La respuesta es vaga y no responde directamente la pregunta

• 4: La respuesta es correcta pero tiene un tono inadecuado

• 5: La respuesta es correcta, directa y con el tono apropiado

Fíjate que el 3 no aparece. No todas las rúbricas tienen que ser continuas. Lo que importa es que cada puntuación esté ligada a un criterio específico.

Paso 2: Elige el modelo juez

El juez tiene que ser más capaz que el modelo que estás evaluando. Pero “más capaz” no significa automáticamente “el más caro”: significa capaz de razonar sobre el criterio que estás evaluando. Para detectar alucinaciones, necesitas un modelo con buena comprensión de contexto. Para evaluar tono o coherencia lógica, también. Para comprobar si la respuesta sigue un formato exacto, no necesitas ningún modelo: eso lo hace código normal.

Si tu agente usa un modelo pequeño y rápido para ahorrar costes, el juez debería ser uno de última generación para ese tipo de tarea. La lógica es directa: si el juez fuera igual de limitado que tu agente, no podría detectar sus errores.

Paso 3: Diseña el prompt de evaluación

Un prompt es el texto que le envías al modelo para pedirle que haga algo. Si este término es nuevo, el post sobre Prompt Engineering para desarrolladores cubre los patrones más útiles para estructurarlos.

A la hora de extraer la evaluación del juez, pedirle simplemente “Devuelve SOLO este JSON” no es fiable en entornos de producción. Con cierta frecuencia, el modelo fallará: añadirá texto introductorio (“Aquí tienes el JSON solicitado:”), usará comillas incorrectas o devolverá una estructura malformada.

Aunque tener un bloque try/catch en tu código para parsear la respuesta es una buena práctica de seguridad, la solución real no es capturar el error y reintentar, sino forzar la salida correcta a nivel de API.

Los proveedores principales ofrecen herramientas específicas para garantizar que recibes un JSON válido y estructurado:

• OpenAI (Structured Outputs): Permite pasarle un esquema (JSON Schema) estricto a la API. El modelo se verá obligado a generar un JSON que coincida exactamente con tu estructura, eliminando los errores de formato.
• Anthropic (Prefilling): Claude soporta el prefilling (precompletado) de respuestas. Puedes forzar a que la respuesta del asistente empiece obligatoriamente por {, lo que guía al modelo a generar únicamente el objeto JSON sin texto extra.

// Sanitización mínima: elimina comillas tipográficas que romperían la plantilla literal.
// En producción adapta esto según la fuente del input (API, formulario, webhook, etc.)
function sanitizeInput(value: string): string {
  return value.replace(/["""'']/g, "'").trim();
}

// Llamamos al modelo juez con todo el contexto que necesita.
// En este tutorial el agente hipotético usaría un modelo más pequeño (ej. claude-haiku-4-5-20251001);
// el juez usa claude-opus-4-6 para tener criterio superior al evaluado.
const response = await anthropic.messages.create({
  model: "claude-opus-4-6",
  max_tokens: 300,
  messages: [
    {
      role: "user",
      // Le damos: la pregunta original + respuesta del agente + rúbrica
      content: `Pregunta del usuario: "${sanitizeInput(preguntaUsuario)}"
Respuesta del agente: "${sanitizeInput(respuestaAgente)}"

Rúbrica de evaluación:
1 = información inventada o incorrecta
2 = respuesta vaga o incompleta
4 = correcta pero tono incorrecto
5 = correcta, directa y tono apropiado

Devuelve SOLO este JSON, sin texto adicional:
{"puntuacion": número, "razon": "una frase explicando la nota"}`
    }
  ]
});

Paso 4: Extrae y almacena los resultados

El juez devuelve texto. Extraes ese texto de la respuesta y lo parseas para obtener la puntuación:

// Extraer el texto de la respuesta
const texto = response.content[0].text;

// El modelo puede devolver JSON precedido de texto explicativo o con comillas simples.
// Si el parseo falla, prueba a extraer el bloque JSON con regex antes de rendirte:
// const match = texto.match(/\{[\s\S]*\}/)?.[0];
try {
  const evaluacion = JSON.parse(texto);
  console.log(evaluacion.puntuacion); // 1-5
  console.log(evaluacion.razon);      // explicación del juez
} catch (e) {
  // Reintenta con un prompt revisado que refuerce el formato JSON estricto.
  // Si el error persiste, marca la evaluación para inspección manual: perder
  // una evaluación silenciosamente es peor que saber que falló.
  console.error("El juez no devolvió JSON válido:", texto);
}

Luego guardas el resultado en algún lugar: una base de datos, un archivo CSV, lo que sea. El valor real no está en la evaluación puntual, sino en el historial: ¿la puntuación media sube o baja después de cambiar el prompt de tu agente?

Sin historial, estás evaluando sin aprender nada.

Los enfoques de evaluación

No siempre usas el juez de la misma forma. Hay cuatro maneras de plantearlo según lo que necesitas medir. El árbol de decisión siguiente te ayuda a elegir el enfoque:

Evaluación directa: El juez lee una respuesta y le asigna una puntuación absoluta según tu rúbrica. Es el enfoque más simple y el que deberías usar primero. Ideal para medir si el agente está alucinando (inventando información que no existe), si tiene el tono correcto, o si responde directamente la pregunta.

Evaluación por pares: Le das al juez dos respuestas y le preguntas cuál es mejor. Cambias el prompt de tu agente, generas respuestas con la versión antigua y la nueva, y el juez decide. Este enfoque detecta mejoras pequeñas que con una puntuación absoluta serían difíciles de ver.

Evaluación con referencia: Tienes una “respuesta ideal” escrita por un humano. El juez compara la respuesta del agente contra esa referencia. Requiere más trabajo inicial, porque alguien tiene que escribir las respuestas ideales, pero es el enfoque más preciso cuando importa que el agente reproduzca un criterio humano específico.

Evaluación de pasos intermedios: Si tu agente ejecuta varias acciones antes de dar la respuesta final, el juez puede evaluar cada paso por separado. ¿Eligió bien la herramienta? ¿Formuló bien la consulta intermedia? Esto es útil cuando el error no está en la respuesta final sino en el razonamiento que llevó a ella.

Qué métricas tiene sentido evaluar

No todo se puede evaluar con reglas de programación. El modelo juez brilla en los casos abstractos, donde no existe una respuesta “correcta” objetivamente comprobable:

Fidelidad y alucinaciones: Si tu agente consulta una base de datos antes de responder (usando el patrón RAG, que significa que el agente busca información relevante antes de generar la respuesta), ¿está la respuesta basada en esos datos o el modelo inventó información? Detectar alucinaciones de forma automática es uno de los casos de uso más frecuentes de este patrón.

Relevancia: ¿La respuesta responde directamente lo que el usuario preguntó o se desvió del tema?

Uso de herramientas: Si tu agente puede llamar herramientas externas (tool calling, cuando el modelo puede usar funciones definidas por ti como consultar una API o buscar en una base de datos, más sobre esto aquí), el juez puede evaluar si eligió la herramienta correcta y con los parámetros adecuados.

Cumplimiento de políticas: ¿El agente siguió las instrucciones que le diste? ¿Evitó temas que no debería tocar?

Ventajas y limitaciones reales

Ventajas:

Aspecto	Detalle
Escalabilidad	Evalúa miles de respuestas por minuto. Un equipo humano no puede hacer eso.
Consistencia	Aplica la misma rúbrica siempre, sin variación
Coste	Mucho más barato que dedicar tiempo de personas a revisar outputs

Limitaciones:

Aspecto	Detalle
Sesgo de posición	En evaluación por pares, el juez puede preferir sistemáticamente la primera respuesta solo por aparecer antes. Mitigación: alterna el orden al hacer las evaluaciones
Sesgo de autopreferencia	Los modelos tienden a dar puntuaciones más altas a respuestas que se parecen a su propio estilo. Si el juez y tu agente son el mismo modelo, los resultados no son fiables
Alucinaciones del propio juez	El juez también puede equivocarse al evaluar. Una evaluación incorrecta que parece objetiva es peor que no tener evaluación

Justificación científica

Puede parecer contraproducente pedirle a una IA que evalúe a otra IA en lugar de hacerlo nosotros mismos. Sin embargo, la investigación demuestra que, al igual que ocurre con los humanos, verificar y evaluar una respuesta es una tarea cognitivamente más sencilla que generarla desde cero. Los LLMs reflejan perfectamente esta asimetría.

Durante años, la industria dependió de métricas clásicas como BLEU o ROUGE, que simplemente contaban coincidencias de palabras. Hoy sabemos que esas métricas están obsoletas para medir calidad real o razonamiento. Según el estudio G-Eval (Liu et al., 2023), usar modelos avanzados como evaluadores alcanza una correlación con las preferencias humanas muy superior a cualquier métrica tradicional.

La viabilidad de esta técnica quedó definitivamente validada en el paper fundacional “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (Zheng et al., 2023). En este estudio, los investigadores demostraron que los modelos de última generación alcanzan más de un 80% de concordancia con evaluadores humanos, un nivel de coincidencia prácticamente idéntico al que tienen los expertos humanos entre sí.

Errores comunes

Usar el mismo modelo como juez y como agente

Si tu agente usa claude-opus-4-6 y el juez también es claude-opus-4-6, el juez va a puntuar bien lo que su propia versión hubiera respondido debido al sesgo de autopreferencia. No es una evaluación objetiva.

Sin embargo, usar simplemente un modelo diferente como juez es una solución incompleta: ese nuevo modelo también tendrá sus propios sesgos particulares. La solución más robusta y respaldada por la investigación actual (como demuestra el paper “Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models”) es utilizar un Panel de Modelos Diversos (PoLL).

En lugar de depender de un solo juez supremo, la mejor práctica es consultar a varios modelos diferentes en paralelo (por ejemplo, mezclar modelos de Anthropic, OpenAI y Google) y agregar sus puntuaciones calculando la media o utilizando un sistema de votación mayoritaria.Rúbrica ambigua

“Evalúa si la respuesta es útil” no es una rúbrica, es una petición vaga. El juez va a interpretar “útil” de forma diferente en cada llamada. Una rúbrica funcional tiene puntuaciones concretas ligadas a criterios específicos y medibles. Sin eso, lo que obtienes es inconsistencia disfrazada de evaluación.

No revisar manualmente una muestra

El modelo juez también se equivoca. Vale la pena revisar manualmente 20 o 30 evaluaciones cada cierto tiempo para comprobar que el juez está siendo consistente con lo que tú esperarías. Si el juez da 5 puntos a respuestas que tú calificarías con 2, algo falla en la rúbrica o en el prompt del evaluador. Esta revisión manual es la que te dice si puedes fiarte del juez.

Evaluar sin guardar historial

Una evaluación puntual no dice mucho. Si cambias el prompt de tu agente hoy y no tienes el dato de antes, no puedes saber si mejoró o empeoró. Guarda siempre la puntuación, la fecha, la versión del prompt y el modelo usado. Con esos cuatro campos ya puedes construir un gráfico de evolución.

Checklist de implementación

• La rúbrica tiene puntuaciones concretas ligadas a criterios específicos y medibles

• El modelo juez es diferente y más capaz que el modelo del agente

• El prompt de evaluación incluye pregunta original, respuesta y rúbrica completa

• El juez devuelve salida estructurada (JSON) para facilitar el parseo automático

• Los resultados se almacenan con timestamp y versión del prompt para rastrear evolución

• Se revisa manualmente una muestra periódicamente para validar que el juez es consistente

Preguntas Frecuentes

¿Cuánto cuesta usar un modelo juez?

Depende del modelo y del volumen de evaluaciones. Para proyectos pequeños, el coste es casi irrelevante: evaluar una respuesta corta con un modelo de última generación cuesta fracciones de céntimo. Para volúmenes muy altos conviene hacer los cálculos antes de escalar, pero en la mayoría de proyectos iniciales no es la primera preocupación.

¿Necesito siempre un modelo más caro para el juez?

No necesariamente más caro, pero sí más capaz para el tipo de evaluación que haces. Si solo necesitas detectar si una respuesta contiene ciertas palabras o sigue un formato específico, eso se hace con código normal sin ningún modelo. El modelo juez vale la pena cuando el criterio es abstracto: tono, razonamiento, fidelidad a una fuente.

¿Cómo sé si mis rúbricas son buenas?

Coge 10 respuestas que tú mismo calificarías claramente bien y 10 que calificarías claramente mal. Pásalas por el juez con tu rúbrica. Si el juez y tú coincidís en la mayoría, la rúbrica funciona. Si no, revisa los criterios donde más discrepáis; ahí está el problema.

¿Este patrón reemplaza los tests de programación tradicionales?

No. Los tests programáticos (los que comprueban si el output cumple una condición exacta) siguen siendo más rápidos, más baratos y más fiables para lo que pueden cubrir. El modelo juez cubre el espacio que los tests programáticos no pueden tocar: calidad semántica, coherencia, tono. Son complementarios. Si quieres ver cómo encaja con otros enfoques de evaluación, el post Cómo evaluar agentes IA en producción tiene el panorama completo.