BIRD-Benchmark: Die Kluft bei realen Datenbanken in LLM Text-to-SQL

Der BIRD-Benchmark (NeurIPS 2023 Spotlight) ist die wissenschaftliche Arbeit, die ich jedes Mal lesen möchte, wenn jemand behauptet, GPT-4 könne „eine Datenbank in einfachem Englisch abfragen“. Er stellt eine gezielte Frage: Können LLMs tatsächlich als Datenbankschnittstelle für reale Datenbanken dienen, anstatt nur für akademische Beispiel-Schemata? Die Antwort ist ernüchternd und lässt sich fast direkt auf die Herausforderungen übertragen, vor denen eine Abfrageschicht in natürlicher Sprache für Beancount-Ledger stehen würde.

Die Arbeit

„Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs“ von Jinyang Li und einem großen Team der DAMO Academy, HKU, UIUC und anderen führt BIRD ein: 12.751 Frage-SQL-Paare über 95 reale Datenbanken mit insgesamt 33,4 GB aus 37 Fachbereichen. Diese Skalierung ist der entscheidende Punkt. Spider und WikiSQL, die beiden Benchmarks, die die Text-to-SQL-Forschung zuvor dominierten, nutzen kleine, saubere Datenbanken mit höchstens ein paar hundert Zeilen. BIRD nutzt Datenbanken aus echten Institutionen – Finanzberichte, Toxikologieberichte, Regierungsdatensätze –, in denen Werte unsauber sind, Spaltensemantik Fachwissen erfordert und Abfrageeffizienz tatsächlich eine Rolle spielt. Die Arbeit führt zudem zwei Metriken ein: Ausführungsgenauigkeit (Execution Accuracy, EX), die prüft, ob das SQL-Ergebnis mit der korrekten Antwort übereinstimmt, und den Valid Efficiency Score (VES), der korrekte, aber langsame Abfragen bestraft.

Kernaussagen

• GPT-4 erreicht im Testset nur 54,89 % Ausführungsgenauigkeit, wenn kuratiertes externes Fachwissen (Evidence) bereitgestellt wird. Ohne dieses Wissen fällt die Genauigkeit auf 34,88 % – eine Kluft von 20 Prozentpunkten, die zeigt, wie sehr sich das Modell auf die bereitgestellten Hinweise stützt, anstatt auf sein eigenes Weltwissen.
• Die menschliche Leistung liegt im Development-Set bei 92,96 %, was selbst nach Bereitstellung des Domänenkontexts für GPT-4 eine Lücke von 38 Punkten lässt.
• Externes Wissen wird als „Beweissatz“ (Evidence Sentence) pro Frage bereitgestellt (z. B. „account.type = 'OWNER' bedeutet, dass der Kontoinhaber der Haupteigentümer ist“). Modelle, die diesen Kontext nicht selbst abrufen oder erschließen können, sind von vornherein massiv eingeschränkt.
• Der Finanzbereich, der für Beancount am relevantesten ist, weist die höchste Fehlerrate bei der Annotation auf: Eine nachträgliche Prüfung ergab, dass etwa 49 % der Datenpunkte im Finanzbereich Fehler enthalten – Rechtschreibfehler, zweideutige Fragen oder falsche SQL-Referenzabfragen.
• Das Leaderboard hat sich seit der Veröffentlichung erheblich weiterentwickelt. Stand 2026 erreicht das führende System (AskData + GPT-4o) 81,95 % im Testset, während die menschliche Leistung weiterhin bei ~92,96 % liegt. Die Lücke wurde jedoch hauptsächlich durch komplexe mehrstufige Pipelines geschlossen, nicht durch die reine Leistungsfähigkeit der Modelle.

Was Bestand hat – und was nicht

Der Kernbeitrag bleibt bestehen: Benchmarks im Spider-Stil haben die Schwierigkeit von Text-to-SQL durch die Verwendung bereinigter Schemata deutlich unterschätzt. BIRDs Beharren auf realen Datenbankwerten und externem Wissen deckt Fehlermuster auf, die bei sauberen Daten nie auftreten. Der Sprung von 20 Prozentpunkten durch das Hinzufügen von Wissensnachweisen ist ein reproduzierbares und wichtiges Ergebnis.

Aber der Benchmark hat einen Designfehler, den seine eigenen Folgestudien einräumen. Die externen Wissensbelege werden pro Abfrage von Annotatoren mit Fachkenntnissen manuell erstellt. Das ist kein realistisches Einsatzszenario. Ein realer NL-to-SQL-Agent erhält keinen vorgefertigten Hinweis für jede Frage; er muss den relevanten Domänenkontext selbst abrufen oder ableiten. Das SEED-Paper (2025) zeigt, dass automatisch generierte Belege in einigen Umgebungen mit handgeschriebenen Belegen mithalten oder diese sogar übertreffen können, was BIRDs implizite Annahme schwächt, dass der Wissensengpass der schwierigste Teil sei.

Die Prüfung der Datenqualität (Noise Audit) ist noch gravierender. Zweiundzwanzig SQL-Referenzabfragen im Datensatz sind schlichtweg falsch. Wenn diese korrigiert werden, verschieben sich die Modell-Rankings: Zero-Shot GPT-3.5 übertrifft DIN-SQL und MAC-SQL, die eigentlich darauf ausgelegt sind, GPT-3.5 im unkorrigierten Benchmark zu schlagen. Das ist ein Warnsignal. Ein Benchmark, dessen Rankings sich nach einer Bereinigung umkehren, lehrt uns ebenso viel über Annotationsartefakte wie über die Modellfähigkeit. Insbesondere die Fehlerrate von 49 % im Finanzbereich macht domänenspezifische Schlussfolgerungen unzuverlässig.

Es gibt auch ein subtileres Problem mit dem VES. Die Belohnung von Abfrageeffizienz ist ein sinnvolles Ziel in der Praxis, aber um ein Modell auf Effizienz zu trainieren und zu bewerten, benötigt man eine objektive Wahrheit darüber, was „effizient“ für eine bestimmte Datenbank-Engine und Datenverteilung bedeutet. VES funktioniert hier, weil BIRD die Ausführungsumgebung kontrolliert. Diese Bedingung gilt nicht für einen Beancount-Agenten, der beanquery auf dem persönlichen Ledger eines Nutzers auf unterschiedlicher Hardware ausführt.

Warum dies für Finanz-KI wichtig ist

Die Abfragesprache von Beancount, BQL (verfügbar über das bean-query CLI und die beanquery-Bibliothek), ist syntaktisch eng an SQL angelehnt: Sie unterstützt SELECT, WHERE, GROUP BY, Aggregationsfunktionen und Joins über die integrierten Buchungs- und Saldentabellen. Eine Schnittstelle in natürlicher Sprache, die Benutzerfragen in BQL übersetzt, ist der natürlichste Einstieg für nicht-technische Benutzer, und die Ergebnisse von BIRD stecken den Rahmen für diese Herausforderung direkt ab.

Das Problem des externen Wissens in BIRD lässt sich eins zu eins auf Beancount übertragen. Ein Benutzer könnte fragen: „Wie viel habe ich letztes Jahr für medizinische Ausgaben ausgegeben?“, und der Agent muss wissen, dass die medizinischen Kosten unter Expenses:Health:* oder Expenses:Medical zu finden sind, je nachdem, wie die Konten organisiert wurden. Diese Zuordnung ist persönlich und findet sich in keinem Trainingskorpus. BIRDs Erkenntnis, dass GPT-4 ohne Belege 20 Punkte verliert, legt nahe, dass jeder BQL-Generierungsagent einen Abrufvorgang (Retrieval) benötigt, der die benutzereigene Kontentaxonomie lernt – im Grunde eine Wissensdatenbank pro Benutzer.

Auch das Problem unsauberer Daten lässt sich direkt übertragen. Importierte Banktransaktionen haben oft inkonsistente Händlernamen, OCR-Artefakte und gemischte Kodierungen. BIRD quantifiziert, was dies für die Korrektheit von SQL bedeutet, und die Zahl ist groß genug, um die Vorverarbeitung zu einem Kernanliegen zu machen, anstatt sie als Nebensache zu behandeln.

Was BIRD nicht abdeckt: Ledger-spezifische Konstrukte wie Saldenprüfungen (balance assertions), Pad-Anweisungen oder Buchungen in mehreren Währungen haben keine Entsprechung in Standard-SQL. Daher wird jeder BQL-Agent mit einer Komplexitätsebene konfrontiert, die BIRD nicht misst. Der Benchmark ist eine nützliche Untergrenze, keine Obergrenze.

Was man als Nächstes lesen sollte

• Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2502.04306, ICLR 2025 Oral) — erweitert BIRD auf Unternehmensumgebungen mit Cloud-Datenbanken und Multi-Datei-Workflows; der natürliche nächste Schritt, um Lücken beim Praxiseinsatz zu verstehen.
• SEED: Enhancing Text-to-SQL Performance and Practical Usability Through Automatic Evidence Generation (arXiv:2506.07423) — befasst sich direkt mit BIRDs Annahme handgeschriebener Belege durch eine automatisierte Pipeline.
• DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction (arXiv:2304.11015, NeurIPS 2023) — eine der führenden BIRD-Baselines; zeigt, wie die Zerlegung einer komplexen SQL-Abfrage in Teilprobleme die Genauigkeit verbessert – eine Technik, die direkt auf mehrstufige BQL-Abfragen über Beancount-Ledger anwendbar ist.