AI / LLM Observability
Entender comportamiento runtime
AI / LLM Observability es la práctica de reunir y correlacionar evidencia para entender cómo se comporta en runtime una aplicación que incorpora modelos, proveedores, prompts, contexto, herramientas, retrieval, streaming, routing o agentes. Especializa preguntas de observabilidad para sistemas AI sin reemplazar la observabilidad general ni prometer que todo comportamiento interno sea visible.
La pregunta no es solamente si hubo una respuesta. Interesa qué solicitud llegó, qué configuración se utilizó, qué proveedor y modelo participaron, qué contexto se aportó, qué herramientas o recuperación ocurrieron, cuánto tardó cada etapa, qué errores y reintentos aparecieron y qué resultado pudo observar el sistema. La evidencia debe ser suficiente para investigar sin capturar indiscriminadamente información sensible.
Las traces de OpenTelemetry ofrecen un fundamento general para relacionar operaciones. Las GenAI semantic conventions son convenciones en evolución; no constituyen un schema universal congelado para el Atlas.
Reutilizar Observability general
Observability general conserva la idea de entender el estado y comportamiento de un sistema mediante señales que pueden ser inspeccionadas. AI / LLM Observability no vuelve a definir logs, métricas, traces, correlación o almacenamiento. Su aporte es identificar qué señales adicionales vuelven investigable un sistema cuyo resultado depende de un modelo y de un contexto cambiante.
Una implementación puede usar logs estructurados, métricas, spans, eventos, perfiles o registros de evaluación. La forma técnica puede variar. El canonical se ocupa de la pregunta y de los límites de interpretación: una señal debe mantener procedencia, contexto y significado suficientes para no confundir una salida generada con un hecho observado.
Observability y Monitoring
Monitoring pregunta por condiciones conocidas que conviene seguir y alertar: errores, latencia, saturación, disponibilidad o umbrales de comportamiento. Observability pregunta si las señales disponibles permiten investigar qué ocurrió y por qué las partes observadas produjeron ese estado. Se superponen, pero no son sinónimos.
En un sistema AI, Monitoring puede alertar por un aumento del tiempo de respuesta o por una caída de tasa de éxito. AI / LLM Observability debe ayudar a separar si el cambio provino del proveedor, modelo, routing, retrieval, una herramienta, una cola o la aplicación. La alerta es una decisión operativa; la evidencia correlacionada permite investigar.
MLOps / LLMOps Operations desarrolla la aplicación de monitoring y evaluación en producción al ciclo operacional de sistemas AI. Esa especialización no crea un nuevo concepto general de Monitoring; la recolección y correlación de evidencia permanecen en esta práctica.
Observability y Evaluation
AI Evaluation Fundamentals aplica criterios para juzgar calidad, comportamiento o adecuación. Observability reúne evidencia runtime. Una telemetría con tokens, latencia y contenido no es automáticamente un quality score; un grader necesita un criterio y una unidad de evaluación explícitos.
La observabilidad puede proporcionar casos para evaluación, contexto para interpretar resultados o señales para seleccionar muestras. Evaluation puede producir eventos que luego se observan. El flujo entre ambos es útil, pero no convierte una señal operacional en un juicio de calidad ni un score en una explicación causal completa.
Una respuesta rápida no es necesariamente correcta. Una respuesta con score alto en una muestra no demuestra que todos los requests de producción estén sanos. Mantener la frontera evita usar un dashboard como sustituto de evaluación o usar una evaluación offline como explicación de un incidente runtime.
Requests y errores
La instrumentación puede conservar evidencia alrededor de:
- identidad de la solicitud, ejecución, tenant y versión de aplicación;
- entrada y salida, cuando estén permitidas y con redacción adecuada;
- proveedor, modelo, modalidad, ruta y configuración;
- estados HTTP o del proveedor, errores, timeouts, cancelaciones y reintentos;
- fallback y motivo de selección o rechazo;
- llamadas a herramientas, resultados, errores y efectos observables;
- operaciones de retrieval, fuentes, versiones de índice y cantidad de contexto.
No todos los campos son necesarios en cada sistema. El objetivo es que un investigador pueda seguir el recorrido relevante y distinguir respuesta, error, cancelación y ausencia de evidencia. Un texto generado que afirma «se llamó a la herramienta» no sustituye un evento de ejecución emitido por el runtime.
Un error de upstream puede llegar sin información suficiente para explicar qué parte del workflow lo provocó. Un error local puede ser atribuido erróneamente al proveedor si sólo se conserva el status final. La correlación entre capas permite comparar lo que la aplicación pidió con lo que realmente ocurrió.
Privacidad y exposición
Prompts, respuestas, traces, contexto recuperado, código y argumentos de herramientas pueden contener datos personales, secretos, propiedad intelectual o información de otros tenants. Más telemetría no es siempre mejor observabilidad. Capturar todo puede aumentar superficie de exposición, costo de almacenamiento y riesgo de acceso sin mejorar la investigación.
Una política de observabilidad debe decidir qué redacción, minimización, muestreo, retención y control de acceso son necesarios. Puede conservar hashes, categorías, referencias, tamaños, errores o fragmentos limitados en lugar de contenido completo. La ausencia de contenido debe quedar visible como una limitación de evidencia, no rellenarse con una interpretación inventada.
Las credenciales nunca deben tratarse como una señal normal por el hecho de que una solicitud las haya incluido. El gateway, el runtime y el sistema de almacenamiento pueden tener distintos límites de confianza. AI / LLM Observability no materializa AI Security: sólo mantiene la frontera necesaria para que recolectar evidencia no implique exponer secretos.
Uso, tokens y coste
Las señales pueden incluir cantidad de requests, input tokens, output tokens, cached tokens, modelo, proveedor y modalidad. Los campos y su disponibilidad dependen del proveedor, modelo, API y runtime. El Atlas no fija nombres de campos ni supone que dos proveedores calculen tokens de la misma manera.
La telemetría puede estimar o atribuir costo por request, modelo, proveedor, tenant o workflow. Medir y atribuir uso no es AI Economics. Cost Efficiency puede interpretar trade-offs económicos generales; la decisión de presupuesto, precio o optimización requiere supuestos que no nacen de un contador.
También conviene distinguir costo de presupuesto. Un evento puede indicar que una solicitud consumió una cantidad estimada, pero no decide si estaba autorizada por el presupuesto del producto. El gateway puede aplicar límites, mientras observabilidad aporta la evidencia para entender el consumo.
Latencia y streaming
Una duración total puede ocultar dónde se gastó el tiempo. Cuando sea útil, conviene separar:
- espera de cola o admisión;
- tiempo hasta la primera respuesta o token;
- latencia del proveedor;
- tiempo de retrieval;
- tiempo de herramientas;
- duración del stream;
- latencia entre tokens cuando la experiencia lo necesita;
- tiempo hasta completar o cancelar.
Las métricas no son universalmente comparables. Un proveedor puede comenzar a transmitir antes de terminar una operación interna; otro puede entregar chunks con una semántica distinta. Un token, evento o chunk no es necesariamente una unidad homogénea entre APIs. La instrumentación debe declarar qué mide y bajo qué estado de ejecución.
El tiempo hasta la primera salida puede mejorar la experiencia y al mismo tiempo esconder una finalización lenta. La duración total puede ser adecuada para batch y no describir una interfaz interactiva. Las decisiones operativas deben conservar el contexto de la modalidad.
Atribución y correlación
La atribución avanzada intenta relacionar el comportamiento con:
- modelo, proveedor y versión o configuración;
- ruta normal, fallback y reglas que se aplicaron;
- prompt, instrucciones y contexto seleccionado;
- herramienta, retrieval e índice utilizado;
- agente, workflow, aplicación y versión de despliegue;
- tenant, caso de uso y tipo de interacción.
Esta información ayuda a comparar grupos y encontrar cambios coincidentes. No establece por sí sola causalidad. Si un score cae después de cambiar el modelo, la correlación orienta una investigación, pero todavía deben examinarse datos, prompts, distribución, herramientas y otras modificaciones.
La atribución también debe representar incertidumbre. Puede haber múltiples proveedores, reintentos o ramas concurrentes. Un único model en el resultado final puede ocultar que un fallback produjo la salida. Los identificadores deben relacionar eventos sin inventar un orden total cuando sólo existen dependencias parciales.
Agent Tracing
Agent Tracing registra y relaciona eventos para reconstruir el recorrido de una ejecución agente. AI / LLM Observability es más amplia: incluye señales de gateway, proveedor, modelo, aplicación, retrieval, streaming y herramientas aunque no exista autonomía agente. Agent Tracing puede ser una fuente o una vista especializada dentro de una observabilidad más amplia.
Un trace de agente no demuestra corrección, autorización o calidad. Del mismo modo, un conjunto de métricas de proveedor no explica por completo cómo un agente tomó decisiones o qué contexto omitió. Mantener las capas separadas permite correlacionarlas sin duplicar la definición de Agent Tracing.
Gateway como una fuente
AI Gateway puede emitir señales centrales de proveedor, ruta, fallback, tokens y estado. Pero observabilidad no requiere un gateway. Una aplicación que llama directamente a un proveedor, un runtime de agente, una herramienta o una operación de retrieval también debe poder producir evidencia.
La posición central puede perder detalles internos de la aplicación y la posición local puede perder información de upstream. Una investigación útil suele combinar fuentes con una correlación común. Ningún punto único debe presentarse como una vista completa por definición.
Streaming, herramientas y retrieval
Los sistemas AI combinan operaciones de diferente duración y semántica. Un trace puede relacionar la solicitud de modelo con una llamada de herramienta y con la continuación posterior, pero debe distinguir solicitud, ejecución, resultado, error y efecto. Una herramienta que devolvió un resultado parcial no equivale a una herramienta que completó su operación remota.
En retrieval, conviene conservar referencias a la consulta, índice o corpus, documentos seleccionados y versión de datos cuando sea permitido. Eso ayuda a investigar grounding y frescura sin registrar contenido sensible sin necesidad. En streaming, se debe distinguir primer chunk, chunks intermedios, finalización, interrupción y cancelación.
La observabilidad no autoriza a inferir razonamiento privado. Puede registrar eventos observables y explicaciones operativas necesarias, no exigir captura de chain-of-thought. Una narración generada por el modelo es una salida que necesita la misma cautela que cualquier otra salida.
Verificación y límites
Generated Code Verification pregunta si un cambio satisface requisitos y restricciones mediante evidencia pertinente. Observability puede mostrar qué ocurrió durante una ejecución, pero no prueba por sí sola que el cambio sea correcto o que la evidencia sea suficiente para entregar. Registrar un test no equivale a pasar el test.
La telemetría puede ser incompleta, retrasada, muestreada, redactada o afectada por fallos del propio sistema de observabilidad. Una reconstrucción coherente debe declarar qué señales faltan y qué conclusiones no pueden sostenerse. La ausencia de un evento puede significar que no ocurrió, que no se instrumentó, que se descartó o que no se pudo almacenar.
Límites
AI / LLM Observability no es:
- Monitoring, aunque produzca señales que monitoring consume;
- Evaluation, aunque pueda alimentar casos y contexto de evaluación;
- Agent Tracing, aunque pueda incluir esos traces;
- Verification, porque evidencia runtime no demuestra satisfacción de requisitos;
- AI Security, aunque deba minimizar exposición;
- AI Economics, aunque mida uso y costo.
Su responsabilidad es hacer investigable el comportamiento observable de sistemas AI, con procedencia y límites explícitos. La calidad de la conclusión depende tanto de la instrumentación como de lo que el sistema realmente puede observar.