Atomare Aufgabengraphen: Die Planung der Arbeit von Agenten als Abhängigkeitsgraph
Wie das Atomic Task Graph-Framework Agentenaufgaben in typisierte Knoten zerlegt, Pläne simuliert und nur fehlerhafte Untergraphen repariert, um kleinen offenen Modellen zum Wettbewerb zu verhelfen.
Quellen: This New AI Framework Turned 7B Models Into GPT-4 Competitors (Without Any Training)
Die meisten Versuche, LLM-Agenten zuverlässiger zu machen, beginnen mit einem größeren Modell. Das Atomic Task Graph (ATG)-Framework, das von Forschern der Tsinghua-Universität und der South China University of Technology vorgeschlagen wurde, geht einen anderen Weg: Es verändert die Art und Weise, wie der Agent seine Arbeit strukturiert. Laut dem Paper übertrafen 7B- und 8B-Open-Source-Modelle, die mit ATG umhüllt waren, GPT-4, das einen standardmäßigen ReAct-Zyklus auf zwei bekannten Agenten-Benchmarks ausführte – ohne jegliche Feinabstimmung, Verstärkungsunterricht oder Gewichtsanpassungen. Im Folgenden wird erklärt, warum lineare Schlussfolgerungsketten versagen, wie ATG sie durch ein Abhängigkeitsgraphen ersetzt und welche Ideen man für eigene Agenten übernehmen kann.
Warum lineare Agentenzyklen bei langen Aufgaben scheitern
Betrachten wir eine Anfrage wie „Erstellen Sie einen Verkaufsbericht für 2024 mit Diagrammen.“ Ein typischer ReAct-ähnlicher Agent behandelt dies als eine lange Abfolge von Schritten, wobei jeder Schritt vom vorherigen abhängt.
Step 1
↓
Find database
↓
Query data
↓
Analyze numbers
↓
Create graphs
↓
Write report
Die Kette funktioniert, solange jeder Schritt erfolgreich ist. Probleme entstehen, wenn einer der Schritte fehlschlägt. Wenn die Datenbankabfrage fehlschlägt, basieren alle nachfolgenden Schritte auf fehlenden oder falschen Daten.
Database query
↓
Everything after it becomes wrong
In diesem Fall kann der Agent entweder von vorne beginnen oder mit dem vorhandenen Wissen weitermachen. Viele wählen die zweite Option, was eine Hauptursache für Halluzinationen ist: Das Modell erfindet plausibel klingende Daten, um die Lücken zu füllen, und jede nachfolgende Entscheidung übernimmt diesen Fehler.
Der Kontext wächst ständig
Das zweite Problem ist, wie diese Agenten ihren Zustand speichern. Nach jeder Aktion werden der Gedanke, der Toolaufruf sowie die Beobachtung dem ständig wachsenden Protokoll hinzugefügt.
User
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
Im Laufe der Zeit bewertet das Modell Seiten voller Historie. Der Kontext wird unübersichtlich, und frühe Fehler bleiben sichtbar, wodurch sie weiterhin spätere Entscheidungen beeinflussen. Wie beim Telefonspiel verfälscht jede Runde den Plan leicht, bis er von der Realität abweicht.
Die Kernidee: Ein Graph statt einer Kette
ATG ersetzt die einfache Abfolge durch einen Graphen von Aufgaben. Jeder Knoten repräsentiert eine Arbeitseinheit, und jede Kante dokumentiert eine Abhängigkeit zwischen zwei Einheiten.
Report
/ \
Analysis Charts
/ \
Database Statistics
Durch diese Struktur wird die Unabhängigkeit sichtbar: Nicht verbundene Arbeiten warten nicht länger, und ein Fehler in einem Teilbereich macht die anderen nicht ungültig.
Wie ATG den Graphen erstellt und ausführt
Das Framework arbeitet in fünf Phasen.
1. Rekursive Aufteilung in atomare Aufgaben
Alles beginnt mit der Anfrage des Benutzers.
Create sales report
ATG teilt dieses Ziel in Unteraufgaben auf.
Create sales report
↓
Load data
↓
Analyze sales
↓
Create charts
↓
Write summary
Dann wird jede noch zu umfassende Unteraufgabe weiter aufgeteilt, wie beispielsweise der Analyseschritt.
Analyze sales
↓
Revenue
↓
Profit
↓
Growth
↓
Regional trends
Die Dekomposition endet, wenn jede Blattnode auf eine einzige Toolaufrufung verweist, zum Beispiel:
SQL query
Python calculation
Matplotlib chart
Markdown writer
Diese Blattnode sind die atomaren Aufgaben: Einheiten, die so klein sind, dass eine weitere Aufteilung keinen Sinn macht. Die Beendigungsregel ist wichtig: Ein vager Node lässt dem Modell zu viel Freiraum für Improvisation, während ein SQL-Abfrage ein klares, überprüfbares Ergebnis liefert.
2. Explizite Eingaben und Ausgaben für jeden Node
Jedem Node wird eine Schnittstelle zugewiesen, ähnlich wie einer Funktionssignatur. Anstatt einer Anweisung wie „Führe die Analyse durch“ beschreibt der Planer, was der Node verbraucht und was er erzeugt.
def analyze_sales(data):
return summary
Der Auszug dient nur zur Veranschaulichung und ist kein Framework-Code, zeigt aber den Vertrag an. Da das Graph nur von diesem Vertrag abhängt, kann ein Knoten erneut versucht werden oder durch ein anderes Tool ersetzt werden, ohne dass seine Nachbarn es bemerken – genau diese Eigenschaft macht modularen Code wartbar.
3. Parallelisierte Ausführung unabhängiger Äste
Ein sequenzieller Agent führt Aufgaben nacheinander aus, selbst wenn einige davon unabhängig voneinander sind.
Task A
↓
Task B
↓
Task C
Falls B und C nur das Ergebnis von A benötigen und nicht das voneinander, kann ATG dies direkt ausdrücken.
Task A
/ \
Task B Task C
\ /
Task D
Dann können B und C gleichzeitig ausgeführt werden, wobei D auf beide wartet. Die Studie weist in allen bewerteten Benchmarks deutlich kürzere Ausführungspfade auf, was natürlich aus der Umwandlung unabhängiger Schritte in parallele resultiert.
4. Ein Probelauf, bevor echte Tools verwendet werden
Vor der Ausführung von etwas simuliert ATG intern den gesamten Plan und fragt im Grunde das Modell, ob der Plan funktionieren würde, wenn er genau so umgesetzt würde wie beschrieben. Bei der Simulation werden folgende Aspekte überprüft:
- Fehlende Schritte
- Falsches Werkzeug, das einem Knoten zugeordnet ist
- Falsche Abhängigkeiten zwischen Knoten
- Unstimmigkeiten bei den Schnittstellen, bei denen die Ausgabe eines Knotens nicht zur Eingabe des nächsten Knotens passt
- Ausführungspfade, die tatsächlich nicht abgeschlossen werden können
- Verstöße gegen die Einschränkungen der Aufgabe
Es handelt sich dabei um das Äquivalent zu Tests vor dem Bereitstellen, und es ist kostengünstig, da keine externen Tools aufgerufen werden. Die Überprüfung ist jedoch nur so gut wie das Modell, das sie durchführt: Das Modell, das den Plan erstellt hat, kann seine Blindstellen aufweisen, daher sollte es als Filter und nicht als Garantie angesehen werden.
5. Gezielte Reparatur des fehlerhaften Teilgraphen
Der auffälligste Aspekt ist die Art und Weise, wie ATG Fehlern zur Laufzeit begegnet. Nehmen wir ein einfaches Diagramm:
Database
↓
Analysis
↓
Charts
↓
Report
Nehmen wir an, der Analyseknoten versagt. Ein herkömmlicher Agent reagiert in der Regel damit, seinen Fortschritt zu verwerfen und von vorn anzufangen.
Database
↓
Analysis
↓
Charts
↓
Report
↓
Start over
ATG hingegen behält das gleiche Diagramm bei und friert jeden Knoten ein, der bereits ein gültiges Ergebnis erzeugt hat. Das untenstehende Diagramm sieht absichtlich identisch aus wie das ursprüngliche: Die Struktur ändert sich nicht, nur der Analyseknoten wird zur Überarbeitung markiert, während die Knoten für Datenbank, Diagramm und Bericht unverändert bleiben.
Database
↓
Analysis
↓
Charts
↓
Report
Nur der fehlerhafte Untergraph wird neu generiert, und sobald dieser erfolgreich ist, setzt das Diagramm mit dem neuen Ergebnis fort.
Database
↓
New Analysis
↓
Charts
↓
Report
Es handelt sich um eine schrittweise Kompilierung, die auf der Planung angewandt wird. Beachten Sie, dass, falls die reparierte Analyse unterschiedliche Werte liefert, die nachgelagerten Knoten, die diese verwenden, dennoch neu ausgeführt werden müssen; eingespart wird lediglich die Arbeit in den vorangegangenen Schritten sowie unverwandte Zweige.
Warum kleinere Kontexte zu weniger Halluzinationen führen
In einem ReAct-Loop sieht jeder Schritt die gesamte Historie. Bei ATG erhält jeder Knoten nur die Eingaben, die seine Schnittstelle definiert, wodurch es weniger Störungen gibt und weniger Raum für frühere Fehler besteht.
Die Studie quantifiziert dies anhand von ALFWorld:
- mithilfe von ReAct enthielten 42,86% der Trajektorien halluzinierte Aktionen
- mithilfe von ATG sank dieser Wert auf 12,14%
Das entspricht einer relativen Reduzierung von etwa 72 Prozent, ohne dass das zugrunde liegende Modell geändert werden musste.
Was die Benchmarks zeigen
Bei der Bewertung wurden drei offene Modelle verwendet:
- Mistral 7B
- Gemma 7B
- Llama 3 8B
und drei Agenten-Benchmarks:
- ALFWorld
- WebShop
- ScienceWorld
Der Hauptvergleich setzt Llama 3 8B mit ATG gegen GPT-4 mit ReAct. In ALFWorld erzielte die GPT-4-Baseline folgende Ergebnisse:
GPT-4 + ReAct
41.24
während das kleine Modell mit ATG folgende Ergebnisse erzielte:
Llama 3 8B + ATG
63.65
In WebShop erreichte die GPT-4-Baseline folgende Ergebnisse:
GPT-4 + ReAct
64.34
und Llama 3 8B mit ATG erreichte folgende Ergebnisse:
Llama 3 8B + ATG
68.36
Das sind die im Paper angegebenen Zahlen. Die Werte für GPT-4 beziehen sich auf eine ReAct-Baseline, sodass der Vergleich zeigt, wie sehr Struktur die Modellgröße ausgleichen kann – nicht, dass ein 8B-Modell im Allgemeinen stärker ist als GPT-4.
Warum diese Idee bei Softwareentwicklern Anklang findet
Die übliche Strategie der Branche bestand darin, Modelle, Clustern und Budgets zu skalieren. ATG fragt stattdessen, wie die Arbeit besser organisiert werden kann – was eher eine Frage der Softwareentwicklung als der maschinellen Lernung ist. Dies erinnert an Git, Abhängigkeitsgraphen, Build-Systeme, Aufgabenscheduler, Compileroptimierung und verteilte Systeme. Die meisten Softwarelösungen sind schon seit langer Zeit nicht mehr streng sequenziell; Agenten holen auf.
Ein konkretes Beispiel: Die Erstellung einer Website
Fragt man einen Agenten, eine Website zu erstellen, neigt ein linearer Agent dazu, einen Plan wie diesen zu erstellen:
Think
↓
Write HTML
↓
Write CSS
↓
Write JavaScript
↓
Debug
↓
Deploy
Ein nach dem ATG-Prinzip arbeitender Planer würde hingegen einen Baum aus unabhängigen Komponenten erstellen:
Website
│
├── HTML
├── CSS
├── Images
├── API
└── Tests
Jede Abteilung kann separat entwickelt werden. Wenn die CSS-Datei fehlerhaft ist, wird nur der entsprechende CSS-Node neu generiert. Das klingt offensichtlich, doch die meisten Agenten arbeiten heutzutage nicht auf diese Weise. Verwandte defensive Muster werden in einer Architektur gegen die Verstärkung von Halluzinationen in Agent-Graphen behandelt.
Wann ein Task-Graph nicht sinnvoll ist
Planung, Simulation sowie das Verwalten von Knoten verursachen zusätzlichen Aufwand. Für Aufgaben, die aus zwei oder drei Tool-Aufrufen bestehen, ist ein einfacher ReAct-Loop einfacher. Ein Graph lohnt sich dann, wenn die Aufgaben langwierig sind, teilweise unabhängig voneinander agieren und teuer zum Neustarten sind – und nur dann, wenn der Planer sinnvoll aufteilt: Ein effizient ausgeführter schlechter Graph bleibt weiterhin ein schlechter Plan.
Kernpunkte
- Lineare Schleifen können dazu führen, dass ein fehlerhafter Schritt alles danach beeinträchtigt, und wachsende Transkripte verstärken frühe Fehler.