Evals: hoe je écht weet of je AI-systeem werkt

Vraag een team hoe het weet dat zijn AI-functie werkt, en je hoort meestal een variant van: "we hebben een stel voorbeelden geprobeerd en het leek goed."

Dat antwoord is prima voor een prototype en fataal voor alles in productie. Het betekent namelijk dat je geen onderscheid kunt maken tussen een promptwijziging die hielp en een die hielp op de vier voorbeelden die je toevallig bekeek, terwijl hij stilletjes een vijfde geval sloopte waar je nooit aan dacht.

Evals zijn de oplossing. Ze zijn ook de betrouwbaarste voorspeller die wij kennen van de vraag of een AI-project het haalt.

Begin met 20 voorbeelden, niet 2.000

De meest voorkomende reden dat teams geen evals hebben, is dat het klinkt als een kwartaal werk. Dat is het niet.

Begin met 20 voorbeelden die je echte verdeling dekken, inclusief de lelijke stukken:

• De vijf meest voorkomende gevallen (de saaie meerderheid van je verkeer)
• Drie echte randgevallen die je kent
• Twee gevallen waar het juiste antwoord "ik weet het niet" of "escaleren" is
• Twee vijandige of misvormde invoeren
• Alles waar al eens een mens over geklaagd heeft

Twintig voorbeelden vangen het merendeel van je promptregressies. Van twintig naar tweehonderd komen is een achtergrondtaak die je eeuwig voedt vanuit productiefouten.

Haal ze uit de werkelijkheid. Een steekproef uit productieverkeer verslaat alles wat je zelf verzint, omdat je fantasie bevooroordeeld is richting de gevallen waarvoor je al ontworpen hebt. Elke fout die een mens bereikt, wordt een permanent eval-geval — die ene gewoonte levert meer op dan al het andere op deze lijst.

Kies de goedkoopste metriek die kan falen

Niet alles heeft een taalmodel als beoordelaar nodig. Werk deze lijst af en stop bij het eerste niveau dat kan uitdrukken waar het je om gaat:

Niveau 1 — deterministische checks. Gratis, direct en ondubbelzinnig. Is de JSON geldig? Klopt hij met het schema? Zit de enum-waarde in de toegestane set? Bestaat het geciteerde ordernummer echt? Riep hij de verwachte tool aan met de verwachte argumenten?

Een verrassend deel van de echte fouten wordt hier gevangen. Draai deze op elk geval.

Niveau 2 — scoren tegen een referentie. Als er een bekend juist antwoord is: exacte match, F1 over geëxtraheerde velden, of semantische gelijkenis voor vrijere tekst. Perfect voor classificatie, extractie en routering.

Niveau 3 — LLM-als-jury. Voor alles wat echt subjectief is: toon, behulpzaamheid, getrouwheid aan een bron. Krachtig en makkelijk verkeerd te doen; zie hieronder.

Niveau 4 — menselijke beoordeling. De grondwaarheid, en duur. Reserveer die voor het kalibreren van je jury en voor periodieke steekproeven, niet voor de dagelijkse cyclus.

LLM-als-jury betrouwbaar maken

Een model dat de output van een ander model beoordeelt werkt goed, mits je de jury behandelt als een systeem dat zelf ook geëvalueerd moet worden.

Scoor één dimensie tegelijk. "Geef dit antwoord een cijfer van 1–10" levert ruis op. "Wordt elke feitelijke bewering in dit antwoord gedekt door de gegeven context? Ja/Nee" levert signaal op. Draai liever meerdere smalle jury's dan één brede.

Geef de jury een rubric met concrete criteria, geen bijvoeglijke naamwoorden. Niet "is dit een goed antwoord" maar "noemt het antwoord een concrete bezorgdatum, citeert het een ordernummer, en belooft het geen terugbetaling". Onafhankelijk beoordeelbare criteria zijn het hele spel.

Gebruik bij voorkeur binaire of driepuntsschalen. Jury's zijn onbetrouwbaar in fijne numerieke onderscheidingen en betrouwbaar in geslaagd/gezakt. Een schaal van 1–10 meet vooral het humeur van de jury.

Let op positiebias. Bij paarsgewijze vergelijkingen bevoordelen jury's het antwoord dat als eerste kwam. Draai beide volgordes en middel, anders lever je een "verbetering" op die eigenlijk een volgorde-artefact is.

Kalibreer tegen mensen. Laat iemand 50 gevallen labelen die de jury heeft gescoord. Ligt de overeenstemming onder ~80%, repareer dan de rubric voordat je één getal ervan vertrouwt. Controleer opnieuw na elke wisseling van jurymodel.

Laat de jury niet zien wie wat schreef. Strip identificerende opmaak. Modellen vertonen een meetbare voorkeur voor tekst in hun eigen stijl.

Wat je meet, per systeemtype

Systeem	Belangrijkste metrieken
Classificatie / routering	Nauwkeurigheid, recall per klasse, verwarringsmatrix
Extractie	F1 per veld, percentage schema-geldig
RAG	Recall@k, getrouwheid, antwoordrelevantie, geldigheid van citaten
Agents	Taakvoltooiing, correctheid van tool-aanroepen, aantal stappen, escalatieprecisie
Generatie	Getrouwheid, instructienaleving, formaatnaleving, veiligheid

Voor agents geldt in het bijzonder: taakvoltooiing alleen is niet genoeg. Een agent die de taak in 40 tool-aanroepen afrondt, kost een veelvoud van een die het in 6 doet, en gaat veel vaker ergens halverwege de mist in. Volg efficiëntie naast succes.

En volg de escalatieratio in beide richtingen. Een agent die 40% van de tickets escaleert bespaart niets; een die 0% escaleert neemt stilzwijgend beslissingen die hij niet zou moeten nemen. Precisie en recall op de beslissing om te escaleren zijn een eersteklas metriek, geen bijzaak.

Draai ze waar ze beslissingen beïnvloeden

Evals die in een notebook wonen dat iemand af en toe draait, zijn decoratie. Koppel ze aan de plekken waar gedrag verandert:

• Bij elke promptwijziging. Prompts zijn code. Ze horen in versiebeheer en krijgen een testrun.
• Bij elke modelwijziging. Ook kleine versiesprongen. Modelgedrag verschuift tussen versies zonder dat het zich aankondigt — instructienaleving wordt letterlijker, breedsprakigheid herijkt zich, de gretigheid om tools aan te roepen verandert. Een prompt die was afgestemd op de terughoudendheid van het ene model, wordt een overtrigger op het volgende.
• Volgens een schema tegen productiesteekproeven. Je invoerverdeling drijft weg, ook als je code dat niet doet. Neem wekelijks een steekproef uit echt verkeer en scoor die.
• Voor en na elke retrieval-wijziging. Chunking, herbouw van de index, upgrades van embeddings — die verschuiven allemaal de recall.

Zet een drempel en behandel het overschrijden ervan als een gefaalde build, niet als een notitie in een dashboard.

De regressieval

Het patroon dat teams verbrandt: een wijziging verbetert het gemiddelde en sloopt een specifiek geval dat enorm belangrijk was.

Gemiddelde scores verbergen dat per definitie. Twee verdedigingslinies:

Houd een gouden set die nooit mag verslechteren. Een klein aantal gevallen — die waar fout zijn echt duur is — waar elke daling de release blokkeert, ongeacht wat het gemiddelde deed.

Vergelijk per geval, niet alleen in totaal. Maak na elke run een lijst van de gevallen waarvan het resultaat veranderde. Zowel verbeteringen als regressies. Een wijziging met netto nul scoreverschuiving die elf gevallen in beide richtingen omklapte, is geen neutrale wijziging; het is een volledig ander systeem met hetzelfde gemiddelde.

Hoe goed eruitziet

Een team met werkende evals kan deze vragen binnen een minuut beantwoorden:

• Wat is ons slagingspercentage deze week, en vorige week?
• Welke faalwijze komt op dit moment het vaakst voor?
• Als we morgen van model wisselden, zou de kwaliteit dan omhoog of omlaag gaan?
• Welke van de laatste tien promptwijzigingen hebben echt geholpen?

Een team zonder evals beantwoordt alle vier met "het voelt ongeveer hetzelfde." Dat is het verschil tussen een systeem dat je verbetert en een systeem waar je op hoopt.

Waar je maandag begint

1. Haal 20 echte invoeren uit je logs, waaronder drie die misgingen.
2. Schrijf voor elk het juiste antwoord op. Ja, met de hand.
3. Voeg de deterministische checks toe — schema, formaat, verplichte velden. Een uur werk.
4. Draai het. Noteer de score. Dat getal is nu je basislijn.
5. Voeg elke nieuwe productiefout toe aan de set, voor altijd.

Stap vijf is degene die telt. De rest is voorbereiding.

---

Elke agent die wij opleveren komt met zijn eval-set, zijn drempel en een review na 30 dagen — en haalt hij de drempel niet, dan repareren we het op onze kosten. Plan een auditgesprek.