Kernpunten
- RAG is bedoeld voor ongestructureerde data, zoals documenten, handboeken en contracten.
- Text-to-SQL is bedoeld voor gestructureerde data in een database, zoals omzet, voorraad en orders.
- Bij RAG formuleert het model het antwoord; bij text-to-SQL rekent de database en schrijft het model alleen de query.
- Je kunt beide combineren door elke vraag naar de juiste techniek te sturen.
- ENABLE gebruikt alleen text-to-SQL; RAG op documenten zit niet in het platform.
Twee manieren om AI op eigen data te laten werken
Een taalmodel kent je organisatie niet. Het weet niet wat je omzet was, wat er in je inkoopvoorwaarden staat of welke klant achterloopt met betalen. Om AI bruikbaar te maken op eigen data, moet je het model op het moment van de vraag de juiste informatie geven.
Daarvoor zijn twee gangbare technieken. RAG (retrieval-augmented generation) haalt relevante stukken tekst op uit je documenten. Text-to-SQL laat het model een query schrijven op je database. Een derde route, een model bijtrainen op je eigen data (fine-tuning), is zelden de eerste keuze voor feitelijke vragen: een model onthoudt feiten niet betrouwbaar en moet bij elke wijziging opnieuw worden getraind.
Hoe RAG werkt
RAG is de gebruikelijke techniek achter een AI-kennisbank in een bedrijf: een assistent die vragen beantwoordt over het personeelshandboek, kwaliteitsprocedures, contracten of supportartikelen.
Bij enterprise RAG, RAG op de schaal van een organisatie, komen daar eisen bij. Rechten per document moeten in de zoekindex worden meegenomen, zodat niemand via de AI een document ziet waar hij geen toegang toe heeft. Verouderde versies moeten eruit, de bronvermelding moet kloppen en je moet regelmatig meten of de antwoorden juist zijn. Houd er ook rekening mee dat bij RAG tekstfragmenten uit je documenten naar het taalmodel gaan. In grote lijnen werkt RAG zo:
- Documenten worden opgeknipt in kleinere stukken tekst (chunks).
- Van elk stuk wordt een embedding gemaakt: een reeks getallen die de betekenis vastlegt. Die embeddings gaan in een vectordatabase of zoekindex.
- Bij een vraag zoekt het systeem de stukken die er het meest op lijken, vaak gecombineerd met gewoon zoeken op trefwoorden.
- De gevonden stukken gaan samen met de vraag naar het taalmodel.
- Het model formuleert een antwoord en verwijst naar de bronnen.
Hoe text-to-SQL werkt
Bij text-to-SQL krijgt het model de structuur van je database mee: tabellen, kolommen, relaties en beschrijvingen uit een datadictionary. Op basis daarvan schrijft het een SQL-query, die de database uitvoert. Het antwoord op "Wat was de marge per productgroep?" komt dus niet uit het taalmodel, maar uit je eigen database.
Daardoor is text-to-SQL sterk in precies het werk waar taalmodellen zwak in zijn: exact rekenen over duizenden of miljoenen regels. Het resultaat is controleerbaar, omdat je de query kunt lezen. De kwaliteit hangt vooral af van een helder datamodel en goede metadata.
RAG en text-to-SQL vergeleken
Beide technieken geven AI toegang tot eigen data, maar ze verschillen in bijna alles: het soort data, wat er naar het model gaat en hoe je een antwoord controleert.
| RAG | Text-to-SQL | |
|---|---|---|
| Soort data | Ongestructureerd: documenten, e-mails, wiki's | Gestructureerd: tabellen in een database of datawarehouse |
| Typische vraag | "Wat is onze opzegtermijn voor leveranciers?" | "Wat was de marge per productgroep in het tweede kwartaal?" |
| Wat het model krijgt | Tekstfragmenten uit je documenten en de vraag | Metadata (tabellen, kolommen) en de vraag |
| Wie levert het antwoord | Het taalmodel, op basis van de fragmenten | De database; het model schrijft alleen de query |
| Controleerbaar via | Bronvermelding naar het document | De uitgevoerde query |
| Grootste risico | Verkeerde of verouderde fragmenten, toch een stellig antwoord | Een query die technisch klopt maar een andere vraag beantwoordt |
| Rekenen over veel regels | Zwak | Sterk |
| Toegangsrechten | Per document of map meenemen in de zoekindex | Via databaserechten, views of filters |
| Belangrijkste voorbereiding | Documenten opschonen, actueel houden, rechten vastleggen | Datamodel en datadictionary op orde brengen |
Wanneer kies je RAG en wanneer text-to-SQL?
De vuistregel is eenvoudig: staat het antwoord in een tekst, kies dan RAG; moet het antwoord berekend worden uit tabellen, kies dan text-to-SQL.
Een veelgemaakte fout is RAG gebruiken op exports van tabellen, zoals een CSV met alle orders in een vectordatabase. Het systeem vindt dan een handvol regels die op de vraag lijken, en het model rekent daarmee. Een totaal over alle orders is op die manier niet betrouwbaar. Zo maak je de keuze:
- Kies RAG voor vragen over beleid, procedures, contracten, productdocumentatie, offertes en notulen.
- Kies text-to-SQL voor vragen over omzet, marges, voorraad, orders, uren, planning en andere KPI's.
- Twijfel je, kijk dan naar het soort antwoord: een uitleg of citaat wijst op RAG, een getal of tabel op text-to-SQL.
RAG en text-to-SQL combineren
Veel vragen in een organisatie raken aan beide soorten data. "Waarom daalde de omzet in regio Noord?" vraagt om cijfers uit de database en om context uit verslagen of notities. Een gecombineerde oplossing stuurt elk deel van de vraag naar de juiste techniek: een routeringslaag bepaalt of er een query nodig is, een zoekactie in documenten, of allebei.
RAG kan text-to-SQL ook helpen. Bij grote databases met honderden tabellen kun je met RAG eerst de relevante tabelbeschrijvingen uit de datadictionary opzoeken, en pas daarna het model een query laten schrijven. Wel neemt de complexiteit toe: je hebt twee beveiligingsmodellen, twee bronnen van fouten en een lastigere evaluatie. Begin daarom met de techniek die bij je belangrijkste vragen past.
Wat ENABLE doet en niet doet
ENABLE gebruikt text-to-SQL. In de SQL Explorer stel je een vraag in gewone taal; de AI schrijft SQL op het PostgreSQL-datawarehouse van je organisatie en ENABLE voert die alleen-lezend uit. De AI ontvangt alleen metadata en de vraag, nooit rijen data.
ENABLE doet geen RAG: het platform doorzoekt geen documenten, SharePoint-sites of kennisbanken. Wil je ook vragen over documenten beantwoorden, dan heb je daarvoor een aparte RAG-oplossing nodig. Opgeslagen queries kun je wel via de Data-API als REST-endpoint beschikbaar maken, zodat andere systemen dezelfde gecontroleerde cijfers kunnen ophalen.