Production RAG in 2026: hybride retrieval, reranking en hallucinatie terugdringen

Een RAG-demo is drie stappen — embedden, ophalen, genereren. Een productie-RAG-systeem is een keten van negen fasen: ingest, parsen, chunken, embedden, indexeren, ophalen, reranken, genereren, en daarna citeren en evalueren. De ongemakkelijke waarheid die praktijkmensen telkens herontdekken: de meeste fouten komen niet van het taalmodel. Ze komen uit de retrieval en de ingest die haar voedt.

Waarom accuratesse in de retrieval weglekt

Pure semantische (vector)zoek heeft een specifieke blinde vlek: letterlijke tokens. Vraag naar “foutcode TS-999” en een embeddingmodel geeft vrolijk algemene inhoud over foutcodes terug terwijl het de exacte string mist. Hetzelfde geldt voor SKU’s, ordernummers, onderdeelnummers en afkortingen — precies wat mensen typen en hardop zeggen. Embeddings vangen betekenis; ze zijn onbetrouwbaar bij zeldzame identifiers die ze in de training nooit zagen.

Hybride zoeken, samengevoegd met RRF

De gevestigde oplossing is hybride retrieval: draai BM25 — een probabilistische ranker uit de jaren 70 die exacte tokens matcht — naast dense vectorzoek, en voeg de twee samen. Reciprocal Rank Fusion (Cormack e.a., SIGIR 2009) doet dat met een formule van één regel, zonder scores, en een standaardconstante k=60, wat het probleem van onverenigbare score-schalen omzeilt. Op gemengde, realistische queries rapporteren geciteerde implementaties dat recall stijgt van ruwweg 65–78% met één methode naar ongeveer 91% met de twee samengevoegd. (Voor een puur-trefwoord- of puur-semantische workload kan één methode meekomen; hybride wint bij variatie.)

Chunken is een retrieval-beslissing, geen voorbewerking

Hoe je documenten splitst, bepaalt de accuratesse meer dan welk embeddingmodel je kiest. Vaste chunks van ~512 tokens met overlap zijn de oude standaard; layout-bewust en semantisch chunken doen het beter. Twee technieken uit 2024 geven elke chunk context van het hele document: Anthropics Contextual Retrieval, waarbij een LLM 50–100 tokens context per chunk schrijft (op hun eigen evaluatie sneden contextuele embeddings plus BM25 de top-20 retrieval-fouten met ongeveer 49%, en met reranking ongeveer 67%, vanaf een basis van 5,7%), en late chunking, dat eerst het hele document embedt en daarna per chunk poolt met alleen het embeddingmodel — goedkoper, zonder extra LLM-call.

De stap met het hoogste rendement is reranking

Na de retrieval heb je een snelle maar verlieslatende shortlist. Een cross-encoder reranker herwaardeert de top ~100–150 kandidaten door de query en elk document samen te lezen met volledige cross-attention — veel preciezer dan losse vectoren vergelijken, en veel te duur om over het hele corpus te draaien, wat precies de reden is voor twee fasen. Gerapporteerde winst ligt rond +10–30% precisie voor ~50–100 ms extra latentie, en is het grootst in juridisch, zorg en finance, waar trefwoordoverlap een slechte maat voor relevantie is. De rerankers van 2024–2025 (Cohere Rerank 3.5 en 4, Voyage rerank-2.5, BGE reranker v2-m3, Jina, Mixedbread) voegden lange context — tot 32K tokens — en instructievolging toe; de open-weight varianten doen ertoe wanneer je data intern moet houden.

Deze tweetrapsvorm — eerst embedden, dan reranken — is precies waarom onze eigen VeriRAG-familie zowel embeddings als reranking levert, niet slechts één.

Onderbouwing vermindert hallucinatie; ze elimineert die nooit

Geef het model alleen de bovenste gererankte passages en eis inline bronvermelding. Dat verlaagt verzinsels meetbaar en bespaart tokens — maar het bereikt geen nul. Op Vectara’s leaderboard voor onderbouwde samenvattingen hallucineren de beste modellen nog ~1,8–3% en zwakkere boven 20%, en citatienauwkeurigheid zonder attributietraining ligt rond 65–70%, dus een model kan met overtuiging de verkeerde chunk citeren. Retrieval is noodzakelijk, niet voldoende: betere recall betekent niet automatisch een correct antwoord.

Meet beide fasen, anders gok je

Behandel evaluatie als een permanente deploy-poort en houd twee scoreborden bij. Retrieval-metrieken (recall@k, NDCG) zeggen of het juiste bewijs is gevonden; generatie-metrieken (faithfulness, context-precisie en -recall) of het antwoord het ook gebruikte. Referentievrije frameworks als RAGAS splitsen een antwoord in atomaire claims en toetsen elk aan de opgehaalde context. Het zijn LLM-gebaseerde schatters met eigen ruis, dus combineer ze met menselijke steekproeven en een vaste golden set, en versioneer het judge-model.

Maakt een contextvenster van een miljoen tokens RAG overbodig?

Nee — de consensus van 2026 is routeren, niet vervangen. Lange context heeft echte faalmodi: het “lost in the middle”-effect, waarbij accuratesse piekt als de relevante passage vooraan of achteraan staat en inzakt in het midden; en effectieve recall die ver onder het geadverteerde maximum degradeert. Het is ook veel trager en duurder per query dan retrieval. En een groot venster lost drie dingen nooit op: actualiteit (verouderde context scoort net zo zelfverzekerd als actuele), toegangscontrole per document, en kosten op schaal. Gebruik lange context om diep te redeneren over een bekend document; gebruik RAG wanneer het corpus groot, veranderlijk of rechtengevoelig is — vaak wil je beide.

Het stuk dat de meeste gidsen overslaan: je documenten verlaten het gebouw

Elke fase hierboven kan een API-call van derden zijn, en elk daarvan stuurt je gevoeligste documenten van je systeem af. Ruwe tekst naar een gehoste embeddingdienst sturen stelt die documenten bloot op het moment van het verzoek — “alleen vectoren verlaten het pand” is geen veiligheidsgarantie. Voor gereguleerde data draait de duurzame architectuur de hele stack binnen je eigen perimeter: open embedding- en rerankingmodellen, een zelf-gehoste vector-store, open-weight inferentie. En rechten-bewuste retrieval hoort in de retrieval-laag — tag chunks met toegangsmetadata bij het indexeren en filter per gebruiker in de query — want filteren in de applicatielaag kan een correct antwoord teruggeven uit een document dat de gebruiker nooit mocht zien.

Waar Arpanet past

Dit is de vorm waarvoor we bouwen. Onze VeriRAG-familie dekt de retrieval-helft — embeddings en reranking — terwijl Qevron, onze OpenAI-compatibele gateway, generatie achter één API zet over onze eigen modellen en 43+ providers, met caching, routing en kostenanalyse. Producten als Calleague draaien precies deze pijplijn — hybride retrieval, reranking, onderbouwde bronvermelding — over echte workloads. En omdat de modellen en de gateway van ons zijn, kan de hele RAG-stack on-prem, volledig geïsoleerd of in de cloud draaien, zodat je documenten je perimeter nooit hoeven te verlaten. Vanaf het ontwerp op de AVG (GDPR) gebouwd.

Betere retrieval — geen groter model — is de goedkoopste accuratesse die je kunt kopen, en de enige soort die je binnen je eigen muren kunt houden.

RAG is in 2026 een engineeringdiscipline, geen prompt. Krijg de retrieval goed, rerank de shortlist, onderbouw elk antwoord met geciteerd bewijs, meet beide fasen — en beslis bewust op wiens servers je documenten draaien.