¿Qué es LLM-as-a-judge y cuándo fiarse del modelo juez?
LLM-as-a-judge consiste en que un modelo puntúe la respuesta de otro. Contamos cómo auditamos nuestro propio modelo juez.
Resumen. LLM-as-a-judge (modelo juez) es el método de poner a otro modelo de lenguaje a puntuar la salida de un modelo. Mientras desarrollamos diffox, lo usamos para emparejar los hallazgos de revisión de código con errores que una persona había marcado de antemano. Este artículo explica los sesgos conocidos del método y cómo auditamos nuestro propio juez en agosto de 2026 sobre 891 pares (cada par es un hallazgo de revisión y un error marcado).
- No le preguntes al juez «¿es bueno?», sino «¿es lo mismo?». La respuesta de una palabra a «¿describen estos dos textos el mismo error?» se puede auditar; la nota que se le pone a «¿es buena esta salida?», no.
- El acuerdo global engaña. En 945 pares comunes, nuestros dos jueces coincidieron en el 98,8 %; en los pares positivos, que son los que deciden el resultado, el acuerdo fue del 93,5 %.
- El juez barato resultó generoso, pero movió poco la puntuación. De los 400 pares que el juez barato había dado por coincidentes, el juez fuerte rechazó 24 (6,0 %). Al puntuar una configuración con tres jueces distintos, la mayor diferencia fue de 0,033, por debajo del suelo de ruido de la medición (0,09).
- El ruido de verdad no está en el juez, sino en la ejecución. Cambiar de juez movió la puntuación como mucho 0,033; la desviación estándar del mismo sistema de una ejecución a otra es de 0,094.
¿Qué es LLM-as-a-judge?
La salida de un modelo de lenguaje muchas veces no se puede comparar con una única respuesta correcta: dos comentarios que describen el mismo error pueden estar escritos con palabras muy distintas. LLM-as-a-judge cubre ese hueco: le encargas la evaluación a otro modelo, al que le das una instrucción (una rúbrica). En español lo llamaremos «modelo juez».
El trabajo que popularizó el nombre es el artículo de 2023 de Zheng y sus colegas: mostraron que los jueces fuertes coinciden con las preferencias humanas en más del 80 % de los casos, el mismo nivel de acuerdo que hay entre personas. Hoy, la mayoría de los benchmarks se apoyan en un modelo juez. También ReviewBench, el que GitHub publicó para la revisión de código: puntúa los hallazgos con un modelo de lenguaje y una sola rúbrica, y explica que midió un 96,6 % de acuerdo al pedir a ingenieros sénior que volvieran a etiquetar sus casos.
El modelo juez no es la primera opción. La documentación de evaluación de Anthropic da el orden con claridad: primero, puntuar con código, porque es lo más rápido y lo más fiable; después, un modelo juez para los juicios que no se pueden expresar con una regla; y, antes de usar el juez a gran escala, comprobar su fiabilidad.
| Método | Punto fuerte | Punto débil | Cuándo |
|---|---|---|---|
| Puntuar con código | El más rápido y el más fiable; escala sin límite | No puede dar un juicio que no se pueda escribir como regla | Si la respuesta se comprueba con una coincidencia exacta o una búsqueda de texto |
| Puntuación humana | La más flexible y la de más calidad | Lenta y cara | En una muestra pequeña, para auditar al juez |
| Modelo juez | Rápido, flexible, escala | Tiene sesgos; hay que probarlo antes | Si hace falta criterio y la respuesta no se puede comprobar con una regla |
Fuente: la documentación de evaluación de Anthropic, 18 de octubre de 2026.
Los modelos juez tienen sesgos conocidos
El mismo artículo enumera también los límites de los modelos juez: sesgo de posición, sesgo de longitud, sesgo de autopreferencia y razonamiento limitado. Al montar el juez, tienes que tomar una medida contra cada uno.
El sesgo de autopreferencia, que favorece la salida del propio modelo, es el más fácil de evitar: basta con que el modelo que evalúa sea distinto del que generó la salida. El código de ejemplo de Anthropic lo señala como buena práctica. El sesgo de posición aparece en las preguntas que comparan dos respuestas; si preguntas dos veces cambiando el orden de las respuestas, ves su efecto. Contra el sesgo de longitud, la medida más eficaz es no pedirle al juez una nota, sino una respuesta que dependa de un único hecho.
Pregúntale al juez «¿es lo mismo?», no «¿es bueno?»
Lo que más decide la fiabilidad del juez es la pregunta. «¿Es bueno este comentario de revisión? Puntúalo del 1 al 10» no tiene una respuesta correcta; dos jueces, e incluso dos ejecuciones del mismo juez, dan notas distintas. El consejo de Anthropic va en la misma línea: que el juez diga solo «correcto» o «incorrecto», o que elija un nivel del 1 al 5; una evaluación puramente cualitativa es difícil de comprobar rápido y a escala.
La pregunta de nuestro juez es una comparación: recibe un comentario de revisión y un error marcado de antemano en el mismo pull request, y se le pregunta una sola cosa. El núcleo de la rúbrica se parece a esto:
You are given a review comment and a known bug in the same pull request.
Do they describe the SAME defect: the same code, failing for the same reason?
- A comment about the same file but a different problem is NOT a match.
- A comment that names the symptom while the known bug names its cause IS a match.
- If the comment is too vague to tell, answer no.
Answer with one word: yes or no.Las tres líneas de la rúbrica responden de antemano a los casos en los que el juez duda más a menudo: el mismo archivo pero otro problema, el síntoma frente a la causa y el comentario ambiguo. Si no se escriben esas líneas, los dos jueces discrepan justo en esos casos.
¿Por qué engaña el acuerdo global entre dos jueces?
El primer paso para probar un juez es hacerle las mismas preguntas a un segundo juez. Nosotros pusimos de jueces a dos modelos distintos con la misma rúbrica: en 945 pares comunes, coincidieron en el 98,8 %. Esa cifra, sola, tranquiliza, y engaña.
La gran mayoría de los pares son un «no» evidente: el comentario habla de un archivo y el error marcado, de otro completamente distinto. En esos casos, los dos jueces coinciden de todos modos. Lo que decide el resultado son los pares en los que al menos un juez dijo «sí», y ahí el acuerdo fue del 93,5 %. Cuando informes de la fiabilidad de un juez, di el denominador: todos los pares o solo los positivos.
Auditamos al juez barato con uno más fuerte, separando los pares en grupos
Nuestras mediciones del día a día las hacemos con un juez barato. Para responder a «¿y si este juez interpreta mal?» no hacía falta cambiar de juez por completo: la matriz completa pedía 4.185 pares. En su lugar, le preguntamos a un modelo más fuerte, con el ajuste de esfuerzo alto, solo por 891 pares, y no los elegimos al azar, sino de los grupos que podían responder a la pregunta.
- 91 pares en los que los dos jueces dijeron «sí»: el juez fuerte no cambió ninguno. Una coincidencia en la que estaban de acuerdo los dos siguió siéndolo con un juez más caro.
- 400 pares en los que los dos jueces dijeron «no»: solo cambió 1 (límite superior: 1,4 %). El juez no deja escapar coincidencias.
- 400 pares de los «sí» que cuentan para la puntuación: rechazó 24, es decir, el 6,0 %. El juez barato es generoso al dar coincidencias por buenas.
El resultado son dos frases distintas, y no conviene mezclarlas. Las puntuaciones absolutas salen unas 0,02–0,03 más optimistas de la cuenta. Cambiar de juez no movió la puntuación de una configuración más de 0,033, por debajo del suelo de ruido de la medición (0,09). Pero lo medimos en una sola configuración, así que no decimos que el orden entre dos configuraciones se mantenga en todos los casos. Que el fallo del juez importe o no depende de para qué lo uses.
Repetir la ejecución mueve la puntuación más que cambiar de juez
Al volver a puntuar la misma configuración con tres jueces distintos, el mayor desplazamiento de F1 fue de 0,033. En cambio, al volver a ejecutar la misma configuración, con los mismos pull requests y el mismo juez, la desviación estándar de una ejecución a otra fue de 0,094; una vez, sin cambiar nada, vimos una diferencia de 0,058 entre dos ejecuciones.
Es decir, la incertidumbre de fondo de la medición no viene del juez, sino de la propia aleatoriedad del sistema. La regla que sale de aquí es sencilla: si la diferencia entre dos configuraciones es menor que unos 0,09, una sola ejecución no la puede ver, y comprar un juez mejor no cambia eso.
Un hallazgo que el juez no puede emparejar no siempre está mal
En la mayoría de los benchmarks, un modelo juez compara el hallazgo con una referencia, es decir, con errores marcados de antemano. Un hallazgo que no está en la referencia cuenta como «falsa alarma». Pero eso solo dice una cosa: quien preparó la referencia no anotó ese punto. El hallazgo también puede ser correcto.
Por eso ReviewBench publica dos familias de métricas: una usa solo las etiquetas que existen y la otra evalúa además, por separado, los hallazgos que no tienen equivalente en el conjunto de referencia (golden set). Haz la misma distinción en tus mediciones: «no coincide con la referencia» y «es incorrecto» son dos etiquetas distintas, y para decir lo segundo hay que mirar el propio hallazgo.
Guarda las decisiones del juez y mide sin juez los cambios de reglas
Cada llamada al juez se paga, y no tiene sentido hacer dos veces la misma pregunta sobre el mismo par. Guarda cada decisión junto con la identidad del par y del juez: el modelo, el ajuste de esfuerzo y la versión de la rúbrica. Si cambia alguno de ellos, no muestres las decisiones antiguas y las nuevas en la misma tabla; dos cifras medidas con dos jueces distintos no se pueden comparar.
No todos los cambios necesitan un juez. Cuando cambias un umbral o un filtro, puedes volver a pasar la regla antigua y la nueva sobre resultados ya guardados y mirar solo los casos en los que no coinciden. Así medimos un cambio en uno de nuestros filtros: sobre 1.405 hallazgos guardados, la regla antigua y la nueva solo discrepaban en 6 casos, y bastó con leer esos seis uno por uno. Una ejecución nueva no habría sido gratis ni tan exacta.
Estas lecciones salen de las mediciones del propio diffox: no decidimos si un cambio funciona con una sola ejecución ni con un juez sin auditar. En el producto, en cambio, la cita en la que se apoya un hallazgo no la comprueba un modelo juez, sino código (artículo sobre la arquitectura).
Preguntas frecuentes
¿Qué es LLM-as-a-judge?
Es el método de poner a otro modelo de lenguaje, al que se le da una instrucción (una rúbrica), a puntuar la salida de una IA. Se usa en tareas en las que la respuesta no se puede comparar con un único texto correcto; por ejemplo, para decidir si dos comentarios describen el mismo error.
¿Es fiable LLM-as-a-judge?
Depende de la pregunta. Un estudio de 2023 mostró que los jueces fuertes coinciden con las preferencias humanas en más del 80 % de los casos. En las preguntas de comparación («¿son estos dos lo mismo?») los jueces son coherentes; en las preguntas abiertas en las que se pide una nota, no. Antes de fiarte, prueba el juez con un segundo juez o con etiquetas humanas en una muestra pequeña.
¿Cómo se escribe una rúbrica para LLM-as-a-judge?
Redúcela a una sola pregunta y limita la respuesta: «sí/no» o un nivel del 1 al 5. Escribe en la rúbrica los casos límite en los que el juez dudaría: qué cuenta como coincidencia, qué no y qué responder si no está claro. La documentación de Anthropic recomienda además que el juez razone antes de dar la respuesta.
¿Qué métricas hay para LLM-as-a-judge y en cuál fijarse?
Para el propio juez: la tasa de acuerdo con etiquetas humanas o con un segundo juez, sobre todo en los ejemplos positivos, y la tasa con la que un juez más fuerte cambia sus decisiones, con su intervalo de confianza. El acuerdo global parece más alto de lo que es por culpa de los ejemplos negativos fáciles.
¿Puede el modelo juez ser el mismo que el modelo evaluado?
Mejor que no. Es un sesgo conocido que los modelos juez den mejor nota a su propia salida. El código de ejemplo de Anthropic señala como buena práctica que el modelo que evalúa sea distinto del que generó la salida.
¿Qué diferencia hay entre LLM-as-a-judge y agent-as-a-judge?
LLM-as-a-judge evalúa solo la salida final. Agent-as-a-judge es una extensión que propuso un artículo de 2024: la evaluación la hace un agente que puede usar herramientas, y también da retroalimentación sobre los pasos intermedios del trabajo. Está pensado para evaluar sistemas de agentes de varios pasos.
¿Usa diffox un modelo juez en sus revisiones?
Durante el desarrollo, sí: para emparejar los hallazgos con errores marcados de antemano y medir si un cambio funciona. Cuando revisa un pull request, en cambio, la cita en la que se apoya un hallazgo no la comprueba un modelo juez, sino código: si la cita está de verdad en el archivo y si pertenece a las líneas que cambiaron.