Automated Graders
Juzgar resultados mediante mecanismos automáticos
Un Automated Grader produce un juicio, score, label o decisión de evaluación mediante reglas, comparaciones, ejecución, métricas o modelos, según criterios definidos para una tarea. Automatizar el juicio puede aumentar velocidad y cobertura, pero no garantiza que el criterio sea válido ni que el grader entienda la propiedad que el equipo necesita medir.
El grader debe recibir el caso y el resultado en una forma suficiente para emitir su juicio. En una tarea de extracción puede comparar una estructura; en una tarea de coding puede ejecutar tests o examinar el estado; en una respuesta abierta puede aplicar una rúbrica mediante un modelo. La elección depende del objetivo, el costo de error y la posibilidad de obtener un oráculo confiable.
Automated Grader no equivale a LLM-as-Judge. LLM-as-Judge es un subtipo que usa un modelo de lenguaje para juzgar; también existen checks exactos, reglas, métricas, ejecución y modelos no generativos. Una comprobación programática puede ser más apropiada cuando el requisito es preciso, mientras un judge puede ayudar cuando la calidad es semántica y difícil de formalizar.
Graders deterministas
Los graders deterministas pueden usar exact match, validación de schema, comparación estructural, regex, reglas, unit tests, ejecución exitosa, estado de un entorno o una condición de política. Son útiles cuando el criterio está definido de manera observable y el costo de una decisión falsa es importante. Un resultado repetible bajo las mismas condiciones facilita diagnosticar cambios.
Determinista no significa semánticamente completo. Un JSON puede cumplir un schema y contener una conclusión equivocada; un test puede verificar una ruta sin cubrir otra; una regex puede detectar una forma y perder una reformulación. La propiedad que el grader comprueba debe permanecer explícita. Repetir un check no amplía automáticamente su alcance.
Los graders basados en referencias exactas también necesitan cuidar normalización y equivalencias válidas. Penalizar una respuesta correcta por usar otra formulación mide estilo o coincidencia textual, no necesariamente correctness. Cuando el dominio admite múltiples salidas, el grader debe comparar propiedades o utilizar otra forma de juicio.
Métricas y heurísticas
Un grader puede calcular similitud, ranking, precisión, recall, cobertura, longitud, latencia, costo o una métrica específica de la tarea. Estas señales ayudan a ordenar o resumir resultados, pero metric score no equivale a task truth. Una métrica de similitud puede premiar texto compartido aunque falte una condición; una métrica de ranking puede no observar el valor de una respuesta generada.
Las heurísticas pueden combinar señales, umbrales y metadata. Su utilidad depende de calibración sobre casos representativos y de una política para incertidumbre. Un umbral ajustado sobre una suite pequeña puede funcionar en esa suite y degradar fuera de ella. El equipo debe conservar qué casos influyeron el umbral y qué errores son aceptables o críticos.
Graders basados en modelos
Un modelo puede juzgar correctness, relevance, style, policy, preference, grounding o satisfacción de una rúbrica. Puede leer una respuesta junto con la consulta y referencias, asignar una escala, elegir entre candidatos o explicar un fallo. Su flexibilidad es valiosa cuando reglas exactas no capturan bien la tarea, pero agrega otra capa probabilística que también necesita evaluación.
El grader-model puede ser sensible al prompt, al formato, al orden, al idioma, a la longitud y a la elección de referencia. Puede preferir una respuesta más extensa, imitar una conclusión del input o aceptar una afirmación fluida sin evidencia. La explicación que produce puede ayudar a investigar, pero no debe tratarse automáticamente como una prueba independiente del score.
Un modelo judge puede ser el mismo modelo evaluado, otra versión o un proveedor diferente. Ninguna elección garantiza independencia. Un judge de la misma familia puede compartir capacidades y sesgos; uno distinto puede introducir sus propios límites. La decisión debe describir qué relación existe entre generator y grader en lugar de reclamar neutralidad por usar dos nombres de modelo.
LLM-as-Judge
LLM-as-Judge es el uso de un modelo de lenguaje para evaluar otra salida o interacción según una pregunta, criterios o rúbrica. Puede producir un score de una sola respuesta, una comparación pairwise, un ranking o un juicio rubric-based. Es una forma de Automated Grader, no una categoría que sustituya a todos los graders.
Un prompt de judge debe precisar objeto, criterio, escala, evidencia disponible y tratamiento de incertidumbre. En una comparación pairwise conviene definir qué significa «mejor» y qué hacer cuando ambas respuestas fallan o son incomparables. En una rúbrica interesa separar dimensiones para evitar que una impresión global o la fluidez domine correctness o groundedness.
El judge debe recibir solo la información que corresponde al criterio. Incluir la respuesta de referencia de manera que revele la label, mezclar instrucciones del grader con contenido no confiable o mostrar metadata que no estaría disponible en el uso real puede inflar el score. Las condiciones del judge forman parte del experimento y deben versionarse.
El formato de salida del judge también necesita un contrato. Un score debe pertenecer a la escala definida, una explicación debe distinguir evidencia de inferencia y un estado incierto no debe convertirse silenciosamente en cero o en pass. Un parser puede comprobar la forma del juicio, pero la forma válida no demuestra que la razón sea pertinente. Si el judge produce una recomendación para otra etapa, esa etapa debe decidir qué autoridad tiene realmente.
Sesgos y sensibilidad
Los graders model-based pueden mostrar position u order bias, preferir una opción presentada primero, favorecer verbosity o estilo, mostrar self-preference o model-family preference, depender del wording del prompt o aceptar una referencia que contiene el mismo error. Estos riesgos son posibles patrones a investigar, no defectos que deban presumirse idénticos en toda tarea.
La respuesta útil es diseñar pruebas de sensibilidad: cambiar el orden de opciones, variar redacción sin cambiar la propiedad, ocultar información irrelevante, incluir respuestas breves y largas con igual calidad, y comparar con casos donde la referencia sea incompleta. Si el score cambia sin que cambie el criterio, el grader está midiendo algo adicional que debe hacerse visible.
El judge también puede ser inconsistente entre ejecuciones. Repetirlo puede ayudar a observar variación, pero no transforma decisiones arbitrarias en verdad. Para un gate crítico puede ser preferible combinar un check determinista, revisión humana o una política conservadora antes que tomar el promedio de varios juicios frágiles.
Calibración y fiabilidad
Calibrar un grader significa contrastarlo con juicios de referencia o con casos diseñados para conocer sus límites. Puede examinarse agreement, consistencia, correlación con humanos, false positives, false negatives, sensibilidad por subgrupo y error por tipo de tarea. Acordar con otro grader imperfecto no demuestra corrección: dos mecanismos pueden compartir el mismo sesgo.
La fiabilidad depende del propósito. Un grader puede ser suficientemente consistente para ordenar candidatos y no ser confiable para decidir un gate de seguridad. Puede detectar formato con gran precisión y juzgar groundedness de manera débil. El resultado debe reportar la propiedad y el alcance evaluados, no resumir todo como «grader quality».
La selección de muestras afecta la conclusión sobre fiabilidad. Medir solo casos fáciles puede hacer parecer consistente a un grader que falla en ambigüedad, idiomas o subpoblaciones. Conviene conservar casos positivos, negativos, frontera, disagreement y ejemplos donde una señal superficial contradiga el criterio. Una muestra de control revisada por humanos puede detectar degradación del grader, pero no elimina la necesidad de analizar qué casos quedaron fuera.
Los casos de calibración deben mantenerse separados de los casos utilizados para ajustar el prompt o el threshold, cuando sea posible. Si el equipo cambia el judge cada vez que contradice una expectativa y vuelve a medir sobre los mismos ejemplos, puede producir una falsa mejora. Versionar grader, rúbrica, referencias y dataset permite reconstruir la evolución.
Grader y Guardrail
AI Guardrails toma una decisión de control durante una ejecución: permitir, rechazar, transformar, pausar o escalar una entrada, salida o acción. Automated Grader mide o juzga para una evaluación. Un mecanismo de grader puede participar dentro de un guardrail, pero el propósito, el momento y las consecuencias son diferentes.
Un score bajo en una evaluación no bloquea automáticamente la producción, y un guardrail que deja pasar una salida no demuestra que sea correcta. Confundir ambos puede convertir una métrica incompleta en permiso de runtime o exigir que toda evaluación tenga efectos operativos. La integración debe declarar qué señal se reutiliza y qué control externo aplica la decisión.
Grader y Human Evaluation
Human Evaluation aporta juicio humano estructurado sobre casos. Puede servir para calibrar un grader, revisar una muestra, resolver desacuerdos o evaluar propiedades que un mecanismo automático no captura bien. Un grader automático no es un sustituto universal: la automatización puede ampliar escala, mientras la revisión humana aporta interpretación y detecta fallos de criterio.
La combinación necesita una política. Se puede enviar a humanos casos inciertos, discrepancias entre graders, clases de alto impacto o una muestra de control. El resultado humano tampoco es verdad infalible: necesita rubrica, contexto, selección de evaluadores y análisis de acuerdo. La finalidad es componer señales con límites visibles.
Ejecución, referencias y evidencia
Un grader puede observar texto, estructura, tool calls, trazas, estado de ambiente o efectos. Para tareas con ejecución, comprobar solo la respuesta final puede perder una escritura no autorizada, una herramienta irrelevante o un estado parcial. Para tareas abiertas, una referencia literal puede no expresar todas las respuestas válidas. El oráculo debe corresponder al objeto evaluado.
La evidencia del grader debe conservar caso, versión del sistema, versión del grader, criterios, resultado y errores. Un timeout del grader no es necesariamente pass ni fail del sistema; debe tener un estado explícito. Si la ejecución externa tuvo efectos, el grader debe distinguir fallo del control de fallo de la tarea. Ocultar estados inciertos produce una tasa artificialmente limpia.
Los graders de ejecución deben aislar, cuando sea posible, el efecto de evaluar. Ejecutar una acción para comprobar si el sistema sabe usar una herramienta puede modificar datos, consumir recursos o crear un resultado que influye en la siguiente prueba. Un sandbox, fixture, simulador o rollback puede reducir ese efecto, pero cada mecanismo aporta garantías diferentes. La evaluación debe indicar si el entorno era solo lectura, efímero o compartido.
Los fallos del propio grader necesitan clasificación. Puede fallar el parsing, faltar una referencia, expirar un servicio, quedar inconsistente el entorno o producir una decisión fuera de escala. Mezclar esos estados con una respuesta mala atribuye al sistema un problema del evaluador; tratarlos como pass oculta un vacío. Una suite madura conserva errores del grader y define cuándo repetir, derivar a una persona o retirar el caso de la agregación.
Costos y límites
Automatizar reduce tiempo humano por caso, pero puede aumentar llamadas de modelos, infraestructura, debugging y mantenimiento de rubrics. Un judge más capaz puede costar más y tener otra latencia. Un programa que califica todo con un modelo puede perder reproducibilidad o hacer que un cambio de proveedor altere la serie histórica.
No existe un grader universal. Exact checks son preferibles cuando el requisito es exacto; modelos pueden ayudar con semántica abierta; humanos pueden ser necesarios para criterios de alto impacto o ambigüedad. La elección debe seguir la decisión, el riesgo y la evidencia disponible, no la novedad del mecanismo.
Un pipeline puede combinar graders por capas: primero un check estructural barato, luego una comparación de contenido y finalmente una revisión de casos inciertos. Esa composición puede ahorrar recursos y mejorar diagnóstico, pero un gate posterior no repara una omisión anterior. Debe quedar claro qué casos llegan a cada capa y si una decisión temprana descarta evidencia que otro grader habría necesitado.
Los scores de graders diferentes no son necesariamente comparables. Una escala de uno a cinco puede tener anclajes distintos, un threshold puede depender del dataset y una métrica puede crecer cuando otra empeora. Antes de promediar o construir un ranking compuesto conviene definir qué significa cada señal, cómo se normaliza y qué trade-off representa. Una cifra agregada sin contrato semántico puede dar una ilusión de precisión.
Fuentes y alcance
Fuentes consultadas: OpenAI Evals, Anthropic, Demystifying evals for AI agents, y Google Cloud generative AI evaluation. Este canonical agrupa LLM-as-Judge y no materializa un documento separado para ese subtópico.