“AI met je eigen data” heet meestal RAG
Zodra een bedrijf een AI wil die zijn eigen handleidingen, contracten of tickets kent, valt al snel het woord RAG: retrieval-augmented generation. Het staat op elke AI-conferentie en in elke salespitch over “een chatbot op jullie documenten”. Net als AI agents klinkt het groot, terwijl de techniek erachter goed te volgen is.
De aanleiding is een bekend probleem. Een LLM weet ontzettend veel over de wereld in het algemeen en helemaal niets over jouw bedrijf. Vraag ChatGPT naar je eigen prijslijst, je leveringsvoorwaarden of de status van order 4815 en hij kan twee dingen doen: zeggen dat hij het niet weet, of een plausibel antwoord verzinnen. Geen van beide kun je aan een klant laten zien.
Een LLM heeft de halve wereld gelezen en jouw intranet nooit. RAG is de simpelste manier om dat recht te zetten: laat hem de bron erbij pakken voordat hij antwoordt.
RAG lost dit op zonder het model aan te raken. Je traint niets opnieuw. Je geeft het model op het moment van de vraag de juiste stukken uit jouw data mee, en laat het daaruit antwoorden.
Retrieval, augmented, generation: drie stappen
De naam is letterlijk de uitleg. RAG doet drie dingen op een rij.
Retrieval (ophalen)
Bij een vraag zoekt het systeem eerst in jouw bronnen naar de stukken tekst die er het meest toe doen: de paar passages die het antwoord bevatten, in plaats van het hele archief.
Augmented (aanvullen)
Die opgehaalde stukken plakt het systeem bij de vraag in de prompt. Het model krijgt dus de vraag én de relevante bron in één keer voorgeschoteld.
Generation (genereren)
Het LLM schrijft het antwoord uit de meegegeven bron, in plaats van uit zijn eigen geheugen. De stof staat er net bij, het model verwoordt het netjes.
De vergelijking die het meteen duidelijk maakt: een open-boek-examen. Zonder RAG laat je het model het tentamen uit zijn hoofd maken en hoop je dat het de stof nog weet. Met RAG leg je precies de juiste bladzijde voor zijn neus en vraag je het antwoord daaruit te halen. Het model wordt er niet slimmer van. Het krijgt op het juiste moment het juiste materiaal bij de hand.
Zonder RAG vraag je het model het uit zijn hoofd te doen. Met RAG schuif je de juiste bladzijde onder zijn neus. Dezelfde AI, een heel ander betrouwbaarheidsniveau.
Hoe het ophalen werkt: embeddings en de vectorstore
De magie zit in stap één. Hoe vindt een systeem in duizenden pagina’s de drie passages die bij een vraag horen? Een gewone zoekopdracht op trefwoorden schiet tekort, want de klant typt zelden exact de woorden die in jouw document staan. RAG zoekt daarom op betekenis, en dat gaat via embeddings.
Een embedding is een stuk tekst vertaald naar een rij getallen die de betekenis vastlegt. Teksten die over hetzelfde gaan, krijgen getallen die dicht bij elkaar liggen, ook als er compleet andere woorden in staan. “Hoe zeg ik mijn abonnement op” en “opzeggen contract” belanden zo naast elkaar, zonder één gedeeld trefwoord. Die getallenrijen bewaar je in een vectordatabase, gemaakt om snel te vinden wat het dichtst bij elkaar ligt.
Knippen in stukken
Je documenten worden opgedeeld in hapklare brokken, een paar alinea's per stuk. Te grof en je haalt ruis op, te fijn en de context valt weg. Dit knippen bepaalt meer aan de kwaliteit dan mensen denken.
Omzetten naar embeddings
Elk brok gaat door een embedding-model en wordt een getallenrij die de betekenis vangt. Eenmalig vooraf, en opnieuw zodra een document verandert.
Opslaan in een vectorstore
Alle getallenrijen komen in een vectordatabase. Die is gebouwd om razendsnel de brokken te vinden die het dichtst bij een vraag liggen.
Zoeken bij de vraag
De vraag van de klant wordt op dezelfde manier een getallenrij. Het systeem pakt de paar brokken die er het dichtst bij liggen en geeft die aan het model mee.
De eerste drie stappen doe je vooraf, één keer, en je werkt ze bij als je data verandert. De vierde gebeurt live bij elke vraag. Dat is het hele mechanisme. Geen bewustzijn, geen model dat “jouw bedrijf leert kennen”, gewoon slim zoeken op betekenis met een LLM erachter dat de gevonden tekst netjes verwoordt.
RAG of het model fine-tunen?
Dit is de vraag die het vaakst verkeerd valt. Als je wilt dat een AI jouw data kent, lijkt “train het model erop” de logische route. Voor bijna alle gevallen is dat het verkeerde gereedschap. Fine-tunen en RAG lossen verschillende problemen op.
RAG geeft het model kennis
Wil je dat de AI jouw feiten, documenten en actuele cijfers kent? Dat is RAG. Je voegt of vervangt een document en het antwoord klopt meteen, zonder iets te hertrainen.
Fine-tunen verandert gedrag
Wil je dat de AI een vaste toon, structuur of taal aanhoudt, of een heel specifiek soort taak leert? Dat is fine-tunen. Je verschuift de manier waarop het model antwoordt; de feiten die het paraat heeft, blijven hetzelfde.
Het verschil zit in vers versus vast. RAG haalt de bron op het moment zelf op, dus actuele data is een kwestie van het document bijwerken. Een fine-getuned model heeft de stof op trainingsmoment ingebakken en loopt achter zodra je prijzen of voorwaarden veranderen. Voor “de AI moet onze kennis kennen” is RAG daarom bijna altijd het startpunt, en fine-tunen iets dat je er pas later eventueel bovenop legt.
Fine-tunen leert het model een vak. RAG geeft het de juiste map erbij. De meeste bedrijven denken dat ze het eerste nodig hebben en zoeken eigenlijk het tweede.
Waar RAG misgaat: het ophalen is alles
RAG klinkt eenvoudig en een demo bouw je in een middag. Het verschil tussen die demo en een systeem waar je klanten op vertrouwen, zit volledig in de retrieval. Haalt stap één de verkeerde brokken op, dan schrijft het model een vloeiend, overtuigend en fout antwoord. Het model is zo goed als wat je het voert.
Slecht geknipt
Brokken die een tabel of een zin doormidden hakken, leveren context op die half klopt. De helft van de RAG-problemen in de praktijk is eigenlijk een knipprobleem.
Verouderde index
De vectorstore loopt achter op je echte documenten. Het model haalt zelfverzekerd het beleid van vorig jaar op. Bijwerken is een doorlopende klus, geen eenmalige import.
Te veel of te weinig opgehaald
Te weinig brokken en het antwoord mist context. Te veel en de echte passage verzuipt in ruis, waardoor het model alsnog de mist in gaat.
Geen manier om kwaliteit te meten
Zonder een vaste set testvragen weet je niet of een aanpassing de antwoorden beter of slechter maakt. Meten hoort bij RAG, anders stuur je blind.
Daarom is een goede bronvermelding zo belangrijk: een serieus RAG-systeem laat zien uit welk document een antwoord komt, zodat een mens het kan nakijken. Dat is precies het verschil met een kale LLM die overtuigend gokt. De engineering zit in het ophalen betrouwbaar maken en houden, en dat is waar wij voor klanten het echte werk doen.
Een demo overtuigt iedereen. De echte vraag is of je systeem na een jaar nog de juiste bron ophaalt, terwijl je documenten elke week veranderen.
RAG, knowledge graphs en agents
RAG staat zelden op zichzelf. Het is een bouwsteen in het grotere AI-landschap waar we eerder over schreven.
Klassieke RAG zoekt in een vectorstore naar losse tekstfragmenten die op de vraag lijken. Dat werkt prima zolang het antwoord in één passage staat. Zit het verspreid over meerdere, met elkaar verbonden feiten, dan loopt die aanpak vast en kom je uit bij GraphRAG en knowledge graphs: daar volgt het systeem de relaties tussen feiten in plaats van losse stukjes tekst. In de praktijk combineer je ze: vectorzoeken om snel een ingang te vinden, de graph om vandaar de verbanden uit te breiden.
En in een agentic workflow is RAG simpelweg een van de tools die een AI agent kan aanroepen. Waar de ene tool een mail stuurt en de andere een ticket aanmaakt, beantwoordt de RAG-tool de vraag “wat staat hierover in onze eigen documenten?” De agent haalt het feit op het moment dat hij het nodig heeft, gebruikt het in zijn volgende stap en houdt zo zijn antwoorden gegrond.
Wanneer RAG loont
RAG verdient zich terug zodra het juiste antwoord in jouw tekst staat en het model er alleen bij moet kunnen. De vuistregel draait om waar de kennis zit.
Kies RAG
Je hebt een hoop eigen tekst die ertoe doet: handleidingen, beleid, contracten, een kennisbank, supporttickets. En je wilt dat de AI daaruit antwoordt, met een bron erbij, ook als die documenten morgen veranderen.
RAG is overbodig
Het antwoord zit al in algemene kennis die het model toch al heeft, of je vraag heeft helemaal geen brondocument nodig. Dan voegt een ophaalstap alleen complexiteit toe.
Begin ook hier zo simpel mogelijk. Een goede chunking-strategie en een nette bronvermelding brengen je verder dan de nieuwste vectordatabase. Elke laag die je toevoegt, is er ook één die je moet bouwen, meten en bijhouden.
Conclusie: laat het model opzoeken in plaats van gokken
RAG wordt begrijpelijk zodra je het ziet als een open-boek-examen voor een AI. Je zoekt de relevante stukken uit jouw data op, geeft ze aan het model mee en laat het daaruit antwoorden. Het model wordt er niet slimmer van. Het krijgt op het juiste moment het juiste materiaal bij de hand.
Ophalen, aanvullen, genereren
Zoek de relevante brokken uit jouw bronnen, plak ze bij de vraag en laat het model daaruit antwoorden. Drie stappen, geen magie.
Jouw data zonder hertraining
Het model blijft ongemoeid. Je werkt een document bij en het antwoord klopt meteen, met een bron die je kunt nakijken.
De winst zit in het ophalen
Knippen, bijwerken en meten maken het verschil tussen een leuke demo en een systeem waar je klanten op kunnen vertrouwen.
Begin klein, zorg dat het ophalen klopt en geef je AI een bron om uit te putten. Dan stopt hij met overtuigend gokken en begint hij met opzoeken.
Wat is RAG?
Hoe werkt RAG technisch?
Wat is het verschil tussen RAG en fine-tunen?
Waarom hallucineert een LLM minder met RAG?
Wat is het verschil tussen RAG en GraphRAG?
Wanneer heb ik RAG nodig?
Een AI die jouw eigen documenten kent?
Wij bouwen de laag onder een betrouwbaar RAG-systeem: het knippen, de embeddings, de bronvermelding en de meting die het ophalen scherp houden terwijl jouw data verandert. Van eerste opzet tot beheer.
