RAG-Evaluatie: Het Meten van Retrieval en Generatie Kwaliteit

Wie bouwt aan een Retrieval-Augmented Generation (RAG) systeem, komt al snel tot een pijnlijke ontdekking: het handmatig intypen van een paar testvragen en kijken of het antwoord "er goed uitziet" schaalt niet. Om een RAG-applicatie betrouwbaar naar productie te brengen, heb je een robuuste evaluatiestrategie nodig. Daarbij is het essentieel om te begrijpen dat een RAG-systeem niet één monolithische AI-magie is, maar uit twee strikt gescheiden pijlers bestaat: het ophalen van de juiste informatie (retrieval) en het formuleren van een correct antwoord (generatie).

In dit artikel ontleden we hoe je een RAG-systeem systematisch evalueert. We kijken naar begrippen als precisie, recall, groundedness en de gevaren van een model dat het juiste antwoord geeft om de verkeerde redenen. We nemen hierbij als aanname dat je al over een werkende RAG-pijplijn beschikt en bekend bent met concepten zoals vectordatabases en chunking, of basiskennis hebt via bronnen zoals onze gids over RAG voor beginners.

Waarom Alleen het Eindantwoord Evalueren Faalt

Veel ontwikkelaars beginnen met end-to-end testen: er gaat een vraag in de applicatie, er komt een antwoord uit, en men beoordeelt dat eindresultaat. Deze methode verhult echter waar de pijplijn daadwerkelijk stukloopt als er een fout wordt gemaakt.

Stel, een gebruiker vraagt aan een interne HR-chatbot: "Hoeveel vakantiedagen krijg ik als parttimer?" Het systeem geeft een foutief antwoord. Waar ligt dit aan? Er zijn grofweg drie mogelijkheden:

  • De zoekmachine faalt: De vectordatabase heeft de HR-handleiding over parttimers niet kunnen vinden (Retrieval probleem).
  • De context is te groot of onoverzichtelijk: De juiste handleiding is wel opgehaald, maar zat verstopt in vijf pagina's aan irrelevante tekst waardoor het taalmodel de weg kwijtraakte (Retrieval/Chunking probleem).
  • Het taalmodel hallucineert: De juiste tekst is perfect aangeleverd, maar het model heeft de berekening verkeerd begrepen of besloot zijn eigen algemene kennis over vakantiedagen in Nederland te gebruiken (Generatie probleem).

Als je alleen het eindantwoord meet, weet je niet aan welke knoppen je moet draaien om het systeem te verbeteren. Je moet de componenten dus isoleren.

Pijler 1: De Retrieval-stap Evalueren (Het Zoekproces)

Voordat we ook maar naar het Large Language Model (LLM) kijken, moeten we de zoekkwaliteit meten. Het doel van de retrieval-stap is om alle benodigde informatie, en uitsluitend die informatie, op te halen. Hier komen twee klassieke begrippen uit de informatiekunde om de hoek kijken: Precision (Precisie) en Recall.

Recall: Hebben we alles gevonden?

Recall draait om volledigheid. Van alle tekstfragmenten in je database die het antwoord op de vraag bevatten, hoeveel heeft je systeem er daadwerkelijk opgehaald? In gewone mensentaal: "Hebben we de speld in de hooiberg gevonden?"

Een hoge recall is in RAG cruciaal. Als het antwoord niet in de meegeleverde context zit, kan het taalmodel immers geen accuraat, op de bron gebaseerd antwoord genereren. Een recall van 100% betekent dat alle relevante documenten voor een specifieke vraag in je top-K resultaten zitten (bijvoorbeeld de top 5 documenten die je aan de prompt toevoegt).

Precisie: Zit er geen ruis tussen?

Precisie draait om relevantie. Van alle documenten die het systeem heeft opgehaald, hoeveel waren er daadwerkelijk nuttig voor de gestelde vraag? In gewone taal: "Hebben we niet de halve hooiberg meegeleverd in de hoop dat de speld erbij zat?"

Een lage precisie lijkt in eerste instantie minder erg dan een lage recall; zolang de speld er maar bij zit, toch? Echter, het meegeven van veel irrelevante chunks heeft drie grote nadelen. Ten eerste stijgen de tokenkosten aanzienlijk. Ten tweede vergroot te veel ruis in de context de kans op hallucinaties (het zogenaamde 'lost in the middle' fenomeen). Tot slot kan het de doorvoersnelheid van je applicatie vertragen.

Context Relevantie

Bij het evalueren van retrieval kijken we vaak naar 'Context Relevance'. Dit meet simpelweg in hoeverre de opgehaalde context direct gerelateerd is aan de gestelde vraag. Deze metric is vaak goed te automatiseren met methodes zoals beschreven in ons artikel over LLM-as-a-judge, waarbij je een krachtig model (zoals GPT-4 of Claude 3.5 Sonnet) vraagt om een score van 0 tot 1 te geven op de relevantie van een document voor een specifieke vraag.

Pijler 2: De Generatie-stap Evalueren (Het Antwoord)

Als we hebben vastgesteld dat de juiste documenten succesvol en zonder te veel ruis uit de database zijn gehaald, verleggen we de focus naar het uiteindelijke antwoord. In een RAG-opstelling zijn er twee fundamentele metrieken voor generatie: Groundedness (of Faithfulness) en Answer Relevance (Volledigheid).

Groundedness: Staat het echt in de bron?

Groundedness, in het Nederlands ook wel feitelijke onderbouwing of getrouwheid genoemd, meet in hoeverre de claims die het LLM maakt, te herleiden zijn naar de meegeleverde context. Dit is jouw belangrijkste wapen tegen hallucinaties. Als het LLM stelt dat het bedrijf op vrijdag om 16:00 uur sluit, moet ergens in de opgehaalde chunks letterlijk staan of duidelijk af te leiden zijn dat het kantoor vrijdag om 16:00 uur sluit.

Is de claim niet te vinden in de context? Dan is de Groundedness laag. Dit gebeurt vaak wanneer het model terugvalt op zijn voorgedrainde kennis. Voor meer diepgang over dit specifieke fenomeen kun je onze gids over hallucinaties meten raadplegen. Een hoge groundedness betekent niet noodzakelijk dat het antwoord nuttig is, alleen dat het model niet zelf dingen heeft bedacht buiten de bronnen om.

Volledigheid (Answer Relevance / Completeness)

De tweede belangrijke metriek voor generatie is de relevantie en volledigheid van het antwoord ten opzichte van de vraag van de gebruiker. Geeft het model direct antwoord, of leidt het de gebruiker met een kluitje in het riet?

Stel de vraag is: "Wat is de opzegtermijn voor een medewerker in vaste dienst, en moet dit schriftelijk?" Het opgehaalde document bevat beide antwoorden (1 maand, ja). Als het model alleen zegt: "De opzegtermijn is 1 maand", is de Groundedness perfect (het klopt met de bron), maar de Volledigheid schiet tekort omdat het tweede deel van de vraag genegeerd is.

De Valkuil: Gelijk Hebben om de Verkeerde Reden

Een van de gevaarlijkste situaties bij het evalueren van een RAG-applicatie is het fenomeen waarbij het model het juiste antwoord geeft, maar zonder dat het de benodigde informatie uit je eigen systemen heeft gehaald.

Als de gebruiker vraagt: "Wat is de hoofdstad van Frankrijk?" zal een RAG-systeem zonder goede retrieval alsnog "Parijs" antwoorden, omdat het taalmodel dit simpelweg al weet uit zijn trainingsdata.

Waarom is dit gevaarlijk? Omdat je end-to-end tests dit als een succes zullen markeren. Je denkt dat je RAG-systeem geweldig werkt, totdat een gebruiker een vraag stelt over een puur intern bedrijfsproces waar het model niets van af weet. Opeens faalt de applicatie spectaculair. Omdat je retrieval-proces (de fundering van RAG) eigenlijk niet functioneerde, maar gemaskeerd werd door de algemene kennis van het LLM. Door retrieval en generatie apart te meten, zoals we hierboven bespraken, leg je dit soort verborgen gebreken feilloos bloot.

Praktijk: Een Gouden Testset Bouwen (Golden Dataset)

Om deze metrieken structureel te kunnen meten, heb je een 'Gouden Testset' nodig. Dit is een verzameling van zorgvuldig samengestelde vraag-bron-paren die als de absolute waarheid dienen voor je tests. Zonder een golden dataset ben je in feite blind aan het optimaliseren.

Hoe bouw je zo'n set? Dit vereist initieel handmatig werk, maar betaalt zich dubbel en dwars terug:

  1. Verzamel echte vragen: Gebruik vragen uit de praktijk. Wat typen gebruikers daadwerkelijk in? Verzin ze niet (volledig) zelf aan je bureau.
  2. Zoek de bron (ground truth): Zoek voor elke vraag handmatig het specifieke document of de chunk op die het antwoord bevat. Noteer het unieke ID (document_id of chunk_id) van deze bron.
  3. Schrijf het referentie-antwoord: Formuleer handmatig het ideale, perfecte antwoord gebaseerd op deze bron.

Een typisch record in je testset ziet er dan conceptueel zo uit:

{
  "vraag": "Kan ik mijn leaseauto meenemen naar het buitenland?",
  "verwacht_document_id": "hr_lease_policy_2026_v2",
  "verwacht_antwoord": "Ja, je mag de leaseauto meenemen naar EU-landen, mits je dit vooraf meldt bij wagenparkbeheer."
}

Zorg voor diversiteit in je vragen. Neem feitelijke vragen op, vragen die om samenvattingen vragen, en vooral ook 'trick questions' of vragen waarop het antwoord simpelweg niet in de documenten staat. Bij die laatste moet het systeem geëvalueerd worden op zijn vermogen om eerlijk "Ik weet het niet" te zeggen, in plaats van te hallucineren.

Regressietesten: Voorkom dat Indexwijzigingen Alles Breken

Een RAG-systeem is dynamisch. Je zult ongetwijfeld in de toekomst de chunk size aanpassen, overstappen op een nieuwer embedding model, of de weging tussen semantisch zoeken en keyword search (BM25 of hybride zoeken) veranderen. Elke keer dat je dit doet, moet je de vectordatabase opnieuw indexeren.

Een wijziging die bedoeld is om een specifiek zoekprobleem op te lossen, kan onbedoeld de resultaten voor tientallen andere queries verslechteren. Dit noemt men regressie. Om dit te voorkomen heb je geautomatiseerde regressietesten nodig. Meer over het effectief instellen van waarschuwingen lees je in ons artikel over regressietesten op prompts.

Met je golden dataset kun je bij elke pipeline-wijziging volautomatisch de recall en precisie hertesten. Als je overstapt naar een nieuw embedding model en je merkt dat de recall op de golden dataset zakt van 85% naar 60%, dan weet je direct dat dit nieuwe model voor jouw specifieke documenten (waarschijnlijk door domeinspecifiek jargon) minder goed presteert, ongeacht wat de benchmarks van de modelmaker beweren.

Conclusie

Het evalueren van een RAG-systeem vereist een systematische aanpak waarbij je de prestaties niet afmeet aan enkel het resulterende antwoord. Door het proces op te splitsen, de recall van je retrieval te optimaliseren, de groundedness van je generatie af te dwingen, en dit continu te monitoren met een golden dataset, transformeer je RAG van een experimenteel prototype naar een betrouwbare applicatie voor productieomgevingen.