LLM-as-a-judge es una de esas ideas que parecen casi demasiado convenientes: usas un modelo para evaluar a otro y, de repente, tu equipo de agentes tiene una forma escalable de calificar la calidad sin revisar cada ejecución manualmente.
El patrón es real y puede ser extremadamente útil. Pero también es fácil usarlo mal.
La investigación describe el problema con bastante claridad. En algunas tareas, los modelos jueces pueden coincidir sorprendentemente bien con los humanos. Pero también pueden verse sesgados por el orden de las respuestas, preferir resultados escritos con su propio estilo, recompensar en exceso la verbosidad, variar sus puntuaciones cuando la rúbrica cambia ligeramente y calificar con seguridad algo que en realidad no pueden verificar.
Así que la pregunta correcta no es: «¿Deberíamos usar LLM-as-a-judge?».
Es esta:
¿Dónde encaja en el stack de pruebas, qué debería evaluar y qué mecanismos de protección hacen que las puntuaciones sean lo bastante confiables para tomar decisiones?
Si quieres conocer el stack de evaluación más amplio que rodea este tema, el repositorio ya tiene dos artículos complementarios útiles:
- Evaluación de agentes de IA con LangWatch: de las impresiones a las puntuaciones
- Pruebas de skills de agentes de IA con LangWatch Scenario: una guía completa
Este artículo se enfoca en un tema más específico y profundiza en el propio patrón de juez.
TL;DR
- LLM-as-a-judge funciona mejor como una capa de la evaluación de agentes, no como tu única fuente de verdad.
- Es más confiable cuando le pides comparar opciones, calificar según una rúbrica estricta o inspeccionar una traza con evidencia, no cuando le pides opiniones vagas y abiertas.
- Los principales modos de falla son el sesgo de posición, el sesgo hacia el propio modelo o su familia, el sesgo de familiaridad, el sesgo de verbosidad, la sensibilidad al prompt y las limitaciones de los jueces débiles.
- Las soluciones de mayor impacto son invertir el orden, usar rúbricas estructuradas, aplicar verificaciones deterministas a los campos objetivos, evaluar con acceso a las trazas, calibrar con humanos y escalar casos de forma selectiva.
- Mi conclusión desde la ingeniería, a partir de las fuentes: si tu juez no puede ver la evidencia detrás de la respuesta, a menudo está calificando la plausibilidad, no la corrección.
Qué aprenderás aquí
- Qué significa realmente LLM-as-a-judge en el contexto de las aplicaciones de agentes
- Dónde encaja frente a las pruebas unitarias, las pruebas de escenarios, las evaluaciones por lotes y la evaluación de trazas
- Qué patrones de evaluación son más útiles en la práctica
- Qué dice la investigación sobre los sesgos y las inconsistencias comunes de los jueces
- Cómo reforzar el patrón para que PMs e ingenieros puedan usar las puntuaciones sin engañarse
Por qué las aplicaciones de agentes necesitan más que pruebas deterministas
Las pruebas de software tradicionales parten de que, ante la misma entrada, el sistema debe producir la misma salida. Eso sigue siendo importante para las aplicaciones de agentes, pero solo cubre una parte del problema.
Puedes y debes escribir pruebas deterministas para aspectos como:
- esquemas de herramientas
- límites de permisos
- lógica de enrutamiento
- validación de JSON
- consultas de políticas
- manejo de errores
Pero esas pruebas no responden las preguntas que suelen causarles problemas a los equipos de agentes en producción:
- ¿El agente hizo la pregunta de seguimiento correcta?
- ¿Eligió la herramienta correcta por la razón correcta?
- ¿Siguió la política sin dejar de ser útil?
- ¿El prompt más reciente mejoró la experiencia o solo hizo que la respuesta fuera más larga?
Al March 30, 2026, la guía de OpenAI sobre mejores prácticas de evaluación plantea la misma idea central en términos de producto más sencillos: los sistemas generativos son variables, por lo que necesitas evaluaciones diseñadas para esa variabilidad y mantener la concordancia con el juicio humano en lugar de depender de impresiones.
Esa es la brecha que LLM-as-a-judge intenta cubrir.
Dónde encaja LLM-as-a-Judge en el stack de pruebas
Para las aplicaciones de agentes, creo que el modelo mental más claro no es «evaluar todo». Es «usar el juez para las partes que son semánticas y costosas de etiquetar manualmente».
| Capa | Qué responde | Mejor mecanismo |
|---|---|---|
| Pruebas unitarias | ¿La lógica determinista se comportó correctamente? | Pruebas tradicionales |
| Pruebas de escenarios | ¿Puede el agente completar un flujo de trabajo realista de principio a fin? | Simulación de múltiples turnos + aserciones + juez |
| Evaluaciones por lotes | En numerosos ejemplos, ¿el agente está mejorando o empeorando? | Verificaciones deterministas + evaluación con rúbrica |
| Evaluación de trazas | ¿En qué parte del flujo de trabajo se equivocó el agente? | Evaluadores con acceso a trazas de ejecuciones reales |
Al March 30, 2026, la guía de OpenAI sobre evaluaciones de agentes recomienda la evaluación de trazas para detectar errores a nivel del flujo de trabajo. Es un cambio importante. Significa que una conversación más madura ya no se limita a «¿La respuesta final parecía buena?», sino que también pregunta «¿Qué pasó durante la ejecución?».
Esa distinción importa porque muchas fallas de agentes no son puramente textuales:
- selección de la herramienta incorrecta
- selección de la herramienta correcta con parámetros incorrectos
- resultado de la herramienta ignorado
- falta de escalamiento
- evidencia incompleta
Si solo evalúas la respuesta final, a menudo pierdes la información más útil para depurar.
Para qué sirve LLM-as-a-Judge
El artículo de 2023 Evaluación de LLM-as-a-Judge con MT-Bench y Chatbot Arena sigue siendo una de las referencias fundamentales más útiles sobre el tema. Encontró que jueces sólidos como GPT-4 alcanzaron más de 80% de concordancia con las preferencias humanas en esos benchmarks, aproximadamente al mismo nivel que la concordancia entre humanos.
Ese es el resultado optimista, y es importante.
Pero el mismo artículo también señala explícitamente limitaciones, entre ellas:
- sesgo de posición
- sesgo de verbosidad
- sesgo de autopromoción
- capacidad de razonamiento limitada
Así que un resumen justo sería:
Los LLM que actúan como jueces son aproximaciones útiles de las preferencias humanas en algunas tareas de evaluación, no oráculos neutrales.
Eso es suficiente para muchos trabajos de producto, siempre que diseñes teniendo en cuenta sus debilidades.
Patrones de evaluación que mejor funcionan
La guía de evaluación de OpenAI dice que los modelos generalmente son mejores para distinguir entre opciones que para generar juicios abiertos desde cero. Eso coincide con lo que muchos equipos descubren de forma empírica.
Estos son los patrones en los que más confío, ordenados de menor a mayor riesgo.
1. Comparación por pares
Pídele al juez que compare dos resultados candidatos para la misma tarea.
Ejemplo:
- Versión A del prompt frente a versión B del prompt
- Modelo anterior frente a modelo nuevo
- Con mecanismos de protección en la recuperación frente a sin ellos
Este suele ser el mejor patrón para detectar regresiones porque el juez está haciendo una comparación, no inventando un estándar global desde cero.
Mejores casos de uso:
- experimentos con prompts
- cambios de modelo
- clasificación de alternativas
Principal advertencia:
- el orden de las respuestas puede sesgar el resultado, así que siempre prueba ambos órdenes
2. Puntuación basada en rúbricas
Pídele al juez que califique un solo resultado según una rúbrica estructurada con dimensiones explícitas.
Ejemplos de dimensiones:
- sustento factual
- cumplimiento de políticas
- claridad
- exhaustividad
- escalamiento apropiado
Este suele ser el patrón más práctico para los dashboards de producción porque convierte las discusiones subjetivas sobre calidad en un conjunto pequeño de dimensiones repetibles.
Mejores casos de uso:
- revisiones semanales de calidad
- criterios de aprobación para releases
- tarjetas de puntuación para discusiones entre PMs e ingeniería
Principal advertencia:
- las rúbricas vagas producen puntuaciones vagas
3. Aprobación o rechazo de un resultado individual
Pregúntale al juez si un solo resultado cumple un criterio de alcance limitado.
Ejemplo:
- ¿El agente pidió el ID de reserva faltante antes de intentar la cancelación?
- ¿La respuesta se mantuvo dentro de la política de reembolsos?
Esto puede funcionar bien cuando el criterio es concreto y observable.
Mejores casos de uso:
- verificaciones de cumplimiento
- verificaciones acotadas de políticas
- aserciones con un solo objetivo
Principal advertencia:
- las preguntas amplias de aprobación o rechazo suelen ocultar la ambigüedad en lugar de reducirla
4. Evaluación con acceso a la traza
Pásale al juez la traza, no solo la respuesta final:
- entrada del usuario
- herramientas seleccionadas
- argumentos de las herramientas
- resultados de las herramientas
- fragmentos recuperados
- respuesta final
Este es el patrón más importante específicamente para las aplicaciones de agentes.
Un juez con acceso a la traza puede responder preguntas como:
- ¿El agente llamó a la herramienta correcta?
- ¿Ignoró evidencia contradictoria?
- ¿Escaló el caso cuando la política lo exigía?
Eso se acerca mucho más a la forma en que las personas depuran agentes en sistemas reales.
Un ejemplo concreto para un agente de soporte que usa herramientas
A continuación se muestra un patrón de evaluación inspirado en OpenAI, pero independiente del framework. La idea principal es combinar verificaciones deterministas de bajo costo con un juez que aplique una rúbrica más estricta, en lugar de pedirle que haga todo.
from dataclasses import dataclass
@dataclass
class EvalCase:
user_message: str
expected_tool: str
expected_escalation: bool
expected_policy_id: str
def run_support_agent(user_message: str) -> dict:
"""
Returns a trace-like structure:
{
"tool_calls": [...],
"tool_results": [...],
"final_answer": "...",
"escalated": bool,
"policy_id_used": "refund_policy_v3"
}
"""
...
def grade_with_llm(model: str, rubric: str, payload: dict) -> dict:
"""
Ask a judge model to return structured scores.
In production, this can map to your eval platform or internal grader.
"""
...
case = EvalCase(
user_message="I missed the deadline by two days. Can I still get a refund?",
expected_tool="lookup_refund_policy",
expected_escalation=False,
expected_policy_id="refund_policy_v3",
)
trace = run_support_agent(case.user_message)
# Deterministic checks for objective facts
deterministic_scores = {
"correct_tool": int(
any(
call.get("name") == case.expected_tool
for call in (trace.get("tool_calls") or [])
)
),
"correct_policy": int(trace["policy_id_used"] == case.expected_policy_id),
"correct_escalation_flag": int(trace["escalated"] == case.expected_escalation),
}
rubric = """
You are grading a customer-support agent trace.
Return a JSON object only, with no explanations or additional text.
The JSON must have exactly these keys, each mapped to an integer 0 or 1:
- policy_adherence
- user_clarity
- action_reasoning
Output format (example, values may change but structure must not):
{
"policy_adherence": 1,
"user_clarity": 0,
"action_reasoning": 1
}
Rules:
- Use the tool outputs and policy_id_used as evidence.
- Do not reward extra verbosity.
- If the final answer sounds plausible but contradicts the policy evidence,
give policy_adherence = 0.
"""
judge_scores = grade_with_llm(
model="gpt-4.1-mini",
rubric=rubric,
payload={
"user_message": case.user_message,
"tool_calls": trace["tool_calls"],
"tool_results": trace["tool_results"],
"final_answer": trace["final_answer"],
"policy_id_used": trace["policy_id_used"],
},
)
final_scores = {
**deterministic_scores,
**judge_scores,
}El patrón es sencillo:
- deja que el código verifique los hechos objetivos
- deja que el juez califique la calidad semántica
- obliga al juez a revisar la evidencia
Esa separación elimina mucho trabajo innecesario para el juez y hace que sea más fácil confiar en las puntuaciones.
El ciclo de mejora de la evaluación
Este es el flujo de trabajo que recomendaría a la mayoría de los equipos que desarrollan aplicaciones de agentes:
Production runs
|
v
Low-score traces / user complaints / sampled sessions
|
v
Curated eval dataset
|
+--------------------+
| |
v v
Deterministic checks LLM judge rubrics
| |
+---------+----------+
|
v
Compare runs over time
|
v
Update prompts / tools / routing / policies
|
v
Re-run evals before ship
|
v
Back to productionLa idea clave es que LLM-as-a-judge debe formar parte de un ciclo continuo, no ser un benchmark aislado.
Problemas comunes de LLM-as-a-Judge
Aquí es donde la mayoría de los equipos se encuentra con problemas.
1. Sesgo de posición
El artículo Los modelos de lenguaje grandes no son evaluadores justos mostró que las clasificaciones se pueden manipular cambiando el orden en que aparecen las respuestas candidatas. En otras palabras, las mismas dos respuestas pueden producir resultados distintos según cuál se muestre primero.
No es un caso marginal académico sin importancia. Afecta directamente a cualquier configuración de evaluación por pares.
Implicación práctica: si comparas el prompt A y el prompt B una sola vez, tu tabla de clasificación podría reflejar en parte el orden de presentación.
2. Sesgo de preferencia propia y sesgo hacia la misma familia
El artículo Sesgo de preferencia propia en LLM-as-a-Judge encontró que los jueces pueden preferir resultados que les resultan más familiares, y los autores relacionan gran parte de ese efecto con una menor perplejidad. El artículo Reemplazar jueces por jurados plantea una idea relacionada desde la perspectiva de sistemas: un único juez grande puede introducir sesgo dentro del modelo, y un panel diverso de jueces más pequeños puede reducir ese sesgo y, al mismo tiempo, bajar los costos.
En la práctica, los equipos suelen describir esto como un problema de sesgo hacia la misma familia:
- una familia de modelos prefiere su propio estilo
- un juez recompensa en exceso el tono o el formato que prefiere
- un modelo que suena «más como el juez» recibe puntos adicionales
Implicación práctica: si la misma familia de modelos genera y evalúa, tus evaluaciones podrían recompensar la familiaridad estilística en lugar del valor para el usuario.
3. Sesgo de familiaridad
El artículo Los modelos de lenguaje grandes son evaluadores inconsistentes y sesgados encontró sesgo de familiaridad, distribuciones de calificaciones sesgadas, efectos de anclaje y sensibilidad a cambios en el prompt que los humanos no considerarían significativos.
Esto importa porque muchos equipos de producto ajustan constantemente la redacción. Si la puntuación del juez cambia mucho porque su prompt se modificó ligeramente, podrías pensar que mejoraste el producto cuando en realidad cambiaste el instrumento de medición.
Implicación práctica: un juez cuyas puntuaciones varían puede crear falsas regresiones y falsas mejoras.
4. Sesgo de verbosidad y estilo
El artículo de MT-Bench menciona explícitamente el sesgo de verbosidad. Es el problema clásico en el que una respuesta más larga parece más impresionante incluso cuando no es más correcta.
Esto es especialmente peligroso en las revisiones de PMs porque visualmente es fácil confundir «suena mejor» con «es mejor».
Implicación práctica: si tu juez recompensa en exceso las respuestas largas, los equipos podrían optimizar la redacción para impresionar en lugar de completar la tarea.
5. Evaluación sin evidencia y confianza alucinada
Este problema está documentado en parte y también se deriva, como inferencia de ingeniería, de cómo la evaluación de trazas cambia el problema.
La guía de OpenAI sobre evaluación de trazas sostiene que la evaluación de caja negra pierde la información necesaria para entender por qué un agente tuvo éxito o falló. Estoy totalmente de acuerdo.
Mi inferencia a partir de las fuentes y de la experiencia en producción es:
Cuando un juez solo ve la respuesta final, a menudo no puede verificar si es correcta en términos factuales. Solo puede verificar si parece plausible.
En las aplicaciones de agentes, esto genera un modo de falla predecible:
- el agente usó la herramienta incorrecta
- la respuesta sigue sonando bien elaborada
- el juez le da una puntuación aceptable
No se trata solo de una alucinación del generador. También es una especie de confianza alucinada en el evaluador.
6. Jueces débiles frente a agentes sólidos
El artículo Sobre la supervisión escalable con LLM débiles que evalúan LLM sólidos explora qué sucede cuando jueces más débiles supervisan agentes más sólidos en tareas como matemáticas, programación, lógica y razonamiento multimodal. La respuesta tiene matices, pero la lección general es sencilla: los jueces más débiles no ofrecen supervisión gratuita. Su confiabilidad depende de la tarea y del protocolo.
El artículo Confiar o escalar es útil aquí porque propone una respuesta más operativa: cuando la confianza es baja, escala el caso a humanos o a una revisión más rigurosa en lugar de fingir que la puntuación es igual de confiable en todos los ejemplos.
Implicación práctica: el juez más barato no siempre es el más seguro, especialmente en tareas de razonamiento difíciles.
Soluciones que hacen viable el patrón
La buena noticia es que la mayoría de los problemas más importantes de los jueces tienen soluciones prácticas y poco espectaculares.
1. Invierte el orden y agrega los resultados de ambos sentidos
Si haces comparaciones por pares, evalúa ambos órdenes:
- A frente a B
- B frente a A
Luego agrega los resultados.
Esta es la defensa mínima contra el sesgo de posición y está directamente alineada con las ideas de mitigación de Los modelos de lenguaje grandes no son evaluadores justos.
2. Usa rúbricas estructuradas, no prompts vagos
En lugar de:
¿Esta respuesta es buena?
Usa:
policy_adherencegrounded_in_retrieved_contextrequested_missing_info_before_actionescalated_when_required
Esto no elimina el sesgo, pero facilita detectarlo y discutirlo.
3. Mantén deterministas las verificaciones objetivas
No uses un LLM como juez para hechos que puedes calcular directamente.
Buenas verificaciones deterministas:
- se seleccionó exactamente la herramienta correcta
- el argumento requerido de la herramienta está presente
- el resultado se puede analizar según el esquema
- la versión de la política coincide con la esperada
- el indicador de escalamiento coincide con lo esperado
Reserva el juez para preguntas que los humanos también evaluarían semánticamente.
4. Proporciona evidencia o trazas, no solo el texto final
Si quieres evaluar:
- sustento factual
- uso correcto de herramientas
- escalamiento correcto
- cumplimiento de políticas
entonces el juez debe ver el rastro de evidencia.
Eso significa proporcionarle:
- fragmentos recuperados
- llamadas a herramientas
- resultados de herramientas
- IDs de políticas
- artefactos intermedios de razonamiento cuando corresponda
Precisamente por eso la evaluación con acceso a trazas aporta más información que la evaluación exclusiva del resultado.
5. Calibra con evaluaciones humanas
La guía de OpenAI sobre mejores prácticas de evaluación recomienda explícitamente mantener la concordancia con la retroalimentación humana. Eso no debe considerarse opcional.
Un flujo de trabajo saludable se ve así:
- toma una muestra de los casos de evaluación
- pide a personas que los etiqueten
- compara las etiquetas del juez con las humanas
- revisa la rúbrica o el modelo juez si la concordancia es baja
Sin ese ciclo, es fácil optimizar para un juez con el que tus usuarios no estarían de acuerdo.
6. Usa jurados de modelos de distintas familias cuando el sesgo importe
El artículo Reemplazar jueces por jurados es especialmente práctico para los equipos preocupados por el sesgo de familia de modelos. Su resultado sugiere que un panel de jueces más pequeños y diversos puede superar a un único juez grande y reducir el sesgo dentro del modelo, además de costar menos.
Eso no significa que todos los equipos necesiten un jurado de modelos desde el primer día.
Sí significa que, si tus evaluaciones sirven para tomar decisiones costosas:
- migraciones de modelos
- criterios de aprobación para releases
- puntuaciones relacionadas con requisitos de cumplimiento
- cambios importantes en las políticas de prompts
un panel de distintas familias suele ser un diseño más inteligente que un único juez favorito.
7. Escala los casos inciertos
No todos los casos merecen el mismo nivel de automatización.
Si un juez no está seguro, si dos jueces discrepan o si el caso afecta un área de políticas de alto riesgo, escálalo. Ese es el espíritu operativo detrás de Confiar o escalar: no fuerces la automatización completa cuando la confianza es baja.
En sistemas reales, puede ser tan sencillo como:
- enviar las evaluaciones de baja confianza a revisión humana
- exigir que dos jueces coincidan en los casos críticos para un release
- dirigir las regresiones relacionadas con políticas a un experto en el dominio
Una lista práctica para la implementación
Si tu equipo quiere adoptar LLM-as-a-judge sin crear una trampa de medición, yo empezaría por aquí:
- Mantén las pruebas unitarias para la lógica determinista.
- Usa pruebas de escenarios para flujos de trabajo realistas de múltiples turnos.
- Agrega evaluaciones basadas en jueces para la calidad semántica, no para hechos objetivos.
- Empieza con una rúbrica acotada en un flujo de trabajo crítico.
- Para las evaluaciones por pares, califica siempre ambos órdenes de respuesta.
- Proporciona trazas o evidencia cuando la corrección dependa de herramientas o de recuperación.
- Calibra las puntuaciones de los jueces con etiquetas humanas antes de usarlas como criterios de aprobación para releases.
- Usa primero un juez más barato, pero escala los casos difíciles a jueces más sólidos o a humanos.
- Si el sesgo hacia la misma familia importa, prueba un pequeño jurado de distintas familias.
- Trata los prompts de los jueces como código: versiónalos, revísalos y vuelve a validarlos después de cada cambio.
La conclusión de fondo
LLM-as-a-judge no es una ficción, pero tampoco es suficiente por sí solo.
La investigación respalda una visión equilibrada:
- los jueces sólidos pueden ser realmente útiles
- algunas tareas de evaluación son mucho más confiables que otras
- los modos de falla ya son lo bastante conocidos como para que los equipos los contemplen desde el principio
Mi recomendación práctica para ingenieros y PMs es:
Usa jueces para escalar la evaluación, no para reemplazar el criterio.
Eso significa:
- mantener las verificaciones deterministas siempre que sea posible
- hacer que los jueces comparen o califiquen según criterios explícitos
- darles evidencia
- medir su concordancia con los humanos
- escalar los casos inciertos en lugar de ocultarlos en una puntuación promedio
Si haces eso, LLM-as-a-judge se convierte en un muy buen compañero de equipo.
Si no lo haces, se convierte en un generador de hojas de cálculo muy convincente.
Fuentes
- Documentación de la API de OpenAI — Mejores prácticas de evaluación — Guía de producto sobre el diseño de evaluaciones específicas para cada tarea, la calibración con humanos y por qué la comparación por pares y la puntuación estructurada suelen ser más confiables que los juicios abiertos y vagos. Consultado el March 30, 2026.
- Documentación de la API de OpenAI — Evaluaciones de agentes — Guía actual de la plataforma sobre la evaluación reproducible de agentes y cuándo usar herramientas de evaluación a nivel de flujo de trabajo. Consultado el March 30, 2026.
- Documentación de la API de OpenAI — Evaluación de trazas — Explica por qué evaluar trazas completas aporta más valor diagnóstico que las verificaciones de resultados de caja negra para sistemas de agentes. Consultado el March 30, 2026.
- Evaluación de LLM-as-a-Judge con MT-Bench y Chatbot Arena — Encontró que los jueces sólidos pueden coincidir bien con las preferencias humanas en algunos benchmarks, y también documentó el sesgo de posición, el sesgo de verbosidad, el sesgo de autopromoción y los límites de razonamiento.
- Los modelos de lenguaje grandes no son evaluadores justos — Muestra los efectos del orden en la evaluación por pares y propone estrategias de mitigación, incluidas la calibración equilibrada de posiciones y la revisión con intervención humana.
- Los modelos de lenguaje grandes son evaluadores inconsistentes y sesgados — Documenta el sesgo de familiaridad, las distribuciones de calificaciones sesgadas, los efectos de anclaje y la sensibilidad al prompt en los LLM evaluadores.
- Sesgo de preferencia propia en LLM-as-a-Judge — Analiza cómo los jueces pueden preferir resultados que les parecen más familiares y relaciona ese sesgo con la perplejidad.
- Reemplazar jueces por jurados: evaluación de generaciones de LLM con un panel de modelos diversos — Propone paneles diversos de jueces como una forma de reducir el sesgo dentro del modelo y los costos.
- Sobre la supervisión escalable con LLM débiles que evalúan LLM sólidos — Explora los límites de los jueces más débiles que supervisan sistemas más sólidos en varios tipos de tareas.
- Confiar o escalar: LLM jueces con garantías demostrables de concordancia humana — Referencia útil para el escalamiento selectivo y el diseño de evaluaciones que tienen en cuenta la confianza.