Observabilidad para apps con LLM: registrar lo que importa

Una aplicación tradicional o funciona o lanza un error, y cuando se rompe lees la traza de la pila. Una aplicación con LLM tiene un tercer estado mucho más común y mucho más difícil de depurar: funciona bien, no devuelve ningún error y produce una respuesta sutil o gravemente equivocada. No hay excepción que capturar. La observabilidad para apps con LLM es la práctica de capturar suficiente sobre cada interacción para que "dio una mala respuesta" se convierta en una pregunta que realmente puedas investigar. Este explicativo cubre qué registrar, por qué y cómo hacerlo sin ahogarse en datos.

Por qué la monitorización ordinaria no basta

La observabilidad clásica vigila errores, latencia y uso de recursos. Eso sigue importando, pero pasa por alto el modo de fallo único de los modelos de lenguaje: una llamada perfectamente exitosa que devuelve el contenido equivocado. El estado HTTP está bien, la latencia es normal, no hay nada ardiendo, y la salida es alucinada, fuera de instrucción o insegura.

Para depurar eso, necesitas ver dentro de la interacción. ¿Qué prompt exacto fue al modelo, incluidas las partes ensambladas en tiempo de ejecución? ¿Qué devolvió el modelo? ¿Qué contexto se recuperó e inyectó? ¿Qué versión del prompt estaba activa? Nada de esto es visible desde las métricas de infraestructura. La observabilidad de LLM existe para hacer inspeccionable a posteriori el contenido de cada interacción, porque en el momento en que algo sale mal, la única evidencia duradera es lo que registraste.

El registro central: captura la interacción completa

La base es un registro de cada interacción con el modelo lo bastante completo para reconstruir qué pasó. Como mínimo, eso significa:

• El prompt resuelto completo. No la plantilla, sino el texto real enviado, con todas las variables, el contexto recuperado y el historial de conversación rellenados. El error está muy a menudo en lo que se ensambló, no en la plantilla que escribiste.
• La respuesta completa. Exactamente lo que devolvió el modelo, antes de que tu posprocesamiento la reformule o trunque.
• El modelo y los parámetros. Qué modelo, y los ajustes que moldean el comportamiento como la temperatura. El mismo prompt se comporta de forma distinta según estos.
• La versión del prompt. Qué versión de tu prompt estaba activa, para que una regresión pueda atarse a un cambio concreto.

Con estos cuatro, la mayoría de las investigaciones de "por qué hizo eso" se vuelven abordables. Sin ellos, estás adivinando. La disciplina es registrar el estado resuelto, porque la brecha entre la plantilla que pretendías y el prompt que realmente enviaste es donde vive una porción sorprendente de los errores.

Traza toda la cadena, no solo la llamada al modelo

Las apps modernas con LLM rara vez son una sola llamada. Una petición podría recuperar documentos, llamar al modelo, invocar una herramienta y luego llamar al modelo de nuevo. Cuando la respuesta final es errónea, la causa podría estar en cualquier paso: mala recuperación, un resultado de herramienta malformado o el modelo mismo.

Por eso el trazado importa tanto como el registro. Una traza ata cada paso del manejo de una petición en una única línea de tiempo enlazada, para que puedas seguir la petición desde la entrada hasta la salida y ver dónde se desvió. ¿Se recuperó el documento equivocado? Entonces el modelo razonó correctamente sobre un mal contexto, y el arreglo está en la recuperación, no en el prompt. ¿La recuperación tuvo éxito pero el modelo ignoró el contexto? Un arreglo totalmente distinto. Sin una traza de extremo a extremo, los sistemas de varios pasos son casi imposibles de depurar, porque no puedes saber qué eslabón de la cadena falló.

Métricas que vale la pena vigilar a lo largo del tiempo

Más allá de los registros por interacción, un puñado de señales agregadas te dice si el sistema está sano en producción.

• Latencia, incluido el tiempo hasta el primer token. Para experiencias en streaming, cuánto tarda en empezar la salida es a menudo lo que el usuario realmente siente, distinto del tiempo total de finalización.
• Uso de tokens. Los tokens consumidos por petición se mapean directamente al coste y crecen a medida que los prompts y el contexto se agrandan. Vigilarlos detecta temprano una deriva costosa.
• Tasas de error y de rechazo. Tanto los fallos duros como el patrón más suave de que el modelo declina o se evade. Una tasa de rechazo creciente suele señalar un problema de prompt o de política que vale la pena investigar.
• Rendimiento y volumen. Tráfico de referencia para que las anomalías destaquen frente a él.

Estas no te dicen si las respuestas son buenas, solo si el sistema se comporta con normalidad. Son la capa de alerta temprana: cuando una métrica se mueve, vas a los registros por interacción para averiguar por qué. Rastréalas como tendencias, no como puntos únicos, ya que un número solo es significativo frente a su propio historial.

Juzgar la calidad, no solo la actividad

Lo más difícil de observar es si las salidas son realmente buenas, porque normalmente no hay una única respuesta correcta con la que comparar. Unos cuantos enfoques prácticos hacen la calidad al menos parcialmente visible.

Captura las señales del usuario cuando existan: pulgares arriba y abajo explícitos, o señales implícitas como que un usuario reintente, abandone o edite la salida. Son ruidosas pero reales, y te apuntan hacia las interacciones que vale la pena examinar. Mantén un conjunto curado de entradas representativas y ejecuta las nuevas versiones de prompt o de modelo contra él antes del despliegue, para comparar la calidad deliberadamente en lugar de descubrir una regresión en producción. Y muestrea interacciones reales para revisión humana con una cadencia regular; una lectura pequeña y rutinaria de salidas reales detecta la deriva que ninguna métrica saca a la luz. El objetivo no es automatizar el juicio por completo, sino dejar de volar a ciegas.

Registrar de forma responsable

Capturar prompts y respuestas completos significa capturar lo que sea que los usuarios escribieron, lo que puede incluir información personal o sensible. La observabilidad no puede convertirse en un problema silencioso de retención de datos.

Incorpora la privacidad desde el principio. Sabe qué se está almacenando, redacta o evita almacenar campos sensibles donde puedas, fija límites de retención para que los registros no se acumulen para siempre y controla quién puede leerlos. Hay una tensión genuina aquí: cuanto más ricos sean tus registros, mejor tu depuración y mayor tu exposición si esos registros se filtran. Resuélvela deliberadamente y no por accidente. La documentación de los proveedores de OpenAI y Anthropic describe su propio manejo de datos, que es parte del cuadro, pero lo que tú almacenas es tu responsabilidad gobernar.

Empieza pequeño y crece

No necesitas una plataforma de observabilidad completa el primer día, y fingir lo contrario es una buena forma de no empezar nunca. Empieza registrando el registro central —prompt resuelto, respuesta, modelo y versión del prompt— para cada interacción. Ese único paso hace posible la mayor parte de la depuración temprana. Añade trazado cuando tu sistema crezca más allá de una sola llamada. Añade métricas agregadas cuando tengas suficiente tráfico para que las tendencias signifiquen algo. Añade evaluación de calidad cuando estés ajustando prompts y modelos en serio. Cada capa se gana su lugar; constrúyelas en el orden en que tu aplicación realmente crece, no todas a la vez.

En resumen

Las apps con LLM fallan de una forma que la monitorización tradicional no puede ver —una llamada exitosa que devuelve una respuesta errónea—, así que la observabilidad tiene que mirar dentro de cada interacción, no solo a la infraestructura que la rodea. Registra el prompt y la respuesta resueltos completos con el modelo y la versión del prompt, traza de extremo a extremo las peticiones de varios pasos, vigila la latencia y el uso de tokens como tendencias, y encuentra una forma de muestrear la calidad en lugar de darla por sentada. Hazlo con la privacidad diseñada desde el principio, y haz crecer las capas a medida que crece tu sistema. La recompensa es que "dio una mala respuesta" deja de ser un encogimiento de hombros y se convierte en una pregunta que puedes responder.