Evaluación de AI agents en producción: de las trazas a las suites de tests

Viacheslav Dubrov

2026-06-10 · Actualizado 2026-09-06 · 30 min · Agentes de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Actualización del artículo

Publicado originalmente el 10 de junio de 2026. Revisado y actualizado el 6 de septiembre de 2026. La actualización cubre benchmarks de agents más recientes, revisiones de graders y evidencias sobre cómo la infraestructura afecta a las puntuaciones.

Una respuesta final puede afirmar que un reembolso se ha completado mientras la traza muestra que verify_identity nunca se ejecutó, que issue_refund se reintentó 17 veces o que el agent declaró el éxito antes de que cambiase la base de datos. Evaluar solo la respuesta oculta esos fallos.

Para los ingenieros que operan agents con tool use en producción, la solución es convertir las trazas repetibles en casos de regresión acotados: las comprobaciones deterministas hacen cumplir el orden de las tools, los argumentos, los bucles y los invariantes; los jueces calibrados se ocupan de las decisiones que requieren interpretación. El resultado es una suite versionada que detecta el mismo fallo antes de la siguiente release.

Para una comparación breve de tools, consulta Best AI Agent Evaluation Tools.

Por qué las evaluaciones de agents son diferentes

Las evaluaciones tradicionales de LLM suelen puntuar un único par de entrada y salida: relevancia, fidelidad, corrección, seguridad y quizá estilo. Los agents añaden planificación, tool calls, reintentos y comprobaciones de terminación, y cada paso introduce un nuevo punto de fallo.

Pensemos en un agent de reembolsos. La transcripción puede terminar bien aunque la traza sea incorrecta:

lookup_order -> issue_refund -> final_answer

La evaluación de la salida pasa. Una evaluación de trayectoria debería fallar porque verify_identity nunca se ejecutó antes de issue_refund. En agents con tool use, las evaluaciones que solo miran la respuesta pueden detectar fallos de calidad del contenido, pero no pueden demostrar que el agent siguió una trayectoria válida ni que produjo los efectos secundarios requeridos.

Hay un segundo problema: los errores se acumulan. Si un workflow tiene 20 pasos obligatorios, cada uno tiene éxito de forma independiente y todos presentan la misma fiabilidad del 95 %, la tasa de éxito end-to-end se sitúa en torno al 36 %:

Por tanto, el agent puede parecer sólido en comprobaciones aisladas y seguir fallando en la mayoría de las ejecuciones completas. El fallo suele estar en algún punto intermedio, y encontrarlo requiere visibilidad a nivel de componente, no volver a mirar la respuesta.

Dos equipos de investigación han puesto cifras a este fenómeno.

tau-bench proporciona tareas de atención al cliente de aerolíneas y retail. El agent habla con un usuario simulado, llama a APIs y debe seguir la política del dominio. Tras la conversación, el grader comprueba si la base de datos ha alcanzado el estado objetivo anotado. Una transcripción plausible con las filas incorrectas sigue fallando.

Con ese sistema de evaluación, GPT-4o resolvió solo el 35,2 % de las tareas de aerolínea y algo más del 60 % de las de retail. El artículo también introdujo pass^k: la probabilidad de que las k pruebas independientes pasen, promediada entre las tareas.

Retail, la partición más sencilla, obtuvo un valor de pass^8 inferior al 25 %. Para una tarea de retail seleccionada al azar y ocho pruebas independientes, la probabilidad de que las ocho ejecuciones pasasen era inferior al 25 %. Una evaluación de una sola ejecución no puede medir esa consistencia.

MAST estudia por qué fallan los agents. Sus autores construyeron una taxonomía de 14 modos a partir de 150 trazas anotadas manualmente y después la aplicaron a más de 1.600 trazas procedentes de 7 frameworks multi-agent populares. La taxonomía incluye definiciones de roles vagas (diseño del sistema), que un agent ignore lo que ha comunicado otro (desalineación entre agents) y declarar el éxito sin comprobar el resultado (ausencia de verificación). Estos fallos apuntan a los prompts, a la lógica de orquestación y a la ausencia de comprobaciones en el harness. Un modelo base más potente no puede ejecutar un paso de verificación que nunca se construyó, por lo que el objetivo de la evaluación debe incluir el harness que rodea al modelo.

La brecha de adopción

La encuesta de LangChain State of Agent Engineering (1.340 participantes, realizada a finales de 2025) sugiere que muchos equipos ya disponen de la materia prima para mejorar sus evaluaciones. Según el informe, el 89 % tenía algún tipo de observabilidad, el 52,4 % ejecutaba evaluaciones offline y el 37,3 % ejecutaba evaluaciones online.

La encuesta también indica que el 57,3 % de los participantes ya tenía agents en producción. Al preguntarles qué impedía llevarlos a producción, el 32 % mencionó la calidad y el 20 % la latencia. Es una encuesta de un proveedor a sus participantes, no un censo de equipos de agents, pero revela una brecha útil entre la recopilación de trazas y la evaluación sistemática.

Esto deja a los equipos en una situación intermedia incómoda: pueden inspeccionar una ejecución incorrecta a posteriori y aun así lanzar dos veces el mismo fallo.

Cada fallo de producción diagnosticado debería dejar una traza, una etiqueta, una fila de dataset y un scorer. Un fallo repetible pertenece a la suite de regresión.

Elige las métricas según el modo de fallo

La métrica adecuada depende del modo de fallo, no del framework. La división útil tiene tres niveles:

1. Evaluaciones de resultado: responden si la tarea tuvo éxito.
2. Evaluaciones de trayectoria: responden si el camino fue válido, eficiente y conforme a la política.
3. Evaluaciones de componentes: responden qué tool, retriever, sub-agent o paso de decisión falló.

Cada nivel puede ejecutarse offline sobre casos fijos y reproducibles antes de una release, o online sobre trazas de producción muestreadas después de la respuesta. La sección sobre guardrails desarrolla esta división. Las evaluaciones offline pueden requerir goldens: casos almacenados que emparejan una entrada con el resultado, los invariantes de las tools y los argumentos que debe producir una ejecución correcta. Las evaluaciones online deberían priorizar invariantes, distribuciones y comprobaciones asíncronas que permanezcan fuera del request path.

Empieza con métricas deterministas. Se repiten para entradas y código fijos y son baratas de ejecutar. Sus reglas pueden quedar obsoletas cuando cambian las tools o la política, así que versiona el scorer junto con la especificación que comprueba.

Corrección de tool calls

La corrección de tools compara las tools llamadas con las esperadas. Elige deliberadamente el nivel de exigencia:

• Coincidencia exacta: la secuencia debe coincidir exactamente. Úsala cuando el orden sea una cuestión de política, por ejemplo lookup_order -> verify_identity -> issue_refund.
• Coincidencia en orden: las tools requeridas deben aparecer en el orden relativo correcto, pero se permiten llamadas adicionales inocuas.
• Coincidencia en cualquier orden: las tools requeridas deben aparecer, pero el orden puede variar.

Para empezar basta con un scorer local pequeño:

from collections import Counter

def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if mode not in {"exact", "in_order", "any_order"}:
        raise ValueError(f"unknown matching mode: {mode}")
    if mode == "exact":
        return float(called == expected)
    if not expected:
        return 1.0
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)

called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667
assert tool_correctness(["issue_refund"], [], "exact") == 0.0
assert tool_correctness([], [], "exact") == 1.0
assert tool_correctness(["a", "b"], ["a", "a", "b"], "any_order") == 2 / 3
try:
    tool_correctness([], [], "typo")
except ValueError:
    pass
else:
    raise AssertionError("unknown modes must fail")

La métrica in_order es el recall de la subsecuencia común más larga: qué fracción de la secuencia requerida sobrevivió en el orden correcto. Fíjate en lo que ignora. Las llamadas basura no la reducen, así que un agent puede obtener aquí 1,0 mientras realiza el doble de llamadas necesarias. Cuando las llamadas adicionales cuestan dinero o mutan el estado, registra también la precisión (llamadas requeridas coincidentes entre el total de llamadas) y lee ambas métricas conjuntamente. El recall detecta el paso ausente; la precisión detecta el deambular. Ni un recall de 1,0 ni una precisión alta autorizan mutaciones adicionales. Comprueba cada llamada que cambie el estado frente a sus permisos, recurso, argumentos y verificación previa requerida. Con una lista esperada vacía, solo el modo exacto significa «no se permiten llamadas»; los demás modos no tienen requisitos positivos.

La métrica Tool Correctness de DeepEval expone los mismos controles mediante should_consider_ordering y should_exact_match.

Corrección de argumentos

Llamar a la tool correcta con argumentos incorrectos suele ser peor que llamar a la tool equivocada, porque la traza parece normal.

En casos sencillos, valida JSON Schema y los valores exactos. En casos semánticos, almacena los argumentos esperados y evalúa las diferencias:

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for June 19, 2026.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

Una métrica basada en el nombre de la tool no puede detectar 2026-06-17 cuando la política exige 2026-06-19. El dataset también tiene que almacenar los argumentos.

En esta ilustración de una llamada por tool, parameter-match es la fracción de las tuplas (tool, key, value) esperadas que el agent acertó. Los diccionarios siguientes solo son válidos cuando cada tool relevante tiene como máximo una invocación. No los construyas sobrescribiendo llamadas anteriores con el mismo nombre: eso ocultaría un reembolso incorrecto seguido de otro correcto. Para llamadas repetidas, conserva los IDs de llamada y el orden, empareja la invocación prevista y valida cada mutación por separado.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if key in called_args.get(tool, {}) and called_args[tool][key] == want:
                matched += 1
    return matched / total if total else 1.0

assert argument_correctness({}, {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {}},
                            {"reschedule_delivery": {"date": None}}) == 0.0
assert argument_correctness({"reschedule_delivery": {"date": None}},
                            {"reschedule_delivery": {"date": None}}) == 1.0

La igualdad exacta es adecuada para IDs, enums y fechas ya normalizadas a un único formato. No lo es para texto libre, floats ni fechas con el formato que produzca el modelo, donde == marca como incorrecta una respuesta válida. Evalúa esos campos según su propia naturaleza: coincidencia de strings normalizados, parseo de fechas o tolerancia numérica. La métrica no cambia; cambia el comparador de cada campo.

Eficiencia, bucles y callejones sin salida

Un agent que completa la tarea después de cinco tool calls redundantes sigue indicando un problema de planificación y cuesta más ejecutarlo.

Señales baratas con las que deberías empezar:

• Tasa de llamadas redundantes: llamadas idénticas a la misma tool con argumentos idénticos repetidas más de dos veces.
• Anomalías en la forma de la traza: picos repentinos de profundidad, número de tool calls, número de tokens, latencia o coste.
• Convergencia de la ruta: cuánto se aproxima la ejecución a la ruta válida más corta conocida para la tarea.
• Corrección de terminación: si el agent se detuvo demasiado pronto, siguió trabajando tras tener éxito o declaró el éxito sin el cambio de estado requerido.
• Adhesión al plan: si el agent escribe un plan antes de actuar, comprueba si la traza lo siguió. Un buen plan ignorado y un mal plan seguido a la perfección fallan por razones opuestas, y la diferencia entre el plan y la traza indica cuál de las dos cosas ocurrió.

Ejecuta estas comprobaciones antes que un juez siempre que puedas. Un detector de bucles ocupa unas pocas líneas sobre la traza. No necesita un modelo.

Finalización de la tarea y evaluación del resultado

Cuando se evalúa el resultado, la pregunta es: «¿El usuario obtuvo lo que pidió?».

Dos patrones funcionan especialmente bien:

• Evaluación de finalización de tareas sin referencia: extrae el objetivo de la entrada y juzga si la traza y la respuesta final lo lograron. Funciona online porque el tráfico de producción rara vez tiene salidas goldens.
• Evaluación del estado del entorno: compara las filas finales de la base de datos, archivos, tickets, reservas o registros con un estado objetivo anotado. Es más robusta que comparar transcripciones, porque los agents pueden encontrar rutas válidas que no hayas escrito explícitamente.

La segunda opción es mejor cuando puedes construirla. El estado final es el contrato. La transcripción solo es una evidencia.

Dos salvedades ayudan a mantener esto bajo control. Una auditoría de 2025 sobre benchmarks agentic descubrió que tau-bench evalúa algunas tareas exclusivamente mediante el estado de la base de datos. En algunas tareas, el resultado anotado no exige ningún cambio de estado ni un texto concreto. En ese caso, un agent que no haga nada puede obtener un aprobado: el 38 % en la partición de aerolíneas y el 6,0 % en retail, para cualquier k. Anthropic informó de una ejecución de Opus 4.5 que «falló» una tarea de reservas en tau2-bench, el benchmark sucesor. El agent encontró una laguna de la política que en realidad producía un resultado mejor para el usuario. La evaluación del estado supera a la comparación de transcripciones, pero el estado objetivo sigue siendo una anotación, y las anotaciones contienen errores. Audita los casos que pasan con demasiada facilidad, no solo los que fallan.

Las versiones de los benchmarks y los entornos cambian el resultado

Las cifras originales de tau-bench anteriores explican la fiabilidad en pruebas repetidas; no constituyen la clasificación actual de modelos. El repositorio mantenido de tau-bench presenta ahora tau3-bench, que añade recuperación de conocimiento y voz full-duplex. Su corrección de evaluación de la versión 1.0.1 de julio de 2026 cambia las puntuaciones de banking_knowledge: los resultados de versiones anteriores no son comparables en ese dominio. Fija las revisiones de las tareas y del grader, además del modelo, y vuelve a puntuar las trayectorias guardadas cuando se corrija una anotación.

Elige un benchmark que ejercite la interfaz desplegada. Los tests de atención al cliente solo con texto no pueden demostrar el manejo de interrupciones en un agent de voz. Las tareas de recuperación de conocimiento también necesitan el corpus, la configuración de búsqueda y las evidencias disponibles en cada turno. Adopta estas formas de tarea para crear casos de regresión locales, en lugar de importar la posición de una clasificación pública como criterio de release.

El sandbox también forma parte del test. El estudio de infraestructura de Anthropic de febrero de 2026 encontró una diferencia de seis puntos porcentuales en Terminal-Bench 2.0 entre sus configuraciones de recursos estricta y sin límite, con el mismo modelo, harness y tareas. Un margen adicional redujo los fallos de infraestructura y permitió estrategias de solución diferentes. Registra las garantías y límites de CPU y RAM, los timeouts, la concurrencia, el acceso a red y el tratamiento de errores de infraestructura. Informa de esos fallos por separado sin eliminarlos silenciosamente del denominador de tareas esperadas.

Evaluaciones de componentes

Las métricas de resultado y de trayectoria indican que la ejecución falló y, aproximadamente, dónde. Las evaluaciones de componentes puntúan un único span: ¿era relevante el chunk recuperado?, ¿devolvió el sub-agent el schema que esperaba su caller?, ¿se pudo parsear la respuesta de la tool? Asocia la puntuación al span y no a la ejecución completa, para que «qué tool ha empeorado esta semana» sea una consulta y no una nueva ejecución.

Tres comprobaciones cubren la mayor parte del problema:

• Puntuación por span: ejecuta la métrica adecuada para el tipo de span. Los spans de retrieval reciben recall y precisión frente al chunk anotado; los spans de sub-agents, validación del schema más su propia puntuación de corrección de tools; los spans de tools, tasa de errores y latencia.
• Interpretación del resultado de la tool: proporciona al agent una salida de tool correcta pero incómoda —una lista vacía, una coincidencia parcial o una marca temporal obsoleta— y comprueba qué hace después. Una tool puede ser correcta mientras el agent la interpreta mal, y ese fallo puede aparecer dos pasos más tarde.
• Atribución del fallo: el fallo visible suele producirse después del fallo real. Atribúyelo al primer span cuya salida ya era incorrecta, no al paso que generó el error.

Aquí también resulta útil la matemática acumulativa del principio. Si 20 pasos parecen correctos de forma aislada, la ejecución todavía puede fallar la mayor parte del tiempo. Las tasas de paso por span muestran qué paso funciona al 95 % y cuál al 70 %.

El flywheel de la traza a la evaluación

Extrae primero los fallos de producción, antes de idear casos de evaluación adicionales.

El ciclo:

1. Captura suficientes evidencias de la traza para reconstruir el fallo, controlando el contenido sensible.
2. Etiqueta qué ha fallado.
3. Agrupa los fallos similares.
4. Conserva goldens representativos, incluidas las variantes que necesitan resultados diferentes.
5. Versiona el dataset.
6. Ejecútalo en CI.
7. Mantén online la puntuación de muestras de trazas de producción.

El repositorio complementario trace2evals implementa el ciclo completo para un agent de soporte defectuoso. Captura spans de OpenTelemetry GenAI, detecta fallos mediante reglas deterministas, deduplica los casos en un golden dataset versionado y vuelve a ejecutar cada golden en CI. El backend predeterminado sustituye el modelo por reglas deterministas que vuelven a representar las decisiones del agent defectuoso, de modo que make demo reproduce offline todo el ciclo sin API key. Ejecuta uv sync --extra live y configura una API key para que los mismos comandos utilicen un modelo real.

Esta es una pipeline didáctica. La revisión del 6 de septiembre de 2026 todavía presenta casos límite en los scorers, comprobaciones de autorización basadas en nombres y estado de prueba compartido. Su adaptador de trazas espera sus propios atributos de span y formatos de mensajes. Los ejemplos corregidos de aquí no actualizan ese repositorio ni establecen autorización para producción; valida la autorización correcta y vinculada al recurso de cada mutación y aísla las pruebas antes de confiar en sus resultados de CI.

Extrae fallos mediante análisis de errores

La guía práctica de Hamel muestra el workflow: inspeccionar conversaciones reales, tomar notas abiertas, categorizar los fallos y construir tests específicos.

1. Inspecciona las trazas y toma notas abiertas sobre lo que ha ido mal.
2. Agrupa los fallos recurrentes en categorías con nombre.
3. Etiqueta las trazas según esa taxonomía.
4. Construye tests específicos para los grupos accionables más grandes.

No empieces con etiquetas como reasoning_issue o tool_problem. Son demasiado vagas para poder probarlas. Usa etiquetas como missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429 o stopped_before_database_update. Una etiqueta tan específica te dice exactamente qué debería afirmar el test de regresión.

Deduplica antes de promocionar

El ciclo de extracción de trazas tiene una trampa: añadir para siempre todas las trazas incorrectas. Eso crea un dataset grande, caro y estrecho. Pasa con near-duplicates de marzo mientras no detecta la nueva forma del mismo bug en junio.

Agrupa primero. Empieza con un golden representativo por clúster y conserva después las variantes con permisos, argumentos, estados de recuperación o resultados esperados diferentes. Un texto similar no hace equivalentes dos casos de política. Almacena los IDs de traza relacionados en metadatos con acceso controlado para que un reviewer pueda inspeccionar posteriormente las evidencias.

Si un clúster de fallos reaparece después de una corrección, el caso de regresión no se ha generalizado. Revisa el clúster y añade las variantes de comportamiento que faltan, en lugar de recopilar transcripciones casi idénticas.

Versiona el dataset

Versiona los datasets igual que versionas los prompts y el código. Cuando cambie algo relevante —modelo, prompt, schema de una tool, prompt del juez o comportamiento de la aplicación— querrás ejecutar la misma versión del dataset antes y después.

La comprobación de CI debería fijar:

• versión del dataset
• versión de la aplicación
• versión del prompt
• modelo del juez
• prompt del juez
• versión del código del evaluador
• schemas de las tools, política, harness y configuración de gestión del contexto
• revisión del modelo, configuración de reasoning y sampling
• fixture del entorno inicial y efectos externos permitidos

Si cambia cualquiera de estos elementos, la comparación antes/después se vuelve confusa. Un archivo goldens-v3.json en git basta a pequeña escala. Las snapshots nativas de las tools en Langfuse, Phoenix, Braintrust o LangSmith ayudan cuando el dataset pasa a ser colaborativo.

Mantén separados los regresiones de desarrollo, los ejemplos de calibración del juez, la validación held-out y las muestras de monitorización. Agrupa las sesiones, usuarios y tareas relacionadas antes de dividir los conjuntos, para que los near-duplicates no se filtren entre ellos. En cuanto un caso contribuya a dar forma a un prompt o a una rúbrica, trátalo como evidencia de desarrollo. Una suite de fallos extraídos comprueba regresiones conocidas; su media no estima la tasa de éxito en producción.

Restablece el estado mutable en cada prueba: archivos, filas de la base de datos, caches y fixtures de las tools. Aísla las credenciales y los efectos externos, y mantén iguales los presupuestos del candidato y de la baseline. Informa por separado del número de tareas y de las pruebas, junto con todos los intentos iniciados, timeouts, crashes y resultados no puntuables. Compara resultados emparejados sobre las mismas tareas. Estas decisiones siguen el enfoque de pruebas limpias y evaluación del resultado descrito en la guía de evaluación de Anthropic.

Ejecuta las evaluaciones en CI

Una comprobación de release debe hacer fallar el build cuando una métrica cruza el límite acordado. De lo contrario, la suite de evaluación solo es un dashboard.

Después de restaurar el fixture del caso en una prueba aislada, el test debe volver a ejecutar el agent actual contra la entrada del golden. No debe limitarse a reproducir la traza antigua que falló (boceto; la versión ejecutable está en el repositorio complementario):

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

Es fácil equivocarse con esta distinción. La función del dataset es detectar que la siguiente versión del agent repite un fallo antiguo, no archivar el fallo en sí.

Calibra el juez antes de confiar en él

LLM-as-judge ayuda. También es fácil engañarse con él.

G-Eval evalúa tres benchmarks de meta-evaluación. Son SummEval, construido a partir de resúmenes de noticias de CNN/DailyMail; Topical-Chat, un benchmark de diálogo basado en conocimiento; y QAGS, que comprueba la consistencia factual en resúmenes de CNN/DailyMail y XSum. Usando GPT-4 como backbone, G-Eval-4 alcanzó una correlación de Spearman de 0,514 con los juicios humanos en SummEval. Su función de puntuación pondera los niveles de valoración según la probabilidad de los tokens ($\text{score} = \sum_i p(s_i)\,s_i$).

El artículo estimó las probabilidades de los tokens de GPT-4 mediante 20 muestras porque ese modelo no las exponía en el experimento. Un modelo alojado puede no proporcionar logprobs utilizables, así que conserva la rúbrica, pero no insinúes que has reproducido la ponderación probabilística del artículo. Estos resultados comparan el protocolo del artículo con sus baselines de NLG en esos benchmarks. Respaldan probar un juez con una rúbrica explícita, no sustituir de forma general las métricas automáticas ni un benchmark de trayectorias de agents en producción.

MT-Bench mostró que GPT-4 coincidía con las preferencias humanas aproximadamente con la misma frecuencia con la que los humanos coincidían entre sí. Ese resultado ayudó a popularizar el uso de LLM como jueces. Trabajos posteriores revelaron sesgos de posición, longitud y autopreferencia. Las puntuaciones del juez también pueden cambiar cuando cambia el prompt o la versión del modelo.

JudgeBench construyó pares de respuestas en los que una de ellas era objetivamente incorrecta en conocimiento verificable, reasoning, matemáticas y código. Con un prompt de juez normal, GPT-4o obtuvo un 50,9 %, apenas por encima del azar; el prompt Arena-Hard más potente del artículo elevó el mismo modelo solo al 56,6 %. Cambiar el modelo con ese prompt más potente importa más: Claude 3.5 Sonnet, el mejor juez de propósito general probado, alcanzó el 64,3 %, y o3-mini con un nivel alto de reasoning llegó al 80,9 %. Las respuestas confiadas pero incorrectas siguen siendo difíciles de detectar para un juez que no razona antes de puntuar.

Trata el juez como un instrumento de medición: calíbralo con etiquetas humanas antes de que puntúe nada y vuelve a comprobarlo cuando cambie el modelo o el prompt del juez.

Cuando sea necesario un juez, haz que el veredicto tenga una estructura. Schema-Guided Reasoning (SGR) proporciona al veredicto un schema para la forma de salida y su inspeccionabilidad. Structured Outputs o constrained decoding pueden imponer la forma del objeto, los campos obligatorios y las restricciones de valores para campos como evidence, passed_criteria, failed_criteria, failure_mode y score.

Coloca los campos de evidencia antes de la puntuación si eso facilita inspeccionar el registro. El orden de los campos es presentación, no una garantía de reasoning. Un veredicto válido según el schema todavía puede contener evidencias sin respaldo o una puntuación poco fiable. Usa la calibración con etiquetas humanas, validadores deterministas y revisión de transcripciones para comprobar la fiabilidad del juez. CI puede comparar un objeto JSON estable, pero eso comprueba la inspeccionabilidad y la forma, no demuestra que se hayan seguido las etapas de la rúbrica.

Un veredicto estructurado también puede cambiar la curva de costes. Trata un modelo más barato como candidato, no como sustituto automático. Ejecútalo sobre el mismo conjunto de calibración etiquetado por humanos. Compara su concordancia y sus tasas de falsos aprobados y falsos suspensos con el juez más grande. Úsalo para casos rutinarios solo si supera los umbrales definidos por tu aplicación. Reserva el juez más grande para desacuerdos, casos de alto riesgo o ejecuciones de calibración.

Lista de comprobación de higiene del juez:

1. Prioriza pass/fail binario siempre que sea posible. Las escalas de cinco puntos invitan a una precisión ficticia.
2. Etiqueta trayectorias que cubran los modos de fallo reales antes de cerrar la rúbrica. Elige el tamaño de la muestra según la cobertura y la incertidumbre que pueda tolerar la decisión, y reserva casos independientes para la validación.
3. Mide la concordancia entre juez y humanos con kappa de Cohen, una matriz de confusión y recall positivo/negativo. Kappa mide la concordancia una vez descontada la esperada por azar; cuanto mayor, mejor. Un juez que siempre dice «pass» no discrimina de forma útil, por lo que kappa puede ser cero o no estar definida. Decide qué hacer cuando no esté definida antes de usar la métrica para aprobar una release.
4. Descompón los criterios generales. «¿Verificó el agent la identidad antes del tool call de reembolso?» es mejor que «¿Fue buena la trayectoria?».
5. Emite el veredicto mediante un schema SGR con evidencias, criterios fallidos, modo de fallo y puntuación.
6. Compara jueces de la misma familia y de familias distintas con etiquetas humanas held-out; la separación de familias por sí sola no demuestra fiabilidad.
7. Mide la sensibilidad al orden por pares. Mantén la aleatorización o la agregación con el orden intercambiado solo si mejora las decisiones held-out; un estudio controlado de 2026 descubrió que intercambiar el orden podía perjudicar los casos adversariales.
8. No otorgues crédito por texto adicional salvo que aporte contenido correcto, relevante y respaldado. Una respuesta más larga no es mejor.
9. Fija el modelo del juez, el prompt, el dataset, el schema y la versión de la aplicación.
10. Recalibra después de cambios en el modelo, prompt, tool, política o schema.

Un panel es otra opción que conviene probar. PoLL informó de una mejor alineación con los juicios humanos, menor sesgo intramodelo y menor coste que su baseline de un único GPT-4 en seis datasets. Esos resultados corresponden a sus modelos, tareas y precios históricos. No demuestran que un panel sea más seguro en tu tarea. Compara sus falsos aprobados, falsos suspensos, coste y carga de desacuerdos con un único juez calibrado sobre etiquetas held-out.

No existe un umbral universal de kappa que haga apto a un juez para CI. Informa de la matriz de confusión, el número de etiquetas, la tasa de falsos aprobados entre los fallos humanos y la tasa de falsos suspensos entre los aprobados humanos, incluyendo la incertidumbre. Elige los límites de release según las consecuencias de esos errores. Usa colas de revisión cuando las evidencias sean demasiado débiles para una aceptación automática y conserva la autorización humana para acciones con consecuencias cuando el workflow lo requiera.

Los guardrails bloquean inline; las evaluaciones online observan después

Se suelen confundir porque ambos producen puntuaciones. La diferencia está en la ubicación: inline en el request path, antes de una release o después de la respuesta.

Los guardrails se ejecutan inline. Son rápidos y visibles para el usuario. Un guardrail puede bloquear un tool call, redactar PII, rechazar un prompt injection u obligar a reintentar antes de que la respuesta salga del sistema. Un falso positivo es un bug de producción. Un falso negativo es más silencioso y peor, porque nada en el request path lo comunica. Las comprobaciones de schema, rango y política son deterministas. La detección de injection y PII son clasificadores, así que trata los fallos como algo esperado y mantén una evaluación asíncrona que supervise lo que dejan pasar.

Las evaluaciones offline se ejecutan antes de la release. Son reproducibles. Comprueban prompts, modelos, tools, retrievers y políticas frente a un dataset fijo.

Las evaluaciones online se ejecutan después de la respuesta, normalmente sobre tráfico muestreado. Pueden usar jueces LLM más lentos porque no están en la ruta de latencia. Su función es detectar deriva, encontrar nuevos clústeres de fallos y alimentar el siguiente dataset offline.

Colocar mal cada mecanismo perjudica al sistema de una forma distinta:

• Un juez en el request path añade latencia y una nueva fuente de inestabilidad.
• Un guardrail relegado a una puntuación asíncrona permite que las infracciones de política lleguen a los usuarios.

En tests de seguridad, distingue entre la detección de un ataque, el intento de una acción prohibida y el éxito real de un efecto dañino. Informa de los efectos dañinos que hayan tenido éxito por prueba de ataque, junto con el threat model y el presupuesto de intentos, además del éxito de la tarea legítima y los bloqueos incorrectos por prueba benigna. La puntuación de un detector por sí sola no demuestra que los datos hayan permanecido privados ni que se haya impedido una escritura. Usa objetivos aislados; el informe del incidente de evaluación de ciberseguridad de Anthropic documenta por qué los efectos de una evaluación necesitan containment.

En sistemas de gran volumen, puntúa una muestra pequeña con un juez más potente y una muestra más amplia con clasificadores baratos. Lanza alertas sobre clústeres e intervalos de confianza, no sobre una única estimación puntual ruidosa.

Opciones de tooling

Ninguna tool es propietaria de todo el ciclo. Compara por separado un trace/dataset store y un runner de CI/evaluación; un mismo producto puede cubrir ambas funciones, pero no necesitas comprar las dos cosas al mismo proveedor.

Esta es una snapshot del autor comprobada el 6 de septiembre de 2026. Cada enlace corresponde a la documentación actual que utilicé para la afirmación de capacidades. Siguen siendo aplicables los planes, licencias, API keys, acceso a proveedores y requisitos de infraestructura.

Las notas sobre trade-offs describen de dónde procede el coste, no cuál es. Las páginas de precios cambian y los proveedores cuentan cosas distintas: trazas, observaciones, spans, puntuaciones, usuarios, retención o datos procesados. Vuelve a comprobar los precios actuales antes de comprometerte.

Recomendaciones según la restricción:

• Elige Phoenix cuando el self-hosting, la privacidad y el tracing compatible con OTel sean requisitos imprescindibles y tu equipo pueda operar el despliegue.
• Elige Langfuse cuando también necesites versionado de datasets y experimentos y puedas operar su stack de almacenamiento o comprar los add-ons necesarios.
• Elige DeepEval cuando el contrato principal sea un pass/fail de CI con Python/pytest.
• Elige Inspect AI cuando el trabajo principal sea la evaluación de seguridad o de agents frontier en sandboxes configurables.
• Elige LangSmith cuando la integración con LangChain/LangGraph encaje en tu workflow; usa Cloud o ten en cuenta el requisito Enterprise para el hosting de la plataforma mediante BYOC o self-hosted.
• Elige Braintrust cuando el feedback gestionado en pull requests y la comparación de experimentos justifiquen un servicio respaldado por API key.
• Elige Promptfoo cuando las comprobaciones de prompts o red-teaming sean la principal superficie de regresión y un trace store quede fuera del alcance.

La elección de tools es secundaria. Si los fallos de producción no se convierten en casos de test, básicamente estás pagando por almacenar trazas.

Checklist práctico de despliegue

Construye primero el pipeline de evidencias antes de ampliar el stack de métricas. Empieza por decidir de dónde saldrán los ejemplos.

1. Recopila primero las ejecuciones históricas. Si el agent ya existe, extrae las trazas, tickets de soporte, informes de bugs, sesiones con thumbs-down, transcripciones de QA manual y notas de dogfooding antes de cambiar la implementación. Si el agent todavía no existe, registra desde el primer día cada prototipo y ejecución de prueba manual.

2. Instrumenta la forma de la traza. Captura mensajes, tool calls, argumentos, salidas de las tools, errores, número de tokens, latencia, coste, feedback del usuario, versión de la aplicación, versión del prompt, versión del modelo, versión del schema de las tools y estado final del entorno. Usa las convenciones GenAI de OpenTelemetry o spans de estilo OpenInference si quieres portabilidad, y fija la versión de la convención y del adaptador. Captura el contenido de forma selectiva: redacta secrets y datos personales, restringe el acceso y establece la retención antes de promocionar las trazas a datasets. Usa Langfuse, LangSmith, Phoenix o Braintrust si quieres disponer inmediatamente de una UI de trazas y un workflow de datasets.

3. Convierte los fallos reales en casos semilla. Lee las trazas antes de resumirlas con un modelo. Para cada fallo útil, almacena la entrada, el ID de la traza de origen, el estado esperado, los invariantes esperados de las tools, el modo de fallo, la severidad y la nota del reviewer. Langfuse puede enlazar elementos del dataset con trazas de producción; LangSmith puede crear datasets a partir de ejecuciones trazadas. Conserva el enlace de origen para que el caso siga siendo auditable.

4. Si no hay historial, genera casos de cold start. Pide a un LLM que redacte tareas a partir de requisitos de producto, políticas, schemas de tools, máquinas de estados y macros de soporte. Cubre caminos felices y fallos como permisos incorrectos, comprobaciones de identidad ausentes, resultados obsoletos de las tools, fechas ambiguas, reintentos tras rate limits y salidas contradictorias de las tools.

5. No confíes en casos sintéticos hasta que los revise una persona. Los ejemplos sintéticos son útiles para la cobertura, no para establecer la verdad. Márcalos con source: synthetic y exige que un reviewer apruebe el resultado esperado. Ejecuta una ruta de referencia conocida como correcta cuando sea posible y valida las expectativas generadas de forma independiente; usar otra familia de modelos no sustituye esa comprobación.

6. Construye un dataset pequeño y equilibrado. Incluye éxitos, fallos, rechazos, casos límite, casos de muchos turnos, casos sensibles a la política y rutas alternativas válidas. No conviertas el golden en «la transcripción antigua exacta». Almacena lo que debe contener un golden, además del modo de fallo que hizo que el caso entrase en la suite.

7. Añade primero comprobaciones deterministas. El orden requerido de las tools cuando el orden sea política, los argumentos requeridos, la validación del schema, los diffs del estado final, los límites de bucles y los límites de tokens y latencia, junto con los invariantes específicos de la tarea, deberían ejecutarse antes que cualquier juez.

8. Añade un juez con forma SGR. Úsalo solo para la parte que necesite interpretación. Calíbralo con etiquetas humanas y prueba la rúbrica elegida con casos de validación intactos. Si no puede separar los ejemplos buenos de los malos en el conjunto de calibración, corrige la rúbrica antes de conectarlo a CI.

9. Conecta el ciclo. Ejecuta la suite offline pequeña en CI, ejecuta la suite grande antes de la release, puntúa online muestras del tráfico de producción y promociona los clústeres de fallos online recurrentes al dataset offline.

Tu primera suite de evaluación omitirá casos. Ejecútala de todos modos y añade después los fallos recurrentes como casos. Una suite que se ejecuta cada día te proporciona evidencias para mejorarla.

Referencias

• repositorio demo complementario de trace2evals
• LangChain - State of Agent Engineering
• Anthropic - Demystifying Evals for AI Agents
• Hamel Husain - A Field Guide to Rapidly Improving AI Products
• convenciones semánticas de OpenTelemetry para sistemas de AI generativa
• DeepEval Tool Correctness
• DeepEval Task Completion
• DeepEval unit testing in CI/CD
• Inspect running evals
• OpenAI Structured model outputs
• Schema-Guided Reasoning: vLLM, xgrammar, and Pydantic
• Phoenix self-hosting
• Langfuse datasets and versioning
• Langfuse experiments in CI/CD
• LangSmith platform setup
• LangSmith - Create and manage datasets programmatically
• Braintrust - Create experiments
• Phoenix LLM evals
• Promptfoo GitHub Action integration
• tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
• Why Do Multi-Agent LLM Systems Fail?
• Establishing Best Practices for Building Rigorous Agentic Benchmarks
• G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models
• JudgeBench: A Benchmark for Evaluating LLM-based Judges
• Self-Preference Bias in LLM-as-a-Judge