Hoe meet je of je RAG-systeem beter wordt?

Je meet of een RAG-systeem beter wordt door niet alleen naar het uiteindelijke antwoord te kijken, maar de hele keten afzonderlijk te beoordelen: vindt het systeem de juiste informatie, gebruikt het die informatie correct en levert het een antwoord dat snel en tegen acceptabele kosten tot stand komt? Een goed evaluatiekader combineert daarom retrieval-metrics zoals precision en recall met antwoordkwaliteit, latency en kosten.

De basis daarvoor is een vaste eval-set of golden set: een verzameling representatieve vragen waarvan vooraf bekend is welke bronnen of passages relevant zijn en wat een goed antwoord minimaal moet bevatten. Door iedere versie van het systeem tegen dezelfde set te testen, zie je of een wijziging aan chunking, embeddings, prompts of het gebruikte model daadwerkelijk een verbetering oplevert — en of je niet ergens anders kwaliteit verliest.

Waarom alleen naar goede antwoorden kijken niet genoeg is

Bij traditionele software is vaak duidelijk of iets werkt: de juiste invoer geeft de verwachte uitvoer. Bij RAG is dat ingewikkelder. Een antwoord kan overtuigend klinken terwijl de retrieval verkeerde documenten heeft opgehaald. Andersom kan de retriever precies de juiste passages vinden, waarna het taalmodel daar alsnog een onvolledig of onnauwkeurig antwoord van maakt.

Daarom is het verstandig minimaal twee onderdelen apart te evalueren:

• Retrieval — wordt de juiste informatie gevonden?
• Generation — maakt het taalmodel daar een goed, onderbouwd antwoord van?

Daarnaast horen operationele eigenschappen zoals snelheid, stabiliteit en kosten bij de totale kwaliteit.

Hoe meet je de kwaliteit van retrieval?

Een RAG-systeem begint met zoeken. Komt de relevante informatie niet in de context terecht, dan kan zelfs een uitstekend taalmodel het juiste antwoord niet betrouwbaar formuleren. Twee klassieke begrippen zijn daarbij na reranking nog steeds leidend: precision en recall.

Retrieval precision

Precision kijkt naar het aandeel opgehaalde resultaten dat daadwerkelijk relevant is. Haalt een retriever vijf passages op en zijn er slechts twee nuttig voor de vraag, dan bevat de context relatief veel ruis. Een lage precision kan ertoe leiden dat het taalmodel irrelevante informatie moet verwerken of zich laat afleiden door passages die toevallig op de zoekvraag lijken.

Retrieval recall

Recall kijkt juist naar hoeveel van de relevante informatie het systeem terugvindt. Zijn voor een goed antwoord drie passages nodig en haalt het systeem er maar één op, dan mist het antwoord mogelijk belangrijke informatie.

Precision en recall kunnen botsen: meer passages ophalen verhoogt de kans dat de juiste informatie ertussen zit, maar voegt ook meer irrelevante tekst toe. Het doel is dus niet één metric maximaliseren, maar een goede balans vinden voor de toepassing. Meet daarnaast hoe vaak een relevante passage binnen de eerste paar zoekresultaten voorkomt — vooral belangrijk wanneer maar een beperkt aantal chunks naar het taalmodel gaat.

Hoe meet je antwoordkwaliteit?

Correcte retrieval garandeert nog geen goed eindantwoord. Ook de generation-stap moet worden geëvalueerd. Een belangrijke eigenschap is faithfulness, ook wel grounding genoemd: zijn de uitspraken in het antwoord daadwerkelijk te onderbouwen met de aangeleverde bronnen? Een RAG-systeem hoort geen extra details toe te voegen die het taalmodel uit zijn trainingsdata denkt te kennen, als die details niet in de opgehaalde context staan.

Daarnaast kun je kijken naar:

• Relevantie — beantwoordt het systeem daadwerkelijk de gestelde vraag?
• Volledigheid — bevat het antwoord de noodzakelijke informatie?
• Brononderbouwing — verwijzen citaties naar passages die de bewering echt ondersteunen?
• Weigeringsgedrag — geeft het systeem aan dat informatie ontbreekt wanneer de kennisbank onvoldoende bewijs bevat?

Voor sommige eigenschappen kun je automatische evaluatiemethoden of een tweede taalmodel als beoordelaar gebruiken. Voor belangrijke toepassingen blijft menselijke controle nuttig, vooral bij inhoudelijke nuance en foutgevoelige domeinen.

Bouw een golden set die op de praktijk lijkt

Zonder vaste testvragen is verbeteren grotendeels giswerk. Een golden set bestaat uit vragen die representatief zijn voor het daadwerkelijke gebruik van het systeem. Leg per vraag bijvoorbeeld vast:

• welke documenten of passages relevant zijn;
• welke feiten in een correct antwoord moeten voorkomen;
• welke bronverwijzingen verwacht worden;
• wanneer het systeem juist geen antwoord zou moeten geven.

Gebruik niet alleen eenvoudige vragen waarvan het antwoord letterlijk in één document staat. Neem ook lastigere gevallen op: synoniemen, formuleringen uit de praktijk, informatie verspreid over meerdere documenten en vragen waarvoor geen antwoord in de kennisbank aanwezig is. Voeg bovendien echte probleemgevallen toe zodra die in productie optreden — daarmee groeit de eval-set mee met het systeem.

Offline evalueren voordat je iets live zet

Veel wijzigingen aan een RAG-pipeline kun je eerst offline testen. Verander je de chunkgrootte, gebruik je een nieuw embeddingmodel of voeg je hybrid search toe? Laat dan zowel de oude als de nieuwe configuratie dezelfde golden set verwerken en vergelijk retrieval, antwoordkwaliteit, snelheid en kosten. Zo voorkom je dat een wijziging op basis van een paar aantrekkelijke voorbeelden als verbetering wordt beschouwd, terwijl de gemiddelde prestaties juist verslechteren.

Wanneer is A/B-testen zinvol?

Offline evaluatie vertelt niet alles: echte gebruikers stellen soms andere vragen dan je testset bevat. Bij een A/B-test krijgt een deel van het verkeer versie A en een ander deel versie B. Vergelijk vervolgens signalen zoals:

• hoeveel vervolgvragen nodig zijn;
• hoe vaak gebruikers een antwoord opnieuw formuleren;
• of gebruikers positieve of negatieve feedback geven;
• hoe vaak een medewerker alsnog moet ingrijpen;
• latency en kosten per beantwoorde vraag.

A/B-tests zijn vooral nuttig wanneer twee systemen offline ongeveer gelijkwaardig lijken, maar je wilt weten welke variant in de praktijk beter functioneert.

Vergeet latency en kosten niet

Een kwalitatief beter antwoord is niet automatisch een beter product. Een configuratie die meer chunks ophaalt, een groter reranking-model gebruikt en een duurder taalmodel inzet, kan de antwoordkwaliteit verbeteren maar ook meer tijd en geld kosten. Meet daarom naast inhoudelijke kwaliteit minimaal:

• retrievaltijd;
• totale responstijd;
• aantal ingevoerde en gegenereerde tokens;
• model- en embeddingkosten;
• aantal retrieval- of modelcalls per vraag.

De beste configuratie is meestal een compromis tussen kwaliteit, snelheid en kosten dat past bij de toepassing. Voor een interne kennisassistent kan een iets langere responstijd acceptabel zijn als de brononderbouwing daardoor aantoonbaar beter wordt. Bij een klantgerichte chatbot kan responstijd zwaarder wegen.

Hoe voorkom je regressie?

RAG-systemen bestaan uit meerdere componenten die elkaar beïnvloeden — een kleine wijziging kan onverwachte neveneffecten hebben. Een andere chunking-strategie kan bijvoorbeeld retrieval verbeteren voor lange beleidsstukken, maar slechter presteren bij korte FAQ-documenten. Daarom hoort iedere relevante wijziging opnieuw tegen dezelfde eval-set te worden getest. Leg per versie minimaal vast:

• chunking-instellingen;
• embeddingmodel;
• zoekmethode en eventuele reranking;
• aantal opgehaalde chunks;
• systeemprompt;
• generatiemodel en relevante instellingen;
• behaalde evaluatieresultaten.

Maak van belangrijke evaluaties bij voorkeur een geautomatiseerde regressietest: een nieuwe configuratie gaat dan pas naar productie wanneer zij geen onacceptabele achteruitgang veroorzaakt op vooraf gekozen kwaliteitscriteria.

Praktische checklist

Een bruikbare RAG-evaluatie hoeft niet ingewikkeld te beginnen. Zorg minimaal dat je:

• een vaste golden set met representatieve vragen hebt;
• weet welke bronnen per vraag relevant zijn;
• retrieval-precision en -recall beoordeelt;
• antwoordrelevantie en grounding controleert;
• test of het systeem kan weigeren wanneer bewijs ontbreekt;
• latency en kosten per vraag meet;
• wijzigingen altijd vergelijkt met de vorige configuratie;
• productieproblemen aan de eval-set toevoegt.

De belangrijkste omslag is dat je een RAG-systeem niet beoordeelt op een paar antwoorden die er goed uitzien, maar kwaliteit herhaalbaar meetbaar maakt. Pas dan kun je onderbouwen dat een nieuwe embedding, chunking-strategie, prompt of model werkelijk een verbetering is.

Veelgestelde vragen

Hoeveel vragen moet een RAG-eval-set bevatten? Er bestaat geen universeel ideaal aantal. Belangrijker is dat de set representatief is voor verschillende soorten vragen, documenten en foutgevallen. Begin met een beheersbare set en breid die uit met relevante praktijkgevallen en gevonden regressies.

Kun je RAG-evaluatie volledig automatiseren? Een groot deel kan worden geautomatiseerd, waaronder retrieval-tests, latency, kosten en sommige vormen van antwoordbeoordeling. Menselijke controle blijft waardevol voor nuance, inhoudelijke juistheid en situaties waarin meerdere antwoorden acceptabel kunnen zijn.

Moet je na iedere promptwijziging opnieuw testen? Ja. Ook een ogenschijnlijk kleine promptwijziging kan invloed hebben op volledigheid, brongebruik, formulering en weigeringsgedrag. Door dezelfde eval-set opnieuw uit te voeren, zie je of de wijziging verbetering of regressie veroorzaakt.