Engineering the «Black Box»: Deep-Dive en la Observabilidad de GenAI

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 la GenAI pasa de ser un «prototipo genial» a un «agente listo para producción», el stack de observabilidad estándar (Métricas, Logs, Trazas) se está quedando obsoleto. ¿Por qué? Porque los LLMs son no deterministas y caros. Evaluar 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
  • Tendencias y detalles: podremos 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

 

 

1.    La brecha: Por qué la trazabilidad tradicional no es suficiente

OpenTelemetry (OTel) estándar es fantástico para microservicios. Te dice que el Servicio A llamó al Servicio B . Pero cuando el servicio B es un LLM. 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ál es el modelo más caro que estamos usando?
  • Parámetros del modelo: ¿Se generó esta respuesta con o 7 ?
  • 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: ¿Fue 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:

  1. Langfuse SDK: Basado en OTel, instrumenta la aplicación para capturar prompts, completions y metadata.
  2. Langfuse Stack: Un backend especializado que utiliza Clickhouse para el almacenamiento de telemetría de alto
  3. Grafana: La capa de visualización, que extrae datos directamente de Clickhouse para crear cuadros de mando

 

3.    Implementación: Instrumentando al Agente

Veamos cómo instrumentamos un servicio Python. La clave es mantener el contexto. Utilizando OTel Baggage, podemos inyectar metadatos como el userID para rastrear y analizar todo el recorrido del usuario.

 

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
  • Acción: La llamada real a la base de
  • Observación: Los datos devueltos al
  • Síntesis: La respuesta

 

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.

 

 

 

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
  • Eficiencia de tokens: Monitorizar los tokens por petición para asegurar que los agentes no se queden atascados en bucles

 

 

C.  LLM-as-a-Judge: Puntuación automatizada

¿Cómo sabes si tu LLM está funcionando correctamente? La revisión manual no escala, por lo que implementamos un Flujo Evaluador:

  1. Llega una petición y se
  2. Un segundo LLM que actúa como «Juez» lee el par entrada/salida.
  3. El Juez asigna una puntuación (0-1) basada en una rúbrica (por ejemplo, «¿Está la información apoyada factualmente por el contexto proporcionado?»).
  4. Alertamos si la Puntuación de Veracidad (Correctness Score) agregada cae por debajo de un cierto umbral.
  5. 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:

 

5.    Valor de negocio: La economía de la IA Generativa

La GenAI no es solo un reto técnico; es uno financiero. Usar Grafana para consultar el backend de Clickhouse nos permite construir cuadros de mando que muestran:

  • Coste por Usuario/Tenant: Vital para productos
  • 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.

 

 

6.    Lecciones desde las trincheras

Después de implementar esto para varios clientes, aquí están nuestros mejores consejos:

  1. 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
  2. Latencia de la respuesta: La instrumentación puede añadir Asegúrate de que tu SDK sea asíncrono y no bloquee la respuesta al usuario.
  3. 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 desentrañar las capas de la «Caja Negra», optimizando el coste, el rendimiento y, lo más importante, la confianza.

¿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 y optimizado.

 

 

 

 

 

 

Eduardo Barajas Pedrosa

Imagen de Ivan Blanco

Ivan Blanco

¿Te ha resultado interesante?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Entradas relacionadas

Engineering the «Black Box»: Deep-Dive en la Observabilidad de GenAI

DTW Ignite 2026: las claves que marcarán el futuro de las operaciones inteligentes

Blindaje financiero contra caídas de más de 500.000€: Éxito en la era de la observabilidad

¿Quieres saber más?