LLM como juez
Por qué importa
En profundidad
La configuración tiene tres ingredientes: un prompt de prueba, una o más respuestas candidatas y un prompt de evaluación que indica al modelo evaluador cómo calificar. El prompt de evaluación suele incluir la entrada original, la salida candidata, una respuesta de referencia opcional y una rúbrica — por ejemplo, "califica utilidad, precisión y claridad en una escala del 1 al 5, explica tu razonamiento y luego proporciona la puntuación final". Pedir al juez que razone antes de puntuar, en un paso de Cadena de pensamiento, mejora sistemáticamente el acuerdo con los evaluadores humanos frente a pedir una simple cifra. Una vez escrita la rúbrica, la misma llamada al juez se ejecuta sobre cientos o miles de casos de prueba por unos pocos centavos cada uno, lo que vuelve práctico el enfoque para la Evaluación continua a una fracción del costo de la Anotación humana.
Puntuación por pares frente a individual
Hay dos configuraciones básicas. En la puntuación individual, el juez ve una respuesta y la califica contra la rúbrica, normalmente en una escala de 1–5 o 1–10; G-Eval, un framework temprano e influyente de 2023, mostró que guiar al juez por la rúbrica paso a paso produce puntuaciones que siguen las calificaciones humanas en tareas de resumen y diálogo. En la comparación por pares, el juez ve dos respuestas al mismo prompt y elige una ganadora, que es como funcionan MT-Bench y la mayoría de las evaluaciones automatizadas de estilo arena. La comparación por pares suele ser más fiable porque elegir entre dos candidatos es una tarea más fácil que calibrar una puntuación absoluta, y evita el problema de que todas las respuestas terminen en 4 de 5. La puntuación individual, por su parte, es más barata para calificar a escala la salida de un solo sistema, ya que cada caso de prueba necesita una única llamada al juez. La mayoría de los pipelines de producción usa ambas: puntuaciones individuales para seguir regresiones, veredictos por pares para comparaciones directas entre modelos.
De benchmarks a bucles de entrenamiento
La misma maquinaria cumple tres trabajos distintos. Primero, benchmarks: MT-Bench califica respuestas de chat de varios turnos con un potente modelo juez y se convirtió en una métrica estándar de leaderboard para la calidad del chat. Segundo, datos de entrenamiento: las preferencias del juez sobre pares de respuestas se convierten en Datos sintéticos de preferencias que entrenan un Modelo de Recompensa, que luego impulsa una optimización al estilo RLHF — este pipeline es, en esencia, a lo que se refiere RLAIF, y así escalan los laboratorios el aprendizaje de preferencias más allá de lo que pueden producir los etiquetadores humanos. Tercero, pruebas de regresión: los equipos de producto mantienen un conjunto fijo de prompts de prueba y vuelven a juzgar las salidas con cada cambio de modelo o prompt, detectando regresiones de calidad antes del lanzamiento. En los tres trabajos, el juez realiza una tarea que los humanos no pueden escalar o no pueden hacer con coherencia.
El problema de los sesgos
Los jueces LLM tienen modos de fallo documentados, e ignorarlos produce clasificaciones basura. Sesgo de posición: muchos jueces favorecen la respuesta que aparece primero (o segunda), por lo que los pipelines serios ejecutan cada par en ambos órdenes y conservan únicamente los veredictos que sobreviven al intercambio. Sesgo de verbosidad: los jueces prefieren sistemáticamente respuestas más largas y estructuradas incluso cuando la longitud adicional no aporta nada, razón por la que existen variantes de puntuación controladas por longitud. Sesgo de preferencia propia: un modelo usado como juez tiende a puntuar las salidas de su propia familia por encima de lo que haría un juez independiente, así que las configuraciones más seguras juzgan con un modelo de familia distinta al evaluado. El formato superficial también importa — los encabezados markdown, las listas con viñetas y un tono seguro empujan las puntuaciones hacia arriba. Ninguno de estos problemas es fatal, pero significan que el prompt y el protocolo de evaluación importan tanto como el modelo juez.
No sustituirá el juicio humano
Una idea equivocada común es que un juez potente vuelve obsoleta la Evaluación humana. El acuerdo declarado entre los principales modelos jueces y los evaluadores humanos supera el 80 % en benchmarks como MT-Bench — aproximadamente el nivel de acuerdo entre dos humanos —, pero ese es un promedio y la fiabilidad por ejemplo es mucho más inestable. Los jueces son malos para detectar una Alucinación segura de sí misma y bien formateada, porque el texto se lee bien y el juez a menudo tampoco conoce la respuesta correcta. También heredan sus propios puntos ciegos, por lo que las evaluaciones de alto riesgo — consejo médico, autolesiones, resistencia a jailbreaks — siguen exigiendo revisión humana, y conviene contrastar con sentido crítico las afirmaciones de leaderboards frente a votos de preferencias humanas como los de Chatbot Arena. El encuadre honesto: un LLM juez es un proxy barato y ruidoso de las preferencias humanas, excelente para clasificar y detectar regresiones, no una fuente de verdad fundamental.
Cuándo confiar en el juez
Como regla general, juzgar funciona mejor cuando la calidad depende de cómo se dice algo y no de si es exactamente correcto: seguimiento de instrucciones, tono, utilidad, fluidez de resúmenes, calidad del chat. Funciona peor en la frontera factual, donde el juez tampoco conoce la respuesta, en dominios especializados donde el modelo juez es débil y en idiomas con pocos recursos. La higiene estándar es construir un pequeño conjunto de referencia de unos cientos de ejemplos etiquetados por humanos, medir el acuerdo entre el juez y los humanos antes de escalar y volver a validarlo cada vez que cambien el modelo juez, la rúbrica o la distribución de tareas. Los equipos que se saltan este paso terminan optimizando sus modelos para complacer al juez en vez de al usuario — un modo de fallo que aparece como modelos que escriben respuestas más largas, ornamentadas y sutilmente peores.