Bij een klant in de energiesector hebben we een RAG-systeem uitgerold over technische normen en operationele richtlijnen. Na de eerste twee weken in productie meldden operators dat het systeem "soms goed antwoordde, soms niet". Toen we nader keken, bleek het probleem twee volkomen verschillende oorzaken te hebben: in sommige gevallen haalde de retrieval de verkeerde documenten op — het juiste antwoord stond wél in de knowledge base, maar het systeem vond het niet. In andere gevallen werkte de retrieval goed, maar negeerde het generatieve model de opgehaalde context en hallucineerde zijn eigen antwoord. Vanuit het perspectief van de gebruiker zagen beide fouten er identiek uit. Zonder metrics konden we ze niet van elkaar onderscheiden.
Dit is de kern van het probleem bij het evalueren van RAG-systemen: retrieval en generation zijn twee afzonderlijke componenten die elk om andere redenen kunnen falen. Als u ze samen meet, verliest u het vermogen om te diagnosticeren. Dit artikel beschrijft hoe u het aanpakt — afzonderlijk, systematisch, met de tools die daarvoor bestaan.
Waarom klassieke metrics niet volstaan
De eerste reflex bij het beoordelen van een RAG-systeem is de vraag: "Is het antwoord correct?" En dat meten via een handmatige controle of een eenvoudige vergelijking met de verwachte uitvoer. Dit heeft een fundamenteel probleem: het vertelt u niet *waar* de pipeline is misgelopen.
Stel u drie scenario's voor:
- Retrieval haalt het juiste document op, het model antwoordt er correct op — goed resultaat.
- Retrieval haalt het verkeerde document op, het model antwoordt er consistent op — slecht resultaat, maar faithfulness is hoog (het model hallucineerde niet, het had alleen slechte context).
- Retrieval haalt het juiste document op, het model negeert het en hallucineert — slecht resultaat, faithfulness is laag.
Drie verschillende scenario's, twee verschillende faalplaatsen, één gemeenschappelijk symptoom: het verkeerde antwoord. Als u alleen het eindresultaat meet, repareert u de retrieval en ontdekt u dat de generation nog steeds hallucineert — of omgekeerd.
Daarom deelt moderne RAG-evaluatie de meting op in twee lagen: retrieval metrics (context precision, context recall) en generation metrics (faithfulness, answer relevancy). En precies dat is de filosofie achter het framework RAGAS.
RAGAS — wat het is en wat niet
RAGAS (Retrieval-Augmented Generation Assessment) is een open-source evaluatieframework dat de kwaliteit van een RAG-pipeline meet zonder dat voor elk geval handmatige annotaties nodig zijn. In plaats daarvan gebruikt het een LLM-as-judge-aanpak: een bewering of stelling wordt beoordeeld door een ander taalmodel.
Wat RAGAS is: een framework voor offline evaluatie van een RAG-pipeline aan de hand van een golden set. U geeft het vragen, referentieantwoorden, door uw retrieval opgehaalde contexten en gegenereerde antwoorden — en het berekent vier sleutelmetrics.
Wat RAGAS niet is: real-time productiemonitoring, een vervanging voor evals van een volledige LLM-applicatie, of een tool om de feitelijke correctheid van de knowledge base zelf te meten. Als uw documenten onjuiste informatie bevatten, zal RAGAS dat niet opvangen — het meet consistentie en relevantie, niet de betrouwbaarheid van de bronnen.
Een belangrijk onderscheid ten opzichte van andere vormen van evaluatie: RAGAS richt zich uitsluitend op de RAG-component. Als u de kwaliteit van een LLM-antwoord onafhankelijk van retrieval wilt meten, of een fine-tuned model wilt beoordelen, gebruikt u andere metrics — die horen thuis in een apart evaluatiedomein. Evenzo is fine-tuning eval (bijvoorbeeld meten of fine-tuning heeft geholpen) een andere discipline dan RAG eval.
De vier sleutelmetrics van RAGAS
Context Precision
Context precision meet of de documenten die retrieval heeft teruggegeven daadwerkelijk relevant zijn voor de gestelde vraag. Concreet: welk deel van de opgehaalde context is nuttig voor het genereren van het juiste antwoord?
Hoge context precision betekent dat retrieval geen ruis teruggeeft — elk opgehaald chunk draagt bij aan het antwoord. Lage context precision signaleert dat het systeem te veel niet-gerelateerde documenten ophaalt, wat de kwaliteit van de generation verslechtert (het LLM moet zich tegelijkertijd oriënteren op relevante én irrelevante inhoud).
In de praktijk: als context precision laag is, ligt het probleem doorgaans in het embeddingmodel, een gebrekkige documentsegmentatie (chunking), of de top-K-instelling (u haalt te veel documenten op). Meer over de keuze en instelling van retrieval-componenten leest u in het artikel over hybride zoeken.
Context Recall
Context recall is de complementaire metric: welk deel van de informatie die nodig is voor het juiste antwoord, is aanwezig in de opgehaalde context? Dit wordt gemeten ten opzichte van het referentieantwoord uit de golden set.
Als context recall laag is, mist retrieval relevante documenten — de informatie bestaat in de knowledge base, maar het systeem vindt ze niet. Oorzaken zijn doorgaans: onvoldoende kwaliteit van het embeddingmodel voor de betreffende taal of het domein, slechte chunking (informatie is verdeeld over meerdere fragmenten die elk afzonderlijk onvoldoende zijn), of een te kleine K (u haalt bijvoorbeeld alleen de top-3 op, maar het relevante document eindigde op positie 7).
Faithfulness
Faithfulness meet in hoeverre het gegenereerde antwoord wordt onderbouwd door de opgehaalde context. RAGAS doet dit door het antwoord op te splitsen in afzonderlijke beweringen en voor elke bewering te verifiëren of die expliciet of impliciet wordt ondersteund door de context.
Dit is de belangrijkste metric vanuit het oogpunt van betrouwbaarheid van een RAG-systeem. Lage faithfulness betekent dat het model hallucineert — het genereert informatie die niet in de opgehaalde context staat, maar wel aannemelijk klinkt. Het is cruciaal te begrijpen: faithfulness ≠ feitelijke correctheid. Het model kan perfect faithful zijn (100% van het antwoord is onderbouwd door de context), maar de context zelf kan onjuist zijn. Als u feitelijke nauwkeurigheid wilt meten, moet u de kwaliteit van de knowledge base apart aanpakken.
Lage faithfulness wordt doorgaans opgelost op het niveau van de systeemprompt (instructies dat het model uitsluitend uit de context antwoordt), de modelkeuze (sommige modellen volgen instructies consistenter) of door het toevoegen van een guardrails-laag. Over guardrails voor AI-agenten, inclusief faithful-answer checks, leest u meer in het artikel over guardrails voor AI-agenten.
Answer Relevancy
Answer relevancy beoordeelt of het antwoord daadwerkelijk ingaat op de gestelde vraag. RAGAS meet dit door vanuit het gegenereerde antwoord meerdere hypothetische vragen terug te genereren en te controleren of die overeenkomen met de oorspronkelijke query.
Lage answer relevancy kan zich ook voordoen bij hoge faithfulness: het model kan trouw aan de context zijn, maar antwoorden op een andere vraag dan gesteld — typisch wanneer de context vaag is of de systeemprompt niet directief genoeg is. In de praktijk legt deze metric problemen bloot met prompting en vraagformulering.
Golden set — de basis van elke evaluatie
RAGAS-metrics zijn slechts zo goed als de dataset waarop u ze berekent. De golden set is een verzameling testgevallen in het volgende formaat:
- Vraag — een echte of representatieve query
- Referentieantwoord — het geverifieerde juiste antwoord (ground truth)
- Opgehaalde context — de documenten die uw retrieval voor die query heeft teruggegeven
- Gegenereerd antwoord — de uitvoer van uw RAG-systeem
Het probleem is dat het samenstellen van een golden set kostbaar is: typisch 100–300 gevallen voor een basiseval, 500–1.000 voor een robuustere variant. Elk geval handmatig laten opstellen door een domeinexpert is traag en duur.
Hier zijn twee strategieën van toepassing:
Synthetische generatie van de golden set: RAGAS en andere tools bevatten functies om testvrages automatisch te genereren rechtstreeks vanuit uw documenten. Een LLM leest een fragment, genereert een vraag en een referentieantwoord. Voordeel: snelheid en schaalbaarheid. Nadeel: synthetische vragen kunnen te eenvoudig zijn of niet overeenkomen met echte gebruikersqueries. In de praktijk adviseren we te combineren: 60–70% synthetische gevallen als basis, 30–40% echte queries uit productielogs geannoteerd door een expert.
Extractie uit productielogs: Zodra het RAG-systeem in productie draait, logt u paren (vraag, antwoord). Door representatieve gevallen te selecteren en te annoteren met gebruikersfeedback (duim omhoog/omlaag) of een domeinexpert, krijgt u een realistische golden set die aansluit op het werkelijke gebruik.
Belangrijk principe: de golden set moet levend gehouden worden. Wanneer de knowledge base wordt bijgewerkt, veroudert een deel van de testgevallen. Controleer bij grote documentatieupdates altijd of de golden set nog de actuele situatie weerspiegelt.
RAGAS in de praktijk — integratie in de pipeline
RAGAS is een Python-bibliotheek die eenvoudig integreert in een bestaande RAG-workflow. Het basisgebruik ziet er als volgt uit: voor elk testgeval uit de golden set roept u de evaluatie aan met de vraag, het referentieantwoord, de opgehaalde context en het gegenereerde antwoord. De uitvoer zijn scores per metric, geaggregeerd én per geval.
Wat u moet weten vóór implementatie:
Kosten: RAGAS roept intern een LLM aan voor de berekening van metrics (LLM-as-judge). Voor een golden set van 200 gevallen kunt u honderden tot duizenden LLM-aanroepen verwachten, wat bij frontier-modellen niet te verwaarlozen kosten oplevert. In de praktijk wordt aanbevolen een kleiner, goedkoper model te gebruiken voor de judge-functie (bijvoorbeeld Haiku/Flash-tier), of waar mogelijk een lokaal open-weight model. De faithfulness-berekening is bijzonder token-intensief, omdat het antwoord wordt opgesplitst in afzonderlijke beweringen.
Periodieke evaluatie, niet alleen ad-hoc: Evaluatie heeft pas zin als terugkerend proces — bij elke wijziging van een retrieval-component, update van de knowledge base of aanpassing van prompts. We adviseren RAGAS-evaluatie op te nemen in de CI/CD-pipeline, minimaal als sanity check op een subset van de golden set vóór elke deployment.
Interpretatie van absolute scores: Een faithfulness-score van 0,80 is niet objectief goed of slecht — dat hangt af van de use case. Voor medische documentatie is 0,80 onvoldoende. Voor een interne helpdesk kan het acceptabel zijn. Belangrijker zijn de trends: als faithfulness na een promptaanpassing daalt van 0,85 naar 0,72, heeft u een duidelijk signaal.
Retrieval eval en generation eval scheiden
Een sleutelpraktijk die we te weinig toegepast zien: de eval van het retrieval-component en de eval van het generation-component moeten ook onafhankelijk worden uitgevoerd, niet alleen via RAGAS end-to-end.
Retrieval eval afzonderlijk: U kunt retrieval evalueren zonder enige LLM-generation. Voor elke testvraag weet u welke documenten retrieval idealiter zou moeten vinden (vanuit de golden set). U meet precision@K en recall@K — hoeveel van de relevante documenten zijn in de top-K-resultaten terechtgekomen. Dit geeft u een helder signaal over de kwaliteit van het embeddingmodel, de indexeringsstrategie en de zoekinstellingen — zonder dat het generatieve model problemen verbergt of retrieval-fouten compenseert.
Generation eval afzonderlijk: U kunt de context vastzetten — in plaats van dynamisch opgehaalde documenten geeft u het model altijd dezelfde, handmatig geverifieerde context — en alleen faithfulness en answer relevancy meten. Dit test geïsoleerd het vermogen van het model om instructies te volgen en informatie te extraheren uit de aangeleverde tekst.
De combinatie van beide perspectieven met de end-to-end RAGAS-metrics geeft een volledig beeld van waar de pipeline precies kwaliteit verliest.
Wat RAGAS niet meet — en waar u op moet letten
RAGAS is een krachtig instrument, maar heeft grenzen die u expliciet moet kennen.
Feitelijke correctheid van de knowledge base: Zoals gezegd meet RAGAS de consistentie van het antwoord met de context. Als de documenten in de knowledge base verouderde of onjuiste informatie bevatten, zal RAGAS dat niet aan het licht brengen. De kwaliteit van de knowledge base moet u apart aanpakken — via domeinreview, datering van documenten en updatemechanismen.
Latentie en kosten in productie: RAGAS is een offline evaluatietool. Het vertelt u niet hoe de pipeline zich gedraagt bij een hoog queryvolume, wat de werkelijke latentie voor de gebruiker is, of wat de productietokenkosten zijn. Voor deze metrics heeft u productiemonitoring nodig — tools als LangSmith, Langfuse of een eigen loglaag. Over observability van AI-agenten en productiemonitoring schrijven we uitgebreider in het artikel over observability van AI-agenten.
Beveiligingseigenschappen: RAGAS meet niet de weerstand tegen prompt injection, het vermogen van het systeem om ongepaste queries te weigeren, of de naleving van beveiligingsguardrails. Dit valt onder security eval, een aparte discipline.
Taalkwaliteit en register: Als uw gebruikers in het Nederlands communiceren en de knowledge base in het Engels is, zegt de RAGAS-score niets over de vertaalkwaliteit of de natuurlijkheid van de Nederlandse antwoorden. Bij een meertalige opstelling heeft u menselijke evaluatie van de taalkwaliteit nodig.
Veelgestelde vragen
Hoeveel gevallen heb ik nodig in de golden set voor betrouwbare resultaten?
Voor een eerste baseline volstaan 50–100 gevallen om een oriëntatie te krijgen. Voor beslissingen als "het embeddingmodel vervangen" of "de chunkingstrategie aanpassen" adviseren we 200–400 gevallen die verschillende vraagtypen en delen van de knowledge base bestrijken. Onder 50 gevallen zijn de resultaten te gevoelig voor individuele uitschieters.
Kan ik RAGAS gebruiken voor real-time productiemonitoring?
Niet rechtstreeks — elke RAGAS-meting kost LLM-aanroepen, wat te duur is voor elke productiequery. De gangbare aanpak is sampling: in plaats van elke query te meten neemt u een willekeurige steekproef van 1–5%, voert u RAGAS-evaluatie asynchroon uit en volgt u de trends in de tijd. Voor real-time productiemonitoring zijn eenvoudigere signalen beter geschikt: duim omhoog/omlaag feedback van gebruikers, latentie, aantal fallback-antwoorden.
Hoe weet ik of het probleem in de retrieval of de generation zit?
De eenvoudigste test: kopieer het relevante document handmatig rechtstreeks in de context (omzeil de retrieval) en stuur het naar het model. Als het antwoord goed is, ligt het probleem in de retrieval. Als het model ook met perfecte context hallucineert of irrelevant antwoordt, zit het probleem in de generation-laag — de prompt, het model, of de manier waarop u de context opmaakt. Deze handmatige test is sneller dan een volwaardige eval en legt de meeste problemen in minuten bloot.
Is LLM-as-judge betrouwbaar? Kan het niet fout beoordelen?
LLM-as-judge heeft zijn eigen blinde vlekken — langere antwoorden worden bijvoorbeeld hoger beoordeeld, ook als ze minder precies zijn, of de stijl die dicht bij de trainingsdata van het judge-model ligt krijgt de voorkeur. RAGAS compenseert dit deels door faithfulness op te splitsen in concrete beweringen en elk afzonderlijk te verifiëren. Voor kritieke use cases (gereguleerde sectoren, beveiligingsgevoelige systemen) adviseren we automatische eval te combineren met menselijke controle, minimaal voor een subset van de gevallen.
Welk model gebruik ik als judge in RAGAS?
Voor de meeste gevallen volstaat een frontier-model van de middelste klasse (Sonnet/Flash/Haiku-tier) — nauwkeurig genoeg en aanzienlijk goedkoper dan de maximale tier. Als u on-prem-vereisten heeft of gevoelige data verwerkt, ondersteunt RAGAS ook lokale modellen via een OpenAI-compatible API — een krachtig open-weight model uit de Qwen3- of Llama-familie op inference via vLLM werkt goed voor beoordelingstaken.
*Twijfelt u waar u moet beginnen met het evalueren van uw RAG-systeem, of wilt u precies weten waar uw pipeline aan nauwkeurigheid verliest — bij MP Industrial Solutions voeren we diagnostische beoordelingen uit van RAG-implementaties en helpen we u een evaluatieproces in te richten dat tot bruikbare resultaten leidt, niet alleen tot cijfers.*