Wat is RAG?

Definitie

RAG staat voor Retrieval-Augmented Generation. Uit elkaar getrokken: retrieval is opzoeken, generation is het schrijven van een antwoord, en augmented betekent dat het tweede wordt gevoed door het eerste. Een AI-assistent met RAG verzint dus geen antwoord uit zijn hoofd, maar zoekt eerst de passages op die met jouw vraag te maken hebben en schrijft dan een antwoord op basis van precies die passages.

Het is geen product dat je aanzet en geen model dat je koopt. Het is een werkwijze die je om een taalmodel heen bouwt. Dat onderscheid is belangrijk als je met leveranciers praat: “wij doen RAG” zegt net zoveel als “wij doen software”. De vraag is hóé het is ingericht, en daar zit het verschil tussen iets dat werkt en iets dat er alleen indrukwekkend uitziet.

Hoe het werkt, in vier stappen

De reden dat RAG bestaat, is simpel: een taalmodel kan niet alles tegelijk lezen. Er past een beperkte hoeveelheid tekst in één gesprek, en jouw complete documentenset past daar meestal niet in. RAG lost dat op door per vraag alleen de paar stukjes op te halen die er werkelijk toe doen.

• Knippen, elk document wordt in stukjes gehakt van doorgaans een halve tot een hele pagina. Een heel contract is te grof om als antwoord te dienen; één losse zin is te weinig om te begrijpen.
• Indexeren, elk stukje krijgt een numerieke vingerafdruk die de betekenis vastlegt. Daardoor vindt het systeem “hoe lang loopt de garantie” ook als er in het document “garantietermijn” staat. Die vingerafdrukken worden bewaard in een aparte zoekindex, vaak een vectordatabase genoemd.
• Ophalen, bij een vraag zoekt het systeem de stukjes op die qua betekenis het dichtst bij de vraag liggen, meestal een stuk of vijf tot tien.
• Antwoorden, die stukjes gaan samen met de vraag naar het taalmodel, met de instructie: beantwoord dit alleen op basis van wat hier staat, en zeg het als het antwoord er niet in staat.

Die laatste instructie is waar het staat of valt. Zonder die begrenzing vult het model de gaten aan met wat het uit zijn training kent, en dan heb je alsnog een antwoord dat goed klinkt maar niet uit jouw documenten komt.

Waarom je het nodig hebt zodra AI je eigen documenten in moet

Een taalmodel zonder toegang tot jouw documenten weet veel over de wereld en niets over jouw bedrijf. Vraag je zo'n model naar jullie leveringsvoorwaarden, dan geeft het je de gemiddelde Nederlandse leveringsvoorwaarden: aannemelijk, netjes geformuleerd en niet de jouwe. Dat verschil is uitgebreider uitgewerkt op standaard AI vs. AI op eigen data.

RAG haalt drie dingen binnen die je zonder niet krijgt. Ten eerste actualiteit: pas je een document aan en indexeer je het opnieuw, dan klopt het antwoord meteen, zonder dat er iets hoeft te worden hertraind. Ten tweede herleidbaarheid: het systeem weet welke passages het heeft gebruikt, dus je kunt bij elk antwoord doorklikken naar de bron. Ten derde begrenzing: het model mag alleen putten uit wat is opgehaald, wat de ruimte om iets te verzinnen fors verkleint.

Verkleint, niet wegneemt. RAG maakt onzin zeldzamer, maar hij verdwijnt niet. Haalt het systeem de verkeerde passage op, dan schrijft het model daar een keurig antwoord bij. En dat antwoord is gevaarlijker dan een leeg antwoord, want er staat een bronvermelding onder.

Eerst een andere vraag: staat het antwoord in een document of in een systeem?

Dit is de stap die in vrijwel elke uitleg over RAG wordt overgeslagen, en het is de goedkoopste manier om een verkeerd project te voorkomen. Voordat je iets bouwt, kijk je waar het antwoord op de vraag eigenlijk vandaan komt.

Vragen als “wat is onze garantietermijn op dit type machine”, “hoe is de procedure bij een retour” of “wat staat er in het contract met deze leverancier over indexering” hebben hun antwoord in lopende tekst. Daar is RAG voor gemaakt.

Maar de vragen die in de praktijk het vaakst worden gesteld, zijn van een andere soort: “wat staat er nog open bij deze klant”, “hoeveel uren zijn er op dit project geschreven”, “is deze order al verzonden”. Die antwoorden staan niet in een document maar in je boekhouding, je urenregistratie of je ordersysteem. Ze veranderen bovendien elke dag. Wie die vragen met RAG probeert te beantwoorden, bouwt een kopie van zijn administratie in een zoekindex en gaat vervolgens het probleem oplossen dat die kopie altijd achterloopt.

Voor die vragen wil je geen index maar een koppeling: de assistent stelt op het moment zelf de vraag aan het systeem en krijgt het echte getal terug. Dat is precies waar een MCP-server voor bedoeld is, een programma dat een afgebakende lijst handelingen uit jouw software beschikbaar stelt aan een AI. Wij bouwen die servers, en op MCP-server laten bouwen staat wat zo'n traject inhoudt en kost. In veel bedrijven is de eerlijke uitkomst een combinatie: een koppeling voor de cijfers uit de systemen, RAG voor de kennis die in documenten staat, en één assistent die allebei kan raadplegen.

Wanneer een zoekfunctie volstaat en RAG overkill is

RAG is een goede oplossing voor een probleem dat lang niet iedereen heeft. Er zijn drie manieren om AI met jouw documenten te laten werken, en de meest indrukwekkende is zelden de goedkoopste.

Die middelste optie wordt vaak vergeten en is de afgelopen jaren veel bruikbaarder geworden. De grotere modellen van dit moment hebben een contextvenster van rond een miljoen tokens, genoeg voor honderden A4'tjes tekst in één gesprek. Heb je een productcatalogus, een personeelshandboek en een set voorwaarden die samen binnen die grens passen, dan kun je die simpelweg elke keer meesturen. Geen index, geen herindexeren, geen risico dat er iets niet wordt opgehaald: het model ziet alles. Je betaalt wel per vraag voor die hele hoeveelheid tekst, dus bij duizenden vragen per dag kantelt de rekensom weer richting RAG.

Sla RAG dus over als je documentenset klein en stabiel is, als je collega's prima uit de voeten kunnen met een fatsoenlijke zoekfunctie in het systeem dat ze al hebben, of als de echte vraag over cijfers uit een pakket gaat in plaats van over tekst. Bouw het wel als je set groot is, blijft groeien, en de kennis erin nu vastzit in de hoofden van twee mensen die daardoor de hele dag worden gestoord.

Wat er in de praktijk misgaat

Bijna elk RAG-project dat teleurstelt, strandt op een van deze drie punten. Geen ervan is technisch onoplosbaar, en geen ervan lost zichzelf op.

Verouderde documenten geven met overtuiging antwoord

Een zoekindex zoekt op betekenis, niet op geldigheid. Staan de handleiding uit 2019 en de herziene versie uit 2024 allebei in de index, dan lijken ze allebei even relevant en is de kans reëel dat de oude bovenkomt. Het antwoord is dan verkeerd, en het klinkt precies zo overtuigend als een goed antwoord.

Dit is geen randgeval maar de normale toestand van een gedeelde schijf. Voordat je indexeert, moet iemand bepalen welke documenten gelden en welke niet, en dat is inhoudelijk werk dat je niet aan een leverancier kunt uitbesteden. Wat daarna helpt: leg per document een geldigheidsdatum en een status vast als metadata, laat het ophalen filteren op “actueel”, en zet het opnieuw indexeren vast in het proces dat documenten wijzigt in plaats van het periodiek met de hand te doen. En houd het archief buiten de index, hoe verleidelijk volledigheid ook is.

Rechten lopen niet vanzelf mee

Dit is het risico dat het vaakst pas na oplevering wordt ontdekt. Je documenten staan keurig in mappen met rechten erop: personeelsdossiers voor HR, klantdossiers per accountmanager, salarisbrieven voor niemand. Zodra je die documenten indexeert, ontstaat er een nieuwe kopie van de inhoud in een zoekindex, en die index heeft die rechten niet. Vanaf dat moment kan iedereen die de assistent mag gebruiken een antwoord krijgen uit een document dat hij zelf nooit had mogen openen, zonder dat er ergens een regel wordt overtreden die iemand had ingesteld.

Er zijn twee werkbare routes. Je kunt per rechtengroep een aparte index bouwen, wat eenvoudig te begrijpen en te controleren is maar duurder wordt naarmate je meer groepen hebt. Of je slaat bij elk stukje op wie het mag zien en filtert daarop tijdens het ophalen, wat flexibeler is maar staat of valt met de vraag of die rechten bij het indexeren correct zijn meegekomen. Wat in geen geval werkt, is het model vragen om gevoelige informatie niet te noemen: dat is een instructie, geen beveiliging.

Begin daarom klein en met een set waar geen rechtenvraagstuk op zit, zoals openbare productdocumentatie of algemene procedures. De AVG-kant en de vraag wat je moet vastleggen staan in de AI-Act & AVG-checklist voor het mkb.

Antwoorden zonder bron zijn niet te controleren

Een RAG-systeem weet altijd welke passages het heeft gebruikt. Er is dus geen enkele goede reden om die niet te tonen. Toch leveren veel implementaties een vloeiend antwoord zonder verwijzing, omdat dat er in een demo prettiger uitziet.

Zonder bron kan niemand het antwoord narekenen, en dus wordt het ofwel blind geloofd ofwel helemaal niet gebruikt. Beide zijn slechte uitkomsten. Eis dat elk antwoord een klikbare verwijzing heeft naar het document én de plek erin, en dat het systeem expliciet “dit staat niet in de documenten” zegt in plaats van iets aannemelijks te construeren. Dat laatste voelt in het begin als een slechter product en is precies waarom je het na een half jaar nog steeds gebruikt.

Wat het kost, en waar de kosten echt zitten

De techniek is zelden het probleem. Voor een set van een paar duizend documenten praat je bij de gangbare aanbieders over enkele tientjes per maand aan opslag en rekenwerk voor de index. Daarbovenop komt een kleine opslag op elke vraag, omdat je bij elke vraag een paar opgehaalde passages meestuurt naar het model. Voor intern gebruik binnen een mkb-bedrijf blijven die bedragen bescheiden; kijk pas goed als je aan tienduizenden vragen per maand denkt.

Het geld gaat naar twee andere dingen. Het eerste is het opruimen vooraf: bepalen wat er in mag, dubbelingen eruit halen, scans die alleen uit plaatjes bestaan leesbaar maken. Dat is meestal het grootste deel van een eerste traject en het is werk waarin jouw mensen de kennis hebben, niet de bouwer. Het tweede is het bijhouden daarna. Een index die na oplevering niet meer wordt onderhouden, is binnen een jaar een verzameling verouderde antwoorden met een bronvermelding eronder.

Vraag een leverancier daarom niet alleen naar de bouwsom. Vraag wat het kost als er honderd documenten wijzigen, wie verantwoordelijk is voor het opnieuw indexeren, en hoe je kunt zien of het systeem nog goede antwoorden geeft. Dat laatste hoort een vaste afspraak te zijn: leg een lijst van dertig tot vijftig echte vragen vast met het antwoord dat eruit hoort te komen, en draai die na elke wijziging opnieuw. Zonder zo'n lijst merk je pas dat de kwaliteit is gezakt wanneer een collega er onderuit gaat bij een klant.

Hoe je verstandig begint

Kies één afgebakende vraagsoort waar nu aantoonbaar tijd in gaat zitten, bijvoorbeeld de vragen die de servicedesk stelt over productdocumentatie, en neem alleen de documenten mee die daarbij horen. Zorg dat elk antwoord een bron toont. Meet een paar weken hoe vaak het antwoord klopte. Pas als dat staat, breid je uit naar een tweede set.

Die volgorde is niet uit voorzichtigheid maar uit ervaring: een RAG-systeem dat op een kleine, opgeruimde set goed werkt, is uit te breiden. Een systeem dat vanaf dag één de hele gedeelde schijf moet dekken, geeft matige antwoorden waarvan niemand meer kan achterhalen waaróm ze matig zijn.

Wil je verder lezen: op standaard AI vs. AI op eigen data staat de vergelijking met een kale chatbot, en op wat is een AI-agent lees je wat er mogelijk wordt zodra een assistent niet alleen kan opzoeken maar ook handelen. Welke pakketten zich laten ontsluiten staat op de koppelingenpagina.