Evals (LLM-evaluatie)

Wat zijn evals?

Evals, afkorting van evaluations, zijn gestructureerde testen om de kwaliteit van een taalmodel of een AI-toepassing te meten. Een eval bestaat uit twee delen: een set testcases met verwachte uitkomsten, en een scoremethode die de output van het model vergelijkt met die verwachting. Evals zijn voor AI wat unit tests zijn voor software, behalve dat de output niet meer zwart-wit is.

Zonder evals is elke modelwijziging giswerk. Je upgradet van Claude 4.5 naar 4.6, de gebruiker zegt "het voelt anders", en je hebt geen idee of dat objectief beter of slechter is. Met evals heb je een cijfer, en kan je gericht bijsturen.

Vergelijk het met een rijexamen. Eén rit met de instructeur zegt weinig. Een gestandaardiseerde route met vaste criteria (parkeren, spiegels checken, richting aangeven) geeft wel een oordeel. Evals zijn die gestandaardiseerde route voor een AI-toepassing.

Soorten evals

Multiple-choice benchmarks
MMLU, HellaSwag, TruthfulQA, BIG-bench. Publieke datasets met vragen waarvan het antwoord vastligt. Makkelijk te scoren, maar Anthropic waarschuwt dat kleine formatverschillen (A/B/C tegenover 1/2/3) de accuracy al met vijf procent kunnen verschuiven. Nuttig als eerste filter, niet als laatste woord.

Referentie-gebaseerde evals
Je hebt een verwacht antwoord en vergelijkt de output van het model. Exact-match voor classificatie, BLEU of ROUGE voor samenvattingen, cosine similarity op embeddings voor semantische nabijheid.

LLM-as-a-judge
Een tweede (meestal krachtiger) model beoordeelt de output van het eerste volgens vooraf afgesproken criteria. Schaalbaar en vrij accuraat bij goed geformuleerde rubrics. Risico: systematische bias van de judge, en de judge zelf moet periodiek tegen menselijk oordeel geijkt worden.

Menselijke beoordeling
A/B-tests waarin mensen twee modelantwoorden vergelijken en aangeven welke beter is. Duur en traag, maar voor nuance (toon, nuttigheid, veiligheid) blijft het de gouden standaard. Anthropic gebruikt het structureel voor training en red-teaming.

Red-teaming
Experts proberen het model kapot te krijgen: jailbreaks, gevaarlijke output, manipulatie. Geen cijfer maar een inventaris van zwaktes. Kritisch voor modellen die in gevoelige domeinen werken (gezondheidszorg, financiën, veiligheid).

Publieke benchmarks versus eigen evals

Publieke benchmarks (MMLU, HELM, BIG-bench) zijn nuttig om modellen onderling te vergelijken. Hun zwaktes:

• Contaminatie. Populaire benchmarks staan online en zitten in trainingsdata. Het model kan ze deels hebben geïnternaliseerd, wat scores opblaast.

• Generiek. Ze meten algemene kennis en redenering, niet of het model werkt voor jouw use case (klantensupport in het Vlaams, facturen lezen, DAX genereren).

• Format-gevoelig. Hoe je de vraag presenteert, beïnvloedt de score meer dan je zou denken.

Eigen evals ondervangen die zwaktes. Een goede eigen eval:

• Ligt dicht bij je echte gebruikers. De testcases zijn reële of realistische queries, niet academische constructies.

• Heeft duidelijke scoring. Voor elke testcase bestaat een objectieve maatstaf of een gedeelde rubric.

• Draait automatisch. Elke wijziging aan prompt, model of temperature triggert de eval en geeft je een cijfer.

Hoe bouw je een eigen eval?

Een pragmatische aanpak in vijf stappen.

1. Verzamel 20 tot 100 realistische testcases. Uit logs, uit interviews met gebruikers, uit edge cases die ooit fout zijn gelopen. Kwaliteit boven kwantiteit: dertig goede cases verslaan driehonderd middelmatige.

2. Formuleer het verwachte gedrag. Voor elke case: wat moet het model minstens doen? Soms een exact antwoord, soms een checklist van eisen ("noemt de prijs", "wijst op garantie-uitsluiting").

3. Kies een scoremethode. Exact-match waar mogelijk, LLM-as-a-judge waar subjectiever, menselijke review voor de eerste paar iteraties.

4. Run baseline. Meet het huidige systeem. Dat is je ijkpunt.

5. Zet regressietesten op. Elke promptwijziging, modelupgrade of parametertuning laat je op deze suite draaien. Zakt de score, dan weet je het vóór je klanten het merken.

Tools zoals OpenAI Evals, Promptfoo, Langfuse en de Anthropic SDK-hulpfuncties versnellen dit, maar je kan ook gewoon starten met een script en een CSV. De tool is ondergeschikt aan de discipline.

Valkuilen

Overfitten op de eval
Als je prompts blijft tunen tot je eval-score maximaal is, kan je gebruikservaring buiten de eval stilletjes verslechteren. Zorg dat je eval representatief blijft en groeit mee met nieuwe gebruikersvragen.

Eval-drift
De wereld verandert. Nieuwe productlijnen, nieuwe regelgeving, nieuw jargon. Een eval van een jaar oud test gedeeltelijk een wereld die niet meer bestaat. Plan een periodieke refresh van je testset.

Te kleine testset
Vijf testcases zeggen niets. Bij elke run zie je toeval. Minimum twintig, liefst vijftig tot honderd per use case om statistische betekenis te krijgen.

Geen kostenmeting
Evals meten vaak kwaliteit en vergeten latency en kosten. Een model dat vijf procent beter scoort maar drie keer duurder is, wil je weten vóór je migreert. Neem tokens en responstijd mee in je scoreboard.