When Agentic Executions Fail: Detecting and Localizing Runtime Faults from Telemetry
Dieses Paper führt AGENTCHAOSBENCH ein, einen Benchmark-Datensatz aus 275 agentischen Ausführungstraces mit injizierten Laufzeitfehlern, um zu demonstrieren, dass aktuelle LLM-basierte Methoden Schwierigkeiten haben, vielfältige betriebliche Ausfälle allein anhand von Telemetrie präzise zu erkennen und zu lokalisieren.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Moderne Software ist nicht mehr nur ein einzelnes Programm, das auf einem Computer läuft; sie besteht oft aus einem Team von künstlichen Intelligenz-Agenten, die zusammenarbeiten. Stellen Sie sich eine digitale Belegschaft vor, bei der ein Agent eine Reise plant, ein anderer die Flüge bucht und ein dritter das Wetter prüft, wobei alle miteinander kommunizieren und externe Werkzeuge wie Karten oder Kalender nutzen. Diese Systeme verlassen sich auf ein komplexes Geflecht von Verbindungen: Die Agenten sprechen miteinander, sie fragen ein großes Sprachmodell um Rat, sie rufen externe Werkzeuge auf, um Arbeit zu verrichten, und sie befolgen strikte Sicherheitsregeln, um sicherzustellen, dass sie nichts Schädliches sagen oder tun. Wenn alles funktioniert, liefert das Team eine korrekte Antwort. Aber wenn etwas schiefgeht, kann das Endergebnis falsch sein, oder das System stellt einfach die Arbeit ein, ohne dem Nutzer einen Hinweis darauf zu geben, warum. Das Problem ist, dass die Betrachtung allein des Endergebnisses uns nichts über den Zusammenbruch verrät. Lag es daran, dass die KI eine schlechte Entscheidung getroffen hat, oder weil ein benötigtes Werkzeug langsam war, oder weil eine Sicherheitsprüfung versehentlich übersprungen wurde? Um diese Systeme zu reparieren, müssen Ingenieure die gesamte Reise sehen, nicht nur das Ziel.
Ein Forscherteam der University of Toronto hat einen neuen Testplatz geschaffen, um dieses Rätsel zu lösen. Sie haben einen Benchmark namens AgentChaosBench entwickelt, der im Wesentlichen eine kontrollierte Umgebung ist, um diese KI-Teams absichtlich kaputt zu machen, um zu sehen, ob Diagnosewerkzeuge das Problem finden können. Die Forscher nahmen fünf verschiedene reale Anwendungen – Systeme, die SQL-Code schreiben, Bücher entwerfen, soziale Medien verwalten, Landing Pages erstellen und beim Recruiting helfen – und simulierten zehn verschiedene Arten, wie sie scheitern könnten. Diese Fehler beinhalteten Werkzeuge, die sich weigerten zu antworten, Werkzeuge, die zu lange für eine Antwort brauchten, Nachrichten, die zwischen Agenten verloren gingen, und Sicherheitsregeln, die umgangen wurden. Für jedes fehlerhafte Szenario ließen sie auch eine perfekte, fehlerfreie Version derselben Aufgabe mit exakt denselben Ausgangsanweisungen laufen. Dieses Paar ermöglichte es ihnen, genau zu wissen, was schiefgelaufen ist und wo. So entstand ein Satz von 275 detaillierten Aufzeichnungen dieser digitalen Reisen.
Der Kern ihrer Arbeit bestand darin, zu prüfen, ob ein automatisiertes System den Datensatz einer fehlgeschlagenen Ausführung betrachten und die Ursache korrekt identifizieren kann. Sie entfernten alle Kennzeichnungen, die die Antwort verraten könnten, und ließen nur die Rohdaten dessen zurück, was passiert ist: die Zeitpunkte der Aufrufe, den Inhalt der Nachrichten und den Status jedes Schritts. Dann baten sie verschiedene Modelle der künstlichen Intelligenz, die von kleineren lokalen Modellen bis hin zu den leistungsfähigsten verfügbaren Frontier-Modellen reichten, als Detektive zu agieren. Diese Modelle mussten den Datensatz lesen, herausfinden, welcher der zehn Fehlertypen aufgetreten war, und genau bestimmen, welcher Teil des Systems dafür verantwortlich war. Die Forscher testeten auch, ob es dem Detektiv helfen würde, eine Kopie des perfekten, fehlerfreien Durchlaufs zum Vergleich zur Verfügung gestellt zu bekommen.
Die Ergebnisse zeigten, dass diese Aufgabe weitaut schwieriger ist, als man es vermuten könnte. Selbst die fortschrittlichsten Modelle, die Gedichte schreiben und komplexe Logikrätsel lösen können, hatten erhebliche Schwierigkeiten, diese Laufzeitfehler zu diagnostizieren. Wenn sie gebeten wurden, die Art des Fehlers aus einem einzelnen Datensatz zu identifizieren, lieferte das beste Modell in weniger als 25 Prozent der Fälle die richtige Antwort. Bei kleineren Modellen lag die Erfolgsquote noch niedriger, etwa bei 13 bis 19 Prozent, was kaum besser als Raten ist. Das Problem war noch schwieriger, wenn die Modelle die spezifische Komponente benennen mussten, die versagte. Es gelang ihnen nur in etwa 31 Prozent der Fälle, den korrekten Teil des Systems zu lokalisieren. Wenn sie beides gleichzeitig tun sollten – den Fehlertyp benennen und den Ort finden –, sank die Erfolgsquote für das beste Modell auf nur 22 Prozent.
Die Studie zeigte, dass einige Fehler leichter zu entdecken sind als andere. Fehler, die offensichtliche Signale erzeugen, wie ein Werkzeug, das eine klare Fehlermeldung zurückgibt, oder eine Verbindung, die zeitüberschreitend abbricht, wurden häufiger identifiziert. Die gefährlichsten und subtilsten Fehler blieben jedoch fast unsichtbar. Wenn eine Sicherheitsregel umgangen wurde, sodass eine Anfrage, die blockiert werden sollte, dennoch fortgesetzt wurde, bemerkten die Modelle dies fast immer nicht. Ähnlich verhielt es sich, wenn eine Antwort eines Werkzeugs korrumpiert war oder das System seinen Speicherplatz aufgebraucht hatte; die Modelle konnten diese Probleme nicht zuverlässig von normalem Verhalten unterscheiden. Die Forscher fanden heraus, dass die Bereitstellung eines perfekten Referenzdurchlaufs zum Vergleich in einigen Fällen half, wie etwa beim Identifizieren, wenn ein Werkzeug ungewöhnlich langsam war oder das System zu viel Speicher beanspruchte. Dieser Vergleich half jedoch nicht bei den Sicherheitsumgehungen oder korrumpierten Daten, da die fehlerhafte Ausgabe immer noch plausibel aussah und die Sicherheitsprüfung scheinbar erfolgreich verlaufen war.
Diese Arbeit zeigt, dass wir zwar anspruchsvolle Systeme zur Koordination mehrerer KI-Agenten gebaut haben, aber noch nicht die Werkzeuge gebaut haben, um zuverlässig zu verstehen, warum sie scheitern. Die aktuelle Generation von Diagnosemodellen, selbst die größten und fähigsten, kann noch nicht konsistent zwischen einem defekten Werkzeug, einem langsamen Netzwerk, einer übersprungenen Sicherheitsprüfung und einem normalen Betrieb unterscheiden. Die Forscher kommen zu dem Schluss, dass die Behebung dieser Systeme neue Methoden erfordert, die über das bloße Fragen eines großen Sprachmodells zum Lesen eines Protokolls hinausgehen. Sie schlagen vor, dass zukünftige Lösungen möglicherweise auf dem Vergleich aktueller Ausführungen mit bekannten guten Durchläufen basieren oder auf spezialisierten Werkzeugen beruhen sollten, die gezielt nach diesen operativen Fehlern suchen, anstatt sich allein auf allgemeine Intelligenz zu verlassen. Der Weg nach vorn besteht darin, bessere Wege zu finden, um die unsichtbaren Risse in der digitalen Maschinerie zu erkennen, bevor sie das gesamte System zum Einsturz bringen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.