RAG-implementatie: waarom naive RAG tekortschiet

Waar naive RAG strandt

Het standaardrecept, documenten in stukken knippen, embedden, bij een vraag de dichtstbijzijnde stukken ophalen en aan een LLM voeren, werkt verrassend goed in een demo en teleurstellend vaak nét niet in productie. Semantische gelijkenis is namelijk niet hetzelfde als relevantie. De vraag "wat kost een vergunning in Ede" levert stukken op die over kosten gaan, over vergunningen gaan, of over Ede gaan, en het stuk dat alle drie combineert staat lang niet altijd bovenaan.

In een demo valt dat niet op, want daar stelt de bouwer de vragen. In productie stellen gebruikers vragen waar de pipeline nooit op is geoefend, en elke misser ondermijnt het vertrouwen in alle antwoorden erna.

Wat een reranker toevoegt

Een reranker is een tweede beoordeling. De eerste zoekslag mag breed en snel zijn en vijftig kandidaten ophalen; de reranker legt daarna elke kandidaat naast de vraag en beoordeelt hoe goed ze echt bij elkaar passen. Dat is rekenwerk dat je niet over je hele corpus wilt doen, maar over vijftig kandidaten prima kan. De volgorde die eruit komt, is aantoonbaar beter dan wat vectorafstand alleen oplevert.

In ons eigen product TenderScan.nl, een zoekmachine en index voor aanbestedingen binnen Europa, is precies dit het verschil tussen "lijkt erop" en "is relevant". Gebruikers slaan zoekopdrachten op en krijgen wekelijks nieuw gevonden aanbestedingen; RAG met reranking zorgt dat die lijst relevanter is dan wat standaard zoeken oplevert. Dat draait in productie, niet in een notebook.

De afwegingen die echt spelen

Kwaliteit versus kosten. Elke stap in de pipeline, chunking, embeddings, ophalen, reranken, genereren, heeft een prijskaartje per vraag. De kunst is meten waar de kwaliteit vandaan komt en betalen waar het loont. Vaak blijkt een betere reranking meer waard dan een groter generatiemodel.

Beheer. Een RAG-pipeline is een levend systeem. Documenten veranderen, de index moet bij, en de kwaliteit moet bewaakt worden met een vaste evaluatieset in plaats van met onderbuikgevoel. Wie dat niet inricht, merkt kwaliteitsverval pas via klagende gebruikers.

Modelonafhankelijkheid. Wij zetten pipelines modelonafhankelijk op: van embeddingmodel, reranker of LLM wisselen is een configuratiekeuze, geen verbouwing. Modellen worden elk kwartaal beter en goedkoper; een pipeline die aan één aanbieder vastzit, kan die winst niet pakken. Vendor lock-in op je LLM-aanbieder is een keuze, en wat ons betreft de verkeerde.

Wanneer RAG de verkeerde oplossing is

Eerlijkheid verplicht: soms is RAG overkill. Past de kennis in de context van één prompt, dan is een goede prompt goedkoper en beter. Is het corpus klein en stabiel, dan komt klassiek zoeken met wat metadata een heel eind. RAG loont wanneer het corpus groot, veranderlijk of te divers is om in een prompt te passen, zoals bij duizenden aanbestedingen per week.

Verder lezen en praten

Hoe we dit soort systemen betrouwbaar houden staat op agentic workflows; wat er bij een LLM-integratie komt kijken op LLM koppelen aan je applicatie. De productiecases staan op wat we bouwen.

Overweeg je RAG voor je eigen data? We laten je graag zien wat het in jouw geval waard is, op je eigen documenten.