Observabilidad de LLM
La observabilidad de LLM es la práctica de instrumentar las aplicaciones de LLM en producción para que los equipos puedan ver qué hace el modelo, depurar fallos, medir el costo y la latencia, detectar la deriva de calidad y evaluar las salidas a lo largo del tiempo. Es el equivalente, en la era de los LLM, a la observabilidad tradicional de aplicaciones (registros, trazas y métricas), adaptada a sistemas probabilísticos en los que la misma entrada puede producir salidas distintas.
La observabilidad de LLM es la práctica de instrumentar las aplicaciones de LLM en producción para que los equipos puedan ver qué hace el modelo, depurar fallos, medir el costo y la latencia, detectar la deriva de calidad y evaluar las salidas a lo largo del tiempo. Es el equivalente, en la era de los LLM, a la observabilidad tradicional de aplicaciones (registros, trazas y métricas), adaptada a sistemas probabilísticos en los que la misma entrada puede producir salidas distintas.
Por qué importa
Una aplicación web tradicional o funciona o lanza un error. Una aplicación de LLM puede "funcionar" (devolver una respuesta bien formateada) mientras que la respuesta es errónea, está fuera de tema, alucinada, sesgada o simplemente peor que ayer. Sin observabilidad, esos fallos permanecen invisibles hasta que los usuarios se quejan, momento en el que la confianza ya está dañada. Entre 2024 y 2025, la observabilidad de LLM se convirtió en una categoría diferenciada, con herramientas como Langfuse, LangSmith, Helicone, Arize Phoenix, Weights & Biases Weave y Braintrust, cada una ocupando su parcela. Para cualquier equipo que ejecute LLM en producción, la observabilidad es ahora un requisito básico, no algo deseable.
Qué instrumentar
Trazas: La ruta de ejecución completa: cada prompt, llamada de recuperación, invocación de herramienta y respuesta en una sola solicitud. Te permite reproducir lo que el agente hizo realmente.
Pares de entrada/salida: El prompt exacto enviado y la finalización exacta recibida, con versiones según la plantilla del prompt.
Costo por solicitud: Recuento de tokens × precio para la entrada y la salida, por modelo. Agregado por funcionalidad, usuario o inquilino.
Latencia: Tiempo hasta el primer token, tiempo total de finalización y tiempo dedicado a cada subpaso.
Errores y reintentos: Errores de limitación de frecuencia, tiempos de espera agotados, fallos en las llamadas a herramientas y errores de análisis.
Señales de calidad: Pulgares arriba/abajo del usuario, señales implícitas (salida copiada, código ejecutado, mensaje enviado) y puntuaciones del LLM como juez sobre las salidas recientes.
Deriva: Cambios a lo largo del tiempo en la distribución de las salidas, la calidad de las respuestas o la tasa de llamadas a herramientas, a menudo la primera señal de que una actualización del modelo o un cambio de prompt rompió algo.
Por qué se diferencia de la observabilidad tradicional
Las salidas no son deterministas: La misma entrada, una salida distinta. Las métricas tienen que tratar la varianza como un concepto de primer nivel.
Los costos son por token, no por solicitud: La supervisión de rendimiento de aplicaciones (APM) tradicional no sabe qué son los tokens. La observabilidad de LLM sí debe saberlo.
La calidad es subjetiva: No puedes afirmar "salida correcta" con una prueba sencilla. La evaluación necesita revisión humana, jueces LLM o comparaciones con datos de referencia.
Los prompts son código: Un cambio de prompt es un despliegue. Sin versionado de prompts, no puedes saber qué versión produjo el error de ayer.
Las cadenas de varios pasos importan: La mayoría de las aplicaciones de LLM son canalizaciones. Necesitas trazas anidadas que reflejen el grafo de llamadas, no registros planos.
El panorama de herramientas (2026)
Langfuse (código abierto): Observabilidad centrada en las trazas, con evaluación, gestión de prompts y comentarios de los usuarios. Popular entre los equipos que se autoalojan.
LangSmith (LangChain): Estrechamente integrada con LangChain. Sólida para equipos que ya están en ese conjunto de tecnologías.
Helicone: Observabilidad ligera basada en proxy. Integración de una línea, fácil de adoptar.
Arize Phoenix / Arize AX: Procede del mundo de la observabilidad de ML; sólida en deriva, incrustaciones y ciencia de la evaluación.
Braintrust: Plataforma centrada en la evaluación, útil para equipos que quieren tratar el desarrollo de LLM como un flujo de trabajo de experimentación.
Weave (Weights & Biases): Extiende el seguimiento de experimentos de ML de WandB al territorio de los LLM.
Supervisión de LLM de Datadog / New Relic: Proveedores de APM clásicos que añaden paneles específicos para LLM.
Convenciones semánticas de GenAI de OpenTelemetry: Un estándar entre proveedores para el trazado de LLM, que gana adopción entre 2025 y 2026.
Qué vigilar
Costo por sesión de usuario: Los picos repentinos a menudo significan un error (bucle de reintentos, agente descontrolado) antes que crecimiento.
Latencia p95/p99: Las colas largas arruinan la experiencia de usuario. El peor caso importa más que la media.
Deriva de la puntuación de evaluación: Una puntuación semanal del LLM como juez sobre prompts representativos detecta las regresiones silenciosas tras los cambios de prompt o de modelo.
Principales modos de fallo: Clasifica los errores (rechazado, alucinado, fuera de tema, con formato erróneo) para saber dónde invertir.
Rendimiento por versión de prompt: Compara las puntuaciones de evaluación entre versiones de prompt para saber si el último cambio ayudó o perjudicó.
Distribución de tokens: Las respuestas largas elevan el costo. Las colas inesperadamente largas suelen indicar deriva del prompt o tokens de parada averiados.
Errores comunes
Registrar solo los errores: Los LLM fallan en silencio. Registra también los éxitos, con suficientes metadatos para evaluar la calidad.
No tener estrategia de muestreo: Registrar el 100 % de las solicitudes a gran escala es costoso. Muestrea de forma inteligente por segmento de usuario, nivel de costo o cambio reciente.
No conectar las trazas con los comentarios del usuario: Un pulgar abajo necesita enlazar de vuelta con la traza exacta que produjo la salida.
Aislamiento por equipos: Producto, ML e infraestructura construyen cada uno sus propios paneles. La observabilidad unificada es la victoria.
Ignorar las pruebas de regresión: "Parece bien" no es suficiente. Construye un conjunto de evaluación de regresión y ejecútalo antes de cada cambio de prompt.
Perseguir la dependencia de un proveedor: Las convenciones de GenAI de OpenTelemetry te permiten instrumentar una vez e intercambiar proveedores de observabilidad más adelante.
Sources: