Same Input, Different Scores: A Multi Model Study on the Inconsistency of LLM Judge

Este estudio demuestra que, a pesar de las expectativas de estabilidad, los modelos de lenguaje actuales (LLM) asignan puntuaciones numéricas inconsistentes a las mismas entradas debido a variaciones entre modelos, familias y configuraciones de temperatura, lo que plantea riesgos significativos para la fiabilidad operativa y la equidad en entornos empresariales que utilizan LLM como evaluadores.

Lo esencial

¡Claro que sí! Imagina que has contratado a un equipo de jueces de cocina muy famosos (los Modelos de Lenguaje o LLMs) para que prueben tus platos y les pongan una nota del 0 al 10. Tu objetivo es que la cocina sea eficiente, así que quieres que estos jueces sean rápidos y justos.

Pero, ¿qué pasa si le das el mismo plato al mismo juez diez veces seguidas y, en lugar de darle siempre un 8, a veces le pone un 9, luego un 6, y luego un 10? ¡Eso sería un caos en tu restaurante!

Aquí te explico lo que descubrió Fiona Lau en su estudio, usando esta analogía:

1. El Problema: Los Jueces "Inestables"

El estudio se centró en ver qué tan consistentes son estos "jueces de IA" (como GPT-4, Gemini o Claude) cuando tienen que dar una nota numérica a una respuesta.

• La expectativa: Pensábamos que si le pedíamos al mismo juez que evaluara el mismo plato con las mismas reglas, siempre daría la misma nota.
• La realidad: ¡No es así! Incluso cuando les pedimos que sean "deterministas" (que actúen como robots sin improvisar), a veces cambian de opinión.
• La analogía: Es como si un juez de gimnasia, al ver a una atleta hacer el mismo salto perfecto, le diera un 9.5 la primera vez, un 7.2 la segunda y un 8.8 la tercera, sin que la atleta haya cambiado nada.

2. Los Tres Grandes Descubrimientos

A. El mismo juez, diferentes notas (Inconsistencia interna)

Si le preguntas al mismo modelo de IA la misma pregunta diez veces, a veces cambia su nota.

• El culpable: La "temperatura". Imagina que la temperatura es como el nerviosismo del juez.
  • Temperatura baja (0): El juez está muy calmado y serio.
  • Temperatura alta (1): El juez está un poco "borracho" de creatividad y cambia de opinión.
• El hallazgo: Incluso cuando el juez está "calmado" (temperatura 0), ¡sigue siendo un poco impredecible! Especialmente cuando tienen que juzgar si una respuesta es completa (¿dijo todo lo necesario?). Es como si el juez tuviera un día bueno y un día malo, aunque no se haya movido de la silla.

B. Jueces diferentes, criterios diferentes (Inconsistencia entre modelos)

Aquí es donde se pone interesante. Si le das el mismo plato a un juez de la familia GPT, otro de Gemini y otro de Claude, te darán notas muy distintas.

• La analogía: Imagina que le pides a tres críticos de comida diferentes que juzguen una pizza.
  • El crítico de Gemini es muy generoso: "¡Qué pizza tan completa! Le doy un 10".
  • El crítico de Claude es muy estricto: "Falta un ingrediente, es un 2".
  • El crítico de GPT se queda en medio: "Es un 6".
• El problema: En una empresa, si usas a un juez generoso para aprobar pedidos y a uno estricto para rechazarlos, ¡tendrás clientes muy confundidos! Un mismo mensaje podría ser "aprobado" por un modelo y "rechazado" por otro.

3. ¿Funciona ponerlos en "Modo Estricto"? (Temperatura)

Los investigadores probaron bajar la "temperatura" (el nivel de aleatoriedad) para ver si los jueces se volvían más estables.

• Resultado mixto: Funcionó bien para algunos (como GPT y Gemini), que se volvieron más consistentes. Pero para otros (como los modelos de Claude), no hizo mucha diferencia; seguían siendo inestables incluso cuando se les pidió que fueran robots.
• La lección: No puedes confiar en que "bajar la temperatura" arregle todos los problemas. Cada modelo tiene su propia personalidad y sus propios defectos.

4. ¿Por qué nos importa esto? (El impacto en el mundo real)

Imagina que tu empresa usa a estos jueces para tomar decisiones importantes:

• Enrutamiento: Si la nota es alta, el cliente habla con un humano experto. Si es baja, se le da una respuesta automática.
• El riesgo: Si el mismo cliente llama dos veces y el juez cambia su nota de "alta" a "baja" por pura casualidad, el cliente podría recibir un trato diferente sin razón. Eso es injusto y peligroso.

Conclusión: ¿Qué debemos hacer?

El estudio nos dice que no podemos confiar ciegamente en estos jueces automáticos para decisiones críticas.

• No son perfectos: Incluso los mejores modelos son como humanos: tienen días buenos y días malos, y a veces cambian de opinión sin razón.
• La solución: Las empresas no deberían usar solo a un juez. Deberían:
  1. Monitorear: Vigilar si las notas cambian mucho.
  2. Mezclar: Usar varios modelos juntos o tener un humano revisando las decisiones dudosas (un "juez de apelación").
  3. Entender sus defectos: Saber que algunos modelos son más estrictos que otros y ajustar las reglas en consecuencia.

En resumen: La IA es una herramienta increíble, pero todavía no es un juez infalible. Si la usas para tomar decisiones importantes, asegúrate de tener un "segundo par de ojos" humano o un sistema de seguridad, porque a veces, la misma pregunta puede recibir dos respuestas totalmente diferentes.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo "Same Input, Different Scores: A Multi Model Study on the Inconsistency of LLM Judge", presentado en español:

1. Planteamiento del Problema

El uso de Modelos de Lenguaje Grande (LLM) como evaluadores automáticos ("LLM-as-a-judge") se ha convertido en una práctica estándar en entornos de investigación y empresas para tareas como la clasificación, el enrutamiento y el control de calidad. Sin embargo, existe una brecha crítica en el conocimiento actual: la consistencia de los LLM al asignar puntuaciones numéricas.

Aunque se ha estudiado la precisión y el sesgo de estos modelos, poco se sabe sobre su estabilidad cuando se les pide generar valores numéricos (ej. una escala de 0 a 1) para criterios cualitativos. El problema central es que, incluso con las mismas entradas y configuraciones "deterministas" (temperatura = 0), los modelos pueden generar puntuaciones diferentes en ejecuciones repetidas. Esta inconsistencia representa un riesgo operativo significativo para flujos de trabajo empresariales que dependen de estas puntuaciones para tomar decisiones automatizadas (gatekeeping, triaje, etc.).

2. Metodología

El estudio se diseñó como una evaluación sistemática para medir la estabilidad de la puntuación bajo condiciones controladas:

• Datos: Se utilizaron pares de preguntas y respuestas extraídos de un sistema real de generación aumentada por recuperación (RAG) de una empresa. Esto asegura una alta validez ecológica y evita la contaminación de benchmarks públicos.
• Modelos Evaluados: Se seleccionaron cinco modelos de tres familias principales:
  • OpenAI: GPT-4o y GPT-4o-mini.
  • Google: Gemini-2.5-Flash.
  • Anthropic: Claude-Haiku-4.5 y Claude-Sonnet-4.5.
• Configuración Experimental:
  • Cada modelo se ejecutó 10 veces para las mismas entradas.
  • Se probaron dos configuraciones de temperatura: 0 (supuestamente determinista) y 1 (aleatoria).
  • Se evaluaron tres criterios: Relevancia, Precisión (Accuracy) y Completitud.
• Métrica de Análisis: Se calculó la desviación estándar de las puntuaciones a través de las 10 ejecuciones para medir la variabilidad intra-modelo, y se compararon las medias entre modelos para la variabilidad inter-modelo.

3. Contribuciones Clave

• Evidencia de No-Determinismo en Puntuación: Demuestra que la configuración de temperatura = 0 no garantiza un comportamiento determinista en la asignación de puntuaciones numéricas, contradiciendo la suposición común en la industria.
• Análisis de la Métrica de Completitud: Identifica que el criterio de "completitud" es el más inestable y variable, lo cual es crítico dado que es fundamental para evaluar sistemas RAG.
• Comparativa Trans-Familia: Revela diferencias sistemáticas en la "estrictitud" e interpretación entre familias de modelos (OpenAI, Google, Anthropic), lo que lleva a clasificaciones divergentes para la misma respuesta.
• Impacto en la Ingeniería de Prompts y Parsing: Destaca que la inconsistencia no solo afecta la puntuación, sino también el formato de salida, causando errores de análisis (parsing) en pipelines automatizados.

4. Resultados Principales

• Inconsistencia Intra-Modelo (RQ1):

  • Ningún modelo alcanzó una consistencia perfecta, incluso con temperatura = 0.
  • La métrica de completitud mostró la mayor variabilidad en todos los modelos.
  • Los modelos de Anthropic (Claude) mostraron picos de inconsistencia significativos incluso en temperatura 0, mientras que GPT-4o y Gemini mostraron mejoras más notables al reducir la temperatura.
  • En casos específicos, modelos como Gemini oscilaron entre puntuar 0 y 1 en la misma pregunta en diferentes ejecuciones.

• Inconsistencia Inter-Modelo (RQ2):

  • Existieron diferencias sistemáticas en la severidad. Por ejemplo, los modelos Gemini tendieron a ser más generosos en las puntuaciones de completitud, mientras que los modelos Claude interpretaron ciertas respuestas como fundamentalmente incorrectas (puntuación cercana a 0) cuando otros modelos las consideraron relevantes.
  • Esto implica que el resultado de una evaluación depende más de la elección del modelo que de la calidad objetiva de la respuesta.

• Efecto de la Temperatura (RQ3):

  • Reducir la temperatura a 0 mejoró la estabilidad en los modelos de OpenAI y Google (Gemini), llegando a reducir la varianza casi a cero en algunos casos de Gemini.
  • Sin embargo, para los modelos de Anthropic, la reducción de temperatura tuvo un efecto marginal o incluso contraproducente en ciertos casos, sugiriendo que la no-determinismo no es solo un problema de muestreo estocástico, sino que podría estar arraigado en diferencias arquitectónicas o de decodificación más profundas.

5. Significado e Implicaciones

El estudio tiene consecuencias críticas para la implementación de LLM en entornos de producción:

1. Riesgo Operativo y de Equidad: Si una misma consulta de usuario recibe puntuaciones diferentes según el modelo o la ejecución, las acciones derivadas (como enrutar a un agente humano, rechazar una solicitud o priorizar contenido) serán inconsistentes. Esto plantea problemas de equidad y responsabilidad legal.
2. Fragilidad de los Pipelines: La dependencia de la consistencia de los LLM para lógica de "gating" (barreras de decisión) es peligrosa. Un sistema que confía en una puntuación única sin monitoreo de estabilidad puede fallar silenciosamente.
3. Nuevas Métricas de Evaluación: Los autores proponen que, para uso empresarial, no basta con evaluar la puntuación media de un modelo. Es imperativo evaluar su desviación estándar (consistencia). Un modelo que es "consistentemente incorrecto" es más útil y predecible que uno que es "aleatoriamente correcto".
4. Recomendaciones: Se sugiere el uso de estrategias híbridas (humano-LLM), parsers robustos (agentes de extracción dedicados) y un monitoreo continuo de la estabilidad antes de desplegar evaluadores automáticos en sistemas críticos.

En conclusión, el artículo advierte que la no-determinismo de los LLM no es solo una curiosidad teórica, sino una fuente práctica de inestabilidad que debe medirse, monitorearse y mitigarse para construir sistemas de IA confiables y justos.