Wat is RAG (Retrieval-Augmented Generation)? Helder uitgelegd

RAG (retrieval-augmented generation) is een techniek die een taalmodel verbindt met uw eigen documenten, zodat het antwoordt op basis van echt opgehaalde informatie in plaats van alleen het geheugen. Komt er een vraag binnen, dan zoekt het systeem in een kennisbank naar de meest relevante passages, voegt die toe aan de prompt, en het model schrijft zijn antwoord verankerd in die opgehaalde tekst. Zo blijven antwoorden actueel en to the point, en wordt het verzinsel (hallucinatie) dat modellen op basis van enkel hun trainingsdata teistert sterk teruggedrongen.

RAG in een zin

Een kaal taalmodel weet alleen wat het tijdens de training heeft opgenomen. Vraag het naar uw retourbeleid, uw nieuwste producthandleiding of een contract dat vorige week is getekend, en het heeft geen idee. Het zegt dan dat het het niet weet of, erger nog, het verzint iets dat plausibel klinkt. Retrieval-augmented generation dicht dat gat door het model de relevante documenten te laten lezen voordat het antwoordt.

Zie het als het verschil tussen een slimme collega die uit het hoofd antwoordt en diezelfde collega die eerst de juiste map opent, de twee pagina's leest die ertoe doen en dan pas reageert. Het redeneren is hetzelfde, de verankering totaal anders. RAG is het leidingwerk dat het model elke keer automatisch de juiste pagina's aanreikt.

Belangrijk: RAG verandert het model zelf niet. U traint niets opnieuw. U omhult het model met een ophaalstap die op het moment van de vraag betrouwbare, actuele context uit uw eigen data haalt.

Die framing doet ertoe, want ze schept realistische verwachtingen. RAG is geen slimmer brein, het is een beter geïnformeerd brein. De intelligentie komt uit het taalmodel dat u al heeft. Wat RAG toevoegt, is dat die intelligentie op de juiste feiten wordt gericht (de uwe) in plaats van op een vaag gemiddelde van alles wat het model tijdens de training op het publieke internet zag.

De pijplijn: ophalen -> verrijken -> genereren

RAG bestaat uit drie stappen op een rij, en de namen zeggen letterlijk wat ze doen. Wie elke stap begrijpt, ziet meteen dat er weinig mysterieus aan is.

1. Ophalen (retrieve). Uw documenten (beleidsstukken, handleidingen, oude tickets, contracten, wikipagina's) worden opgesplitst in kleinere stukken (chunks) en omgezet in numerieke representaties, embeddings genaamd. Die staan in een vectordatabase. Komt er een vraag binnen, dan wordt ook die omgezet in een embedding, en het systeem zoekt de chunks waarvan de betekenis het dichtst bij de vraag ligt. Dit is vectorzoeken, ook wel semantisch zoeken: het matcht op betekenis en niet alleen op exacte trefwoorden, zodat "hoe krijg ik mijn geld terug" uw retourbeleid vindt, ook als die woorden er nergens in voorkomen.

2. Verrijken (augment). De handvol best scorende chunks worden samen met de vraag van de gebruiker in de prompt gezet, meestal met een instructie als "beantwoord de vraag uitsluitend op basis van de onderstaande context". Het model ziet nu de vraag én het bronmateriaal in hetzelfde verzoek.

3. Genereren (generate). Het taalmodel schrijft een antwoord in natuurlijke taal op basis van die aangereikte context. Omdat de relevante feiten letterlijk in de prompt staan, weerspiegelt het antwoord uw eigen documenten. Een goed gebouwd systeem kan bovendien aangeven welke passages het heeft gebruikt, zodat een mens het kan verifiëren.

Dat is het hele mechanisme. Geen toverij, geen hertraining: zoeken, dan lezen, dan schrijven. De kwaliteit van het eindantwoord hangt sterk af van de eerste stap: haalt u de juiste chunks op, dan is het antwoord doorgaans uitstekend; haalt u de verkeerde op, dan antwoordt het model met overtuiging vanuit het verkeerde materiaal.

Een klein maar belangrijk detail: de prompt die in stap twee naar het model gaat, is meestal een sjabloon en blijft voor de gebruiker onzichtbaar. Achter een vriendelijk vraagvenster zit een instructie die in feite zegt: "hier is de vraag van de gebruiker, hier zijn de meest relevante passages uit de kennisbank, beantwoord de vraag alleen op basis hiervan en geef aan als het antwoord er niet in staat." Die laatste zinsnede (het model toestaan om "ik weet het niet" te zeggen) is een van de goedkoopste en effectiefste manieren om een RAG-systeem eerlijk te houden.

Waarom RAG hallucinaties terugdringt en antwoorden actueel houdt

Hallucinatie (een model dat iets onwaars met volle overtuiging beweert) komt grotendeels doordat het model gaten opvult met statistische patronen in plaats van feiten. RAG pakt die oorzaak bij de wortel aan. Staat het echte antwoord direct in de prompt, dan heeft het model veel minder reden om iets te verzinnen. Het moet de context nog steeds correct lezen, dus RAG vermindert hallucinatie eerder dan dat het die uitschakelt, maar bij vragen die op documenten zijn verankerd is de verbetering groot en consistent.

Het tweede voordeel is actualiteit. De trainingsdata van een model hebben een afsluitdatum en liggen na de training vast. Uw onderneming ligt niet vast: prijzen wijzigen, beleid wordt geactualiseerd, nieuwe producten komen op de markt. Met RAG werkt u simpelweg de documenten in de kennisbank bij en weerspiegelt het volgende antwoord die wijziging meteen. Geen modelupdate, geen wachten, geen technische release. Het model blijft hetzelfde; de kennis die het leest is altijd actueel.

Er is ook een vertrouwensdimensie die in de gereguleerde Europese context zwaar weegt. Omdat RAG-antwoorden te herleiden zijn naar specifieke bronpassages, kunt u laten zien *waarom* het systeem zei wat het zei. Die controleerbaarheid wordt steeds belangrijker onder kaders als de EU AI Act, en het is een reden waarom verankerde systemen beter te verdedigen zijn dan een blackbox-model dat uit zijn geheugen antwoordt. Het bredere regelgevingsbeeld behandelen we in onze gids over naleving van de EU AI Act in Nederland.

Nog een praktisch punt over kosten en controle. Omdat de ophaalstap het model terugbrengt tot een paar relevante passages, kunt u vaak een kleiner, goedkoper model gebruiken en toch sterke antwoorden krijgen; het model hoeft minder zelf uit te dokteren. En omdat uw kennis in een database staat die u zelf bezit en niet ingebakken zit in andermans modelgewichten, houdt u er grip op: u kunt ze corrigeren, versioneren, afschermen of verwijderen. Voor organisaties die met gevoelige of persoonsgegevens werken, is die scheiding tussen de redeneermotor en de kennis die ze leest een echt governance-voordeel.

RAG versus fine-tuning, kort

Mensen vragen vaak of ze nu RAG of fine-tuning nodig hebben. Ze lossen verschillende problemen op, en de korte versie is deze: RAG geeft een model nieuwe kennis om te lezen; fine-tuning leert een model een nieuwe vaardigheid of stijl.

RAG is de juiste standaardkeuze wanneer het doel is om vragen te beantwoorden over een hoeveelheid informatie die verandert: uw kennisbank, uw beleid, uw productdocumentatie. Het is sneller te bouwen, goedkoper actueel te houden en veel eenvoudiger te controleren, omdat u bij elk antwoord de exacte bron kunt aanwijzen.

Fine-tuning verdient zijn plek wanneer u het model een consistente toon wilt laten aannemen, een strak uitvoerformaat wilt laten volgen of een gespecialiseerde taak wilt laten uitvoeren die geen enkele hoeveelheid context kan aanleren. De twee zijn geen rivalen; volwassen systemen gebruiken vaak RAG voor de kennis en een lichte vorm van fine-tuning voor het gedrag. Dit is een echte afweging met kosten- en onderhoudsconsequenties, dus daar schreven we een aparte vergelijking over. Zie RAG vs fine-tuning voor de volledige uitsplitsing. Hier signaleren we alleen dat het verschillende gereedschappen zijn.

Een handige vuistregel als iemand erop staat dat hij "de AI op onze data moet trainen": negen van de tien keer wil hij eigenlijk dat de AI *antwoordt vanuit* zijn data, en dat is RAG, geen fine-tuning. Met RAG beginnen houdt bovendien uw opties open; u kunt later altijd fine-tuning eroverheen leggen als blijkt dat gedrag, en niet kennis, het knelpunt is.

Concrete zakelijke toepassingen van RAG

RAG komt het best tot zijn recht overal waar medewerkers of klanten vragen stellen waarvan het antwoord ergens al op schrift staat, maar verspreid, lang of moeilijk doorzoekbaar is. Een aantal patronen komt bij de klanten waar we bij Crux Digits mee werken keer op keer terug.

• Interne kennisassistent. Nieuwe medewerkers en drukke teams stellen hun vraag aan een chatbot in plaats van collega's lastig te vallen of in een wiki te spitten. "Wat is onze reiskostenlimiet voor Duitsland?" wordt beantwoord vanuit het feitelijke HR-handboek, met een link naar de bronparagraaf.
• Klantenservice op uw documentatie. Een supportassistent beantwoordt klantvragen vanuit producthandleidingen, FAQ's en eerder opgeloste tickets, en handelt zo de repetitieve 60 à 70 procent van de vragen af, zodat medewerkers zich op de lastige kunnen richten. Doordat de antwoorden verankerd zijn, blijven ze consistent met uw officiële documentatie.
• Beleids- en compliancevragen. Juridische, financiële en complianceteams bevragen dichte regelgeving en interne beleidsdocumenten in gewone taal, met bronvermeldingen die ze kunnen verifiëren voordat ze handelen. Herleidbaarheid is hier geen extraatje; het is de hele bedoeling.
• Offerte- en aanbestedingsondersteuning. Teams hergebruiken goedgekeurde eerdere antwoorden en productinformatie om sneller reacties op te stellen. Hier gaan we dieper op in bij AI-gestuurde offerte- en RFP-generatie.

Deze toepassingen overlappen met het bredere werk dat we doen rond generatieve AI en AI-agentontwikkeling, waar een RAG-laag vaak het onderdeel is dat een assistent echt nuttig maakt in plaats van een generieke chatbot.

De rode draad is informatie die al bestaat maar moeilijk bereikbaar is op het moment dat iemand haar nodig heeft. Als de meestgestelde vragen van uw team allemaal antwoorden hebben die begraven liggen in pdf's, gedeelde schijven, ticketgeschiedenissen of een handboek van honderd pagina's, is dat een sterk signaal dat RAG zich terugverdient. Hangen de antwoorden daarentegen af van live berekeningen, realtime systeemstatus of een oordeel dat geen enkel document vastlegt, dan is RAG op zichzelf het verkeerde gereedschap, en een eerlijke beoordeling vooraf bespaart veel verspilde moeite.

Hoe goede data voor RAG eruitziet

RAG is niet beter dan de documenten die eronder liggen, dus de datakwaliteit bepaalt of het project slaagt. De eerlijke waarheid is dat het grootste deel van het werk bij een RAG-bouw niet de AI is, maar het op orde brengen van het bronmateriaal.

Goede RAG-data zijn schoon, actueel en gezaghebbend. Schoon betekent leesbare tekst in plaats van gescande afbeeldingen of rommelige tabellen die de chunker in de war brengen. Actueel betekent dat verouderde documenten worden verwijderd of duidelijk geversioneerd; niets vergiftigt een RAG-systeem sneller dan twee tegenstrijdige beleidsstukken die allebei in de index staan. Gezaghebbend betekent dat u de bron vertrouwt; klopt het onderliggende document niet, dan herhaalt RAG die fout trouw.

Ook dekking telt. De kennisbank moet de antwoorden bevatten op de vragen die mensen daadwerkelijk gaan stellen. Staat een onderwerp nergens beschreven, dan kan geen enkele ophaaltechniek het tevoorschijn toveren; een gat in uw documenten is een gat in uw antwoorden. Een korte inventarisatie van wat mensen vragen tegenover wat er op schrift staat, wijst meestal precies uit waar te beginnen. Bronmateriaal naar een betrouwbare, doorzoekbare staat brengen is bij uitstek een data engineering-vraagstuk, en daar besteedt een verstandig project zijn eerste weken aan.

Structuur helpt meer dan mensen verwachten. Heldere koppen, consistente metadata (de eigenaar, datum en categorie van een document) en logische scheidingen tussen onderwerpen maken het ophalen allemaal preciezer, omdat het systeem meer signaal heeft om op te matchen. U heeft geen perfect datawarehouse nodig om te starten; een gerichte, goed georganiseerde set van de documenten die uw meestgestelde vragen beantwoorden, verslaat doorgaans een wildgroei aan half onderhouden bestanden. Begin smal, bewijs de waarde en breid de kennisbank uit naarmate het vertrouwen groeit.

Grenzen en faalmodi om rekening mee te houden

RAG is krachtig maar niet moeiteloos, en de faalmodi zijn voorspelbaar genoeg om omheen te ontwerpen. Ze vooraf kennen is het verschil tussen een demo die imponeert en een systeem dat het in productie volhoudt.

• Slecht ophalen, slecht antwoord. Levert de zoekstap de verkeerde chunks op, dan antwoordt het model vlot vanuit het verkeerde materiaal. De meeste kwaliteitsproblemen bij RAG zijn ophaalproblemen, geen modelproblemen, dus daar betaalt het afstemwerk zich terug.
• Chunking-keuzes doen ertoe. Splitst u documenten te klein, dan verliest u context; te groot, dan begraaft u de relevante zin in ruis. Er is geen universele instelling; het hangt af van uw content en wordt beter met testen.
• Evaluatie is onmisbaar. U heeft een manier nodig om te meten of antwoorden accuraat en verankerd zijn, idealiter tegen een set echte vragen met bekende goede antwoorden. Evaluatie overslaan betekent dat u problemen pas ontdekt wanneer een gebruiker dat doet.
• Het is geen kennismaker. RAG haalt op wat er is; het redeneert zich niet naar feiten die nooit zijn opgeschreven. Stel uw verwachtingen daarop af.

Geen van deze punten is een reden om RAG te mijden, het zijn redenen om het bewust te bouwen, met meting vanaf dag één. Wilt u een eerlijke kijk op de vraag of RAG bij uw situatie past, dan is onze opdracht AI-audit & strategie een vastomlijnde manier voor EUR 2.500 om daar achter te komen voordat u zich aan een bouw verbindt, en u bent welkom om eerst een vrijblijvend gesprek in te plannen om het samen door te nemen.

Veelgestelde vragen