Teams die Retrieval-Augmented Generation (RAG) van een demo naar een productieservice verplaatsen, lopen tegen een handvol beslissingen aan die het verschil maken tussen een nuttige assistent en een assistent die veel ruis produceert. Vijf ontwerpkeuzes — chunking, het embeddingmodel, de vector store, hybrid search en evaluatie — bepalen de precisie, recall en latentie die echte gebruikers ervaren.

Waarom de stap van prototype naar productie belangrijk is

De meeste tutorials laten een RAG-pipeline draaien in een paar dozijn regels code, maar schieten tekort wat betreft de engineering-discipline die nodig is voor live verkeer.

1. Chunking-strategie – de eerste kwaliteitscontrole

De grootte van de chunks is het belangrijkst. Grote chunks overstemmen het signaal met ongerelateerde tekst; minuscule chunks ontnemen het model de omringende context die nodig is om coherente antwoorden te genereren. Splitsen op basis van een vaste grootte negeert de natuurlijke structuur van het bronmateriaal.

Praktische vuistregel

  • Splits op logische grenzen: koppen in documenten, alinea-overgangen in artikelen, functiedefinities in code.
  • Houd chunks klein genoeg voor nauwkeurige retrieval, maar behoud de grotere 'parent'-sectie voor de generatiestap van de LLM. Dit "parent-child"-patroon stelt de retriever in staat om een specifiek fragment naar boven te halen, terwijl de generator voldoende context ziet om feitelijk te blijven.

2. Embeddingmodellen – hoe gelijkenis wordt beoordeeld

Het embeddingmodel zet tekst om in vectoren die de similarity search engine vergelijkt. Een sterk algemeen model zoals OpenAI's text-embedding-3-large biedt een solide basis voor de meeste domeinen. Als het corpus zich in een zeer gespecialiseerd vakgebied bevindt — juridische adviezen, medische dossiers, technische specificaties — test dan een domeinspecifiek model, maar doe dit pas nadat je een tastbare verbetering op je eigen data hebt gemeten.

Wanneer overstappen

  • Stap alleen over als je een meetbare winst ziet in de relevantiescores die belangrijk zijn voor je applicatie (bijv. een hogere contextprecisie).

3. Vector database – het schalen van de opslag

Kies een vector store die past bij je bestaande infrastructuur en het verwachte aantal vectoren.

  • pgvector draait binnen PostgreSQL en kan probleemloos tot ongeveer een miljoen vectoren aan. Het is ideaal voor teams die al een relationele database beheren en een onderhoudsarme oplossing nodig hebben.
  • Qdrant blinkt uit in de range van 1M tot 100M, waarbij het een hogere doorvoer en lagere latentie biedt voor grotere corpora.
  • Pinecone biedt een volledig beheerde cloudservice, waardoor de operationele last van zelf hosten wegvalt.

4. Hybrid search en reranking – de balans tussen betekenis en exactheid

Pure vector search is uitstekend in semantische gelijkenis, maar kan exacte trefwoordovereenkomsten missen die gebruikers verwachten. Hybrid search legt een traditionele BM25-trefwoordindex over de vectorindex heen en voegt vervolgens de twee resultatenlijsten samen. Reciprocal Rank Fusion (RRF) wijst aan elke kandidaat een score toe op basis van de rangorde in beide lijsten en combineert deze, waarbij items die in een van beide lijsten hoog staan, worden gepromoot.

Reranking voegt een laatste precisiefilter toe. Voer na de hybride retrieval de top-N (meestal 50) kandidaten aan een cross-encoder — een model dat een query-documentpaar gezamenlijk scoort. De scores van de cross-encoder vervangen de oorspronkelijke similarity-cijfers, zodat je het meest relevante chunk kunt kiezen voordat je het naar de LLM stuurt. Deze extra stap levert vaak een merkbare sprong in antwoordkwaliteit op, vooral bij lange of ruisgevoelige corpora.

5. Evaluatie en abstention – meten wat belangrijk is

Je kunt een systeem dat je niet meet, niet verbeteren. Het RAGAS-framework stelt vier metrieken voor die samen de gezondheid van een RAG-pipeline weergeven:

  • Context Precision – het aandeel opgehaalde chunks dat daadwerkelijk het antwoord bevat.
  • Context Recall – het aandeel van alle relevante chunks dat is opgehaald.
  • Faithfulness – de mate waarin het gegenereerde antwoord binnen de opgehaalde context blijft, om hallucinaties te voorkomen.
  • Answer Relevance – hoe goed het uiteindelijke antwoord voldoet aan de oorspronkelijke query.

Houd deze metrieken bij op een voortdurende testset die het productieverkeer weerspiegelt.

Een laatste, vaak over het hoofd geziene beveiliging is abstention. In plaats van het model te dwingen te antwoorden bij een lage betrouwbaarheid, stel je een drempelwaarde in voor de faithfulness- of relevance-score die een "Ik weet het niet"-antwoord triggert. Gebruikers geven de voorkeur aan een duidelijke erkenning van onzek