Voor wie is dit artikel?Voor wie de term “RAG” steeds tegenkomt en eindelijk wil snappen wat het is. Korter en concreter dan een technische deep dive. Wil je daarnabouwenmet RAG, ga dan door naar onze diepereRAG-uitleg met implementatie.
Bedrijven die in 2026 AI bouwen op eigen data komen op een gegeven moment hetzelfde woord tegen: RAG. Het staat overal in de tooling, in de tutorials, in vacatures voor AI-engineers. En het is geen marketinghype — RAG is de standaardmanier geworden om een taalmodel met jouw data te laten werken. Maar wat ís het?
De korte versie
RAG staat voor Retrieval-Augmented Generation. Drie woorden, één idee: een AI eerst relevante informatie laten retrieven (ophalen) uit een externe bron, en pas dán laten generen (een antwoord schrijven). Je geeft het model context die het van zichzelf niet kent, en daarmee veel betere antwoorden krijgt.
Vergelijk het met een collega die je vraagt naar het boekingsbeleid van jullie hotel. Zonder RAG: hij verzint iets plausibels op basis van algemene kennis van hotels. Met RAG: hij pakt eerst het beleidsdocument, leest de drie relevante alinea’s, en formuleert dan zijn antwoord op basis daarvan. Het tweede is wat je wil — en RAG maakt dat mogelijk voor een AI.
Waarom RAG bestaat
Taalmodellen zoals Claude, ChatGPT en Gemini zijn getraind op een momentopname van het publieke internet. Ze weten heel veel, maar:
- ze kennen jouw bedrijfsinhoud niet,
- hun kennis stopt op een bepaalde datum (de “knowledge cutoff”),
- ze hebben geen toegang tot interne afspraken, contracten of klantdossiers,
- ze kunnen niet uitleggen waar hun antwoord vandaan komt.
Voor een chat-assistent op het gewone web zijn die beperkingen acceptabel. Voor een AI die jouw eigen klanten of medewerkers helpt — niet. RAG lost het op zonder dat je het model zelf hoeft te hertrainen.
Beginner-tip:Als je nog nooit met een AI-API hebt gewerkt: lees eerstClaude voor beginnersom een gevoel te krijgen van hoe je tegen zo’n model praat. RAG is een uitbreiding daarop, geen aparte technologie.
Hoe werkt RAG in drie stappen
Stap 1 — Indexeren
Je documenten (PDF’s, Word-bestanden, intranet-pagina’s, klantgesprekken) worden geknipt in kleinere stukjes — chunks van bijvoorbeeld 500 tot 1.500 tokens elk. Voor elke chunk maakt een embedding-model een numerieke vector — een soort vingerafdruk van de betekenis. Die vectoren komen in een vector-database zoals pgvector, Pinecone of Qdrant.
Stap 2 — Ophalen
Iemand stelt een vraag. Die vraag wordt door hetzelfde embedding-model omgezet in een vector. De vector-database zoekt de fragmenten waarvan de vector het dichtst bij die van de vraag ligt — meestal de top-3 tot top-10.
Stap 3 — Genereren
Die fragmenten worden samen met de oorspronkelijke vraag in de prompt voor het taalmodel gestopt:
Beantwoord deze vraag op basis van de onderstaande fragmenten.
Vraag: <vraag van de gebruiker>
Fragmenten:
1. <fragment uit document A>
2. <fragment uit document B>
3. <fragment uit document C>
Het model formuleert het antwoord, en idealiter vermeldt het ook uit welke bronnen het put. Dat laatste is voor compliance vaak doorslaggevend.
De drie sterke kanten van RAG
- Goedkoper dan fine-tunen. Een model fine-tunen kost duizenden euro’s per ronde en moet bij elke datawijziging opnieuw. RAG werkt met een ongewijzigd model — je update alleen de indexed documenten.
- Bronnen zijn controleerbaar. Het model citeert waaruit het put. Bij fine-tuning verdwijnt kennis “in het model” en kun je niet meer terugvinden waarom het iets zei.
- Werkt direct op verse data. Voeg een document toe → re-index → het antwoord weet erover. Geen training, geen wachttijd.
Gevorderden:De kwaliteit van een RAG-systeem staat of valt met de chunking-strategie en het embedding-model. Te kleine chunks = context weg, te grote = irrelevante tekst in de prompt. Voor Nederlandse content levert het multilingual model van Cohere of
text-embedding-3-largevan OpenAI in 2026 de beste retrieval-precisie op redelijke kosten. Hybrid search (keyword + vector) verhoogt accuracy nog eens 15–20%.
Wanneer je RAG (nog) niet nodig hebt
Drie scenario’s waarin je het beter overslaat:
- Generieke chat-assistenten die geen toegang tot interne data nodig hebben — een gewoon LLM-call is sneller en goedkoper.
- Hoge-frequentie productieworkloads met een compacte vaste kennisbasis — fine-tunen of in-context-prompting kan voordeliger uitkomen.
- Documenten met sterk verspreide referenties (lange juridische contracten waar de relevante alinea afhangt van een verwijzing 200 pagina’s verder) — daar werkt agentic search of een eigen hybride structuur vaak beter dan klassieke RAG.
Waar dit naartoe beweegt
In 2026 zien we drie trends. Eén: Files & Skills in Claude — Anthropic levert nu out-of-the-box retrieval over bijgevoegde bestanden, waardoor kleinere RAG-use-cases zonder eigen vector-DB kunnen. Twee: agentic retrieval — Claude of GPT die zelf bepaalt welke bron te raadplegen (wat agents zijn en wanneer je ze gebruikt helpt om dat te plaatsen). Drie: kleine lokale modellen + RAG als privacy-vriendelijk alternatief — combineer een lokaal taalmodel via Ollama met een lokale vector-DB en je hebt een AI-assistent die nooit data het pand uitstuurt.
Voor wie zelf wil bouwen: onze tutorial AI-agent bouwen in een weekend gebruikt RAG in een tweede fase, en Karpathy’s persoonlijke kennisbasis-idee laat zien hoe je RAG persoonlijk inzet.
Samenvatting — de 5-minuten-versie
- RAG = Retrieval-Augmented Generation: eerst documenten doorzoeken, dán laten antwoorden.
- Drie stappen: indexeren (chunks → embeddings → vector-DB), ophalen (top-N relevante fragmenten), genereren (LLM krijgt vraag + fragmenten).
- Voordelen: goedkoper dan fine-tunen, bronnen controleerbaar, werkt direct op verse data.
- Geen wondermiddel: voor creatieve generatie en hoge-frequentie compact-kennis-vragen niet de beste keuze.
- 2026-trends: built-in retrieval in Claude, agentic retrieval, en RAG op lokale modellen voor privacy-toepassingen.
Bronnen
- Anthropic Claude — Files & Skills documentatie — built-in retrieval-capabilities
- pgvector: open-source vector-extensie voor Postgres — meest gebruikte vector-DB in 2026
- OpenAI embeddings overzicht — text-embedding-3 family, multilingual support
- Cohere multilingual embeddings — sterke optie voor Nederlandse documenten
- Onze eigen Hoe RAG werkt — technische deep dive — voor wie de uitleg hier wil uitdiepen