Resumen — LLM-as-a-judge es la práctica de utilizar un modelo de lenguaje para puntuar la respuesta de otro modelo según una rúbrica escrita, en lugar de (o junto a) evaluadores humanos. El artículo MT-Bench de Zheng et al. (2023) demostró que GPT-4 coincide con expertos humanos en aproximadamente un 80%, a la par de la frecuencia con la que dos humanos coinciden entre sí en la misma tarea. Ese resultado es lo que convirtió a esta técnica en el estándar para evaluar chatbots, pipelines RAG y agentes a gran escala. También es lo que permite que la técnica falle sin ser detectada: un juez genérico puede igualar el promedio humano mientras pasa por alto todas las alucinaciones de su conjunto de pruebas. Utilice la puntuación de respuesta única con una rúbrica explícita para la evaluación en producción, la comparación por pares para clasificar versiones de modelos y nunca confíe en un juez que no haya medido frente a un conjunto de datos de referencia etiquetado.
Este artículo está dirigido a ingenieros que ya realizan evaluaciones y buscan una respuesta sólida a la pregunta: "¿deberíamos usar un juez LLM aquí y, de ser así, cómo?". Si nunca ha redactado una evaluación, comience por el artículo de MT-Bench y luego regrese.
Qué significa realmente "LLM-as-a-judge"
Un juez LLM es un modelo al que se le envía un prompt pidiéndole que evalúe algo, generalmente la respuesta de otro modelo. Devuelve una puntuación, una etiqueta o una preferencia. Esa es toda la arquitectura. Todo lo interesante reside en el prompt, la rúbrica y cómo se mide si los veredictos del juez coinciden con la realidad.
El patrón fue nombrado en "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" de Zheng et al.. Antes de ese artículo, ya se utilizaban LLMs para calificar a otros LLMs (el repositorio de evaluaciones de OpenAI lo hacía desde GPT-3.5), pero MT-Bench fue el trabajo que le puso cifras. Calificaron 80 preguntas de múltiples turnos sobre escritura, razonamiento, matemáticas, programación, conocimiento y juegos de rol, utilizando GPT-4 como juez y pares de expertos humanos como verdad fundamental. La concordancia entre GPT-4 y los humanos se situó en el mismo rango que la concordancia entre dos humanos. La técnica era real.
La razón por la que se popularizó es operativa, no filosófica. Un proceso de evaluación exclusivamente humano no escala bien. Tres evaluadores, 200 ejemplos y una rúbrica de múltiples criterios suponen una semana de trabajo. Si se sustituye por un juez LLM, la misma evaluación se ejecuta en 12 minutos por 4 dólares. La contrapartida es que el juez aporta sus propios sesgos y, a diferencia de los evaluadores humanos, esos sesgos son sistemáticos.
Cómo puntúa las respuestas un juez LLM
Existen tres modos de puntuación, y la elección entre ellos cambia lo que su evaluación puede y no puede decirle.
- Comparación por pares pide al juez que elija cuál de las dos respuestas es mejor. En esto se basa Chatbot Arena, y es el modo más fiable en los resultados de MT-Bench, porque los juicios relativos son más fáciles que los absolutos. Utilice la comparación por pares cuando realice pruebas A/B de dos versiones de modelos o dos prompts. No la utilice cuando necesite un umbral de calidad absoluto, porque las puntuaciones por pares no tienen un suelo: la respuesta B puede ganar todas las comparaciones y aun así ser inutilizable.
- Calificación de respuesta única con rúbrica pide al juez que puntúe una respuesta según un estándar explícito. Este es el modo que desea en producción, porque cada respuesta obtiene una puntuación en el mismo eje y puede establecer puertas de despliegue a su alrededor ("lanzar si la recuperación de fidelidad se mantiene por encima de 0.85 en el conjunto de prueba"). Elija la escala de menor precisión que capture la distinción que le interesa: binaria (aprobado/suspendido) cuando la pregunta es "¿violó el modelo la rúbrica, sí o no?", una escala de tres puntos (suspendido / parcial / aprobado) cuando los grados de fallo importan para la clasificación, y solo pase a escalas de 1 a 5 o de 1 a 10 si realmente necesita esa resolución y dispone de datos de referencia para validar que el juez puede utilizarla. Las escalas detalladas invitan al juez a inventar distinciones que no puede defender, y el ruido resultante consume la señal que quería medir. La calidad de la rúbrica importa más que la elección de la escala. Una rúbrica vaga ("califique la utilidad del 1 al 5") le da un número sin contenido informativo. Una rúbrica basada en afirmaciones ("puntuación 0 si alguna afirmación factual no está respaldada directamente por el pasaje recuperado") le da un número sobre el que puede actuar. Las rúbricas también son inestables con el tiempo; Shankar et al. (2024) documentaron que los evaluadores humanos revisan rutinariamente sus criterios después de ver las respuestas del modelo, un fenómeno que denominan deriva de criterios, razón por la cual una rúbrica redactada al principio nunca debe considerarse definitiva.
- Evaluación basada en referencias proporciona al evaluador una respuesta correcta conocida y mide qué tan cerca está la respuesta del candidato. Es el equivalente más cercano a las métricas tradicionales de PNL como BLEU y ROUGE, pero basado en la semántica en lugar de en la superposición de n-gramas. Funciona bien para tareas con resultados restringidos (traducción, resúmenes comparados con un resumen de referencia, extracción de datos estructurados). Sin embargo, falla en tareas abiertas, ya que suele haber muchas respuestas aceptables y el evaluador penalizará aquellas que sean correctas pero diferentes.
En la práctica, la mayoría de las configuraciones de producción utilizan una evaluación de respuesta única por criterio (fidelidad, relevancia y cumplimiento de formato) y emplean la comparación por pares solo durante la fase de desarrollo para elegir entre diferentes prompts candidatos.
Cuándo un LLM es la herramienta adecuada para evaluar
Un LLM evaluador funciona bien en tareas donde el juicio es esencialmente un problema de comprensión lectora basado en una rúbrica claramente definida. "¿Contiene esta respuesta alguna afirmación fáctica no respaldada por el contexto recuperado?" es una pregunta de comprensión lectora. Lo mismo ocurre con "¿Se niega esta respuesta a contestar en los casos en que la especificación exige que lo haga?". El modelo evaluador debe extraer la afirmación, localizar el pasaje de respaldo (o notar su ausencia) y emitir un veredicto. Los modelos de vanguardia realizan esto con eficacia.
Funciona menos bien en tareas que requieren que el evaluador sepa cosas que el prompt no puede codificar. "¿Es graciosa esta respuesta?" es una pregunta que cualquier modelo responderá, pero las respuestas reflejarán los sesgos del evaluador, no los de sus lectores. "¿Es este código Rust idiomático?" requiere que el evaluador haya asimilado las mismas convenciones que su equipo, lo cual probablemente no haya hecho. Para estas tareas, trate al evaluador como una señal más entre varias, en lugar de como una verdad absoluta.
Es contraproducente en tareas donde el costo de un error no detectado es alto y el patrón de fallo es poco frecuente. Un evaluador que detecta el 80% de las alucinaciones parece aceptable hasta que se implementa un chatbot de información médica donde el 20% restante representa un riesgo regulatorio. En esos casos, el evaluador actúa como un filtro de triaje (reduce el volumen de casos que deben revisar los humanos), no como la última palabra.
Un ejemplo práctico: un evaluador de fidelidad en 40 líneas
El evaluador útil más sencillo es una rúbrica de fidelidad de respuesta única para una respuesta RAG. Aquí tiene una versión ejecutable utilizando el SDK de Python de OpenAI (probada con openai==1.54.3 y gpt-4o-2024-11-20):
Tres aspectos a destacar sobre este prompt que una versión genérica suele pasar por alto. Al evaluador se le indica que enumere las afirmaciones antes de evaluarlas, lo cual es chain-of-thought prompting aplicado a la evaluación: el paso de razonamiento explícito fuerza una verificación a nivel de afirmación en lugar de una basada en impresiones generales, y Wei et al. (2022) demostraron que este tipo de estructura paso a paso mejora consistentemente el rendimiento en tareas de clasificación y razonamiento. El contexto truncado se maneja explícitamente, ya que las canalizaciones de recuperación truncan en los límites de los fragmentos y, de lo contrario, el evaluador trataría oraciones incompletas como soporte completo. La temperatura es cero, porque una temperatura distinta de cero en una tarea de clasificación binaria introduce una varianza que no se puede interpretar.
Esto es suficiente para ejecutar, pero no para implementar. Las dos secciones siguientes cubren las partes que convierten un ejemplo funcional en un evaluador desplegable: perfeccionar el prompt y medir si realmente coincide con el criterio humano.
Redacción del prompt y la rúbrica del evaluador
El prompt del evaluador es donde realmente se obtienen la mayoría de las mejoras en una configuración de LLM como juez. El modelo está fijado por su proveedor, la escala de puntuación está fijada por el diseño de su rúbrica y el conjunto de referencia está fijado por su dominio. El prompt es la única pieza que puede iterar de forma económica, y es la que distingue a un evaluador que obtiene una alineación de 0.40 de uno que obtiene 0.75 frente a las mismas etiquetas.
Un prompt de evaluación eficaz consta de cuatro elementos. Una definición del criterio en los términos propios de su dominio, no con vocabulario genérico de aprendizaje automático (por ejemplo, "fiel al contexto recuperado" es una definición de dominio; "alta calidad" no lo es). Una estructura de razonamiento explícita que indique al evaluador que enumere las afirmaciones, condiciones o llamadas a herramientas antes de puntuar (esto es la cadena de pensamiento, y mejora el rendimiento en tareas de clasificación de forma generalizada). Una regla de puntuación que asigne el resultado del razonamiento a la escala, como "si alguna afirmación enumerada no está respaldada directamente por el contexto recuperado, puntuar 0", en lugar de "use su criterio". Y una cláusula de gestión para los casos excepcionales que surgen en producción: contexto truncado, recuperaciones vacías, respuestas parciales o negativas.
Lo que no debe incluir en el prompt es una larga lista de "asegúrate de que tu respuesta sea útil, honesta e inofensiva". Las instrucciones genéricas se ignoran. Las reglas específicas a nivel de afirmación sí se siguen. Otra cosa que debe evitar es especificar demasiado el formato del veredicto; si el modelo tiene que producir una justificación estructurada larga antes de su puntuación, está pagando por tokens que no leerá.
Los sesgos que hacen que los evaluadores ingenuos no sean fiables
Tres sesgos aparecen con la suficiente constancia como para tener nombre propio. Los tres fueron documentados en MT-Bench y se han reproducido en trabajos posteriores; las magnitudes varían según el modelo y la tarea, así que considere las cifras siguientes como ilustrativas.
- Sesgo de posición es la tendencia a favorecer la respuesta que aparece primero (o a veces la última) en una comparación por pares. En las mediciones originales de MT-Bench, GPT-4 cambió su respuesta preferida cuando se intercambió el orden en aproximadamente un tercio de los casos. La solución es evaluar cada comparación en ambos órdenes y contar solo los casos en los que el veredicto sea coherente. Esto duplica el coste de inferencia y no es opcional.
- Sesgo de verbosidad es la tendencia a preferir respuestas más largas. Los evaluadores más recientes son menos susceptibles que el GPT-4 original, pero el sesgo no ha desaparecido y se ve afectado negativamente por las rúbricas de respuesta única que no incluyen la longitud como criterio. Si su rúbrica no dice "las respuestas concisas puntúan igual o mejor que las verbosas con una precisión equivalente", su evaluador está optimizando implícitamente para la longitud. La mitigación consiste en incluir explícitamente la neutralidad de longitud en la rúbrica.
- Sesgo de preferencia propia es la tendencia de un evaluador a favorecer las salidas de la misma familia de modelos a la que pertenece. La magnitud de este efecto es objeto de debate (algunas replicaciones lo consideran pequeño, otras grande), pero es lo suficientemente importante como para no utilizar el Modelo A como evaluador en una comparación A frente a B si A o B es el Modelo A. Utilice un tercer modelo como evaluador o recurra a evaluadores humanos para esa comparación específica.
Existen más (sesgo de sentimiento, sesgo de adulación, prioridades de longitud que interactúan con el formato de la rúbrica), pero estos tres explican la mayoría de los fallos de producción que vemos en la práctica. Detectarlos en su propio conjunto de referencia es para lo que sirve la calibración.
Calibración del evaluador frente a un conjunto de referencia etiquetado
Un prompt de evaluación que parece razonable con tres ejemplos fallará en producción. La forma de descubrirlo antes de la implementación es la calibración: ejecute el evaluador frente a un conjunto de referencia etiquetado, mida la brecha entre sus veredictos y las etiquetas humanas, e itere el prompt hasta que la brecha se cierre.
El ciclo de calibración mínimo viable tiene tres entradas. Un conjunto de referencia de 30 a 200 ejemplos extraídos de la distribución de evaluación real, etiquetados por expertos en el dominio (no por anotadores generalistas; el conocimiento del dominio es importante aquí, y la diferencia es grande). Una ejecución de referencia que registre el conjunto completo de exactitud, precisión, exhaustividad, F1, correlación de Pearson, correlación de Spearman y Kappa de Cohen, no solo una de ellas. Y un paso de optimización que reescriba el prompt basándose en los ejemplos con peor rendimiento, utilizando un meta-LLM como optimizador (el patrón OPRO de Yang et al. 2023). El ciclo se repite hasta que la alineación se estabiliza, lo que en la práctica ocurre entre cinco y diez iteraciones.
Por qué utilizar las siete métricas y no solo la exactitud: la exactitud agregada oculta la exhaustividad por clase. Un evaluador con 0,9 de exactitud y 0,1 de Kappa de Cohen está esencialmente adivinando; el mismo evaluador produciría una exactitud similar en un conjunto de datos aleatorio. Un evaluador con 0,7 de exactitud y 0,6 de Kappa está razonando. Informar solo de la exactitud es el error más común que cometen los equipos cuando creen que tienen un evaluador funcional.
Para obtener detalles sobre el conjunto de siete métricas, el bucle OPRO, el análisis de coste frente a alineación y un caso de producción real donde la calibración mejoró un juez GPT-4.1 genérico de 0,40 a 0,75 de alineación utilizando nueve anotaciones humanas, consulte Cómo optimizar su juez LLM para evaluaciones de IA.
Creación del conjunto de referencia (gold set)
La calibración depende de un conjunto de referencia, y estos no existen por defecto. Construir uno es el paso previo indispensable que determina si todo lo que viene después mide algo real o simplemente ruido.
Un conjunto de referencia es una colección de pares de entrada-salida etiquetados por expertos en la materia con el veredicto que desea que emita el juez. Tres propiedades hacen que un conjunto de referencia sea sólido para la evaluación. Debe extraerse de la distribución de evaluación real: consultas reales, contextos recuperados reales y respuestas de agentes reales, no ejemplos sintéticos que parezcan plausibles para quien escribió el conjunto de datos. Las clases de error deben estar representadas; un conjunto de referencia de 100 ejemplos que son todos fieles no le dice nada sobre si el juez detecta la falta de fidelidad, que es el único error que importa. Además, el acuerdo entre evaluadores sobre el conjunto de referencia debe medirse antes de utilizarlo; si dos expertos discrepan en más del 20% de las etiquetas, la rúbrica es ambigua y la calibración optimizará frente al ruido en lugar de frente a los modos de fallo.
Generar las consultas y las respuestas sintéticas pero realistas para un conjunto de referencia es un problema de ingeniería en sí mismo. Actualmente existen varios marcos de trabajo para hacer esto a partir de sus documentos fuente, y las diferencias entre ellos afectan a los tipos de fallos que el conjunto de referencia resultante pone de manifiesto. Para una prueba comparativa de seis marcos de generación de preguntas y respuestas frente a los mismos documentos fuente, consulte Conjuntos de datos de referencia para la evaluación de LLM: seis marcos de trabajo de preguntas y respuestas probados.
El acuerdo entre el juez y el humano depende de la tarea
La cifra que la mayoría recuerda de MT-Bench es "alrededor del 80%", pero ese número oculta tres aspectos que vale la pena conocer.
El primero es que el 80% es el acuerdo sobre el tipo de tarea que midió MT-Bench (chat abierto de varios turnos). El acuerdo es mayor en tareas cerradas (preguntas y respuestas factuales, código con comprobaciones de salida deterministas) y menor en tareas donde los propios humanos discrepan (escritura creativa, opinión y humor). El juez no puede superar el acuerdo entre evaluadores en la tarea subyacente; si dos expertos humanos solo coinciden el 65% de las veces sobre si una respuesta es útil, ningún juez alcanzará el 80%.
El segundo es que el acuerdo no es lo mismo que la alineación. Un juez puede obtener un 80% de precisión bruta acertando la mayoría de los casos fáciles (respuestas fieles identificadas como fieles) mientras pasa por alto cada instancia de la clase de error que realmente importa (respuestas no fieles marcadas como fieles). La cifra agregada halaga al juez; el recuerdo (recall) por clase es lo que le indica si debe implementarlo. La sección de calibración anterior es la que soluciona esto: mida ambos, ajuste el prompt frente a los fallos y repita.
El tercero es que las métricas de acuerdo dependen de la métrica utilizada. Informar de la precisión bruta en un conjunto de referencia desequilibrado (la mayoría de ejemplos correctos, pocos fallos) halaga al juez. Informar del Kappa de Cohen, que se ajusta al acuerdo por azar, es más difícil de falsear. Un juez con 0,9 de precisión y 0,1 de Kappa está esencialmente adivinando. La correlación de Pearson es útil para puntuaciones continuas; la de Spearman es más fiable si solo confía en la clasificación y no en los valores absolutos.
Para los flujos de trabajo de producción, el estándar mínimo es: medir sobre un conjunto de referencia etiquetado, informar al menos de la precisión más el Kappa de Cohen, y tratar cualquier afirmación basada en una sola métrica con sospecha.
La decisión de cuándo usar un juez LLM por sí solo, cuándo usarlo como filtro de triaje con humanos en el subconjunto marcado, y cuándo prescindir del juez y usar solo humanos depende de tres variables: el coste de un fallo no detectado, el volumen de evaluaciones y la tasa a la que deriva la distribución de evaluación.
Del ejemplo a la producción: integrando el juez
El ejemplo de 40 líneas que vimos al principio de este artículo es suficiente para evaluar una respuesta en un REPL de Python. Poner un juez frente a cada respuesta en producción (o ejecutarlo en cada solicitud de extracción en CI) es un problema de ingeniería diferente.
Los aspectos que surgen a escala no son llamativos. Procesar solicitudes por lotes para que la inferencia del juez no domine la latencia de extremo a extremo. Gestión de reintentos para los casos en los que el juez devuelve JSON mal formado, supera los límites de tasa o agota el tiempo de espera. Registro estructurado de veredictos y razonamientos para que pueda diagnosticar más tarde por qué se marcó un caso específico. Detección de regresiones que se activa cuando la alineación en el conjunto de referencia de control cae entre despliegues. Control de versiones de los prompts del juez de la misma manera que versiona el código de la aplicación, para que pueda atribuir los cambios de alineación a ediciones específicas del prompt. E integración con su sistema de CI para que la ejecución del juez sea parte de la puerta de despliegue en lugar de una comprobación manual que alguien olvida hacer bajo presión de tiempo.
Ninguna de estas cosas es intelectualmente difícil. Todas requieren trabajo, y el orden en el que las implemente afecta a qué fallos de producción se enfrentará primero. El error que cometen la mayoría de los equipos es implementar el bucle de prompt y evaluación sin control de versiones, perdiendo así la capacidad de atribuir regresiones cuando la alineación cambia.
Cuándo NO usar un juez LLM
Tres situaciones en las que no deberías recurrir a un juez, pero en las que los equipos suelen hacerlo de todos modos.
Cuando la tarea tiene una comprobación de exactitud determinista, no utilices un juez. La equivalencia de consultas SQL, la validación de esquemas JSON, la coincidencia mediante expresiones regulares, la comparación exacta de cadenas y la coincidencia de argumentos en llamadas a herramientas son problemas ya resueltos. Un juez LLM que envuelva cualquiera de estos procesos añade latencia, costes y una probabilidad no nula de equivocarse en algo que tiene una respuesta definitiva. Ejecuta la comprobación determinista, detecta los fallos rápidamente y llama al juez solo para las partes que realmente requieran razonamiento en lenguaje natural.
Cuando no hayas creado un conjunto de datos de referencia (gold set) etiquetado, no utilices un juez en producción. El juez te da un número. Sin una verdad absoluta, no puedes saber si ese número significa algo. Hay equipos que lanzan jueces que obtienen una puntuación media de 4,2 sobre 5 y la utilizan como señal para el despliegue, sin darse cuenta de que ese mismo juez puntuaría un resultado aleatorio con un 4,0. El conjunto de referencia no necesita ser enorme (30 ejemplos bien elegidos superan a 300 descuidados), pero debe existir.
Cuando el coste de un fallo no detectado supera el coste de una revisión humana, no utilices un juez como filtro final. Úsalo como un filtro de triaje que reduzca el volumen de casos que deben revisar las personas. Un juez que detecta el 80% de los fallos permite a los revisores humanos gestionar cinco veces más volumen de trabajo; eso es una verdadera ventaja. Desplegar un juez sin supervisión humana en un sector regulado es una decisión distinta, que debe tomarse de forma explícita con la participación de los departamentos legal y de cumplimiento, y no de forma implícita solo porque el juez obtuvo una buena puntuación en un conjunto de desarrollo.
El juez es una herramienta, no un veredicto. Se gana su lugar detectando los fallos que, de otro modo, llegarían al usuario. Pierde su lugar en el momento en que dejas de medir si sigue cumpliendo su función.
