Observabilidad de LLM: por qué el APM clásico no ve cuando el modelo miente
El APM clásico se queda ciego cuando el fallo es una respuesta perfecta pero falsa. La observabilidad de LLM añade evaluación de calidad, coste por token y trazado de la decisión.
Cuando un microservicio se rompe, algo salta: una excepción, un código que no es 2xx, una métrica que se dispara. Cuando se rompe un sistema construido sobre un LLM, muchas veces no salta nada. La respuesta llega con una redacción impecable y es falsa. El contexto recuperado no venía a cuento. El coste por petición se ha doblado sin que nadie lo mirara. Y el dashboard sigue en verde, porque el APM mide latencia, tasa de error y throughput, no si lo que sale del modelo tiene sentido. Ese punto ciego es el que ocupa a la observabilidad de LLM, que en 2026 ya se trata como disciplina propia y no como un añadido al monitoring de siempre.
Los tres pilares, extendidos
Las trazas dejan de ser la cadena de llamadas entre servicios y pasan a registrar el camino completo de decisión: prompt, recuperación, preparación de contexto, generación y post-proceso. En arquitecturas multiagente esto es lo único que permite saber qué agente de la cadena produjo la salida intermedia errónea.
Las métricas suman consumo de tokens, coste por petición y puntuaciones de calidad: fidelidad al contexto, relevancia y tasa de alucinación. Los logs ya no guardan eventos del sistema, sino pares prompt-respuesta completos, el contexto recuperado, la versión del modelo y el feedback del usuario.
La calidad no se puede medir con umbrales fijos, y ahí está la diferencia de fondo. Hace falta un segundo modelo o un cross-encoder que evalúe la salida del primero, el patrón conocido como LLM-as-judge. En producción no hace falta evaluar el 100%: con muestrear entre el 10% y el 20% del tráfico basta para detectar tendencias, y la alerta salta cuando empeora la muestra, no cuando falla una petición suelta.
El coste es la parte que más se descuida. Los tokens escalan con la longitud del prompt, la ventana de contexto y el volumen, así que un equipo descubre con frecuencia que una función en producción cuesta entre 5 y 10 veces lo presupuestado, simplemente porque nadie medía tokens por sesión y por modelo. Lo mínimo es poder desglosar ese gasto con consultas SQL.
Herramientas y un estándar que aún se mueve
El catálogo se ha diferenciado bastante. Langfuse cubre trazado, evaluación y gestión de prompts, es open source con licencia MIT y se puede desplegar en infraestructura propia con Docker Compose o Kubernetes; las instrucciones están en la guía de self-hosting de Langfuse. Arize Phoenix va por Elastic License 2.0 y OpenObserve, con AGPL-3.0, es la única propuesta que junta trazado de LLM y monitorización clásica de infraestructura en una sola instancia autoalojada. Confident AI, Datadog LLM Observability y LangSmith solo se ofrecen como servicio en la nube; el detalle de cada una está en esta comparativa.
Por debajo empuja OpenTelemetry con sus convenciones semánticas GenAI: atributos bajo el espacio de nombres gen_ai.* para llamadas al modelo, invocaciones de herramientas, embeddings y pasos de agente. Una vez instrumentado, las trazas se exportan a cualquier backend compatible con OTLP y se evita el encierro en un proveedor. Dos matices: las convenciones siguen en estado Development y los atributos pueden cambiar, y OTel solo recoge telemetría, no evalúa ni interviene. De ese hueco sale una categoría nueva, el plano de control de agentes, que aplica políticas como la detección de PII al margen del framework de ejecución.
La barrera de entrada es baja: montar Langfuse o OpenObserve son minutos. Lo que no es barato es enterarse por los usuarios de que el modelo lleva tres semanas degradándose.
