Van RAG-demo naar productie: de vijf dingen die stukgaan
Een RAG-demo bouw je in een middag. In productie breekt hij op vijf voorspelbare plekken: retrieval, chunking, verzonnen citaties, het ontbreken van een meetlat, en schaal. Wat wij tegenkwamen op 3,6 miljoen rechterlijke uitspraken.
Een RAG-demo is niet moeilijk. Documenten inlezen, in stukken hakken, embeddings maken, een vectordatabase erbij, een model ervoor — en op de tien vragen die je zelf verzint werkt het. Dat is precies het probleem: een demo bewijst dat de pijplijn draait, niet dat de antwoorden kloppen.
Wij draaien een RAG-systeem op 3,6 miljoen Nederlandse rechterlijke uitspraken. Retrieval loopt via SQLite FTS5 (een index van circa 19 GB) in combinatie met pgvector voor vectorzoeken. In dat traject gingen dezelfde vijf dingen stuk die bij vrijwel elk RAG-project stukgaan. Hieronder staan ze, met wat er tegen helpt.
1. Waarom haalt mijn RAG-systeem de verkeerde documenten op?
Omdat semantisch zoeken alléén niet is gebouwd voor exactheid. Een embedding vangt betekenis, en dat is precies wat je níet wilt bij een zaaknummer, een artikelnummer, een eigennaam of een datum. Zoek je op een specifiek nummer, dan levert een puur vectorzoek documenten op die "erover gaan" in plaats van het document dat het nummer bevat. Voor juridische, financiële en technische domeinen — waar identifiers de kern van de vraag zijn — is dat een fundamenteel probleem, geen afrondingsfout.
De praktische oplossing is hybride retrieval: full-text zoeken naast vectorzoeken, en de resultaten samenvoegen. Full-text (bij ons FTS5) pakt exacte termen, nummers en eigennamen; de vectorkant (pgvector) pakt parafrases en verwante begrippen. Daarna gaat er een reranker overheen die de gecombineerde kandidatenlijst opnieuw ordent op werkelijke relevantie voor de vraag.
Hybride retrieval plus reranking is geen luxe-optimalisatie voor later. Het is het verschil tussen een systeem dat het juiste document vindt en een systeem dat iets vindt dat erop lijkt.
2. Wat gaat er mis bij chunking?
Chunking is het opknippen van documenten in blokken die in de context van het model passen. Knip je op een vaste lengte, dan valt de knip vroeg of laat middenin een redenering: de overweging begint in blok 7 en de conclusie staat in blok 8. Het opgehaalde blok ziet er dan perfect uit — relevante termen, juiste toon — maar mist de helft van de betekenis.
Erger nog: zo'n half blok is niet herkenbaar kapot. Het model krijgt een grammaticaal correcte passage die de vraag lijkt te dekken, en beantwoordt de vraag op basis van een halve gedachte. Bij uitspraken is dat het verschil tussen "de rechtbank overwoog dat X" en "de rechtbank overwoog dat X, maar oordeelde anders".
Wat helpt: knip mee met de structuur van het document in plaats van op tekenaantal — kopjes, genummerde overwegingen, alinea's. Laat blokken licht overlappen zodat een gedachte niet precies op de grens sneuvelt. En geef elk blok metadata mee (bron, datum, plaats in het document), zodat een blok ook los interpreteerbaar blijft.
3. Hoe voorkom je dat het model een bron verzint?
Dit is de gevaarlijkste faalmodus, en wel om één reden: het ziet er goed uit. Een taalmodel dat de opmaak van een ECLI-nummer heeft geleerd, kan er feilloos één produceren die niet bestaat. Correct formaat, plausibel jaartal, geloofwaardige instantie — en volledig verzonnen. Een lezer die de verwijzing niet natrekt, ziet het verschil niet. Een lezer die hem wél natrekt, verliest het vertrouwen in het hele systeem.
Bronvermelding alleen lost dit dus niet op; die maakt de verzinsels alleen overtuigender. Wat wél helpt is citatie-verificatie als aparte stap na generatie. In ons systeem wordt gecontroleerd of een aangehaalde ECLI daadwerkelijk bestaat, en of de aangehaalde passage de claim ook echt dekt. Haalt een claim die controle niet, dan wordt hij gemarkeerd — niet stilzwijgend meegeleverd.
Belangrijk om eerlijk over te zijn: RAG met verificatie dringt hallucinatie terug en maakt hem meetbaar, maar sluit hem niet volledig uit. Wie garanties belooft, verkoopt iets anders dan een taalmodel. Het realistische doel is dat onbewezen claims zichtbaar zijn in plaats van onzichtbaar. Meer daarover in waarom RAG zonder bronvermelding waardeloos is.
4. Hoe weet je of je RAG-systeem beter wordt?
Meestal: dat weet je niet. Het typische verbetertraject is een reeks losse ingrepen — andere chunkgrootte, ander embeddingmodel, aangepaste prompt — waarna iemand vijf vragen stelt, tevreden knikt en doorgaat. Dat is geen meting, dat is een steekproef van één. Ondertussen kan diezelfde wijziging een hele categorie vragen slechter hebben gemaakt zonder dat iemand het merkt.
Wat je nodig hebt is een evaluatieharnas met een goldenset: een vaste set vragen met gecontroleerde antwoorden die bij elke wijziging opnieuw draait. Bij ons meet dat harnas kwaliteit én hallucinatiegraad, zodat regressie zichtbaar wordt vóórdat een wijziging productie haalt. De goldenset hoeft niet groot te zijn om nuttig te zijn — hij moet vooral de randgevallen bevatten waar het systeem eerder op onderuitging.
Bijkomend voordeel: een goldenset maakt discussies concreet. "Voelt beter" wordt vervangen door een verschil dat je kunt aanwijzen — en soms door de constatering dat de mooie nieuwe aanpak niets oplevert.
5. Wat verandert er als je opschaalt?
Alles wat op 500 documenten irrelevant was. Op die schaal past de index in het geheugen, is elke query snel genoeg, en zijn de kosten verwaarloosbaar. Op miljoenen documenten worden precies die drie dingen de bepalende factoren: index-grootte, latency en kosten per query. Bij ons is de FTS5-index circa 19 GB — een omvang die je dwingt na te denken over waar hij staat, hoe hij wordt herbouwd en wat er gebeurt tijdens een herbouw.
Latency is het tweede: hybride retrieval plus reranking plus generatie plus verificatie is een keten, en elke schakel telt op. Kosten zijn het derde. Een prototype waarbij niemand naar de rekening kijkt, wordt in productie een post die per query zichtbaar moet zijn. Daarom loggen wij per call model, tokens en kosten — zonder die logging kun je achteraf niet verklaren waar een rekening vandaan komt, laat staan hem sturen.
Op schaal telt ook leverancierrisico mee. Onze antwoordlaag is daarom modelagnostisch opgezet: elke API is inkoppelbaar, en valt er één uit, dan schuift het systeem door naar de volgende provider. Dat is geen theoretische netheid — het is het verschil tussen een storing bij je leverancier en een storing bij jou.
Wat onderscheidt een demo van een productiesysteem?
Kort samengevat: een demo laat zien dat de pijplijn draait. Een productiesysteem laat zien hoe vaak hij het goed doet, en wat het kost. Die vier verschillen doen het meeste werk:
- Hybride retrieval met reranking in plaats van vectorzoeken alleen.
- Structuurbewuste chunking in plaats van knippen op tekenaantal.
- Citatie-verificatie die controleert of de bron bestaat én de claim dekt.
- Een goldenset die bij elke wijziging opnieuw draait.
Hoe dat er in de praktijk uitziet — inclusief de keuzes rond index, retrieval en verificatie — staat uitgewerkt in onze showcase over de rechtspraak-zoekmachine.
Conclusie
De vijf breukpunten zijn voorspelbaar, en dat is goed nieuws: je kunt ze vóór de bouw adresseren in plaats van erna repareren. Retrieval hybride maken, chunken langs de structuur, citaties verifiëren, een goldenset aanleggen en vanaf dag één per call meten wat een antwoord kost. Geen van die vijf maakt hallucinatie onmogelijk — samen maken ze hem klein genoeg om mee te werken, en zichtbaar genoeg om over te beslissen.