observabilidad sistemas agentes. observabilidad sistemas agentes.
observabilidad sistemas agentes.
observabilidad sistemas agentes.
Observabilidad en sistemas de agentes
1. Por qué la observabilidad es diferente para agentes
Los fallos de los agentes son fundamentalmente distintos de los fallos del software tradicional. Un agente es no determinista, no acotado y puede usar herramientas para afectar arbitrariamente a otros sistemas. Una misma instrucción puede producir caminos de ejecución completamente diferentes en cada invocación. Esto hace que las pruebas tradicionales y las evaluaciones offline sean insuficientes.
Amy Boyd y Nitya (Microsoft Foundry) plantean la metáfora del «mind the gap» (cuidado con el hueco) londinense: hay una brecha entre lo que esperamos que haga un agente y lo que realmente hace. Esa brecha solo puede entenderse mediante observabilidad en producción, no mediante pruebas de laboratorio.
La observabilidad en agentes no es un lujo: es una necesidad de seguridad. Un agente que toma decisiones autónomas puede ejecutar acciones costosas, acceder a datos sensibles o tomar atajos peligrosos sin que el desarrollador lo sepa. La única forma de detectarlo es monitorizando cada paso de su ejecución.
2. Señales explícitas e implícitas
La observabilidad efectiva se apoya en dos categorías de señales. Las señales explícitas son métricas objetivas y verificables: tasa de error, latencia, coste por tarea, tasa de regeneración. Son fáciles de medir y comparar, pero no capturan la calidad semántica del trabajo del agente.
Las señales implícitas son semánticas y más difíciles de detectar: patrones de regex, clasificadores binarios y autodiagnósticos. Las señales implícitas más efectivas no son valoraciones genéricas tipo «LLM-as-a-judge», sino clasificadores binarios específicos: rechazos, fallo de tarea, frustración del usuario, jailbreaking, brechas de capacidad.
La clave está en rastrear la tasa de estos problemas específicos a lo largo del tiempo. Un incremento en la tasa de frustración del usuario tras un cambio en el prompt es mucho más accionable que una puntuación genérica de calidad que no dice dónde está el problema.
3. Autodiagnósticos: la técnica de alto impacto
Una de las técnicas más potentes y sencillas para la observabilidad de agentes son los autodiagnósticos (self-diagnostics). Consiste en añadir una herramienta «report» al conjunto de herramientas del agente e indicarle en el prompt del sistema que informe de incidencias a sus creadores.
Esta técnica puede detectar: brechas de capacidad (el agente sabe que no puede hacer algo), fallos de herramientas (una API devuelve un error inesperado), y atajos no deseados (un agente que evita una herramienta de escritura rota usando bash directamente).
El problema del «modelo pulido»: los modelos están entrenados para ser educados y se resisten a autoinculparse. Para que funcione, la herramienta debe presentarse de forma neutra («report» o «feedback al creador») en lugar de negativa («comportamiento inseguro»). El prompt debe animar a informar de «cualquier cosa destacable», no solo de «fallos».
4. Experimentos A/B en producción
Una vez establecidas las señales de observabilidad, habilitan un potente flujo de trabajo de experimentación A/B en producción. Al enviar un cambio (un nuevo prompt, un modelo diferente, una herramienta nueva) a un porcentaje de usuarios y comparar las tasas de señal (como frustración del usuario o tasa de regeneración) contra un grupo de control, los equipos pueden validar cambios rápidamente.
Este enfoque es más potente que las evaluaciones offline porque mide el comportamiento real de los usuarios, no el comportamiento esperado en un conjunto de datos curado. Permite detectar regresiones sutiles que las evaluaciones predefinidas no capturarían.
La tasa de regeneración es una métrica especialmente reveladora: con qué frecuencia el usuario o el propio agente solicita regenerar una respuesta. Una tasa alta indica problemas de calidad no capturados por otras métricas. Combinada con la tasa de abandono (el usuario cierra la sesión tras una interacción fallida), ofrece una imagen clara de la salud del agente.
5. La paradoja del «último problema de la humanidad»
La observabilidad de agentes se enmarca como un desafío crítico y creciente. A medida que los agentes se vuelven más complejos, ejecutan tareas más largas y se despliegan en dominios de alto riesgo (salud, finanzas, defensa), la capacidad de los humanos para monitorizarlos manualmente se vuelve imposible.
La paradoja: cuanto más autónomo y capaz es un agente, menos podemos entender lo que hace simplemente observando sus salidas. Necesitamos sistemas de observabilidad automatizados que puedan rastrear, analizar y alertar sobre el comportamiento del agente sin intervención humana.
El camino a seguir incluye: trazado detallado de cada paso del agente (tool calls, decisiones intermedias, tiempos), dashboards en tiempo real con señales explícitas e implícitas, alertas automáticas cuando las métricas se desvían de lo esperado, y capacidad de reproducción de sesiones para depuración forense. La observabilidad no es un añadido: es la base sobre la que se construyen agentes fiables.
Fuentes
- Amy Boyd & Nitya, Microsoft Foundry — «Mind the Gap (In your Agent Observability)» (AI Engineer). Duración: 1:20:07. URL: https://youtu.be/iOXM3zE-2dk
- Danny Gollapalli & Zubin Koticha, Raindrop — «Everything You Need To Know About Agent Observability» (YouTube). Duración: 50 min. URL: https://www.youtube.com/watch?v=-aM2EDTiaMs
Atribución: Este artículo adapta material de las charlas de Amy Boyd y Nitya (Microsoft Foundry) y de Danny Gollapalli y Zubin Koticha (Raindrop) en el canal AI Engineer.
Artículos relacionados
Recursos en línea
Ver también: PARTE 3: La Habana 1762: cuando la logística falló | Viento en las velas: cómo la Royal Navy venció al escorbuto. Fuente: Observabilidad en sistemas de agentes.
Deja una respuesta