Observabilidad en sistemas con LLM: más allá de los logs

Un stack con LLM mezcla retrieval, generación, post-procesado y llamadas a terceros. Cuando algo «se siente mal» para el usuario, rara vez hay un stack trace que lo explique: hay una cadena de decisiones probabilísticas.

Los logs de request/response siguen siendo necesarios, pero no suficientes. Necesitás evaluaciones periódicas sobre un golden set curado con casos de negocio — preguntas reales, respuestas esperadas o criterios de calidad acordados con producto.

Medí latencia p95 por etapa: embedding, búsqueda, generación, validación de salida. En la práctica, los cuellos de botella suelen estar en retrieval mal dimensionado o en serialización innecesaria entre servicios, no en el modelo en sí.

Las alertas de infraestructura (CPU, errores 5xx) llegan tarde al problema de calidad. Sumá señales de producto: thumbs down, re-apertura de tickets, abandono del flujo, deriva de costo por sesión. Esas métricas anticipan el incidente visible.

Versioná prompts, configuración de RAG y datasets de evaluación como código en el mismo repositorio que la aplicación. Un cambio de modelo sin regresión documentada es deuda técnica que explota en el primer pico de tráfico o en la primera campaña de marketing.

La observabilidad madura termina en un ritual: revisión semanal de evals + muestra de conversaciones reales. Eso alinea ingeniería y negocio sobre qué «bueno» significa en producción.