RAG evalueren: retrieval-metrics, faithfulness en golden sets

Een RAG-systeem heeft twee stappen die op verschillende manieren fout gaan. De retrieval kan de passage met het antwoord missen. Het model kan een passage die het kreeg negeren, verkeerd lezen of mooier maken dan hij is. Geef je alleen het eindantwoord een score, dan weet je dat er iets misging, zonder te weten welke helft je moet repareren.

Deze gids is voor engineers en product owners die RAG-chatbots, zoekassistenten of vraag-en-antwoordsystemen voor documenten beheren en metingen willen waarop ze kunnen vertrouwen. We behandelen de twee families van metrics, hoe je faithfulness (trouw aan de bronnen) controleert, hoe je een golden set bouwt en waar LLM-judges je misleiden.

Lees de metrics samen. Lage recall met hoge faithfulness betekent dat het model zich goed gedraagt bij slechte context. Verbeter dan de retrieval. Hoge recall met lage faithfulness betekent dat de juiste passages aankomen en het model ervan afdwaalt. Kijk dan naar de prompt, het model of de opmaak van de context. Juiste antwoorden met lage faithfulness zijn ook een waarschuwing. Het model antwoordt dan uit zijn trainingsdata, en dat gaat mis zodra je documenten iets anders zeggen dan algemene kennis.

Metrics voor retrieval zijn goedkoop en deterministisch zodra de relevante passages gelabeld zijn. Draai ze dus bij elke wijziging. Onze gids over embeddings en semantisch zoeken laat zien hoe je recall@k en nDCG berekent.

Faithfulness gaat over de vraag of het antwoord alleen zegt wat de bronnen ondersteunen. Een heel antwoord in één keer scoren is onbetrouwbaar, omdat één niet-onderbouwde zin makkelijk wegvalt tussen correcte zinnen. Een betrouwbaardere methode:

1. 01Splits het antwoord in losse beweringen, met een model, of per zin bij korte antwoorden.
2. 02Vraag per bewering aan een beoordelend model (judge) of de opgehaalde passages de bewering ondersteunen, tegenspreken of er niets over zeggen.
3. 03Laat de judge het ondersteunende bewijs letterlijk citeren, en controleer of dat citaat in de bronnen staat.
4. 04Rapporteer per antwoord het aandeel ondersteunde beweringen, en markeer elke bewering die wordt tegengesproken.

import json
from anthropic import Anthropic

client = Anthropic()

JUDGE_PROMPT = """Decide whether the sources support the claim.
Reply with JSON only: {{"verdict": "supported" | "contradicted" | "not_found", "quote": "<exact text or empty>"}}

Sources:
{sources}

Claim:
{claim}"""

def judge_claim(claim: str, sources: list[str]) -> dict:
    context = "\n\n".join(sources)
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=300,
        messages=[{"role": "user", "content": JUDGE_PROMPT.format(sources=context, claim=claim)}],
    )
    result = json.loads(response.content[0].text)
    if result["verdict"] == "supported" and result["quote"] not in context:
        result["verdict"] = "unverified"  # the judge quoted text that is not in the sources
    return result

Die controle op het citaat is belangrijk. Judges markeren een bewering soms als ondersteund en verzinnen het bewijs erbij. Een simpele string-match vangt dat goedkoop af. Normaliseer in productie de witruimte voor het matchen en gebruik structured outputs waar dat kan, zodat de JSON altijd te parsen is.

Een golden set is een zorgvuldig samengestelde verzameling vragen, elk met een beschrijving van de juiste uitkomst. Voor RAG bevat elke vraag in de set:

• De vraag, geschreven zoals echte gebruikers hem stellen.
• De ID's van de passages die het antwoord bevatten.
• Een referentieantwoord, of de kernfeiten die een juist antwoord moet bevatten.
• Labels voor bedoeling, moeilijkheid en risico, plus een markering voor vragen die de documenten niet kunnen beantwoorden.

Haal vragen uit zoeklogs, supporttickets en bij vakexperts, en neem bewust vragen op die niet te beantwoorden zijn. Mik op een paar honderd vragen, verdeeld over je belangrijkste documenttypen. Label relevante passages op een niveau dat een nieuwe chunking overleeft, zoals document en sectie. Dan blijft de set geldig als je je chunkingstrategie verandert.

Geef de golden set versienummers en bekijk hem opnieuw als documenten veranderen. Anders straft een vraag waarvan het antwoord naar een nieuwe beleidsversie is verhuisd het systeem af terwijl het gelijk heeft.

Met judge-modellen kun je antwoorden op grote schaal evalueren, en ze hebben bekende zwakke plekken:

• Voorkeur voor lengte en stijl. Judges geven vaak de voorkeur aan langere antwoorden die zekerder klinken. Beoordeel op specifieke criteria en kernfeiten, en vraag niet welk antwoord in het algemeen beter is.
• Voorkeur voor zichzelf. Een judge kan output van zijn eigen modelfamilie voortrekken. Laat waar het kan een ander model beoordelen dan het model dat de antwoorden schrijft.
• Voorkeur voor positie. Bij vergelijkingen per paar kan de eerste optie vaker winnen. Draai beide volgordes.
• Vage beoordelingsschema's. "Geef de behulpzaamheid een cijfer van 1 tot 10" levert ruis op. Gebruik een paar categorieën met uitgeschreven definities.
• Niet-gevalideerde judges. Beoordeel een steekproef met de hand en meet de overeenstemming voordat je de judge vertrouwt. Controleer opnieuw na een wijziging in het judge-model of de prompt.
• Lekkage. Ziet de judge het referentieantwoord terwijl hij faithfulness controleert, dan beloont hij misschien overeenkomst met de referentie in plaats van overeenkomst met de bronnen.

1. 01Bouw een golden set van echte vragen met gelabelde passages, referentiefeiten en vragen zonder antwoord.
2. 02Draai metrics voor retrieval bij elke wijziging in chunking, embeddings, zoeken of reranking.
3. 03Draai controles op faithfulness, juistheid, bronvermelding en weigeringen bij elke wijziging in prompts of modellen.
4. 04Valideer de judge tegen beoordelingen door mensen, en controleer opnieuw als de judge verandert.
5. 05Laat releases afhangen van afgesproken drempels, zoals beschreven in LLM-evaluaties voor elke release.
6. 06Neem elke week een steekproef van gesprekken uit productie en maak van fouten nieuwe vragen in de golden set.

We zetten zo'n evaluatie op voordat we een RAG-systeem gaan afstellen, omdat elke latere wijziging dan een gemeten besluit wordt. Onze RAG-case voor een advocatenkantoor is een voorbeeld van een systeem dat zo is gebouwd. De gids voor een RAG-chatbot in productie behandelt het bouwen zelf, en onze aanpak legt uit waar evals in ons proces passen.