RAG-evaluatie: retrieval-kwaliteit meten en verbeteren

RAG-evaluatie is hoe je erachter komt of je retrieval-augmented generation-systeem vragen écht goed beantwoordt — of ze alleen met veel zelfvertrouwen beantwoordt. Geeft je RAG-assistent foute, vage of half kloppende antwoorden, dan begint de oplossing bijna nooit bij een betere prompt. Ze begint bij meten. In deze gids lees je hoe je een RAG-pijplijn van begin tot eind evalueert: de retrieval-metrieken die laten zien of de juiste context überhaupt is gevonden, de generatie-metrieken die laten zien of het model die context getrouw heeft gebruikt, en een praktische manier om de testset op te bouwen die dat alles herhaalbaar maakt.

Het kernidee om vast te houden: een RAG-systeem heeft twee motoren, en een slecht antwoord kan uit beide komen. Retrieval kan de juiste passage niet ophalen, of generatie kan een perfect opgehaalde passage negeren, verkeerd lezen of aandikken. Gooi je die twee op één hoop, dan verspil je weken aan het finetunen van de verkeerde helft. Goede RAG-evaluatie houdt ze gescheiden, meet elk apart en wijst precies aan waar het antwoord misging.

Waarom een RAG-systeem faalt zonder het te melden

Traditionele software faalt luidruchtig — een exception, een stacktrace, een 500. Een RAG-systeem faalt stilletjes. Het levert een vloeiende, aannemelijke, keurig opgemaakte alinea die toevallig fout is. Niemand ziet een rode foutmelding. De gebruiker krijgt gewoon verkeerde informatie, met volle overtuiging gebracht, en tenzij iemand toevallig het juiste antwoord kent, blijft de fout onzichtbaar. Dát maakt RAG riskant in productie, en dáárom is "het lijkt te werken" geen kwaliteitsnorm waarop je kunt bouwen.

De enige verdediging is systematisch meten. Je kunt niet honderd antwoorden op het oog beoordelen en dat evaluatie noemen, en je gaat zeker niet live op basis van een demo waarin je de drie vragen uitkoos die het goed had. Je hebt cijfers nodig die meebewegen met de kwaliteit — en je moet weten welk cijfer naar welk deel van de pijplijn wijst. Dat is dezelfde discipline die we bij elke LLM-optimalisatie hanteren: eerst meten, dan finetunen.

Splits het probleem: retrieval versus generatie

Voordat je iets meet, moet die splitsing er goed in zitten. Een RAG-antwoord is niet beter dan twee dingen achter elkaar. Eén: haalde de retriever de passages op die het antwoord daadwerkelijk bevatten? Twee: produceerde het taalmodel, gegeven die passages, een antwoord dat er getrouw aan is en relevant voor de vraag? Dat zijn verschillende fouten met verschillende oplossingen.

Is retrieval kapot, dan redt geen enkele prompt-engineering je — het model moet antwoorden uit de verkeerde pagina's. Is generatie kapot, dan is een perfecte retriever verspilling omdat het model negeert wat het krijgt aangereikt. Elke metriek hieronder hoort bij één kant van die lijn, en de eerste taak van evaluatie is je vertellen welke kant bloedt.

Retrieval-kwaliteit meten

Retrieval is in de kern een rangschikkingsprobleem: zet bij een vraag de juiste chunks bovenaan. De metrieken die ertoe doen zijn de klassieke information-retrieval-maten, berekend over een set vragen waarvan je weet welke documenten relevant zijn.

Recall@k

Van alle passages die voor een vraag opgehaald hadden moeten worden — welk deel stond er in je top-k? Recall@k is de belangrijkste retrieval-metriek voor RAG, want zit de antwoorddragende chunk niet in de top-k die je het model voert, dan kán het model zijn antwoord er onmogelijk op baseren. Lage recall is de meest voorkomende — en meest over het hoofd geziene — oorzaak van slechte RAG-antwoorden.

Precision@k

Van de k passages die je ophaalde, welk deel was echt relevant? Precisie telt omdat irrelevante chunks geen onschuldige opvulling zijn — ze verdunnen de context, leiden het model af en kunnen het antwoord naar een aannemelijke maar foute zijweg trekken. Hoge recall met lage precisie betekent dat je de juiste passage in ruis verdrinkt.

MRR en nDCG

De rangpositie telt, niet alleen de aanwezigheid. Mean Reciprocal Rank (MRR) beloont het zo hoog mogelijk zetten van het eerste relevante resultaat — het geeft om waar de eerste juiste treffer landt. Normalised Discounted Cumulative Gain (nDCG) gaat verder en beloont systemen die álle relevante passages hoog rangschikken en straft relevante resultaten die onderaan verstopt zitten. Samen vertellen ze of je retriever het antwoord slechts bevat of het ook echt naar boven haalt.

Lees ze als een set. Sterke recall maar zwakke MRR betekent dat de juiste chunk er wél is maar te laag staat, en een re-ranker helpt. Sterke precisie maar zwakke recall betekent dat je retriever te voorzichtig is en materiaal mist, en dan heb je betere chunking of hybride zoek nodig. Het patroon wijst de oplossing aan.

Generatie-kwaliteit meten

Stel even dat retrieval zijn werk deed. Het model heeft de juiste passages voor zich. Nu moet je meten of het antwoord dat het schreef vertrouwen verdient. Hier zijn referentievrije frameworks als RAGAS standaard geworden. RAGAS, geïntroduceerd in een artikel uit 2023 van Es en collega's, scoort RAG-antwoorden zonder voor elke vraag een met de hand geschreven modelantwoord nodig te hebben — en dát maakt routinematige evaluatie betaalbaar. De gepubliceerde metriekdefinities sluiten netjes aan op de vragen waar het echt om draait.

Faithfulness (gegrondheid)

Is elke bewering in het antwoord terug te voeren op de opgehaalde context, of verzon het model iets? Faithfulness meet je door het antwoord op te knippen in losse beweringen en elke daarvan te toetsen aan de aangeleverde passages. Dit is je hallucinatiedetector. Een zelfverzekerd antwoord met 70% faithfulness is een zelfverzekerd antwoord dat bijna een derde van zichzelf verzon — en in een juridische, medische of financiële context is dat een aansprakelijkheid, geen feature.

Antwoordrelevantie

Beantwoordt het antwoord daadwerkelijk de gestelde vraag, of is het een goed gegrond antwoord op een net iets andere vraag? Een model kan volkomen getrouw aan de context zijn en tóch de plank misslaan. Antwoordrelevantie vangt het "technisch juist maar nutteloos"-antwoord.

Context-precisie en context-recall

Deze beoordelen de opgehaalde context tegen het ideaal, vanuit de generatiekant. Context-recall vraagt of de passages alles bevatten wat nodig was om te antwoorden; context-precisie vraagt of de nuttige passages boven de nutteloze stonden. Ze vormen de brug tussen je retrieval-metrieken en je antwoordkwaliteit — en scoort een systeem goed op faithfulness maar slecht hier, dan heb je je knelpunt gevonden.

LLM-as-judge: krachtig, en stiekem feilbaar

De meeste van deze generatie-metrieken worden berekend door een ander taalmodel het antwoord te laten beoordelen — het "LLM-as-judge"-patroon. Het is oprecht nuttig: het schaalt naar duizenden voorbeelden, is snel en correleert op veel taken redelijk met menselijk oordeel. Zonder deze aanpak zou referentievrije evaluatie helemaal niet praktisch zijn.

Maar behandel de jury als een instrument dat kalibratie nodig heeft, niet als orakel. LLM-jury's dragen bekende biases: ze prefereren vaak langere antwoorden, kunnen de stijl van hun eigen modelfamilie bevoordelen, en hun scores schuiven als je het jurymodel of zelfs de prompt verandert. De eerlijke praktijk is de jury periodiek te toetsen aan menselijke beoordelingen op een steekproef, scores als trends te rapporteren in plaats van als absolute waarheid, en nooit één automatisch getal alleen een release te laten bewaken. Een jury die je nooit controleert, is gewoon een tweede model dat je blind besluit te vertrouwen.

De ondankbare kern: een gouden testset

Dit is het deel dat teams overslaan, en het is juist het deel dat het meest telt. Elke metriek hierboven heeft een set vragen nodig, gekoppeld aan de juiste antwoorden en de juiste bronpassages — een gouden testset. Zonder die set evalueer je niet; je gokt. Dit is het echte werk van RAG-evaluatie, en hier zit de hefboom.

Een goede testset komt uit echt gebruik, niet uit de fantasie achter een bureau. Verzamel de vragen die je gebruikers werkelijk stellen, inclusief de rommelige, dubbelzinnige en buiten-scope-vragen. Dek de lastige gevallen bewust af: vragen waarvan het antwoord over meerdere documenten loopt, vragen zonder antwoord in het corpus (het systeem hoort te weigeren, niet te verzinnen), bijna-identieke vragen met verschillende juiste antwoorden, en tijdsgevoelige vragen waar de juiste passage veranderde. Vijftig zorgvuldig gekozen, goed gelabelde vragen verslaan vijfhonderd luie. Zo'n set bouwen en onderhouden is net zozeer een dataprobleem als een ML-probleem, en het hangt nauw samen met de data-engineering die de pijplijn voedt.

Houd de set geversioneerd en stabiel. De hele bedoeling is dezelfde vragen te draaien na elke wijziging — een nieuwe chunking-strategie, een nieuw embeddingmodel, een nieuwe prompt — en de cijfers te zien bewegen. Verschuift de testset elke week, dan verlies je je nulmeting en daarmee je vermogen om te zeggen of er écht iets verbeterde.

Diagnose vóór reparatie

Zodra je metrieken op beide helften hebt, wordt diagnose bijna mechanisch. Neem een falend antwoord en stel twee vragen op volgorde. Zat de antwoorddragende passage in de opgehaalde context? Zo nee, dan is het een retrieval-probleem — stop met nadenken over de prompt. Zo ja, gebruikte het model die correct? Negeerde of verdraaide het een passage die er gewoon stond, dan is het een generatie-probleem.

Deze eenvoudige beslisregel bespaart enorm veel verspilde moeite. De fout die we het vaakst zien: teams die wekenlang prompts herschrijven om antwoorden te redden die al bij de retrieval-stap gedoemd waren, omdat de juiste chunk nooit in het contextvenster belandde. Meet eerst recall, en je weet binnen een middag of je aan de retriever of aan de generator sleutelt.

Retrieval verbeteren

Wijzen de cijfers naar retrieval, dan bewegen een handvol hefbomen recall en rangschikking het sterkst:

• Chunking. Te grote chunks begraven de relevante zin in ruis en verzieken de precisie; te kleine chunks verliezen de context die een passage betekenis geeft. Chunken op semantische of structurele grenzen — secties, clausules, kopjes — verslaat meestal splitsen op vaste grootte.
• Hybride zoek. Pure vectorzoek mist exacte termen — productcodes, namen, afkortingen — die een trefwoordzoek meteen vangt. Dense (embedding) en sparse (trefwoord/BM25) retrieval combineren tilt de recall op de vragen waar semantisch zoeken stilletjes faalt.
• Re-ranking. Een cross-encoder re-ranker herwaardeert de topkandidaten met veel meer precisie dan de eerste retriever. Is je recall hoog maar je MRR laag, dan is dit vaak de wijziging met het hoogste rendement.
• Metadata en filtering. Filteren op documenttype, datum of afdeling vóór het rangschikken verwijdert hele klassen fout-maar-vergelijkbare passages, en het is goedkoop toe te voegen.

Deze wijzigingen stapelen, maar alleen meten vertelt welke zijn brood verdiende. Voeg een re-ranker toe, draai de gouden set opnieuw, en houd hem alleen als de MRR echt bewoog.

Generatie verbeteren

Is retrieval solide maar blijven de antwoorden zwak, dan zitten de oplossingen aan de generatiekant. Scherp de prompt aan zodat het model expliciet de opdracht krijgt alleen uit de aangeleverde context te antwoorden en "ik weet het niet" te zeggen als de context het antwoord niet bevat — weigeren is een feature, geen mislukking. Maak de gegrondheid zichtbaar door te vragen om verwijzingen naar de gebruikte passages, wat de faithfulness verbetert én gebruikers een manier geeft om te controleren. En test het weigerpad bewust: een RAG-systeem dat zelfverzekerd vragen beantwoordt zonder bron is slechter dan één dat de leemte toegeeft. Bouw je een assistent over de kennisbank van een organisatie, dan laat ons stuk over RAG-assistenten over de kennisbank van een bedrijf zien hoe deze keuzes in de praktijk uitpakken.

Van offline testset naar productiemonitoring

Een gouden testset vertelt hoe het systeem presteert op de vragen die je bedacht op te nemen. Productie vertelt hoe het presteert op de vragen die je je nooit voorstelde. Beide tellen, en volwassen RAG-evaluatie loopt op twee klokken: offline evaluatie op de vaste testset vóór elke release, en online evaluatie op live verkeer erna.

Offline evaluatie is je regressiepoort. Koppel de gouden set aan je pijplijn zodat elke wijziging — een nieuw embeddingmodel, een herchunk, een prompt-aanpassing — de benchmark automatisch opnieuw draait en een release blokkeert als faithfulness of recall onder een afgesproken drempel zakt. Behandel een kwaliteitsregressie precies als een falende unittest: iets om te repareren vóór het live gaat, geen verrassing die je twee weken later uit klachten van gebruikers ontdekt.

Online evaluatie is van een andere aard. Hier kun je niet elk antwoord labelen, dus leun je op goedkopere signalen: duim-omhoog en duim-omlaag, of gebruikers dezelfde vraag herformuleren (een teken dat het eerste antwoord miste), hoe vaak het systeem weigert, en periodieke LLM-as-judge-scoring op een steekproef van echte gesprekken. Deze signalen brengen de faalvormen aan het licht die je testset niet dekt — nieuwe onderwerpen, verschuivende gebruikersintentie, en de trage drift die insluipt naarmate je onderliggende documenten veranderen. Zakken de live signalen, dan voer je de nieuw ontdekte lastige vragen terug in de gouden set, en versterken de twee klokken elkaar. Een testset die nooit groeit vanuit productie, veroudert langzaam.

De praktische discipline is expliciete doelen stellen in plaats van een perfecte score najagen. Bepaal welke faithfulness- en recall-niveaus goed genoeg zijn voor jouw risicoprofiel, sla alarm als je eronder zakt, en steek je verbeterinspanning in de vragen die daadwerkelijk falen — niet in het uitknijpen van nog een punt uit gevallen die al werken.

Wees eerlijk over de grenzen van geautomatiseerde metrieken

Geautomatiseerde evaluatie is onmisbaar, maar niet de hele waarheid, en een goede praktijk zegt dat ook. De metrieken meten proxy's — getrouwheid aan opgehaalde tekst, niet correctheid in de echte wereld; relevantie voor de vraag, niet nut voor de mens. Een systeem kan goed scoren en gebruikers tóch frustreren omdat de antwoorden, hoe accuraat ook, de verkeerde lengte, toon of mate van detail hebben. En LLM-jury's hebben, zoals gezegd, hun eigen blinde vlekken.

Houd dus een mens in de lus waar het telt. Geautomatiseerde metrieken zijn er om regressies snel te vangen en opties op schaal te vergelijken; periodieke menselijke review is er om te oordelen of het systeem echt behulpzaam is. De twee zijn aanvullend, geen vervanging. Elke leverancier die zegt dat één dashboardgetal bewijst dat hun RAG-systeem "95% accuraat" is, verkoopt je een proxy vermomd als garantie.

Evaluatie is ook governance

Voor Europese organisaties zit er een compliance-dimensie aan die evaluatie van goede gewoonte tot zorgvuldigheidsplicht maakt. De EU AI Act legt verplichtingen rond nauwkeurigheid, robuustheid en dossiervorming op aan AI-systemen met hoger risico, en nauwkeurigheid die je nooit hebt gemeten, kun je niet aantonen. Een gedocumenteerd evaluatieproces — een geversioneerde testset, bijgehouden metrieken, een verslag van wat er veranderde en wat dat met de kwaliteit deed — is precies het soort bewijs dat dat kader verwacht. Dezelfde logica draagt de meetfuncties van het NIST AI Risk Management Framework, dat meetbare, toetsbare prestaties als voorwaarde voor betrouwbare AI ziet. Evaluatie is niet alleen hoe je een betere assistent bouwt; het is hoe je bewijst dat hij klaar is om ingezet te worden.

Hier is geen onderzoekslab voor nodig. Wel de discipline om de juiste dingen te meten en de eerlijkheid om te handelen naar wat de cijfers zeggen. Zo pakken we elke RAG-bouw aan — je ziet het terug in onze casestudy's, of boek een gratis consult en we brengen de evaluatie in kaart die jouw systeem echt nodig heeft. Geeft je RAG-assistent antwoorden die je niet volledig vertrouwt, dan is de weg vooruit geen slimmere prompt. Het is meten.

Veelgestelde vragen