Niet elke kennisbot heeft een vectordatabase nodig: CAG vs RAG in de praktijk

Elke week duik ik diep in een AI-onderwerp en test ik het meteen in de praktijk. Deze week: heb je voor een kennisbot eigenlijk wel een vectordatabase nodig?

Wie een assistent bouwt op eigen documenten krijgt vrijwel altijd RAG aangeraden, voluit retrieval augmented generation: het systeem zoekt bij elke vraag de relevante passages op in een aparte documentendatabase en geeft alleen die aan het taalmodel. Het alternatief heet CAG, cache augmented generation: je laadt de volledige kennisbank vooraf in het werkgeheugen van het model (het contextvenster) en hergebruikt die bij elke volgende vraag via prompt caching.

Ik bouwde dezelfde interne beleidsassistent twee keer · een keer met RAG, een keer met CAG · en liet ze tien dagen lang naast elkaar draaien op identiek verkeer.

Het resultaat was niet wat ik verwachtte.

De setup

De use case was een kennisbot voor een middelgrote klant: ~140 interne beleidsdocumenten, ~280k tokens aan brondata (de tekstblokjes waarin een taalmodel rekent; hier ruwweg 200.000 woorden), plus een laag met FAQ-items. Latency was belangrijk (het is een tool die mensen midden in een gesprek met prospects gebruiken), en accuratesse nog belangrijker (een verkeerd antwoord over commissiebeleid verspreidt zich snel).

De RAG-build was de standaardstack: Voyage embeddings → Pinecone → Cohere reranker → Claude Sonnet voor generatie. In gewone taal: documenten worden als zoekbare getalreeksen (embeddings) in een vectordatabase gezet, een tweede model sorteert de gevonden passages op relevantie, daarna schrijft het taalmodel het antwoord. Vijf pipeline-stappen, zes losse infrastructuuronderdelen, twee SLA's om in de gaten te houden.

De CAG-build was het volledige corpus van 280k tokens, vooraf geladen in het contextvenster van Claude Opus 4.7 met prompt caching aan. Eén pipeline-stap. Eén leverancier. Eén ding dat kapot kan gaan.

Dezelfde vragen, dezelfde evaluator (een aparte Claude-run die scoort tegen een handmatig beoordeelde golden set van 200 vraag-antwoordparen · de vaste meetlat voor elke wijziging), dezelfde tien dagen.

Wat ik verwachtte

Ik verwachtte dat CAG zou winnen op latency en zou verliezen op kosten. Beide intuïties bleken fout.

Wat er echt gebeurde

Na 10 dagen en ~4.200 productiequeries waren dit de cijfers. Daarbij: p50 is de mediaan, p95 de traagste 5 procent, first-token latency de tijd tot het eerste woord verschijnt.

De zeven RAG-incidenten: 3× Pinecone-traagheid, 2× timeout van het embedding-model, 1× foutieve ranking door de reranker, 1× JSON-parsefout.

CAG won in deze test op elke dimensie die ik belangrijk vond. Inclusief kosten · wat ik oprecht niet had verwacht.

De kostenwinst was de grootste verrassing. De intuïtie dat “bij elke query 280k tokens in de context laden vreselijk duur is” bleek onjuist dankzij prompt caching. Voor het eerste verzoek betaalde ik de volledige tokenprijs. Voor elk volgend verzoek binnen het cachevenster ongeveer 10% daarvan. Bij aanhoudend verkeer kelderden de gemiddelde kosten per query. Kanttekening: die verhouding en de cacheduur verschillen per aanbieder en veranderen geregeld; reken het na voor je eigen stack.

De accuratessewinst heeft een saaiere verklaring: de RAG-retriever zat er soms naast. Hij haalde het verkeerde beleidsdocument op, of te weinig chunks, of sneed dwars door een alineagrens en verloor daarmee de helft van het antwoord. Elke misser bij retrieval is een gegarandeerd fout antwoord. Als je retrieval overslaat, sla je die faalmodi ook over.

Waar het misging

Lees het bovenstaande niet als “kies altijd voor CAG”. Ik probeerde het bewust kapot te maken om de valkuilen te vinden.

Scenario 1 · voorbij het contextvenster duwen. Ik voegde het corpus van een andere klant toe (180k tokens) bovenop het eerste, totaal ~460k tokens. Nog steeds binnen het venster van Opus 4.7. De accuratesse op de originele golden set daalde van 94,5% naar 89,2%. Het model had last van lost-in-the-middle: antwoorden die zich op ongeveer twee derde van de context bevonden, waren stelselmatig minder accuraat dan antwoorden in de eerste of laatste 50k tokens. RAG haalde in dit scenario 87,1% accuratesse, omdat het model alleen de relevante 8k tokens kreeg aangeleverd.

Scenario 2 · onregelmatig, laagvolumig verkeer. Ik testte een use case met ~12 queries/uur en lange pauzes tussen de pieken. De cache verviel telkens tussen de verzoeken door. De effectieve kosten per query stegen naar $0,0038 · nog steeds goedkoper dan RAG, maar slechts marginaal. De kosteneconomie van CAG staat of valt met aanhoudend verkeer dat de cache warm houdt.

Scenario 3 · het corpus verandert dagelijks. Ik simuleerde elke zes uur een herziening van een beleidsdocument. Elke herziening vereiste het opnieuw opwarmen van de cache, wat ongeveer evenveel kost als een enkele niet-gecachete query. Bij één herziening per zes uur is dat te doen. Bij één herziening per 30 minuten overtrof de opwarmkost de besparing per query. RAG embedt gewoon het gewijzigde document opnieuw en gaat verder.

Scenario 4 · toegangscontrole voor meerdere tenants. Verschillende gebruikers zien verschillende subsets van het corpus. CAG kan de context niet gemakkelijk per gebruiker opsplitsen zonder opnieuw op te warmen, wat de kosteneconomie om zeep helpt. RAG handhaaft toegang op rijniveau moeiteloos in de retrieval-stap. Voor multi-tenant SaaS blijft RAG de schonere architectuur.

Wanneer CAG echt wint

Samengevat blijft er een duidelijk kader over:

• Totaal corpus ruim onder ~500k tokens · de praktische sweet spot, ruim onder de limiet van 1M, waar lost-in-the-middle nog niet optreedt.
• Aanhoudend queryvolume · op zijn minst een query per paar minuten, idealiter tientallen per minuut.
• Updatetempo in dagen of weken, niet uren.
• Eén tenant, of een kleine vaste set tenants waarbij cache-per-tenant haalbaar is.
• Accuratesse die je daadwerkelijk kunt meten en waar je om geeft · de winst ten opzichte van RAG is reëel, maar je ziet hem alleen als je ook echt evalueert.

Binnen dat kader was CAG in mijn test op alle fronten de betere keuze: lagere latency, hogere accuratesse, lagere kosten, minder bewegende onderdelen. Mijn inschatting: dat is geen toevalstreffer, maar een structureel voordeel van de eenvoudigere architectuur.

Buiten dat kader blijft RAG de juiste keuze.

Het hybride patroon dat het beste werkte

Het interessantste resultaat kwam niet uit het kiezen van de ene aanpak boven de andere, maar uit het combineren van beide.

Voor mijn tweede klant bouwde ik een hybride oplossing: elke query gaat eerst langs het CAG-pad. Het model beoordeelt zelf of het gecachete corpus het antwoord bevat. Zo ja, dan antwoordt het direct. Zo nee, dan valt het systeem terug op een RAG-retriever gericht op een veel groter archief (legacy contracten, historische FAQ, supporttickets · miljoenen tokens, niets daarvan warm).

CAG verwerkte 78% van de queries via het warme pad. RAG nam de long tail van 22% voor zijn rekening. De gemiddelde latency kwam uit op 690ms, omdat de long tail maar een klein deel van het totale volume is. De accuratesse op de gecombineerde golden set haalde 96,1% · beter dan beide aanpakken afzonderlijk, omdat elk systeem de vragen behandelde waarvoor het het meest geschikt was.

Dit is de architectuur die ik in productie zou uitrollen voor elk kennisproduct waarvan het corpus zowel een “kern” als een “long tail” heeft. Het is geen compromis. Het is specialisatie.

Voor wie is dit nu interessant?

Veel Nederlandse organisaties zitten precies in de zone waar CAG sterk is. Een personeelshandboek, productdocumentatie, offerte- en commissiebeleid, een support-FAQ: dat past bij een mkb-bedrijf vrijwel altijd ruim binnen die ~500k tokens. Een vectordatabase-project optuigen is daarvoor vaak zwaarder dan nodig.

CAG is nu het overwegen waard als je één afgebakende kennisbank hebt, verkeer dat de cache warm houdt (denk aan een salesteam dat er de hele dag vragen aan stelt) en een updatetempo in dagen of weken. Nog niet als je multi-tenant SaaS draait, als je corpus meerdere keren per dag verandert, of als je archief in de miljoenen tokens loopt. Daar blijft RAG of het hybride patroon de schonere keuze. De realistische eerste stap is geen infraproject maar een middag testen; hoe, staat hieronder.

Drie vragen om de beslissing te toetsen

Als teams mij vragen wat ze moeten kiezen, laat ik ze drie vragen doorlopen:

1. Past je volledige warme corpus in ruwweg 500k tokens, met speling? Zo ja, dan is CAG een optie. Als je nu al tegen het contextvenster aanloopt, begin er dan niet aan.
2. Blijft de cache warm? Als je verkeer aanhoudend en voorspelbaar is, ja. Als het onregelmatig of seizoensgebonden is, wint de per-query-kostprijs van RAG.
3. Hoe vaak verandert het corpus? Wekelijks of trager → CAG. Meerdere keren per dag → RAG. Ergens daartussenin → hybride.

Wat ik klanten nu vertel

De meeste teams kiezen standaard voor RAG omdat de tutorials standaard voor RAG kiezen. De infracategorie · vectordatabases, rerankers, embedding pipelines · heeft de sector jarenlang het beeld gegeven dat retrieval altijd noodzakelijk is. Mijn inschatting na deze test: voor kennisbanken die ruim binnen het contextvenster passen, is retrieval vaak een omweg.

Als je naar een corpus van 200k–500k tokens kijkt en meteen naar Pinecone grijpt, stop dan. Probeer eerst het eenvoudigere alternatief. Laad het hele corpus in een long-context model met prompt caching ingeschakeld. Meet latency, kosten en accuratesse op een echte golden set, niet op een synthetische.

Misschien ontdek je · net als ik · dat de architectuur die je al kent de verkeerde is voor het systeem dat je eigenlijk probeert te bouwen.

De vraag was nooit wie er wint, maar wat jouw specifieke use case daadwerkelijk nodig heeft.