Hoe beoordeel je of een model goed antwoordt: evals voor beginners

Dit artikel hoort bij module 2 (Een model gebruiken) van de leerlijn. Wie begint met het bouwen van applicaties rond grote taalmodellen, ontdekt al snel een hardnekkig knelpunt: hoe stel je objectief vast of de gegenereerde antwoorden daadwerkelijk van hoge kwaliteit zijn? Waar traditionele software binaire uitkomsten levert (de code compileert of faalt), werken taalmodellen met kansverdelingen en variabele formuleringen. Een promptwijziging die één specifiek probleem oplost, kan ongemerkt drie andere use cases beschadigen.

Het systematisch testen van taalmodel-outputs noemen we evaluaties, in het vakgebied afgekort tot evals. Zonder geautomatiseerde evaluaties blijft prompt engineering een kwestie van gokken. In dit artikel behandelen we de volledige methodologie achter evaluaties: van eenvoudige deterministische asserts tot het inzetten van geavanceerde modelbeoordelaars (LLM-as-a-judge). We bespreken hoe je betrouwbare testsets opbouwt, welke statistische metrieken relevant zijn en hoe je veelvoorkomende meetfouten vermijdt.

Waarom handmatig testen ('vibe checks') faalt in productie

Wanneer ontwikkelaars een nieuwe prompt schrijven of overstappen naar een ander basismodel, testen ze dat vaak door handmatig drie tot vijf voorbeelden in te voeren in een chatvenster. Ziet het antwoord er overtuigend, beleefd en grammaticaal kloppend uit, dan ontstaat de verleiding om de wijziging direct door te voeren naar productie. In de praktijk staat deze werkwijze bekend als de vibe check.

Het fundamentele probleem van handmatige controle is dat taalmodellen opereren in een oneindige invoerruimte. Een model kan uitstekend presteren op vriendelijke, enkelvoudige vragen, maar volledig ontsporen zodra een gebruiker tegenstrijdige instructies geeft, ontbrekende parameters invoert of een afwijkend dialect hanteert. Daarnaast treedt bij handmatige inspectie snel menselijke vermoeidheid op: subtiele fouten in datumnotaties, ontbrekende juridische disclaimers of hallucineerde feiten worden na vijftig controles gemakkelijk over het hoofd gezien.

Bovendien maakt handmatig testen regressietesten onmogelijk. In klassieke softwareontwikkeling zorgt een testsuite (zoals unittests en integratietests) ervoor dat nieuwe functionaliteit bestaande code niet breekt. Bij LLM-toepassingen heb je exact hetzelfde vangnet nodig. Zonder een vaste evaluatiesuite weet je nooit zeker of een aanscherping van de systeeminstructie geen regressie veroorzaakt in eerdere scenario's.

De drie niveaus van evaluatie

Om een schaalbare evaluatiestrategie op te zetten, categoriseren we tests op basis van hun complexiteit, uitvoeringssnelheid en kosten. We onderscheiden drie complementaire niveaus:

Een robuuste evaluatiepijplijn vertrouwt nooit op slechts één van deze lagen. De kunst bestaat erin om goedkope, deterministische regels als eerste filter te gebruiken en pas voor complexere kwaliteitscriteria een zwaarder taalmodel als beoordelaar in te schakelen.

Niveau 1: Deterministische en heuristische checks

Deterministische checks vereisen geen kunstmatige intelligentie; het zijn traditionele programmacodes die controleren of de output voldoet aan harde structurele randvoorwaarden. Dit is de meest kostenefficiënte manier om foutieve generaties direct af te keuren.

Denk hierbij aan concrete validaties zoals:

• JSON- en schemaconformiteit: Kan de gegenereerde tekst foutloos geparseerd worden als JSON en bevat het object alle verplichte velden met de juiste datatypes?
• Aanwezigheid van vereiste elementen: Bevat de output noodzakelijke zinnen, zoals een waarschuwing of een specifiek referentienummer?
• Zwarte lijsten (Negative matches): Bevat de reactie verboden woorden, concurrentienamen of lekken van interne systeemprompts?
• Lengte- en opmaakgrenzen: Blijft de samenvatting strikt onder een maximum aantal woorden of alinea's?

Hieronder staat een voorbeeld van een eenvoudig Python-evaluatiescript dat controleert of een gegenereerd klantenservice-antwoord aan strikte basisregels voldoet:

import json
import re

def evalueer_deterministisch(output_tekst: str) -> dict:
  resultaten = {
    "is_valide_json": False,
    "bevat_ticket_id": False,
    "geen_verboden_termen": True,
    "lengte_binnen_marge": False
  }
  
  # 1. Valideer JSON-structuur
  try:
    data = json.loads(output_tekst)
    resultaten["is_valide_json"] = True
    
    # 2. Controleer op ticket-ID patroon (bijv. NL-12345)
    bericht = data.get("antwoord", "")
    if re.search(r"NL-\d{5}", bericht):
      resultaten["bevat_ticket_id"] = True
      
    # 3. Zwarte lijst controle
    verboden = ["interne database", "geheim", "systeemprompt"]
    if any(woord in bericht.lower() for woord in verboden):
      resultaten["geen_verboden_termen"] = False
      
    # 4. Lengtecontrole van het antwoord (tussen 20 en 200 woorden)
    woord_aantal = len(bericht.split())
    if 20 <= woord_aantal <= 200:
      resultaten["lengte_binnen_marge"] = True
      
  except json.JSONDecodeError:
    resultaten["is_valide_json"] = False

  return resultaten

Wanneer een model zakt voor een van deze basischecks, hoef je geen verdere kosten te maken aan diepere semantische inspectie. Het antwoord kan direct als ongeldig worden gemarkeerd.

Niveau 2: Semantische evaluatie en embedding-afstanden

Niet elk antwoord laat zich vangen in een exacte regex. Wanneer een model een vraag van een klant beantwoordt, zijn er honderden manieren om dezelfde boodschap correct te verwoorden. In dit stadium kijken we naar semantische overeenkomst.

Historisch werden hiervoor n-gram metrieken zoals BLEU (Bilingual Evaluation Understudy) en ROUGE (Recall-Oriented Understudy for Gisting Evaluation) gebruikt. Deze metrieken tellen hoeveel woorden of woordcombinaties uit de referentietekst exact terugkomen in de gegenereerde tekst. Hoewel nuttig voor vertalingen, schieten ze tekort bij creatieve antwoorden: twee zinnen met exact dezelfde betekenis maar compleet andere synoniemen scoren op ROUGE bedroevend laag.

De moderne aanpak maakt gebruik van vector-embeddings. Hierbij zetten we zowel het modelantwoord als een vooraf vastgesteld 'gouden antwoord' om in een hoogdimensionale vector. Vervolgens berekenen we de cosinussimilariteit tussen beide vectoren. Ligt de overeenkomst boven een bepaalde drempelwaarde (bijvoorbeeld 0.88), dan beschouwen we de betekenis als gelijkwaardig. Let wel op de valkuil: een ontkenning ("De winkel is niet open op zondag" versus "De winkel is open op zondag") heeft een hoge cosinussimilariteit op embeddingniveau, terwijl de feitelijke betekenis lijnrecht tegenovergesteld is.

Niveau 3: LLM-as-a-Judge

Voor complexe beoordelingen — zoals feitelijke correctheid, empathie, logische samenhang of instructietrouw — is een taalmodel met geavanceerde redeneercapaciteiten zelf de beste beoordelaar. Dit principe noemen we LLM-as-a-Judge.

Hierbij voeden we een onafhankelijk beoordelingsmodel (de 'rechter') met de oorspronkelijke gebruikersinvoer, het gegenereerde antwoord, eventueel de contextdocumenten en een expliciete scoringsrubriek. De rechter krijgt de opdracht om eerst stapsgewijs te redeneren en pas daarna een gestructureerd oordeel (zoals een score van 1 tot 5 of een binaire 'PASS'/'FAIL') te vellen.

Hieronder staat een voorbeeld van een effectieve beoordelingsprompt voor feitelijke accuraatheid:

Je bent een neutrale en strikte examinator die antwoorden van een AI-systeem beoordeelt.

[BRONCONTEXT]
{context}

[GEBRUIKERSVRAAG]
{vraag}

[GEGENEREERD ANTWOORD]
{antwoord}

Beoordeel of het gegenereerde antwoord feitelijk volledig wordt ondersteund door de broncontext.
Volg strikt deze stappen:
1. Identificeer alle feitelijke beweringen in het gegenereerde antwoord.
2. Controleer voor elke bewering of deze expliciet terug te vinden is in de broncontext.
3. Noteer eventuele tegenstrijdigheden of niet-ondersteunde aannames (hallucinaties).
4. Geef je eindoordeel in JSON-formaat.

Formaat:
{
  "redenering": "Stapsgewijze analyse...",
  "bevat_hallucinaties": true/false,
  "score": 1 tot 5,
  "oordeel": "PASS of FAIL"
}

In de gids over AI-agent engineer worden in 2026 ontdek je hoe geautomatiseerde evaluaties een centrale rol spelen bij het bouwen van robuuste softwaresystemen en autonome agents.

Een gouden testset samenstellen

Zonder een representatieve testdataset (vaak de golden dataset genoemd) zijn evaluaties waardeloos. Een goede testset weerspiegelt de werkelijke diversiteit van productieverkeer en bevat minstens honderd tot vijfhonderd voorbeelden.

Een gebalanceerde testset bestaat uit vier pijlers:

• Standaardgevallen (Happy path): Veelvoorkomende, duidelijke vragen waarvoor een eenduidig antwoord bestaat.
• Randgevallen (Edge cases): Vragen met ontbrekende informatie, extreem lange teksten of ambigue formuleringen.
• Tegenstrijdige en kwaadaardige invoer (Adversarial): Pogingen tot prompt injection, ongepaste verzoeken of verzoeken die buiten het domein van de applicatie vallen.
• Taalspecifieke eigenschappen: Specifiek voor Nederlandstalige toepassingen: invoer met samengestelde woorden, afkortingen, typfouten en regionale terminologie.

Laten we kijken naar een concrete Nederlandse casus: een klantenservice-assistent voor een Nederlandse zorgverzekeraar. In plaats van generieke voorbeelden test je situaties zoals:

Statistische metrieken en kwantificering

Zodra je evaluatieset draait over honderden voorbeelden, analyseer je de geaggregeerde resultaten met concrete meetwaarden. Afhankelijk van de toepassing gebruik je verschillende metrieken:

1. Pass Rate (% geslaagde tests): Het percentage testcases dat aan alle binaire voorwaarden voldoet. Dit is de meest gangbare indicator in continuous integration (CI/CD) pijplijnen.

2. Precisie, Recall en F1-score: Cruciaal bij classificatietaken of informatie-extractie. Precisie meet hoeveel van de geëxtraheerde entiteiten correct waren. Recall meet hoeveel van alle aanwezige entiteiten daadwerkelijk zijn opgemerkt.

3. Pass@k: Deze metriek wordt veel gebruikt bij code-generatie en redeneertaken. Als we het model $k$ antwoorden laten genereren voor dezelfde vraag, hoe groot is de kans dat minstens één daarvan volledig correct is? Dit geeft inzicht in het generatieve potentieel van het model onder verschillende sampling-instellingen.

4. Win-rate bij A/B-vergelijking: Wanneer je twee prompts of twee modellen direct tegen elkaar afweegt, laat je een rechter bepalen welk antwoord superieur is. Lees de handleiding over A/B-testen van prompts om te zien hoe je twee promptvarianten systematisch tegen elkaar afweegt in een live testomgeving.

Valkuilen en blinde vlekken bij geautomatiseerde evals

Hoewel LLM-as-a-judge krachtig is, introduceert het zijn eigen structurele meetfouten. Wie hier geen rekening mee houdt, optimaliseert voor een scheefgetrokken werkelijkheid. De belangrijkste valkuilen zijn:

• Positiebias (Position bias): Wanneer een model twee antwoorden (A en B) moet vergelijken, heeft het vaak een sterke voorkeur voor het antwoord dat als eerste wordt gepresenteerd. Dit los je op door elke vergelijking tweemaal uit te voeren met omgewisselde volgorde (A/B en B/A) en alleen een overwinning toe te kennen als het model consistent blijft.
• Lengtebias (Verbosity bias): Taalmodellen beoordelen langere, breedvoerige antwoorden stelselmatig als kwalitatiever dan beknopte antwoorden, zelfs als de extra tekst puur opvulling is. Je voorkomt dit door expliciet in de rubricering op te nemen dat beknoptheid en directheid worden beloond.
• Zelfvoorkeur (Self-enhancement bias): Modellen van een bepaalde leverancier geven vaak een hogere score aan tekst die door een model uit dezelfde familie is gegenereerd. Gebruik bij voorkeur een ander type model als rechter dan het model dat je test.

Integratie in de ontwikkelcyclus

Evaluaties leveren pas echt waarde op wanneer ze een vast onderdeel vormen van de ontwikkelcyclus. Dit betekent dat bij elke aanpassing in de prompt, de contextaanvoer of het onderliggende model de evaluatiesuite automatisch wordt uitgevoerd.

Door drempelwaarden in te stellen (bijvoorbeeld: een pull request mag pas gemerged worden als de pass rate minimaal 95% is en er geen enkele veiligheidscheck faalt), creëer je reproduceerbaarheid. Zo transformeer je promptontwikkeling van een onvoorspelbaar knutselproces naar een volwaardige software-engineeringdiscipline.