RAG die écht werkt: de zeven dingen die niemand je vertelt

Retrieval-augmented generation heeft een imagoprobleem. De tutorialversie — knip je documenten in stukken, embed ze, zoek op cosine-gelijkenis, plak de top vijf in de prompt — werkt prachtig op een zorgvuldig samengesteld demo-corpus en valt binnen ongeveer een week uit elkaar op een echt corpus.

De fout zit vrijwel nooit in het model. Hij zit in de retrieval. Staat de juiste passage niet in het contextvenster, dan redt geen enkele hoeveelheid prompt-engineering het antwoord.

Dit is wat er verandert tussen de demo en productie.

1. Chunking is een inhoudelijke keuze, geen configuratiewaarde

Vaste chunks van 512 tokens met 50 tokens overlap is de standaard in elke tutorial, en voor de meeste echte documenten is het fout.

De eenheid van retrieval hoort te matchen met de eenheid van betekenis:

• Beleids- en juridische documenten — knip per paragraafkop en houd de kophiërarchie eraan vast. Een clausule uit een retourbeleid is betekenisloos zonder te weten dat hij onder "EU-klanten" valt.
• Technische documentatie — knip per kop, splits nooit een codeblok, en zet paginatitel en broodkruimel vóór elke chunk.
• Supporttickets en gesprekken — knip per thread, niet per bericht. Een half gesprek komt terug als ruis.
• Tabellen en spreadsheets — knip ze helemaal niet in tekst. Houd ze gestructureerd en bevraag ze met gegenereerde SQL of een filter, niet met embeddings.

Twee technieken die consequent hun geld opleveren:

Contextuele prefix. Zet vóór het embedden één of twee zinnen die beschrijven waar de chunk in het moederdocument zit — één keer offline gegenereerd door een goedkoop model. "Deze paragraaf komt uit het EU-retourbeleid 2026 en behandelt de uitzonderingsprocedure voor gepersonaliseerde artikelen." De winst in retrieval-nauwkeurigheid is groot en het kost je één batchjob.

Klein-naar-groot. Embed en zoek over kleine, precieze chunks, maar geef de bovenliggende paragraaf terug aan het model. Je krijgt de precisie van een strakke embedding én de volledigheid van een hele passage.

2. Puur vectorzoeken verliest van hybride zoeken. Elke keer.

Embeddings zijn uitstekend in semantische gelijkenis en slecht in exacte termen. Vraag naar order #DE-88410, een SKU-code, een achternaam of een foutmelding, en dense retrieval geeft je vol overtuiging vijf documenten die over hetzelfde onderwerp gaan en geen van die termen bevatten.

Draai allebei:

• Dense (embeddings) voor semantische en geparafraseerde vragen.
• Sparse (BM25 / keyword) voor identifiers, namen, foutcodes en zeldzame termen.

Voeg de twee resultatenlijsten samen met Reciprocal Rank Fusion — dat vraagt geen normalisatie van scores en geen tuning, precies wat je wilt in een component dat moet blijven werken terwijl al het andere verandert:

score(doc) = Σ  1 / (k + rang_in_lijst)      # k ≈ 60

In elke implementatie waar we het hebben gemeten, leverde het toevoegen van een keyword-been aan een dense-only systeem meer recall-winst op dan welke upgrade van het embeddingmodel ook.

3. Haal breed op, rerank daarna

Retrieval optimaliseert voor recall. Het contextvenster vraagt om precisie. Dat zijn verschillende taken, dus gebruik twee fases.

Haal 50–100 kandidaten op met hybride zoeken en stuur die door een cross-encoder-reranker die elke kandidaat scoort tegen de daadwerkelijke vraag, in plaats van vooraf berekende vectoren te vergelijken. Houd de top 5–10 over.

Dit is de toevoeging met de meeste hefboom voor de meeste RAG-systemen. Het is een tweede modelaanroep, het kost een paar honderd milliseconden extra, en het lost standaard de categorie "het antwoord stond in chunk 23 en we stuurden er maar 5" op.

4. Metadatafilters verslaan betere embeddings

De goedkoopste nauwkeurigheidswinst is meestal helemaal niet semantisch.

Zit de klant in Duitsland, doorzoek dan niet de Britse beleidsdocumenten. Gaat de vraag over het huidige abonnement, haal dan niet de prijspagina uit 2023 op. Gaat het ticket over een fysiek product, sluit dan de kennisbank voor digitale producten uit.

Hang metadata aan bij het inladen — markt, productlijn, documenttype, ingangsdatum, versie, toegangsniveau — en filter vóór de semantische zoekopdracht draait. Je krimpt de kandidatenpool tot documenten die überhaupt juist kúnnen zijn, wat de precisie verhoogt en tegelijk de kosten verlaagt.

Actualiteit verdient aparte aandacht. De meeste corpora bevatten achterhaalde documenten. Staan er drie versies van het retourbeleid in je index zonder besef van welke geldig is, dan citeert je agent er vroeg of laat de verkeerde aan een klant. Filter hard op actuele versies, of pas een expliciete recency-decay toe.

5. De vraag die de gebruiker typte is zelden de vraag die je moet zoeken

Gebruikers schrijven "het duurt al eeuwen, waar blijft het?" In je index staat "verwacht bezorgmoment" en "status van de zending".

Drie transformaties, goedkoop uit te voeren, groot in effect:

• Herschrijven. Zet een gespreksbericht plus de historie om in een zelfstandige zoekopdracht. Essentieel bij meerdere beurten — "en die blauwe dan?" is onzoekbaar zonder de vorige beurt.
• Opsplitsen. Splits meerdelige vragen. "Kan ik dit retourneren én de aanbiedingsprijs krijgen op de vervanger?" zijn twee zoekopdrachten, geen één.
• HyDE (hypothetische documentembeddings). Laat een goedkoop model een plausibel antwoord schetsen, en embed en zoek daarmee. Het gegenereerde antwoord ligt in de embeddingruimte dichter bij echte antwoordpassages dan de vraag.

Draai deze met een klein, snel model. De extra latency is het waard.

6. Evalueer retrieval los van generatie

Dit is de discipline die systemen die verbeteren scheidt van systemen die wegdrijven.

Als een RAG-antwoord fout is, zijn er twee mogelijke oorzaken: de juiste passage werd niet opgehaald, of hij werd wel opgehaald en het model negeerde hem. Die vragen om totaal verschillende oplossingen, en één end-to-end score kan je niet vertellen welke van de twee je hebt.

Bouw een gelabelde set — 100–200 echte vragen met de passages die ze daadwerkelijk beantwoorden — en volg:

• Recall@k — zit de juiste passage in de top k? Is dit laag, dan is alles stroomafwaarts ruis. Repareer eerst de retrieval.
• MRR / nDCG — hoe hoog staat hij? Positie telt; modellen letten ongelijkmatig op over een lange context.
• Getrouwheid — wordt elke bewering in het antwoord gedekt door een opgehaalde passage? Scoor dit met een model-als-jury tegen de opgehaalde set.
• Antwoordrelevantie — beantwoordde het de gestelde vraag?

Recall@k is degene waar je vroeg op moet hameren. Retrieval-fouten zijn onzichtbaar in productie — het model produceert een vloeiend, plausibel, fout antwoord en niemand meldt een bug.

7. Ontwerp voor het lege resultaat

De gevaarlijkste toestand in een RAG-systeem is "er is niets relevants gevonden".

Het standaardgedrag van een taalmodel dat vijf irrelevante passages en een vraag krijgt, is tóch antwoorden, uit parametrisch geheugen, in precies hetzelfde zelfverzekerde register dat het gebruikt als het klopt. Zo ontstaan de ergste fouten van RAG-systemen.

Drie verdedigingslinies, alle drie goedkoop:

1. Een relevantiedrempel. Ligt de hoogste reranker-score onder een grens, behandel het dan als geen resultaat.
2. Een expliciete instructie én een expliciet pad. "Bevat de opgehaalde context het antwoord niet, zeg dat dan en escaleer. Antwoord niet uit algemene kennis." Geef het model ergens om naartoe te gaan, niet alleen iets om te vermijden.
3. Bronvermelding, afgedwongen. Verplicht het model de chunk te citeren die elke bewering onderbouwt, en valideer dat die chunk daadwerkelijk in wat je stuurde voorkwam. Ongeciteerde beweringen worden verwijderd of gemarkeerd. Dat maakt van hallucinatie een detecteerbare fout in plaats van een onzichtbare.

De volgorde waarin je bouwt

Begin je vanaf een systeem op demo-niveau, dan is dit de volgorde die voor ons het meest heeft opgeleverd:

1. Bouw de evaluatieset. 100 echte vragen met bekende juiste passages. Een halve dag, en alles daarna wordt meetbaar.
2. Voeg metadatafilters toe. Meestal de grootste enkelvoudige winst, en het is niet eens een ML-wijziging.
3. Voeg hybride zoeken toe. Op één na de grootste.
4. Voeg reranking toe. Derde.
5. Pas de chunking aan op de structuur van je inhoud.
6. Voeg query-herschrijving toe.
7. Overweeg pas nu een ander embeddingmodel.

De meeste teams doen dit lijstje achterstevoren, en beginnen bij het embeddingmodel omdat dat aanvoelt als het ML-deel. Het is de kleinste hefboom op de lijst.

---

Wij bouwen retrieval-systemen op klantdata, binnen de infrastructuur van de klant — inclusief het eval-harnas dat we samen met de code overdragen. Plan een auditgesprek.