En lo único que coinciden es en la palabra «juez».
Para mi tesis doctoral he leído el código fuente de siete herramientas de código abierto que usan un LLM como juez. Además estoy desarrollando un framework de pruebas para agentes LLM, y las dos cosas influyen en cómo leo estas herramientas.
El problema es la varianza. Si ejecutas un juez LLM dos veces sobre la misma entrada, la puntuación varía; si cambias el modelo del juez, varía más, y si reformulas la rúbrica, más todavía. Ninguna de estas herramientas elimina esa varianza, pero cada una la restringe a su manera. Lo decisivo es qué restricción elige, y de eso tratan las siguientes entregas.
Por qué recurrir a un juez
Si el paradigma existe es porque la mayor parte de lo que quieres evaluar de un agente, como la coherencia del plan, la elección de herramientas o si la respuesta fue útil, no tiene una respuesta de referencia. No hay un conjunto de test con el que comparar, así que recurres a un juez. Y el más barato que tienes a mano es un LLM potente.
Zheng et al. (2023) defendieron que ese LLM hiciera de juez. Bautizaron el paradigma «LLM-as-a-judge», construyeron MT-Bench en torno a él y mostraron que GPT-4 alcanzaba un 85 % de concordancia con expertos humanos en los votos sin empate del benchmark, algo por encima del 81 % que lograban los humanos entre sí en el mismo experimento. Fue esa cifra la que vendió el paradigma. Si un juez potente coincide con la preferencia humana más o menos tanto como los humanos entre sí, puedes meter un juez en una puerta de CI sin pagar a una persona para que haga ese trabajo.
Unos meses antes, Liu et al. (2023) ya habían afinado la técnica. Su framework G-Eval añadía dos piezas: unos pasos de razonamiento (chain-of-thought) que el propio LLM genera antes de puntuar y una función que pondera la puntuación final por la probabilidad que el modelo asigna al token de cada opción (en GPT-4, que no exponía esas probabilidades, se estimaban con 20 muestras a temperatura 1). El resultado era una puntuación continua, capaz de recoger la incertidumbre del modelo sin reducirla a un único entero. En la tarea de resumen, la correlación de Spearman de G-Eval con las valoraciones humanas llegó a 0,514 y superó la de todos los evaluadores anteriores; el que más se acercó fue UniEval, con 0,474.
Tres años después, el paradigma está en todas partes, hasta el punto de que todos los frameworks de evaluación de código abierto que he leído implementan alguna versión de él. Eso ya no se discute.
Cómo aparece la varianza
Si coges cualquier juez LLM de los que se usan de verdad, verás cuatro tipos de varianza en sus puntuaciones.
De una ejecución a otra, con el mismo modelo. Aunque pongas la temperatura a cero, la puntuación sigue variando, porque al servir el modelo la inferencia no es determinista bit a bit. Liu et al. (2023) observaron un efecto relacionado: si pides a un LLM una puntuación entera en una escala de 1 a 5, las puntuaciones de entradas distintas se amontonan en un mismo entero y borran diferencias reales. Su arreglo (ponderar la puntuación por las probabilidades de los tokens, sin quedarse con el argmax) suaviza esa granularidad, pero la incertidumbre de fondo del juez sigue ahí. El juez no se decanta por una respuesta fija; en cada llamada reduce una distribución a un único valor.
De un juez a otro. Si cambias el modelo que hay detrás del prompt del juez, los veredictos varían todavía más. Con los votos de Chatbot Arena, Zheng et al. (2023) vieron que GPT-4 y Claude-v1 coincidían el 66 % de las veces si se cuentan los empates y los veredictos que cambian con la posición, y el 95 % en los votos en que los dos eligen ganador. Con el mismo prompt y las mismas respuestas, otro modelo juzga distinto.
De un prompt a otro. Basta reformular la misma rúbrica para que cambie la puntuación. Zheng et al. prueban dos variantes del prompt para la misma tarea, y con solo cambiarles el nombre a los asistentes la tasa de «sesgo hacia el primero» de Claude-v1 baja del 75 % al 11,2 %. Al juez le afecta cómo están redactadas sus instrucciones, además de lo que dicen.
Sesgos sistemáticos que no se compensan al promediar. Zheng et al. pusieron nombre a tres. El primero, el de posición, hace que los jueces favorezcan la respuesta que aparece antes. Con pares de respuestas deliberadamente parecidas, GPT-4 mantiene el veredicto el 65 % de las veces al intercambiar el orden y en el 30 % de esas pruebas lo cambia a favor de la primera, mientras que Claude-v1 lo mantiene el 23,8 % de las veces. En el segundo, el de verbosidad, un ataque de «lista repetitiva» (rellenar una respuesta con viñetas reformuladas, sin contenido nuevo) hace que Claude-v1 y GPT-3.5 elijan la respuesta más larga el 91,3 % de las veces. Y en el tercero, el de autopreferencia, GPT-4 favorece sus propias respuestas con una tasa de victorias un 10 % mayor y Claude-v1 las suyas con un 25 % más, aunque Zheng et al. advierten de que sus datos son demasiado limitados para confirmar este sesgo. Gu et al. (2024) documentan otros en su revisión posterior (el de concreción, el cultural y el de diversidad), pero los tres de Zheng son los primeros con los que se topa cualquier puerta de CI.
Un matiz sobre el alcance. Las cifras anteriores salen de MT-Bench y Chatbot Arena en 2023, con los GPT-4 y Claude-v1 de entonces. Con los modelos más recientes las magnitudes han cambiado, pero el patrón de fondo se mantiene y al juez le siguen afectando los detalles de forma. La deriva entre actualizaciones del modelo es un eje de varianza aparte y queda fuera de esta entrada.
Son cuatro ejes y ninguno desaparece por sí solo. Ninguna de las siete herramientas de código abierto que he leído los elimina, aunque todas los restringen, cada una a su manera. En la sección siguiente explico por qué esa diferencia importa cuando el juez forma parte de un pipeline de producción.
Por qué importa en producción
En el entorno académico, a los jueces LLM se les evalúa con benchmarks, mientras que en producción se les pone a decidir en puertas de calidad. Las dos situaciones parecen iguales, pero no lo son.
Pongamos una puerta concreta: cada PR lanza la batería de tests, entre los que hay varias evaluaciones con juez LLM (la coherencia del plan sobre una entrada fija, la idoneidad de las llamadas a herramientas sobre otra y la utilidad de la respuesta sobre una tercera). Cada una puntúa entre 0 y 1, y la PR se fusiona si todas las puntuaciones superan un umbral.
Ahora lleva a ese pipeline lo que describe la sección anterior. El mismo juez, con el mismo prompt y la misma entrada, da puntuaciones distintas en ejecuciones consecutivas. Si pasas el juez a otro modelo, muchas puertas cambian de veredicto, y si retocas la rúbrica en un docstring, el umbral deja de significar lo que significaba la semana pasada.
Los equipos reaccionan de dos maneras, y las dos empeoran la puerta.
La primera es relanzar el test cuando falla y, si pasa al reintentarlo, darlo por bueno. Eso es enmascarar fallos reales con la excusa de gestionar tests inestables, porque cada reintento que convierte un fallo real en un aprobado es un bug fusionado. Cuando relanzar se vuelve costumbre en el equipo, la puerta pasa a ser, como mucho, informativa.
La segunda es saltarse la puerta cuando conviene. Los ingenieros sénior aprenden qué puntuaciones son ruidosas y cuáles no. La puerta acaba siendo una convención social que nadie hace cumplir, y la gobernanza se va erosionando PR a PR.
Las dos reacciones tienen el mismo origen. A una puerta de calidad no le basta con que la varianza sea baja: necesita que esté acotada, cosa que ninguno de los cuatro ejes anteriores garantiza por defecto. De ese hueco trata esta serie, que recorre las distintas maneras en que cinco de las siete herramientas intentan poner una cota a lo que puede decir un juez.