De meeste RAG-tutorials eindigen precies waar de productie begint. Je splitst je documenten in chunks van 512 tokens, haalt ze door een enkel embedding-model en roept een vectordatabase aan met eenvoudige top-k retrieval. In een demo ziet dit er overtuigend uit. Vraag de bot naar het verlofbeleid van het bedrijf en hij geeft een samenhangende paragraaf terug. Iedereen knikt instemmend. Helaas liegen demo's.

Productie legt elke shortcut bloot. Vaste chunks snijden dwars door juridische contracten, midden in vrijwaringsclausules. API-documentatie verandert in overlappende ruis die de signalen die je eigenlijk nodig hebt, overstemt. De latentie kruipt omhoog totdat gebruikers de zoekopdracht opgeven voordat het antwoord is gearriveerd. Wij liepen tegen deze muur aan en moesten alles opnieuw opbouwen. Onze retrieval-laag evolueerde van "semantisch zoeken en hopen" naar een gemeten, geïnstrumenteerde pipeline. Het resultaat was een recall van 95% en een vermindering van de latentie met 40%. Dit is wat er echt werkte.

Stem de chunking-strategie af op het document

De standaard van 512 tokens blijft bestaan omdat het makkelijk is, niet omdat het correct is. Verschillende documenten dragen betekenis op verschillende manieren over, en je chunking-strategie moet dat weerspiegelen.

Voor juridische contracten gebruik je recursieve chunking die de structurele grenzen respecteert. Juridische taal is genest. Een clausule is afhankelijk van de sectie erboven, en een vaste knip midden in een zin vernietigt de logica van een verplichting. Recursieve chunking probeert eerst splitsingen te maken op natuurlijke scheidingstekens — paragrafen, dan zinnen — voordat er een tokenlimiet wordt opgelegd. Dit houdt vrijwarings- of aansprakelijkheidsclausules intact.

Voor API-documentatie gebruik je functie-bewuste chunking. Ontwikkelaars zoeken niet naar willekeurige paragrafen; ze zoeken naar endpoints, parameters en foutsignaturen. Een chunk moet de volledige functiesignatuur, de beschrijving en het return-schema bevatten als één logische eenheid. Als je dat blok in tweeën splitst, geeft het retrieval-systeem slechts de helft van de context terug en hallucineert het generatiemodel de rest.

Voor supporttickets vertrouw je op semantische chunking die de gespreksbeurten volgt. Support-threads zijn lineair en repetitief. Een klant herhaalt het probleem, een agent vraagt om logs, de klant voegt ze toe. Elke beurt is een eigen semantische eenheid. Chunking op basis van beurten zorgt ervoor dat bewaard blijft wie wat wanneer zei, wat cruciaal is wanneer de gebruiker vraagt: "Wat suggereerde de agent op dinsdag?"

Voor interne wiki's kun je agentic chunking proberen. Geef een LLM een sectie en vraag het om te bepalen waar het ene onderwerp eindigt en het andere begint. Dit kost meer tijdens het ingest-proces, maar wiki's zijn rommelig. Pagina's bevatten niet-gerelateerde updates van verschillende teams, en een door mensen gedefinieerde grens helpt zelden. Door een model grenzen te laten trekken op basis van onderwerpverschuivingen, verminder je de ruis drastisch.

Het draaien van meerdere strategieën in één pipeline vereist dat documenten tijdens het ingest worden gelabeld op type. Die kleine hoeveelheid schema-discipline betaalt zich onmiddellijk uit.

Combineer zoekmethoden, kies er niet slechts één

Vector search begrijpt de intentie, maar faalt routinematig bij exacte overeenkomsten. Vraag om foutcode ERR_CONNECTION_REFUSED of een specifieke SKU, en dense embeddings geven vaak conceptueel vergelijkbare maar feitelijk onjuiste resultaten terug. BM25, de klassieke keyword sparse retrieval-methode, gaat uitstekend om met exacte strings, maar mist semantische nuance. Je hebt beide nodig.

Gebruik hybride retrieval. Voer vector search en BM25 parallel uit. Combineer ze vervolgens met Reciprocal Rank Fusion (RRF). RRF beloont documenten waar beide methoden het over de relevantie eens zijn, terwijl er nog steeds sterke kandidaten uit beide benaderingen naar boven komen. De wiskunde is eenvoudig en het resultaat is stabiel: geen enkele retrieval-methode domineert de uiteindelijke rangschikking.

Voeg na de fusie een cross-encoder reranker toe. De eerste fase — vector plus sparse retrieval — is snel en breed. De cross-encoder scoort vervolgens elk query-document-paar met volledige aandacht, wat betekent dat het de kandidaat daadwerkelijk afzet tegen de oorspronkelijke vraag. Ja, dit voegt latentie toe. In ons geval ongeveer vijftig tot honderd milliseconden. Maar de winst in precisie is groot genoeg om de afweging de moeite waard te maken. Je kunt het je niet veroorloven dit over te slaan als je om recall geeft.

Verbeter de query voordat je de index verbetert

Gebruikers schrijven geen queries voor jouw zoekmachine. Ze schrijven ze voor mensen. "Het werkt niet" is een veelvoorkomende support-query. Een vage beschrijving van een functie is een veelvoorkomende zoekopdracht in interne wiki's. Als je de index doorzoekt met die ruwe input, krijg je onzin terug.

Transformeer de query voordat deze de retriever bereikt.

Use query expansion to generate multiple versions of the user’s question. If someone types “server down,” your system should also search for “service unavailable,” “502 error,” and “connection timeout.” Covering these intent variants moved our recall from 78% to 96%. It is a single step, and it costs almost nothing compared to the gain.

Use query decomposition for complex questions. When a user asks something like “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?,” break it into sub-questions. One sub-question targets migration steps. Another targets enterprise-specific breaking changes. Each hits a different part of the index. The downstream language model synthesizes the final answer from well-retrieved chunks rather than guessing across a noisy context window.

Stop Guessing Hyperparameters

Once you have multiple chunking strategies, hybrid retrieval, and query transformation, you face a combinatorial problem. Chunk size, overlap, fusion weights, reranker depth, and expansion count all interact. Tweaking one in isolation breaks another. Grid search across this space is wasteful and slow.

Use Bayesian optimization instead. Treat this like a machine learning tuning job. Define your objective clearly: maximize recall while keeping latency under a ceiling. Build a golden dataset — a few hundred representative questions where you know precisely which chunks should be retrieved. Then let the Bayesian search explore the configuration space efficiently. It builds a probabilistic model of what works and tests the most promising regions next.

Every candidate configuration must pass the golden dataset before it reaches staging. If a new chunk size drops recall or a heavier reranker pushes you past the latency budget, the optimization catches it automatically. This removes opinion from the room. You stop debating whether 256 or 512 tokens is “better” and start reading the results.

The Outcome

The pipeline changes compounded exactly as we hoped.

  • Recall@10 climbed from 78% to 95%.
  • P95 latency dropped from 850 ms to 320 ms.
  • Hallucination rate fell from 12% to 3%.
  • Cost per query dropped by 38%, largely because better retrieval let us use a smaller generation model and fewer prompt tokens.

The latency reduction surprised some people on the team. Adding rerankers and query expansion sounds like it should slow things down. But because retrieval quality improved, the generation model needed less prompting, less speculation, and fewer retries. Good retrieval makes everything downstream cheaper.

Treat Retrieval Like Infrastructure

Retrieval is not a notebook you run once and forget. It is infrastructure, and it should be managed like code. Version your chunking strategies. When the legal team releases a new contract template, test your recursive splitter before it reaches production. Maintain your golden dataset as living documents, not a static CSV from last quarter. Automate your evaluations in CI so that a pull request modifying an embedding model or a fusion weight gets a comment with recall and latency numbers before a human ever reviews it.

Your users will never ask which embedding model you run. They will not care about your chunking heuristic or your reranker architecture. They care if the answer is correct, if it arrives fast, and if they can trust it. Build a pipeline that earns that trust, measure it honestly, and stop treating retrieval like an afterthought.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community