🤖 AI

TraceGraph: Shared Decision Landscapes for Diagnosing and Improving Agent Trajectories

TraceGraph führt ein graphbasiertes Framework ein, das Trajektorien von Multi-Modell-Agenten in gemeinsame Entscheidungslandschaften transformiert, um verborgene Navigationsunterschiede und Fehlermuster aufzudecken, was wiederum eine fallenfähige Wiederherstellungspipeline ermöglicht, die die Lösungsraten auf dem SWE-bench signifikant verbessert.

Ursprüngliche Autoren: Junjie Nian, Kang Chen, Ge Zhang, Yixin Cao, Yugang Jiang

Veröffentlicht 2026-06-01

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Junjie Nian, Kang Chen, Ge Zhang, Yixin Cao, Yugang Jiang

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

Stellen Sie sich vor, Sie beobachten eine Gruppe von fünf verschiedenen Entdeckern, die versuchen, ein komplexes Labyrinth zu lösen. Früher, wenn man wissen wollte, wer der beste Entdecker war, schaute man einfach auf die Endpunktzahl: „Hat er den Ausgang erreicht? Ja oder Nein?“

Das Papier TraceGraph argumentiert, dass diese „Ja oder Nein“-Bewertung zu viel verbirgt. Es ist so, als würde man einen Koch nur danach beurteilen, ob der Kuchen gegessen wurde, ohne zu bemerken, dass einer der Köche die Küche niedergebrannt hat, um dorthin zu gelangen, während ein anderer einen malerischen Weg durch den Garten nahm.

So funktioniert TraceGraph, einfach erklärt:

1. Die gemeinsame Karte (Die Entscheidungslandschaft)

Anstatt den Pfad jedes Entdeckers isoliert zu betrachten, führt TraceGraph alle ihre Schritte auf einer einzigen, riesigen, gemeinsamen Karte zusammen.

Die Schritte: Jedes Mal, wenn ein KI-Agent (der Entdecker) eine Aktion ausführt (wie „eine Datei lesen“ oder „einen Test ausführen“) und ein Ergebnis sieht, hinterlässt er einen „Fußabdruck“.
Das Clustering: TraceGraph analysiert diese Fußabdrücke. Wenn zwei Schritte sehr ähnlich aussehen (z. B. beide versuchen, einen spezifischen Fehler in derselben Datei zu beheben), zieht das System eine Linie, um sie zu verbinden.
Das Ergebnis: Dies erzeugt ein Netz oder eine „Landschaft“ der Aufgabe. Einige Bereiche sind sicher und führen zum Erfolg; andere sind Sackgassen.

2. Die drei Schlüsselereignisse

Sobald die Karte erstellt ist, beobachtet TraceGraph, wie sich die KI über diese Karte bewegt. Es kümmert sich noch nicht um die Endpunktzahl; es achtet auf drei spezifische Momente:

Zugang (Access): Hat die KI den „produktiven Kern“ gefunden? (Den sicheren, wertvollen Bereich, in dem gute Arbeit geleistet wird).
Fallenexposition (Trap Exposure): Ist die KI in eine „Falle“ geraten? (Einen verwirrenden Bereich, in dem viele andere gescheitert sind oder steckengeblieben sind).
Reparatur (Repair): Wenn die KI in eine Falle geraten ist, hat sie es geschafft, wieder herauszuklettern und zum produktiven Kern zurückzukehren?

3. Was die Karte enthüllte

Als die Forscher diese gemeinsame Karte betrachteten, fanden sie Dinge, die einfache Punktzahlen übersehen haben:

Unterschiedliche Stile: Einige Modelle (wie DeepSeek-V3.2) waren mutige Entdecker. Sie fanden oft den produktiven Kern, gerieten manchmal in Fallen, waren aber sehr gut darin, wieder herauszuklettern (Reparatur). Andere (wie Qwen3-Next) waren sehr vorsichtig. Sie gerieten selten in Fallen, fanden aber auch selten den produktiven Kern, weil sie zu viel Angst hatten zu explorieren.
Unterschiedliche Regeln für unterschiedliche Labyrinthe: Die Forscher testeten dies auf fünf verschiedenen Arten von Aufgaben (wie das Beheben von Softwarefehlern, die Websuche oder die Nutzung von Werkzeugen). Sie fanden heraus, dass einige Labyrinthe das Vermeiden von Fallen belohnen (mach keinen Fehler!), während andere (wie das Beheben von Softwarefehlern) das Regenerieren von Fehlern belohnen. Ein Modell, das gut darin ist, Fallen zu vermeiden, kann tatsächlich bei einer Aufgabe scheitern, bei der man in der Lage sein muss, sich von einem Fehler zu erholen.

4. Das „Fallen-Detektor“-Experiment

Der spannendste Teil ist, wie sie diese Karte genutzt haben, um der KI in Echtzeit zu helfen.

Die Idee: Da sie genau wussten, wie eine „Falle“ auf der Karte aussah (ein spezifisches Muster von Aktionen und Fehlern), bauten sie einen Detektor.
Der Auslöser: Wenn eine KI bei der Lösung eines neuen Problems in ein Muster trat, das einer bekannten „Falle“ entsprach, löste der Detektor Alarm aus.
Die Rettung: Als der Alarm losging, ließ das System die KI nicht einfach weiter scheitern. Es hielt inne und versuchte zwei einfache Korrekturen:
1. Der „Hot“-Fix: Es sagte der KI, sie solle es mit etwas mehr Zufälligkeit versuchen (wie das Schütteln der Würfel), um zu sehen, ob ein anderer Pfad funktioniert.
2. Der „Notiz“-Fix: Es gab der KI eine sanfte Erinnerung in Form einer Notiz basierend auf dem Fehler: „Hey, du scheinst hier festzusitzen. Lies die Fehlermeldung erneut, konzentriere dich auf diese spezifische Datei und versuche eine kleine Änderung.“

Das Ergebnis: Bei einer Software-Reparatur-Aufgabe (SWE-bench) half die Verwendung dieses Fallen-Detektors der KI, etwa 3 bis 4 % mehr Probleme zu lösen, als sie es allein gekonnt hätte. Es bewies, dass das Wissen darüber, wo die Fallen liegen, es ermöglicht, ein Sicherheitsnetz zu bauen, das die KI auffängt, bevor sie scheitert.

Zusammenfassung

TraceGraph ist ein Werkzeug, das uns lehrt, nicht nur auf die Endpunktzahl einer KI zu schauen. Stattdessen baut es eine gemeinsame Karte davon auf, wie sich KI-Agenten durch Aufgaben bewegen. Es zeigt uns:

Welche Modelle mutige Entdecker vs. vorsichtige Wanderer sind.
Welche Aufgaben das Vermeiden von Fehlern vs. das Regenerieren von ihnen erfordern.
Wie man ein einfaches „Sicherheitsnetz“ baut, das erkennt, wenn eine KI kurz davor ist, in eine bekannte Falle zu fallen, und ihr eine zweite Chance gibt, dies zu korrigieren.

Es verwandelt die Black Box des „KI-Fehlers“ in eine klare Geschichte: „Die KI ist in eine Falle getappt, aber mit ein wenig Hilfe hätte sie herausklettern können.“

Technisches Resümee: TraceGraph – Gemeinsame Entscheidungslandschaften zur Diagnose und Verbesserung von Agenten-Trajektorien

1. Problemstellung

Aktuelle Agenten-Benchmarks erfassen zunehmend reichhaltige, verschachtelte Interaktions-Trajektorien (Gedanken, Tool-Aufrufe, Feedback aus der Umgebung). Die gängige Evaluierungspraxis kollabiert diese komplexen Prozesse jedoch typischerweise in einen einzelnen Skalarwert (z. B. Pass/Fail-Rate oder Reward-Score). Während solche Scores Systeme zwar ranken, verschleiern sie die zugrunde liegende Prozessdynamik: Sie offenbaren nicht, wie Modelle durch Aufgabenräume navigieren, wo sie in ihren Strategien divergieren oder ob sie Fehlerregionen vermeiden oder aus ihnen zurückkehren.

Die Kernherausforderung ist das Fehlen eines gemeinsamen Koordinatensystems zum Vergleich von Trajektorien über verschiedene Modelle hinweg. Agentenzustände sind lang, verzweigt und benchmarkspezifisch; sie mischen Tool-Wahlen, Datei-Hinweise und partielle Evidenzen. Ohne eine solche Ausrichtung ist es schwierig zu bestimmen, ob Modell A einen analogen Zustand wie Modell B erreicht hat, eine identische Fehlerregion vermieden hat oder über einen anderen Weg regeneriert ist. Bestehende Methoden untersuchen oft einzelne Trajektorien isoliert oder verlassen sich auf aggregierte Scores, die die Prozessdiversität verbergen.

2. Methodik: Das TraceGraph-Framework

TraceGraph ist ein graphbasierter Rahmen, der gepoolte Agenten-Rollouts in eine gemeinsame Entscheidungslandschaft transformiert. Er operiert in drei Stufen und konstruiert eine modellagnostische Karte des Aufgabenraums, bevor er spezifische Modellverhaltensweisen analysiert.

Stufe 1: Aufbau der gemeinsamen Landschaft

Das Framework verarbeitet Aktions-Beobachtungs-Schritte aus mehreren Modellen und Aufgaben.

Kodierung: Jeder Schritt $i$ wird als eine spärliche Menge beobachtbarer Schlüssel $K_i$ kodiert, einschließlich Tool-/Aktions-Typen, Kommandoklassen, Beobachtungsmustern (z. B. Error-Traces), Datei-Hinweisen und temporalen Phasen. Für Suchaufgaben werden spezifische Schlüssel für URL-Domains und Query-Neuheit hinzugefügt.
Ähnlichkeit & Graphkonstruktion: Die paarweise Ähnlichkeit wird mittels einer IDF-gewichteten Jaccard-Überlappung über die Schlüsselmengen berechnet. Seltene, informative Schlüssel (z. B. spezifische Traceback-Muster) werden stärker gewichtet als generische Schlüssel.
Topologie: Ein mutual- $k$ $k$ NN-Graph wird über alle gepoolten Schritte erstellt. Dieser Graph wird in bikonnektive Komponenten (BCCs) und Artikulationspunkte (Gates) zerlegt.
- BCCs gruppieren Schritte mit dichter gegenseitiger Ähnlichkeit und repräsentieren grobe gemeinsame Agentenzustände.
- Artikulationspunkte markieren Strategie- oder Phasenübergänge, an denen eine Rollout in qualitativ unterschiedliche Fortsetzungen verzweigen kann.
Modellagnostik: Die Modellidentität wird bei der Signatur- und Graphkonstruktion ausgeschlossen. Die Landschaft wird ausschließlich durch den beobachtbaren Zustandsraum definiert.

Stufe 2: Ergebnisorientierte Overlays

Sobald die Graphstruktur fixiert ist, legt das Framework Ergebnisdaten darüber, um „produktive Kerne“ und „Trap-Regionen“ (Fallen-Regionen) zu identifizieren.

Reward-Diffusion: Für jeden BCC-Block wird ein Laplace-geglätteter Reward basierend auf den terminalen Ergebnissen der Rollouts zugewiesen, die diesen Block besuchen. Dieser Reward wird dann über den Block-Quotienten-Graphen diffundiert, um lokales Rauschen zu glätten.
Regionsdefinition:
- Produktiver Kern ( $C_t$ ): Hochpositive Quantile des diffundierten Reward-Feldes.
- Trap-Regionen ( $B_t$ ): Niedrig-negative Quantile des diffundierten Reward-Feldes.
Diese Overlays sind deskriptiv; sie lokalisieren, wo sich hoher- und niedriger Outcome-Verkehr konzentriert, anstatt Ergebnisse für ungesehene Durchläufe vorherzusagen.

Stufe 3: Zusammenfassung von Rollout-Ereignissen

Jede Modell-Trajektorie wird durch drei diskrete Ereignisse zusammengefasst, die auf den Kern-/Trap-Overlays definiert sind:

Zugriff ( $A_r$ ): Hat der Rollout den produktiven Kern geschnitten?
Trap-Exposition ( $E_r$ ): Hat der Rollout eine Trap-Region geschnitten?
Reparatur ( $R_r$ ): Hat der Rollout eine Trap besucht und anschließend einen Kern erreicht?

Analyse: Angebot- und Nachfrageprofile

TraceGraph generiert zwei deskriptive Profile:

Modell-Angebot (Model Supply): Der aufgabenzentrierte Mittelwert der Ereignisse eines Modells im Vergleich zum Durchschnittsmodell. Dies offenbart einen „Navigationsstil“ (z. B. High-Access/High-Repair vs. konservativ/flach).
Benchmark-Nachfrage (Benchmark Demand): Der reward-gewichtete Kontrast zwischen High-Outcome- und Low-Outcome-Verkehr. Dies zeigt, was ein spezifischer Benchmark belohnt (z. B. Trap-Vermeidung vs. Reparatur).

3. Kernbeiträge

TraceGraph-Framework: Eine Methode zur Konstruktion modellagnostischer Aufgaben-Graphen aus gepoolten Rollouts und zur Überlagerung von ergebnisorientierten Regionen zur Schaffung einer gemeinsamen Entscheidungslandschaft.
Kompakte Prozessprofile: Ein Nachweis, dass über fünf Benchmark-Splits (7.329 Datensätze, 427 Aufgaben, 5 Modelle) hinweg die Ereignisse von Zugriff, Trap-Exposition und Reparatur Modell-Navigationsstile und Benchmark-Anforderungen trennen, die aggregierte Scores kollabieren lassen.
TraceGraph-gesteuerte Reparatur-Pipeline: Eine praktische Anwendung auf SWE-bench, bei der aus dem Graphen abgeleitete Trap-Regionen als Laufzeit-Trigger dienen. Wenn ein Live-Agent eine historische Trap-Region betritt, wird eine leichtgewichtige Reparatur-Policy aktiviert.

4. Experimentelle Ergebnisse

Diagnostische Erkenntnisse

Modell-Diversität: Aggregierte Scores verbergen oft Prozessunterschiede. Beispielsweise zeigt DeepSeek-V3.2 auf einer gemeinsamen Landschaft einen „High-Access, High-Repair“-Stil, während Qwen3-Next einen „Low-Access, Low-Repair“-Stil aufweist (konservative, flache Navigation).
Benchmark-Heterogenität: Benchmarks stellen unterschiedliche Prozessanforderungen:
- $\tau^2$ -bench, MCPBench, TerminalBench: Stark trap-avers (hohe Outcomes korrelieren mit der Vermeidung von Low-Outcome-Regionen).
- SWE-bench: Stark reparatur-demanding (hohe Outcomes korrelieren mit der Reparatur von Trap-ähnlichen Zuständen nach anfänglichem Scheitern).
- Search: Belohnt den Zugriff auf produktive Evidenz mit gelegentlicher Reparatur.

Reparatur-Experiment (SWE-bench)

Die Autoren implementierten eine trap-bewusste Prefix-Fork-Pipeline auf SWE-bench Verified Instanzen (insgesamt 500).

Mechanismus: Ein Detektor wird ausgelöst, wenn ein Live-Rollout eine kanonische Trap-Signatur erfüllt. Beim Auslösen setzt der Agent die Ausführung unter drei Policies fort:
1. Baseline: Standardmäßige Fortsetzung ( $T=0.6$ ).
2. Hot: Erhöhte Sampling-Diversität ( $T=0.9$ ).
3. Note: Eine konservative, evidenzbasierte Diagnose-Notiz, die dem Kontext hinzugefügt wird (ohne Gold-Patches).
Ergebnisse:
- Auf dem pro-Provider-getriggerten Subset ( $n=616$ ) steigerte die beste gepoolte Policy (Hot) die Lösungsrate von 40,4 % auf 43,5 % (+3,1 pp, $p=0.016$ ).
- Auf dem gemeinsam-getriggerten Subset ( $n=288$ ) steigerte die Hot-Policy die Rate von 41,0 % auf 44,8 % (+3,8 pp, $p=0.045$ ).
- Provider-Spezifität: Die aktive Reparatur-Komponente variierte je nach Provider. Qwen3.6-35B-A3B profitierte am meisten von der Diagnose-Notiz, während GLM-5.1 und DeepSeek-V4-Pro am meisten vom Temperatur-Bump profitierten.

5. Bedeutung und Ansprüche

Das Paper positioniert TraceGraph nicht als neuen Skalar-Score oder blinden Erfolgsprognostiker, sondern als Prozess-Vokabular für die Agenten-Evaluierung.

Deskriptive Kraft: Es offenbart, was ein Benchmark testet (z. B. Vermeidung vs. Reparatur) und wo sich Modelle auf einer gemeinsamen Landschaft unterscheiden.
Handlungsorientierte Anleitung: Es demonstriert, dass aus Graphen abgeleitete Traps gezielte Interventionen leiten können. Durch die Identifizierung historischer Fehlerregionen ermöglicht das Framework gezielte Reparatur-Policies, die die Lösungsraten verbessern, ohne Oracle-Informationen oder vollständiges Re-Training zu erfordern.
Bescheidenheit: Die Autoren betonen, dass die Reparatur-Pipeline eine lokale Intervention für einen spezifischen Teil von SWE-bench ist und nicht als universeller Agenten-Reparatur-Mechanismus beansprucht wird. Das Framework ist ein analytisches Instrument zur Erklärung von Verkehrskonzentrationen, kein Controller für alle Agentenverhaltensweisen.

Zusammenfassend verschiebt TraceGraph den Fokus von der Frage „Wie viele Aufgaben hat der Agent gelöst?“ hin zu „Wie hat der Agent durch die Aufgabenlandschaft navigiert und wo ist er steckengeblieben oder erfolgreich zurückgekehrt?“, und bietet so eine strukturelle Basis für das Verständnis und die Verbesserung von Agenten-Trajektorien.