Observabilidad de LLMs en producción: Langfuse vs Arize

TL;DR

La observabilidad de LLMs en producción es la práctica de instrumentar, registrar, evaluar y alertar sobre cada llamada a un modelo de lenguaje desplegado en un entorno real, midiendo latencia, coste, tokens, errores y calidad de respuesta con el mismo rigor con el que un equipo SRE monitoriza un servicio crítico. En Datalvar AI montamos pipelines basadas en Langfuse self-hosted cuando hay datos sensibles, Arize Phoenix cuando el cliente prioriza evaluación experimental rápida y Helicone o LangSmith en casos puntuales. Los KPIs que de verdad mueven la aguja son latencia P95/P99 por endpoint, coste por request y por sesión, error rate desagregado por tipo, hallucination rate medida con LLM-as-judge calibrado y drift semántico de inputs. Sin esa capa, un agente o un RAG pueden parecer estables durante semanas y derrumbarse en silencio cuando cambian las preguntas reales de los usuarios.

¿Por qué la observabilidad de LLMs en producción es un problema distinto al de un microservicio clásico?

Cuando entramos por primera vez en un proyecto donde el cliente ya tiene un asistente o un agente en producción, la conversación suele empezar con frases del tipo “funciona bien, pero a veces hace cosas raras”. Esa frase es la confesión exacta de que no hay observabilidad de LLMs en producción digna de ese nombre. Si un microservicio HTTP tradicional fallara “a veces”, cualquier equipo decente sacaría inmediatamente el dashboard de Datadog, Grafana o New Relic, miraría latencias y códigos de error y tendría hipótesis razonables en minutos. Con un LLM no, porque los síntomas son cualitativos, intermitentes y dependen del input.

Un LLM no es determinista en el sentido clásico. La misma pregunta con la misma temperatura puede generar respuestas distintas, y aunque fijemos temperature=0 y seed, el comportamiento del modelo cambia cuando OpenAI, Anthropic o Google despliegan una versión nueva sin avisarte, cuando el contexto recuperado por el RAG varía un 5%, cuando un usuario hace una pregunta fuera de distribución o cuando una tool del agente devuelve un error parcial que el modelo decide ignorar de forma silenciosa. Esto rompe el modelo mental clásico de monitorización: ya no basta con “está arriba o está abajo”, necesitamos saber si está respondiendo bien. La observabilidad de LLMs en producción nace precisamente para llenar ese hueco entre “el servicio responde HTTP 200” y “el servicio está dando respuestas útiles”.

A eso se suma que el coste deja de ser una línea fija en la factura de infra y se vuelve variable por interacción. Un agente que entra en un bucle de razonamiento puede convertir una pregunta de tres euros de coste medio en una de treinta sin avisar a nadie. Una mala caché o un prompt mal escrito multiplican los tokens de salida. La consecuencia práctica es que la observabilidad de LLMs en producción tiene que cubrir simultáneamente tres dimensiones que en un microservicio normal viven separadas: rendimiento, coste y calidad. Cuando ese trípode no está completo, lo que parece estabilidad acaba siendo deuda invisible que estalla en facturas, en cancelaciones de clientes o en titulares incómodos.

¿Qué significa exactamente “observar” un LLM y no solo monitorizarlo?

Conviene separar dos conceptos que en el mundo de IA se mezclan a menudo. Monitorización es saber si algo está funcionando: pings, healthchecks, alertas de caída. Observabilidad es poder responder preguntas nuevas sobre el sistema sin tener que desplegar código adicional. Aplicado a LLMs significa que cuando un cliente nos dice “el chatbot dio una respuesta incorrecta el martes a las 16:42 al usuario X”, deberíamos poder reconstruir esa interacción completa: prompt del sistema, mensajes previos, documentos recuperados por el retriever, llamadas a tools, tokens consumidos, latencia por paso y respuesta final.

En la práctica eso se traduce en instrumentar trazas distribuidas siguiendo el espíritu de OpenTelemetry, aunque adaptadas al ciclo de vida de un LLM. Cada generación es un “span”; cada paso del agente es otro span anidado; cada llamada a una tool, otro más. Langfuse y Arize Phoenix lo soportan de forma nativa, y los SDK oficiales se integran con LangChain, LlamaIndex, OpenAI SDK, Anthropic SDK y los frameworks principales de orquestación. Sin esta traza completa, depurar es adivinar.

Esta diferencia tiene una implicación operativa que nos gusta dejar clara en el primer kick-off con cualquier cliente. La observabilidad no es un dashboard bonito que mira el CTO una vez al mes; es una herramienta de operación diaria que un equipo de producto, soporte y data usa para responder incidencias concretas. Cuando se diseña con esa intención, los datos se almacenan completos, las búsquedas funcionan por sesión y usuario, y las métricas agregadas tienen sentido. Cuando se diseña para parecer profesional sin pensar en el caso de uso, acaba siendo decoración cara. Por eso insistimos en que la observabilidad de LLMs en producción es, ante todo, un compromiso operativo, no una compra de software.

¿Por qué los SLOs típicos de SRE no se trasladan literalmente a un LLM?

Un SLO clásico de un endpoint REST suele ser algo como “99,9% de las peticiones respondidas en menos de 200 ms con un 0,1% de errores 5xx en una ventana de 30 días”. Trasladado a un LLM, ese 99,9% se desmorona porque la latencia depende del tamaño del prompt, del tamaño esperado de la respuesta, del modelo elegido, de si hay streaming o no y de la carga del proveedor cloud que sirve el modelo. Pretender uniformidad en esos números es ingenuo.

Lo que sí funciona es definir SLOs segmentados por flujo de negocio. En un asistente conversacional típico podemos definir, por ejemplo, “respuesta inicial visible al usuario en menos de 1,5 segundos en P95” si hay streaming, distinguiéndolo del tiempo total hasta completar la respuesta. En un agente que hace varias llamadas a tools, el SLO útil es el “tiempo total hasta acción ejecutada”, no la latencia bruta del modelo. En un pipeline batch de generación, el SLO puede ser “coste por documento procesado menor de X céntimos en el percentil 95”.

Un SLO de LLM que no distingue entre streaming y respuesta completa, entre agente y llamada simple, o entre coste fijo y coste por interacción, no es un SLO: es un titular para tranquilizar al comité.

La consecuencia es que parte de la observabilidad consiste en construir vistas distintas para cada flujo y no caer en la trampa del “dashboard único”. A los pocos meses, los equipos que han hecho bien este trabajo tienen entre cinco y diez vistas operativas, cada una mapeada a un flujo de producto, con sus propios paneles, alertas y umbrales. Los equipos que se quedaron en un dashboard genérico siguen depurando por intuición. En la observabilidad de LLMs en producción, la granularidad por flujo de negocio no es un lujo sino una condición de utilidad.

¿Qué métricas de verdad importan en la observabilidad de LLMs en producción?

Si tuviéramos que reducir todo el ruido del mercado a una lista corta, en Datalvar AI defendemos un set de métricas que siempre estará en cualquier proyecto serio de observabilidad de LLMs en producción. Hablamos de métricas que no solo se miden, sino que se accionan: cada una tiene un dueño, un umbral y un plan B cuando se cruza. Esta lista no es teoría sacada de un paper, es el destilado de incidentes reales que hemos tenido que cerrar en clientes con tráfico de cientos de miles de interacciones al mes. Cada métrica viene asociada a un tipo de incidente concreto que aprendimos a temer.

Las métricas se organizan en tres bloques: rendimiento, coste y calidad. Es importante no confundir bloques porque las decisiones que se toman a partir de cada uno son distintas. Una alerta de latencia abre un ticket técnico; una alerta de coste abre una conversación con producto; una alerta de calidad abre un debate con negocio. Diseñar la observabilidad de LLMs en producción con esa segregación clara facilita la operación y reduce el ruido.

A continuación las desglosamos con el detalle suficiente para que cualquier equipo técnico pueda implementarlas sin tener que reinventar nada. Si tu equipo está empezando, basta con cubrir las métricas marcadas como críticas en la primera iteración y dejar el resto para sprints posteriores. Lo importante es no caer en el extremo opuesto: medirlo todo sin priorizar acaba en parálisis y en dashboards que nadie mira. La observabilidad de LLMs en producción es un ejercicio de selección, no de acumulación.

¿Cómo medir latencia P50, P95 y P99 cuando hay streaming, agentes y tools?

La latencia en un LLM no es un número, son varios. El más visible es time-to-first-token (TTFT), fundamental cuando hay streaming porque define la percepción de velocidad del usuario. El segundo es time-to-last-token (TTLT) o “tiempo total de generación”, que cuenta lo que tarda en completarse la respuesta. El tercero es tiempo total del flujo, que en un agente incluye llamadas a tools, retrievers, ejecuciones de código y, finalmente, la generación textual.

En cualquier proyecto de observabilidad de LLMs en producción hay que medir los tres percentiles (P50, P95, P99) para cada uno de esos tiempos, segmentados al menos por modelo, endpoint y tenant. El P50 te dice cómo va la experiencia mediana, el P95 te dice cuándo se enciende el botón rojo del producto y el P99 te dice si hay outliers patológicos que merecen investigación individual. En general, en proyectos serios solemos alertar sobre P95 y reservar P99 para análisis manual.

Una práctica que recomendamos es medir también la latencia añadida por la orquestación, es decir, la diferencia entre lo que cobra el proveedor del modelo y lo que mide el cliente final. Cuando esa diferencia crece sin explicación, suele indicar problemas en el retriever, en serialización JSON pesada, en logs síncronos que bloquean o en políticas de retry mal configuradas. Hemos visto casos donde el 40% de la latencia total venía del propio stack del cliente, no del modelo, y nadie lo había detectado porque el dashboard solo enseñaba “tiempo de OpenAI”. Una observabilidad de LLMs en producción digna de ese nombre obliga a medir extremo a extremo, no solo el tramo más vistoso.

¿Cómo controlar coste por request, por sesión y por feature?

El coste es la métrica que más rápido cambia la prioridad de un proyecto de IA cuando empieza a escalar. Una demo divertida que cuesta diez céntimos por interacción se vuelve insostenible si el producto recibe cien mil interacciones diarias. Por eso la observabilidad de LLMs en producción debe registrar, en cada llamada, tokens de entrada, tokens de salida, modelo usado, coste calculado en dólares o euros, y tags de contexto (feature, endpoint, plan del cliente, idioma).

Con esos datos crudos se construyen tres vistas útiles. La primera es coste por feature, que permite responder “¿qué partes del producto son rentables y cuáles no?”. La segunda es coste por sesión o por usuario activo, fundamental cuando hay un modelo de negocio por suscripción y necesitas saber si tus clientes premium están consumiendo más de lo que pagan. La tercera es distribución de coste por percentil, que detecta usuarios o flujos anómalos: si el 1% superior de sesiones consume el 30% del coste, ahí hay un patrón a investigar (abusos, bucles, prompts mal diseñados).

Si no sabes cuánto te cuesta atender al percentil 99 de tus usuarios en IA, no estás operando un producto: estás patrocinándolo.

Aquí Langfuse, Helicone y LangSmith hacen un trabajo limpio porque calculan el coste automáticamente sabiendo el modelo y los tokens. La trampa es no fiarse ciegamente del coste mostrado: hay que validar trimestralmente que los precios de los proveedores no han cambiado y que la tabla de tarifas interna de la herramienta está actualizada. En 2024 y 2025 hubo varias bajadas de precio relevantes en OpenAI, Anthropic y Google, y vimos equipos cuyo dashboard seguía calculando con tarifas viejas durante meses. No es un problema crítico, pero distorsiona las decisiones. Una observabilidad de LLMs en producción que pinta números viejos es solo marketing interno.

¿Cómo medir calidad sin caer en métricas vacías como BLEU o ROUGE?

Las métricas tradicionales de NLP (BLEU, ROUGE, METEOR) nacieron para tareas de traducción automática y resumen donde existe una “respuesta correcta” contra la que comparar. En la observabilidad de LLMs en producción aplicada a un asistente conversacional, un agente o un RAG empresarial, esa “respuesta correcta” rara vez existe, y cuando existe es subjetiva. Por eso BLEU y ROUGE tienen una utilidad muy limitada y solo los usamos en casos muy concretos (traducción, generación con plantilla fija, comparación contra un gold set bien curado).

Las métricas que sí funcionan en producción son las basadas en LLM-as-judge y en evaluadores específicos del dominio. La idea es usar un modelo (típicamente más potente que el que está en producción) como juez para evaluar cada respuesta según criterios definidos: relevancia, factualidad, tono, completitud, ausencia de información sensible. Estas evaluaciones se ejecutan de forma asíncrona sobre una muestra representativa del tráfico (entre el 1% y el 10%, dependiendo de volumen y presupuesto) y los resultados se agregan en dashboards.

El gran riesgo del LLM-as-judge es la calibración. Un juez sin un set de ejemplos anotados manualmente puede dar veredictos consistentes pero sesgados. Por eso en Datalvar AI siempre montamos primero un “golden set” de entre 100 y 500 ejemplos etiquetados por humanos del cliente, lo usamos para calibrar el prompt del juez hasta que su acuerdo con los humanos supera un umbral aceptable (típicamente Cohen’s kappa por encima de 0,6) y solo entonces lo ponemos a evaluar tráfico real. Saltarse este paso es la diferencia entre tener una métrica útil y una métrica que solo confirma sesgos del equipo de desarrollo. La calidad es la dimensión más delicada de la observabilidad de LLMs en producción y la que más rigor metodológico exige.

¿Qué hacer con error rate, hallucination rate y drift de inputs?

El error rate clásico se refiere a fallos técnicos: timeouts, rate limits del proveedor, errores de parsing de salida JSON, fallos en tools. Es la métrica más fácil de instrumentar porque la mayoría son excepciones capturables. Aquí lo importante es desagregar por tipo de error, porque “5% de errores” no significa nada operativamente: si el 90% son timeouts del proveedor, el plan de acción es uno; si son fallos de parsing, es otro completamente distinto.

El hallucination rate es más sutil porque requiere evaluación. En un sistema RAG lo medimos comprobando si cada afirmación de la respuesta está respaldada por los documentos recuperados, usando un evaluador LLM con un prompt cuidadosamente diseñado. En un asistente sin contexto recuperado, la tarea es más difícil y solemos limitarnos a detectar inconsistencias evidentes (fechas imposibles, nombres inventados de productos del propio cliente, citas falsas) usando reglas combinadas con verificación cruzada. Es una métrica costosa de mantener pero crítica en sectores regulados.

El drift de inputs es la métrica que más equipos pasan por alto. Se trata de detectar cuándo los usuarios empiezan a hacer preguntas distintas a las que el sistema fue diseñado para responder. Lo medimos comparando embeddings de inputs reales contra una distribución de referencia y vigilando la divergencia. Cuando el drift sube de forma sostenida, sabemos que hay que añadir documentación nueva al RAG, ampliar la cobertura de tools del agente o reentrenar el clasificador de intención. Sin esta métrica integrada en la observabilidad de LLMs en producción, los sistemas degradan en silencio durante meses antes de que alguien lo note.

¿Qué herramientas elegir para la observabilidad de LLMs en producción y por qué?

El mercado de herramientas para observabilidad de LLMs en producción se ha consolidado bastante en los últimos dos años. Hay cuatro nombres que aparecen en prácticamente todas las conversaciones serias: Langfuse, Arize Phoenix, Helicone y LangSmith. Cada uno tiene una filosofía y un caso de uso ideal, y la elección rara vez es “el mejor” sino “el adecuado para este cliente concreto”. Cuando entramos en un proyecto, lo primero que evaluamos son tres ejes: soberanía del dato, profundidad de evaluación y madurez del equipo operativo.

Vamos a recorrerlas con honestidad, incluyendo lo que nos gusta y lo que no de cada una. No tenemos partnership con ninguna, no cobramos referrals y nuestros clientes nos pagan por elegir bien, no por defender una marca. Los criterios que aplicamos cambian según el sector: en salud, banca y administración pública el filtro de soberanía del dato es eliminatorio; en startups SaaS B2B pesa más la velocidad de iteración; en proyectos con tooling muy específico de LangChain o LangGraph, la integración nativa puede ser decisiva. La observabilidad de LLMs en producción no se elige en abstracto, se elige contra las restricciones reales del cliente.

A continuación entramos en cada herramienta con el detalle que nos gustaría haber tenido cuando empezamos. La idea no es comparar features, eso está en la web de cada producto. La idea es contar qué pasa cuando las pones a trabajar como pilar de observabilidad de LLMs en producción en un cliente real con tráfico, equipo limitado y deadlines apretados.

¿Por qué recomendamos Langfuse self-hosted en clientes con datos sensibles?

Langfuse es nuestro caballo de batalla en la mayoría de proyectos donde hay datos sensibles. Es open source, está bajo licencia MIT en el componente core, se despliega con Docker Compose o Helm en pocas horas y ofrece una experiencia de producto que está cerca de los SaaS comerciales. Para un cliente con datos médicos, financieros o de menores que no puede enviar prompts ni respuestas a un tercero, Langfuse self-hosted resuelve la papeleta sin sacrificar funcionalidad.

Lo que más nos gusta de Langfuse es el modelo de datos: tiene el concepto de “trace” como contenedor de una interacción de usuario, “observation” como unidad atómica (generación, span, evento) y “session” como agrupación de varias interacciones de un mismo usuario. Esa estructura encaja como un guante con asistentes conversacionales, agentes y RAGs. Además, el SDK de Python y TypeScript es minimalista, los decoradores son agradables de usar y la integración con LangChain, LlamaIndex, Vercel AI SDK y OpenAI SDK funciona prácticamente plug-and-play.

Donde sufre Langfuse, en nuestra experiencia, es en la parte de evaluación offline a gran escala. Tiene funcionalidad de datasets y evaluators, mejorada bastante en las últimas releases, pero cuando un cliente quiere correr miles de evaluaciones automatizadas con métricas específicas del dominio y comparar versiones de prompts en CI/CD, a veces hay que complementar con scripts propios. Aun así, en el 80% de proyectos cubre todo el ciclo. Y para el 20% restante, suele bastar con una integración ligera con MLflow o con un runner casero conectado al backend de observabilidad de LLMs en producción.

¿Qué aporta Arize Phoenix en evaluación experimental y debugging de RAG?

Arize Phoenix es otro open source, también desplegable on-prem, que viene del mundo del MLOps clásico y por eso tiene una visión muy fuerte de evaluación y experimentación. Lo recomendamos especialmente cuando el cliente tiene un equipo de data science maduro y quiere hacer evaluación rigurosa de prompts, comparar pipelines de RAG, debuggear retrieval con embeddings visualizables y, en general, tratar el sistema de IA con la misma seriedad con la que trataría un modelo de ML clásico.

La gran fortaleza de Phoenix es el conjunto de evaluators preconstruidos y el flujo de trabajo de notebooks. Tiene desde evaluadores de relevancia y factualidad hasta evaluación específica de hallucinaciones en RAG, todo con prompts ya calibrados que puedes usar como punto de partida y adaptar. Además, la integración con OpenTelemetry es de primera, lo que facilita conectar la observabilidad de LLMs con el resto del stack de observabilidad clásica de la empresa.

Lo que no nos termina de convencer es la experiencia operativa diaria. Phoenix está pensado más como herramienta de experimentación que como dashboard de producto, y aunque tiene UI para producción, en proyectos donde el equipo de soporte necesita investigar incidencias concretas, Langfuse nos resulta más cómodo. La combinación que más estamos viendo en clientes grandes es Langfuse para operación diaria y Phoenix para experimentación de calidad, con un puente de datos entre ambos. No es lo más simple, pero permite combinar lo mejor de cada herramienta dentro de una estrategia única de observabilidad de LLMs en producción.

¿Cuándo tiene sentido Helicone o LangSmith?

Helicone es un proxy de observabilidad muy ligero. La integración es prácticamente cambiar el base_url de OpenAI por el suyo y ya. Esa simplicidad lo hace ideal para startups que necesitan visibilidad básica de tráfico, coste y latencia sin invertir tiempo en instrumentación. La parte negativa es que, al funcionar como proxy, todo el tráfico pasa por su infraestructura en la versión cloud, lo que en muchos clientes europeos no es asumible. Tiene self-hosted, pero la experiencia de despliegue y mantenimiento es menos pulida que Langfuse.

LangSmith es la apuesta de LangChain Inc. y su gran ventaja es la integración nativa con LangChain y LangGraph. Si un equipo ya está casado con ese stack, ahorra muchísimo tiempo porque la observabilidad llega gratis. La gran pega es que no tiene self-hosted gratuito (existe una opción enterprise on-prem pero con precio enterprise) y eso descarta su uso en muchos contextos europeos sensibles a privacidad. Cuando el cliente no tiene problema con el envío de datos y quiere acelerar al máximo, LangSmith es una opción muy sólida para arrancar la observabilidad de LLMs en producción en cuestión de días.

No existe la mejor herramienta de observabilidad de LLMs en producción: existe la que casa con tu modelo de datos, tu soberanía digital y la madurez operativa de tu equipo.

Nuestra recomendación general para la mayoría de proyectos en España y la UE es Langfuse self-hosted como base, complementado con Arize Phoenix cuando el equipo de IA quiere profundizar en evaluación, y usar Helicone o LangSmith puntualmente en MVPs donde la prioridad sea la velocidad. Esta combinación cubre el 90% de casos de observabilidad de LLMs en producción que vemos en proyectos europeos.

!IMAGE_TODO[diagrama comparativo Langfuse vs Arize Phoenix vs Helicone vs LangSmith con ejes soberanía/evaluación/operativa]

¿Cómo se diseña un dashboard útil de observabilidad de LLMs en producción?

Hemos visto suficientes dashboards de observabilidad de LLMs en producción mal montados como para tener una opinión muy fuerte sobre lo que funciona y lo que no. El error más común es confundir el dashboard con un escaparate técnico, llenándolo de gráficas que demuestran que se está midiendo “mucho” pero que nadie utiliza para tomar decisiones reales. Un dashboard útil es uno que se mira cada día y del que salen acciones concretas.

Trabajamos siempre con tres capas de dashboards, segregadas por audiencia y por frecuencia de uso. La capa operativa la mira el equipo técnico cada mañana y ante cualquier incidencia. La capa de producto la mira el PM y el equipo de éxito de cliente una vez por semana. La capa ejecutiva la mira la dirección una vez al mes y solo agrega métricas estratégicas. Cuando se mezclan las capas, todas se devalúan: el ejecutivo se pierde en detalles técnicos, el técnico se aburre de mirar métricas comerciales y el producto no encuentra lo que necesita.

Otra regla que aplicamos es la del “umbral de acción”. Cada gráfica del dashboard tiene que tener asociado, de forma explícita, qué hacer cuando se cruza un umbral concreto. Si no hay acción definida, la gráfica sobra. Esta regla, aplicada con disciplina, reduce los dashboards a la mitad y los hace mucho más operativos. Suena obvio, pero la cantidad de dashboards en producción que violan esta regla es enorme.

¿Qué debe ver el equipo técnico cada mañana?

El dashboard operativo del equipo técnico que opera la observabilidad de LLMs en producción suele tener entre cinco y ocho gráficas, nunca más. Las críticas son: latencia P95 por endpoint en las últimas 24 horas con línea horizontal del SLO, error rate desagregado por tipo de error en las últimas 24 horas comparado con la línea base de la semana anterior, coste acumulado del día comparado con el coste medio diario del último mes, número de trazas con feedback negativo del usuario en las últimas 24 horas y drift score de inputs en las últimas 24 horas.

Las complementarias, que ayudan a investigar cuando algo se enciende, son: distribución de tokens de entrada y salida, tasa de cache hit si existe capa de caché, disponibilidad por proveedor (OpenAI, Anthropic, Google) si se usa más de uno, y un top 10 de sesiones más caras o más largas del día para investigación manual.

Lo que NO debe estar en este dashboard, aunque pueda parecer útil, son métricas semanales o mensuales agregadas, comparativas con periodos largos, métricas comerciales como conversión o retención y, por supuesto, gráficas decorativas. El equipo técnico necesita poder identificar en treinta segundos si hoy hay un problema y cuál es la dirección probable. Todo lo demás distrae y arruina la utilidad operativa de la observabilidad de LLMs en producción.

¿Qué debe ver el equipo de producto cada semana?

El dashboard de producto cambia de horizonte temporal y de tipo de métrica. Las gráficas críticas aquí son: evolución semanal de feedback positivo y negativo por feature, número de usuarios activos que usaron IA por día, distribución de calidad estimada por LLM-as-judge segmentada por flujo, coste por usuario activo mensual, drift acumulado de inputs por mes y top 10 de intents o flujos con peor calidad.

El propósito de este dashboard no es operar, es decidir prioridades de roadmap. ¿Hay un flujo donde la calidad se está degradando? Hay que invertir en ese flujo. ¿El coste por usuario activo está subiendo más rápido que la facturación por usuario? Hay que renegociar precios o optimizar prompts. ¿Hay un drift sostenido de inputs hacia un tema nuevo? Hay que ampliar la documentación o cambiar el alcance del producto.

Una práctica que recomendamos es vincular cada gráfica de este dashboard a un ticket o iniciativa del backlog cuando se cruza un umbral. Sin ese vínculo explícito, el dashboard se convierte en información pasiva. Cuando hay un mecanismo de “métrica mala → ticket creado”, la observabilidad de LLMs en producción empieza a tener efecto real en la dirección del producto.

¿Qué debe ver dirección cada mes?

El dashboard ejecutivo es el más sencillo de diseñar y el más fácil de hacer mal. Debe responder cinco preguntas: cuánto nos cuesta la IA, cuánto valor está generando, qué riesgos están aumentando, qué decisiones de inversión hay que tomar y cómo estamos comparados con objetivos definidos. Cinco preguntas, cinco gráficas o tablas, y nada más. Cuando un dashboard ejecutivo tiene veinte gráficas, no se mira o se mira mal.

Las gráficas concretas suelen ser: coste mensual total de IA por línea de producto, calidad agregada del último mes vs trimestre anterior, ahorro estimado o ingreso atribuible al sistema de IA, número de incidencias significativas del mes y su tiempo de resolución, y estado de SLOs principales. Si el cliente está en sector regulado, añadimos también un panel de cumplimiento que muestre número de respuestas filtradas por moderación, accesos a datos sensibles y trazabilidad de modelos usados.

Este dashboard suele exportarse como PDF mensual para el comité y para los stakeholders no técnicos. La trampa habitual es maquillar los números cuando son malos, pero esa es exactamente la peor decisión posible: la observabilidad de LLMs en producción existe para diagnosticar realidad, y un comité que no ve la realidad acaba tomando decisiones equivocadas. En Datalvar AI defendemos siempre presentar los números crudos con narrativa honesta encima.

¿Cómo configurar alertas que no se conviertan en ruido?

Las alertas son el frente donde la observabilidad de LLMs en producción se gana o se pierde como práctica operativa. Un sistema de alertas bien diseñado convierte al equipo en alguien que duerme tranquilo y se levanta cuando hay algo real. Un sistema mal diseñado convierte al equipo en alguien que silencia notificaciones a las dos semanas y deja de mirar el canal en Slack al mes. El segundo caso es peligrosísimo porque crea la ilusión de tener observabilidad de LLMs en producción sin tenerla realmente.

La regla más importante que aplicamos es alert fatigue ≥ no alert. Es preferible tener menos alertas y que cada una sea accionable que tener muchas y que el 80% se ignore. Cuando entramos en un proyecto donde ya hay alertas configuradas, lo primero que hacemos es auditar el ratio de alertas accionadas vs ignoradas en los últimos 30 días. Si está por debajo del 60%, recomendamos pausar todas las alertas y reconstruir desde cero con criterios estrictos.

Las alertas se dividen en tres niveles de severidad, cada uno con un canal de respuesta distinto. Crítica: despierta a alguien por la noche o interrumpe la jornada inmediatamente. Alta: requiere atención en horario laboral del mismo día. Informativa: aparece en un canal de equipo pero no requiere acción urgente. Esa segregación, bien aplicada, es la diferencia entre un on-call humano y uno que quema personas. La observabilidad de LLMs en producción tiene que cuidar a quien la opera, no solo al sistema observado.

¿Qué alertas críticas debe tener cualquier sistema en producción?

Las alertas críticas son las que apuntan a fallos de servicio reales y deben ser muy pocas. Las que aplicamos por defecto son: error rate global por encima del 5% sostenido durante más de 5 minutos, caída total de uno de los proveedores principales detectada por error 5xx persistente, latencia P95 superior al doble del SLO durante más de 10 minutos y coste por hora más de tres veces el coste medio horario del último mes. Estas cuatro cubren la mayoría de incidentes graves sin generar ruido.

Conviene resistir la tentación de meter aquí alertas de calidad. La calidad fluctúa por naturaleza y casi nunca requiere acción inmediata: una caída del 5% en relevancia del LLM-as-judge a las tres de la mañana de un sábado no es razón para despertar a nadie. Esas señales pertenecen al nivel alta o informativa, donde se procesan en horario y con calma.

Otra regla que aplicamos es que toda alerta crítica debe tener un runbook asociado documentando los primeros cinco pasos de diagnóstico. Sin runbook, el on-call gasta los primeros 20 minutos averiguando dónde mirar, lo cual es inaceptable cuando hay tráfico afectado. El runbook debe ser corto, ejecutable y mantenido por el equipo que diseña las alertas dentro de la observabilidad de LLMs en producción, no por nadie externo al sistema.

¿Cómo evitar el ruido en alertas de calidad y drift?

Las alertas de calidad y drift son las más peligrosas en términos de fatiga porque son métricas ruidosas por naturaleza. La técnica que mejor nos funciona es usar ventanas largas y comparación contra base. Por ejemplo, en lugar de alertar cuando la relevancia LLM-as-judge baja del 80% en una hora, alertamos cuando la media móvil de 24 horas baja más de 5 puntos respecto a la media móvil de 7 días anteriores. Esto elimina los falsos positivos por ruido estadístico.

Otra técnica es agrupar señales relacionadas en una sola alerta compuesta. Si la calidad baja al mismo tiempo que sube el drift de inputs y baja la cache hit, probablemente sea el mismo incidente y no tres distintos. Las herramientas modernas de alertas (PagerDuty, Opsgenie, Grafana OnCall) permiten estas agrupaciones con relativa facilidad y son fundamentales para mantener el ruido bajo control.

Por último, para alertas de coste recomendamos predicción de fin de mes. En vez de alertar cuando el coste del día supera un umbral arbitrario, alertamos cuando la proyección lineal del coste mensual basada en lo que llevamos del mes supera el presupuesto. Esto evita falsos positivos por días de tráfico alto puntuales y captura desvíos sostenidos que sí requieren intervención. La calidad del sistema de alertas marca, en última instancia, la madurez real de la observabilidad de LLMs en producción.

¿Cómo es un caso real de implementación de observabilidad de LLMs en producción?

Vamos a contar un caso concreto, anonimizado, para que se entienda cómo se traduce todo lo anterior sobre observabilidad de LLMs en producción a un proyecto real con plazos y presupuesto. Cliente: empresa SaaS B2B europea del sector legal, con un asistente conversacional integrado en su producto que ayuda a abogados a buscar jurisprudencia y redactar borradores de escritos. Tráfico: alrededor de 80.000 interacciones diarias en hora pico, con picos de hasta 12.000 por hora. Stack original: LangChain + GPT-4o + Pinecone, sin observabilidad más allá de logs en CloudWatch.

Cuando entramos en el proyecto, el síntoma del cliente era “el asistente da respuestas correctas el 80% de las veces, pero cuando falla, falla feo y los abogados se quejan”. El equipo no podía cuantificar ese 80%, era una intuición del jefe de producto. El coste mensual de OpenAI estaba creciendo un 15% mes a mes sin que pudieran explicar por qué. Y había habido dos incidentes en los seis meses anteriores donde un cambio de prompt aparentemente menor había degradado el sistema y se habían enterado por tickets de soporte, no por alertas, porque no existía aún ninguna capa de observabilidad de LLMs en producción merecedora de ese nombre.

El proyecto duró tres meses, con un equipo de dos personas nuestras dedicadas part-time y una persona del cliente como point of contact. El presupuesto total estuvo por debajo de los 35.000 euros y lo amortizaron en aproximadamente cinco meses solo con la reducción de coste de tokens. La parte de calidad y operación se considera ganancia recurrente. A continuación contamos las decisiones técnicas y operativas más relevantes del proyecto de observabilidad de LLMs en producción.

¿Qué stack final implementamos y por qué?

Elegimos Langfuse self-hosted desplegado en el clúster Kubernetes del cliente como pieza central. El motivo principal fue soberanía del dato: como cliente del sector legal, no podían enviar contenido de prompts y respuestas a un tercero europeo, ni mucho menos a uno estadounidense. Langfuse en self-hosted con Postgres y ClickHouse encajaba con su política de seguridad y permitía cumplir con su DPO sin discusión.

Sobre Langfuse construimos una capa de evaluación con Arize Phoenix instalado en modo notebook para el equipo de IA del cliente. Phoenix se usaba solo en flujos experimentales: cuando había un cambio de prompt importante, se lanzaba una evaluación offline sobre el golden set y se comparaba la versión nueva contra la actual antes de subir a producción. Esa puerta de calidad evitó dos despliegues malos durante el propio proyecto.

Para alertas montamos Grafana conectado a las métricas que Langfuse expone vía OpenTelemetry, con notificaciones a Slack para nivel alta e informativa y a PagerDuty para nivel crítica. El runbook quedó en su Confluence con enlaces directos a las queries de Langfuse correspondientes a cada alerta. La instrumentación de la aplicación se hizo con el SDK de Langfuse para Python, añadiendo decoradores en los puntos clave del pipeline y un middleware que capturaba metadatos de tenant y sesión. Toda la observabilidad de LLMs en producción quedó así dentro del perímetro del cliente.

¿Qué métricas concretas implementamos y qué encontramos?

Implementamos el set completo descrito en este artículo, pero adaptado al dominio legal. La calidad la evaluamos con un LLM-as-judge calibrado con un golden set de 350 ejemplos anotados por dos abogados senior del cliente, midiendo cuatro dimensiones: relevancia jurídica, exactitud de citas legales, ausencia de hallucinations factuales y adecuación de tono profesional. El acuerdo entre el juez automatizado y los humanos llegó al 0,71 de Cohen’s kappa tras tres iteraciones, suficiente para operar.

Los primeros 30 días de datos revelaron cosas que el cliente no sabía. Primero, el 12% de las interacciones tenían un coste tres o más veces superior al medio, y casi todas correspondían a un flujo concreto donde el sistema concatenaba documentos completos en el prompt en vez de chunks relevantes. Segundo, el hallucination rate medido era del 9%, casi el doble de lo que el cliente estimaba; y la mitad de esas hallucinations se concentraban en consultas sobre normativa autonómica reciente que no estaba indexada en el RAG. Tercero, la latencia P95 era el doble del SLO objetivo porque había una llamada síncrona innecesaria a un servicio externo que se podía paralelizar.

Las tres acciones que disparamos a partir de esos hallazgos redujeron el coste mensual un 34%, bajaron el hallucination rate al 4% en seis semanas y mejoraron la latencia P95 en un 45%. Ninguna de las tres habría sido posible sin la observabilidad de LLMs en producción correctamente desplegada. Antes del proyecto, el cliente estaba a punto de pedir más presupuesto a su CFO para sostener el crecimiento del coste; tras el proyecto, pudieron crecer el doble de tráfico sin aumentar el presupuesto de IA.

¿Qué lecciones nos llevamos para futuros proyectos?

La primera lección es que invertir en observabilidad de LLMs en producción antes de invertir en optimización es lo correcto en el 99% de casos. Los equipos suelen querer “mejorar el sistema” sin saber dónde están las pérdidas reales. Sin observabilidad, optimizar es disparar a ciegas: a veces aciertas, a veces gastas semanas trabajando en algo que no movía la aguja. Con una observabilidad de LLMs en producción bien hecha, las prioridades se autoeligen casi solas.

La segunda lección es que el LLM-as-judge calibrado contra humanos es la inversión de calidad con mejor ROI. El esfuerzo inicial de crear y anotar el golden set es real, pero a partir de ahí cada nueva métrica de calidad se obtiene casi gratis. Los clientes que se resisten a invertir en ese golden set acaban operando a ciegas en calidad, y eso es insostenible en sectores donde un error mal gestionado puede tener consecuencias graves.

La tercera lección es que la observabilidad cambia la cultura del equipo, no solo las métricas. Cuando un equipo empieza a ver datos cualitativos de su sistema en tiempo real, las conversaciones cambian. Las decisiones se toman con números, no con opiniones. Los debates se cierran con experimentos, no con autoridad. Esa transformación cultural es probablemente el mayor valor a largo plazo de un buen sistema de observabilidad de LLMs en producción, aunque sea más difícil de capturar en un business case.

¿Qué errores cometemos los equipos al implementar observabilidad de LLMs en producción?

Para cerrar la parte técnica antes de las preguntas frecuentes, queremos compartir los errores que hemos cometido nosotros mismos o que vemos repetidamente en proyectos de observabilidad de LLMs en producción que auditamos. No son errores de principiantes: son trampas en las que cae gente seria con experiencia. Identificarlos y nombrarlos es la forma más eficiente de evitarlos.

El primer error es instrumentar solo lo fácil. Es muy tentador empezar capturando llamadas al LLM y dejarlo ahí, porque es lo más visible. Pero un agente o un RAG fallan tan a menudo en la parte de tools, retrievers, parsers y orquestación como en el propio LLM. Si no se instrumenta el flujo completo, la observabilidad de LLMs en producción pinta un cuadro distorsionado donde el modelo parece responsable de problemas que están en otra parte.

El segundo error es medir sin actuar. Hemos visto proyectos con dashboards espectaculares donde nadie tomaba decisiones a partir de los datos. La observabilidad de LLMs en producción es un medio, no un fin en sí mismo. Si la organización no tiene la disciplina o la cultura para convertir métricas en acción, montar más métricas no soluciona nada y a veces empeora la situación porque genera la falsa sensación de control.

El tercer error es confundir herramientas comerciales con observabilidad real. Comprar Langfuse, Arize o LangSmith no es tener observabilidad de LLMs en producción: es tener una herramienta. La observabilidad emerge cuando hay instrumentación correcta, métricas pertinentes, dashboards usados, alertas accionadas, runbooks vivos y un equipo entrenado para usar todo eso. Sin esa práctica organizacional, la herramienta es solo software caro.

La observabilidad de LLMs en producción no se compra: se construye, se opera y se cuida cada semana.

El cuarto error es subestimar la deriva de proveedores y modelos. Los proveedores de modelos cambian comportamiento sin avisar, y la observabilidad de LLMs en producción es lo único que permite detectar esa deriva a tiempo. Una versión de GPT-4o de hace seis meses no se comporta exactamente igual que la actual. Una buena observabilidad de LLMs en producción debe versionar el modelo usado en cada generación y permitir comparar comportamiento histórico. Sin esa capacidad, cuando algo “se rompe sin tocar nada”, el equipo se vuelve loco buscando un cambio interno que no existe.

El quinto error, y quizá el más doloroso, es no involucrar a soporte y customer success en el diseño. Los equipos técnicos diseñamos observabilidad de LLMs en producción pensando en nosotros mismos, pero quien primero detecta problemas reales son los equipos que hablan con clientes. Si soporte no puede consultar las trazas de una interacción concreta, no puede ayudar al cliente y no puede pasar información útil al equipo técnico. Esta colaboración debe estar contemplada desde el inicio.

Preguntas frecuentes

¿Cuánto cuesta implementar observabilidad de LLMs en producción en un proyecto típico?

Depende mucho de la madurez de partida y del volumen de tráfico, pero podemos dar referencias realistas para un proyecto de observabilidad de LLMs en producción. Un proyecto greenfield donde solo hay que instrumentar una aplicación pequeña, montar Langfuse self-hosted y configurar dashboards básicos puede cerrarse entre 8.000 y 15.000 euros con un equipo externo, en dos a tres semanas de trabajo. Si el cliente lo hace internamente con un par de ingenieros con experiencia, baja a las semanas-persona equivalentes en coste interno.

Cuando se trata de un sistema en producción complejo con varios flujos, evaluaciones de calidad calibradas con humanos, integración con SLOs corporativos y formación al equipo, los proyectos de observabilidad de LLMs en producción suelen quedar entre 30.000 y 60.000 euros y duran entre dos y cuatro meses. El componente más caro suele ser la creación del golden set para la evaluación de calidad, porque requiere tiempo de expertos del dominio del cliente. La buena noticia es que la inversión casi siempre se amortiza en ahorro de coste de tokens y mejora de calidad en menos de un año.

¿Qué pasa si mi LLM corre on-premise o en un modelo open source autohospedado?

La observabilidad de LLMs en producción funciona igual o mejor en escenarios on-premise. De hecho, cuando el modelo es propio (vía vLLM, TGI, Ollama o similar) puedes capturar métricas adicionales como uso de GPU, throughput de tokens por segundo del propio servidor, latencia de batching y comportamiento bajo carga. Langfuse y Arize Phoenix soportan modelos arbitrarios sin problema porque la captura ocurre en la aplicación, no en el proveedor.

La gran ventaja operativa de tener el modelo on-premise junto con observabilidad de LLMs en producción también on-premise es la coherencia: ningún dato sale de tu infraestructura. Para sectores como salud, banca o defensa, esta combinación es lo que hace viable el proyecto entero. Lo único a vigilar es calcular el coste real por request, que ya no se basa en tarifas de proveedor sino en amortización de hardware y consumo eléctrico; las herramientas no lo calculan automáticamente y hay que configurarlo manualmente.

¿Cómo afecta el RGPD a la observabilidad de LLMs en producción?

El RGPD es la razón principal por la que recomendamos siempre soluciones self-hosted para la observabilidad de LLMs en producción cuando hay datos personales involucrados. Capturar prompts y respuestas significa, en muchos casos, almacenar datos personales y a veces categorías especiales de datos. Si esos prompts y respuestas se envían a un proveedor SaaS de observabilidad fuera del EEE, hay que justificar la transferencia internacional con garantías adecuadas, lo cual es posible pero suma fricción legal innecesaria.

Con Langfuse o Phoenix self-hosted en infraestructura del cliente (idealmente en una región europea de su cloud o en su propio datacenter) ese problema desaparece. Aun así, hay buenas prácticas adicionales: implementar políticas de retención (por ejemplo, 90 días para datos completos y agregados anónimos indefinidamente), permitir borrado a petición vinculado al usuario, y aplicar masking automático de PII en los logs cuando sea posible. La AEPD ha publicado guías específicas sobre IA y protección de datos que conviene revisar al diseñar el sistema.

¿Se puede observar a un agente complejo con muchas tools igual que a una llamada LLM simple?

Sí, pero la observabilidad de LLMs en producción aplicada a agentes requiere instrumentación más cuidadosa. Cada llamada a tool debe registrarse como un span anidado dentro de la traza del agente, capturando inputs, outputs, tiempo de ejecución y errores. Los frameworks modernos (LangGraph, OpenAI Swarm, CrewAI, AutoGen) tienen integraciones con Langfuse y Phoenix que generan esa estructura automáticamente, lo que reduce mucho el trabajo manual. Si usas un framework propio, hay que añadir los decoradores o spans a mano.

Lo que cambia con un agente es la importancia de medir el comportamiento a nivel de flujo completo, no solo a nivel de generación. Métricas específicas de agentes que recomendamos incluir son: número medio de pasos por interacción, tasa de éxito de cada tool, porcentaje de interacciones que entran en bucles detectados por heurísticas (mismas tools repetidas, mismas queries) y coste por interacción agente completada vs abandonada. Sin estas métricas integradas en la observabilidad de LLMs en producción, un agente puede degradar silenciosamente y solo se nota cuando la factura se dispara.

¿Es viable hacer evaluación de calidad continua sin que dispare el coste?

Sí, dentro de una observabilidad de LLMs en producción bien planteada el muestreo inteligente lo hace perfectamente viable. La práctica habitual es evaluar entre el 1% y el 10% del tráfico real, seleccionando muestras de forma representativa por feature, segmento de usuario y periodo del día. Para tráficos de cientos de miles de interacciones diarias, el coste de evaluación con un LLM-as-judge basado en un modelo potente queda en cientos de euros al mes, no en miles. La proporción se ajusta según el presupuesto y la criticidad del flujo.

Un truco adicional es encadenar dos modelos de evaluación: un modelo más barato para una primera pasada que descarte respuestas claramente correctas y reserve un modelo más caro solo para casos dudosos. Esto reduce el coste de evaluación entre un 60% y un 80% sin perder calidad. Y para algunos checks específicos (longitud, formato, presencia de información sensible), pueden usarse reglas deterministas que cuestan cero y resuelven gran parte del trabajo dentro de la observabilidad de LLMs en producción.

¿Cómo gestionar la observabilidad cuando hay varios modelos de proveedores distintos en producción?

Es una situación cada vez más común. Lo crítico es que la capa de observabilidad de LLMs en producción sea independiente del proveedor y unifique las métricas en un formato común. Langfuse y Phoenix lo hacen bien porque tratan cada proveedor como un origen de datos más y registran modelo, versión y proveedor en cada generación. Eso permite comparar comportamiento, coste y calidad entre proveedores con honestidad.

La práctica que recomendamos en multi-proveedor es dashboards comparativos por flujo. Por ejemplo, si un mismo flujo usa GPT-4o, Claude 3.5 Sonnet y Gemini 2.0 dependiendo del tipo de pregunta, queremos ver lado a lado latencia, coste y calidad de cada uno. Esa visibilidad permite tomar decisiones de routing dinámico basadas en evidencia: enviar cada tipo de query al modelo donde tiene mejor relación calidad-coste. La documentación de OpenTelemetry sobre semantic conventions para IA generativa es buen punto de partida para estandarizar la captura.

¿En cuánto tiempo se nota el impacto de un buen sistema de observabilidad de LLMs en producción?

El impacto técnico es prácticamente inmediato. Desde el primer día que la observabilidad de LLMs en producción está activa, el equipo gana visibilidad sobre métricas que antes no veía. Las primeras “sorpresas” (consultas anómalas, flujos caros, errores ignorados) suelen aparecer en las primeras dos semanas y dan pie a las primeras optimizaciones concretas. Es habitual que en el primer mes de observabilidad de LLMs en producción se identifiquen y resuelvan problemas que llevaban meses ocultos.

El impacto cultural y operativo lleva más tiempo, entre dos y seis meses. Es el periodo en el que el equipo aprende a usar la observabilidad de LLMs en producción como herramienta diaria, los procesos de incidencia se rediseñan alrededor de ella y las decisiones de roadmap empiezan a apoyarse en datos. Ese impacto cultural es el que multiplica el ROI del proyecto a largo plazo y el que más cuesta capturar en un business case formal, pero el que realmente diferencia a un equipo maduro de uno aficionado.

Ese es, en el fondo, el verdadero retorno de invertir en observabilidad de LLMs en producción: pasar de operar por intuición a operar por evidencia, y de discutir opiniones a comparar números. Es una transición lenta, pero una vez que ocurre, no hay marcha atrás.