Inteligencia Artificial

Qué debe poder explicar la observabilidad de una aplicación con LLM

La observabilidad tradicional sigue siendo necesaria: una aplicación con IA también debe controlar disponibilidad, errores de red o tiempos de respuesta. El problema es que esas señales solo describen una parte del sistema. Una petición puede completar con HTTP 200 y, aun así, devolver una respuesta irrelevante, utilizar un modelo distinto al previsto o consumir muchos más tokens de lo habitual. El servicio puede estar sano mientras la experiencia se degrada.

Por eso, antes de producción conviene plantear una pregunta más exigente: si una interacción genera un incidente, ¿podemos reconstruir qué ocurrió sin intentar reproducirlo a ciegas? Esa capacidad amplía la observabilidad en un pipeline DevOps hacia el comportamiento específico de las aplicaciones generativas. Hay que relacionar ejecución, contexto y resultado.

Detectar no es diagnosticar: métricas frente a trazas

Las métricas agregadas permiten descubrir desviaciones. Una subida del p95 de latencia, un aumento del consumo de tokens o una mayor tasa de errores indican que algo ha cambiado. Son útiles para alertar y comparar periodos, pero no explican por sí solas la causa. Una media de ocho segundos, por ejemplo, no revela si el retraso procede del proveedor del modelo, de una recuperación de contexto previa o de varios reintentos.

Ahí entra el trazado o tracing. Una traza representa una ejecución concreta y puede dividirse en segmentos, denominados spans, para seguir sus pasos: recuperación de contexto, llamada al modelo, ejecución de una herramienta o procesamiento posterior. La métrica señala el problema; la traza permite investigarlo y relacionarlo con una interacción determinada.

Qué información debe acompañar a cada ejecución

Una traza solo resulta útil si contiene contexto suficiente. Como mínimo, debería ser posible relacionar una interacción con el modelo utilizado, la operación realizada, la versión de la aplicación o del prompt y sus pasos dependientes. Cuando existen herramientas, recuperación de contexto o varias llamadas a modelos, cada etapa debe conservar la relación con la solicitud original.

Eso no obliga a almacenar prompts y respuestas completos. Registrar indiscriminadamente contenido puede aumentar costes y exponer información que no es necesaria para operar el sistema. En algunos casos bastará con identificadores, versiones, tamaños, hashes o atributos seleccionados. El criterio es conservar los datos mínimos que permitan formular y comprobar una hipótesis de fallo, aplicando controles adicionales cuando la telemetría pueda contener información sensible.

Qué medir antes de llevar un LLM a producción

No todas las métricas tienen el mismo valor operativo. Antes del despliegue conviene priorizar las que permiten responder a tres preguntas: qué se está degradando, dónde ocurre y cuánto impacto genera. La referencia debe ser una interacción, petición o tarea completada, de modo que las tendencias agregadas puedan relacionarse después con ejecuciones concretas.

Latencia, errores y reintentos: detectar dónde se degrada la experiencia

La latencia total resulta insuficiente cuando una petición atraviesa varios componentes. Conviene separar el tiempo empleado en recuperar contexto, llamar al modelo, ejecutar herramientas y procesar la respuesta. En aplicaciones con generación progresiva también interesa medir el tiempo hasta el primer token (TTFT), porque condiciona la percepción de velocidad aunque la generación completa tarde más.

Las medias tampoco cuentan toda la historia. Si el p50 permanece estable pero el p95 aumenta de forma sostenida, una parte de los usuarios está recibiendo una experiencia peor. Para investigarlo hay que relacionar esas ejecuciones con modelo, proveedor, longitud del contexto, herramientas utilizadas o número de reintentos.

Los errores deben distinguir su origen: proveedor, modelo, herramientas, dependencias o propia aplicación. ¿Y si un reintento consigue finalmente una respuesta válida? Ese éxito puede estar ocultando un problema: añade latencia y coste y puede indicar una inestabilidad que se volverá crítica cuando aumente el tráfico.

Tokens, coste y calidad: detectar degradaciones que la disponibilidad no muestra

El consumo debe poder atribuirse a modelo, funcionalidad y tipo de ejecución, diferenciando tokens de entrada y salida cuando sea posible. Un aumento en la entrada puede revelar contextos demasiado grandes o prompts que han crecido; uno en la salida puede señalar generaciones menos controladas. El gasto mensual sirve para presupuestar, pero llega demasiado tarde para explicar qué cambio técnico está provocando una desviación.

La atribución permite detectar patrones que el dato agregado oculta. Si una funcionalidad representa el 8 % de las interacciones pero concentra el 30 % del consumo, exige una revisión distinta de un incremento uniforme provocado por mayor tráfico. Coste y uso deben conducir a una causa investigable, no quedarse en una cifra financiera.

La disponibilidad tampoco informa sobre la utilidad de la respuesta. Según el caso de uso, conviene combinar evaluaciones automáticas fiables, feedback del usuario, correcciones posteriores o comprobaciones específicas de la tarea. No se trata de crear una puntuación universal de calidad, sino de detectar cambios respecto al comportamiento esperado y relacionarlos con modelo, prompt, contexto o herramientas. Para equipos que necesiten profundizar en la construcción de este tipo de aplicaciones, la ruta de IA para desarrolladores ofrece un siguiente paso centrado en APIs de IA generativa, agentes y desarrollo de soluciones con mayor control técnico.

Checklist para decidir si la observabilidad es suficiente

La observabilidad debería formar parte del criterio de salida a producción, igual que las pruebas funcionales o la gestión de errores. La pregunta no es si existe un dashboard, sino si el equipo dispone de información suficiente para detectar una desviación y reconstruir una ejecución problemática.

El mínimo dependerá de la arquitectura y del riesgo del caso de uso. No todas las señales necesitan almacenarse con el mismo detalle ni durante el mismo tiempo, pero cada una debe responder a una necesidad operativa concreta.

Qué debe quedar trazado antes del despliegue

Este checklist permite comprobar qué capacidad de diagnóstico existe antes de publicar la aplicación:

• Modelo y versión. Permiten relacionar cambios de comportamiento, latencia o coste con el modelo utilizado y detectar degradaciones después de una migración.
• Prompt o versión del prompt. Facilita comparar ejecuciones antes y después de un cambio sin obligar a almacenar siempre el texto completo.
• Latencia por etapa. Debe mostrar dónde se consume el tiempo cuando intervienen recuperación de contexto, herramientas o varias llamadas al modelo.
• Errores y reintentos. Conviene diferenciar fallos del proveedor, modelo, herramientas, dependencias y aplicación, incluyendo recuperaciones automáticas que añaden latencia o coste.
• Tokens de entrada y salida. Permiten detectar crecimiento del contexto o generaciones anormalmente largas y atribuirlos a una funcionalidad concreta.
• Coste atribuible. Debe poder relacionarse con modelo, flujo o tipo de ejecución cuando el impacto económico sea relevante.
• Resultado y señales de calidad. Tienen que existir indicadores adecuados al caso de uso para identificar respuestas que terminan correctamente pero no cumplen su función.
• Pasos intermedios. Si intervienen recuperación de contexto, llamadas a herramientas o agentes, cada paso debe conservar relación con la ejecución original.

Las convenciones semánticas de OpenTelemetry para IA generativa ayudan a normalizar esta instrumentación y reducen la necesidad de crear esquemas distintos para cada servicio.

Qué señales deben activar una revisión o una alerta

Instrumentar no basta. Cada señal relevante necesita un criterio de actuación. Un pico puntual de coste puede ser normal en una tarea compleja, mientras que un crecimiento sostenido después de modificar un prompt merece investigación. Lo mismo ocurre con latencia, reintentos, errores o calidad: los umbrales deben responder al comportamiento esperado de esa aplicación.

La referencia debería partir de pruebas con casos representativos y revisarse cuando cambien el modelo, el prompt, el proveedor o la arquitectura. Una vez en producción, conviene contrastarla con tráfico real para comprobar que sigue reflejando un funcionamiento aceptable y ajustar los umbrales cuando sea necesario.

El criterio de paso a producción puede probarse de forma directa: introducir una degradación conocida y comprobar si el equipo puede localizar su origen utilizando únicamente la telemetría disponible. Si el diagnóstico depende de suposiciones o de reproducir el problema a ciegas, la observabilidad todavía no es suficiente para producción.

Conclusiones

La observabilidad de una aplicación con LLM debe permitir algo más que confirmar que el servicio responde. Tiene que ofrecer suficiente contexto para detectar desviaciones, reconstruir ejecuciones y relacionar una degradación con su causa probable. Sin esa capacidad, medir latencia, errores o coste aporta visibilidad, pero no necesariamente criterio para actuar.

Antes de producción conviene comprobar que métricas y trazas cubren tanto el comportamiento agregado como las ejecuciones individuales. Modelo, prompt, tiempos por etapa, reintentos, tokens, coste y señales de calidad deben poder conectarse cuando el caso de uso lo exija, sin registrar más información de la necesaria.

El criterio final no es cuánta telemetría se ha instrumentado, sino si permite tomar decisiones. Una aplicación está preparada para operar con mayor control cuando el equipo puede explicar una degradación con los datos disponibles, estimar su impacto y saber qué señal debería activar una revisión antes de que el problema escale.