Modelo como juez (LLM-as-a-judge): qué evalúa y qué sesgos hay que comprobar

Definición: qué es un modelo como juez

Un modelo como juez es un modelo de lenguaje empleado para evaluar una respuesta, una salida o el comportamiento de una aplicación de IA mediante criterios especificados de antemano. Puede, por ejemplo, asignar una puntuación, clasificar el resultado o comparar dos alternativas. El término inglés habitual es LLM-as-a-judge.

El objeto evaluado no tiene por qué ser únicamente un texto. Según el uso, puede ser la respuesta de un chatbot, un resumen, una salida generada por una herramienta o la traza de acciones de un agente. La evaluación también puede considerar información de referencia, como la pregunta original, un documento fuente, una política o una lista de restricciones.

La expresión describe un método de evaluación, no una garantía de exactitud. El juicio producido sigue siendo una salida de un modelo: depende de qué se le pide que examine, de los criterios que recibe y de la información disponible. Por tanto, una puntuación automatizada no equivale por sí sola a una verdad comprobada, a una etiqueta de referencia independiente ni a una revisión humana.

La guía de Langfuse define el método, en su alcance operativo, como el uso de un modelo de lenguaje para evaluar la calidad de las salidas de otra aplicación basada en LLM. La documentación de MLflow incluye tanto aplicaciones LLM como agentes y enumera dimensiones de calidad posibles, entre ellas corrección, relevancia, fundamentación, seguridad y utilidad. Estas descripciones ayudan a entender el uso, pero no convierten una herramienta concreta en una definición universal.

Cómo funciona el proceso

Un flujo de evaluación razonable empieza por definir qué se quiere juzgar y con qué propósito. No es lo mismo comprobar si una respuesta respeta una política que valorar si resulta clara para una persona. Si el objetivo queda ambiguo, el modelo puede responder con una valoración aparentemente precisa que no corresponda a la necesidad real.

Después se concretan los criterios. Una rúbrica puede describir dimensiones separadas, como fidelidad a una fuente, cobertura de información, cumplimiento de restricciones o relevancia. También puede definir una escala y explicar qué significa cada nivel. La rúbrica no elimina el desacuerdo, pero hace explícito qué se espera que valore el juez.

A continuación se le presenta el material pertinente: la respuesta o traza evaluada y, cuando haga falta, la pregunta, el documento de referencia, las reglas vigentes o las restricciones de la tarea. El contexto debe ser suficiente para aplicar el criterio, pero la ficha no asume que añadir más información siempre mejore el juicio: conviene comprobar qué contexto necesita realmente la tarea.

La instrucción de evaluación especifica el papel del juez y el formato de salida. El resultado puede incluir una puntuación, una categoría, una preferencia entre opciones y una explicación. Por último, se revisa el juicio: se buscan errores, se contrasta con evaluadores humanos o referencias externas cuando sea posible, y se decide si el resultado es adecuado para el uso previsto. Que el juez genere una justificación no demuestra por sí solo que esa justificación sea correcta.

Formas de juicio: puntuación, clasificación y comparación

En una puntuación según criterios, el juez valora una respuesta de forma individual, por ejemplo, en una escala definida por el equipo. La escala solo es interpretable si se conoce qué representa cada valor. Una puntuación de calidad global puede ocultar que una respuesta es fiel pero incompleta, o completa pero contraria a una restricción; separar dimensiones puede hacer más legible ese tipo de compensación.

En una clasificación, el juez asigna una categoría, como «cumple», «no cumple» o «requiere revisión». También puede ordenar varias respuestas en grupos o niveles. Las categorías reducen la apariencia de precisión numérica, pero todavía dependen de definiciones claras y de que el modelo aplique esas definiciones de manera adecuada.

En una comparación por pares, se presentan dos alternativas y se pide elegir cuál satisface mejor un criterio, o declarar un empate si el formato lo permite. El resultado es relativo: que una opción sea preferida no demuestra que sea correcta ni que cumpla un umbral absoluto. Además, la comparación responde a la pareja presentada; no establece automáticamente un orden fiable para todas las respuestas posibles.

Estos formatos son distintos y responden a preguntas diferentes. Una puntuación intenta expresar el desempeño frente a una escala; una categoría asigna una etiqueta; una comparación indica una preferencia entre opciones. No se debe asumir que uno sea siempre superior. La elección depende de la decisión que se tomará y debe probarse con ejemplos representativos.

Ejemplo aplicado: respuestas de atención al cliente

Supongamos que un equipo quiere revisar respuestas de un asistente de atención al cliente. El objeto de evaluación es cada respuesta; el contexto pertinente puede incluir la consulta de la persona y la versión vigente de la política aplicable. Una rúbrica podría separar, como mínimo, si la respuesta aborda la consulta, si coincide con la política proporcionada y si respeta las restricciones de comunicación definidas por el equipo.

El juez podría clasificar cada dimensión o asignar puntuaciones separadas y marcar los casos dudosos para revisión. Por ejemplo, si la respuesta promete una devolución, el criterio no debería ser que la promesa suene razonable: debe comprobarse contra la política que se le proporcionó. La valoración del modelo indica cómo interpretó el material; no sustituye la comprobación de que la política está actualizada ni la decisión sobre qué regla debe aplicarse.

Para evaluar el método, el equipo puede seleccionar casos que cubran distintas consultas y excepciones, comparar los juicios con revisiones humanas y examinar desacuerdos. Si el sistema se utiliza para priorizar revisiones, conviene comprobar también si identifica los casos que el equipo considera sensibles o inciertos. Esta propuesta es una pauta de diseño: las fuentes disponibles no permiten afirmar que un juez vaya a coincidir con especialistas en todos los casos.

Ejemplo aplicado: resúmenes de documentos

Para comparar resúmenes, el objeto evaluado es el resumen y el contexto de referencia es el documento original, junto con la instrucción que pidió resumirlo. Los criterios podrían distinguir cobertura de los puntos relevantes y fidelidad de las afirmaciones al texto fuente. Mantener esas dimensiones separadas ayuda a evitar que una prosa fluida se confunda con un resumen completo o fiel.

Un juez podría puntuar cada resumen individualmente o comparar dos resúmenes para determinar cuál cubre mejor los contenidos relevantes sin introducir afirmaciones no respaldadas. La revisión debería comprobar si la valoración señala omisiones concretas o afirmaciones incompatibles con el documento, en vez de basarse únicamente en una explicación genérica como «es más completo».

La elección de qué información cuenta como relevante depende de la tarea: un resumen ejecutivo, uno técnico y uno destinado a una consulta concreta pueden requerir coberturas distintas. Por eso, el documento fuente y el propósito del resumen deben estar disponibles para el evaluador. La puntuación del juez no es en sí misma una lista verificada de hechos omitidos o inventados.

Ejemplo aplicado: agentes de programación

En la evaluación de un agente de programación, el objeto puede incluir el resultado final y la traza de acciones, no solo el texto de la respuesta. La tarea, las pruebas disponibles y las restricciones definen qué significa completar el trabajo. Entre los criterios explícitos podrían estar resolver la tarea solicitada y respetar límites como no modificar ciertos archivos o no usar una herramienta determinada, si esas restricciones forman parte del encargo.

Un juez puede valorar cada criterio, resumir qué evidencia de la traza parece respaldarlo o indicar que no puede decidir con la información disponible. El equipo debe comprobar si el juicio se corresponde con el resultado verificable. Por ejemplo, una explicación convincente de que se completó una tarea no reemplaza la ejecución de pruebas; a la vez, superar una prueba aislada no demuestra necesariamente que se hayan respetado todas las restricciones.

Este ejemplo muestra por qué el objeto de evaluación debe definirse con cuidado: juzgar únicamente la respuesta textual puede omitir acciones relevantes, y juzgar solo una traza sin sus restricciones puede llevar a una valoración incompleta. Qué evidencias son suficientes dependerá del entorno y de la tarea concreta.

Qué conviene comprobar antes de confiar en un juez

Una comprobación central es la correspondencia entre los juicios del modelo y una referencia apropiada para la tarea. Esa referencia puede consistir en evaluaciones humanas, reglas verificables o resultados externos, según qué se esté midiendo. No basta con obtener un porcentaje general de coincidencia si no se sabe qué casos se evaluaron, cómo se resolvieron los desacuerdos y si los ejemplos representan el uso previsto.

También conviene probar la estabilidad del proceso. Si se presenta el mismo caso más de una vez, ¿el juicio se mantiene lo suficiente para la decisión prevista? ¿Cambian las valoraciones al modificar elementos no relevantes de la presentación? En comparaciones por pares, se debe examinar si invertir el orden de las alternativas cambia la preferencia. Estas son preguntas de validación, no afirmaciones de que el cambio ocurra siempre.

La justificación merece una revisión independiente. Una explicación puede ser útil para localizar qué criterio aplicó el modelo, pero no constituye una prueba de que la puntuación sea correcta. Se pueden contrastar las razones con el material de entrada y comprobar si apuntan a evidencia pertinente o si son vagas, incompatibles con el resultado o no respaldadas por la fuente.

Por último, hay que valorar la adecuación del juez a la tarea. Un modelo capaz de evaluar un tipo de respuesta no queda validado automáticamente para otro dominio, otro idioma, otro formato de entrada o una decisión con consecuencias distintas. Una encuesta técnica sobre LLM-as-a-judge presenta el campo como el uso de modelos de lenguaje para evaluar tareas complejas; la descripción disponible también menciona instrucciones y ejemplos para especificar tareas. Eso no establece por sí solo que un método concreto sea fiable en cada aplicación.

Conceptos próximos y confusiones frecuentes

Un benchmark es un conjunto organizado de tareas o casos usado para medir o comparar sistemas bajo condiciones definidas. Un modelo como juez, en cambio, es un método para asignar valoraciones a salidas. Un benchmark puede incorporar un juez, pero ambos términos no significan lo mismo: el conjunto de evaluación define qué casos se prueban; el juez produce o participa en los juicios.

Una rúbrica es una especificación de criterios, niveles o reglas de valoración. No es necesariamente un modelo ni un resultado. El juez puede recibir una rúbrica para orientar su evaluación, pero disponer de una rúbrica no garantiza que la aplique correctamente.

La puntuación de un juez tampoco equivale a una etiqueta de referencia o a la verdad del caso. Una respuesta puede obtener una puntuación alta y aun así contener un error que la rúbrica no detectó o que el evaluador interpretó mal. Cuando existe una comprobación directa —por ejemplo, una regla verificable o un resultado de prueba— conviene no reemplazarla sin validación por una opinión generada.

Por último, hay que distinguir el modelo evaluador del modelo evaluado. En una aplicación puede ser el mismo tipo de sistema o pueden ser modelos distintos, pero sus funciones son diferentes en el proceso: uno genera la respuesta o ejecuta la tarea; el otro emite un juicio sobre esa salida. Y «juicio automatizado» no significa «sin supervisión humana»: la revisión humana puede ser necesaria para validar el método, resolver excepciones o tomar decisiones relevantes.

Límites y criterios prácticos de uso

El juicio depende de la definición de la tarea, los criterios y el contexto suministrado, además del comportamiento del modelo evaluador. Por eso, una evaluación automatizada debería describirse con suficiente detalle para que otras personas entiendan qué se juzgó, con qué instrucciones y qué salida produjo el juez. La documentación de herramientas puede ofrecer formatos operativos y dimensiones de evaluación, pero las recomendaciones de una plataforma no constituyen por sí solas evidencia de que ese diseño funcione en cualquier aplicación.

Antes de adoptar el método, conviene preguntar: ¿el criterio representa una necesidad real del producto o solo una aproximación fácil de puntuar? ¿Hay casos de referencia adecuados? ¿Se sabe cómo tratar desacuerdos y resultados inciertos? ¿Se ha probado la sensibilidad a cambios de presentación? ¿La decisión puede contrastarse con una comprobación externa? Las respuestas ayudan a delimitar dónde el juez sirve como apoyo y dónde hace falta revisión adicional.

También es útil empezar con un uso acotado y reversible, analizar ejemplos de aciertos y errores, y volver a evaluar el método cuando cambien las políticas, los datos, las instrucciones o el modelo. Esto es una recomendación práctica, no una garantía de que la evaluación permanezca estable. La extensión de la revisión humana debe depender de la relevancia de la decisión, de las consecuencias de un error y de la evidencia obtenida para esa tarea.

Para continuar, pueden consultarse las fichas de evaluación de IA, benchmark, rúbrica y humano en el circuito, además de la entrada de **juez LLM** y los criterios de **comparación de modelos**. Estos conceptos se relacionan, pero no son intercambiables.

En síntesis, un modelo como juez sirve para estructurar o automatizar una parte del trabajo de evaluación cuando los criterios y el objeto están claros. Su resultado debe leerse como un juicio producido por un modelo y comprobarse para el uso previsto. La decisión práctica no es si un juez es fiable en abstracto, sino qué evidencia respalda su empleo para una tarea, unos datos y unas consecuencias concretas.

Conceptos relacionados