RAG in Productie: Retrieval-Augmented Generation Bouwen voor Bedrijven

Grote taalmodellen zijn indrukwekkend capabel, maar ze hallucineren, hun kennis is bevroren op het moment van training, en ze hebben geen toegang tot uw bedrijfsdata. Retrieval-Augmented Generation (RAG) lost alle drie de problemen op door LLM-antwoorden te baseren op opgehaalde documenten. Het concept is eenvoudig — relevante context in de prompt voeden — maar het bouwen van een productiewaardig RAG-systeem is een engineeringuitdaging die veel teams verrast.

Dit artikel destilleert lessen uit enterprise RAG-implementaties, met specifieke aandacht voor patronen die relevant zijn op de Nederlandse markt: meertalige retrieval (Nederlands/Engels), AVG-conforme datapipelines en integratie met Europese cloudproviders.

De RAG-architectuurstack

Een productie-RAG-pipeline bestaat uit vijf fasen:

• 1. Ingestie — documenten worden geparsed, opgeschoond en in chunks verdeeld
• 2. Embedding — chunks worden omgezet naar vectorrepresentaties
• 3. Indexering — vectoren worden opgeslagen in een vectordatabase
• 4. Retrieval — gebruikersquerys worden gematcht tegen opgeslagen vectoren
• 5. Generatie — opgehaalde context wordt doorgegeven aan een LLM voor antwoordsynthese

Elke fase kent eigen engineeringbeslissingen.

Fase 1: Ingestie en Chunking

Chunking bepaalt of een RAG-pipeline slaagt of faalt. Het doel is om zelfstandige, semantisch betekenisvolle teksteenheden te creeren die onafhankelijk opgehaald kunnen worden.

Chunkingstrategieen

| Strategie | Geschikt voor | Typische grootte | |-----------|---------------|-----------------| | Vaste grootte | Eenvoudige, uniforme documenten | 256-512 tokens | | Recursief/semantisch | Lange documenten met structuur | 512-1024 tokens | | Documentbewust | PDFs, HTML met koppen | Sectieniveau | | Zinsvenster | Conversatie, Q&A-stijl retrieval | 3-5 zinnen | | Ouder-kind | Juridische, regulatoire documenten | Alinea + sectiecontext |

De Nederlandse taaluitdaging: Nederlandse samengestelde woorden (bijv. *arbeidsongeschiktheidsverzekering*) en langere gemiddelde zinslengte betekenen dat tokengebaseerde chunkgroottes 10-15% groter moeten zijn dan Engelstalige standaardwaarden om te voorkomen dat semantische eenheden midden in een gedachte worden gesplitst.

Praktische Tips

• Bewaar metadata: Sla documenttitel, sectiekop, paginanummer en bron-URL op bij elke chunk. Dit maakt bronvermelding en filtering mogelijk bij het opvragen.
• Overlap chunks met 10-15%: Zorgt dat context niet verloren gaat op grenzen.
• Behandel tabellen apart: Extraheer tabellen als gestructureerde data en embed ze met beschrijvende bijschriften in plaats van rauwe celtekst.
• Versiebeheer van chunks: Wanneer brondocumenten worden bijgewerkt, moet u opnieuw chunken en embedden — houd bij welke chunks bij welke documentversies horen.

Fase 2: Embeddingmodellen

Het embeddingmodel bepaalt hoe goed uw retrieval semantische betekenis vastlegt.

Modelopties (2026 Landschap)

| Model | Dimensies | Meertalig | Opmerkingen | |-------|----------|-----------|-------------| | OpenAI text-embedding-3-large | 3072 | Ja | Sterke Nederlandse prestaties, hosted API | | Cohere embed-v4 | 1024 | Ja | Goed voor zoeken, ondersteunt compressie | | E5-mistral-7b-instruct | 4096 | Ja | Open-source, zelf te hosten | | multilingual-e5-large | 1024 | Ja | Uitstekend voor Nederlands/Engels gemengde corpora | | BGE-M3 | 1024 | Ja | Multigranulariteit, ondersteunt sparse+dense |

Voor Nederlandse bedrijven die gevoelige data verwerken (zorg, financien, overheid) zijn zelf-gehoste modellen als E5-mistral of BGE-M3 aantrekkelijk omdat data uw infrastructuur nooit verlaat — een belangrijke AVG-overweging.

Embedding Best Practices

• Normaliseer tekst voor embedding: consistente hoofdletters, witruimte en encoding
• Embed querys anders dan documenten: Veel modellen ondersteunen instructie-prefixed embeddings (bijv. "Zoek relevante documenten voor: [query]") — gebruik ze
• Benchmark op uw eigen data: Publieke benchmarks (MTEB, BEIR) zijn nuttige baselines, maar uw domeinvocabulaire weegt zwaarder dan generieke prestaties

Fase 3: Vectordatabases

Uw keuze van vectordatabase beinvloedt latentie, schaalbaarheid en operationele complexiteit.

Opties Vergeleken

| Database | Type | Managed | EU-hosting | Hybride zoeken | |----------|------|---------|-----------|----------------| | Weaviate | Purpose-built | Ja | Ja (hoofdkantoor Amsterdam) | Ja | | Qdrant | Purpose-built | Ja | Ja (EU-regios) | Ja | | Pinecone | Purpose-built | Ja | Ja (EU-regio) | Ja | | pgvector | PostgreSQL-extensie | Via managed PG | Ja | Via SQL | | Milvus | Purpose-built | Ja (Zilliz) | Ja | Ja |

Nederlandse markt: Weaviate is opgericht in Amsterdam en is populair bij Nederlandse bedrijven vanwege de hybride zoekmogelijkheden en lokale ondersteuning. Als u al PostgreSQL draait, biedt pgvector een lagere drempel met trade-offs op schaal.

Belangrijke Ontwerpbeslissingen

• Namespace-isolatie: Gescheiden vectorruimten per tenant, afdeling of dataclassificatieniveau
• Hybride zoeken: Combineer dense vectoren met sparse (BM25/keyword) zoekopdrachten — dit presteert consistent beter dan beide benaderingen apart, vooral voor Nederlandse vaktermen
• Filtering: Gebruik metadatafilters om zoekopdrachten te beperken tot specifieke documenttypen, datumbereiken of toegangsniveaus
• Indextuning: HNSW-parameters (ef_construction, M) ruilen nauwkeurigheid in voor snelheid — benchmark met uw werkelijke data

Fase 4: Retrieval en Re-Ranking

Ruwe vectorovereenkomst is een startpunt, geen eindpunt.

Het Tweefasen-retrievalpatroon

• 1. Brede retrieval: Haal top-50 kandidaten op via vectorzoekopdracht (snel, bij benadering)
• 2. Re-ranking: Score kandidaten met een cross-encodermodel (langzamer, nauwkeuriger) en retourneer top-5

Cross-encoder re-rankers zoals Cohere Rerank, Jina Reranker of de open-source BGE-reranker-v2-m3 verbeteren de antwoordkwaliteit drastisch — vaak de enkele wijziging met de hoogste ROI in een RAG-pipeline.

Geavanceerde Retrievaltechnieken

• Querydecompositie: Splits complexe vragen in subquerys, haal op voor elk en voeg resultaten samen
• HyDE (Hypothetical Document Embeddings): Genereer een hypothetisch antwoord, embed dat en gebruik het voor retrieval — werkt goed voor abstracte vragen
• Self-query: Laat het LLM metadatafilters extraheren uit de natuurlijke-taalvraag van de gebruiker voor retrieval
• Contextuele retrieval: Voeg documentniveaucontext toe aan elke chunk voor embedding (zoals beschreven in [Anthropic's onderzoek](https://www.anthropic.com/news/contextual-retrieval)) — vermindert retrievalfouten met 49%

Fase 5: Generatie

Met relevante context opgehaald draait de generatiestap om het juiste prompt en het afhandelen van edge cases.

Belangrijke Overwegingen

• Stel een contextvensterbudget in: Reserveer tokens voor opgehaalde context, systeemprompt en verwachte antwoordlengte. Met moderne modellen die 128K+ tokens ondersteunen is de verleiding groot alles erin te proppen — weersta dit. Meer context betekent niet altijd betere antwoorden.
• "Ik weet het niet" afhandelen: Het systeem moet netjes toegeven wanneer het onvoldoende informatie heeft in plaats van te hallucineren.
• Taaldetectie: In Nederlandse bedrijfsomgevingen wisselen gebruikers mid-conversatie tussen Nederlands en Engels. Detecteer de taal en reageer dienovereenkomstig.
• Bronvermelding: Voeg bronverwijzingen toe in gegenereerde antwoorden zodat gebruikers claims kunnen verifieren.

Evaluatie: RAG-kwaliteit Meten

Wat je niet meet, kun je niet verbeteren. RAG-evaluatie vereist het beoordelen van zowel retrieval- als generatiekwaliteit.

Retrievalmetrieken

• Recall@k: Welk percentage relevante documenten verschijnt in de top-k resultaten?
• MRR (Mean Reciprocal Rank): Hoe hoog staat het eerste relevante resultaat?
• Precision@k: Welk percentage van de top-k resultaten is daadwerkelijk relevant?

Generatiemetrieken

• Getrouwheid: Houdt het antwoord zich aan de opgehaalde context? (Gebruik LLM-as-judge of het [RAGAS](https://docs.ragas.io/) framework)
• Relevantie: Beantwoordt het antwoord de vraag?
• Volledigheid: Dekt het antwoord alle aspecten van de vraag?

Praktische Evaluatie

Bouw een gouden dataset van 100-200 vraag-antwoordparen met geannoteerde brondocumenten. Draai geautomatiseerde evaluaties bij elke pipelinewijziging. RAGAS en DeepEval zijn open-source frameworks die dit automatiseren.

Veelvoorkomende Valkuilen

• 1. Re-ranking overslaan: Vectorovereenkomst alleen is niet genoeg — re-ranking verbetert de kwaliteit consistent
• 2. Chunkkwaliteit negeren: Rommel erin, rommel eruit. Investeer tijd in uw chunkingstrategie
• 3. Embeddings niet versioneren: Als u van embeddingmodel wisselt, worden alle opgeslagen vectoren incompatibel
• 4. RAG als set-and-forget behandelen: Documenten veranderen, modellen verbeteren en gebruikersbehoeften evolueren — bouw voor continue iteratie
• 5. Te veel ophalen: Het contextvenster overspoelen met marginaal relevante chunks verslechtert de antwoordkwaliteit
• 6. Toegangscontrole verwaarlozen: In enterprise-omgevingen mag niet elke gebruiker elk document zien — implementeer permissiebewuste retrieval

Kostenoptimalisatie

RAG-kosten komen uit drie bronnen: embeddingberekening, vectoropslag en LLM-inference.

• Cache embeddings: Embed nooit ongewijzigde documenten opnieuw
• Comprimeer vectoren: Kwantisatie (bijv. Weaviates PQ, Qdrants scalar-kwantisatie) kan opslag met 4-8x verminderen bij minimaal kwaliteitsverlies
• Gebruik getrapte modellen: Snelle, goedkope modellen voor initiele retrieval; krachtige modellen voor uiteindelijke generatie
• Batch embed: Verwerk documenten in batches tijdens daluren

Aan de Slag

Voor Nederlandse bedrijven die aan hun RAG-reis beginnen:

• 1. Begin met een beperkte scope — een documentcollectie, een use case
• 2. Gebruik een managed vectordatabase om operationele overhead te vermijden
• 3. Implementeer re-ranking vanaf dag een
• 4. Bouw evaluatie in uw pipeline, niet als nagedachte
• 5. Plan voor meertaligheid vanaf het begin — Nederlandse ondersteuning achteraf inbouwen is lastiger dan het er direct in bouwen

Ontdek onze automatiserings- en DevOps-diensten voor hulp bij het bouwen van productie-RAG-systemen, of lees onze artikelen over data engineering trends en databeheer.