Text-to-SQL

Wat is text-to-SQL?

Bij text-to-SQL zet je een taalmodel tussen een mens en een database. Je typt "hoeveel hebben we vorig kwartaal gefactureerd in België", het model schrijft de query voor jou, de database voert ze uit en je krijgt een cijfer terug. Je hoeft dus geen query-editor te openen om zelf code te schrijven.

Het idee bestaat al veel langer dan de huidige golf taalmodellen. Onderzoekers zijn al decennia bezig met databases bevragen in gewone taal, en Power BI had Q&A al jaren voor iemand van LLM's had gehoord. Wat wel veranderd is, is de succesratio van de technologie. Een model dat enorm veel SQL gelezen heeft, krijgt vandaag joins, datumlogica en aggregaties voor elkaar waar de oudere systemen op strandden.

De moeilijkheid is wel op precies dezelfde plek blijven zitten. SQL schrijven was namelijk nooit het echte knelpunt. Het echte werk zit in wat je over je eigen data moet weten. Je moet weten in welke tabel het omzetcijfer staat dat je directie ook echt gebruikt. Je moet weten welke lijnen de boekhouding eruit haalt. En je moet weten welke van de vier datumkolommen jullie bedoelen als jullie "vorig kwartaal" zeggen. Een model dat alleen tabelnamen en kolomnamen te zien krijgt, moet naar die drie dingen raden.

Hoe een text-to-SQL-systeem een query bouwt

Als je onder de motorkap kijkt, doen zowat alle implementaties dezelfde vier stappen.

1. Het schema ophalen
   Het systeem verzamelt eerst de tabellen, kolommen, datatypes en relaties die voor de vraag nodig kunnen zijn. In een groot warehouse kan je dat niet allemaal meesturen, dus zoekt het systeem eerst welke tabellen het meest relevant lijken. Als die keuze fout zit, dan zit alles wat erna komt ook fout.

2. De prompt samenstellen
   Het schema, de vraag, de gespreksgeschiedenis en een reeks voorbeelden van een vraag met de bijhorende query gaan samen naar het model. Die voorbeelden doen meer werk dan de meeste teams verwachten. Het is namelijk daar dat je vastlegt dat "omzet" bij jullie de nettolijn is en niet de brutolijn.

3. De query genereren
   Het model schrijft een query. Sommige systemen laten het model meerdere voorstellen maken en kiezen daar dan één van uit.

4. Valideren en uitvoeren
   Het systeem controleert de query op vorm, toetst ze aan het schema en dwingt meestal af dat ze alleen mag lezen. Loopt ze op een fout, dan stuurt het systeem die foutboodschap terug naar het model en probeert het opnieuw. Dankzij die herstellus kan een systeem dat in een demo wankel oogt, in de praktijk toch goed bruikbaar zijn.

Let op wat er in dat rijtje ontbreekt. Er zit geen stap in die nagaat of de query de vraag ook echt beantwoordt. Je kan de syntax van een query controleren, maar de betekenis ervan niet.

Text-to-SQL tegenover een semantische laag

Bij allebei stelt iemand een vraag in gewone taal. Het verschil zit in wat er gebeurt tussen die vraag en je tabellen.

Text-to-SQL is een toegangsmechanisme. Het vertaalt een zin naar een query op de tabellen die er nu eenmaal staan, en het leidt de betekenis van een kolom af uit haar naam en haar inhoud.

Een semantische laag is een laag die betekenis vastlegt. Iemand heeft daar één keer opgeschreven wat omzet is, langs welke dimensies je ze mag opsplitsen en hoe de tabellen aan elkaar hangen. Het model schrijft dan geen SQL meer. Het kiest een metriek en een paar dimensies, en een query-engine bouwt de query volgens vaste regels.

Het verschil dat je in de praktijk voelt, is hoe een fout eruitziet. Als text-to-SQL zich vergist, dan krijg je een geloofwaardig cijfer zonder enige waarschuwing erbij. Als een semantische laag zich vergist, dan krijg je een foutmelding die zegt dat die metriek of die dimensie niet bestaat. Een fout getal dat er juist uitziet, kost je veel meer dan een vraag die je niet beantwoord krijgt.

Onafhankelijke tests wijzen almaar in dezelfde richting. Text-to-SQL is de voorbije jaren een pak accurater geworden, en het blijft nog altijd achter op een goed gemodelleerde semantische laag. Dat verschil zit vooral bij vragen die draaien om een bedrijfsdefinitie en niet om SQL-syntax. Het interessante is dat je met beter modelleren allebei de aanpakken tegelijk vooruithelpt. Je model opkuisen is dus nooit verloren werk.

Waar je text-to-SQL tegenkomt in de Microsoft-stack

Microsoft levert dit op verschillende plekken, telkens onder een andere naam.

Fabric data agent
Deze kiest eerst een databron en roept dan natural language to SQL aan voor een lakehouse of een warehouse, natural language to DAX voor een Power BI semantisch model, en natural language to KQL voor een eventhouse. Alles draait alleen-lezen en onder de rechten van wie de vraag stelt, dus je row level security blijft gewoon werken.

Copilot in Power BI
Copilot beantwoordt hier vragen op een semantisch model in plaats van op ruwe tabellen. Dat leunt dus dichter aan bij een semantische laag dan bij echte text-to-SQL, en daarom bepalen jouw beschrijvingen, synoniemen en verborgen velden hoe goed het werkt.

Copilot in het warehouse en in notebooks
Deze variant is gemaakt voor mensen die de gegenereerde SQL zelf kunnen lezen en bijsturen. Dat is een pak veiliger, want er kijkt iemand met verstand van zaken naar het resultaat voor het ergens terechtkomt.

Waar moet je op letten bij het gebruik van text-to-SQL

De fout maakt geen lawaai. Een verkeerde join of een vergeten filter levert je een getal op en geen foutmelding. Zorg er dus voor dat mensen de gegenereerde query kunnen opvragen, en dat er minstens iemand in je team is die ze kan lezen.

De echte dubbelzinnigheid zit in je eigen bedrijfstermen. Denk aan "actieve klant", "marge" of "openstaande order". Elk van die termen heeft een definitie die ergens in een Excel of in iemands hoofd zit. Schrijf ze op als voorbeeldquery of als measure voor je het model de schuld geeft.

Rechten regelen zichzelf niet. Het systeem moet de database bevragen als de gebruiker en niet als een serviceaccount dat overal leesrecht heeft. Controleer dat meteen bij de start, want dit is de fout die je geen verkeerd cijfer oplevert maar een datalek.

Meer tabellen maken het slechter in plaats van beter. Als je een agent op een volledig warehouse richt, dan gaat de accuraatheid omlaag, omdat de zoekstap meer kansen krijgt om de verkeerde tabel te pakken. Begin met een kleine set goed benoemde tabellen en breid van daaruit rustig uit.

Dezelfde vraag kan je twee keer een ander antwoord geven. De output van een model ligt niet vast. Voor een cijfer dat in een raad van bestuur belandt of in een rapportering aan de overheid, stuur je de vraag beter langs een metriek die je zelf hebt vastgelegd.