Vroeg of laat vraagt elke klant hetzelfde, net iets anders verwoord: "Kunnen we een ChatGPT die ónze dingen kent?" Hun handboek, hun tickets, hun productdocs, vijf jaar aan projectbestanden. Het eerlijke, hype-vrije antwoord is ja — en de techniek heeft een naam van drie letters die meer buzzwords heeft verzameld dan verdiend: RAG.

Laten we het ontluchten. RAG betekent: vraag het model niet om je data te onthouden — haal de relevante stukjes op tijdens de vraag en geef ze mee. Het model "leert" niets. Het leest wat je geeft en schrijft een antwoord dat in die tekst geworteld is. Dat is het hele idee. De rest is leidingwerk — maar in dat leidingwerk leven of sterven projecten.

Waarom de weekenddemo liegt

Dit is de valkuil. Je zet een vector-database op, gooit er honderd documenten in, stelt drie vragen, en het antwoordt prachtig. Je demonstreert het op vrijdag, de klant is laaiend enthousiast, en je noemt een livedatum. Drie maanden later stellen echte gebruikers echte vragen, is de recall stilletjes ingestort, verzint de assistent zelfverzekerd een retourbeleid dat niet bestaat, en kan niemand uitleggen waarom.

De demo liegt omdat honderd schone documenten en drie makkelijke vragen elk probleem verbergen. Productie legt ze allemaal tegelijk bloot: rommelige pdf's, bijna-identieke pagina's, exacte artikelnummers die niemand foutloos spelt, vragen die twee documenten beslaan, en een kennisbank die onder je handen verandert. RAG die in productie werkt is geen ander idee — het is hetzelfde idee met de faalmodi eruit ge-engineerd.

De retrieval-stack die het overleeft bij echte gebruikers

Generatie krijgt alle aandacht, maar het antwoord is nooit beter dan de tekst die je ophaalt. Haal de verkeerde chunks op en geen enkel model redt je — het hallucineert alleen vloeiender. Dus bijna al het echte werk zit in retrieval. Vier stappen doen het meeste.

1. Chunk op betekenis, niet op tokens

Je kunt het model geen hele documenten geven, dus je knipt ze in chunks. De naïeve aanpak — knip elke 500 tokens — hakt zinnen doormidden en parkeert een definitie drie chunks verderop, weg van de vraag die hem nodig heeft. Knip op structuur: koppen, secties, lijstgrenzen. Houd een chunk over één ding, houd wat overlap tussen buren, en bewaar metadata (bron, sectie, datum) bij de tekst. Te grote chunks verdunnen het signaal met onnodig materiaal; te kleine verliezen de context die ze beantwoordbaar maakt.

2. Hybride search, geen pure vectors

De standaard RAG-tutorial gebruikt alleen embeddings — semantisch zoeken dat op betekenis matcht. Prima voor parafrases, zwak voor de dingen waar bedrijven écht op zoeken: factuurnummers, SKU's, foutcodes, achternamen, een exacte clausule. Daarvoor wil je ouderwets keyword-zoeken — BM25. Het productieantwoord is niet "kies er één"; het is allebei draaien en de resultaten samenvoegen. Hybride search is in 2026 de standaard omdat echte vragen beide helften nodig hebben.

3. Rerank vóór je het overdraagt

Hybride search geeft je een shortlist — zeg de top 50 kandidaten. Die zijn ongeveer goed, niet precies geordend. Een cross-encoder-reranker leest elke kandidaat tegen de echte vraag en sorteert opnieuw op werkelijke relevantie, zodat je het model de beste 5–8 geeft in plaats van een rommelige 50. Het kost je iets — een reranking-stap voegt doorgaans tientallen tot een paar honderd milliseconden toe — maar het is de toevoeging met de meeste hefboom in de meeste pipelines. Minder ruis erin, minder hallucinaties eruit.

4. Vertel elke chunk waar hij vandaan komt

Een chunk die uit een document van 40 pagina's wordt getrokken, verliest zijn context: "het tarief steeg met 3%" — welk tarief, welk jaar? De techniek contextual retrieval van Anthropic lost dit goedkoop op: vóór het indexeren plak je een door het model geschreven regel vóór elke chunk die hem in zijn document plaatst. In hun gepubliceerde benchmarks verlaagden contextual embeddings het top-20-faalpercentage van retrieval met 35%; gecombineerd met contextual BM25 was de daling 49%, en met reranking erbovenop werd het 67%. Een flinke kwaliteitswinst voor een eenmalige indexeerkost.

Het antwoord is nooit beter dan de tekst die je ophaalt. Het meeste van RAG is geen AI — het is zoeken, goed gedaan.

De stap die iedereen overslaat: evaluatie

Dit is het verschil tussen een demo en een product, en het is het minst glamoureuze deel, dus het sneuvelt als eerste. Laat dat niet gebeuren.

Bouw een gouden set: 50 tot 200 echte vraag/antwoord-paren, getrokken uit echt gebruikersverkeer, niet bedacht aan je bureau. Elke keer dat je een chunkgrootte wijzigt, een embedding-model wisselt of een prompt aanpast, scoor je tegen de gouden set en zie je of de kwaliteit omhoog of omlaag ging — in plaats van te gokken op drie vragen die toevallig werkten.

En meet de twee helften apart. Als een antwoord fout is, zijn er maar twee verdachten: óf retrieval haalde de juiste chunk niet op (geen model lost dat op), óf hij werd opgehaald en generatie ging alsnog de mist in (een prompt- of groundingprobleem). Gooi je ze op één hoop, dan is elke bug een mysterie van vijf uur; scheid je ze, dan is het een triage van vijf minuten. Die splitsing — retrieval-kwaliteit versus generatie-kwaliteit — is het nuttigste instrument dat je kunt bouwen.

Eerlijk blijven in de EU

Eén ding dat de tutorials nooit noemen: je zoekindex is een kopie van de data van de klant, op een nieuwe plek. Dat heeft gevolgen die jij draagt.

  • Toegangsrechten volgen de data. Mag een gebruiker een document niet zien in het bronsysteem, dan mag retrieval de tekst ervan ook niet tonen. Filter de index op de rechten van de gebruiker — een copilot die HR-bestanden over afdelingen heen lekt, is een datalek, geen feature.
  • Residency is een hostingkeuze. Moet de data in de EU blijven, dan moeten het embedding-model, de vector-store én het generatiemodel in een EU-regio staan — of op de eigen infrastructuur van de klant. Beslis het vóór de eerste prompt, niet na de pilot.
  • De AVG geldt nog steeds. PII in de documenten is PII in de index. Rechtsgrond, bewaartermijn en het recht op verwijdering van een betrokkene reiken ook tot in je retrieval-store.

Niets hiervan is exotisch; het is dezelfde discipline als elk dataproject. We lopen het door op onze EU Ready-pagina, en de modelhosting-helft van de beslissing staat in ons stuk over de modelstack kiezen voor EU-klanten.

De saaie stack die wij echt bouwen

Ontdaan van hype is een productie-copilot op bedrijfsdata een korte, saaie lijst — en saai is het punt:

  1. Structuurbewuste chunking met metadata en overlap.
  2. Hybride retrieval — embeddings + BM25 — samengevoegd tot één shortlist.
  3. Een cross-encoder-reranker terug naar de beste handvol chunks.
  4. Contextuele snippets zodat elke chunk weet waar hij vandaan komt.
  5. Een gegrounde prompt die zijn bronnen citeert en "ik weet het niet" mag zeggen.
  6. Een gouden evaluatieset en aparte retrieval/generatie-scoring bij elke wijziging.
  7. Opnieuw indexeren bij een documentwijziging, en toegangsfiltering bij elke query.

Geen GraphRAG, geen agent-zwerm, geen onderzoeksproject van acht weken — die hebben hun plek, maar zijn zelden de bottleneck. De bottleneck is zoeken dat goed is gedaan en eerlijk is gemeten. Dat is een bouw die we in weken kunnen opleveren, white-label, onder jouw naam.

FAQ

Moeten we het model fine-tunen op de data van de klant?

Bijna nooit. Fine-tunen leert een model stijl en gedrag, geen feiten — en het bakt data erin tot de volgende trainingsronde, dus het veroudert en je krijgt het er niet meer uit. Voor "beantwoord vragen op onze documenten" is retrieval het juiste gereedschap: je haalt de relevante tekst op tijdens de vraag, dus een update is gewoon opnieuw indexeren.

Pure vector-search voelde prima in de demo. Waarom keyword-search erbij?

Embeddings zijn sterk in betekenis maar zwak in exacte tokens — productcodes, foutnummers, namen, afkortingen. BM25 keyword-search vangt die wel, en mist juist de parafrases die embeddings oppikken. Allebei draaien en de resultaten samenvoegen (hybride search) is de productiestandaard, want echte vragen hebben beide helften nodig.

Hoe weten we of het echt werkt en niet stilletjes verslechtert?

Bouw een gouden set van 50–200 echte vraag/antwoord-paren uit echt gebruikersverkeer en scoor elke wijziging daartegen. Meet retrieval en generatie apart: is de juiste chunk niet opgehaald, dan redt geen enkel model je; is hij wel opgehaald en klopt het antwoord nog niet, dan is het een prompt-probleem. Zonder dit vlieg je blind.

Is onze bedrijfsdata veilig met RAG?

Alleen als je ervoor ontwerpt. Je index is een kopie van de brondata, dus die erft dezelfde toegangsregels — filter retrieval op de rechten van de gebruiker, host de index en het model in een EU-regio als residency telt, en houd PII-verwerking onder de AVG. RAG verandert je privacyplichten niet; het verplaatst de data naar een nieuwe plek.

Waarom citeert het antwoord een document dat vorige maand is bijgewerkt, met de oude tekst?

Verouderde index. De bron veranderde maar de index heeft het nooit opnieuw verwerkt, dus retrieval geeft zelfverzekerde, achterhaalde antwoorden. Opnieuw indexeren bij een documentwijziging — niet alleen een trage nachtelijke cron — hoort bij de bouw, niet erna.

Bronnen: Anthropic, Introducing Contextual Retrieval (faalpercentage-benchmarks) · PremAI, Building Production RAG: architecture, chunking, evaluation & monitoring (2026) · StackAI, RAG best practices: chunking, embeddings, reranking en hybride search.

Een klant die vraagt om een copilot op de eigen data? Plan een call — wij bouwen de retrieval-stack en dragen hem over onder jouw merk.