Je kunt uitleggen wat een eval is, hoe hij is opgebouwd (dataset met criteria, grader, geaggregeerde score), waarom een paar keer proberen geen bewijs is, en waar een eval je toch voor de gek houdt.
Handig vooraf: Hallucinatie
Je probeerde een handvol prompts, de demo liep gladjes, dus je zette hem live. Daarmee weet je nog niet of je AI werkt. Je weet alleen dat hij een paar keer niet stuk ging. Dat is geen test, dat is een onderbuikgevoel met goede belichting.
Neem een supportbot die vragen over je product beantwoordt. Op je vijf testvragen antwoordt hij keurig, dus live. In productie verzint hij af en toe een functie die niet bestaat, en dat merk je pas als een klant erover valt. De vraag is niet of hij het soms goed doet, maar hoe vaak hij het goed doet, en of dat cijfer stijgt of zakt zodra je iets aanpast.
Er zijn twee manieren om die vraag te beantwoorden. De ene is op gevoel: proberen tot het er goed uitziet. De andere is met een eval.
Wat de rechterkant doet, heet een eval. Een eval is een systematische, herhaalbare test van je AI-systeem: een vaste set representatieve invoer met een verwacht antwoord of duidelijke criteria, een grader die elk item scoort, en een geaggregeerde score waarmee je varianten vergelijkt en stille achteruitgang vangt. Het is in de kern een regressietest voor je AI, geen onderbuikgevoel maar een getal.
Concreet voor die supportbot: je legt vijftig echte vragen vast met het juiste antwoord of duidelijke criteria, draait de bot erover en krijgt een score, zeg 84 procent goed met zes hallucinaties. Pas je daarna je prompt aan, dan zie je meteen of dat getal naar 88 klimt of naar 79 zakt, in plaats van te gokken. En omdat de output varieert door sampling, test je een set, niet een enkele toevallig goede beurt.
Onder die score zitten drie lagen. Klap ze uit van intuitie naar mechaniek:
Vibes is een keer meekijken en denken: ziet er goed uit. Een eval is een vast proefwerk. Dezelfde vragen, een nakijkmodel en een cijfer. Verander je later iets aan je systeem, dan maak je hetzelfde proefwerk opnieuw en zie je meteen of het cijfer stijgt of zakt, in plaats van het te hopen.
Hoe bepaal je of een antwoord goed is?
Dat is de taak van de grader, en er zijn drie soorten, van hard naar zacht. Een regelcheck is het goedkoopst en het meest betrouwbaar: klopt het exact, parseert de JSON, staat het verplichte veld erin. Alleen werkt dat enkel als er een duidelijk juist antwoord is. Voor subjectieve kwaliteit is een mens de gouden standaard, maar traag en duur. Daartussenin zit LLM-as-a-judge: een vaak sterker model beoordeelt de output tegen je criteria of een referentie. Dat is een gedocumenteerde techniek bij zowel OpenAI als Anthropic, en het schaalt goed. Een goede lat voor een bruikbare testvraag: twee mensen vellen er onafhankelijk hetzelfde oordeel over. Kunnen ze het niet eens worden, dan meet je criterium te weinig. De vorm check je dus met regels, de inhoud met een mens of een judge. Hetzelfde onderscheid zie je bij het afdwingen van geldige JSON: structured output borgt dat het formaat klopt, een eval borgt of de inhoud klopt.
Wanneer klopt dat cijfer niet?
Een eval is geen wondermiddel, en hier gaat het vaak mis. Hij is maar zo goed als zijn dataset: een testset die je echte productieverkeer niet trouw nabootst meet net de gevallen die makkelijk gaan en geeft vals vertrouwen. En een model als nakijker is krachtig maar niet neutraal: het onderzoek achter MT-Bench laat zien dat zulke judges systematisch langere antwoorden, de eerste optie en hun eigen output voortrekken, oftewel breedsprakigheids-, positie- en zelfvoorkeur-bias. Daarom ijk je je judge tegen een set menselijke labels en geef je hem een uitweg, een Onbekend voor als hij het niet zeker weet. Reken ook zelden op een enkel getal: juistheid, gegrondheid, formaat en veiligheid zijn aparte assen die je los meet.
Is een hoge benchmarkscore niet genoeg?
Nee, en dat is het laatste misverstand om op te ruimen. Een publieke benchmark meet algemene modelvaardigheid, jouw eval meet jouw taak op jouw data. Een model dat bovenaan een coding-ranglijst staat, zegt niets over of jouw supportbot de juiste dingen zegt. En een eval is geen eenmalige keuring: je draait hem bij elke prompt-wijziging en elke modelupgrade, en je blijft in productie meten, of het nu de retrieval in een RAG-opzet is of de eindtekst. Want zolang de output door sampling varieert, is een enkele goede beurt nooit het bewijs. Dit is ook precies hoe je de hallucinatie-frequentie meet die je anders niet ziet: je kunt niet verbeteren wat je niet meet.
Even terughalen. Beantwoord deze drie en je weet of het zit:
Je supportbot gaf op tien testvragen tien keer een goed antwoord. Weet je nu dat hij werkt?
Zodra je dit ziet, verandert wat klaar betekent. Een indrukwekkende demo is geen bewijs, het is een steekproef van een. Werken doet je AI pas als je het kunt meten, kunt herhalen en het cijfer ziet bewegen als je iets verandert. Vibes voelen sneller. Maar het enige wat een onderbuikgevoel je vertelt, is hoe jij je voelt over vijf voorbeelden, niet hoe je systeem het doet op de vijftig die je nog niet zag.
Veelgestelde vragen
Van demo naar betrouwbaar
Ik denk mee over wat goed genoeg voor jouw taak betekent, ontwerp de eval eromheen en bouw het systeem end-to-end, zodat je op cijfers stuurt in plaats van op onderbuikgevoel.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
