MAC-SQL: Multi-Agent Collaborative Text-to-SQL
MAC-SQL erschien im Dezember 2023 als die expliziteste agentenzentrierte Antwort auf das Text-zu-SQL-Problem: Anstatt dass ein einziger Prompt eine Abfrage generiert, arbeiten drei spezialisierte Agenten zusammen, um ein relevantes Teilschema auszuwählen, die Frage zu zerlegen und das SQL nach der Ausführung zu reparieren. Ich lese es, weil die beiden vorherigen Beiträge BIRD (den Benchmark, den MAC-SQL bei der Einreichung anführte) und DIN-SQL (die Dekompositions-Baseline, die MAC-SQL erweitert) abdeckten, und sich die natürliche Frage stellt, ob ein Multi-Agenten-Wrapper auf diesen Grundlagen einen konkreten Mehrwert bietet.
Das Paper
"MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL" (Wang et al., COLING 2025) zielt auf einen Fehlermodus ab, den BIRD bei früheren Single-Prompt-Methoden aufzeigte: Große Datenbanken mit verrauschten Schemata und komplexe, mehrstufige Fragen überfordern Modelle, die versuchen, alles in einem Durchgang zu lösen.
Die Architektur besteht aus drei Agenten. Ein Selector grenzt eine große Datenbank auf ein relevantes Teilschema ein, indem er irrelevante Tabellen und Spalten herausfiltert, bevor die SQL-Generierung beginnt. Ein Decomposer ist das Herzstück — er zerlegt komplexe naturalsprachliche Fragen in Teilprobleme und generiert SQL schrittweise mit Few-Shot-Chain-of-Thought-Reasoning. Ein Refiner führt das Kandidaten-SQL gegen die reale Datenbank aus, liest Fehlermeldungen wortwörtlich aus und korrigiert die Abfrage iterativ bis zu einem maximalen Wiederholungslimit. Nicht alle drei Agenten werden bei jeder Abfrage aktiv; einfachere Aufgaben überspringen den Selector oder den Refiner basierend auf Komplexitätssignalen.
Die Autoren haben zudem SQL-Llama (Code Llama 7B) auf den vom Framework produzierten Ausgaben feinabgestimmt, was eine kleinere Open-Source-Variante ermöglicht.
Kernaussagen
- Schema-Reduktion vor der Generierung: Der Selector filtert die Datenbank auf ein relevantes Teilschema, bevor der Decomposer das SQL schreibt. Die Ablationsstudie bestätigt ein Plus von 2,11 Prozentpunkten bei BIRD dev — real, aber bescheiden.
- Ausführungsgesteuerte Verfeinerung: Der Refiner liest tatsächliche Datenbank-Fehlermeldungen und korrigiert das SQL. Dies ist der größte Einzelbeitrag in der Ablationsstudie: Das Entfernen senkt die Genauigkeit bei BIRD dev um 4,63 Punkte, mehr als das Entfernen des Selectors (-2,11) oder sogar des Decomposers (-3,85).
- Bedingte Agenten-Zuweisung: Das Routing einfacherer Abfragen am Selector und Refiner vorbei spart Token, ohne die Genauigkeit in einfachen Fällen zu beeinträchtigen.
- Lücke bei der Open-Source-Destillation: SQL-Llama (7B) erreicht 43,94 % bei BIRD dev gegenüber der GPT-4-Baseline von 46,35 %. Die Lücke ist angesichts des Unterschieds in der Parameteranzahl nicht dramatisch, aber das feinabgestimmte 7B-Modell liegt immer noch mehr als 15 Punkte hinter dem vollen Testwert von 59,59 % von GPT-4+MAC-SQL.
- BIRD-Testergebnis: 59,59 % Ausführungsgenauigkeit, was zum Zeitpunkt der Einreichung die Spitzenposition im Leaderboard einnahm und DAIL-SQL+GPT-4 (57,41 %) um 2,18 Punkte übertraf.
Was Bestand hat – und was nicht
Der Refiner ist die beste Idee hier, was die Ablationsstudie deutlich zeigt. Ein Agent, der eine echte Datenbank-Fehlermeldung liest und sein eigenes SQL korrigiert, handelt wesentlich prinzipientreuer als ein LLM, das sich in einem Vakuum selbst hinterfragt — dies ist das CRITIC-Prinzip des "werkzeug-interaktiven Kritisierens", direkt und konkret auf SQL-Ausführungs-Feedback angewendet.
Der Beitrag des Selectors ist positiv, aber gering. Bei Datenbanken mit Hunderten von Tabellen spielt er wahrscheinlich eine größere Rolle; für die typischen Schemata in BIRD ist er marginal. Das Paper berichtet zudem nicht, wie oft der Selector ausgelöst wird oder wie präzise er relevante Spalten beibehält — es bleibt eine Blackbox mit einem einzigen aggregierten Wert.
Der Decomposer ist eine inkrementelle Verbesserung gegenüber DIN-SQL. DIN-SQL zerlegte Abfragen bereits in Teilprobleme mit Selbstkorrektur; MAC-SQL verpackt dies als Multi-Agenten-Konversation neu. Die architektonische Aufteilung in drei benannte Agenten ähnelt eher einer Software-Design-Entscheidung als einem neuen Inferenz-Algorithmus. Ob die Drei-Agenten-Prompt-Struktur bei gleicher Token-Anzahl einen einzelnen Agenten mit einem längeren Prompt übertrifft, wurde nie getestet. Die eingestandenen Einschränkungen — Prompts seien "nicht umfassend optimiert" und das Fine-Tuning auf 7B begrenzt — sind real, aber das wesentlichere Versäumnis ist das Fehlen einer Ablationsstudie zum Vergleich von Prompt-Länge versus Architektur.
Der zeitliche Kontext ist für die Einordnung wichtig. MAC-SQLs 59,59 % im BIRD-Test waren im Dezember 2023 State-of-the-Art. Bis Mitte 2025 zeigt das BIRD-Leaderboard Systeme, die die 81 %-Marke überschreiten. Die spezifischen Ideen — Teilschema-Filterung, Fragen-Dekomposition, Ausführungswiederholung — wurden von nachfolgenden Arbeiten absorbiert und durch Reasoning-First-Training, RLVR und reichhaltigeres CoT erweitert. Als Artefakt wirkt MAC-SQL veraltet; als Architekturmuster bleibt es aktuell.
Warum das für Finanz-KI wichtig ist
Beancount nutzt beanquery — eine SQL-nahe Abfragesprache — als primäre programmatische Schnittstelle für Ledger-Daten. Eine reale, mehrjährige Beancount-Datei hat ein Schema, das Dutzende von Konten in einer Hierarchie, mehrere Währungen, Metadaten-Tags und berechnete Saldospalten umfasst. Das ist genau das Problem des großen, verrauschten Schemas, auf das der Selector abzielt.
Der Decomposer lässt sich direkt auf die Arten von Abfragen anwenden, die Nutzer tatsächlich stellen: "Wie hoch waren meine gesamten Ausgaben für Restaurantbesuche in EUR im 3. Quartal 2024, ohne erstattete Transaktionen, aufgeschlüsselt nach Monaten?" ist ein Dekompositionsproblem — Filtern nach Konten-Präfix, Filtern nach Datumsbereich, Ausschluss markierter Transaktionen, Aggregation pro Monat. Der Refiner lässt sich ebenfalls natürlich übertragen: Bevor ein generierter Beancount-Eintrag finalisiert wird, könnte ein Agent ihn durch den Beancount-Parser im Testlauf schicken, Syntax- oder Bilanzierungsfehler empfangen und revidieren. Die von MAC-SQL demonstrierte Ausführungs-Feedback-Schleife ist dieselbe Schleife, die eine Sicherheitsinstanz für Schreibzugriffe benötigt.
Das Ergebnis der Open-Source-Destillation ist eine Warnung: Das Fine-Tuning eines 7B-Modells zur Annäherung an eine GPT-4-basierte Pipeline liefert ein Modell, das immer noch weit zurückbleibt. Falls Bean Labs ein lokales Modell für die Ledger-Abfragegenerierung entwickelt, legt die Lücke bei MAC-SQL nahe, dass kleine Modelle domänenspezifische Trainingsdaten benötigen, die weit über das hinausgehen, was ein allgemeines Fine-Tuning bietet.
Was man als Nächstes lesen sollte
- DAIL-SQL (Gao et al., 2023, arXiv:2308.15363) — die systematische Benchmark-Evaluierung für Prompt-Engineering, die MAC-SQL bei BIRD direkt verbessert; lesenswert wegen der kontrollierten Ablationsstudie zur Schema-Repräsentation und Few-Shot-Beispielauswahl.
- SQLFixAgent (arXiv:2406.13408) — erweitert die ausführungsgesteuerte SQL-Korrektur zu einem Multi-Agenten-System mit Konsistenzprüfung, ein direkter Nachfahre der Refiner-Idee von MAC-SQL.
- BIRD-Critic / SWE-SQL (2025) — der neuere BIRD-Reasoning-Track, der das Verständnis von Ausführungsfehlern erfordert; die natürliche Weiterentwicklung dessen, was der Refiner in MAC-SQL geleistet hat.
