DIN-SQL: Zerlegtes In-Context Learning für Text-zu-SQL

Letzte Woche habe ich BIRD behandelt, den Benchmark, der aufzeigte, wie stark LLMs ins Stolpern geraten, wenn Text-zu-SQL von kuratierten Spielzeug-Datenbanken zu realen Schemata mit unordentlicher Benennung, Domänenwissen und Effizienzbeschränkungen übergeht. DIN-SQL ist das Paper, das ich eigentlich zuerst hätte lesen sollen: Es definierte, was eine sorgfältig zerlegte LLM-Prompting-Pipeline tatsächlich auf Spider und BIRD erreichen kann, und es erschien zur NeurIPS 2023 von Mohammadreza Pourreza und Davood Rafiei, genau als GPT-4 allgemein verfügbar wurde. Es jetzt zu lesen – nachdem BIRD die Grenzen aufgezeigt hat – macht die Stärken und Limitierungen viel deutlicher erkennbar.

Das Paper

DIN-SQL (arXiv:2304.11015) adressiert eine eklatante Leistungslücke. Anfang 2023 erreichten die besten feingetunten Modelle – RESDSQL-3B+NatSQL – eine Ausführungsgenauigkeit von 79,9 % auf dem Spider-Testdatensatz, während GPT-4 mit einfachem Few-Shot-Prompting auf dem Development-Set nur 67,4 % schaffte. Die Hypothese von Pourreza und Rafiei lautet, dass diese Lücke primär ein Interface-Problem ist: LLMs sind leistungsfähig genug, aber die Generierung von SQL in einem einzigen Durchgang verlangt von ihnen, Schema-Verknüpfung, Komplexitätsklassifizierung und Abfragesynthese gleichzeitig zu lösen. Zerlegt man diese in sequentielle Teilaufgaben und gibt jede Lösung als Kontext weiter, ändert sich das Bild.

Ihre Pipeline besteht aus vier Phasen: (1) ein Modul zur Schema-Verknüpfung (Schema Linking), das Chain-of-Thought-Prompting nutzt, um die natürlichsprachliche Frage auf spezifische Spalten und Werte im Schema abzubilden; (2) ein Modul zur Klassifizierung und Zerlegung, das die Abfrage in einfach (eine Tabelle, keine Joins), komplex nicht-verschachtelt (Joins, aber keine Unterabfragen) oder komplex verschachtelt (Joins, Unterabfragen, Mengenoperationen) einteilt und bei verschachtelten Abfragen das Problem in Teilabfragen zerlegt; (3) ein SQL-Generierungsmodul, das die Prompting-Strategie an die Komplexitätsklasse anpasst – einfaches Few-Shot für einfache Fälle, NatSQL-Zwischendarstellung für nicht-verschachtelte und mehrstufiges Chain-of-Thought für verschachtelte Fälle; und (4) ein Selbstkorrekturmodul, das das Modell auffordert, seine eigene Ausgabe auf kleinere Fehler wie fehlendes DISTINCT oder falsch platziertes DESC zu überprüfen.

Kernideen

• GPT-4 + DIN-SQL erreicht 85,3 % Ausführungsgenauigkeit auf dem Spider-Holdout-Testset, ein Sprung von +5,4 Punkten gegenüber dem damaligen SOTA-feingetunten RESDSQL-3B+NatSQL (79,9 %), ohne jegliche aufgabenspezifische Trainingsdaten.
• Auf dem Spider-Dev-Set verbessert die Zerlegungs-Pipeline GPT-4 von 67,4 % (Few-Shot-Baseline) auf 74,2 % – ein reiner Gewinn von +6,8 Punkten. CodeX Davinci verbessert sich von 61,5 % auf 69,9 %.
• Ablation-Studien bestätigen, dass jede Phase beiträgt: Das Entfernen der Schema-Verknüpfung allein lässt CodeX von 69,9 % auf 65,9 % fallen; das Entfernen der Klassifizierung senkt den Wert weiter auf 63,1 %.
• Die Gewinne konzentrieren sich auf einfache und mittlere Abfragen. Bei „besonders schwierigen“ (extra hard) Abfragen erreicht selbst die vollständige DIN-SQL + GPT-4 Pipeline nur 43,4 % auf dem Spider-Dev-Set – die Zerlegung löst die Komplexität nicht auf, sie reduziert lediglich vermeidbare Fehler bei lösbaren Abfragen.
• Selbstkorrektur ist modellspezifisch: GPT-4 reagiert auf „sanfte“ Prompts, die nach potenziellen Verbesserungen fragen; CodeX reagiert besser auf „generische“ Prompts, die davon ausgehen, dass das SQL falsch ist. Dies deutet darauf hin, dass das Modul eher stilistische Bereinigungen als echte semantische Verifizierungen durchführt.
• Auf dem BIRD-Dev-Set erzielt DIN-SQL + GPT-4 50,72 % gegenüber einer einfachen GPT-4-Baseline von 46,35 % – eine Verbesserung von +4,4 Punkten, was wesentlich geringer ist als die Gewinne bei Spider, worauf ich noch zurückkommen werde.

Was Bestand hat – und was nicht

Das Kernergebnis ist real. Die Zerlegung von Text-zu-SQL in explizite Teilaufgaben verbessert die Leistung, und die Ablation-Studien sind sauber genug, um den Beiträgen der einzelnen Module Glauben zu schenken. Die Schema-Verknüpfung ist für schwierige Abfragen am wichtigsten, was logisch ist: Das Modell kann keine korrekten JOINs generieren, wenn es nicht zuerst korrekt identifiziert hat, auf welche Tabellen und Spalten sich die Frage bezieht.

Doch einige Punkte lassen mich stutzen. Die Diskrepanz zwischen 74,2 % im Dev-Set und 85,3 % im Test-Set ist verdächtig. Development-Sets sind normalerweise schwieriger oder zumindest genauso schwer wie Test-Sets, da Modelle implizit darauf abgestimmt werden; ein Sprung von +11 Punkten beim Übergang zum Test-Set ist ungewöhnlich. Die Autoren erklären dies nicht, was mich fragen lässt, ob das Test-Set eine andere Verteilung der Abfrageschwierigkeiten aufweist oder ob sich die Evaluierung des Holdout-Tests (über den offiziellen Spider-Leaderboard-Server) von ihrer Dev-Set-Evaluierung unterscheidet. Ich würde die 85,3 % nicht ohne diesen Vorbehalt zitieren.

Die BIRD-Lücke (50,72 % Dev) ist deutlich kleiner als die Gewinne bei Spider. BIRD-Datenbanken haben unordentliche, reale Schemata mit abgekürzten Spaltennamen, domänenspezifischer Terminologie und mehrdeutigen Werten. Das Schema-Verknüpfungsmodul von DIN-SQL wurde mit Blick auf die relativ sauberen Spider-Schemata entwickelt; wenn die Schemata unsauberer werden, sinkt die Genauigkeit der Verknüpfung, und der Rest der Pipeline verschlechtert sich mit ihr. Dies ist genau das, was das BIRD-Paper gemessen hat, und DIN-SQL löst dieses Problem nicht.

Die Kosten und Latenzzeiten sind ein Problem für jedes Produktionssystem: etwa 0,50 $ und 60 Sekunden pro Frage mit GPT-4. Das ist akzeptabel für einen Datenanalysten, der zehn Abfragen pro Tag ausführt, aber völlig unpraktikabel für die interaktive Nutzung. Das Paper präsentiert dies als bekannte Einschränkung, schlägt aber keinen Weg zur Reduzierung vor. DAIL-SQL (arXiv:2308.15363), das einige Monate später erschien, sollte zeigen, dass eine bessere Beispielauswahl anstelle einer expliziten Zerlegung 86,6 % auf Spider erreichen konnte – und damit DIN-SQL bei deutlich geringeren Kosten übertraf.

Das Selbstkorrekturmodul ist der schwächste Teil. Die Autoren räumen ein, dass es nur „kleinere“ Fehler abfängt. Was es nicht kann, ist das Erkennen semantischer Fehler – Fälle, in denen das generierte SQL syntaktisch gültig ist und sogar ausgeführt wird, aber die falsche Frage beantwortet. Das ist für echte Nutzer die weitaus schwierigere Fehlerart.

Warum dies für Finance-AI wichtig ist

Beanquery (BQL) ist eine SQL-ähnliche Abfragesprache für Beancount-Journaldaten. Sie hat ihre eigene Tabellenstruktur – transactions, postings, balance, prices – mit Kontenhierarchien, Tags und Metadatenfeldern, die nichts mit generischen Datenbankschemata gemeinsam haben. Eine natürliche Schnittstelle für BQL ist eine reale und nützliche Sache (es gibt bereits einen experimentellen beanquery-mcp-Server, der genau dies über MCP implementiert), und die Zerlegungsstrategie von DIN-SQL ist der richtige Ausgangspunkt.

Die Schema-Verknüpfung über BQL ist das analoge Problem zur Verknüpfung über relationalen Tabellen, jedoch mit zwei zusätzlichen Besonderheiten: Kontonamen sind hierarchische Pfade wie Assets:US:Checking:Bank, und das relevante Schema hängt davon ab, welche Art von Abfrage der Benutzer stellt (Erfolgsrechnung, Bilanz, Cashflow). Das Klassifizierungsmodul von DIN-SQL legt eine direkte Anpassung nahe: Zuerst die Absicht der Abfrage klassifizieren (Saldo vs. Flow vs. Preisabfrage) und dann zu verschiedenen Prompt-Templates leiten.

Die Erkenntnis des BIRD-Benchmarks, dass reale Unordnung LLM-Text-zu-SQL schadet, ist direkt relevant. Ein Beancount-Ledger ist ebenfalls „unordentlich“ – benutzerdefinierte Kontonamen, inkonsistente Währungssymbole, benutzerdefinierte Metadaten-Keys. Die Verbesserung von 4,4 Punkten bei BIRD gegenüber 6,8 Punkten bei Spider sagt mir, dass das strukturierte Regime mit sauberen Schemata überschätzt, wie viel Zerlegung bei tatsächlichen BQL-Abfragen helfen wird. In der Praxis ist mit geringeren Gewinnen zu rechnen.

Die Kostenbeschränkung ist real, hier aber weniger bindend. Ein Privatanwender im Finanzbereich, der 10–20 Abfragen pro Tag durchführt, kann 5–10 $/Tag an API-Kosten tolerieren, wenn das Interface wirklich nützlich ist. Die Latenz (60 Sekunden) ist eher ein Problem für die interaktive Nutzung; das Batch-Processing analytischer Abfragen könnte dies umgehen.

Was Sie als Nächstes lesen sollten

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) – Systematische Studie von Prompt-Engineering-Strategien; erreicht 86,6 % auf Spider durch Fokus auf Beispielauswahl statt architektonischer Zerlegung, ein nützlicher Gegenpol zu DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) – Die feingetunte Baseline, die DIN-SQL schlug; zu verstehen, was der feingetunte Ansatz gut macht, verdeutlicht, wo Prompting noch zu kurz greift.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) – Erweitert die Idee der mehrstufigen Zerlegung in eine explizite Multi-Agenten-Pipeline mit einem Selector, Decomposer und Refiner; erreicht 59,59 % auf BIRD mit GPT-4 und ist der am stärksten agentenzentrierte Ansatz in diesem Bereich.