Een medewerker typt een vraag in het AI-systeem van de organisatie: hoe gaan we om met btw-verlegging bij dienstverlening buiten de EU? Het antwoord verschijnt binnen enkele seconden. Het verwijst naar de juiste interne richtlijn. Het noemt de voorwaarden die van toepassing zijn. Het antwoord is specifiek voor deze organisatie, gebaseerd op documenten die nergens op het publieke internet staan.
En toch heeft het model dat dit antwoord genereerde, geen enkel van die documenten ooit verwerkt tijdens de training. De richtlijn stond op de interne SharePoint. Het model is getraind op het publieke internet. Hoe kan het antwoord dan kloppen?
Het mechanisme dat dit mogelijk maakt heet Retrieval-Augmented Generation, afgekort tot RAG.
Roland Bieleveldt
Een AI-model genereert antwoorden op basis van patronen uit de training. Die training omvat miljarden documenten van het publieke internet: webpagina’s, boeken, artikelen, codebases. Dat maakt het model breed inzetbaar voor algemene vragen. Maar zodra iemand vraagt “wat is ons retourbeleid voor zakelijke klanten?” of “welke afspraken staan er in het contract met leverancier X?”, stopt het. Die informatie zat niet in de training.
Er zijn twee voor de hand liggende oplossingen, en geen van beide schaalt. De eerste: kopieer de relevante documenten handmatig naar het chatvenster. Dat werkt bij twee pagina’s. Niet bij tweeduizend. De tweede: train het model opnieuw met je eigen data via fine-tuning. Dat is duur, tijdrovend, en het resultaat is verouderd zodra er een nieuw document bijkomt.
RAG kiest een derde weg. Het model wordt niet aangepast. De informatie wordt automatisch opgehaald op het moment dat de vraag wordt gesteld, en meegegeven als context. Het model verwerkt die context en genereert een antwoord dat is gebaseerd op de eigen documenten van de organisatie. Retrieval-Augmented Generation: ophalen, verrijken, genereren. De naam beschrijft exact wat er gebeurt.
Hoe werkt dat concreet? Neem een middelgroot accountantskantoor. Tweehonderd medewerkers, duizenden adviesdocumenten, richtlijnen, procesbeschrijvingen en klantdossiers. Verspreid over SharePoint, een kennisbank en lokale mappen. Een nieuwe medewerker wil weten: “Hoe gaan we om met btw-verlegging bij dienstverlening buiten de EU?”
Het antwoord staat ergens in de interne richtlijnen. Maar waar precies? En in welk document? RAG lost dat op in vijf stappen.
De vraag van de medewerker wordt omgezet naar een reeks getallen, een zogenoemde embedding. Die getallen vatten de betekenis van de vraag samen in een vorm die een computer kan vergelijken met andere teksten.
Dat klinkt abstract. Maar het principe is intuïtief. Stel je een ruimte voor met honderden dimensies, waarin elke tekst een punt inneemt. Teksten die over hetzelfde onderwerp gaan, liggen in die ruimte dicht bij elkaar. Teksten over iets totaal anders liggen ver uit elkaar. “Btw-verlegging bij buitenlandse dienstverlening” ligt dicht bij “fiscale behandeling van grensoverschrijdende services”. En ver van “kantoorbenodigdheden bestellen”.
Die ruimte, de zogenoemde vectorruimte, is de sleutel tot het hele RAG-proces. Het maakt het mogelijk om te zoeken op betekenis in plaats van op exacte woorden.
De embedding van de vraag wordt vergeleken met de embeddings van alle passages in de kennisbron. Die passages liggen opgeslagen in een vector database: een database die is geoptimaliseerd voor het zoeken op betekenisovereenkomst.
Een gewone database zoekt op exacte trefwoorden. Zoek op “btw-verlegging” en je vindt alleen documenten waar precies die term in staat. Een vector database werkt anders. Die vergelijkt de betekenis van de zoekvraag met de betekenis van elke opgeslagen passage. Het document dat dezelfde fiscale regel beschrijft maar de term “omzetbelasting bij cross-border transacties” gebruikt, wordt ook gevonden. Dat is het verschil dat ertoe doet: zoeken op wat je bedoelt, niet op wat je typt.
De vector database retourneert de passages die het dichtst bij de vraag liggen in de vectorruimte. Meestal zijn dat drie tot tien passages, afhankelijk van hoe het systeem is ingericht. In het voorbeeld van het accountantskantoor: twee passages uit de interne btw-richtlijn, één passage uit een recente update over Europese regelgeving, en een fragment uit een eerdere adviesmemo over een vergelijkbare situatie.
Die opgehaalde passages worden samengevoegd met de oorspronkelijke vraag en als context meegegeven aan het AI-model. Het model ontvangt nu de vraag én de relevante informatie uit de eigen kennisbron.
Vergelijk het met het verschil tussen een vraag stellen aan een collega die net is aangenomen, en dezelfde vraag stellen aan die collega nadat je haar het relevante dossier hebt gegeven. De persoon is dezelfde. Het verschil zit in de informatie die ze tot haar beschikking heeft.
Het model verwerkt de vraag en de opgehaalde passages, en genereert een antwoord. Dat antwoord is gebaseerd op de passages. Als de passages de juiste informatie bevatten, is het antwoord relevant en specifiek. Als de passages niet relevant zijn, is het antwoord dat ook niet.
De medewerker van het accountantskantoor krijgt een antwoord dat verwijst naar de interne richtlijn, de recente regelgevingsupdate en de eerdere adviesmemo. Het antwoord bevat de informatie die in die bronnen staat, geformuleerd als een samenhangend geheel. Het model heeft betere informatie gekregen. De capaciteiten zijn identiek gebleven.
Er is een stap die plaatsvindt voordat het RAG-proces kan draaien: de documenten moeten worden voorbereid. Dat is minder vanzelfsprekend dan het klinkt.
Een heel document, een richtlijn van dertig pagina’s of een procesbeschrijving van vijftien pagina’s, is te groot om als geheel op te halen en mee te geven aan het model. Het context window raakt vol en de relevantie verwatert. Maar een enkele zin is te klein: er zit te weinig context in om een bruikbaar antwoord op te baseren. De oplossing is chunking: het opknippen van documenten in passages van de juiste omvang. Elke passage, elke chunk, is groot genoeg om een samenhangend stuk informatie te bevatten en klein genoeg om gericht op te halen. Van elke chunk wordt een embedding gemaakt en opgeslagen in de vector database. Het resultaat is een doorzoekbare versie van de hele kennisbron, waarin elke passage bereikbaar is op basis van betekenis.
Hoe documenten worden opgeknipt, bepaalt de kwaliteit van het hele systeem. Chunks die te groot zijn, bevatten te veel irrelevante informatie naast de relevante passage. Het model moet dan zelf uitzoeken wat ertoe doet, en dat gaat niet altijd goed. Chunks die te klein zijn, missen de context die het antwoord begrijpelijk maakt. Een passage die luidt “de grens is 25.000 euro” is waardeloos zonder de context die vertelt welke grens, voor welke situatie en onder welke voorwaarden.
Het vinden van de juiste granulariteit is een ontwerpkeuze, niet een instelling die je één keer aanzet. Bij het accountantskantoor uit het voorbeeld werden de richtlijnen opgeknipt per onderwerp en per situatie, niet per pagina. Elke chunk bevat een afgeronde uitleg van één fiscale regel, inclusief de toepassingsvoorwaarden. Die keuze kostte tijd om goed te maken. Maar het verschil in de kwaliteit van de antwoorden was direct merkbaar.
Je zou na het voorgaande kunnen denken dat RAG het model verbetert. Dat is een begrijpelijke gedachte. Maar het klopt niet.
RAG verandert het model niet. Het model heeft dezelfde training, dezelfde capaciteiten, dezelfde beperkingen als zonder RAG. Wat verandert, is de informatie die het model ontvangt op het moment dat het een antwoord genereert. RAG verandert de context, niet het model.
Dat onderscheid wordt helder in de vergelijking met fine-tuning. Fine-tuning past het model zelf aan. Het model wordt verder getraind op eigen data, zodat het domeinspecifieke kennis, vakjargon of een bepaalde schrijfstijl overneemt. Het resultaat: het model is permanent veranderd. Dat werkt voor kennis en vaardigheden die stabiel zijn: medische terminologie, juridische redeneerpatronen, een vaste huisstijl.
RAG levert kennis aan bij elke vraag opnieuw. De relevante passages worden vers opgehaald. Verandert het brondocument? Dan verandert het antwoord mee. Komt er een nieuw document bij? Dan is dat direct beschikbaar zonder dat het model opnieuw getraind hoeft te worden.
Fine-tuning werkt voor stabiele domeinkennis. RAG werkt voor kennis die verandert. In de praktijk vullen ze elkaar aan: fine-tuning maakt het model deskundiger in een domein, RAG voorziet het van de actuele informatie die het per vraag nodig heeft.
Hoe werkt het RAG-mechanisme in andere contexten? Twee scenario’s.
Neem een huisartsenpraktijk met zes huisartsen die het eigen medicatieprotocol, de NHG-richtlijnen en het lokale formularium aan een RAG-systeem koppelt. Een arts wil tijdens een consult weten of twee medicijnen samen voorgeschreven kunnen worden. Het systeem haalt de relevante passages op uit het formularium en het interactieprotocol, en genereert een antwoord dat specifiek verwijst naar de richtlijnen van deze praktijk. De arts krijgt geen generiek antwoord van het internet, maar een antwoord dat is gebaseerd op de bronnen waar de praktijk zelf mee werkt. De arts neemt de eindbeslissing. Het systeem levert de informatie aan die die beslissing ondersteunt.
Neem een zelfstandige organisatieadviseur die in tien jaar honderden adviesdocumenten, projectverslagen en methodiekbeschrijvingen heeft opgebouwd en dat archief aan een RAG-systeem koppelt. Bij het voorbereiden van een nieuwe offerte vraagt ze: “Welke aanpak heb ik eerder gebruikt bij vergelijkbare verandertrajecten in de financiële sector?” Het systeem doorzoekt haar eigen archief op betekenis, haalt relevante passages op uit drie eerdere projectverslagen, en presenteert de kern van haar eigen werkwijze. Geen generiek advies, maar haar eigen ervaring, teruggehaald op het moment dat ze die nodig heeft.
Wie wil weten welke factoren bepalen of een RAG-systeem daadwerkelijk goede resultaten oplevert en welke fouten het vaakst worden gemaakt, leest verder bij Wat bepaalt of RAG werkt? (5.2b).
Wie wil begrijpen wanneer RAG de juiste keuze is voor een organisatie en hoe het zich verhoudt tot alternatieven als search en grote context windows, leest verder bij RAG: organisatiekennis koppelen (5.2).
Wie wil zien hoe RAG past in het bredere kader van contextbeheer en het ontwerpen van de informatieomgeving rond een AI-model, vindt dat bij Context engineering: van goede prompt naar slim systeem (4.4).