LLM como juez: evaluar un modelo mediante un modelo

#El principio y su utilidad

Se le da a un modelo una pregunta, la respuesta producida por el sistema que se quiere evaluar, posiblemente los pasajes utilizados para responder y una respuesta de referencia, y después una rúbrica de evaluación. Devuelve una puntuación y una justificación. Al repetir este proceso en cien casos, se obtiene un indicador que se puede seguir a lo largo del tiempo, con cada cambio de prompt, de modelo o de parámetro de búsqueda.

La alternativa es la evaluación humana, que sigue siendo la referencia y no es escalable: nadie revisará cien respuestas con cada cambio de prompt. El juez automático permite responder a «¿esta modificación ha mejorado o empeorado el sistema?» en diez minutos, lo que cambia la forma de trabajar. El artículo fundacional de Zheng et al. estuvo motivado precisamente por esta constatación: los benchmarks existentes (MMLU y similares) no miden lo que importa en una conversación abierta, y la evaluación humana a gran escala es demasiado costosa para iterar rápidamente sobre un sistema que evoluciona cada semana.

#Elaborar una rúbrica sólida

1. 01
   Un criterio a la vez

   Pedir una puntuación global no tiene sentido. Se puntúan por separado la fidelidad a las fuentes, la pertinencia y la exhaustividad.
2. 02
   Una escala breve con descripciones

   Tres o cuatro niveles, con una descripción de lo que significa cada uno. Una escala sobre diez produce puntuaciones que no son reproducibles.
3. 03
   Exigir justificación antes de la calificación

   Un juez al que se le pide razonar y luego concluir es claramente más estable que el que solo da un número. Es la misma lógica que la «limited reasoning ability» señalada por Zheng et al.: forzar el razonamiento explícito reduce esta limitación.
4. 04
   Preferir la comparación por pares

   «¿Cuál de estas dos respuestas es la mejor?» es una pregunta a la que un modelo responde mucho mejor que a «puntúa esta respuesta sobre cinco» —es el formato que utiliza Chatbot Arena para comparar los modelos entre sí.

#Los sesgos y cómo contenerlos

El artículo de referencia sobre el tema identifica exactamente tres sesgos y una limitación: el sesgo de posición, el sesgo de verbosidad, el sesgo de autopreferencia (self-enhancement) y una capacidad de razonamiento limitada. No es una hipótesis de un blog, sino el resultado central del estudio que introdujo MT-Bench y Chatbot Arena, dos referencias que aún se utilizan hoy para clasificar modelos.

La buena noticia, documentada por el mismo estudio: un juez potente como GPT-4 alcanza más del 80 % de coincidencia con las preferencias humanas en MT-Bench y Chatbot Arena, el mismo nivel de coincidencia que el medido entre dos evaluadores humanos. La regla de uso que resume todo este capítulo: un juez sirve para comparar, nunca para certificar la calidad en términos absolutos. Una puntuación de 4,2 sobre 5 no dice nada; pasar de 3,1 a 3,8 en el mismo conjunto de pruebas con el mismo juez dice algo real.

El sesgo de verbosidad no es una preocupación teórica: el benchmark AlpacaEval, muy utilizado para comparar modelos ajustados mediante instrucciones, es conocido explícitamente por favorecer a los modelos que generan respuestas más largas, a igualdad de calidad. Su versión con control de longitud («length-controlled») eleva la correlación con las clasificaciones de Chatbot Arena de 0,94 a 0,98 — una prueba numérica de que neutralizar este único sesgo acerca mecánicamente la evaluación automática a la evaluación humana, en lugar de alejarla de ella.

#¿Un juez local es una opción seria?

Sí, bajo dos condiciones. La primera es el tamaño: por debajo de unos 14 mil millones de parámetros, los juicios se vuelven inestables y el formato de salida falla, lo que hace que la campaña sea inutilizable; esto es coherente con la referencia de memoria del sitio (14B ≈ 9 GB en Q4). La segunda es el contexto: el juez debe poder incluir la pregunta, los pasajes y la respuesta a la vez; un contexto saturado hace que se puntúe un texto truncado, y nadie lo nota, ya que el modelo sigue respondiendo normalmente sobre lo que realmente ha recibido.

La ventaja de un juez local es evidente cuando los datos evaluados son confidenciales: enviar cada respuesta y cada fragmento a una API externa para puntuarlos anula la ventaja de haber mantenido el sistema en local, especialmente en un caso médico, jurídico o financiero en el que los propios fragmentos fuente contienen datos sensibles. Y, a diferencia de la producción, una campaña de evaluación tolera muy bien la lentitud: se inicia por la noche, en una GPU que se utiliza para otra cosa durante el día, y se recogen los resultados por la mañana.

#Herramientas para no reinventar el pipeline

No es necesario escribir desde cero tu propio sistema de evaluación con un modelo juez. Prometheus, un proyecto de investigación de código abierto, entrena específicamente un modelo de 13 mil millones de parámetros para este uso: « We train Prometheus, a 13B evaluator LLM that can assess any given long-form text based on customized score rubric provided by the user » (entrenamos Prometheus, un LLM evaluador de 13 mil millones de parámetros, capaz de evaluar cualquier texto largo según una rúbrica de puntuación personalizada proporcionada por el usuario). Los autores indican una correlación de Pearson de 0,897 con evaluadores humanos en 45 rúbricas personalizadas, frente a 0,882 para GPT-4 y solo 0,392 para ChatGPT con el mismo protocolo: una diferencia que ilustra hasta qué punto un modelo no especializado puede evaluar mal, incluso cuando sus respuestas en una conversación son, por lo demás, correctas.

Prometheus

13B, abierto, diseñado específicamente para una evaluación detallada con una rúbrica personalizada; una base sólida para un juez local dedicado, en lugar de un modelo generalista adaptado a un uso distinto del original.

Un modelo generalista de 14B o más

Qwen, Llama o Mistral en este rango de tamaño también funcionan como juez, con una rúbrica cuidadosamente redactada en lugar de un entrenamiento dedicado a esta tarea específica.

Un marco de orquestación

Útil para lanzar la campaña, almacenar los resultados y seguir la evolución del puntaje con el tiempo, en lugar de recodificar todo cada vez que se vuelva a ejecutar un test en una nueva versión.

#Cómo es un prompt de juez sólido

Retomemos las cuatro reglas de la sección anterior con un caso concreto: un sistema RAG interno que responde a preguntas sobre procedimientos. El prompt del juez debe contener explícitamente la pregunta planteada, los pasajes fuente recuperados, la respuesta que se va a evaluar, una rúbrica con criterios separados y una instrucción para justificar la evaluación antes de dar la puntuación. Es más largo de escribir que un simple «puntúa esta respuesta sobre diez», pero ese detalle es lo que distingue una campaña de evaluación aprovechable de una cifra que tranquiliza sin medir nada.

Question de l'utilisateur : {question}
Passages source fournis au système : {passages}

Réponse A : {reponse_a}
Réponse B : {reponse_b}

Pour chaque réponse, évalue séparément :
1. Fidélité aux passages fournis (aucune affirmation absente des sources)
2. Pertinence par rapport à la question posée
3. Complétude (la question est traitée entièrement)

Justifie d'abord ton analyse pour chaque critère, puis conclus par :
Meilleure réponse : A ou B
Raison en une phrase.

Dos detalles lo cambian todo en esta estructura básica. Primero, los pasajes de las fuentes se envían al juez, no solo la respuesta: sin ellos, es imposible verificar la fidelidad, solo la forma. Segundo, la justificación precede a la conclusión en el orden del prompt: un juez al que se le pide primero la puntuación tiende a justificarla a posteriori en lugar de razonar antes de decidir, lo que agrava la capacidad de razonamiento limitada señalada por el estudio de referencia. Por último, alternar el orden de las respuestas A y B de un caso a otro y luego calcular la media de las dos pasadas neutraliza la mayor parte del sesgo de posición documentado por Zheng et al.

#Cuándo no usarlo

Para validar un sistema con implicaciones importantes

Médico, jurídico, financiero: un juez automático no reemplaza una revisión humana en casos que implican responsabilidad.

Para comparar dos sistemas muy diferentes

Los sesgos de estilo y de longitud dominan en cuanto los formatos de respuesta difieren, como muestra el sesgo de verbosidad documentado por Zheng et al.

Cuando existe un test determinista

Si la respuesta correcta es un número o un valor exacto, una simple comparación es más precisa e infinitamente más barata que un LLM que actúe como juez.

Con demasiado pocos casos

Con diez preguntas, la varianza de generación supera la diferencia que quieres medir.

• Ragas: evaluar tu RAG local con cifras
• Langfuse: observar tus LLM locales (trazas, prompts, evaluaciones)
• Leer los rankings de modelos sin equivocarse
• RAG local: introducción (para situar lo que se evalúa)
• Fuente: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023)
• Fuente: Prometheus, un juez open source de 13B (Kim et al., 2023)
• Fuente: repositorio oficial de GitHub de Prometheus

#FAQ