
Rag'n'Roll
Green but Wrong
Warum ein Agent eine positive Statusmeldung liefern und trotzdem das Falsche tun kann, und wie man das im Trace erkennt
Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.
Heute auf der Setlist: Warum ein Agent eine positive Statusmeldung liefern und trotzdem das Falsche tun kann, und wie man das im Trace erkennt.
🎚️ Soundcheck
In Ausgabe #004 ging es darum, RAG-Qualität messbar zu machen. Bei agentischen Systemen kommt eine Schwierigkeit hinzu: Ein Agent, der in einer Schleife hängt, das falsche Tool aufruft oder vom ursprünglichen Ziel abweicht, liefert oft trotzdem eine positive Statusmeldung mit normaler Latenz und normalem Tokenverbrauch. Klassisches Monitoring sieht dann keinen Fehler, obwohl das Ergebnis eigentlich falsch ist. Der schwierige Teil ist deshalb nicht das reine Aufzeichnen der Aufrufs-Kette von Tools oder Sub-Agenten, sondern das Lesen: Wie sieht eine gesunde Kette aus, und welche konkreten Muster deuten auf ein Problem hin.
🎤 Main Set: Die Entscheidungskette lesen
Wie eine Kette aussieht
Ein Trace ist eine Aufzeichnung eines gesamten Laufs auf Session-Ebene, aufgeteilt in Spans, also einzelne Schritte. Es gibt im Wesentlichen drei Arten von Spans: LLM-Aufrufe mit Prompt, Antwort, Token-Anzahl und Latenz, Tool-Aufrufe mit Name, übergebenen Argumenten, Rückgabe oder Fehler und Ausführungszeit, sowie Zustandsübergänge mit Kontext-Updates und etwas „Zwischen“-Reasoning. Ein typischer Lauf reiht diese Spans hierarchisch aneinander: Der Agent plant, wählt ein Tool, ruft es mit Argumenten auf, verarbeitet die Rückgabe, entscheidet erneut, und so weiter bis zur Antwort.
Woran man ein Problem erkennt
Weil ein fehlerhafter Lauf strukturell unauffällig bleiben kann, braucht es die Auswertung der Spans selbst. Die wiederkehrenden Signaturen:
- Tool-Fehlnutzung: Es kann sein, dass es falsche oder fehlende Argumente (oder eine leere Antwort des Tools) trotz positiver Statusmeldung gibt, die der KI Agent nicht bemerkt. Ein kaputter beziehungsweise korrupter Output beim X’ten Schritt verfälscht alle folgenden Schritte: Das ist die am schwersten zu entdeckende Fehlerart.
- Retry-Schleifen: Dasselbe Tool wird mit identischen Argumenten wiederholt mit Fehlermeldung als Antwort aufgerufen, ohne dass sich der KI Agent darüber Gedanken macht, ob das gerade so Sinn macht (Stichwort: Strategie ändern), während sich Token und Latenz aufsummieren.
- Goal Drift: Hier schlagen einzelne Schritte per se nicht fehl, mit der Zeit ändert sich aber langsam & stetig das Ziel der orchestrierten KI Agenten. Eine Schlussbewertung des Endergebnisses übersieht das gegebenenfalls, eine detaillierte Bewertung der ganzen Trajektorie deckt es auf.
- Context Loss: In längeren Sitzungen verliert der Agent frühere Vorgaben, Erkenntnisse & Ergebnisse. Die Antworten wirken hier in sich grundsätzlich erstmal schlüssig, verletzen aber oft frühere Einschränkungen oder Entscheidungen.
- Stille Qualitätsverschlechterung: Die Qualität sinkt ohne offensichtliche Fehlercodes (zum Beispiel nach einem Modellwechsel) und bleibt bei reinem Monitoring auf „Fehler raten“- & Bauchgefühl-Basis unsichtbar.
Diese Muster sind wissenschaftlich systematisiert. Die MAST-Taxonomie unterscheidet 14 Fehlermodi in drei Kategorien, und Benchmarks wie TRAIL zeigen, dass selbst starke Modelle den entscheidenden fehlerhaften Schritt in langen Traces nur schwer lokalisieren können.
🥁 Track 2: Woran man KEIN Problem erkennt
- Ein legitimer Retry passt Strategie oder Parameter an, bleibt bei wenigen Versuchen und ruft das Tool mit veränderten Argumenten auf. Erst identische Argumente ohne Anpassung bis zum Timeout kennzeichnen die problematische Schleife.
- Normale Exploration probiert verschiedene Tools, hält dabei den Kontext und hält den Fortschritt in Richtung Ziel vor. Das unterscheidet sie von Goal Drift, bei dem der Zielbezug langsam verloren geht.
- Einzelmetriken bewegen sich aus harmlosen Gründen: Latenz steigt bei ausgelastetem Modell, Tokenkosten steigen mit wachsendem Kontext, die Fehlerrate steigt bei einem Anbieterausfall. Sowas ist daher nur im Verbund gut zu betrachten und entsprechend aussagekräftig.
- Eine einzelne Anfrage kann OK aussehen, während die Sitzung aber driftet. Die Bewertung gehört daher generell auf die Session-Ebene, nicht nur auf den einzelnen Request.
Daraus folgt die Betriebslogik: Aufzeichnung und Bewertung sind zwei Schichten. Der Trace zeichnet auf, eine getrennte Evaluationsschicht bewertet einzelne Spans und das Endergebnis gegen die ursprüngliche Absicht, oft mit einem Modell als Bewerter (LLM-as-a-Judge) über die volle Historie. Als Standard etabliert sich die OpenTelemetry-GenAI-Konvention, damit Instrumentierung und Auswertungswerkzeug unabhängig wählbar bleiben. Werkzeuge dafür sind unter anderem LangSmith, Arize Phoenix, Braintrust, Galileo und MLflow.
🎯 Encore: Der eine Gedanke für Entscheider
Strukturelles Tracing beantwortet erstmal nur die Frage, ob ein Lauf auch durchgelaufen ist, nicht aber die Frage, ob der Lauf zum richtigen Ziel gekommen ist. Für den Produktivbetrieb braucht es beides: die Aufzeichnung der Kette und eine Bewertung auf Session-Ebene gegen die ursprüngliche Absicht.
Die Frage für Entscheider lautet, ob das eigene Monitoring einen Agenten bemerken würde, der mit einer positiven Statusmeldung, normaler Latenz und normalem Tokenverbrauch trotzdem das Falsche tut, und ob sich im Fehlerfall der entscheidende (Fehl)Schritt erkennen lässt.
💿 B-Side
Anti-Pattern: Nur auf Request-Ebene und nur strukturell monitoren, also Statusmeldung, Latenz und Token. Semantische Fehler wie Goal Drift, stille Qualitätsverschlechterung oder ein korruptes Tool-Argument bleiben so unsichtbar. Sinnvoller ist eine Bewertung auf Session-Ebene, die die gesamte Trajektorie statt nur das Endergebnis prüft und Signale wie identische Retry-Argumente oder Leerantwort-Raten pro Tool erfasst.
Für die Tiefe lohnt ein Blick in die Fehler-Taxonomien, etwa MAST und den TRAIL-Benchmark, die Fehlerkategorien und Lokalisierung systematisch beschreiben.
Das war Rag'n'Roll #008. Die nächste Ausgabe befasst sich mit Agent-Memory und der Frage, warum Erinnerung eine eigene Architekturschicht ist und nicht bloß ein längerer Kontext.
Weiterleiten erwünscht🤘
Diese Ausgabe hat dir gefallen?
Dann hol dir die nächste direkt ins Postfach. Kostenlos, jede Woche.
