RAG — Retrieval Augmented Generation uitgelegd

Er is een probleem dat iedereen tegenkomt zodra ze serieus met LLMs gaan werken: het model weet niet wat jij weet.

Het heeft zijn trainingsdata — een brede maar verouderde snapshot van de wereld. Het heeft de context die jij hem geeft in de chat. Dat is het. Alles buiten die twee bronnen bestaat voor het model niet.

RAG is de oplossing voor dat probleem.

Wat RAG is

RAG staat voor Retrieval Augmented Generation. Het idee: voordat het model een antwoord genereert, zoek je relevante documenten op en voeg je die toe aan de context. Het model genereert op basis van die aangevulde input.

In plaats van het model te vragen "wat staat er in ons HR-handboek over verlofaanvragen?" en hopen dat het iets uit zijn trainingsdata haalt dat klopt, stuur je letterlijk de relevante paragraaf uit het handboek mee, en vraag je hem dat te beantwoorden.

Het model hallucineert minder, het antwoord is specifieker, en je hoeft niets in het model te trainen.

Hoe het technisch werkt

Drie stappen.

Indexeren: je breekt documenten op in stukken (chunks), zet die om naar wiskundige vectoren (embeddings), en slaat ze op in een vectordatabase. Die vectoren zijn representaties van de betekenis van de tekst — niet de letters, maar de inhoud.

Ophalen: als er een vraag binnenkomt, zet je die ook om naar een vector en zoek je naar de chunks die er het meest op lijken. Je haalt de meest relevante stukken op.

Genereren: je voegt de opgehaalde chunks samen met de vraag aan het model. Het model genereert een antwoord op basis van die gecombineerde input.

Het resultaat: het model heeft toegang tot informatie die buiten zijn trainingsdata valt, zonder dat je het opnieuw hoeft te trainen.

Wanneer je het gebruikt

RAG is de juiste keuze als je een grote hoeveelheid eigen documenten hebt, als de informatie vertrouwelijk is en niet in trainingsdata mag, als de informatie regelmatig verandert, of als je wil weten welk document een antwoord heeft geïnformeerd.

Je hebt het niet nodig als de context klein genoeg is om gewoon in de prompt te stoppen, of als het gaat om breed bekende informatie die al in het model zit.

Fine-tuning versus RAG

De vraag die altijd opkomt: waarom niet gewoon het model fine-tunen op mijn documenten?

Fine-tuning past de gewichten van het model aan. Het model leert patronen en stijl, en tot op zekere hoogte feiten — maar voor dynamische of specifieke domeinkennis is dat minder betrouwbaar dan RAG. Fine-tuning is ook duur, traag, en niet transparant: je kunt niet zien welk document een antwoord heeft geïnformeerd.

RAG is sneller, goedkoper, en traceerbaar. Als het antwoord fout is, kun je de bronchunks bekijken.

Fine-tuning is nuttig als je gedrag of stijl wil aanpassen. Voor domeinkennis die verandert of controleerbaar moet zijn: RAG.

Wat ik er zelf mee doe

Mijn LLM-wiki is een primitieve RAG-implementatie. Claude Code leest de relevante index-bestanden en pagina's als ik een vraag stel. Geen vectordatabase, maar hetzelfde principe: relevante context ophalen en aan het model geven voordat het antwoord genereert.

claude-mem gaat een stap verder. Observaties worden geïndexeerd en semantisch doorzocht. Als ik een vraag stel, zoekt de server naar relevante observaties en injecteert die in de context. Dat is RAG met een echte retrieval-stap.

Het verschil in kwaliteit is merkbaar. Een model met goede context geeft betere antwoorden dan een model dat gist op basis van trainingsdata.

Waar het wringt

RAG lost het hallucinatieprobleem niet op. Als de opgehaalde chunks de vraag niet goed dekken, improviseert het model toch. Chunk-kwaliteit en retrieval-precisie bepalen hoeveel je het systeem kunt vertrouwen.

Een RAG-systeem bouwen is relatief eenvoudig. Een RAG-systeem bouwen dat consequent de goede dingen ophaalt, is engineering.