When Agentic Executions Fail: Detecting and Localizing Runtime Faults from Telemetry
Este artículo presenta AGENTCHAOSBENCH, un conjunto de datos de referencia de 275 trazas de ejecución agénticas con fallos de tiempo de ejecución inyectados, para demostrar que los métodos actuales basados en LLM tienen dificultades para detectar y localizar con precisión diversos fallos operativos basándose únicamente en la telemetría.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
El software moderno ya no es solo un programa único ejecutándose en una computadora; a menudo es un equipo de agentes de inteligencia artificial trabajando juntos. Imagine una fuerza laboral digital donde un agente planifica un viaje, otro reserva los vuelos y un tercero consulta el clima, todos comunicándose entre sí y utilizando herramientas externas como mapas o calendarios. Estos sistemas dependen de una compleja red de conexiones: los agentes se hablan entre sí, piden consejo a un modelo de lenguaje extenso, recurren a herramientas externas para realizar un trabajo y siguen reglas estrictas de seguridad para asegurar que no digan o hagan algo dañino. Cuando todo funciona, el equipo produce una respuesta correcta. Pero cuando algo sale mal, la respuesta final puede ser errónea, o el sistema simplemente puede dejar de funcionar, dejando al usuario sin ninguna pista de por qué. El problema es que mirar únicamente el resultado final no nos dice nada sobre la avería. ¿Falló el sistema porque la IA tomó una mala decisión, o porque una herramienta que necesitaba fue lenta, o porque una regla de seguridad se saltó accidentalmente? Para arreglar estos sistemas, los ingenieros necesitan ver todo el trayecto, no solo el destino.
Un equipo de investigadores de la Universidad de Toronto ha construido un nuevo campo de pruebas para ayudar a resolver este misterio. Crearon un banco de pruebas llamado AgentChaosBench, que es esencialmente un entorno controlado para romper estos equipos de IA a propósito para ver si las herramientas de diagnóstico pueden encontrar el problema. Los investigadores tomaron cinco aplicaciones del mundo real diferentes —sistemas que escriben código SQL, redactan libros, gestionan redes sociales, crean páginas de aterrizaje y asisten en la contratación— y simularon diez formas diferentes en las que podrían fallar. Estos fallos incluyeron herramientas que se negaron a responder, herramientas que tardaron demasiado en responder, mensajes que se perdieron entre agentes y reglas de seguridad que fueron eludidas. Para cada escenario fallido, también ejecutaron una versión perfecta y libre de fallos de la misma tarea utilizando exactamente las mismas instrucciones iniciales. Este emparejamiento les permitió saber exactamente qué salió mal y dónde, creando un conjunto de 275 registros detallados de estos trayectos digitales.
El núcleo de su trabajo fue observar si un sistema automatizado podía analizar el registro de una ejecución fallida e identificar correctamente la causa. Eliminaron cualquier etiqueta que pudiera revelar la respuesta, dejando solo los datos brutos de lo sucedido: el tiempo de las llamadas, el contenido de los mensajes y el estado de cada paso. Luego, pidieron a varios modelos de inteligencia artificial, que iban desde modelos locales más pequeños hasta los modelos de frontera más potentes disponibles, que actuaran como detectives. Estos modelos tenían que leer el registro, determinar qué tipo de fallo de los diez había ocurrido y señalar exactamente qué parte del sistema era la responsable. Los investigadores también probaron si dar al detective una copia de la ejecución perfecta y libre de fallos para comparar ayudaría.
Los resultados mostraron que esta tarea es mucho más difícil de lo que cualquiera podría haber esperado. Incluso los modelos más avanzados, que pueden escribir poesía y resolver complejos acertijos lógicos, tuvieron dificultades significativas para diagnosticar estos fallos de tiempo de ejecución. Cuando se les pidió identificar el tipo de fallo a partir de un solo registro, el mejor modelo obtuvo la respuesta correcta en menos del 25 por ciento de las veces. Para los modelos más pequeños, la tasa de éxito fue aún menor, situándose entre el 13 y el 19 por ciento, lo que apenas supera el azar. El problema fue aún más difícil cuando los modelos tenían que señalar el componente específico que falló. Lograron localizar la parte correcta del sistema solo un 31 por ciento de las veces. Cuando se les pidió hacer ambas cosas a la vez —nombrar el fallo y encontrar la ubicación—, la tasa de éxito cayó a solo un 22 por ciento para el mejor modelo.
El estudio reveló que algunos fallos son más fáciles de detectar que otros. Los errores que producen señales obvias, como una herramienta que devuelve un mensaje de error claro o una conexión que agota el tiempo de espera, fueron identificados con mayor frecuencia. Sin embargo, los fallos más peligrosos y sutiles permanecieron casi invisibles. Cuando se eludió una regla de seguridad, permitiendo que una solicitud que debería haber sido bloqueada procediera, los modelos casi siempre fallaron en detectarlo. Del mismo modo, cuando la respuesta de una herramienta estaba corrupta o cuando el sistema se quedó sin espacio de memoria, los modelos no pudieron distinguir estos problemas de un comportamiento normal de manera fiable. Los investigadores encontraron que proporcionar una ejecución de referencia perfecta para comparar ayudaba en algunos casos, como identificar cuándo una herramienta era inusualmente lenta o cuándo el sistema intentaba usar demasiada memoria. Sin embargo, esta comparación no ayudó con las elusiones de seguridad o los datos corruptos, porque la salida defectuosa todavía parecía plausible y la verificación de seguridad todavía parecía haber pasado.
Este trabajo demuestra que, si bien hemos construido sistemas sofisticados para coordinar múltiples agentes de IA, aún no hemos construido las herramientas para comprender de forma fiable por qué fallan. La generación actual de modelos de diagnóstico, incluso los más grandes y capaces, no puede todavía distinguir consistentemente entre una herramienta rota, una red lenta, un salto de una regla de seguridad y una operación normal. Los investigadores concluyen que arreglar estos sistemas requerirá nuevos métodos que vayan más allá de simplemente pedirle a un modelo de lenguaje extenso que lea un registro. Sugieren que las soluciones futuras pueden tener que basarse en comparar las ejecuciones actuales contra aquellas que son conocidas como buenas o en desarrollar herramientas especializadas diseñadas específicamente para buscar estos fallos operativos, en lugar de depender únicamente de la inteligencia de propósito general. El camino a seguir consiste en construir mejores formas de ver las grietas invisibles en la maquinaria digital antes de que causen el colapso de todo el sistema.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.