Als je de afgelopen twee jaar iets over AI hebt gelezen, is de kans groot dat je het woord RAG bent tegengekomen. Retrieval-Augmented Generation. Het klinkt alsof je bedrijf het nodig heeft. Consultants verkopen het als standaardoplossing. Ontwikkelaars bouwen het als standaardantwoord.
Ik heb RAG gebouwd in meerdere projecten. Ik heb het ook bewust uit een project verwijderd en vervangen door een eenvoudigere aanpak die accurater bleek. In dit artikel leg ik uit wat RAG precies is, wanneer het zinvol is, en wanneer je beter kiest voor CAG of een simpele indexed aanpak.
Wat is RAG precies?
RAG staat voor Retrieval-Augmented Generation. Het idee is eenvoudig: een taalmodel weet niet wat er in jouw bedrijfsdocumenten staat, maar als je de juiste stukken tekst bij elke vraag meestuurt, kan het er wel over redeneren.
De implementatie is minder eenvoudig.
Een RAG-systeem bestaat uit drie losse onderdelen die allemaal correct moeten functioneren:
1. Embeddings model Alle documenten worden omgezet naar numerieke vectoren: lange reeksen getallen die de betekenis van een stuk tekst vastleggen. Dit kost rekenkracht en geld, en moet opnieuw worden gedaan als de documenten veranderen.
2. Vector database De vectoren worden opgeslagen in een speciale database (Pinecone, Weaviate, pgvector en andere). Bij elke vraag zoekt het systeem in die database naar de vectoren die het meest lijken op de vraag. Dat heet semantic search.
3. Reranker (optioneel maar bijna altijd nodig) De eerste retrieval-stap haalt de meest vergelijkbare tekststukken op, maar vergelijkbaar is niet hetzelfde als relevant. Een reranker beoordeelt de resultaten opnieuw en sorteert ze op daadwerkelijke relevantie. Zonder reranker zijn RAG-systemen aanzienlijk minder nauwkeurig.
Dit alles bij elkaar is een systeem met meerdere faalplekken, hogere kosten en meer onderhoud dan de meeste bedrijven verwachten.
Wanneer RAG zinvol is
RAG heeft zijn plek. Maar die plek is specifieker dan de hype doet vermoeden.
RAG werkt goed wanneer:
- Je duizenden documenten hebt die niet allemaal tegelijk in een contextvenster passen
- Je database continu groeit met nieuwe informatie (klanttickets, kennisartikelen, rapporten)
- De documenten ongestructureerd zijn en niet vooraf samengevat kunnen worden
- Je een hoge latency acceptabel vindt, want retrieval voegt tijd toe
Een praktisch voorbeeld: een groot bedrijf met 10.000 interne kennisartikelen, die wekelijks worden bijgewerkt. Daar is RAG het juiste gereedschap.
Waarom RAG bij de meeste bedrijven niet werkt
Het probleem met RAG is niet de techniek zelf. Het probleem is de mismatch: de meeste bedrijven die RAG willen implementeren hebben geen 10.000 documenten. Ze hebben misschien 50 tot 300 relevante documenten.
Bij kleinere databases doet RAG iets onverwachts: het wordt minder accuraat dan eenvoudigere alternatieven.
Hoe dat kan? Semantic search is erg goed in het vinden van tekst die lijkt op de vraag. Maar bedrijfsdocumenten zijn zelden zo gestructureerd dat de meest relevante passage ook de meest semantisch vergelijkbare is. Een medewerker die vraagt "wat is onze marge op type B-opdrachten?" krijgt mogelijk tekst terug over marges in het algemeen, niet het specifieke document met het juiste antwoord.
Bovendien:
- Hogere kosten: embeddings genereren, vector database hosten en reranker draaien telt op
- Meer onderhoud: als documenten veranderen moeten embeddings opnieuw worden gegenereerd
- Lastiger te debuggen: als het antwoord fout is, weet je niet of het retrievalprobleem, een slechte embedding of het taalmodel de oorzaak is
Ik heb dit meegemaakt in een project waarbij ik een RAG-systeem had gebouwd voor een bedrijf met een behapbare set interne documenten. De retrieval miste regelmatig het juiste document. Na overstap naar een eenvoudiger aanpak, verbeterde de accuraatheid direct.
CAG: het alternatief dat de meeste bedrijven nodig hebben
CAG staat voor Context Augmented Generation. Het idee is nog eenvoudiger dan RAG: in plaats van bij elke vraag te zoeken welke stukken tekst relevant zijn, stuur je gewoon de relevante context direct mee.
Dat klinkt bijna te simpel. Maar moderne taalmodellen kunnen grote hoeveelheden tekst tegelijk verwerken. De nieuwste modellen van Anthropic (Claude Opus 4.8) en OpenAI (GPT-5.5) hebben een contextvenster van 1 miljoen tokens: ruwweg 750.000 woorden, ofwel zo'n tien gemiddelde romans. Dat is ruim voldoende voor vrijwel elke bedrijfsdocumentset.
Een kanttekening die erbij hoort: een groot contextvenster betekent niet dat je het ook altijd volledig moet vullen. Modellen presteren slechter op informatie die ver van het begin of einde van de context staat, een fenomeen dat "lost in the middle" wordt genoemd. Voor een beperkte, goed gestructureerde kennisbase is dat zelden een probleem. Bij tientallen megabytes aan ruwe documenten wel.
CAG werkt goed wanneer:
- Je database overzichtelijk is (tot een paar honderd documenten of samengevatte versies)
- De informatie relatief stabiel is en niet dagelijks verandert
- Je hoge nauwkeurigheid nodig hebt, want het model ziet alle relevante context in één keer
- Je eenvoud wilt in onderhoud: geen vector database, geen embeddings pipeline
Het nadeel: grotere invoerkosten per vraag, want je stuurt meer tekst mee. Maar die kosten zijn bij normale gebruikspatronen lager dan de infrastructuurkosten van een volledig RAG-systeem.
LLM wiki: een gestructureerde tussenvorm
Een derde aanpak die ik gebruik voor bedrijven met een iets grotere kennisbase is de LLM wiki of gestructureerde index.
Het idee: in plaats van ruwe documenten in een vector database te stoppen, maak je een gestructureerde samenvatting van alle kennis in een vaste indeling. Denk aan een intern wiki-systeem waarbij elk onderwerp een duidelijke structuur heeft (definitie, uitleg, uitzonderingen, voorbeelden).
Bij elke vraag zoekt het systeem via een eenvoudige keyword- of categoriezoekactie de juiste wiki-entries op en stuurt die mee als context.
Dit combineert het beste van beide werelden: geen zware retrieval-infrastructuur nodig, maar toch selectieve context in plaats van alles tegelijk meesturen. De structuur helpt het model ook beter redeneren, want goed gestructureerde informatie is makkelijker te gebruiken dan ruwe documenten.
Wanneer kies je wat?
| Situatie | Beste aanpak |
|---|---|
| Minder dan 300 documenten, stabiele content | CAG |
| 300-2000 documenten, gestructureerd samen te vatten | LLM wiki |
| Duizenden documenten, continu groeiend | RAG |
| Ongestructureerde data, hoge zoekprecisie vereist | RAG met reranker |
De vuistregel: begin met CAG. Schaal naar een LLM wiki als de context te groot wordt. Kies pas voor RAG als de schaal het echt vereist, niet omdat het indrukwekkend klinkt.
Wat je meeneemt
RAG is geen slechte techniek. Het is gewoon geen universeel antwoord. Voor de meeste MKB-bedrijven met een behapbare kennisbase is CAG nauwkeuriger, goedkoper en eenvoudiger te onderhouden.
De vraag die je moet stellen is niet "hoe bouwen we RAG?" maar "hoeveel documenten hebben we, hoe snel groeien ze, en wat heeft het minste faalplekken?"
Als je die vraag stelt, kies je in de meeste gevallen voor iets anders dan RAG.
Wil je weten welke aanpak past bij de data die jouw bedrijf heeft? Lees meer over een interne kennisbank met AI of neem direct contact op voor een vrijblijvend gesprek.
Stan Westenbrink bouwt AI-systemen en automatiseringen voor bedrijven in Nederland. Gevestigd in Groningen, actief door heel Noord-Nederland.
Veelgestelde vragen
Wat is het verschil tussen RAG en CAG? RAG haalt bij elke vraag relevante stukken tekst op uit een vector database. CAG stuurt de relevante context direct mee als input aan het taalmodel, zonder retrieval-stap. CAG is eenvoudiger en nauwkeuriger bij kleinere documentsets; RAG schaalt beter bij duizenden documenten.
Wanneer is RAG de juiste keuze? RAG is zinvol bij duizenden documenten die continu groeien en niet in één contextvenster passen. Bij honderden documenten of minder is RAG doorgaans minder accuraat en duurder dan alternatieven.
Wat heeft een RAG-systeem nodig? Een werkend RAG-systeem vereist minimaal een embedding model om documenten om te zetten naar vectoren, een vector database om die vectoren op te slaan, en een retrieval-stap bij elke zoekvraag. Voor goede nauwkeurigheid is ook een reranker nodig.
Is RAG duur om te gebruiken? Dat hangt af van de schaal. Een kleine RAG-implementatie kost een paar euro per maand. Maar bij actief gebruik tellen de kosten op: embedding-generatie, vector database hosting en extra API-aanroepen voor retrieval. Voor kleine databases zijn deze kosten zelden gerechtvaardigd.