Bij RAG (Retrieval-Augmented Generation) richten de meeste debug-pogingen in 2026 zich op modelprompts en system instructions. De klant wijzigt de prompt 12 keer, zit er 4 dagen aan en de precisie stijgt van 67 % naar 70 %. Ondertussen zouden drie instellingen in de retrieval-laag — chunking, embedding-model, reranking — in een halve dag werk de precisie naar 84 % brengen. Dit artikel gaat over die drie instellingen.
Waarom retrieval beslist, niet de LLM
Een fundamentele asymmetrie van de RAG-architectuur: levert retrieval **de juiste stukken documentatie**, dan geeft zelfs een gemiddeld 7B-model een kwalitatief antwoord. Levert retrieval irrelevante of onvolledige stukken, dan redt zelfs Claude Opus 4.6 het antwoord niet — het model heeft simpelweg geen feiten in de context. "Garbage in, garbage out" is in RAG letterlijk een fysieke wet.
Concreet voorbeeld: een juridische RAG over Slowaakse wetgeving, 12 000 documenten, 8 M tokens. Met default chunking (500 tokens fixed-size) en OpenAI text-embedding-ada-002 haalden we precision@5 = 0,61, recall@10 = 0,72. Na drie aanpassingen (document-aware chunking, embedding-upgrade naar BGE-M3, Cohere Rerank 3) — precision@5 = 0,84, recall@10 = 0,93. **Geen LLM-wijziging, geen promptwijziging.**
Instelling 1: chunk size + chunking strategy
De meest voorkomende configuratie in PoC-projecten: `RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)` uit de LangChain-default. Werkt voor 60 % van de use-cases. Voor de rest is het verkeerd.
**Twee beslissingsdimensies:**
A) Chunkgrootte (tokens)
- **128–256 tokens** — hoge precisie, retrieval vindt precies de paragraaf die antwoordt. Risico: de context rondom de paragraaf ontbreekt, het model ziet niet de hele gedachtegang. Geschikt voor FAQ's, codesnippets, gestructureerde data.
- **256–512 tokens** — meest voorkomende compromis. Een paragraaf met omliggende context. Default-keuze voor de meeste B2B knowledge base-implementaties.
- **512–1024 tokens** — bredere context, het model krijgt meer samenhang, maar de retrieval-precisie daalt (de embedding van een 1 024-token-chunk "verdunt" het hoofdthema). Geschikt voor langere narratieve documenten (juridische uitspraken, onderzoekspapers, technische handleidingen).
- **> 1 024 tokens** — zelden correct. Embedding-modellen hebben een reële effectieve lengte van ~512 tokens — de meeste informatie boven die drempel "lost op" in één vector. Uitzondering: long-context embedding-modellen (Voyage-3-large, BGE-M3 in volledige modus, NV-Embed-v2) kunnen tot 8 192 tokens effectief verwerken.
B) Splittingsstrategie (fixed vs. semantic vs. document-aware)
- **Fixed-size chunking** — eenvoudig, deterministisch, maar breekt paragrafen, zinnen, zelfs woorden op de grens. Contextverlies bij ~15 % van de chunks, wat 8–12 % verslechtering in precision@5 oplevert.
- **Semantic chunking** — met behulp van embeddings detecteert grenzen tussen zinvolle segmenten (bv. `semantic_chunker` in LlamaIndex). Behoudt context beter, maar chunks hebben variabele grootte — bij inference rekent u met een spreiding van 200–800 tokens. Verbetering precision@5 met 5–8 %.
- **Document-aware chunking** — gebruikt de structuur van het document (markdown headings, HTML `<section>`, PDF-secties via Docling of Unstructured.io). Chunks komen overeen met de logische eenheden van de auteur. **De beste keuze voor 80 % van de B2B use-cases**, verbetering precision@5 met 12–18 % ten opzichte van fixed-size.
Praktische configuratie voor een juridische RAG: Docling-parsed PDF → split op `<heading>` in serie → als heading section > 800 tokens, sub-split per alinea (`\n\n`) → metadata per chunk: `{doc_id, section, page, jurisdiction, paragraph_number}`. 10–20 % overlap tussen aangrenzende chunks voor continuïteit.
**Concrete benchmark:** 12 000 juridische documenten, fixed 500-token vs document-aware chunking. - Fixed: 38 400 chunks, gemiddeld 487 tokens, precision@5 = 0,61 - Document-aware: 24 200 chunks, gemiddeld 612 tokens, precision@5 = 0,73
Instelling 2: embedding-model
De meest onderschatte beslissing. De klant kiest OpenAI `text-embedding-ada-002` uit 2022 omdat "het in de LangChain-quickstart staat" en verliest 15–20 % precisie die hij met een modern model had gewonnen.
Topkeuzes in 2026 — cost/quality/latency tradeoff
**OpenAI text-embedding-3-large** - Dimensie: 3 072 (verlaagbaar via Matryoshka representation naar 256/512/1 024) - MTEB-score: ~64,6 - Prijs: 0,13 USD / M tokens - Multilingual: goed, maar niet het beste voor SK/CZ — in tests met Slowaakse juridische teksten precision@5 = 0,77 - Latency: ~80 ms per request (API) - **Wanneer:** all-in cloud-setup, Engels + gangbare EU-talen
**Cohere embed-multilingual-v3.0** - Dimensie: 1 024 - MTEB-score: ~63,8 (multilingual benchmark hoger) - Prijs: 0,10 USD / M tokens - Multilingual: uitstekend voor 100+ talen, met name sterk voor Oost-Europese talen (SK, CZ, HU, RO) - Latency: ~60 ms per request - **Wanneer:** multilingual knowledge base, EU-compliance (Cohere heeft een EU-region-endpoint)
**sentence-transformers/all-mpnet-base-v2** - Dimensie: 768 - MTEB-score: ~57,8 - Prijs: self-hosted (CPU/GPU) - Multilingual: zwak (primair EN) - Latency: ~10 ms op CPU, ~3 ms op GPU - **Wanneer:** budgetset-up, EN-only, off-line
**BGE-M3 (BAAI/bge-m3)** - Dimensie: 1 024 (dense), plus sparse + colBERT-style multivector - MTEB-score: ~66,1 (multilingual benchmark) - Prijs: self-hosted - Multilingual: uitstekend voor 100+ talen inclusief SK - Latency: ~15 ms op RTX 4090 - **Wanneer:** SOTA-keuze voor multilingual + self-hosted. **Onze default in 2026 voor EU-klanten.**
**Voyage AI voyage-3-large** - Dimensie: 1 024 - MTEB-score: ~68,2 (een van de hoogste in 2026) - Prijs: 0,18 USD / M tokens - Multilingual: uitstekend - **Wanneer:** premium cloud, waar elke 1 % precisie meetelt
**Concrete benchmark:** zelfde juridisch corpus (8 M tokens), document-aware chunking, geen reranker. - OpenAI text-embedding-3-large: precision@5 = 0,77, latency 80 ms - Cohere embed-multilingual-v3: precision@5 = 0,79, latency 60 ms - BGE-M3 (self-hosted): precision@5 = 0,81, latency 15 ms - Voyage-3-large: precision@5 = 0,82, latency 95 ms
Voor Slowaakse juridische content is het verschil tussen `text-embedding-ada-002` (0,61) en BGE-M3 (0,81) **20 procentpunten precisie** — de eenvoudigste wijziging met de grootste impact.
Instelling 3: reranker
De meest onderschatte component van de pipeline. Architectuur: retrieval levert top-K kandidaten (meestal K = 20–50) op embedding-similarity, **reranker** scoort die met een cross-encoder-model (trager, maar nauwkeuriger) en selecteert top-N (meestal N = 5) voor de LLM-context.
Waarom dit werkt: bi-encoder embedding (snelle retrieval) is "lossy" — comprimeert een document naar één vector. De cross-encoder reranker (trager) ziet document + query samen en beoordeelt hun relevantie per token. Bij top-20-reranking voegt het 50–200 ms latency toe, maar precision@5 stijgt typisch met 12–18 %.
Topkeuzes in 2026
**Cohere Rerank 3** - Prijs: 2,00 USD / 1 000 search units (1 unit = 1 query + tot 100 documents) - Multilingual: uitstekend - Latency: ~100–150 ms per query (top-20 rerank) - API: eenvoudig, EU-endpoint beschikbaar - **Wanneer:** cloud-setup, multilingual content, premium-kwaliteit
**BAAI/bge-reranker-v2-m3 (BGE Reranker v2 M3)** - Prijs: self-hosted - Multilingual: uitstekend (zelfde training als BGE-M3) - Latency: ~80–120 ms op RTX 4090 voor top-20 - **Wanneer:** self-hosted setup, SOTA open-source keuze voor multilingual
**cross-encoder/ms-marco-MiniLM-L-6-v2** - Prijs: self-hosted, klein model (66 M parameters) - Multilingual: zwak (EN-trained) - Latency: ~30 ms op GPU - **Wanneer:** budgetset-up, EN-only
**Geen reranker (baseline)** - Prijs: nul - **Wanneer:** PoC, laag volume, latency onder 200 ms is vereist
Concrete benchmark — reranker toevoegen aan bestaande pipeline
Juridisch RAG, BGE-M3 retrieval, top-20 → top-5: - Zonder reranker: precision@5 = 0,81, latency 250 ms - Cohere Rerank 3: precision@5 = 0,88, latency 380 ms - BGE-Reranker-v2-m3 (self-hosted): precision@5 = 0,89, latency 340 ms
**Een reranker verhoogt precision met 7–8 % voor 130–150 ms.** Voor een gereguleerde knowledge base (recht, geneeskunde, finance) is dat altijd de moeite waard. Voor een low-stake chatbot (FAQ) kan een reranker overbodig zijn — afhankelijk van de prijs van één fout antwoord.
Hybride retrieval — wanneer trefwoorden én semantiek tellen
Bij content waar **trefwoorden op zichzelf waarde hebben** (wetnummers, paragrafen, GUID's, normnummers, exacte productnamen) kan dominantie van dense embedding-retrieval falen. De embedding vangt semantische gelijkenis op, maar een letterlijke match op "§ 271 lid 2" kan in de semantische norm verloren raken.
**Oplossing: hybride retrieval** = parallel BM25 (sparse, keyword-based) + dense embedding retrieval, resultaten samengevoegd (meestal via `reciprocal_rank_fusion`).
Stack in 2026: Qdrant 1.10+ met native sparse vectors + dense vectors, OpenSearch met pgvector layer, of Weaviate hybrid search API. Configuratie: alpha-parameter bepaalt het gewicht (0 = puur BM25, 1 = puur dense, default 0,5).
**Benchmark hybride retrieval voor juridisch corpus:** - BM25 only: precision@5 = 0,68 (uitstekend voor "§ 271", zwak voor "wat geldt bij opzegging om gezondheidsredenen") - Dense (BGE-M3) only: precision@5 = 0,81 - Hybrid (alpha=0,5): precision@5 = 0,87
Voor juridische / medische / technische normcontent is hybride significant beter. Voor conversationele FAQ-content krimpt het verschil tot 1–2 %.
Praktisch beslissingsraamwerk
1. **Welk type content?** Conversationele FAQ/blogposts → dense embedding voldoet. Gestructureerde documenten met secties/paragrafen → document-aware chunking is verplicht. 2. **Welke taal?** EN-only → MTEB-top performer (Voyage, BGE-M3, OpenAI). Multilingual EU-talen → BGE-M3, Cohere multilingual-v3. 3. **Welk budget?** Alleen cloud → OpenAI 3-large + Cohere Rerank 3. Self-hosted → BGE-M3 + BGE-Reranker-v2-m3. 4. **Welke latency tolereert u?** < 200 ms → zonder reranker of klein cross-encoder. 200–500 ms → volledige pipeline met reranker. 5. **Zijn trefwoorden kritisch?** Ja → hybride BM25 + dense. Nee → puur dense. 6. **Wat is het queryvolume?** Bij > 100 RPS verdient self-hosted stack zich binnen 4–8 maanden terug.
Praktische iteratie
Het tunen van RAG is geen "stel één keer in, klaar"-project. De iteratiestack die wij hanteren:
1. **Eval-set:** 200+ realistische queries + handmatig geannoteerde "ideale" brondocumenten. Zonder dit kan verbetering niet worden gemeten. 2. **Baseline:** eerst een eenvoudige pipeline (fixed chunking + één embedding-model + geen reranker). Score = baseline. 3. **Wijzig één parameter per keer:** chunking → embedding → reranker → hybrid. Meet na elke wijziging precision@5, recall@10, latency. 4. **Stop wanneer marginal cost > marginal benefit.** Doorgaans vereist precision@5 boven 0,90 disproportioneel veel werk — een fine-tuned embedding of een custom reranker die zich niet uitbetaalt bij use-cases met tolerante kwaliteit.
In een juridische RAG voor 12 000 documenten brachten we in 4 weken precision@5 van 67 % naar 88 %. De volgende 4 weken zouden ons waarschijnlijk op 90 % brengen. De klant koos voor stoppen — 88 % was operationeel voldoende en nog 5 weken GPU + engineer-tijd verdienden zich niet terug.
---
*Wij doen RAG-architectuur + tuning voor B2B knowledge bases met 1k–10M documenten. Hebt u een bestaande pipeline en blijft precision@5 onder 75 % steken, dan doorlopen we in een audit van 90 minuten concreet de drie instellingen voor uw content en geven u een cijfermatige baseline voor de tuning-roadmap.*