RAG of prompt-stuffing: wanneer kies je wat?

Als een klant vraagt "kunnen jullie een AI bouwen die antwoord geeft op basis van onze documentatie?", is het standaard-antwoord van veel bureaus tegenwoordig: "ja, met RAG". Vector database, embeddings, retrieval, herrangschikking, top-K terugsturen naar de LLM. De hele stack.

Soms is dat het juiste antwoord. Maar net zo vaak niet. Met modellen die 200k+ tokens contextwindow hebben (Claude Opus 4, GPT-4 Turbo, Gemini 1.5 Pro), kun je voor veel use cases beter de hele documentenset in de prompt gooien en het model laten zoeken. Dat heet prompt-stuffing of full-context, en het is simpeler, sneller te bouwen en vaak nauwkeuriger.

In deze post: wanneer kies je wat, en welke vragen stel je vooraf.

Wat RAG eigenlijk doet

RAG (Retrieval-Augmented Generation) is in essentie een twee-staps proces:

1. Retrieval. Je documenten zijn opgeknipt in chunks (paragrafen, secties, bullets). Elke chunk is omgezet naar een vector via een embedding-model. Bij een vraag van de gebruiker maak je een vector van de vraag, en zoekt de N chunks waarvan de vector het dichtst bij die van de vraag ligt.

2. Generation. Je geeft die N chunks samen met de oorspronkelijke vraag aan de LLM. De LLM antwoordt op basis van wat hij in die chunks vindt.

Voordelen: je kunt overweg met willekeurig veel content (terabytes, als nodig), je betaalt alleen voor de tokens in de relevante chunks, en je kunt nieuwe documenten incrementeel toevoegen zonder de hele knowledge base opnieuw te indexeren.

Nadelen: de kwaliteit van het antwoord hangt af van of de retrieval de juiste chunks ophaalt. En de retrieval-stap is geen exacte wetenschap — embeddings zijn benaderingen, en welke chunks "het dichtst bij" een vraag liggen, hangt af van hoe je de chunks hebt gemaakt, welk embedding-model je gebruikt, en welke similarity-metric je kiest.

Wat prompt-stuffing doet

Prompt-stuffing is hilarisch eenvoudig: je gooit alle relevante content in de prompt en laat de LLM zelf de relevante stukken eruit halen.

const allDocs = await loadAllProductDocs(); // 80k tokens
const prompt = `
Hieronder staat de volledige productdocumentatie. Beantwoord de vraag
van de gebruiker op basis van deze documentatie. Citeer de exacte sectie
waar je het antwoord op baseert.

DOCUMENTATIE:
${allDocs}

VRAAG: ${userQuestion}
`;

Dat is alles. Geen vector database, geen chunking, geen embedding-model. De LLM doet zelf de retrieval — en omdat hij de hele content kan zien, kan hij verbanden leggen tussen secties die een vector-search nooit zou hebben gevonden.

Voordelen: simpeler architectuur (één API-call, geen index om te onderhouden), betere antwoordkwaliteit voor synthese-vragen (waarbij meerdere secties moeten worden gecombineerd), en geen "verkeerd opgehaalde chunks"-categorie van fouten.

Nadelen: kost per call meer tokens (en dus geld), heeft een harde bovengrens (~200k tokens voor de meeste frontier-modellen), en de latentie schaalt mee met de promptgrootte.

Drie vragen om vooraf te beantwoorden

Hier is hoe ik kies tussen de twee in een eerste gesprek met een klant.

Vraag 1: Hoeveel content gaat in de knowledge base?

Tel het op. Echt: maak een schatting van het totaal aantal tokens (vuistregel voor Nederlands: één token ≈ 3 karakters; je kunt het exact tellen met tiktoken of Anthropic's tokenizer).

• < 100k tokens → prompt-stuffing is bijna altijd beter. Eén document, een handleiding, een paar PDF's, een statisch product-handboek. Geen RAG nodig.
• 100k–500k tokens → twijfelgeval. Kijk naar de andere vragen.
• > 500k tokens → RAG. Geen contextwindow is groot genoeg, en zelfs als die er over twee jaar wel is, betaal je per call enorm veel om alles mee te sturen.

Concreet voorbeeld: een productdocumentatie van een SaaS-product is meestal 50–150k tokens. Een interne wiki van een bedrijf met 200 medewerkers is meestal 1–5M tokens. Het eerste is een prompt-stuffing-kandidaat, het tweede vereist RAG.

Vraag 2: Veranderen de documenten vaak?

• Statisch (zelden updates) → maakt niet uit, beide werken.
• Dagelijks updates → prompt-stuffing is operationeel makkelijker. Je laadt gewoon de laatste versie. Bij RAG moet je een re-indexering pipeline onderhouden, en dat is in productie meer werk dan mensen verwachten.
• Continue stroom van nieuwe documenten (bijvoorbeeld: dagelijks honderden binnenkomende e-mails) → RAG. Maar dan moet je ook nadenken over chunking-strategie, versie-management en incremental indexing.

Vraag 3: Wat is de vraag-stijl?

Hier wordt het interessant.

• Lookup-vragen ("wat is de openingstijd op zondag?") → beide werken. RAG is goedkoper als de knowledge base groot is.
• Synthese-vragen ("hoe verhoudt feature X zich tot het beleid Y zoals beschreven in document Z?") → prompt-stuffing is duidelijk beter. Synthese vereist dat de LLM meerdere stukken context tegelijk ziet, en RAG mist vaak één van de relevante stukken.
• Comparatieve vragen ("welke van onze klanten voldoen aan criterium A?") → meestal geen van beide. Dit zijn vragen voor een database-query, geen LLM-call. Gebruik tool use met een SQL-tool.

In de praktijk: 60–70% van wat klanten "AI op onze documenten" noemen, zijn synthese-vragen vermomd als lookup-vragen. "Wat zegt onze HR-policy over verlof bij ziekte tijdens vakantie?" lijkt een lookup, maar vereist dat de LLM de verlof-regels, de ziekteregels en de vakantieregels in samenhang ziet. Dat is een synthese-vraag — en daarvoor wint prompt-stuffing.

De hybride aanpak

In productie eindigen we vaak met een hybride: een lichte retrieval-laag die voorfiltert tot ~50k tokens relevante content, en dan prompt-stuffing van die 50k. Dat noemen sommige bureaus "RAG", maar het is functioneel iets anders — de retrieval haalt grote brokken op (bijvoorbeeld hele documenten), niet kleine chunks. De LLM doet vervolgens de fijne selectie.

Dat werkt omdat het twee soorten fouten vermijdt:

• Pure RAG met kleine chunks mist verbanden tussen secties.
• Pure prompt-stuffing van 500k tokens kost te veel per call.

De hybride zit in het midden: snel selecteren op document-niveau (BM25, of vector-search op samenvattingen, of metadata-filtering), en daarna alles van de geselecteerde documenten meesturen.

Wat we kiezen bij Boomer

Onze defaults voor verschillende project-typen:

• Klantsupport-bots op productdocumentatie (typisch 50–200k tokens): prompt-stuffing. Eén call, één goed antwoord, geen indexering om te onderhouden.
• Juridische dossier-analyse (typisch 10–50k per dossier): prompt-stuffing per dossier. Hier maak je dossier-bound LLM-sessies.
• Bedrijfsbrede knowledge bases (Confluence, Notion, SharePoint van een MKB-bedrijf): hybride. Retrieval op documentniveau, daarna prompt-stuffing van top-3 documenten.
• Productie-logs of grote tabelvormige data: geen RAG, geen prompt-stuffing — gebruik tool use met SQL.

Tot slot

Een vector database voelt indrukwekkend. Een Postgres-tabel met een paar duizend documenten en gpt_call_with_full_context() voelt simpel. De truc is om eerlijk te zijn over wat je use case eigenlijk is: hoeveel content, hoe vaak verandert het, en wat voor vragen worden gesteld. Beantwoord die drie vragen, en de keuze maakt zichzelf.

Als de keuze niet duidelijk is, beginnen we bijna altijd met prompt-stuffing. Het is goedkoper te bouwen, makkelijker te debuggen, en geeft je meteen een baseline om RAG tegen af te zetten. Als prompt-stuffing tegen contextlimieten of kosten aan loopt, schakelen we over. Maar in 60% van de projecten is die overstap nooit nodig.

We helpen graag bij die afweging als je twijfelt. Stuur ons je use case — we zeggen het eerlijk als RAG overkill is.