Kernpunten
- Bij text-to-SQL schrijft de AI de query en rekent de database; het model hoeft daarvoor geen rijen data te zien.
- Duidelijke tabel- en kolomnamen, een datadictionary en vastgelegde definities bepalen grotendeels de kwaliteit van de antwoorden.
- Laat AI-gegenereerde SQL alleen-lezend draaien, met een timeout, een rijlimiet en een controle vooraf.
- Een query kan technisch kloppen en toch een andere vraag beantwoorden; toon de query daarom altijd naast het resultaat.
Hoe text-to-SQL werkt
Text-to-SQL, ook wel AI SQL of natural language to SQL genoemd, maakt een database toegankelijk voor iedereen die een vraag kan formuleren. Het model heeft voor deze taak alleen de structuur van de database nodig, niet de inhoud. Dat is een belangrijk verschil met een export van je data in een chatbot plakken: bij text-to-SQL kunnen de rijen data in de database blijven.
Een typische keten ziet er zo uit:
- Een gebruiker stelt een vraag, bijvoorbeeld "Wat was de omzet per regio in het derde kwartaal?".
- Het systeem verzamelt context: tabellen, kolommen, datatypes en relaties, plus beschrijvingen uit de datadictionary.
- Het taalmodel schrijft een SQL-query in het juiste dialect, zoals PostgreSQL of T-SQL.
- Het systeem controleert de query: is hij geldig, alleen-lezend en beperkt tot toegestane tabellen?
- De database voert de query uit binnen vaste limieten.
- De gebruiker ziet het resultaat samen met de query en kan die aanpassen of opslaan.
Waarom metadata en een datadictionary het verschil maken
Een taalmodel weet niets van jouw organisatie. Het ziet alleen wat je meegeeft. Heet een kolom amt2 en staat nergens wat erin zit, dan moet het model gokken. Bij tabellen die rechtstreeks uit een ERP-systeem komen, met afkortingen en technische codes, gaat dat vaak mis.
Een datadictionary beschrijft per tabel en kolom in gewone taal wat erin staat, in welke eenheid, welke waarden geldig zijn en hoe tabellen aan elkaar hangen. Minstens zo belangrijk zijn bedrijfsdefinities: is omzet gefactureerd of besteld, met of zonder creditnota's? Wat telt als een actieve klant?
In de praktijk levert een opgeruimde laag in je datawarehouse, met begrijpelijke namen en views per onderwerp, meer op dan eindeloos sleutelen aan de prompt. Het verschil tussen zwakke en sterke metadata:
| Onderdeel | Zwak | Sterk |
|---|---|---|
| Kolomnaam | amt2 | bedrag_excl_btw |
| Beschrijving | Leeg | Factuurbedrag exclusief btw, in euro |
| Definitie | "Omzet" betekent voor iedereen iets anders | Omzet is gefactureerd bedrag minus creditnota's |
| Relaties | Niet vastgelegd | orders.klant_id verwijst naar klanten.id |
| Waarden | status = 1, 2 of 3 | status: 1 = open, 2 = verzonden, 3 = geannuleerd |
Veiligheidsmaatregelen bij AI op een database
Wie AI op een database loslaat, moet ervan uitgaan dat een gegenereerde query soms fout, zwaar of ongewenst is. Goede text-to-SQL-oplossingen leggen daarom meerdere lagen beveiliging aan. In de SQL Explorer van ENABLE zijn dat vaste grenzen: alleen-lezen transacties, een timeout van 45 seconden, resultaten in pagina's en een limiet op het aantal queries per minuut. De AI krijgt alleen metadata en de vraag, ENABLE controleert de query met een alleen-lezen queryplan en de gegenereerde query wordt pas uitgevoerd als jij hem uitvoert.
Los van welke tool je gebruikt, zijn dit de maatregelen om op te letten:
- Alleen-lezen: een databasegebruiker met alleen leesrechten, en daarbovenop een alleen-lezen transactie.
- Timeouts: een query die te lang loopt, bijvoorbeeld door een verkeerde join, wordt afgebroken.
- Rijlimieten: een resultaat wordt begrensd, zodat niemand per ongeluk een hele tabel ophaalt.
- Gelijktijdigheidslimieten: een beperkt aantal queries tegelijk per organisatie of gebruiker.
- Afgebakende toegang: alleen de schema's en views die nodig zijn, bij voorkeur op een datawarehouse of kopie in plaats van op het productiesysteem.
- Controle vooraf: de query wordt gevalideerd, bijvoorbeeld met een queryplan, en pas na bevestiging uitgevoerd.
- Minimale gegevens naar het model: alleen metadata en de vraag, geen rijen data of wachtwoorden.
Typische fouten in AI-gegenereerde SQL
De gevaarlijkste fouten geven geen foutmelding. De query draait, het resultaat ziet er geloofwaardig uit, maar het beantwoordt net een andere vraag. Daarom is het belangrijk dat de query altijd zichtbaar is naast het resultaat. Veelvoorkomende fouten en hoe je ze voorkomt:
| Fout | Wat er gebeurt | Hoe je het voorkomt |
|---|---|---|
| Verkeerde join | Orders worden dubbel geteld na een koppeling met orderregels; totalen vallen te hoog uit | Leg vast op welk niveau elke tabel staat en bied views op het juiste niveau |
| Verkeerde definitie | Omzet inclusief btw, of zonder aftrek van creditnota's | Beschrijf kerncijfers in de datadictionary |
| Datumfouten | Kalenderjaar in plaats van boekjaar, of een andere uitleg van "vorige maand" | Gebruik een datumtabel en vermeld het boekjaar |
| Verzonnen kolommen | Het model gebruikt een kolom of tabel die niet bestaat | Valideer tegen het schema en laat het model de fout herstellen |
| Vergeten filters | Geannuleerde orders of testklanten tellen mee | Documenteer statuswaarden en standaardfilters |
| Verkeerd dialect | Functies uit een ander SQL-dialect, zoals TOP in plaats van LIMIT | Geef het databasetype mee als context |
| Vage vraag | "Beste klant" op omzet, terwijl marge bedoeld was | Toon aannames en laat de gebruiker de vraag aanscherpen |
Wanneer text-to-SQL goed werkt, en wanneer niet
Text-to-SQL werkt het best bij gestructureerde data in een goed ingericht model, en bij vragen die niet in een bestaand dashboard staan. Controllers, analisten en datateams gebruiken het om sneller een ad-hocvraag te beantwoorden, een bestaande query te laten uitleggen of een foutmelding op te lossen. Voor wie SQL kent, is AI SQL vooral een versneller; voor wie het niet kent, een ingang.
Het werkt minder goed bij vragen over documenten en beleid (daarvoor is RAG geschikter), bij rommelige brontabellen zonder beschrijving en bij cijfers waarop je zonder controle belangrijke beslissingen neemt. Terugkerende KPI's horen in een vast dashboard met afgesproken definities, niet in een nieuwe vraag aan de AI elke maand.
Text-to-SQL invoeren: een praktische aanpak
Een goede invoering begint niet bij het AI-model, maar bij je data. Deze volgorde werkt in de praktijk:
- Begin bij een datawarehouse of een set views met begrijpelijke namen, niet bij de ruwe tabellen van je bronsysteem.
- Schrijf een datadictionary voor de tabellen die het meest gebruikt worden, inclusief definities van kerncijfers.
- Richt een alleen-lezen databasegebruiker in, met timeouts, rijlimieten en beperkte rechten.
- Start met een kleine groep gebruikers die de data kennen en fouten herkennen.
- Verzamel vragen die fout gingen en verbeter daarmee je metadata, niet alleen de prompt.
- Maak van vragen die steeds terugkomen een opgeslagen query of een dashboard.