BIRD-benchmark: De kloof met echte databases in LLM Text-to-SQL

De BIRD-benchmark (NeurIPS 2023 Spotlight) is het artikel dat ik steeds van plan ben te lezen wanneer iemand beweert dat GPT-4 een "database in gewoon Engels kan bevragen". Het stelt een scherpe vraag: kunnen LLM's daadwerkelijk dienen als database-interface op echte databases, in plaats van academische "toy" schema's? Het antwoord is ontnuchterend op manieren die bijna direct laten zien waar een natuurlijke-taal querylaag voor Beancount-grootboeken mee te maken zou krijgen.

Het artikel

"Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs" door Jinyang Li en een groot team van DAMO Academy, HKU, UIUC en anderen introduceert BIRD: 12.751 vraag-SQL-paren over 95 echte databases van in totaal 33,4 GB verdeeld over 37 professionele domeinen. Die schaal is essentieel. Spider en WikiSQL, de twee benchmarks die het text-to-SQL onderzoek hiervoor domineerden, gebruiken kleine, schone databases met hooguit een paar honderd rijen. BIRD gebruikt databases afkomstig van echte instellingen — financiële overzichten, toxicologische rapporten, datasets van de overheid — waar waarden vervuild zijn, kolom-semantiek domeinkennis vereist en query-efficiëntie er daadwerkelijk toe doet. Het artikel introduceert ook twee statistieken: Execution Accuracy (EX), die controleert of het SQL-resultaat overeenkomt met het juiste antwoord, en de Valid Efficiency Score (VES), die correcte maar trage queries bestraft.

Belangrijkste ideeën

• GPT-4 bereikt slechts 54,89% uitvoeringsnauwkeurigheid op de testset wanneer er geselecteerde externe kennisbewijzen worden verstrekt. Zonder dat bewijs daalt dit naar 34,88% — een kloof van 20 procentpunten die onthult hoe sterk het model leunt op de verstrekte hints in plaats van op zijn eigen wereldkennis.
• De menselijke prestatie ligt op 92,96% op de dev-set, wat een gat van 38 punten laat, zelfs nadat GPT-4 de domeincontext van de antwoorden heeft gekregen.
• Externe kennis wordt verstrekt als een "bewijszin" per vraag (bijv. "account.type = 'OWNER' betekent dat de rekeninghouder de primaire eigenaar is"). Modellen die deze context niet zelf kunnen ophalen of afleiden, zijn vanaf het begin in feite gehandicapt.
• Het financiële domein, dat het meest relevant is voor Beancount, vertoont het hoogste percentage ruis in annotaties: een vervolgaudit wees uit dat ongeveer 49% van de datapunten in het financiële domein fouten bevatten — spelfouten, dubbelzinnige vragen of onjuiste SQL-queries.
• Het scorebord is sinds de publicatie aanzienlijk veranderd. Vanaf 2026 bereikt het leidende systeem (AskData + GPT-4o) 81,95% op de testset, terwijl de menselijke prestatie nog steeds op ~92,96% ligt, maar de kloof is voornamelijk gedicht door complexe meerstaps-pipelines, niet door ruwe modelcapaciteit.

Wat overeind blijft — en wat niet

De kernbijdrage blijft staan: benchmarks in de stijl van Spider onderschatten de moeilijkheidsgraad van text-to-SQL door geschoonde schema's te gebruiken. BIRD's nadruk op echte databasewaarden en externe kennis onthult faalmechanismen die nooit voorkomen bij schone data, en de verschuiving van 20 procentpunten door het toevoegen van kennisbewijs is een reproduceerbare en belangrijke bevinding.

Maar de benchmark heeft een ontwerpfout die in eigen vervolgonderzoek wordt erkend. Het externe kennisbewijs is handgeschreven, per query, door annotatoren met domeinexpertise. Dat is geen realistisch implementatiescenario. Een echte NL-to-SQL agent krijgt geen vooraf geschreven hint voor elke vraag; hij moet de relevante domeincontext zelf ophalen of afleiden. Het SEED-artikel (2025) laat zien dat automatisch gegenereerd bewijs in sommige settings gelijkwaardig kan zijn aan of zelfs beter kan zijn dan handgeschreven bewijs, wat BIRD's impliciete aanname dat de kennishinderpaal het moeilijkste deel is, verzwakt.

De ruis-audit is schadelijker. Tweeëntwintig "gold" SQL-queries in de dataset zijn ronduit fout. Wanneer deze worden gecorrigeerd, verschuiven de modelranglijsten: zero-shot GPT-3.5 presteert beter dan DIN-SQL en MAC-SQL, die ontworpen zijn om GPT-3.5 te verslaan op de ongecorrigeerde benchmark. Dat is een waarschuwingssignaal. Een benchmark waarvan de ranglijst omkeert bij opschoning leert ons net zoveel over annotatie-artefacten als over modelcapaciteit. Met name het ruispercentage van 49% in de financiële sector maakt domeinspecifieke conclusies onbetrouwbaar.

Er is ook een subtieler probleem met VES. Het belonen van query-efficiëntie is een verstandig praktijkdoel, maar om een benchmark te kunnen trainen en evalueren op efficiëntie, heb je feitelijke gegevens nodig over wat "efficiënt" betekent voor een specifieke database-engine en datadistributie. VES werkt hier omdat BIRD de uitvoeringsomgeving beheert. Die voorwaarde zou niet gelden voor een Beancount-agent die beanquery uitvoert op het persoonlijke grootboek van een gebruiker op uiteenlopende hardware.

Waarom dit belangrijk is voor financiële AI

Beancount's querytaal, BQL (beschikbaar via de bean-query CLI en de beanquery-bibliotheek), komt syntactisch dicht in de buurt van SQL: het ondersteunt SELECT, WHERE, GROUP BY, aggregatiefuncties en joins over de ingebouwde posting- en balanstabellen. Een natuurlijke-taalinterface die vragen van gebruikers vertaalt naar BQL is de meest logische instap voor niet-technische gebruikers, en de bevindingen van BIRD kaderen deze uitdaging direct in.

Het probleem van externe kennis in BIRD is direct te vertalen naar Beancount. Een gebruiker vraagt misschien "hoeveel heb ik vorig jaar uitgegeven aan medische kosten?" en de agent moet weten dat de medische kosten van de gebruiker onder Expenses:Health:* of Expenses:Medical vallen, afhankelijk van hoe de rekeningen zijn georganiseerd. Die koppeling is persoonlijk en staat in geen enkel trainingscorpus. De bevinding van BIRD dat GPT-4 zonder bewijs 20 punten verliest, suggereert dat elke BQL-genererende agent een ophaalstap nodig heeft die de eigen rekening-taxonomie van de gebruiker leert — in feite een kennisbank per gebruiker.

Het probleem met vervuilde data is ook direct herkenbaar. Geïmporteerde banktransacties hebben vaak inconsistente namen van verkopers, OCR-fouten en gemengde coderingen. BIRD kwantificeert wat dit kost aan SQL-correctheid, en het getal is groot genoeg om voorverwerking tot een cruciaal onderdeel te maken in plaats van een bijzaak.

Wat BIRD niet behandelt: grootboekspecifieke constructies zoals balanscontroles (balance assertions), pad-directives of boekingen in meerdere valuta's hebben geen equivalent in standaard SQL, dus elke BQL-agent zal te maken krijgen met een complexiteitslaag die BIRD niet meet. De benchmark is een nuttige ondergrens, geen plafond.

Wat nu te lezen

• Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2502.04306, ICLR 2025 Oral) — breidt BIRD uit naar bedrijfsomgevingen met cloud-databases en workflows met meerdere bestanden; de natuurlijke volgende stap voor het begrijpen van implementatiekloven in de praktijk.
• SEED: Enhancing Text-to-SQL Performance and Practical Usability Through Automatic Evidence Generation (arXiv:2506.07423) — pakt direct BIRD's aanname van handgeschreven bewijs aan met een geautomatiseerde pipeline.
• DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction (arXiv:2304.11015, NeurIPS 2023) — een van de top BIRD-baselines; laat zien hoe het opdelen van een complexe SQL-query in subproblemen de nauwkeurigheid verbetert, een techniek die direct toepasbaar is op meerstaps BQL-queries over Beancount-grootboeken.