La observabilidad en sistemas de IA en producción es la capacidad de entender qué está pasando dentro de tus pipelines —latencia, costos, calidad de respuesta, drift— sin necesidad de revisar logs manualmente. No es un dashboard bonito: es la diferencia entre detectar una degradación en 5 minutos o en 5 días, cuando ya perdiste usuarios. En nodo. operamos agentes y pipelines RAG en producción para empresas chilenas, y este artículo comparte lo que hemos aprendido monitoreando sistemas reales.
El problema específico de los sistemas de IA es que fallan de manera silenciosa. Un endpoint REST devuelve 500 y tu monitor lo captura. Pero un agente de IA que empieza a alucinar sigue devolviendo 200 OK con respuestas plausibles pero incorrectas. Sin observabilidad diseñada para IA, esas fallas pasan desapercibidas hasta que un usuario se queja.
¿Qué métricas debo monitorear en un sistema de IA en producción?
Métricas esenciales: Latencia p50/p95/p99 por request, tasa de errores y timeouts, costo acumulado por día (en USD), calidad de respuesta medida por sampling, y drift en la distribución de inputs. Para pipelines RAG, agrega recall del retriever y hallucination rate.
Las métricas de un sistema de IA se dividen en tres capas: infraestructura, modelo y negocio. La mayoría de los equipos solo cubren la primera y se sorprenden cuando el sistema degrada sin que ningún alerta se dispare.
Capa 1: Métricas de infraestructura
Son las métricas que ya conoces: latencia HTTP, uso de CPU/memoria, tasa de errores 4xx/5xx, y throughput (requests por segundo). En sistemas de IA, la latencia tiene particularidades importantes. Un request a un LLM puede tardar entre 800ms y 12 segundos dependiendo del largo del prompt y la longitud de la respuesta generada. Necesitas medir percentiles, no promedios. En nuestra experiencia, un p50 de 1.8s con un p99 de 8.2s es común para agentes con tool calling.
- Latencia por componente: descomponer el tiempo total en embedding generation (típicamente 50-150ms), vector search (20-80ms), LLM inference (1-8s) y post-processing (10-50ms)
- Token throughput: tokens de input y output por request, porque determinan directamente el costo
- Queue depth: si usas procesamiento asíncrono, cuántos requests están esperando
- Rate limit hits: cuántas veces el proveedor de LLM te hace throttling (crítico con Claude, GPT-4o o Gemini en peak hours)
Capa 2: Métricas de modelo
Aquí es donde la mayoría de los equipos tienen un punto ciego. Las métricas de modelo miden la calidad del output, no solo si el sistema responde. Estas son las que debes implementar desde el día uno:
- Hallucination rate: porcentaje de respuestas que contienen información no sustentada por el contexto. En nuestros pipelines RAG, medimos esto con un LLM evaluador que compara la respuesta contra los chunks recuperados. Target: menor al 3%
- Retriever recall: de los documentos relevantes disponibles, ¿cuántos recuperó el retriever? Lo medimos con un golden dataset de 200 pares query-documento. Target: mayor al 85%
- Answer relevancy: ¿la respuesta realmente responde la pregunta? Evaluación automática con RAGAS o evaluación humana por sampling. Target: mayor al 90%
- Refusal rate: porcentaje de veces que el modelo se niega a responder legítimamente. Un spike aquí indica que algo cambió en el prompt o el modelo
Capa 3: Métricas de negocio
Las métricas que le importan al que paga. Costo acumulado por día (desglosado por modelo y endpoint), tasa de resolución sin escalamiento humano, NPS o satisfacción del usuario final, y conversión atribuida al sistema de IA. En un proyecto de nodo. para un cliente de retail, descubrimos que el 23% del costo diario provenía de un solo endpoint que generaba respuestas innecesariamente largas. Ajustar max_tokens de 2048 a 512 redujo el costo mensual en USD $340 sin afectar la calidad.
¿Cómo detecto que mi modelo de IA está perdiendo calidad?
Detección de degradación: Implementa evaluación continua con un dataset de referencia ejecutado diariamente. Compara scores actuales contra la baseline del deploy inicial. Alertas automáticas cuando la calidad cae más de un 5% permiten detección temprana antes de que los usuarios lo noten.
La degradación de un sistema de IA en producción ocurre por tres razones principales, y cada una requiere una estrategia de detección distinta:
1. Drift en los datos de entrada
Los usuarios empiezan a hacer preguntas que el sistema no esperaba. El vocabulario cambia, los temas mutan, el contexto evoluciona. En un agente de soporte que operamos para un cliente fintech, detectamos que después de un cambio regulatorio, el 35% de las consultas incluían términos que no existían en el corpus original. El retriever seguía devolviendo resultados —pero irrelevantes.
¿Cómo lo detectamos? Monitoreamos la distribución de scores de similaridad del retriever. Cuando el p75 de similaridad cayó de 0.82 a 0.71 en una semana, la alerta se disparó. La solución: actualizar el corpus con la nueva normativa y reindexar los embeddings. Tiempo de detección: 2 días. Sin monitoreo habrían sido semanas.
2. Cambios en el modelo del proveedor
Los proveedores de LLM actualizan sus modelos sin previo aviso. OpenAI, Anthropic y Google han hecho cambios que alteran el comportamiento de modelos en producción. Un cambio de versión menor en Claude puede modificar cómo el modelo maneja edge cases en tus prompts. No es un bug: es una característica del ecosistema actual.
La defensa: un suite de evaluación automatizada que corre cada 24 horas contra un dataset de referencia de 150-300 casos. Comparas los scores de hoy contra tu baseline. Si la precisión en tu métrica principal (hallucination rate, answer relevancy, format compliance) baja más de un 5%, la alerta se dispara antes de que ningún usuario lo note.
3. Degradación del contexto (RAG)
En sistemas RAG, la calidad depende de la frescura y completitud del corpus. Documentos obsoletos, duplicados, o chunks mal segmentados degradan gradualmente la calidad. Hemos visto casos donde la calidad cae un 2% por semana durante meses —imperceptible día a día, devastador en acumulado.
¿Qué alertas debo configurar para un sistema de IA?
Las alertas en sistemas de IA son más complejas que en software tradicional porque muchas fallas no son binarias. El sistema no se cae: degrada. Estas son las alertas que configuramos en cada proyecto de plataformas de IA que operamos:
| Alerta | Umbral | Severidad | Acción |
|---|---|---|---|
| Latencia p95 > 10s | Sostenido 5 min | Crítica | Verificar rate limits y estado del proveedor |
| Error rate > 5% | Ventana 15 min | Crítica | Circuit breaker, fallback a cache |
| Costo diario > 120% del promedio | Acumulado 24h | Alta | Revisar tokens por request, buscar loops |
| Retriever similarity p75 < 0.70 | Promedio diario | Alta | Verificar corpus, buscar input drift |
| Hallucination rate > 5% | Evaluación diaria | Alta | Revisar prompt, verificar retriever |
| Eval score cae > 5% vs baseline | Evaluación diaria | Media | Investigar cambio de modelo o datos |
| Refusal rate > 10% | Ventana 1h | Media | Revisar cambios en guardrails o modelo |
Un patrón que funciona bien: alertas escalonadas con cooldown. La primera alerta va a Slack. Si no se reconoce en 15 minutos, escala a PagerDuty. Si el problema persiste 30 minutos, activa el circuit breaker automático que desvía tráfico a respuestas cacheadas o un modelo de fallback más estable.
¿Qué herramientas uso para monitorear IA en producción?
El stack de observabilidad para IA tiene dos capas: la infraestructura clásica (que probablemente ya tienes) y la capa específica para LLMs (que probablemente no tienes). No necesitas las dos desde el día uno, pero sí necesitas un plan para llegar a ambas.
Stack mínimo viable: Para empezar, necesitas tres cosas: structured logging con request_id que vincule cada paso del pipeline, un dashboard con latencia/costo/errores por endpoint, y un eval suite automatizado que corra diario. Todo lo demás es optimización. No inviertas en herramientas sofisticadas antes de tener estos tres pilares.
Infraestructura clásica (lo que ya conoces)
- Prometheus + Grafana: métricas de latencia, throughput, errores. Open source, funciona. Para equipos que ya lo usan, agregar métricas custom de IA es trivial
- Datadog / New Relic: si prefieres SaaS. Datadog tiene integración nativa con OpenAI y Bedrock que captura tokens, costos y latencia automáticamente
- CloudWatch: si estás en AWS. Métricas de Bedrock llegan automáticamente. Para Lambda + Bedrock, es la opción con menor fricción
Capa específica para LLMs
- LangSmith: tracing completo de cadenas LangChain/LangGraph. Cada paso del agente queda registrado con input, output, tokens y latencia. Excelente para debugging, costoso en volumen alto
- Langfuse: alternativa open source a LangSmith. Self-hosted o cloud. Tracing, evaluaciones y datasets de prueba. Es lo que usamos en nodo. para proyectos donde el cliente quiere control total de sus datos
- Arize Phoenix: detección de drift y evaluación de embeddings. Visualiza cómo la distribución de tus inputs cambia en el tiempo. Open source
- Helicone: proxy para APIs de LLM que captura cada request con costo, tokens y metadata. Setup en 5 minutos: cambias la base URL del SDK y listo
En nodo. usamos un stack pragmático: Langfuse para tracing de agentes, Prometheus para métricas de infraestructura, y un eval suite custom con Python que corre como cron job cada 24 horas. El costo total de observabilidad es menor al 3% del costo de los LLMs que monitoreamos.
¿Cómo implemento evaluación continua para mi sistema de IA?
La evaluación continua es el componente más importante y el más ignorado. No basta con evaluar tu sistema antes del deploy. Necesitas evaluarlo todos los días, automáticamente, contra un dataset de referencia que represente los casos de uso reales.
Construye tu golden dataset
Un golden dataset es un conjunto de 150-300 pares de pregunta-respuesta esperada que representan los escenarios críticos de tu sistema. No necesitas miles: necesitas los correctos. Incluye:
- Happy path: 60% del dataset. Las preguntas típicas que tus usuarios hacen diariamente
- Edge cases: 25% del dataset. Preguntas ambiguas, fuera de scope, en formatos inesperados
- Adversarial: 15% del dataset. Intentos de jailbreak, inyección de prompts, preguntas que deberían ser rechazadas
Cada entrada tiene: query de input, respuesta esperada (o criterios de evaluación), y un score de referencia (baseline). El eval suite corre el dataset completo contra tu sistema en producción, compara los resultados contra la baseline, y dispara alertas si hay degradación. Nosotros usamos un LLM como juez (Claude evaluando las respuestas de tu pipeline) con rúbricas específicas por tipo de pregunta.
¿Cuánto cuesta operar observabilidad para IA?
Este es un punto donde la mayoría de los equipos sobreestiman o subestiman. La observabilidad no debería costar más que el 5% de tu gasto en LLMs. Si estás pagando más, probablemente estás almacenando demasiado o usando herramientas sobredimensionadas.
| Componente | Opción económica | Opción enterprise | Costo mensual aprox. |
|---|---|---|---|
| Tracing de LLM | Langfuse self-hosted | LangSmith / Datadog LLM | $0 – $400 |
| Métricas infra | Prometheus + Grafana | Datadog APM | $0 – $200 |
| Eval suite | Script Python + cron | Braintrust / RAGAS cloud | $20 – $150 |
| Drift detection | Arize Phoenix OSS | Arize cloud | $0 – $300 |
| Alertas | Slack webhooks | PagerDuty + OpsGenie | $0 – $50 |
Para una empresa mediana en Chile operando un sistema de IA con 5,000-20,000 requests diarios, el stack completo de observabilidad cuesta entre USD $50 y $300 mensuales usando herramientas open source. Con stack SaaS enterprise, sube a USD $500-1,200. En ambos casos, es una fracción del costo de los LLMs (que típicamente están entre USD $500-3,000/mes para ese volumen).
¿Por qué la observabilidad tradicional no alcanza para IA?
La observabilidad tradicional fue diseñada para sistemas deterministas: dado el mismo input, esperas el mismo output. Los sistemas de IA son inherentemente no deterministas. El mismo prompt puede generar respuestas distintas en ejecuciones sucesivas. Esto rompe asunciones fundamentales del monitoreo clásico:
- No puedes hacer assertions exactas: en tests clásicos verificas
output === expected. En IA necesitas evaluación semántica: ¿la respuesta captura la idea correcta, aunque las palabras sean distintas? - Las fallas son probabilísticas: un sistema puede alucinar en el 3% de los requests. Eso no dispara un alerta de error rate clásica, pero es inaceptable en producción
- El costo es variable por request: un request de 100 tokens y uno de 4,000 tokens cuestan 40x diferente. Sin monitoreo granular de tokens, tu factura es una caja negra
- La cadena causal es larga: en un agente con tool calling, un solo request puede involucrar 3-8 llamadas a LLM, cada una con su propia latencia, costo y potencial punto de falla
¿Cuál es el primer paso para implementar observabilidad?
No intentes implementar todo de una vez. El orden que recomendamos en nodo., basado en lo que hemos visto funcionar en producción real:
- Semana 1: Structured logging con
request_iden cada paso del pipeline. Cada log entry incluye: timestamp, request_id, componente (retriever, LLM, post-process), tokens in/out, latencia, y estado - Semana 2: Dashboard básico con latencia p50/p95, costo diario, y error rate. Grafana con Prometheus o CloudWatch si estás en AWS
- Semana 3: Eval suite con 50 casos iniciales (crece a 200+ en los meses siguientes). Cron job diario que compara contra baseline
- Mes 2: Tracing completo con Langfuse o LangSmith. Alertas escalonadas en Slack
- Mes 3: Drift detection y evaluación automática de hallucinations con LLM-as-judge
Este orden prioriza lo que te da visibilidad inmediata (logs y métricas) antes de invertir en herramientas más sofisticadas. Cada paso es útil por sí solo: no necesitas completar todo para obtener valor.
Si no puedes medir la calidad de tu sistema de IA en producción, no sabes si tu sistema funciona. Funciona hasta que deja de funcionar, y sin observabilidad, te enteras por tus usuarios.