En producción no basta con ver la respuesta final. Necesitas la traza completa: entrada, contexto recuperado, herramienta, argumentos, salida, latencia y coste.
La traza
Una traza es el registro completo de una ejecución. Incluye la petición del usuario, el contexto que se recuperó, las instrucciones que se enviaron al modelo, las herramientas que se llamaron, los argumentos, los resultados, la respuesta final y el tiempo de cada paso. Sin eso, solo ves el final.
En un sistema con varias llamadas, la traza es la forma más directa de saber dónde se rompió. Quizá la recuperación trajo el documento correcto, pero el modelo lo ignoró. Quizá la herramienta devolvió un error y el agente lo ocultó. La respuesta final no te lo dice.
Métricas
Las métricas que importan son las del trabajo: cuántos casos se resuelven, cuántos se derivan, cuánto tardan, cuánto cuestan y cuántas veces interviene una persona. También las de calidad: errores por tipo, casos sin respuesta, respuestas corregidas. Las métricas del modelo, como los tokens, son contexto, no el objetivo.
Mide por segmento. Un sistema puede ir bien en general y fallar en un tipo de cliente, un canal o un idioma. El promedio esconde los problemas. Separar por caso de uso te dice dónde mirar.
Feedback
El feedback del usuario es útil, pero llega poco y sesgado. La gente que está contenta no suele responder. La que está enfadada, sí. Combina el feedback explícito con la revisión de trazas y con las métricas de resultado. Ninguna fuente sola cuenta la historia.
Guarda el feedback junto a la traza. Si alguien marca una respuesta como incorrecta, quieres ver qué contexto tenía el sistema y qué herramienta llamó. Sin esa conexión, el feedback es una queja sin diagnóstico.
Evaluación en producción
Puedes evaluar una muestra de las trazas reales con un juez automático y con revisión humana. No necesitas evaluar todo. Necesitas una muestra suficiente para detectar regresiones y casos nuevos. Esas trazas se convierten en casos para la suite de evals.
La evaluación en producción no sustituye a la evaluación previa. La complementa. En producción aparecen casos que no imaginaste. La observabilidad es la forma de encontrarlos.
Privacidad
Las trazas contienen datos reales. Si guardas todo, puedes estar guardando información personal, conversaciones sensibles o datos de clientes. Define qué se guarda, durante cuánto tiempo y quién puede verlo. Redacta lo que no necesites y limita el acceso.
La observabilidad no sirve para acumular datos. Sirve para mejorar el sistema. Si no puedes guardar un dato, guarda la estructura y las métricas, o usa una versión seudonimizada.
Alertas
Una alerta tiene que avisar de algo que requiere acción. Un aumento de errores, una caída de la tasa de resolución, un coste por encima del presupuesto, una latencia que se dispara. Si la alerta no lleva a una decisión, es ruido.
También conviene una revisión periódica, aunque no haya alertas. Leer trazas cada semana es la forma de detectar lo que las métricas no capturan: respuestas raras, derivaciones innecesarias, clientes cuyo caso se cierra sin resolver.
Qué guardar en una traza
Una traza útil no guarda solo el texto de entrada y salida. Guarda el recorrido. Como mínimo: un identificador de la ejecución, la entrada del usuario, el contexto recuperado, la versión del prompt, las herramientas llamadas con sus argumentos y resultados, la respuesta final, la latencia por paso, el coste y el motivo de derivación si lo hubo.
Añade el feedback y el resultado del trabajo. Si la respuesta se envió, si la reserva se creó, si el cliente volvió a llamar. Sin esa última parte, sabes qué dijo el sistema, pero no si sirvió. La traza se convierte en una historia completa del caso.
Sigue leyendo