RAG vs database queries voor bedrijfsdata

RAG (retrieval-augmented generation) zoekt stukken tekst op die lijken op de vraag en geeft die aan een taalmodel om een antwoord te schrijven. Een database query haalt exact de records op die aan een voorwaarde voldoen en rekent er precies mee. Voor vragen over documenten, zoals contracten, mails en beleid, is RAG geschikt. Voor vragen over getallen, zoals omzet, facturen, aantallen en verschillen, is een query de juiste aanpak, omdat RAG niet garandeert dat alle relevante gegevens worden meegenomen en een taalmodel niet betrouwbaar rekent.

Twee manieren om AI aan je data te laten komen

Een taalmodel weet niets van jouw bedrijf. Om een vraag over je klanten of contracten te beantwoorden, moet het eerst de juiste informatie krijgen. Daar zijn twee hoofdroutes voor.

Hoe RAG werkt

1. Voorbereiden. Documenten worden opgeknipt in stukken van een paar alinea's. Elk stuk wordt omgezet in een getallenreeks die de betekenis vastlegt, een embedding, en opgeslagen in een zoekindex.
2. Zoeken. Bij een vraag wordt ook de vraag omgezet in een embedding. Het systeem zoekt de stukken waarvan de betekenis het meest lijkt op die van de vraag, bijvoorbeeld de beste tien.
3. Antwoorden. Die tien stukken gaan samen met de vraag naar het taalmodel, dat er een antwoord van maakt.

RAG zoekt dus op betekenis, niet op exacte woorden. Een vraag over "prijsaanpassing" vindt ook een passage over "indexering van de vergoeding". Dat maakt het sterk voor ongestructureerde tekst.

Hoe een database query werkt

1. Vertalen. De vraag wordt vertaald naar een exacte opdracht, meestal SQL: selecteer alle facturen van klant X in 2026, tel de bedragen op.
2. Uitvoeren. De database voert de opdracht uit en geeft precies de records terug die eraan voldoen. Niet de meest lijkende, maar alle die voldoen.
3. Uitleggen. Een taalmodel kan het resultaat in gewone taal verwoorden.

Een query is exact en reproduceerbaar. Dezelfde vraag op dezelfde data geeft altijd hetzelfde antwoord. In een AI-systeem wordt de query vaak aangeroepen via tool calling.

Het verschil in één voorbeeld

Vraag: hoeveel hebben we klant X in 2026 gefactureerd?

Met RAG: het systeem zoekt de tien tekststukken die het meest lijken op de vraag. Misschien zijn dat acht facturen van klant X, een factuur van een klant met een vergelijkbare naam en een mail over een factuur. Klant X heeft in 2026 echter 34 facturen gehad. Het model telt de acht op die het kreeg, of schat. Het antwoord klinkt stellig en is fout.

Met een query: SELECT SUM(bedrag) FROM facturen WHERE klant_id = 'X' AND jaar = 2026. De database telt alle 34 op. Het antwoord is exact.

Dit is geen randgeval. RAG is ontworpen om de meest relevante stukken te vinden, niet om volledigheid te garanderen. Voor een optelling, een telling of een vergelijking is volledigheid precies wat je nodig hebt.

Wanneer RAG, wanneer een query

De vuistregel: staat het antwoord in een veld, gebruik een query. Staat het in tekst, gebruik RAG. Moet je tekst en getallen combineren, haal dan eerst de afspraken uit de tekst naar velden en vergelijk die daarna met een query.

De combinatie: extractie en vergelijking

Voor omzetcontrole is de combinatie de interessantste. Veel lekken zitten precies op de grens: een afspraak in tekst die niet in de facturatie terechtkwam.

Rekenvoorbeeld: stel, je hebt 220 klantcontracten als pdf. Je wilt weten bij welke klanten een afgesproken minimale jaarafname niet wordt gefactureerd.

Stap 1, extractie. Een taalmodel leest elk contract en haalt de afspraak eruit in vaste velden: klantnummer, minimale jaarafname in euro's, periode. Dit is geen RAG-vraag, maar een gerichte extractie per document. Een steekproef wordt tegen de pdf gecontroleerd.

Stap 2, opslaan. De velden gaan in een tabel naast de klantgegevens.

Stap 3, query. Een query vergelijkt de minimale afname met de werkelijk gefactureerde omzet per klant. Stel dat 14 klanten onder hun minimum zitten, samen EUR 71.000 onder de afgesproken afname, en dat bij geen van hen een aanvullende factuur is opgemaakt.

Stap 4, beoordelen. Per klant beslist een mens of het minimum wordt ingeroepen. Dat is een commerciële keuze.

De bedragen zijn een voorbeeld. De taakverdeling is de kern: het taalmodel leest, de database rekent, de mens beslist. Het lekpatroon zelf staat in revenue leakage tussen contract en factuur.

Waar RAG misgaat bij bedrijfsdata

Onvolledigheid. De beste tien zoekresultaten zijn niet alle relevante. Bij documenten is dat vaak acceptabel, bij cijfers nooit.

Verouderde versies. De index bevat het oude en het nieuwe contract. Beide lijken op de vraag. Het model krijgt misschien het oude.

Verkeerde context. Een stuk tekst wordt los van zijn document aangeboden. Een bedrag uit een bijlage "Optie B, niet gekozen" lijkt voor het model een afspraak.

Toegangsrechten. Een zoekindex met alle documenten van het bedrijf geeft iedereen die vragen mag stellen potentieel toegang tot alles. Rechten moeten ook in de index gelden, zie hoe je AI toegang geeft tot bedrijfsdata.

Waar queries misgaan

Een verkeerde vertaling. Als een taalmodel de SQL schrijft, kan het de verkeerde tabel of het verkeerde filter kiezen. Een query die foutloos draait, kan inhoudelijk verkeerd zijn. Smalle, vooraf gedefinieerde functies, zoals omzet_per_klant(klant, periode), zijn veiliger dan vrije SQL.

Slechte brondata. Een exacte query op foute data geeft een exact fout antwoord. Zie wat er gebeurt als AI verkeerde bedrijfsdata gebruikt.

Onduidelijke definities. "Omzet" kan gefactureerd, betaald of contractueel betekenen. Zonder vaste definitie beantwoordt de query een andere vraag dan gesteld.

Controlelijst: welke aanpak gebruikt jouw AI-toepassing?

1. Vraag hoe getallen tot stand komen. Via een query of berekening, of door het model uit opgehaalde tekst?
2. Stel een controlevraag waarvan je het antwoord kent, zoals de omzet van een klant in een afgesloten jaar, en vergelijk met de administratie.
3. Stel dezelfde vraag twee keer. Krijg je hetzelfde getal?
4. Vraag bij documentvragen om de bron: welk document, welke passage?
5. Check of toegangsrechten gelden voor zowel de database als de zoekindex.
6. Check of oude documentversies uit de index worden verwijderd of gemarkeerd.

In een revenue intelligence-systeem

Een systeem dat omzetlekkage vindt, rekent met geld. Daarom moeten de bedragen uit exacte berekeningen op de bronsystemen komen, niet uit tekst die een taalmodel samenvat. RAG en extractie hebben hun plek bij het lezen van contracten, offertes en mails, waar afspraken staan die nooit in een veld zijn beland. Het samenspel van die lagen staat in hoe AI binnen Revenue Intelligence werkt en in de AI-architectuur voor Revenue Intelligence.

Veelgestelde vragen

Is RAG slecht voor bedrijfsdata?

Nee, maar het is gemaakt voor tekst. Voor contracten, beleid en correspondentie is het nuttig. Voor cijfers uit je administratie of CRM is een query betrouwbaarder.

Kan een taalmodel zelf SQL schrijven?

Ja, en dat werkt vaak redelijk. Maar een query die draait is niet automatisch een juiste query. Voor terugkerende vragen zijn vooraf gedefinieerde functies veiliger dan vrije SQL.

Wat is het verschil tussen RAG en fine-tuning?

RAG geeft het model op het moment van de vraag relevante informatie mee. Fine-tuning past het model zelf aan door het extra te trainen. Voor bedrijfsdata die steeds verandert, is fine-tuning zelden de juiste keuze.

Heb ik een data warehouse nodig voor queries?

Niet per se. Een query kan ook rechtstreeks op de database van een systeem draaien of via de API van je CRM of administratie. Een centrale plek wordt nuttig zodra je gegevens uit meerdere systemen wilt combineren.