Observabilidad para aplicaciones con LLM: trazas, costes, latencia y deriva de la calidad

Las aplicaciones con LLM fallan de forma distinta al software tradicional. Un error convencional deja una traza de pila; un «error» de LLM puede ser una deriva de la calidad que solo se advierte cuando los usuarios se quejan. Un problema de latencia convencional es un endpoint lento; en un LLM puede ser una traza de razonamiento de 30 segundos durante la que el usuario no ve más que un indicador de carga.

La observabilidad tradicional (Datadog, New Relic, Sentry) indica que la llamada a la API se completó en 8.4 segundos y utilizó 12,847 tokens de entrada. No revela si la respuesta era buena, si el modelo alucinó, si se invocó la herramienta equivocada o si la calidad se ha deteriorado desde la semana pasada.

Los sistemas con LLM en producción necesitan un stack de observabilidad diferente o, al menos, capas adicionales sobre las tradicionales. Este artículo explica qué cambia, qué debe instrumentarse y qué patrones funcionan.

Qué distingue a la observabilidad de LLM

Algunas características distintivas de los sistemas de LLM que la observabilidad tradicional no aborda:

No determinismo en cada unidad. La misma entrada puede producir resultados distintos en llamadas sucesivas. No se puede responder a «¿funcionó correctamente?» consultando únicamente el código de estado.

La calidad como métrica principal. La latencia y el coste importan, pero la calidad importa aún más y es la dimensión más difícil de medir.

Trazas de varios pasos. Una consulta puede desencadenar 5-50 llamadas a LLM —bucles de agentes, recuperación de RAG, extracción estructurada o reflexión—. Cada llamada forma parte de una traza más amplia.

Variabilidad del coste por token. Una llamada puede costar entre €0.001 y €1.00 según el tamaño del prompt, la longitud del resultado y el modelo. Los costes agregados deben poder atribuirse a cada llamada.

Deriva a lo largo del tiempo. Los modelos se actualizan, los prompts evolucionan y las distribuciones de entrada cambian. La calidad varía y debes poder observar esa evolución.

Payloads sensibles. Las entradas y los resultados suelen ser los datos de diagnóstico más valiosos, pero también los más sensibles. Es imprescindible aplicar una disciplina estricta al registro.

Flujos asíncronos prolongados. Ejecuciones de agentes que duran minutos, tareas por lotes en segundo plano y respuestas en streaming. El modelo tradicional de observabilidad de solicitud y respuesta no encaja.

Estos no son preocupaciones teóricas. Cada equipo de producción que ejecuta sistemas de LLM los enfrenta.

La pila de observabilidad

Una pila completa de observabilidad de LLM tiene estas capas:

1. Instrumentación de cada llamada. Se registran la entrada, el resultado, la latencia, el coste, el modelo y el estado de cada llamada a un LLM.

2. Instrumentación de trazas. Los flujos con varias llamadas se agrupan en trazas que permiten ver la cadena completa de una solicitud.

3. Métricas de aplicación. Agregaciones por funcionalidad, usuario e inquilino.

4. Monitorización de la calidad. Evaluación automatizada de una muestra o de todo el tráfico.

5. Captura de comentarios del usuario. Señales explícitas —valoración positiva o negativa— e implícitas —regenerar o abandonar—.

6. Alertas. Avisos en tiempo real sobre picos de costes, degradación de la latencia, caídas de calidad y aumentos de la tasa de errores.

7. Herramientas de depuración. Cuando algo falla, puedes encontrar la traza, ver las entradas y salidas, entender qué pasó.

Revisaremos cada una.

Instrumentación de cada llamada

Cada llamada a un LLM debe generar un registro con:

{
  "call_id": "uuid",
  "timestamp": "2026-05-15T14:23:45Z",
  "trace_id": "uuid",  // for grouping into traces
  "span_id": "uuid",   // for parent-child relations
  "feature": "summarize_document",
  "prompt_version": "v3.2",
  "model": "claude-4-sonnet",
  "provider": "anthropic",
  "input_messages": [...],
  "output_message": "...",
  "input_tokens": 1842,
  "output_tokens": 384,
  "total_tokens": 2226,
  "cost_usd": 0.0084,
  "latency_ms": 2340,
  "first_token_ms": 1240,  // streaming
  "status": "success",
  "error": null,
  "user_id": "user_123",
  "tenant_id": "tenant_45",
  "metadata": {
    "session_id": "...",
    "experiment_arm": "v3_test"
  }
}

Este es el mínimo imprescindible. Registra todo lo necesario.

Elecciones clave de implementación:

Dónde registrar. Opciones:

• Una herramienta de observabilidad dedicada (Helicone, LangSmith, Phoenix, Braintrust, Arize).
• Una plataforma de observabilidad general con extensiones para LLM (Datadog LLM Observability, Sentry).
• Tus propios registros o base de datos.

Para la mayoría de los equipos conviene elegir una herramienta dedicada. Sus interfaces están diseñadas específicamente para inspeccionar llamadas a LLM y su curva de aprendizaje es moderada frente al esfuerzo de desarrollar una solución propia.

Los equipos grandes pueden combinar ambos enfoques: una herramienta dedicada para la interfaz específica de LLM y la plataforma central de observabilidad para correlacionar los datos entre sistemas.

Cómo instrumentar. Opciones:

• Un proxy que se sitúa entre tu aplicación y el proveedor de LLM (modelo de Helicone).
• Un SDK que envuelva las llamadas en el código de la aplicación.
• Una clase envolvente que se invoque manualmente en cada llamada al LLM.

Los proxies son la opción más sencilla, pero añaden latencia. Los SDK ofrecen una integración limpia, aunque requieren trabajo inicial. La envoltura manual es más flexible, pero resulta fácil olvidar alguna llamada.

Un enfoque pragmático consiste en envolver con un SDK el límite donde la aplicación invoca al LLM. Solo hay un punto que instrumentar y todo el tráfico pasa por él.

Qué registrar. Consideraciones prácticas:

• Trunca entradas/salidas muy largas (pero registra la truncación).
• Aplica un hash o anonimiza la información de identificación personal; si es necesario, conserva la posibilidad de recuperar el original mediante una consulta segura.
• No registres credenciales, incluso en rutas de error.
• Para streaming, registra tanto la latencia del primer token como la latencia total.

Instrumentación de trazas

Una sola acción del usuario suele implicar muchas llamadas a LLM. Sin instrumentación de trazas, tendrías miles de registros sin saber cuáles pertenecen a cada acción.

Implementación:

Generación del ID de traza. Crea un identificador único al inicio de la solicitud y propágalo por todas las llamadas posteriores.

Spans con relaciones padre-hijo. Dentro de una traza, cada llamada tiene un ID de span y, opcionalmente, el ID de su span padre. Así se forma un árbol que muestra la jerarquía de llamadas.

Nombre de la operación. Cada span recibe un nombre —«resumir_documento», «extraer_entidades» o «llamada_herramienta:buscar»—. La traza muestra toda la cadena de operaciones.

Una vista de traza en tu interfaz de usuario:

Trace abc-123 (12.3s total)
├─ classify_intent (450ms) [gpt-5-mini]
├─ retrieve_documents (1.2s) [embedding + search]
├─ generate_response (8.5s) [claude-4-sonnet]
│   ├─ tool_call: search_internal (320ms)
│   ├─ tool_call: lookup_customer (180ms)
│   └─ generate_final_text (7.5s)
└─ judge_response_quality (2.1s) [claude-4-haiku]

Ahora puedes ver exactamente qué hizo el sistema ante esta solicitud y localizar en su contexto las llamadas lentas, costosas o fallidas.

Herramientas que manejan esto bien: LangSmith, Phoenix (Arize), Helicone con integración personalizada. Además, observabilidad general (Datadog, OpenTelemetry) para trazado entre sistemas.

Métricas de aplicación

Más allá de las llamadas individuales, métricas agregadas:

Por funcionalidad.

• Volumen de llamadas.
• Latencia promedio.
• Latencia p50, p95, p99.
• Coste medio por solicitud.
• Tasa de error.
• Puntuación de calidad (si se mide).

Por usuario o inquilino.

• Llamadas por usuario por día.
• Costo por usuario.
• Usuarios con un consumo elevado y patrones de abuso.

Por modelo.

• Volumen por modelo.
• Proporción del coste por modelo.
• Tasa de error por modelo.
• Calidad (donde se mide) por modelo.

Por funcionalidad × modelo.

• ¿Qué modelos utiliza cada funcionalidad?
• ¿Dónde podríamos enrutar a modelos más económicos?

Estos paneles orientan las decisiones operativas: qué funcionalidades son caras, cuáles son lentas y cuáles necesitan optimización.

Monitorización de la calidad

La capa más difícil: evaluación automatizada de calidad.

Las evaluaciones —tratadas por separado— se ejecutan sobre un conjunto de datos definido. La monitorización de la calidad en línea, en cambio, analiza el tráfico de producción.

Enfoques:

Un LLM como juez de una muestra. Selecciona, por ejemplo, el 1% del tráfico de producción. Un LLM juez puntúa cada respuesta en las dimensiones pertinentes. Sigue la evolución de esas puntuaciones y alerta ante las caídas.

Señales implícitas. Registra las regeneraciones, los abandonos, las tasas de error, el tiempo hasta completar la tarea y la frecuencia de los mensajes de seguimiento. Son señales débiles, pero baratas; utilízalas como indicadores tempranos.

Comentarios explícitos de los usuarios. Valoraciones positivas o negativas, botones de «¿te ha resultado útil?» e informes expresos. Ofrecen una señal de alta calidad, pero en menor volumen.

Detección de patrones. Marca automáticamente patrones problemáticos concretos —«No puedo ayudarte con eso», «Solo soy una IA» o rechazos repetidos—. Así se detectan algunas regresiones de inmediato.

Un entorno típico:

• Muestra el 1% del tráfico de producción.
• Ejecuta un LLM juez en cada uno, calificando multidimensionalmente.
• Agrega las puntuaciones diarias por funcionalidad.
• Alerta si alguna funcionalidad cae >10% de una semana a otra.

El coste es real, pero está acotado (1% del tráfico × un modelo juez pequeño = asumible para la mayoría de los equipos).

Observabilidad de costes

Los costes de los LLM pueden dispararse. Un solo error —un bucle de reintentos descontrolado o una funcionalidad que utiliza 10x más tokens de lo previsto— puede generar una factura 10x mayor antes de que alguien lo advierta.

Capas de observabilidad de costes:

Coste por llamada. El coste se calcula en el momento del registro y puede agregarse de inmediato.

Alertas de presupuesto. Define presupuestos diarios, semanales y mensuales por funcionalidad o inquilino. Genera una alerta al superar los umbrales (50%, 75%, 90%, 100%).

Detección de anomalías. ¿El coste diario es 5x superior al habitual? Alerta. ¿Una sola llamada cuesta 100x más de lo normal? Alerta.

Atribución de costes. Desglosa el coste por funcionalidad, inquilino y usuario para localizar sus principales causas.

Previsión. Basado en la trayectoria actual, ¿cuál será la factura al final del mes?

Un panel útil muestra en una sola vista el coste de hoy frente al acumulado de esta semana y al de la semana pasada, desglosado por funcionalidad.

Consejo práctico: establece límites estrictos siempre que sea posible. Si una funcionalidad debería costar €X/día, detenla automáticamente al alcanzar 10X. Las fugas de costes crecen con rapidez; el límite las contiene.

Observabilidad de latencia

La latencia de LLM es más sutil que las APIs típicas:

Latencia total. Desde la solicitud hasta la respuesta final.

Tiempo hasta primer token (TTFT). Para streaming, ¿cuándo ve el usuario el primer carácter? Esto domina la latencia percibida para la UX de chat.

Tiempo hasta último token (TTLT). ¿Cuánto tiempo hasta que la respuesta se complete?

Tokens por segundo. Velocidad de generación. Algunos modelos transmiten los tokens más despacio que otros.

Latencia de las llamadas a herramientas. En los flujos de agentes, compara el tiempo dedicado a las herramientas con el de las llamadas a LLM.

Rastrea todos estos. Diferentes estrategias de optimización se centran en diferentes métricas.

En un chat orientado al usuario, lo que importa es el TTFT. Un primer token lento da la impresión de que el sistema está roto; una velocidad de generación baja se percibe como una espera gradual.

En los procesos por lotes importa la latencia total, pero el rendimiento agregado importa aún más.

Para agentes: la latencia de llamada a herramienta suele dominar; optimizar el LLM no ayuda si las herramientas son lentas.

Observabilidad de errores

Errores específicos de LLM:

Errores de API. Límites de tasa, errores de autenticación, errores del servidor. Lo mismo que cualquier API.

Errores de validación. Salida estructurada no se ajusta al esquema. Rastrea la frecuencia por característica.

Errores de filtro de contenido. El proveedor bloqueó la solicitud. Rastrea para detectar problemas de prompt.

Errores de herramientas. Registra los fallos de cada herramienta por separado.

Errores de calidad. Un LLM juez ha calificado el resultado como deficiente. Sigue su evolución temporal.

Señales de alucinación. Detectan alucinaciones probables, como una afirmación que no aparece en la fuente. Son difíciles de identificar automáticamente, pero pueden estimarse.

Errores de coste. Las llamadas mucho más caras de lo previsto suelen indicar un fallo.

Cada una tiene su propio panel. Cada una puede desencadenar alertas.

Herramientas de depuración

Cuando algo falla, necesitas encontrarlo y entenderlo. La superficie de depuración incluye:

Búsqueda de trazas. Localiza una solicitud concreta por ID de traza, ID de usuario o marca temporal.

Inspector de llamadas. Muestra la solicitud, la respuesta, los parámetros, la latencia y el coste de cualquier llamada.

Cronología de la traza. Permite visualizar la cadena de llamadas de los flujos complejos.

Capacidad de reproducción. ¿Puedes volver a ejecutar una llamada anterior con otro prompt o modelo y comprobar qué habría ocurrido? Es fundamental para probar correcciones.

Vista comparativa. Compara en paralelo dos llamadas, ya sean versiones distintas de un prompt o modelos diferentes.

Búsqueda por contenido. Busca en el corpus de llamadas anteriores patrones específicos (“muestra llamadas donde el modelo dijo ‘No puedo ayudar’”).

Estas son las capacidades que ofrecen las herramientas específicas de observabilidad de LLM. Desarrollarlas requiere un esfuerzo considerable; utilizar una herramienta existente suele resultar más barato.

Privacidad y PII

Los registros de observabilidad de LLM son sensibles. Tanto las entradas como los resultados pueden contener información de identificación personal. En ocasiones es necesario conservarla para depurar, pero debe hacerse de forma controlada.

Prácticas:

Tokenización y hashing. Sustituye los identificadores por tokens y permite recuperar el original mediante una consulta segura independiente. De este modo, la mayoría de los registros no contiene datos personales.

Anonimización al registrar. Detecta y anonimiza los datos personales antes de que lleguen al almacén de observabilidad. Sustituye patrones concretos —correos, números de teléfono o SSN— por marcadores.

Aislamiento por inquilino. Datos de observabilidad multiinquilino aislados por inquilino. Los datos de un inquilino no son visibles para otro.

Control de acceso. Registra quién puede consultar las entradas y salidas sin anonimizar.

Políticas de conservación. Registros más antiguos de X días se eliminan o se mueven a almacenamiento frío. La conservación de PII tiene límites legales en muchas jurisdicciones.

Derecho a ser olvidado. Cuando un usuario solicita eliminación (GDPR), sus registros deben ser encontrables y eliminables.

Estas medidas no son opcionales en un sistema que trate datos personales. Aplícalas bien desde el principio; incorporarlas a posteriori resulta costoso y doloroso.

Alertas

Umbrales y señales que justifican una alerta:

Costo.

• Coste diario > 2x el habitual.
• Coste de una sola llamada > €5.
• Pico de coste por hora > 5x el habitual.

Latencia.

• Latencia p95 > 2x la referencia.
• TTFT > 5s para UX de chat.
• Aumento de tiempos de espera de llamada a herramienta.

Tasa de error.

• Tasa de error > 1% (la referencia habitual es 0.1-0.5%).
• Pico de tipo de error específico (errores de validación, límites de tasa).

Calidad.

• Caída > 10% de la puntuación de calidad de una semana a otra en cualquier funcionalidad.
• Tasa de comentarios negativos > referencia.
• Tasa de regeneración > referencia.

Patrón.

• Aparición más frecuente de frases específicas malas.
• Cambio repentino en la distribución de entrada.

Cada alerta debe ser específica y permitir actuar. «El coste es alto» no es útil; «la funcionalidad X ha consumido 10x su presupuesto durante los últimos 30 minutos; probablemente existe un bucle descontrolado en la sesión del cliente Y» sí lo es.

Consideraciones multiinquilino

Para aplicaciones SaaS B2B:

Métricas por inquilino. Cada cliente puede consultar su propio uso, costes y calidad.

Alertas por inquilino. Específicas para sus umbrales.

Depuración por inquilino. El soporte puede ver las trazas de un cliente (con controles de acceso adecuados).

Configuración por inquilino. Algunos clientes pueden tener modelos, prompts o políticas diferentes. La capa de observabilidad refleja esto.

Esto añade complejidad, pero es esencial en soluciones B2B a gran escala. El equipo de soporte no puede investigar «la IA no me funciona» sin acceso controlado a las trazas del inquilino.

Ecosistema de herramientas (2026)

Panorama de las herramientas de observabilidad de LLM disponibles al redactar este artículo:

Observabilidad dedicada de LLM:

• Helicone. Basado en proxy, fácil de integrar y con paneles sólidos.
• LangSmith. Vinculado al ecosistema de LangChain; trazado profundo.
• Phoenix (Arize). De código abierto y sólido en la monitorización de calidad.
• Braintrust. Fuerte en evaluaciones + observabilidad combinadas.
• PromptLayer. Enfocado en prompts; fuerte en seguimiento de versiones.
• Weights & Biases Weave. Adecuado para equipos de ML e integrado con el conjunto más amplio de herramientas de W&B.

APM general con extensiones para LLM:

• Datadog LLM Observability. Orientado a empresas y caro.
• New Relic LLM Observability. Similar.
• OpenTelemetry + tu APM de elección. OTel tiene convenciones semánticas de GenAI; instrumenta una vez, visualiza en muchas herramientas.

Construye tu propio:

• Una tabla de Postgres con una fila por llamada cubre muchas necesidades de la mayoría de los equipos.
• Añade una interfaz de usuario simple para buscar y mostrar.
• Integra con tu infraestructura de registro existente.

La elección correcta depende del tamaño del equipo, escala, presupuesto y herramientas existentes. La mayoría de los equipos comienzan con una herramienta dedicada y migran a una configuración más completa a medida que escalan.

Configuración práctica

Para un equipo típico de tamaño medio que comienza desde cero:

Semana 1: Elige una herramienta (Helicone es un comienzo común y fácil). Integra con tu ruta principal de llamada de LLM. Verifica que las llamadas se estén registrando.

Semana 2: Configura paneles básicos: coste, latencia y tasa de errores por funcionalidad.

Semana 3: Configura alertas de picos de costes y aumentos de la tasa de errores.

Semana 4: Añade instrumentación de trazas. Conecta los spans de los flujos con varias llamadas.

Mes 2: Implementa un muestreo de calidad. Elige algunas funcionalidades y configura la puntuación mediante un LLM juez para el 1% del tráfico.

Mes 3: Añade captura de retroalimentación del usuario. Conecta botones de me gusta/no me gusta o similares.

Mes 4: Añade compatibilidad multiinquilino, alertas granulares y herramientas de depuración.

Con esto tendrás un stack de observabilidad funcional. Cada capa añade capacidades valiosas; omitir una de ellas deja un punto ciego.

Lo que sale mal sin ella

Un catálogo breve de patrones de incidentes que se repiten en equipos sin observabilidad adecuada de LLM:

• Un error causó que una característica repitiera llamadas en un bucle cerrado. Se acumularon cargos inesperados de cinco cifras durante el fin de semana. Solo se detectó cuando llegó la factura mensual. (Variantes de esta historia se repiten con tanta frecuencia que los números específicos importan menos que el patrón.)

• Una actualización del modelo cambió el comportamiento de forma silenciosa. La calidad disminuyó en una funcionalidad clave. Los usuarios se quejaron, pero el equipo de ingeniería lo atribuyó a «algún caso extraño». Transcurrieron dos meses hasta que se relacionó con la actualización.

• Se desplegó una nueva versión del prompt que introdujo accidentalmente una regresión en un flujo de usuario importante. Sin métricas por flujo, nadie lo advirtió durante semanas.

• Un sistema de agentes entró en un bucle. Algunas sesiones acumularon 200+ llamadas a LLM. Localizar el bucle exigió horas de investigación porque no había instrumentación de trazas.

• Un fallo de autenticación de una herramienta confundió al agente. Este siguió «probando cosas» y acumulando costes. Sin alertas, el problema continuó durante horas.

• Una inyección de prompt hizo que la IA revelara instrucciones del sistema y datos personales. Sin observabilidad, el equipo no podía identificar con facilidad a los usuarios afectados.

No son casos teóricos: ocurren. La observabilidad evita muchos de ellos o permite detectarlos rápidamente.

Instrumenta antes del incidente

La observabilidad de LLM constituye una disciplina propia. La observabilidad tradicional es necesaria, pero insuficiente. También hacen falta las capas específicas de llamadas, trazas, calidad, costes, latencia, errores y depuración.

Las herramientas ya existen. Elige una, intégrala pronto e invierte en paneles, alertas y procesos que detecten los problemas antes que los usuarios.

Los equipos que lo hacen:

• Detectan errores en horas en lugar de semanas.
• Gestionan los costes de forma predecible en lugar de recibir facturas inesperadas.
• Mantienen la calidad con el tiempo en lugar de desviarse.
• Depuran sistemáticamente en lugar de adivinar.

Los equipos que no lo hagan acabarán sufriendo un incidente que les obligará a hacerlo. Es mejor instrumentar antes del incidente que después.