Saltar a contenido

Traducción automática

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

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

La respuesta de un chatbot es una fila. La ejecución de un agente es un árbol.

Esa diferencia rompe muchos hábitos de evaluación. La respuesta final puede parecer correcta mientras el agente omitió una herramienta obligatoria, reintentó la misma llamada 17 veces, interpretó mal el resultado de una herramienta o siguió una ruta que sería ilegal en producción. Si solo evalúas la respuesta, te pierdes la parte en la que el sistema realmente falló.

TL;DR: Las evaluaciones de agentes necesitan tres capas: métricas de resultado, métricas de trayectoria y métricas de componentes. Construye en torno a este bucle: traza -> etiqueta -> clusteriza -> deduplica -> dataset versionado -> puerta de CI -> monitorización online. Usa comprobaciones deterministas para orden de herramientas, argumentos, bucles e invariantes. Usa jueces LLM solo cuando la comprobación dependa de la interpretación, define esos jueces con Schema-Guided Reasoning (SGR) y cálibralos frente a etiquetas humanas antes de confiar en ellos.

Por qué las evaluaciones de agentes son distintas

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

Tomemos un agente de reembolsos. La transcripción puede terminar bien mientras la traza es incorrecta:

lookup_order -> issue_refund -> final_answer

La evaluación de salida aprueba. Una evaluación de trayectoria debería suspender porque verify_identity nunca se ejecutó antes de issue_refund. Para agentes que usan herramientas, las evaluaciones basadas solo en la respuesta son smoke tests: detectan roturas totales y se pierden todo lo demás.

Hay un segundo problema: los errores se acumulan. Si un flujo de trabajo de 20 pasos es fiable al 95% en cada paso, su tasa de éxito extremo a extremo sigue quedándose en torno al 36%:

\[ 0.95^{20} \approx 0.36 \]

Así que el agente puede parecer sólido en comprobaciones aisladas y aun así fallar en la mayoría de las ejecuciones completas. La rotura suele estar en algún punto intermedio, y encontrarla requiere visibilidad a nivel de componente, no otra mirada a la respuesta.

Una fila frente a un árbol: dónde se esconden los fallos de los agentes

Dos equipos de investigación pusieron números a esto.

tau-bench es un benchmark en el que un agente resuelve tareas de atención al cliente en aerolíneas y retail: habla con un usuario simulado, llama a APIs y tiene que seguir la política del dominio durante el proceso. La evaluación ignora la transcripción. Cuando termina la conversación, el benchmark comprueba si la base de datos alcanzó el estado objetivo anotado, así que una ejecución educada y plausible que dejó filas incorrectas sigue suspendiendo. Con esa evaluación, incluso GPT-4o resolvió con éxito menos de la mitad de las tareas. El artículo también introdujo pass^k: ejecutar la misma tarea k veces y contar como acierto solo si el agente tiene éxito en las k ejecuciones. Las puntuaciones de retail que parecían tolerables para un solo intento cayeron por debajo del 25% con k = 8. Mismo agente, misma tarea, ocho ejecuciones, resultados en su mayoría distintos. Esa inconsistencia es invisible si tu evaluación ejecuta cada caso una sola vez.

MAST plantea otra pregunta: no con qué frecuencia fallan los agentes, sino por qué. Los autores anotaron más de 1.600 trazas de ejecución de 7 frameworks multiagente populares y clasificaron los fallos en 14 modos recurrentes. Casi ninguno de ellos es "el modelo dio una respuesta incorrecta". Son cosas como definiciones vagas de roles (diseño del sistema), un agente ignorando lo que otro agente le dijo (desalineación entre agentes) y declarar éxito sin comprobar el resultado (sin verificación). La mayoría de los fallos viven en el harness: los prompts, la lógica de orquestación, las comprobaciones que faltan. Un modelo base más potente reduce estas cifras, pero no puede arreglar un paso de verificación que nunca se construyó. Por eso tienes que evaluar el harness, no solo el modelo que hay dentro.

La brecha de adopción

La mayoría de los equipos ya tienen la materia prima para mejores evaluaciones. Tienen trazas. Simplemente no las han convertido en tests.

La encuesta State of Agent Engineering de LangChain es la foto pública más clara de esta brecha. Informa de que el 57,3% de quienes respondieron ya tienen agentes en producción, el 89% tiene algún tipo de observabilidad, el 52,4% ejecuta evaluaciones offline y el 37,3% ejecuta evaluaciones online. Y cuando se preguntó qué bloquea la producción, el 32% de quienes respondieron señaló la calidad, por delante de la latencia, con un 20%. Lo que miden las evaluaciones es precisamente lo que está bloqueando a los equipos.

Eso deja a los equipos en un estado intermedio incómodo: pueden inspeccionar una ejecución mala a posteriori y luego seguir desplegando el mismo fallo dos veces.

Una regla lo arregla: cada fallo de producción diagnosticado debe dejar detrás una traza, una etiqueta, una fila de dataset y un scorer. Si puede volver a ocurrir, pertenece a la suite de regresión.

Elige métricas según el modo de fallo

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

  1. Evaluaciones de resultado responden a si la tarea tuvo éxito.
  2. Evaluaciones de trayectoria responden a si la ruta fue válida, eficiente y conforme a la política.
  3. Evaluaciones de componentes responden a qué herramienta, retriever, subagente o paso de decisión se rompió.

Tres niveles de evaluación de agentes con sus métricas

Cada ámbito puede ejecutarse offline (casos fijos y reproducibles antes del release) u online (muestras de trazas de producción después de la respuesta); la sección de guardrails de abajo cubre esta división en detalle. La versión corta: las evaluaciones offline pueden exigir golden cases, mientras que las online deberían preferir invariantes, distribuciones y comprobaciones asíncronas que se mantengan fuera del request path.

Pregunta Familia de métricas Contrato offline / online ¿Determinista o juez? Ojo con
¿Llamó el agente a las herramientas correctas? Corrección de herramientas: coincidencia exacta, en orden o en cualquier orden Goldens exactos offline; invariantes de herramienta obligatoria y anomalías online Determinista La coincidencia exacta castiga rutas alternativas válidas
¿Las llamó con las entradas correctas? Corrección de argumentos, validación de esquema, coincidencia de parámetros Argumentos esperados offline; comprobaciones de esquema, rango y política online Ambos Herramienta correcta con argumentos erróneos sigue estando mal
¿Desperdició pasos? Eficiencia de pasos, recuento de reintentos, detección de bucles, coste y latencia Presupuestos de pasos y bucles offline; deriva de coste y latencia online Mayoritariamente determinista Una alta finalización de tareas puede ocultar deambulación costosa
¿La tarea tuvo realmente éxito? Finalización de tarea, evaluación de resultado, diff del estado final Simulador o estado golden offline; estado final, señal del usuario o juez asíncrono online Juez o comprobación de estado Evalúa el estado del entorno cuando sea posible
¿Mantuvo el contexto entre turnos? Fidelidad multi-turno, adherencia al rol, completitud de la conversación Casos guionizados de horizonte largo offline; sesiones largas muestreadas online Juez Los tests de un solo turno no dicen nada sobre el turno 14
¿Se detuvo en el momento correcto? Corrección de terminación, éxito prematuro, trabajo infinito Tests de escenario offline; monitores de bucle, timeout y falso éxito online Ambos "Hecho" puede ser un estado alucinado
¿Interpretó correctamente los resultados de las herramientas? Comprensión del resultado de la herramienta, comprobaciones de estado aguas abajo Salidas adversarias de herramientas offline; comprobaciones de estado aguas abajo y revisión muestreada online Ambos La herramienta puede ser correcta mientras el agente la lee mal

Empieza con métricas deterministas. Son baratas, rápidas y no derivan.

Corrección de llamadas a herramientas

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

  • Coincidencia exacta: la secuencia debe coincidir exactamente. Úsalo 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 extra inocuas.
  • Coincidencia en cualquier orden: las herramientas obligatorias deben aparecer, pero el orden puede variar.

Un scorer local pequeño basta para empezar:

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":
        return len(set(expected) & set(called)) / len(set(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 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 herramienta correcta con argumentos incorrectos suele ser peor que llamar a la herramienta equivocada porque la traza parece normal.

Para casos simples, valida el esquema JSON y los valores exactos. Para casos semánticos, guarda 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 de nombre de herramienta no puede detectar 2026-06-17 cuando la política exige 2026-06-19. El dataset también tiene que almacenar los argumentos.

Eficiencia, bucles y callejones sin salida

La ruta importa incluso cuando se alcanza el destino. Un agente que completa la tarea después de cinco llamadas redundantes a herramientas 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 de herramienta idénticas con argumentos idénticos repetidas más de dos veces.
  • Anomalías de forma de la traza: picos repentinos en profundidad, número de llamadas a herramientas, número de tokens, latencia o coste.
  • Convergencia de ruta: cuánto se acerca la ejecución a la ruta válida más corta conocida para la tarea.
  • Corrección de terminación: si el agente se detuvo demasiado pronto, siguió trabajando después del éxito o declaró éxito sin el cambio de estado requerido.

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

Finalización de tarea y evaluación del resultado

Extremo a extremo, la pregunta es "¿obtuvo el usuario lo que pidió?"

Dos patrones funcionan mejor:

  • Evaluación de finalización de tarea sin referencia: extrae el objetivo de la entrada y evalúa si la traza más la respuesta final lo lograron. Esto funciona online porque el tráfico de producción rara vez tiene salidas golden.
  • Evaluación por estado del entorno: compara las filas finales de la base de datos, archivos, tickets, reservas o registros con un estado objetivo anotado. Esto es más robusto que comparar transcripciones porque los agentes pueden encontrar rutas válidas que tú no dejaste escritas.

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

El flywheel de traza a evaluación

No empieces ideando primero tu conjunto de evaluación. Extrae fallos de producción.

El flywheel de traza a evaluación

El bucle:

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

Extrae fallos con análisis de errores

Hamel Husain y Shreya Shankar enseñan un flujo de trabajo de análisis de errores precisamente para este paso; la guía de campo de Hamel lo recorre. Los dos primeros pasos toman sus nombres de la investigación cualitativa, pero el método es sencillo: lee trazas, toma notas, pon nombre a los patrones.

  1. Open coding: lee de 30 a 50 trazas reales y escribe notas libres sobre qué salió mal.
  2. Axial coding: agrupa esas notas en 5 o 6 categorías de fallo con nombre.
  3. Etiquétalo todo según la taxonomía.
  4. Construye métricas para los grupos más grandes.

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

Deduplica antes de promocionar

El bucle de minería de trazas tiene una trampa: añadir todas las trazas malas para siempre. Eso crea un dataset grande, caro y estrecho. Aprueba sobre casi duplicados de marzo mientras se pierde la nueva forma del mismo bug en junio.

Agrupa primero. Promociona un golden representativo por clúster. Guarda los IDs de las trazas relacionadas en los metadatos para que una persona revisora pueda inspeccionar más tarde la evidencia de producción.

Si un clúster de fallo reaparece después de una corrección, el caso de regresión no generalizó. Reagrupa y amplía el golden en lugar de añadir 15 ejemplos puntuales.

Versiona el dataset

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

La puerta de CI debería fijar:

  • versión del dataset
  • versión de la app
  • versión del prompt
  • modelo del juez
  • prompt del juez
  • versión del código del evaluador

Si cualquiera de esas piezas se mueve, la comparación antes/después se ensucia. Un archivo goldens-v3.json en git está bien a pequeña escala. Los snapshots nativos de herramienta en Langfuse, Phoenix, Braintrust o LangSmith ayudan cuando el dataset pasa a ser colaborativo.

Pon una puerta en CI

Una métrica que falla debe convertirse en un build que falla, o la suite de evaluación es solo un dashboard que nadie lee.

El test debe volver a ejecutar el agente actual contra la entrada golden. No debería limitarse a reproducir la vieja traza fallida:

@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)

Esta distinción es fácil de pasar por alto. El trabajo del dataset es detectar que la siguiente versión del agente 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ñarte con ello.

La idea tiene recorrido. G-Eval mostró que un juez que recorre explícitamente una rúbrica paso a paso sigue mejor las valoraciones humanas que las métricas automáticas antiguas a las que sustituyó. MT-Bench mostró que GPT-4 coincidía con las preferencias humanas aproximadamente tanto como coinciden las personas entre sí, y eso fue lo que hizo mainstream la evaluación con LLM. Luego llegaron los matices: los jueces favorecen la respuesta que aparece primero en un prompt por pares, puntúan más alto las respuestas más largas, prefieren salidas de su propia familia de modelos y cambian cuando cambia el prompt o la versión del modelo. JudgeBench evaluó jueces sobre pares de respuestas en los que una de las respuestas es objetivamente incorrecta y encontró que incluso los jueces potentes rondan una precisión cercana al cara o cruz en los casos difíciles.

Trata al juez como un instrumento de medida.

Cuando se necesite un juez, estructura el veredicto. Schema-Guided Reasoning (SGR) es aquí el patrón por defecto: define la ruta de razonamiento del juez como un esquema Pydantic, ejecútalo mediante Structured Outputs o constrained decoding, y fuerza al modelo a emitir campos como evidence, passed_criteria, failed_criteria, failure_mode y score.

Eso no hace que el juez sea mágicamente correcto. Sí hace que la medición sea más reproducible. El juez tiene que recorrer los mismos pasos predefinidos de la rúbrica, en el mismo orden de campos, en cada ejecución y en cualquier modelo compatible. Una persona revisora puede inspeccionar campos con nombre en lugar de analizar un párrafo. CI puede hacer diff de un objeto JSON estable. La calibración resulta más fácil porque la rúbrica ya no está enterrada dentro de prosa libre.

También cambia la curva de coste. Cuando la topología de razonamiento es explícita y la salida está restringida, modelos más baratos suelen ser suficientemente buenos para evaluaciones rutinarias. Reserva el juez más grande para desacuerdos, casos de alto riesgo o ejecuciones de calibración en lugar de pagarlo en cada traza.

Bucle de calibración del juez

Sesgo Qué ocurre Mitigación
Posición Los prompts por pares favorecen una posición Intercambia el orden y promedia ambas permutaciones
Verbosidad Las respuestas más largas puntúan más alto aunque la calidad no cambie Penaliza la verbosidad no respaldada en la rúbrica
Autopreferencia Un juez favorece su propia familia de modelos Usa una familia de modelos distinta o un jurado
Complacencia El juez da crédito a afirmaciones no verificadas Exige evidencia de la traza en el veredicto
Deriva de calibración Una actualización del modelo o del prompt cambia las puntuaciones Fija modelo y prompt del juez; recalibra cuando cambien

Checklist por defecto de higiene del juez:

  1. Prefiere aprobado/suspenso binario cuando sea posible. Las escalas de cinco puntos invitan a una falsa precisión.
  2. Etiqueta manualmente de 30 a 50 trayectorias antes de redactar la rúbrica final.
  3. Mide el acuerdo juez-humano con el kappa de Cohen o con TPR/TNR simple.
  4. Descompón criterios amplios. "¿Verificó el agente la identidad antes de la llamada a la herramienta de reembolso?" es mejor que "¿Fue buena la trayectoria?".
  5. Emite el veredicto mediante un esquema SGR con evidencia, criterios fallidos, modo de fallo y puntuación.
  6. Usa, cuando sea posible, un juez de una familia de modelos distinta a la del generador.
  7. Aleatoriza el orden por pares y promedia ambas direcciones.
  8. Fija modelo del juez, prompt, dataset, esquema y versión de la app.
  9. Recalibra tras cambios de modelo, prompt, herramienta, política o esquema.

Para puntuaciones de alto riesgo, usa un jurado pequeño en lugar de un único gran juez. PoLL probó exactamente esta configuración: un panel de jueces más pequeños extraídos de familias de modelos disjuntas, con sus veredictos agregados en una sola puntuación. En seis datasets, el panel siguió mejor los juicios humanos que un único juez GPT-4, evitó el sesgo de autopreferencia que arrastra un juez aislado hacia la salida de su propia familia y costó más de siete veces menos. Mantén la revisión humana para decisiones que afecten a dinero, acceso, seguridad o compliance.

Si un juez coincide con humanos con un kappa de 0,55 en tu tarea, no lo uses para bloquear despliegues. Úsalo para ordenar colas de revisión. Si se sitúa cerca de 0,75 y el coste del fallo es moderado, una puerta de CI es mucho más defendible.

Las evaluaciones online no son guardrails

La gente mezcla estas cosas porque ambas producen puntuaciones. Están en sitios distintos.

Guardrails frente a evaluaciones online

Los guardrails se ejecutan en línea. Son rápidos, deterministas y visibles para el usuario. Un guardrail puede bloquear una llamada a herramienta, redaccionar PII, rechazar prompt injection o forzar un reintento antes de que la respuesta salga de tu sistema. Un falso positivo es un bug en producción.

Las evaluaciones offline se ejecutan antes del release. Son reproducibles. Ponen una puerta a 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 trabajo es detectar deriva, encontrar nuevos clústeres de fallo y alimentar el siguiente dataset offline.

Colocarlo mal duele en cualquiera de los dos sentidos:

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

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

Elecciones de tooling

Ninguna herramienta cubre por sí sola todo el bucle. La mayoría de los stacks serios usan dos piezas: un almacén de trazas y un runner de CI/evaluación.

Herramienta Mejor encaje Historia en CI Historia de self-hosting Trade-off
DeepEval Evaluaciones nativas de Pytest para agentes y LLM Fuerte: deepeval test run encaja en CI La librería base es local/open source Las llamadas al juez y las funciones cloud pueden añadir coste
Inspect AI Evaluaciones de seguridad, frontier y en sandbox CLI y API de Python Totalmente local/open source No es una plataforma de trazas de producción
Phoenix Trazado OTel/OpenInference más evaluaciones Scripts personalizados Opción self-host fuerte La alerta gestionada vive en la capa comercial
Langfuse Almacén de trazas, datasets, versiones de prompts Experimentos y puertas personalizadas Opción self-host fuerte Las métricas de evaluación vienen menos completas que en DeepEval
LangSmith Trazado y evaluaciones de LangChain/LangGraph pytest, Vitest, workflows de GitHub Self-host empresarial Código cerrado; vigila el precio por asiento y por volumen de trazas
Braintrust Bucle de producto guiado por evaluación y revisión de PR Flujo gestionado de regresión en PR muy fuerte Empresarial/híbrido El volumen de spans, los datos procesados y el número de puntuaciones pueden acumularse
Promptfoo Tests de prompts y suites de red-team GitHub, GitLab, Jenkins, CircleCI Núcleo local/open source Gran runner pre-release, no un hub de trazas

Las notas de trade-off describen de dónde viene el coste, no cuál es. Las páginas de precios cambian, y cada proveedor cuenta cosas distintas: trazas, observaciones, spans, puntuaciones, usuarios, retención o datos procesados. Revisa los precios vigentes antes de comprometerte.

Atajos de decisión:

  • Si necesitas trazado self-hosted con portabilidad OTel: empieza por Phoenix o Langfuse.
  • Si necesitas una puerta de CI code-first: empieza por DeepEval.
  • Si ya estás comprometido con LangGraph: LangSmith es cómodo.
  • Si quieres revisión gestionada de regresión en PR: Braintrust es difícil de superar.
  • Si dominan los casos de seguridad y red-team: Promptfoo es la herramienta enfocada.
  • Si haces investigación en seguridad o trabajo de benchmark controlado: Inspect AI encaja mejor.

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

Un checklist práctico de despliegue

Antes de que la implementación se vuelva sofisticada, construye la canalización de evidencia. La primera pregunta no es "¿qué métrica deberíamos optimizar?" Sino "¿de dónde van a salir los ejemplos?"

  1. Recoge primero ejecuciones históricas. Si el agente ya existe, extrae trazas, tickets de soporte, informes de bugs, sesiones con pulgar abajo, transcripciones de QA manual y notas de dogfooding antes de cambiar la implementación. Si el agente aún no existe, registra desde el primer día cada prototipo y cada ejecución de prueba manual.

  2. Instrumenta la forma de la traza. Captura mensajes, llamadas a herramientas, argumentos, salidas de herramientas, errores, recuentos de tokens, latencia, coste, feedback del usuario, versión de la app, versión del prompt, versión del modelo, versión del esquema de la herramienta y estado final del entorno. Usa las convenciones GenAI de OpenTelemetry o spans estilo OpenInference si quieres portabilidad. Usa Langfuse, LangSmith, Phoenix o Braintrust si quieres una UI de trazas y un flujo de trabajo de datasets inmediatamente.

  3. Convierte fallos reales en casos semilla. Lee las trazas antes de resumirlas con un modelo. Para cada fallo útil, guarda la entrada, el ID de la traza de origen, el estado esperado, las invariantes esperadas de herramientas, el modo de fallo, la severidad y la nota de la persona revisora. Langfuse puede enlazar elementos del dataset de vuelta a 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 histórico, genera casos de arranque en frío. Pide a un LLM que redacte tareas a partir de requisitos de producto, políticas, esquemas de herramientas, máquinas de estados y macros de soporte. Genera tanto happy paths como casos de "esto no debería pasar": permisos incorrectos, comprobaciones de identidad ausentes, resultados obsoletos de herramientas, fechas ambiguas, reintentos tras rate limits y salidas de herramientas que contradigan la petición del usuario.

  5. No confíes en casos sintéticos hasta que una persona los revise. Los ejemplos sintéticos sirven para cobertura, no para verdad. Márcalos con source: synthetic, exige que una persona revisora apruebe el resultado esperado, ejecuta una ruta de referencia conocida como buena cuando sea posible y evita usar la misma familia de modelos para generar el caso y juzgar el resultado.

  6. Construye un dataset pequeño y equilibrado. Incluye éxitos, fallos, rechazos, casos límite, casos de muchos turnos, casos sensibles a políticas y rutas alternativas válidas. No conviertas el golden en "la transcripción exacta antigua". El golden debe codificar el resultado requerido, las invariantes permitidas y el modo de fallo.

  7. Añade primero comprobaciones deterministas. El orden obligatorio de herramientas cuando el orden es política, los argumentos obligatorios, la validación de esquema, los diffs de estado final, los límites de bucles, los techos de tokens y latencia y las invariantes específicas de la tarea deberían ejecutarse antes que cualquier juez.

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

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

Tu primera suite de evaluación estará mal en formas aburridas. Desplíegala igualmente. Una suite que ejecutas cada día es más fácil de arreglar que un documento de diseño perfecto que nunca bloquea una PR mala.

Ideas clave

  1. Las evaluaciones de agentes son evaluaciones de trazas. La respuesta final es solo un nodo de la ejecución.
  2. La selección de herramientas, la corrección de argumentos, la detección de bucles, la finalización de tareas y la fidelidad multi-turno deben vivir en métricas separadas.
  3. El flywheel de producción es traza -> etiqueta -> clusteriza -> deduplica -> dataset -> puerta de CI -> puntuación online.
  4. Empieza por lo determinista. Las comprobaciones de herramientas, argumentos, estado y detectores de bucles son más baratas y más estables que los jueces.
  5. Los jueces LLM necesitan estructura y calibración. Usa SGR para veredictos reproducibles e inspeccionables, y luego fija el modelo del juez, el prompt, el esquema, la versión del dataset, la versión de la app y la muestra de etiquetas humanas.
  6. Las evaluaciones offline ponen una puerta a casos conocidos antes del release. Las evaluaciones online extraen muestras de trazas de producción después de la respuesta. Los guardrails bloquean comportamiento inseguro en línea.
  7. La mayoría de los equipos necesitan un almacén de trazas y un runner de CI. Elige herramientas aburridas que conviertan rápido los fallos de producción en tests de regresión.

Referencias