Waarom RAG-pipelines falen in productie (en hoe ze op te lossen)

Retrieval-Augmented Generation (RAG) is de dominante architectuur om Large Language Models te verankeren in eigen data. In theorie is het simpel: zet uw documenten om in embeddings, sla ze op in een vector database, voer een similarity search uit wanneer een gebruiker een vraag stelt, en geef de opgehaalde context door aan het LLM.

In de praktijk faalt deze naïeve aanpak spectaculair wanneer deze in productie wordt genomen. Het hallucineert, mist cruciale context en retourneert irrelevante chunks. Na het bouwen van enterprise-grade RAG-systemen voor financiële instellingen en advocatenkantoren hebben we de belangrijkste redenen geïdentificeerd waarom deze pipelines falen en de architectonische patronen die nodig zijn om ze te herstellen.

1. De chunking-strategie is te rigide

De meest voorkomende fout is het gebruik van chunking met een vaste grootte (bijvoorbeeld het splitsen van documenten na elke 500 tokens). Dit willekeurige opknippen scheurt zinnen in tweeën en scheidt cruciale context van de gegevens die ze beschrijven. Als de kop van een tabel zich bijvoorbeeld in Chunk A bevindt en de rijgegevens in Chunk B, gaat de semantische betekenis verloren.

De oplossing: Semantic Chunking Gebruik semantic chunking in plaats van het tellen van tokens. Dit houdt in dat de documentstructuur wordt geanalyseerd en opgesplitst op basis van koppen, alinea's en logische secties. Voor complexe documenten zoals PDF's gebruiken we gespecialiseerde vision-modellen of layout parsers om tabellen en grafieken als afzonderlijke semantische eenheden te extraheren. Bovendien zorgt het implementeren van overlappende chunks ervoor dat de context op de grenzen nooit volledig verloren gaat.

2. Uitsluitend vertrouwen op vector similarity

Vector embeddings zijn uitstekend in het vastleggen van semantische gelijkenis, maar ze zijn erg slecht in exacte zoekwoordmatches. Als een gebruiker zoekt naar "SKU-987452", kan een pure vector search documenten over vergelijkbare producten opleveren in plaats van de exacte SKU.

De oplossing: Hybrid Search (BM25 + Dense Vectors) Productiepipelines moeten hybrid search gebruiken. Door dense vector embeddings (voor semantische betekenis) te combineren met sparse keyword search zoals BM25 (voor exacte overeenkomsten), krijgt u het beste van twee werelden. Een orchestratielaag kan reciprocal rank fusion (RRF) gebruiken om de resultaten van beide ophaalmethoden samen te voegen, zodat zeer specifieke query's de exact vereiste documenten ophalen.

3. Het negeren van contextuele window-bloat

Het doorgeven van 15 opgehaalde chunks aan een LLM zonder filtering introduceert het "lost in the middle"-syndroom. LLMs vergeten of negeren vaak informatie die in het midden van hun context window is geplaatst, wat leidt tot verminderde logica en hallucinaties.

De oplossing: Re-ranking Voordat u opgehaalde chunks naar de LLM-generatiestap stuurt, haalt u ze door een cross-encoder re-ranker (zoals Cohere's Rerank of een gefinetunede cross-encoder). Waar vector search snel maar grof is, is een cross-encoder computationeel zwaar maar uiterst nauwkeurig, omdat deze de query en de chunk tegelijkertijd evalueert. Haal snel 50 chunks op, rangschik ze opnieuw en geef alleen de top 5 meest relevante chunks door aan het LLM.

4. Ongestructureerde metadata

Een vector database vol met text chunks zonder metadata is een black box. Als een gebruiker vraagt: "Wat waren onze Q3-inkomsten in 2025?", zal een naïeve vector search inkomstenrapporten uit 2022, 2023 en 2024 ophalen, simpelweg omdat de tekst semantisch vergelijkbaar is.

De oplossing: Metadata Filtering Elke chunk die in de vector database wordt geïnjecteerd, moet uitgebreid worden geannoteerd met metadata: datum, auteur, documenttype, toegangsniveau en categorie. Gebruik vóór het uitvoeren van de vector search een LLM router om filters uit de query van de gebruiker te extraheren. Als de gebruiker vraagt naar Q3 2025, moet het systeem een hard filter toepassen voor date >= 2025-07-01 AND date <= 2025-09-30 voordat er vectorafstanden worden berekend.

Het RAG-productieblauwdruk

Het bouwen van een betrouwbare RAG-pipeline vereist dat we wegblijven van de LangChain-handleidingen en een systems-engineering-benadering kiezen:

1. Intelligente Ingestie: Semantic chunking, OCR en metadata-extractie.
2. Hybrid Retrieval: Dense vectors + BM25 sparse vectors.
3. Re-ranking: Cross-encoder-evaluatie voor precisie.
4. Generatie: Prompt engineering die het LLM dwingt om zijn bronnen te citeren uit de verstrekte context.

Door deze architectonische patronen te implementeren, transformeren we fragiele prototypen in veerkrachtige, bank-grade intelligente systemen die meetbare bedrijfswaarde opleveren zonder de hallucinaties.