Tracing y monitoreo: cazar el degrade que un eval set no puede ver

Un eval set offline está congelado en el momento en que lo construís. Califica los casos que se te ocurrieron, contra respuestas que escribiste, antes de que nada de eso shippee — y eso es justo lo que lo vuelve un portón de regresión en el que podés confiar (eval datasets y métricas). Pero la parte congelada es también su punto ciego: producción manda tráfico que ningún eval set anticipó, fraseado de formas que nunca probaste, y el sistema que pasó cada caso offline puede empezar a empeorar a la intemperie sin que un solo test se ponga en rojo. El modelo de abajo recibe un upgrade, la distribución de inputs deriva a medida que llega una audiencia nueva, un servicio upstream cambia un campo — y el output se degrada mientras tu suite offline, por definición, sigue calificando los mismos casos en verde. Este es el degrade silencioso, y es la falla que la evaluación offline estructuralmente no puede cazar.

Esta página es la mitad de producción de la subcategoría. Donde qué es la evaluación trazó la línea entre offline y online, y llm-as-judge mostró el mismo judge corriendo en los dos modos, esta página construye el lado online: cómo trazás lo que pasó de verdad en producción, cómo evaluás tráfico en vivo, y cómo cazás el degrade antes que un cliente. Es el principio 11 hecho operacional — trazá todo, porque no podés debuggear, ni evaluar, lo que no podés reproducir — y es lo que convierte un sistema que era correcto en el launch en uno que sigue correcto un martes tres meses después.

Esta es una referencia para la disciplina en distintas superficies. El harness de online evaluators de abajo es el de LangSmith, el equivalente in-platform es el session tracing de Agentforce exportado a través de OpenTelemetry hacia Data 360; la disciplina se transfiere, los knobs exactos son de cada proveedor.

Tracing: un trace, spans adentro, por pedido

Antes de poder evaluar o debuggear un run de producción, lo tenés que haber capturado. Un trace es el registro de un único pedido de punta a punta; los spans adentro son los pasos individuales — la llamada de retrieval, la llamada al modelo, cada invocación de tool — cada uno con su propio timing y payload anidados bajo el trace. Un pedido de usuario produce un trace; todo lo que le pasó para servirlo vive en los spans de abajo. Sin ese registro, una queja sobre una respuesta mala el martes pasado no tiene respuesta: tenés el output y nada sobre cómo el sistema llegó a él.

La disciplina es loguear lo suficiente como para poder reconstruir el run entero desde el trace solo — reproducirlo en tu cabeza sin volver a correr nada. En concreto, eso es lo siguiente, capturado por pedido:

Qué loguear	Por qué importa
Input	El pedido tal como lo recibió el sistema — el prompt, el mensaje del usuario, los parámetros. El punto de partida de cualquier replay; sin él no podés distinguir si una respuesta mala vino de una pregunta mala o de un sistema malo.
Output	La respuesta final devuelta al usuario. Lo que se califica, y aquello de lo que se queja una queja.
Latencia	El tiempo de reloj del pedido, y por span. Costo y latencia son features (principio 6); una respuesta correcta que llega demasiado lento no resolvió el problema, y un desglose por span muestra cuál paso es el lento.
Costo y tokens	Tokens de input, output y cacheados, y el costo resultante. Te deja mirar la factura moverse con el tráfico y cazar un cambio de prompt que en silencio duplicó el uso de tokens antes que lo haga el invoice.
Llamadas a tools y actions	Cada tool que invocó el run, los argumentos que pasó, y lo que volvió. Cada tool es un radio de impacto (principio 5); el trace es el rastro de auditoría de lo que el agente hizo de verdad, no solo de lo que dijo.
Contexto recuperado	Los chunks o registros que el grounding trajo para este pedido. Cuando una respuesta es errónea pero fluida, la falla suele ser el retrieval, no el modelo — y eso solo lo ves si el trace muestra qué se le dio de verdad al modelo para trabajar.
Score de métrica / eval	El score que un online evaluator le asignó a este run, escrito de vuelta sobre el trace. Esto es lo que convierte una pila de logs en algo que podés graficar, alertar y filtrar.
Feedback del usuario	La señal de la persona del otro lado — un pulgar arriba/abajo, una respuesta aceptada o rechazada, una escalación a un humano, un re-fraseo y reintento. Ground truth que producción te da gratis, y el mejor filtro para qué traces vale la pena mirar de cerca.

El hilo de la tabla es el principio 11: cada fila es algo que vas a desear haber logueado la primera vez que un run salga mal y trates de reconstruirlo. La fila de contexto recuperado y la de llamadas a tools son las dos que los equipos saltean más seguido y lamentan más — son justo lo que necesitás para distinguir una falla de retrieval de una falla de razonamiento, y una tool que disparó mal de un modelo que alucinó haberla llamado. Logueálas en el momento de escritura; no las podés agregar a un trace después de que el pedido se fue.

Evaluación online: calificar tráfico en vivo, no un set congelado

El tracing te dice qué pasó. La evaluación online lo califica. El mismo judge o métrica del loop offline — un LLM-as-judge, un chequeo determinístico — corre sobre traces de producción en vivo en vez de sobre un eval set curado, dándote, en palabras de LangSmith, "feedback en tiempo real sobre tus traces de producción". La mecánica de llm-as-judge es idéntica; solo cambia la fuente del input — en vez de un caso que vos escribiste, el harness saca las variables de cada trace en vivo y se las pasa al judge a medida que el pedido fluye.

Dos controles hacen esto pagable y útil, y ponés los dos:

Filtrá qué runs calificar. No evaluás cada trace a ciegas. Un filtro decide qué runs disparan evaluación — LangSmith te deja filtrar sobre feedback de usuario que marcó una respuesta como insatisfactoria, sobre una invocación de tool específica, o sobre metadata custom como el tier de un cliente, y nota que "los filtros en los evaluators funcionan igual que cuando filtrás traces en un proyecto". Calificar los runs que un usuario ya marcó con pulgar abajo es mucha más señal que calificar una tajada al azar; el filtro es cómo apuntás el judge al tráfico que importa.
Poné un sampling rate. Incluso dentro del set filtrado, rara vez necesitás calificar cada llamada. El sampling rate fija qué fracción de los traces que matchean se evalúan de verdad — ponelo en 0.1 y solo el 10 por ciento de los traces que matchean se califican, lo que LangSmith documenta como la palanca para el manejo de costo. Una llamada al judge cuesta plata y suma latencia; el sampling rate es cómo comprás una señal estadísticamente útil sin pagar por calificar toda la producción. (Una nota operativa: LangSmith auto-promueve un trace a retención extendida cuando un online evaluator corre sobre él, así que los traces evaluados — los que más querés conservar — se preservan.)

El punto de la evaluación online no es calificar todo; es mantener una lectura continua y muestreada de la calidad a medida que fluye el tráfico real, para que el número que probó que el sistema funcionaba en el launch se siga calculando sobre el tráfico que el sistema sirve ahora.

Cazar el degrade silencioso: alertá sobre la caída, no sobre el crash

Acá está la falla para la que existe toda esta mitad de la subcategoría. Un crash te pagea — el pedido tira 500, la cola se traba, alguien se da cuenta en minutos. Un degrade silencioso no: nada explota, cada pedido devuelve una respuesta plausible, la latencia se ve bien, y el sistema está en silencio poniéndose peor. El score de faithfulness se resbala de 0.94 a 0.78 en una semana porque un upgrade de modelo corrió el comportamiento. La tasa de aceptación cae porque un segmento nuevo de clientes hace preguntas que el grounding nunca cubrió. Un servicio upstream empieza a devolver un campo en una forma nueva y el retrieval se degrada en silencio. Ninguno de estos es un error; todos son el sistema fallando en su trabajo real mientras el dashboard de infraestructura se queda en verde.

El eval set offline no puede cazar esto, porque está congelado — sigue calificando los mismos casos con los mismos scores, por construcción, sin importar lo que haga el tráfico de producción. Lo que lo caza es la métrica online, mirada en el tiempo: graficás el score del eval y las señales de producción (aceptación, escalación, latencia, costo) trace por trace, y alertás sobre una caída de la métrica, no sobre una excepción. Cuando el promedio móvil del judge de faithfulness cae por debajo de un umbral, eso dispara — igual que lo harían un pico de latencia o una tasa de error — y vos investigás antes de que el goteo de quejas se vuelva una inundación.

Este es el significado operativo del principio 1 — una demo no es un producto. La demo probó que el sistema podía hacer la cosa una vez; el monitoreo es lo que te dice que la sigue haciendo, sobre tráfico que nadie scripteó, sobre un modelo que se movió debajo tuyo. Un sistema sobre un modelo en movimiento se degrada en silencio por defecto; el trace más la métrica online más la alerta es el aparato que hace que el degrade sea ruidoso.

La composición: la misma disciplina, dos superficies

El tracing y la evaluación online son una disciplina que corre en dos lugares, elegidos — como siempre en este catálogo — según dónde corre el sistema, nunca como productos rivales entre los que elegir:

LangSmith — off-platform. Cuando el sistema corre sobre un control loop custom o un stack de LangGraph, LangSmith es donde aterrizan los traces y corren los online evaluators. Definís el judge, le enganchás un filtro y un sampling rate, y califica traces de producción en vivo para feedback en tiempo real, escribiendo el score de vuelta sobre cada trace donde lo podés graficar y alertar. Esta es la mitad online del mismo harness que corrió el eval offline en eval datasets y métricas — una herramienta, el lado del dataset y el lado de producción.
Agentforce — in-platform. Cuando el agente corre sobre Agentforce dentro del modelo de seguridad de Salesforce, el trace ya se está capturando: el session tracing registra turns, mensajes, llamadas al LLM, actions, scores de métricas y feedback — las mismas columnas que la tabla de arriba — dentro de Data 360. La API Export Session Tracing Data de Salesforce lo sirve como OpenTelemetry (OTLP) — extrae "unified trace, metric and log data" que cubre "cada paso de una interacción de un agente de Agentforce" y lo devuelve en formato OTel ResourceSpans, así que lo podés meter directo en una plataforma de observabilidad OTLP-nativa (Splunk, Datadog, New Relic) o en cualquier collector OTLP sin paso de conversión. Los scores de calidad viajan en el mismo export, así que la historia de monitoreo es la misma que off-platform — score en el tiempo, alerta sobre la caída — solo que el trace se origina dentro de la plataforma y sale a través de un estándar en vez de vivir en un harness aparte.

No elegís una y le jurás lealtad. Un agente construido en Agentforce y groundeado sobre Data 360 se traza y se califica dentro de la plataforma, con su export OTel alimentando tu stack central de observabilidad; un sistema Claude-más-LangGraph off-platform se traza y se evalúa online en LangSmith. Un equipo que corre los dos monitorea cada sistema donde corre y mira las mismas dos cosas en ambos: la métrica en el tiempo, y la alerta cuando cae. La disciplina — trazá cada pedido, evaluá una tajada muestreada de tráfico en vivo, alertá sobre el degrade — es idéntica; la superficie solo decide dónde se origina el trace y qué harness lo sostiene.

El hilo

La evaluación offline está congelada por diseño, que es lo que la vuelve un portón de regresión confiable y también lo que la deja ciega al degrade silencioso — el upgrade de modelo, el shift de distribución, el cambio upstream que mueve el output mientras cada caso offline se queda en verde. La observabilidad de producción es la otra mitad. Trazá cada pedido — input, output, latencia, costo y tokens, llamadas a tools, contexto recuperado, el score del eval, feedback del usuario — para que cualquier run se pueda reconstruir desde el trace solo. Corré un judge o una métrica sobre traces en vivo para feedback en tiempo real, filtrado a los runs que importan y muestreado para no calificar cada llamada. Después graficá el score en el tiempo y alertá sobre una caída de la métrica, no sobre un crash, porque el degrade que más te cuesta es el que nunca tira un error. Hacelo en LangSmith off-platform o a través del export OTel de Agentforce hacia Data 360 in-platform — la misma disciplina, dos superficies. El eval offline prueba que el sistema era lo bastante bueno para shippear; el tracing y el monitoreo es cómo sabés que siguió bueno una vez que lo hizo.

LLM-as-judge — el mismo judge, corrido online sobre traces en vivo; su sección de offline-y-online es el puente hacia esta página
Qué es la evaluación — la división offline/online de la que esta página construye la mitad online
Eval datasets y métricas — el harness offline cuya contraparte online corre acá, sobre la misma superficie de LangSmith
Gotchas de evaluación — las formas en que el monitoreo mismo te engaña, y cómo leer un movimiento de métrica con honestidad
Testing y observabilidad de Agentforce — la superficie in-platform desde la que esta página exporta, en profundidad
Debugging de evals — qué hacés una vez que una métrica cae y abrís el trace para averiguar por qué
Style Guide de evaluación — la vara que un online evaluator supera antes de que confíes en sus scores lo bastante como para alertar sobre ellos
Debugging de agentes — leer el trace de un único run malo, la vista por pedido que esta página agrega
Tools y actions — cada llamada a tool que registra el trace es un radio de impacto que el rastro de auditoría existe para cubrir
Qué es el grounding — el contexto recuperado que loguea el trace, para que puedas distinguir una falla de retrieval de una de razonamiento
Principios de AI Engineering — trazá todo (11), una demo no es un producto (1), costo y latencia son features (6)

Reference: