AutoGen: Multi-Agent-Konversations-Frameworks für Finanz-KI

Nachdem Gorilla gezeigt hat, dass ein einzelnes LLM lernen kann, Tausende von APIs präzise aufzurufen, stellt sich die natürliche Frage: Was passiert, wenn man mehreren LLMs unterschiedliche Rollen gibt und sie miteinander sprechen lässt? AutoGen (Wu et al., 2023) beantwortet diese Frage durch den Aufbau eines Frameworks für Multi-Agent-Konversationen, und das Lesen fühlt sich heute zeitgemäß an – die meisten produktiven Finanz-KI-Systeme, deren Design ich sehe, beinhalten standardmäßig mindestens drei Agenten.

Das Paper

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Wu, Bansal, Zhang et al., Microsoft Research, 2023) schlägt ein Framework vor, in dem „konversationsfähige Agenten“ – jeder unterstützt durch eine Kombination aus einem LLM, Tools und menschlichem Input – Nachrichten untereinander austauschen, bis eine Aufgabe abgeschlossen ist. Das Framework führt zwei integrierte Agententypen ein: AssistantAgent (gesteuert durch ein LLM) und UserProxyAgent (der Code ausführen und menschlichen Input weiterleiten kann), sowie einen GroupChatManager, der die Züge in größeren Ensembles steuert.

Die Kernidee ist das, was die Autoren „Konversationsprogrammierung“ nennen: Anstatt die Orchestrierungslogik manuell in Code zu schreiben, spezifiziert man über System-Prompts in natürlicher Sprache, was jeder Agent tun soll, und überlässt die Steuerung des Ablaufs dem Nachrichtenaustausch. Das Paper demonstriert dies anhand von mathematischer Problemlösung, Retrieval-Augmented QA, ALFWorld-Entscheidungsfindung und einer Operations-Research-Anwendung namens OptiGuide.

Kernideen

• Genauigkeitssteigerung im MATH-Benchmark: Ein AutoGen-Setup mit zwei Agenten (ein LLM-Assistent plus ein codeausführender Proxy) erreicht 69,48 % im MATH-Testset, verglichen mit 55,18 % bei alleiniger Nutzung von GPT-4 – ein Gewinn von 14 Punkten durch das Hinzufügen von Feedback zur Codeausführung.
• Human-in-the-Loop ist erstklassig integriert: Der UserProxyAgent verfügt über einen konfigurierbaren human_input_mode – ALWAYS, NEVER oder TERMINATE – was bedeutet, dass man die Aufsicht intensivieren oder reduzieren kann, ohne die Logik des Agenten zu ändern.
• Dynamischer Gruppenchat: Der GroupChatManager wählt den nächsten Sprecher basierend auf dem Konversationsstatus aus, anstatt einer festen Round-Robin-Reihenfolge zu folgen, wodurch Workflows als Reaktion auf entstehende Ergebnisse verzweigen können.
• Sicherheitsgewinn bei OptiGuide: Das Hinzufügen eines SafeGuard-Agenten zu einem Optimierungs-Workflow für die Lieferkette verbesserte die F1-Erkennung von unsicherem Code bei GPT-4 um 8 Prozentpunkte und bei GPT-3.5 um 35 Punkte, während die Codebasis des Benutzers von 430 Zeilen auf 100 schrumpfte.
• Interaktives Retrieval: In QA-Aufgaben konnte der Assistent-Agent zusätzlichen Kontext anfordern, indem er ein UPDATE CONTEXT-Signal ausgab; dies geschah bei etwa 19,4 % der Fragen bei Natural Questions, und der Gesamt-F1-Wert lag bei 23,40 %.
• Komponierbarkeit durch Design: Jeder AutoGen-Agent ist selbst ein gültiges „Tool“, das ein anderer Agent aufrufen kann, sodass hierarchische Pipelines ohne speziellen Glue-Code zusammengesetzt werden können.

Was Bestand hat – und was nicht

Die MATH- und ALFWorld-Ergebnisse sind solide – kontrollierte, reproduzierbare Vergleiche gegen benannte Baselines mit echten Benchmarks. Die Zahl von 69,48 % ist aussagekräftig, da sie den Vorteil des Feedbacks zur Codeausführung innerhalb einer strukturierten Konversationsschleife isoliert.

Schwächer ist die Kosten- und Latenzanalyse bzw. deren Fehlen. Jeder GroupChat-Zug löst einen vollständigen LLM-Aufruf mit dem gesamten bisherigen Konversationsverlauf aus. Ein Workflow mit vier Agenten und zehn Runden bedeutet mindestens vierzig LLM-Aufrufe, jeder mit einem wachsenden Kontextfenster. Das Paper berichtet in keiner seiner Anwendungen über Token-Kosten oder Latenz. In einer Live-Buchhaltungspipeline, die Tausende von Transaktionen verarbeitet, ist dieses Versäumnis nicht akademisch – es entscheidet darüber, ob der Ansatz überhaupt praktikabel ist.

Die Metapher der Konversationsprogrammierung ist ebenfalls fragiler, als sie in Demos erscheint. Der GroupChatManager wählt den nächsten Sprecher aus, indem er das LLM auffordert, aus einer Liste von Agenten zu wählen. Diese Auswahl ist selbst ein probabilistischer Textgenerierungsschritt, was bedeutet, dass der Kontrollfluss auf subtile Weise schiefgehen kann, ohne Ausnahmen auszulösen. Für einen Agenten, der in ein Hauptbuch schreibt – wo die Reihenfolge der Operationen entscheidend ist und ein falsch platzierter Tool-Aufruf einen Journaleintrag korrumpieren könnte – ist eine nicht-deterministische Sprecherauswahl ein echtes Risiko.

Schließlich sind die Evaluierungsaufgaben alle auf eine Sitzung und einen kurzen Horizont beschränkt. Es gibt kein Experiment, bei dem Agenten über Tage hinweg einen Status aufbauen, widersprüchliche Anweisungen verarbeiten oder Konflikte zwischen einem älteren Agenten-Gedächtnis und einem neueren Journaleintrag lösen müssen. Dies sind genau die Szenarien, die in realen Buchhaltungs-Workflows auftreten.

Warum dies für Finanz-KI wichtig ist

Das Argument für Multi-Agenten-Systeme in der Finanz-KI ist simpel: Abstimmung, Buchung und Berichterstattung sind von Natur aus getrennte Anliegen. Eine Beancount-Pipeline könnte einen LedgerReaderAgent haben, der das Hauptbuch schreibgeschützt abfragt, einen ReconcilerAgent, der Transaktionen mit Bankauszügen vergleicht, einen WriterAgent, der neue Einträge vorschlägt, und einen ReviewerAgent, der diese gegen Kontenplan-Regeln prüft, bevor eine Buchung festgeschrieben wird. Das UserProxyAgent-Muster von AutoGen ist die richtige Abstraktion für den WriterAgent – er kann den tatsächlichen Schreibvorgang im Hauptbuch ausführen und das Ergebnis als Nachricht zurückgeben, die der ReviewerAgent prüft.

Das SafeGuard-Ergebnis von OptiGuide ist die am direktesten übertragbare Erkenntnis: Das Hinzufügen eines speziellen Verifizierungsagenten zum Abfangen unsicherer Aktionen verbesserte die Erkennung erheblich, und die Erkennung erfolgte innerhalb der Konversationsschleife und nicht als Post-hoc-Audit. Das ist genau die Architektur, die ich mir für die Sicherheit von Beancount-Schreibvorgängen wünschen würde – ein Verifizierer, der den Commit blockiert, und nicht einer, der erst im Nachhinein warnt.

Das Problem der nicht-deterministischen Sprecherauswahl ist lösbar: Man kann den GroupChatManager mit einer deterministischen Python-Funktion überschreiben, die basierend auf dem Nachrichteninhalt routet. Aber man muss wissen, dass man das tun muss, und das Paper hebt dies nicht als Problem hervor.

Was man als Nächstes lesen sollte

• AgentBench: Evaluating LLMs as Agents (Liu et al., arXiv:2308.03688, ICLR 2024) – bewertet LLMs in acht verschiedenen Agentenumgebungen, darunter Web-Browsing, Coding und Datenbankmanipulation; die Lücke zwischen kommerziellen und Open-Source-Modellen ist die wichtigste Erkenntnis und gibt direkt Aufschluss darüber, welche Basismodelle für Finanz-Agenten-Pipelines verwendet werden sollten.
• TradingAgents: Multi-Agents LLM Financial Trading Framework (arXiv:2412.20138) – instanziiert das AutoGen-Muster direkt für Finanzmärkte mit spezialisierten Agenten für Analysten, Forscher, Trader und Risikomanager; die Ergebnisse für Sharpe-Ratio und maximalen Drawdown liefern die ersten echten Performance-Zahlen für Multi-Agenten-Finanzsysteme.
• AGENTLESS: Demystifying LLM-based Software Engineering Agents (Xia et al., arXiv:2407.01514) – argumentiert, dass ein einfacher, agentenloser Zwei-Phasen-Ansatz (Lokalisieren, dann Reparieren) komplexe Multi-Agenten-Frameworks auf SWE-bench übertrifft; ein nützliches Gegengewicht zu der Annahme, dass mehr Agenten immer hilfreich sind.