Introducción: El problema de la observabilidad de la IA
En la clásica película Terminator, vemos el mundo a través de los ojos de la máquina: un HUD teñido de rojo con texto desplazándose, analizando objetivos y calculando probabilidades.
En la ingeniería moderna, hemos construido las máquinas (LLMs), pero a menudo carecemos de ese «HUD rojo»: enviamos un prompt, recibimos una respuesta, y cruzamos los dedos para que la factura no sea demasiado alta y la respuesta no sea una alucinación de la IA.
A medida que las empresas abarcan la transición en el uso de IA Generativa (GenAI) desde un prototipo a un sistema listo para producción, el stack de observabilidad estándar (Métricas, Logs, Trazas) se está quedando obsoleto. Esto es debido a dos características propias de la GenAI que no se dan en aplicaciones clásicas:
- Los LLMs son no deterministas.
- Cada llamada a un LLM cuesta dinero.
Evaluar el estado de una llamada a una API JSON es fácil: 200 Ok vs 500 Error; evaluar una respuesta de un LLM es un juego de matices, semántica y análisis de coste-beneficio.
En este post, exploraremos cómo diseñar una capa de observabilidad completa para GenAI utilizando Grafana, Langfuse y OpenTelemetry, obteniendo los siguientes beneficios:
- Panel de Control Único (Single Pane of Glass): donde podremos visualizar nuestros KPIs.
- Tendencias y detalles: podremos realizar analítica, ver las tendencias de nuestros KPIs y profundizar en los detalles de cada uno.
- Evaluaciones: ejecutaremos evaluaciones tanto offline como online para asegurar que nuestros sistemas de IA funcionan funcionan correctamente.
Figura 1: Panel de Control Único
1. La brecha: Por qué la trazabilidad tradicional no es suficiente
OpenTelemetry (OTel) es fantástico para microservicios: te dice que el Servicio A llamó al Servicio B , este a su vez al Servicio C , si hubo errores y cuál es la latencia en cada llamada. El problema surge cuando uno de esos servicios en el flujo interactúa con un LLM, ya que OTel a menudo se pierde lo más importante:
- Tokens y Costes: ¿cuánto nos costó este usuario específico? ¿Cuánto estamos gastando en ese proveedor? ¿Cuánto gastamos en cada modelo?
- Parámetros del modelo: ¿se generó esta respuesta con temperature: 0 .4 o 0. 9 ?
- Pasos intermedios: en un agent loop, ¿qué «pensó» el LLM antes de llamar a una tool?
¿Qué devolvieron los servidores MCP? ¿Qué paso fue el más costoso?
- Métricas de calidad: ¿fué la respuesta tóxica? ¿Fue factualmente correcta o la IA alucinó y se inventó la respuesta?
Para solucionar esto, necesitamos un stack de observabilidad especializado en GenAI.
2. Arquitectura: El Stack de Observabilidad de GenAI
Nuestra arquitectura en Datadope apunta a un enfoque de «Single Pane of Glass», mezclando el rendimiento técnico con el valor de negocio.
Los componentes:
- Langfuse SDK: Basado en OTel, instrumenta la aplicación para capturar prompts, completions y metadata, permitiendo caracterizar cada operación de nuestro código con términos del campo de la inteligencia artificial ( generation , tool , embedding , etc).
- Langfuse Stack: Un backend especializado que utiliza Clickhouse para el almacenamiento de telemetría con alto rendimiento.
- Grafana: La capa de visualización, que extrae datos directamente de Clickhouse para crear cuadros de mando unificados.
Figura 2: Arquitectura de alto nivel del sistema.
3. Instrumentación de la aplicación
Veamos cómo instrumentamos un servicio en Python utilizando la técnica Zero-Code Instrumentation (apenas modificamos el código pero obtenemos insights avanzados):
Con este simple cambio ya podemos obtener información acerca de modelo utilizado, parámetros, tokens de input y output, costes de cada llamada y costes por usuario, entre otros indicadores.
4. Casos de uso avanzados: Más allá del "funciona o no funciona"
A. Trazabilidad profunda
Cuando un sistema que interactúa con LLMs utiliza herramientas, MCPs u otros sistemas intermedios (por ejemplo, llamando a una base de datos o a un motor de búsqueda), la lógica de ejecución puede volverse compleja. Esta solución de observabilidad permite visualizar esos pasos intermedios y obtener una visibilidad total del comportamiento del sistema. Por ejemplo, veamos una traza donde el LLM quiere usar una herramienta:
- Input: la decisión del LLM de usar una herramienta.
- Acción: la llamada real a la base de datos.
- Observación: los datos devueltos al LLM.
- Síntesis: la respuesta final.
Este es el momento «¡Eureka!» para los desarrolladores que hacen debug de por qué un agente se quedó atascado en un bucle o eligió la herramienta equivocada.
Figura 3: Detalle de trazabilidad.
B. Seguimiento de la evolución: Tendencias y Rendimiento
La observabilidad no se trata solo del «ahora», sino también de tendencias. Al agregar la telemetría en Clickhouse, podemos visualizar la evolución de los KPIs a lo largo del tiempo para identificar regresiones o problemas de escalado:
- Escalado de costes: ¿nuestro gasto crece linealmente con nuestra base de usuarios, o hay una ineficiencia oculta en nuestros prompts?
- Desviación de latencia: identificar si un cambio reciente en el prompt o una actualización del modelo ha provocado un aumento gradual en la latencia p95
- Eficiencia de tokens: monitorizar los tokens por petición para asegurar que los agentes no se queden atascados en bucles redundantes.
Figura 4: Evolución de los KPI de IA Generativa y análisis de tendencias.
C. LLM-as-a-Judge: Scoring automatizado
¿Cómo sabes si tu LLM está funcionando correctamente? La revisión manual no escala, por lo que implementamos un Flujo Evaluador:
- Llega una petición y se almacena.
- Un segundo LLM que actúa como «Juez» lee el input que se envió al LLM y el output que ha generado (de forma asincrona, para no impactar la latencia de la petición del usuario).
- El Juez asigna una puntuación (0-1 ). Por ejemplo, «¿Está la información apoyada factualmente por el contexto proporcionado?».
- Alertamos si la Puntuación de Veracidad (Correctness Score) cae por debajo de un cierto umbral.
- También medimos otras puntuaciones relevantes, como la Toxicidad o la Relevancia.
Finalmente, mostramos en nuestro Panel de Control Único los resultados de estas evaluaciones:
Figura 5: Resumen de LLM-as-a-Judge.
5. Valor de negocio: La economía de la IA Generativa
La GenAI no es solo un reto técnico, sino que también es uno financiero: cubrimos la necesidad de tener un control preciso de los costes usando Grafana para consultar el backend de Clickhouse, lo cual nos permite construir cuadros de mando que muestran:
- Coste por Usuario/Tenant: vital para productos SaaS.
- Eficiencia del modelo: ¿estamos usando GPT-4 para tareas simples donde GPT-4o-mini sería suficiente?
- Latencia: la métrica de experiencia de usuario (UX) más crítica para las respuestas del LLM
Figura 6: Costes de los sistemas de IA Generativa.
6. Lecciones desde las trincheras
Después de implementar este sistema para varios clientes, aquí están nuestros mejores consejos:
- Sanitización de PII: nunca envíes información de identificación personal (PII) al backend de observabilidad. Usa enmascaramiento a nivel de SDK o un OTel Collector para filtrarla.
- Latencia de la respuesta: tanto la instrumentación como las evaluaciones puede añadir sobrecarga. Asegúrate de que tu SDK sea asíncrono y no bloquee la respuesta al usuario.
- El «Baggage» es tu amigo: los IDs de correlación en la cabecera OTel Baggage son esenciales para vincular el comportamiento del usuario con los costes del LLM.
Conclusión: Avanzando con confianza
La observabilidad en la era de la GenAI trata de pasar del «espero que esto funcione» al «sé que esto funciona». Al implementar un stack robusto y seguir las buenas prácticas, los equipos pueden finalmente comprender qué está haciendo el modelo, cuánto cuesta cada interacción y si las respuestas cumplen los niveles de calidad esperados, optimizando el coste, el rendimiento y, lo más importante, la confianza en el buen funcionamiento de sus aplicaciones.
¿Listo para iluminar tu stack de GenAI? En Datadope, nos especializamos en hacer medibles los sistemas complejos. Hablemos sobre cómo convertir tu IA en un sistema gobernable, observable y optimizado.
Eduardo Barajas Pedrosa
