Wat is RAG en wanneer heeft je bedrijf het nodig?

Is je hele kennisbank kleiner dan 200.000 tokens, ongeveer 500 pagina's tekst, dan raadt Anthropic aan om er geen RAG voor te bouwen maar alles gewoon in de prompt te zetten (Anthropic, contextual retrieval, 2024).

Dat is een ongebruikelijk advies van een partij die aan RAG-projecten verdient. Het is ook het juiste startpunt voor de vraag op deze pagina: RAG is een oplossing voor een schaalprobleem, niet een verplicht onderdeel van elke AI-toepassing.

Hieronder staat wat RAG doet, hoe een echte pipeline eruitziet, wat elk onderdeel kost en de tabel waarmee je bepaalt of jouw situatie om RAG vraagt of om iets anders.

Wat RAG doet, in drie stappen#

De term komt uit een paper van Patrick Lewis en collega's, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, gepresenteerd op NeurIPS 2020 (Lewis et al., arXiv, 2020). Zij koppelden een taalmodel aan een doorzoekbare vectorindex van Wikipedia en lieten het model antwoorden op basis van wat de zoeker terugvond.

Het effect dat zij maten, geldt nog steeds: het gecombineerde model gaf "more specific, diverse and factual language" dan een model dat alleen uit zijn eigen geheugen putte. Zes jaar later is het principe hetzelfde, alleen is Wikipedia vervangen door jouw documenten.

Een RAG-toepassing bestaat uit drie stappen:

1. Indexeren. Je documenten worden in stukken geknipt (chunks) en elk stuk krijgt een embedding: een reeks getallen die de betekenis vastlegt. Die vectoren gaan in een database.
2. Ophalen. Bij een vraag wordt ook die vraag omgezet in een vector. De database zoekt de stukken die er het dichtst bij liggen, meestal aangevuld met klassiek trefwoordzoeken.
3. Genereren. De gevonden stukken gaan als context mee naar het taalmodel, samen met de vraag. Het model schrijft het antwoord op basis van die stukken en kan ernaar verwijzen.

Stap 1 gebeurt vooraf en bij elke wijziging in de documenten. Stap 2 en 3 gebeuren bij elke vraag.

Het woord "augmented" zit in de naam omdat het model niet wordt veranderd. Het krijgt alleen bij elke vraag extra materiaal aangereikt, en dat is het wezenlijke verschil met fine-tuning, waar de kennis in het model zelf wordt gebakken.

Die keuze werken we apart uit in de vergelijking RAG of fine-tuning; hier gaat het om de vraag wanneer je überhaupt aan RAG toe bent.

Een echte pipeline: Bijbel Assistent#

Theorie is goedkoop. Een eigen product waarin fouten direct zichtbaar zijn, is een betere leermeester, en daarom bouwden we Bijbel Assistent: een Nederlandstalige AI-assistent voor Bijbelstudie, sinds december 2025 in doorlopende ontwikkeling.

Waarom dit corpus? Iemand die naar de betekenis van een vers in het Hebreeuws of Grieks vraagt, slaat het antwoord na: in de brontekst, in de commentaren, in het woordenboek.

Klinkt het model vloeiend maar wijst het een citaat aan het verkeerde hoofdstuk toe, dan heeft de lezer dat binnen een minuut door.

Een assistent op contracten of handleidingen heeft exact hetzelfde probleem; hier wordt het alleen sneller zichtbaar.

Het corpus. Vier Nederlandse vertalingen naast elkaar (Statenvertaling, Herziene Statenvertaling, NBV21 en Bijbel in Gewone Taal), klassieke commentaren zoals Matthew Henry, kruisverwijzingen en Strong-nummers voor Hebreeuwse en Griekse lemma's. Alles moet doorzoekbaar zijn en in het antwoord meelopen.

De ophaallaag. PostgreSQL met de pgvector-extensie als vector-database, zodat corpus, embeddings en gebruikersdata in één systeem staan met dezelfde back-ups en transacties. Redis vangt caching en sessietoegang op.

De redeneerlaag. De Claude API van Anthropic, die per vraag de gevonden passages als context krijgt en in het antwoord terugwijst naar die passages, inclusief de vertaling waaruit ze komen.

Het ontwerpdoel. Ieder inhoudelijk antwoord moet terug te voeren zijn op één aanwijsbare plek in het corpus: een vers met vertaling erbij, een regel commentaar of een lemma uit de grondtaal. Dat is een ontwerpeis die we onszelf stelden, geen extern gemeten nauwkeurigheidsscore, en zo presenteren we het ook niet.

De productlaag. Fastify-backend met JWT-authenticatie, Next.js-frontend, abonnementen via Mollie met iDEAL, data-export en accountverwijdering ingebouwd, een React Native-app en een PWA die offline werkt.

Twee dingen staan bewust niet in deze beschrijving: de chunkgrootte en het embeddingmodel. De case legt die niet vast en dus noemen we ze hier niet.

Wel legt de case vast waar het werk zat: het corpus opschonen en knippen, embeddings genereren en bijhouden, en toetsen of de assistent de juiste passage ophaalt. De kosten zaten daarin zelden bij het taalmodel.

Die verdeling zie je terug in de kostentabel hieronder.

Wat elk onderdeel kost of betekent#

Onderstaande tabel is onze eigen samenstelling op de leverancierspagina's van 18 september 2026. Dollarbedragen zijn per miljoen tokens; de eurobedragen zijn circa, exclusief btw, omgerekend op de ECB-koers van diezelfde dag (1,1460 dollar per euro).

De rij die opvalt: de embeddings. Een corpus van een miljoen tokens (naar de vuistregel van Anthropic ongeveer 2.500 pagina's) embedden kost tussen de 2 en 20 dollarcent, eenmalig.

Dat is geen kostenpost, dat is afrondingsverschil.

Wat wél telt, staat in de laatste twee rijen. Bronvermelding en evaluatie kosten geen tokens maar ontwerptijd, en dat zijn precies de posten die een offerte op basis van "modelgebruik" mist.

Rekenvoorbeeld: wat een vraag kost#

Een rekenvoorbeeld op de tabel, geen meting. Stel de assistent haalt per vraag 20 chunks van gemiddeld 400 tokens op (Anthropic vond top-20 effectiever dan top-10 of top-5), plus de vraag en instructies: circa 8.500 inputtokens.

Het antwoord is 500 tokens.

• Claude Sonnet 5: 8.500 × $2 plus 500 × $10, per miljoen: circa $0,022 per vraag, circa €0,019.
• Claude Haiku 4.5: circa $0,011 per vraag, circa €0,010.
• Bij 10.000 vragen per maand: circa $220 (Sonnet 5) of $110 (Haiku 4.5), circa €192 of €96, exclusief btw.

Wil je per model de volledige tokentabel, inclusief caching en batch, dan staat die voor Anthropic op Claude API-kosten en voor OpenAI op OpenAI API-kosten. Die twee pagina's behandelen de API-kant; hier gaat het om de vraag of je RAG nodig hebt.

Wanneer wel, wanneer niet: RAG naast de alternatieven#

RAG concurreert met drie andere manieren om een model aan jouw kennis te helpen. De tabel is onze eigen indeling.

Drie toelichtingen bij de tabel.

De lange-contextprompt is onderschat. Modellen als Claude Sonnet 5 hebben een contextvenster van een miljoen tokens tegen standaardtarief (Anthropic pricing). Voor een enkel dik contract of een handboek per gesprek is dat sneller gebouwd dan een index.

Hoe je dat aanpakt bij lange documenten, krijgt in de tweede golf van deze kennisbank een eigen pagina.

MCP is geen RAG. Het Model Context Protocol geeft een model toegang tot tools die live systemen bevragen: een orderstatus, een saldo, een voorraadstand. RAG haalt tekst op uit een index die je zelf bijwerkt.

Vraagt je proces om beide, dan combineer je ze: documenten via RAG, cijfers via MCP. De uitlegpagina over MCP volgt in deze golf; wat een koppeling kost, staat al op de pagina over de kosten van een MCP-server.

Fine-tuning verandert het model, RAG verandert de invoer. Wie beide overweegt, leest de vergelijking RAG versus fine-tuning; de korte versie is dat fine-tuning zelden de eerste stap is bij bedrijfskennis die verandert.

Vijf signalen dat je bedrijf RAG nodig heeft#

• Medewerkers zoeken dagelijks in meer dan een paar honderd pagina's aan handleidingen, contracten, procedures of dossiers.
• Een fout antwoord heeft gevolgen, dus "waar staat dat?" moet beantwoordbaar zijn.
• De inhoud verandert wekelijks of vaker en een hertraining per wijziging is ondenkbaar.
• Dezelfde vragen komen bij verschillende mensen terug (klantenservice, binnendienst, HR).
• Je wilt zelf bepalen welk model antwoordt en wat er met je documenten gebeurt.

En drie signalen dat je het (nog) niet nodig hebt:

• Alles wat het model moet weten, past in één prompt.
• De vragen gaan over cijfers uit een systeem, niet over tekst uit documenten.
• Niemand in het bedrijf kan de antwoorden controleren; dan is een evaluatieset bouwen de eerste stap, niet een pipeline.

Waar een RAG-project misgaat#

In onze implementaties zien we dezelfde vier oorzaken terugkomen.

Chunks zonder context. Een stuk tekst dat begint met "De omzet steeg met 3% ten opzichte van het vorige kwartaal" zegt niets als de naam van het bedrijf en het kwartaal in een ander stuk staan. Anthropic mat precies dat effect: contextuele chunks halveerden bijna het aantal ophaalfouten (Anthropic, 2024).

Alleen op betekenis zoeken. Vectorzoeken vindt "opzegtermijn" als iemand "hoe lang moet ik van tevoren stoppen" vraagt, maar mist een artikelnummer of een foutcode. Daarom hoort er trefwoordzoeken naast, en dat is in PostgreSQL een gewone tekstindex.

Geen evaluatieset. Zonder een lijst vragen met het juiste bronfragment weet je niet of een wijziging in chunkgrootte of embeddingmodel iets verbetert. Je test dan op gevoel, en gevoel is precies wat een taalmodel uitstekend kan bespelen.

Live data in de index. Voorraadstanden van gisteren in een vectorindex zetten, geeft antwoorden die stellig en fout zijn. Dat hoort in een tool-aanroep, niet in een index.

Een vijfde, minder technisch: het product stopt bij het chatvenster. Bijbel Assistent kreeg een prediker-modus, woordstudie op Strong-nummers, groepsstudie en een REST-API omdat een los chatvenster geen werkinstrument is.

Dat geldt voor een assistent op contracten net zo goed.

Wat het kost als wij het bouwen#

Onze prijsband voor deze dienst staat op de pagina AI software laten maken. RAG-zoeken op je eigen data begint bij €12.500; is de zoekfunctie een onderdeel van een bredere applicatie, dan geldt de band voor één ingebouwde AI-feature (vanaf €8.500).

Het onderhoud daarna begint bij €750 per maand, met de modelkosten als aparte post. Vaste prijs na scoping, en broncode, prompts en evaluatiesets zijn van jou.

RAG-zoeken staat in 4-6 weken live. De eerste twee weken gaan naar haalbaarheid op je echte documenten, want of je corpus zich laat knippen en ophalen, weet je pas als je het probeert.

Wat er in die €12.500 zit en waar de bandbreedte vandaan komt, krijgt in de tweede golf een eigen kostenpagina over AI op eigen data. Wil je eerst het bredere plaatje, dan zet de pagina wat kost AI voor bedrijven alle vormen naast elkaar, van chatbot tot managed AI.

Onze default voor de redeneerlaag is Claude, om de reden die de case laat zien: het model moet zich laten binden aan de opgehaalde passages en dat rustig toegeven als de passage het antwoord niet bevat. De embeddinglaag is daar los van; die kiezen we per corpus, en Voyage, OpenAI en Google staan alle drie in de tabel hierboven.

Wil je weten of jouw documenten zich lenen voor RAG, dan beoordelen we dat in een scoping op je eigen bestanden. Bel 085 016 0118 of laat via contact weten om welk corpus het gaat; je krijgt een antwoord op de vraag "RAG, prompt of koppeling" en een vaste prijs.

Welk model daarna de antwoorden schrijft, is een aparte keuze; de vergelijking van AI-modellen voor zakelijk gebruik zet de kandidaten per taak naast elkaar.