DIN-SQL: Gedecomponeerd In-Context Leren voor Text-to-SQL

Vorige week behandelde ik BIRD, de benchmark die liet zien hoe hard LLM's struikelen wanneer text-to-SQL verschuift van zorgvuldig samengestelde speelgoeddatabases naar praktijkschema's met rommelige naamgeving, domeinkennis en efficiëntiebeperkingen. DIN-SQL is het artikel dat ik eigenlijk eerst had moeten lezen: het definieerde wat een zorgvuldig gedecomponeerde LLM-prompting-pijplijn daadwerkelijk kan bereiken op Spider en BIRD, en het verscheen op NeurIPS 2023 van Mohammadreza Pourreza en Davood Rafiei, precies op het moment dat GPT-4 breed beschikbaar kwam. Het nu lezen — nadat BIRD het plafond heeft blootgelegd — maakt de sterktes en beperkingen veel duidelijker zichtbaar.

Het artikel

DIN-SQL (arXiv:2304.11015) richt zich op een aanzienlijk prestatiegat. Begin 2023 bereikten de beste ge-finetunede modellen — RESDSQL-3B+NatSQL — een uitvoeringsnauwkeurigheid van 79,9% op de Spider-testset, terwijl GPT-4 met naïeve few-shot prompting slechts 67,4% haalde op de ontwikkelset. De hypothese van Pourreza en Rafiei is dat dit gat grotendeels een interfaceprobleem is: LLM's zijn capabel genoeg, maar het genereren van SQL in één enkele stap vraagt hen om schema-linking, complexiteitsclassificatie en query-synthese tegelijkertijd op te lossen. Decomponeer deze in sequentiële subtaken en geef elke oplossing door als context, en het verhaal verandert.

Hun pijplijn bestaat uit vier fasen: (1) een schema-linking module die chain-of-thought prompting gebruikt om de vraag in natuurlijke taal te koppelen aan specifieke kolommen en waarden in het schema; (2) een classificatie- en decompositiemodule die de query indeelt in eenvoudig (één tabel, geen joins), niet-genest complex (joins maar geen subquery's), of genest complex (joins, subquery's, set-bewerkingen) en, voor geneste query's, het probleem opdeelt in sub-query's; (3) een SQL-generatiemodule die de prompting-strategie afstemt op de complexiteitsklasse — simpele few-shot voor eenvoudig, NatSQL tussenliggende representatie voor niet-genest, meerstaps chain-of-thought voor genest; en (4) een zelfcorrectiemodule die het model vraagt om zijn eigen output te controleren op kleine fouten zoals een ontbrekende DISTINCT of een verkeerd geplaatste DESC.

Belangrijke ideeën

• GPT-4 + DIN-SQL bereikt 85,3% uitvoeringsnauwkeurigheid op de Spider holdout-testset, een sprong van +5,4 punten ten opzichte van de toenmalige SOTA ge-finetunede RESDSQL-3B+NatSQL (79,9%), zonder enige taakspecifieke trainingsdata.
• Op de Spider-dev-set verhoogt de decompositie-pijplijn de score van GPT-4 van 67,4% (few-shot baseline) naar 74,2% — een duidelijke winst van +6,8 punten. CodeX Davinci stijgt van 61,5% naar 69,9%.
• Ablatie bevestigt dat elke fase bijdraagt: het verwijderen van enkel schema-linking verlaagt CodeX van 69,9% naar 65,9%; het verwijderen van classificatie verlaagt dit verder naar 63,1%.
• De winst is geconcentreerd in eenvoudige en gemiddelde query's. Bij "extra moeilijke" query's bereikt zelfs de volledige DIN-SQL + GPT-4 pijplijn slechts 43,4% op Spider-dev — decompositie lost complexiteit niet op, het vermindert alleen vermijdbare fouten bij behapbare query's.
• Zelfcorrectie is modelgevoelig: GPT-4 reageert op "vriendelijke" prompts die vragen om mogelijke verbeteringen; CodeX reageert beter op "generieke" prompts die ervan uitgaan dat de SQL fout is. Dit suggereert dat de module stilistische opschoning uitvoert, geen echte semantische verificatie.
• Op BIRD-dev scoort DIN-SQL + GPT-4 50,72% tegenover een gewone GPT-4 baseline van 46,35% — een verbetering van +4,4 punten, aanzienlijk kleiner dan de winst op Spider, waar ik later op terugkom.

Wat standhoudt — en wat niet

Het kernresultaat is reëel. Het decomponeren van text-to-SQL in expliciete subtaken verbetert de prestaties, en de ablatiestudies zijn overtuigend genoeg om de bijdragen van de individuele modules te geloven. Schema-linking is het belangrijkst voor moeilijke query's, wat logisch is: het model kan geen correcte JOINs genereren als het niet eerst correct heeft geïdentificeerd naar welke tabellen en kolommen de vraag verwijst.

Toch plaatsen de resultaten me voor een aantal vragen. De discrepantie tussen 74,2% (dev) en 85,3% (test) is verdacht. Ontwikkelsets zijn meestal moeilijker of minstens even moeilijk als testsets omdat modellen er impliciet op worden afgestemd; een sprong van +11 punten van dev naar test is ongebruikelijk. De auteurs verklaren dit niet, en het doet me afvragen of de testset een andere distributie van query-moeilijkheidsgraden heeft, of dat er iets is in de manier waarop de holdout-test wordt geëvalueerd (via de officiële Spider-leaderboard-server) dat verschilt van hun eigen dev-set-evaluatie. Ik zou die 85,3% niet citeren zonder dat voorbehoud.

Het gat bij BIRD (50,72% dev) is opvallend kleiner dan de winst bij Spider. BIRD-databases hebben rommelige praktijkschema's met afgekortte kolomnamen, domeinspecifieke terminologie en ambigue waarden. De DIN-SQL schema-linking module is ontworpen met de relatief schone schema's van Spider in het achterhoofd; wanneer de schema's vuiler worden, daalt de nauwkeurigheid van de linking en verslechtert de rest van de pijplijn mee. Dit is precies wat het BIRD-artikel mat, en DIN-SQL lost dit niet op.

De kosten- en latentiecijfers zijn een probleem voor elk productiesysteem: ongeveer $0,50 en 60 seconden per vraag met GPT-4. Dat is prima voor een data-analist die tien query's per dag uitvoert, maar volstrekt onwerkbaar voor interactief gebruik. Het artikel presenteert dit als een bekende beperking, maar stelt geen pad voor om dit te verminderen. DAIL-SQL (arXiv:2308.15363), dat enkele maanden later verscheen, zou laten zien dat een betere voorbeeldselectie in plaats van expliciete decompositie 86,6% op Spider kon bereiken — waarmee het DIN-SQL overtrof tegen aanzienlijk lagere kosten.

De zelfcorrectiemodule is het zwakste onderdeel. De auteurs geven toe dat deze alleen "kleine" fouten onderschept. Wat het niet kan, is semantische fouten detecteren — gevallen waarin de gegenereerde SQL syntactisch correct is en zelfs wordt uitgevoerd, maar de verkeerde vraag beantwoordt. Dat is de moeilijkere foutmodus voor echte gebruikers.

Waarom dit belangrijk is voor finance AI

Beanquery (BQL) is een SQL-achtige querytaal voor Beancount-grootboekgegevens. Het heeft zijn eigen tabelstructuur — transactions, postings, balance, prices — met rekeninghiërarchieën, tags en metadatavelden die in niets lijken op generieke databaseschema's. Een natuurlijke taalinterface voor BQL is zeer nuttig (er is al een experimentele beanquery-mcp server die precies dit implementeert via MCP), en de decompositiestrategie van DIN-SQL is het juiste startpunt.

Schema-linking over BQL is het analoge probleem van schema-linking over relationele tabellen, maar met twee extra complicaties: rekeningnamen zijn hiërarchische paden zoals Assets:US:Checking:Bank, en het relevante schema hangt af van het type query dat de gebruiker stelt (resultatenrekening, balans, kasstroomoverzicht). De classificatiemodule van DIN-SQL suggereert een directe aanpassing: classificeer eerst de intentie van de query (balans vs. flow vs. prijsopzoeking) en leid dit vervolgens naar verschillende prompt-sjablonen.

De bevinding van de BIRD-benchmark dat rommeligheid in de praktijk LLM text-to-SQL schaadt, is direct relevant. Een Beancount-grootboek is ook "rommelig" — door de gebruiker gedefinieerde rekeningnamen, inconsistente valutasymbolen, aangepaste metadatasleutels. De verbetering van 4,4 punten bij BIRD tegenover de 6,8 punten bij Spider vertelt me dat het regime van gestructureerde, schone schema's overschat hoeveel decompositie zal helpen bij daadwerkelijke BQL-query's. Verwacht in de praktijk kleinere winsten.

De kostenbeperking is reëel, maar hier minder bindend. Een particuliere financiële gebruiker die 10–20 query's per dag uitvoert, kan API-kosten van $5–10 per dag tolereren als de interface echt nuttig is. De latentie (60 seconden) is meer een probleem voor interactief gebruik; het batchen van analytische query's zou dit kunnen omzeilen.

Wat je nu kunt lezen

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — een systematische studie van prompt-engineering-strategieën; haalt 86,6% op Spider door te focussen op voorbeeldselectie in plaats van architecturale decompositie, een nuttig tegenwicht voor DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — de ge-finetunede baseline die door DIN-SQL werd verslagen; begrijpen wat de ge-finetunede aanpak goed doet, verduidelijkt waar prompting nog tekortschiet.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — breidt het idee van meerstaps decompositie uit naar een expliciete multi-agent pijplijn met een Selector, Decomposer en Refiner; bereikt 59,59% op BIRD met GPT-4 en is de meest agent-centrische aanpak in dit vakgebied.