Trace grading vs. scenario testing para agentes de IA en producción

Al 30 de marzo de 2026, mi lectura de la documentación oficial de LangWatch, LangSmith y Langfuse es que la evaluación de agentes se está expandiendo de la calificación de la respuesta final hacia el trace grading: la calificación de traces, spans, llamadas a herramientas y trayectorias, no solo del último mensaje. Esa afirmación es mi inferencia editorial a partir de las capacidades actuales de los productos, no un benchmark estandarizado de la industria.

La razón es simple: los agentes no solo generan respuestas. Son sistemas que toman decisiones. Una respuesta final puede parecer correcta mientras que la ejecución que la produjo es ineficiente, frágil, insegura o está a una edición del prompt de fallar.

TL;DR

Las comprobaciones solo del resultado final califican la respuesta final. Siguen siendo útiles, pero pasan por alto muchas fallas de los agentes.
El trace grading califica la ruta de ejecución: la elección de herramientas, sus argumentos, la calidad de la recuperación de información, las decisiones intermedias, la latencia, el costo y la transferencia de control.
El scenario testing sigue siendo esencial porque permite ensayar el comportamiento en conversaciones de múltiples turnos antes de una versión.
El patrón que suele funcionar en producción es usar ambos, no elegir entre uno u otro:
- Pruebas de escenarios para el comportamiento antes de la versión
- Trace grading para la calidad en producción
LangWatch es la plataforma que más apuesta por las pruebas de agentes basadas en simulación.
LangSmith es muy sólido en evaluaciones offline y online, evaluación de trayectorias y flujos de revisión humana.
Langfuse es especialmente sólido si buscas un stack de observabilidad y calificación de código abierto, que puedas alojar por tu cuenta y que esté centrado en traces y evaluaciones paso a paso.

Qué aprenderás aquí

Por qué la evaluación basada solo en el resultado final se queda corta para los agentes en producción
Qué significa realmente el trace grading en la práctica
Cómo se complementan el scenario testing y el trace grading
Un stack práctico de evaluación para equipos con participación de ingenieros y PMs
Cómo se comparan LangWatch, LangSmith y Langfuse al 30 de marzo de 2026
Por dónde empezar si tu equipo todavía evalúa a los agentes principalmente por intuición

Por qué importa ahora

Están ocurriendo tres cosas al mismo tiempo:

Cada vez más equipos ponen en producción agentes que toman decisiones intermedias, no solo generan respuestas finales.
Cada vez más regresiones de calidad se manifiestan como rutas incorrectas dentro de un flujo de trabajo, no como texto final claramente incorrecto.
Cada vez más plataformas de evaluación ofrecen formas de calificar directamente traces, runs, spans, observaciones y trayectorias.

Esa combinación cambia el trabajo de evaluación. La pregunta ya no es solo «¿Fue buena la respuesta?». También es «¿Fue confiable la ejecución?».

Por qué la evaluación basada solo en el resultado final se queda corta

Si solo calificas la última respuesta, pierdes de vista el proceso que la produjo.

Imagina un agente de soporte que atiende una solicitud de reembolso:

Recupera el documento de políticas equivocado.
Llama a la herramienta de reembolsos antes de verificar la cuenta.
Reintenta la misma herramienta dos veces porque el ciclo del prompt es inestable.
Aun así, termina con una respuesta amable que suena plausible.

Un evaluador que solo revise el resultado final podría calificar esa respuesta como «mayormente correcta». En producción, sin embargo, importa más que el estilo:

¿El agente eligió la herramienta correcta?
¿Pasó los argumentos correctos?
¿Usó el contexto correcto?
¿Tomó demasiados pasos?
¿Siguió una ruta riesgosa aunque la respuesta final pareciera correcta?

Esa es la razón principal por la que importa el trace grading.

Trace grading vs. scenario testing

Son conceptos relacionados, pero resuelven problemas distintos.

Scenario testing

El scenario testing plantea preguntas como estas:

¿Puede este agente manejar una conversación realista de múltiples turnos?
¿Hace preguntas de aclaración en el momento adecuado?
¿Se recupera ante la ambigüedad, una negativa o una falla de una herramienta?
¿Sigue teniendo sentido su comportamiento general después de un cambio de modelo o de prompt?

Esto es un ensayo. Se parece más a una prueba de comportamiento de extremo a extremo.

Simulated user
    |
    v
Agent under test
    |
    v
Judge / rubric
    |
    +--> pass / fail / continue

Trace grading

El trace grading plantea preguntas como estas:

En este trace real de producción, ¿qué tan bueno fue cada paso?
¿Fue relevante el span de recuperación de información?
¿Fue adecuada la decisión de qué herramienta usar?
¿La respuesta final fue coherente con la ruta seguida?
¿Están cambiando la calidad, el costo y la latencia con el tiempo?

Esto es una calificación operativa. Se parece más a la observabilidad en producción combinada con evaluación.

Live traffic
    |
    v
Trace
  +-- span: retrieval
  +-- span: tool choice
  +-- span: tool execution
  +-- span: final answer
    |
    v
Per-step graders + user feedback + dashboards
    |
    v
Scores, alerts, annotations, datasets

En pocas palabras

El scenario testing te dice si el agente puede comportarse bien en una situación ensayada.
El trace grading te dice si el agente se está comportando bien en condiciones reales.

Para los equipos de producción, esa es la diferencia entre la confianza antes de la versión y el control después de la versión.

Qué significa realmente evaluar con traces

El trace grading significa que tu objetivo de evaluación no es solo la cadena de texto final. Es la estructura de ejecución que hay detrás.

En el caso de los agentes, eso suele implicar calificar alguna combinación de lo siguiente:

Capa	Preguntas de ejemplo
Respuesta final	¿La respuesta fue correcta, útil, segura y coherente con la marca?
Elección de herramienta	¿El agente eligió la herramienta o el flujo de trabajo correcto?
Argumentos de la herramienta	¿Los parámetros estaban completos y eran correctos?
Recuperación de información	¿Recuperó los documentos o registros correctos?
Trayectoria	¿La secuencia de acciones tuvo sentido?
Costo / latencia	¿La ruta fue lo suficientemente eficiente para producción?
Retroalimentación humana	¿Los usuarios y revisores coincidieron con las calificaciones automatizadas?

Esto es especialmente importante para los agentes porque muchas fallas son fallas del proceso antes de hacerse visibles en la respuesta.

Las fallas que pasan por alto las comprobaciones del resultado final

Estos son algunos casos comunes que pasan desapercibidos:

Tipo de falla	Por qué no la detectan las comprobaciones del resultado final	Por qué la detecta el trace grading
Herramienta equivocada, respuesta correcta por suerte	El texto final sigue sonando correcto	El trace muestra la llamada incorrecta a la herramienta
Reintentos excesivos	El texto final todavía puede estar bien	El trace muestra un ciclo ineficiente
Recuperación de información deficiente	El evaluador puede recompensar una paráfrasis bien redactada	El span de recuperación se puede calificar directamente
Incidente de seguridad que casi ocurre	La respuesta final oculta una acción intermedia incorrecta	La evaluación a nivel de span expone el paso riesgoso
Regresiones después de editar el prompt	El resultado final varía de forma sutil	Las métricas del trace muestran cambios en la selección de herramientas y pasos adicionales

Por eso no presentaría el trace grading como un reemplazo del scenario testing. Lo presentaría como la capa de producción que falta y que las comprobaciones del resultado final no pueden cubrir por sí solas.

Un stack práctico de evaluación para agentes en producción

El stack más útil que he visto es:

                 PRODUCTION AGENT QUALITY LOOP

  Unit tests
      |
      v
  Dataset evals on components
      |
      v
  Scenario tests on full agent behavior
      |
      v
  Release
      |
      v
  Production traces
      |
      +--> trace grading
      +--> alerts
      +--> human annotation
      |
      v
  Promote bad traces into datasets and scenarios
      |
      v
  Re-run evals before next release

En términos sencillos:

Las pruebas unitarias protegen el código determinista.
Las evaluaciones de datasets califican componentes y prompts.
Las pruebas de escenarios ensayan el comportamiento del agente antes de una versión.
El trace grading monitorea el comportamiento real después de una versión.
La revisión humana calibra los evaluadores automatizados.
Los traces problemáticos de producción se convierten en las pruebas offline del mañana.

Ese ciclo es el punto en el que la evaluación empieza a convertirse en un sistema de ingeniería en lugar de un ritual para demos.

Ejemplo de código: califica el trace, no solo la respuesta

Este es el modelo mental más simple, en pseudocódigo similar a Python:

def handle_refund_request(user_input: str):
    trace = start_trace(name="refund-agent")

    retrieval = start_span(trace, name="policy_lookup")
    policy_docs = search_policy_docs(user_input)
    retrieval.score(
        name="retrieval_relevance",
        value=judge_retrieval(user_input, policy_docs),
    )

    planning = start_span(trace, name="tool_routing")
    action = choose_next_action(user_input, policy_docs)
    planning.score(
        name="tool_choice_correctness",
        value=judge_tool_choice(user_input, action),
    )

    execution = start_span(trace, name="tool_execution")
    result = run_action(action)
    execution.score(
        name="tool_argument_quality",
        value=validate_tool_args(action),
    )

    response = start_span(trace, name="final_response")
    answer = draft_user_response(user_input, result)
    response.score(
        name="answer_helpfulness",
        value=judge_answer(user_input, answer),
    )

    trace.score(name="workflow_efficiency", value=judge_efficiency(trace))
    return answer

La decisión de diseño importante es esta:

No esperes hasta la respuesta final para calificar la calidad.
Califica los pasos que importan para el riesgo de tu negocio.

En la práctica, las tres plataformas implementan este patrón de distintas maneras:

LangWatch permite asociar evaluaciones a traces y spans, además de ejecutar experimentos y simulaciones de agentes.
LangSmith admite evaluadores offline, evaluadores online sobre traces y evaluaciones de trayectorias de agentes.
Langfuse admite calificaciones en traces y observaciones, LLM-as-a-judge gestionado sobre traces de producción o desarrollo, y experimentos con datasets.

El scenario testing sigue siendo más importante de lo que muchos equipos creen

A menudo veo esta trampa:

El equipo agrega traces
El equipo agrega un evaluador de la respuesta final
El equipo declara que la evaluación está resuelta

Pero los agentes en producción suelen fallar durante la conversación, no solo en respuestas aisladas.

Ejemplos:

El agente debe hacer una pregunta de aclaración antes de reservar un vuelo.
El agente debe negarse a llamar a una herramienta que ejecuta acciones destructivas sin confirmación.
El agente debe recuperarse cuando una herramienta devuelve datos parciales.
El agente debe conservar el contexto durante múltiples turnos sin repetir trabajo.

Esos son problemas de escenario. Son difíciles de reducir a pares individuales de entrada y salida.

Aquí es donde las herramientas Scenario de LangWatch tienen un enfoque especialmente definido: consideran que la confiabilidad de un agente debe ensayarse mediante interacciones realistas, no solo calificarse después de los hechos. LangSmith también ofrece una sólida evaluación de agentes mediante evaluadores de trayectorias y evaluadores de pasos individuales o respuestas finales, pero su documentación se enfoca más en el ciclo de vida de la evaluación que en priorizar la simulación. Langfuse, según la documentación que revisé, destaca más en la calificación centrada en traces y los experimentos que en un flujo de simulación de escenarios propio de la plataforma.

Esa última comparación también es mi síntesis editorial de la documentación, no una afirmación de los proveedores.

LangWatch vs. LangSmith vs. Langfuse

La mejor opción depende de qué problema de evaluación te afecte más.

Herramienta	Dónde parece más sólida	Trace grading	Pruebas de escenarios / trayectorias	Revisión humana	Mejor opción para
LangWatch	Un stack para observabilidad, evaluaciones y pruebas de agentes con énfasis en simulación	Modelo sólido de evaluación de traces y spans, evaluaciones online y alertas	El enfoque más centrado en escenarios de los tres	Admite anotaciones	Equipos que quieren simulación y calificación en producción en un solo flujo de trabajo
LangSmith	Ciclo de vida de evaluación maduro, desde datasets offline hasta evaluadores online	Evaluadores online sólidos sobre traces y flujos de experimentación completos	Evaluación de trayectorias sólida; útil para comprobar las rutas del agente	Flujo sólido de colas de anotación	Equipos que ya usan LangChain/LangGraph o quieren operaciones de evaluación robustas
Langfuse	Observabilidad de código abierto, gestión de prompts y calificación basada en traces reales	Calificaciones sólidas en traces y observaciones, y LLM-as-a-judge gestionado sobre traces de producción	Buenos experimentos offline, pero menos centrado en escenarios en la documentación revisada	Admite colas de anotación	Equipos que quieren una evaluación centrada en traces, de código abierto y que puedan alojar por su cuenta

Mi lectura práctica

Elige LangWatch si la pieza que falta es «necesitamos mejores formas de ensayar y depurar el comportamiento completo de los agentes».
Elige LangSmith si la pieza que falta es «necesitamos un sistema disciplinado de evaluación offline, online, de trayectorias y con revisión humana».
Elige Langfuse si la pieza que falta es «queremos trazabilidad profunda en producción y calificación flexible en un stack de código abierto».

Si asesorara a un equipo que empieza desde cero, no preguntaría solo «¿Qué herramienta tiene evaluaciones?». Preguntaría:

¿Necesitamos más las simulaciones?
¿Necesitamos más las operaciones de trayectorias y evaluadores?
¿Necesitamos más la observabilidad en producción, de código abierto y centrada en traces?

Esa pregunta suele aclarar mucho la elección.

Dónde deben alinearse PMs e ingenieros

Este tema no es solo para ingenieros de plataforma.

A los PMs les importa:

Si el agente completa el flujo de trabajo que esperan los usuarios
Si las regresiones aparecen antes de que se acumulen los tickets de soporte
Si la calidad se puede explicar con dashboards, no con anécdotas

A los ingenieros les importa:

Si la lógica de selección de herramientas sufrió una regresión
Si los cambios en los prompts aumentaron los reintentos o el costo
Si las calificaciones bajas se pueden atribuir a un paso específico

El trace grading les da a ambos grupos una mejor base común:

Los PMs obtienen tendencias de calidad vinculadas a los recorridos de los usuarios
Los ingenieros obtienen los spans, pasos y criterios exactos detrás de esas calificaciones

Ese es un modelo de trabajo mucho más saludable que discutir sobre una captura de pantalla seleccionada a conveniencia en staging.

Por dónde empezar el lunes

Si tu equipo está empezando, haz esto:

Elige un flujo de trabajo importante en producción, como la gestión de reembolsos o la calificación de leads.
Define tres o cuatro criterios de evaluación a nivel de span:
- relevancia de la recuperación de información
- elección correcta de la herramienta
- utilidad de la respuesta final
- eficiencia del flujo de trabajo
Agrega revisión humana para los traces con calificaciones bajas.
Convierte los peores traces reales en datasets offline y pruebas de escenarios.
Solo entonces amplía la evaluación a más métricas.

Si intentas evaluarlo todo a la vez, crearás dashboards en los que nadie confía.

Si empiezas con un flujo de trabajo y un conjunto reducido de criterios, podrás mejorar el sistema.

Conclusión

La evaluación basada solo en el resultado final tenía sentido cuando muchas aplicaciones con LLM eran, básicamente, funciones de texto inteligentes.

Los agentes cambiaron las reglas del juego. Una vez que un sistema puede planificar, llamar a herramientas, tomar distintas rutas, reintentar y mantener estado, la respuesta final deja de contar toda la historia. La ruta de ejecución se convierte en parte del producto.

Por eso espero que más equipos de producción adopten el trace grading como una capa estándar de calidad de los agentes, mientras mantienen el scenario testing como la capa de ensayo que protege las versiones.

La verdadera elección no es entre trace grading o scenario testing.

La estrategia real en producción es:

usar scenario testing para ensayar el comportamiento antes de una versión
usar trace grading para controlar el comportamiento después de una versión

Trace grading vs. scenario testing: cómo evaluar agentes en producción