LLM-as-a-Judge: evaluar con modelos de lenguaje tiene más matices de lo que parece

Usar un modelo de lenguaje para evaluar la salida de otro modelo de lenguaje ya no es una práctica experimental: es el método dominante en pipelines de evaluación de producción. El problema es que buena parte de los equipos que lo adoptan lo hacen sin entender bien sus sesgos estructurales ni cómo se complica cuando entran en juego entradas multimodales.

Esta semana circuló en Hacker News un artículo de Yingzhe Lan que ofrece una introducción sistemática al tema: Introduction to (Multimodal) LLM-as-a-Judge. Vale la pena detenerse en él porque, aunque se presenta como introducción, recoge con precisión varios problemas que la literatura académica lleva meses discutiendo y que los equipos de producto suelen ignorar hasta que el sistema falla.

Qué es exactamente LLM-as-a-Judge

El patrón es sencillo: en lugar de pagar a evaluadores humanos o confiar en métricas automáticas clásicas como BLEU o ROUGE, se le pide a un modelo —el juez— que puntúe o compare respuestas generadas por otro modelo. En la práctica, esto se usa para evaluar calidad de respuestas en chatbots, alinear modelos mediante RLHF, construir leaderboards comparativos y validar outputs en pipelines agenticos.

La ventaja obvia es el coste y la escala: un juez LLM puede procesar miles de pares en minutos. La desventaja, menos obvia, es que el juez hereda los sesgos del modelo base y añade los propios del prompt de evaluación.

Los sesgos que más importan en la práctica

El artículo identifica varios patrones de sesgo bien documentados. El más conocido es el sesgo de posición: cuando se le presentan al juez dos respuestas para comparar, tiende a favorecer la primera o la última dependiendo del modelo. Hay estudios que muestran variaciones de hasta 15 puntos porcentuales solo por reordenar las opciones.

Otro sesgo relevante es el de verbosidad: los jueces LLM suelen puntuar más alto respuestas más largas aunque no sean más correctas o útiles. Esto es especialmente problemático cuando el objetivo es justamente entrenar modelos más concisos.

El tercero, menos discutido, es el sesgo de familiaridad: un modelo tiende a valorar más alto respuestas que se parecen a su propio estilo de generación. Si usas Claude Opus 4.8 como juez para evaluar respuestas generadas por el mismo modelo, la correlación con preferencias humanas puede ser artificialmente alta y no generalizar a otros modelos.

La capa multimodal añade complejidad real

Cuando las entradas incluyen imágenes, gráficos o vídeo, el problema se amplifica. El artículo señala que los jueces multimodales tienen dificultades adicionales para calibrar si una respuesta describe correctamente una imagen o si una explicación técnica sobre un diagrama es precisa. Los errores de percepción visual del modelo juez se confunden con errores de razonamiento del modelo evaluado, y separar ambas fuentes de error no es trivial.

Esto es relevante para cualquier equipo que esté construyendo sistemas de evaluación para aplicaciones con visión: análisis de documentos, asistentes de código con capturas de pantalla o pipelines de moderación de contenido visual. Usar un juez multimodal sin validar su propia tasa de error en percepción visual es añadir ruido a la señal de evaluación sin saberlo.

Para quién es útil esta lectura

El artículo está escrito para perfiles técnicos que ya conocen los fundamentos de los LLMs pero no han profundizado en metodología de evaluación. No requiere familiaridad con papers específicos, aunque referencia algunos. Es especialmente útil para:

• Ingenieros construyendo pipelines de evaluación automatizada en producción.
• Equipos que usan Claude Code con subagentes y necesitan validar la calidad de outputs entre capas del sistema.
• Investigadores aplicados que quieren un mapa mental antes de entrar en la literatura más técnica sobre reward models y preference learning.

Qué queda fuera

El artículo no entra en detalle sobre cómo calibrar jueces LLM contra anotaciones humanas, ni sobre técnicas como Constitutional AI scoring o el uso de rubrics estructuradas para reducir varianza. Tampoco aborda la gestión de coste cuando el juez es un modelo de frontera como Claude Opus 4.8 y se evalúan millones de pares. Son lagunas razonables para una introducción, pero conviene tenerlas en cuenta si se busca implementación directa.

---

Desde EP, el patrón LLM-as-a-Judge nos parece útil y probablemente inevitable a escala, pero el nivel de ingenuidad con que muchos equipos lo despliegan sigue siendo preocupante. Una introducción como esta no resuelve el problema, pero al menos nombra bien los riesgos.