
Observabilidad de LLMs: ver qué hizo el modelo en cada petición
Registra cada petición a un LLM como traza: prompt, respuesta, herramientas, tokens, latencia y costo. Qué guardar y cómo usarlo para depurar y medir calidad.
¿Qué es una traza en un sistema con IA?
Una traza es la historia completa de una petición. Si el usuario pregunta por una cancelación, la traza muestra que el sistema recibió el mensaje, llamó al modelo con cierto prompt, el modelo pidió consultar una reserva, la herramienta devolvió un resultado y el modelo respondió. Cada paso tiene su duración y sus entradas y salidas, y los pasos están conectados entre sí.
La documentación de Langfuse describe el tracing como logs estructurados de cada solicitud, que registran el flujo de la petición por el sistema y preservan las relaciones causales entre operaciones. En su interfaz, esas operaciones aparecen anidadas, con tiempos, entradas, salidas y metadatos. LangSmith, de LangChain, define la traza de forma parecida: el registro de lo que hicieron tus agentes en producción, que se usa para depurar fallos, monitorear calidad y construir conjuntos de datos de evaluación.
¿Qué conviene registrar?
Una traza útil guarda, por lo menos:
- El prompt exacto que se envió, con la versión del prompt que estaba activa.
- La respuesta del modelo y el motivo por el que terminó (respuesta completa, límite de tokens, herramienta).
- Las llamadas a herramientas y recuperación de documentos, con sus entradas y resultados.
- Tokens de entrada y salida, para medir costo.
- Latencia de cada paso, para saber dónde se tarda.
- El identificador del modelo y de la versión de la aplicación, para comparar despliegues.
Sobre el costo, Langfuse explica que usa el costo que envíes con la respuesta del modelo y, si no hay ninguno, lo infiere multiplicando el uso de tokens que reportes por el precio del modelo en una tabla de definiciones. Por eso necesita que el proveedor o tu código informen los tokens: no los estima a partir del texto. Para entender por qué ese número importa, mira el costo por token.
¿Qué estándar existe para nombrar esos datos?
OpenTelemetry, el estándar abierto de telemetría, mantiene convenciones semánticas para IA generativa. Hoy viven en un repositorio propio (semantic-conventions-genai) y el índice marca el conjunto como Development, es decir, no estable. Cubren operaciones de inferencia, embeddings, ejecución de herramientas, recuperación y agentes, además de convenciones específicas para Anthropic, OpenAI, AWS Bedrock y Azure AI Inference. Algunos nombres de atributos de la página de inferencia:
| Qué registras | Atributo OpenTelemetry | Nivel |
|---|---|---|
| Tipo de operación | gen_ai.operation.name | Requerido |
| Modelo solicitado | gen_ai.request.model | Condicional |
| Tokens de entrada | gen_ai.usage.input_tokens | Recomendado |
| Tokens de salida | gen_ai.usage.output_tokens | Recomendado |
| Mensajes de entrada y salida | gen_ai.input.messages, gen_ai.output.messages | Opt-in |
Dos consecuencias prácticas. Primera: como el estándar aún no es estable, los nombres pueden cambiar, así que revisa la versión de tu librería de instrumentación antes de construir tableros sobre un atributo concreto. Segunda: el contenido de los mensajes es opt-in a propósito. La especificación advierte que esos campos probablemente contienen información sensible, incluidos datos personales.
La recomendación: usa un formato abierto cuando puedas, para no quedar atado a una sola herramienta.
¿Por qué le importa a un diseñador?
Porque la observabilidad es lo que permite diseñar la respuesta a los fallos. Si descubres que una herramienta hace una consulta lenta y eso retrasa muchas respuestas, puedes diseñar un estado de carga específico para ese paso. Si ves que el modelo reintenta una acción varias veces, puedes cambiar la interfaz para pedir confirmación.
También cambia la conversación con ingeniería. En vez de “el asistente anda raro”, el equipo puede señalar una traza concreta, su paso lento y su respuesta.
¿Cómo se usa para calidad?
Langfuse propone tres usos, que sirven de guía:
- Depurar. Según su documentación, depurar sin observabilidad se parece a adivinar. Con trazas, ves qué pasó en cada petición.
- Monitorear calidad. Asignar puntajes (scores) a las trazas y levantar alertas cuando una métrica cruza un umbral que tú defines.
- Evaluar. Las trazas de producción son datos reales para correr evals y mejorar el sistema de forma continua.
Hamel Husain y Shreya Shankar recomiendan, en su guía de evals, empezar con análisis de errores sobre salidas reales, revisadas a mano (hablan de 20 a 50), antes de recurrir a métricas genéricas. La observabilidad es la fuente de esas trazas.
¿Cuándo NO conviene?
- Cuando guardas el contenido completo sin decidir qué pasa con él. Los prompts y las respuestas pueden incluir nombres, teléfonos o datos de salud. Consulta privacidad en productos de IA.
- Cuando nadie revisa las trazas. Un tablero que nadie mira no mejora el producto.
- Cuando todo se registra sin filtrar. El ruido oculta los fallos que sí importan.
Ejemplo
Ejemplo ilustrativo: un asistente de una app de viajes recibe quejas de que “a veces tarda mucho”. El equipo activa trazas con latencia por paso y con la versión del prompt. En dos días ven que una parte de las peticiones pasa de 14 segundos, y que casi todo ese tiempo es una llamada a la herramienta de disponibilidad de vuelos, no el modelo. Con esa evidencia, el equipo cambia la interfaz: muestra un estado de carga con el nombre de la consulta que se está haciendo, y pide a ingeniería que guarde la disponibilidad en caché durante cinco minutos. Dos semanas después, las trazas muestran si la proporción de peticiones lentas bajó.
Las mismas trazas alimentan después el análisis de errores que describe evals como UX research. Para los estados de espera en pantalla, lee estados de carga en interfaces de IA. Para medir qué tan bien funciona la función en conjunto, métricas de calidad de una feature de IA. Y si el sistema actúa por su cuenta, el loop de un agente muestra qué pasos conviene que aparezcan en la traza.
Errores comunes
- Registrar solo el texto final y no los pasos intermedios.
- Guardar prompts y respuestas completas sin decidir su retención ni quién los ve.
- No registrar la versión del prompt. Sin ella, no puedes comparar antes y después de un cambio.
- Crear tableros sin alertas ni dueño.
- Confundir la latencia del modelo con la latencia total. Muchas veces el cuello de botella es una herramienta.
- Depender de nombres de atributos experimentales sin fijar la versión de la librería de instrumentación.