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

Viacheslav Dubrov

2026-06-10 · Actualizado 2026-08-16 · 26 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.

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 agente declaró el éxito antes de que cambiara la base de datos. Evaluar solo la respuesta oculta estos fallos.

Para los ingenieros que operan agentes que usan herramientas en producción, la solución consiste en convertir trazas repetibles en casos de regresión acotados: las comprobaciones deterministas hacen cumplir el orden de las herramientas, los argumentos, los bucles y las invariantes; los jueces calibrados se encargan 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 comparativa breve de herramientas, consulta Mejores herramientas para evaluar agentes de IA.

Por qué la evaluación de agentes es diferente

Las evaluaciones tradicionales de LLM suelen puntuar un único par de entrada y salida: relevancia, fidelidad, corrección, seguridad y quizá estilo. Los agentes añaden planificación, llamadas a herramientas, reintentos y comprobaciones de terminación, de modo que cada paso es un nuevo punto de fallo.

Pensemos en un agente 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 que issue_refund. En los agentes que usan herramientas, las evaluaciones basadas solo en la respuesta son smoke tests: detectan una rotura total y no ven casi nada más.

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

Por tanto, el agente puede parecer sólido en comprobaciones aisladas y aun así fallar 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 a un agente tareas de atención al cliente de aerolíneas y comercios minoristas. El agente conversa con un usuario simulado, llama a APIs y debe seguir la política del dominio. Tras la conversación, el evaluador comprueba si la base de datos ha alcanzado el estado objetivo anotado. Una transcripción plausible con filas incorrectas también falla.

Con esa evaluación, GPT-4o resolvió solo el 35,2 % de las tareas de aerolíneas y algo más del 60 % de las de retail. El artículo también introdujo pass^k: ejecutar la misma tarea k veces y contabilizar un aprobado solo si el agente tiene éxito en las k ejecuciones.

Retail, la división más sencilla, cayó por debajo del 25 % con k = 8. En más de tres cuartas partes de esas tareas, el mismo agente, enfrentado ocho veces a la misma tarea, falló al menos una vez. Una evaluación de una sola ejecución no puede revelar esa inconsistencia.

MAST estudia por qué fallan los agentes. Los autores crearon 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 de 7 frameworks multiagente populares. La taxonomía incluye definiciones de roles vagas (diseño del sistema), que un agente ignore lo que ha comunicado otro agente (desalineación entre agentes) y declarar el éxito sin comprobar el resultado (ausencia de verificación). Estos fallos apuntan a los prompts, la lógica de orquestación y la falta de comprobaciones en el harness. Un modelo base más potente no puede ejecutar un paso de verificación que nunca se implementó, por lo que el objetivo de evaluación debe incluir el harness que rodea al modelo.

La brecha de adopción

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

La encuesta también indica que el 57,3 % de los participantes ya tenía agentes en producción. Al preguntarles qué impedía pasar a producción, el 32 % señaló la calidad y el 20 %, la latencia. Se trata de una encuesta del proveedor a sus participantes, no de un censo de equipos que desarrollan agentes, pero pone de manifiesto una brecha útil entre recopilar trazas y realizar una evaluación sistemática.

Esto deja a los equipos en una situación intermedia incómoda: pueden inspeccionar una ejecución fallida a posteriori y, aun así, volver a desplegar el mismo fallo.

Cada fallo de producción diagnosticado debería dejar una traza, una etiqueta, una fila en un dataset y un scorer. Un fallo reproducible debe formar parte de 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. Evals de resultado responden si la tarea se completó correctamente.
2. Evals de trayectoria responden si el recorrido fue válido, eficiente y conforme a las políticas.
3. Evals de componentes responden qué herramienta, retriever, subagente o paso de decisión falló.

Cada nivel puede ejecutarse offline sobre casos fijos y reproducibles antes del lanzamiento, o online sobre una muestra de trazas de producción después de generar la respuesta. La sección sobre guardrails explica esta división en detalle. Los evals offline pueden requerir goldens: casos almacenados que asocian una entrada con el resultado, los invariantes de las herramientas y los argumentos que debe producir una ejecución correcta. Los evals online deberían priorizar invariantes, distribuciones y comprobaciones asíncronas que no interfieran en el request path.

Empieza por métricas deterministas. Son baratas, rápidas y no sufren deriva.

Corrección de las llamadas a herramientas

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

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

Para empezar, basta con un pequeño scorer local:

from collections import Counter

def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if not expected:
        return 1.0
    if mode == "exact":
        return float(called == expected)
    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

La puntuación de in_order es el recall de la subsecuencia común más larga: qué fracción de la secuencia requerida se mantuvo, en el orden correcto. Fíjate en lo que ignora. Las llamadas basura no la reducen, así que un agente puede obtener aquí un 1,0 haciendo el doble de llamadas de las necesarias. Cuando las llamadas adicionales cuestan dinero o mutan el estado, realiza un seguimiento también de la precisión (llamadas requeridas coincidentes sobre el total de llamadas) y analiza ambas métricas conjuntamente. El recall detecta el paso que falta; la precisión detecta los rodeos.

La métrica de corrección de herramientas de DeepEval expone los mismos controles mediante should_consider_ordering y should_exact_match.

Corrección de los argumentos

Llamar a la herramienta correcta con argumentos incorrectos suele ser peor que llamar a la herramienta equivocada, porque el trace parece normal.

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

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for next Friday.",
    "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 herramienta no puede detectar 2026-06-17 cuando la política exige 2026-06-19. El dataset también tiene que almacenar los argumentos.

La puntuación asociada a ese dataset es el ajuste de parámetros: la fracción de las ternas (tool, key, value) esperadas que el agente acertó.

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 called_args.get(tool, {}).get(key) == want:
                matched += 1
    return matched / total if total else 1.0

La igualdad exacta es adecuada para identificadores, enums y fechas ya normalizadas a un único formato. No lo es para texto libre, floats y fechas con cualquier formato producido por el modelo, donde == marca como incorrecta una respuesta válida. Evalúa esos campos según sus propias reglas: comparación de cadenas normalizadas, parseo de fechas o tolerancia numérica. La métrica sigue siendo la misma; cambia el comparador de cada campo.

Eficiencia, bucles y callejones sin salida

Un agente que completa la tarea después de cinco llamadas redundantes a herramientas sigue indicando un problema de planificación y resulta más caro de ejecutar.

Señales baratas con las que conviene empezar:

• Tasa de llamadas redundantes: llamadas idénticas a la misma herramienta y con los mismos argumentos repetidas más de dos veces.
• Anomalías en la forma del trace: picos repentinos de profundidad, número de llamadas a herramientas, cantidad de tokens, latencia o coste.
• Convergencia de la ruta: proximidad de la ejecución a la ruta válida más corta conocida para la tarea.
• Corrección de la terminación: si el agente se detuvo demasiado pronto, siguió trabajando después de lograr el objetivo o declaró el éxito sin realizar el cambio de estado requerido.
• Adherencia al plan: si el agente escribe un plan antes de actuar, comprueba si el trace lo siguió. Ignorar un buen plan y seguir perfectamente uno malo son fallos, aunque por motivos opuestos; la diferencia entre el plan y el trace indica cuál de los dos ocurrió.

Ejecuta estas comprobaciones antes de recurrir a un judge siempre que puedas. Un detector de bucles requiere solo unas pocas líneas sobre el trace. No necesita un modelo.

Finalización de tareas y evaluación del resultado

Si se evalúa el resultado, la pregunta es: «¿ha obtenido el usuario lo que pidió?».

Hay dos patrones que funcionan especialmente bien:

• Evaluación de la finalización de la tarea sin referencia: extrae el objetivo de la entrada y juzga si el trace, junto con la respuesta final, lo alcanzó. Funciona online porque el tráfico de producción rara vez tiene salidas de referencia.
• Evaluación del estado del entorno: compara las filas finales de la base de datos, los archivos, los tickets, las reservas u otros registros con un estado objetivo anotado. Es más robusta que comparar transcripciones, porque los agentes pueden encontrar rutas válidas que no habías documentado.

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

Dos salvedades mantienen esto con los pies en la tierra. Una auditoría de benchmarks agentic de 2025 descubrió que tau-bench puntúa algunas tareas únicamente según el estado de la base de datos. En algunas tareas, el resultado anotado no requiere ningún cambio de estado ni un texto concreto. Por tanto, un agente que no haga nada puede aprobar: un 38 % en la partición de aerolíneas y un 6,0 % en retail, con 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 agente encontró un resquicio en 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 aprueban con demasiada facilidad, no solo los que fallan.

Evaluaciones de componentes

Las métricas de resultado y de trayectoria te indican que la ejecución ha fallado y, aproximadamente, dónde. Las evaluaciones de componentes puntúan un único span: ¿era relevante el fragmento recuperado?, ¿devolvió el subagente el esquema que esperaba su caller?, ¿se pudo parsear la respuesta de la propia herramienta? Asocia la puntuación al span en lugar de a la ejecución, para que «¿qué herramienta 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 precision frente al fragmento anotado; los spans de subagentes, validación del esquema y su propia puntuación de corrección de la herramienta; los spans de herramientas, tasa de errores y latencia.
• Interpretación del resultado de la herramienta: proporciona al agente una salida de herramienta correcta, pero poco cómoda (una lista vacía, una coincidencia parcial o una marca de tiempo obsoleta) y comprueba qué hace a continuación. Una herramienta puede ser correcta mientras el agente la interpreta mal, y ese fallo puede aparecer dos pasos después.
• Atribución del fallo: el fallo visible suele producirse aguas abajo 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 de acumulación del principio. Aunque 20 pasos parezcan correctos de forma aislada, la ejecución puede seguir fallando la mayoría de las veces. Las tasas de aprobación por span muestran qué paso funciona al 95 % y cuál al 70 %.

El flywheel de trace a eval

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

El ciclo:

1. Captura la traza completa.
2. Etiqueta qué ha fallado.
3. Agrupa los fallos similares.
4. Conserva un golden representativo por clúster.
5. Versiona el dataset.
6. Ejecútalo en CI.
7. Sigue puntuando online trazas de producción muestreadas.

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

Extraer fallos mediante análisis de errores

Hamel Husain y Shreya Shankar enseñan un flujo de trabajo de análisis de errores específico para este paso; la guía práctica de Hamel lo explica paso a paso. Los dos primeros pasos toman sus nombres de la investigación cualitativa, pero el método es sencillo: leer trazas, tomar notas y poner nombre a los patrones.

1. Codificación abierta: lee entre 30 y 50 trazas reales y escribe notas libres sobre qué salió mal.
2. Codificación axial: agrupa esas notas en 5 o 6 categorías de fallos con nombre.
3. Etiqueta todo según la taxonomía.
4. Construye métricas para los grupos más numerosos.

No empieces con etiquetas como reasoning_issue o tool_problem. Son demasiado vagas para 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 indica exactamente qué debe comprobar el regression test.

Deduplica antes de promocionar

El ciclo de minería de trazas tiene una trampa: añadir para siempre cada traza incorrecta. Eso crea un dataset grande, caro y poco variado. Pasa con near-duplicates de marzo, pero no detecta la nueva forma del mismo bug en junio.

Agrupa primero. Promociona un único golden representativo por clúster. Guarda los IDs de las trazas relacionadas en los metadatos para que un revisor pueda inspeccionar posteriormente las evidencias de producción.

Si un clúster de fallos reaparece después de una corrección, el caso de regresión no se ha generalizado. Vuelve a agrupar y amplía el golden en lugar de añadir 15 ejemplos puntuales.

Versiona el dataset

Versiona los datasets igual que versionas los prompts y el código. Siempre que cambie algo relevante (el modelo, el prompt, el esquema de herramientas, el judge prompt o el comportamiento de la aplicación), querrás ejecutar la misma versión del dataset antes y después.

La puerta de CI debe fijar:

• versión del dataset
• versión de la aplicación
• versión del prompt
• judge model
• judge prompt
• versión del código del evaluador

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

Bloquea la CI

Una métrica fallida debe hacer fallar el build; de lo contrario, la suite de evaluación no es más que un dashboard que nadie lee.

La prueba debe volver a ejecutar el agente actual con la entrada golden. No debe limitarse a reproducir la traza antigua que falló (borrador; 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 agente repite un fallo antiguo, no archivar el fallo en sí.

Calibra el judge antes de confiar en él

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

G-Eval evalúa tres benchmarks de meta-evaluación. Son SummEval, creado a partir de la tarea de resumen de noticias de CNN/DailyMail; Topical-Chat, un benchmark de diálogo con grounding en conocimiento; y QAGS, que comprueba la consistencia factual en resúmenes de CNN/DailyMail y XSum. Con GPT-4 como backbone, G-Eval-4 alcanzó una correlación de Spearman de 0,514 con las evaluaciones humanas en SummEval. Su función de puntuación pondera los niveles de valoración mediante 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 muestreos, porque ese modelo no las exponía durante el experimento. Un modelo alojado puede no proporcionar logprobs utilizables, así que conserva la rúbrica, pero no des a entender 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 la evaluación con un judge basado en una rúbrica explícita, no su sustitución general por métricas automáticas ni por un benchmark de trayectorias de agentes en producción.

MT-Bench mostró que GPT-4 coincidía con las preferencias humanas aproximadamente con la misma frecuencia con la que las personas coincidían entre sí. Este resultado contribuyó a popularizar la evaluación mediante LLM. Trabajos posteriores revelaron sesgos de posición, longitud y autopreferencia. Las puntuaciones del juez también pueden cambiar cuando se modifica el prompt o la versión del modelo.

JudgeBench creó pares de respuestas en los que una de ellas era objetivamente incorrecta en conocimientos verificables, razonamiento, matemáticas y código. Con un prompt de juez sencillo, GPT-4o obtuvo un 50,9 %, apenas por encima de lo que daría lanzar una moneda; el prompt más potente de Arena-Hard del artículo elevó el resultado del mismo modelo solo hasta el 56,6 %. Cambiar el modelo con ese prompt más potente tiene un efecto mayor: Claude 3.5 Sonnet, el mejor juez de propósito general evaluado, alcanzó el 64,3 %, y o3-mini con un nivel alto de esfuerzo de razonamiento llegó al 80,9 %. Las respuestas seguras pero incorrectas siguen siendo difíciles de detectar para un juez que no razona antes de calificar.

Trata al juez como un instrumento de medición: calibra su comportamiento con etiquetas humanas antes de que evalúe nada y vuelve a comprobarlo cada vez que cambie el modelo juez o el prompt.

Cuando sea necesario usar un juez, haz que el veredicto tenga una estructura definida. Schema-Guided Reasoning (SGR) proporciona al veredicto un esquema que define la forma de salida y facilita su inspección. Structured Outputs o el constrained decoding pueden imponer la forma del objeto, los campos obligatorios y las restricciones de valor 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 la inspección del registro. El orden de los campos es una cuestión de presentación, no una garantía de razonamiento. Un veredicto válido según el esquema aún puede contener evidencia no respaldada o una puntuación poco fiable. Usa la calibración con etiquetas humanas, validadores deterministas y la revisión de transcripciones para comprobar la fiabilidad del juez. CI puede comparar mediante diff un objeto JSON estable, pero eso comprueba la capacidad de inspección y la forma, no demuestra que se hayan seguido las distintas fases 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 personas. Compara su grado de acuerdo, su tasa de falsos aprobados y su tasa de falsos rechazos con las del juez de mayor tamaño. Úsalo para los casos rutinarios únicamente si supera los umbrales definidos por tu aplicación. Reserva el juez de mayor tamaño para los desacuerdos, los casos de alto riesgo o las ejecuciones de calibración.

Lista de comprobación de higiene del juez por defecto:

1. Prioriza el binario aprobado/rechazado siempre que sea posible. Las escalas de cinco puntos invitan a una falsa precisión.
2. Etiqueta manualmente entre 30 y 50 trayectorias antes de escribir la rúbrica definitiva.
3. Mide la concordancia entre el juez y las personas con la kappa de Cohen, una matriz de confusión y el recall de positivos y negativos. Un juez que siempre responde «aprobado» no discrimina de forma útil; la kappa puede ser cero o no estar definida cuando el denominador de la concordancia esperada es cero. Establece una política explícita para la kappa no definida antes de usar esta métrica como criterio de bloqueo del despliegue.
4. Descompón los criterios generales. «¿Verificó el agente la identidad antes de llamar a la herramienta de reembolso?» es mejor que «¿Fue buena la trayectoria?».
5. Emite el veredicto mediante un esquema SGR con evidencias, criterios incumplidos, modo de fallo y puntuación.
6. Cuando sea posible, utiliza un juez de una familia de modelos distinta de la del generador.
7. Aleatoriza el orden en las comparaciones por pares y calcula la media en ambas direcciones.
8. Penaliza en la rúbrica la longitud no justificada. Una respuesta más larga no es necesariamente mejor.
9. Fija el modelo juez, el prompt, el dataset, el esquema y la versión de la aplicación.
10. Recalibra tras cualquier cambio en el modelo, el prompt, las herramientas, la política o el esquema.

Para puntuaciones de alto riesgo, utiliza un jurado pequeño en lugar de un único juez grande. PoLL probó un panel de jueces más pequeños procedentes de familias de modelos disjuntas y agrupó sus veredictos. En seis datasets, el panel siguió mejor los juicios humanos que un único juez GPT-4. También evitó el sesgo de preferencia por sí mismo del juez único y costó más de siete veces menos. Mantén la revisión humana para las decisiones que afecten al dinero, el acceso, la seguridad o el cumplimiento normativo.

Si un juez alcanza una kappa de 0,55 con las personas en tu tarea, no lo uses para bloquear despliegues. Úsalo para ordenar las colas de revisión. Si se sitúa cerca de 0,75 y el coste de los fallos es moderado, una puerta de CI resulta mucho más fácil de defender.

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

!!! byte «Byte dice»

Hice asíncrona la comprobación de inyección para proteger el p95. Las puntuaciones que producía eran idénticas. Simplemente llegaron después de que la llamada a la herramienta ya se hubiera ejecutado.

La gente confunde estos mecanismos porque ambos producen puntuaciones. La diferencia es dónde se sitúan: inline, en la ruta de la petición y antes de liberar la respuesta, o después de la respuesta.

Los guardrails se ejecutan inline. Son rápidos y visibles para el usuario. Un guardrail puede bloquear una llamada a una herramienta, redactar PII, rechazar una prompt injection o forzar un reintento antes de que la respuesta salga de tu sistema. Un falso positivo es un bug de producción. Un falso negativo es más silencioso y peor, porque nada en la ruta de la petición lo notifica. Las comprobaciones de esquema, rango y política son deterministas. La detección de inyecciones y PII usa clasificadores, así que debes asumir que habrá fallos y mantener una evaluación asíncrona que supervise lo que dejan pasar.

Las evaluaciones offline se ejecutan antes del despliegue. Son reproducibles. Permiten evaluar prompts, modelos, herramientas, 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 drift, encontrar nuevos clústeres de fallos y alimentar el siguiente dataset offline.

Si colocas mal cada componente, las consecuencias aparecen en ambos sentidos:

• Un juez en la ruta de la petición 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 sistemas de gran volumen, puntúa una muestra pequeña con un juez más potente y una muestra más amplia con clasificadores más baratos. Genera alertas sobre clústeres e intervalos de confianza, no sobre una única estimación puntual ruidosa.

Elección de herramientas

Ninguna herramienta controla todo el ciclo. Compara por separado un almacén de trazas/datasets y un runner de CI/evaluaciones; un mismo producto puede cubrir ambas funciones, pero no necesitas contratar las dos a un único proveedor.

Esta es una instantánea del autor verificada el 2026-08-16. Cada enlace corresponde a la documentación actual que utilicé para justificar la afirmación sobre la capacidad. Siguen siendo aplicables los planes, las licencias, las claves de API, el acceso a proveedores y los requisitos de infraestructura.

Las notas sobre las compensaciones describen de dónde procede el coste, no en qué consiste. Las páginas de precios cambian y cada proveedor cuenta elementos distintos: traces, observaciones, spans, puntuaciones, usuarios, retención o datos procesados. Vuelve a comprobar los precios vigentes antes de tomar una decisión.

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 contratar los add-ons necesarios.
• Elige DeepEval cuando el contrato principal sea un resultado pass-fail en CI con Python/pytest.
• Elige Inspect AI cuando el trabajo principal sea evaluar seguridad o agentes frontier en sandboxes configurables.
• Elige LangSmith cuando la integración con LangChain/LangGraph compense el requisito Enterprise para despliegues híbridos o self-hosted.
• Elige Braintrust cuando el feedback gestionado sobre pull requests y la comparación de experimentos justifiquen un servicio respaldado por una 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 la herramienta es secundaria. Si los fallos en producción no se convierten en casos de prueba, en la práctica estás pagando sobre todo por almacenar traces.

Una checklist práctica para el rollout

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

1. Recopila primero las ejecuciones históricas. Si el agente ya existe, extrae los traces, 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 agente aún no existe, registra todas las ejecuciones de prototipos y pruebas manuales desde el primer día.

2. Instrumenta la estructura del trace. Captura mensajes, llamadas a herramientas, argumentos, salidas de herramientas, errores, recuentos de tokens, latencia, coste, feedback de usuarios, versión de la aplicación, versión del prompt, versión del modelo, versión del esquema de herramientas y estado final del entorno. Usa las convenciones GenAI de OpenTelemetry o spans al estilo de OpenInference si quieres portabilidad. Usa Langfuse, LangSmith, Phoenix o Braintrust si quieres disponer inmediatamente de una interfaz de traces y un workflow de datasets.

3. Convierte los fallos reales en casos iniciales. Lee los traces antes de resumirlos con un modelo. Para cada fallo útil, guarda la entrada, el ID del trace de origen, el estado esperado, los invariantes esperados de las herramientas, el modo de fallo, la gravedad y la nota del revisor. Langfuse puede vincular los elementos de un dataset con los traces 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 histórico, genera casos de cold start. Pide a un LLM que redacte tareas a partir de los requisitos del producto, las políticas, los esquemas de las herramientas, las máquinas de estados y las macros de soporte. Cubre los happy paths y fallos como permisos incorrectos, comprobaciones de identidad ausentes, resultados obsoletos de herramientas, fechas ambiguas, reintentos tras límites de rate y salidas contradictorias de herramientas.

5. No des por válidos los casos sintéticos hasta que los revise una persona. Los ejemplos sintéticos son útiles para obtener cobertura, no para establecer la verdad. Márcalos con source: synthetic y exige que un revisor apruebe el resultado esperado. Cuando sea posible, ejecuta una ruta de referencia conocida como correcta y utiliza familias de modelos distintas para generar el caso y evaluar el resultado.

6. Construye un dataset pequeño y equilibrado. Incluye éxitos, fallos, negativas, casos límite, casos de muchos turnos, casos sensibles desde el punto de vista de las políticas y rutas alternativas válidas. No hagas que el golden sea «la transcripción antigua exacta». Almacena lo que almacena un golden, además del modo de fallo que hizo que el caso entrara en la suite.

7. Añade primero comprobaciones deterministas. El orden obligatorio de las tools cuando el orden sea una política, los argumentos obligatorios, la validación del esquema, los diffs del estado final, los límites de bucle, los límites de tokens y latencia, y los invariantes específicos de la tarea deben ejecutarse antes que cualquier judge.

8. Añade un judge con formato SGR. Úsalo únicamente para la parte que requiere interpretación. Calíbralo con etiquetas humanas. 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 cada release, puntúa online muestras del tráfico de producción y devuelve los clústeres recurrentes de fallos online al dataset offline.

Tu primera suite de evals tendrá fallos aburridos. Publícala de todos modos. Una suite que ejecutas a diario es más fácil de corregir que un documento de diseño perfecto que nunca bloquea un PR incorrecto.

Referencias

• repositorio de demostración complementario de trace2evals
• LangChain - Estado de la ingeniería de agentes
• Anthropic - Desmitificación de las evals para agentes de IA
• Hamel Husain - Guía práctica para mejorar rápidamente productos de IA
• Convenciones semánticas de OpenTelemetry para sistemas de IA 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