LLM Evals

Wat zijn LLM Evals?

LLM-evals zijn herhaalbare, geautomatiseerde tests die meten of de output van een taalmodel een gedefinieerde kwaliteitslat haalt: correctheid, toon, veiligheid, formaat, taakvoltooiing. Waar unittests controleren dat code zich deterministisch gedraagt, scoren evals probabilistische output tegen een standaard, zodat teams prompts en modellen kunnen wijzigen zonder te gokken of kwaliteit is bewogen.

De belangrijkste punten

• Evals zijn de regressiesuite voor AI-features. Zonder ze is elke promptaanpassing en modelupgrade een blinde wijziging aan productiegedrag.
• Een nuttige eval heeft drie delen: een dataset van representatieve inputs, een beoordelingsmethode, en een drempel die implementatie poort.
• Beoordelingsmethoden stapelen op kosten: exact-match- en codegebaseerde checks eerst, LLM-as-a-judge voor kwaliteiten die stringmatching weerstaan, menselijke review voor kalibratie.
• De dataset doet er meer toe dan het framework. Twintig echte faalgevallen uit productie verslaan vijfhonderd generieke voorbeelden.
• Evals zijn nooit klaar. Elk productie-incident zou een evalcase moeten worden, op dezelfde manier waarop uitvallen regressietests worden.

Hoe het werkt

Een evalrun neemt een dataset van inputs, voert je daadwerkelijke systeem tegen elk uit (prompt, model, retrieval, wat er ook in het pad zit), en beoordeelt elke output. De beoordeling is waar ontwerpinspanning zich concentreert. Deterministische checks komen eerst omdat ze gratis en ondubbelzinnig zijn: parseerde de JSON, voerde de SQL uit, bevat het antwoord de vereiste terugbetalingsbeleidsclausule, slaagde gegenereerde code voor zijn tests. Alles wat goedkope checks overleeft maar nog steeds oordeel nodig heeft, zoals behulpzaamheid of getrouwheid aan een brondocument, gaat naar een modelgebaseerde beoordelaar die scoort tegen een geschreven rubriek. Een kleine plak krijgt periodieke menselijke review om te bevestigen dat de geautomatiseerde beoordelaars nog steeds overeenstemmen met mensen.

Scores rollen op tot metrieken die je per commit volgt, precies zoals een testsuite. Teams bedraden evals in CI zodat een promptwijziging die taaknauwkeurigheid van 94 naar 81 procent laat vallen de merge blokkeert in plaats van stilletjes uit te leveren. Adoptie loopt nog achter op de retoriek: in LangChains onderzoek van eind 2025 onder meer dan 1.300 professionals rapporteerde slechts 52,4 procent van de organisaties offline-evaluaties te draaien op testsets en draaide slechts 37,3 procent online-evaluaties [1]. Dat is echte vooruitgang ten opzichte van het jaar ervoor, toen hetzelfde onderzoek 39,8 procent vond die offline-evals gebruikte en 32,5 procent online [2], maar het betekent nog steeds dat ruwweg de helft van de industrie wijzigingen uitlevert op gevoel. Dezelfde suite draait wanneer een aanbieder een nieuwe modelversie uitbrengt, wat vaak waar stille regressies vandaan komen: de leverancier upgradede, je prompts bleven hetzelfde, en gedrag verschoof onder je. Dit is ook de verdediging tegen model drift.

Het bouwen van de dataset is de onglamoureuze kern. Goede bronnen zijn productielogs, supportescalaties, en randgevallen die het team al weet lastig te zijn. Synthetische data kan dekking opvullen, maar de ankervoorbeelden zouden echt moeten zijn. De meeste teams beginnen gênant klein, tien tot vijftig gevallen, en laten de suite groeien elke keer dat iets breekt.

Voorbeeld

Een fintech-team levert een assistent uit die vragen beantwoordt over transactiegeschillen. Voor lancering bouwen ze een evalsuite van 120 echte geanonimiseerde klantvragen met referentieantwoorden geschreven door hun supportleads. Elke run controleert drie dingen: een codegebaseerde check dat antwoorden nooit een gegarandeerde terugbetalingstermijn stellen (een complianceregel), een LLM-judge die feitelijke overeenstemming met het referentieantwoord scoort op een schaal van 1 tot 5, en een formatteringscheck voor de vereiste escalatielink. De suite draait bij elke promptwijziging. Twee maanden later brengt hun aanbieder een modelupdate uit; de evalrun vangt dat de nieuwe versie een chargeback-vraag begint te beantwoorden met het verkeerde geschillenvenster, één regel in een rapport van 120 gevallen. Ze pinnen de oude versie, herstellen de prompt, en leveren de upgrade een week later uit met scores intact. Niemand buiten het team zag ooit de regressie.

Veelvoorkomende misvattingen

De grote misvatting is dat publieke benchmarks private evals overbodig maken. De score van een model op een LLM-benchmark zoals MMLU of SWE-bench vertelt je over algemene capaciteit, en niets over of hij je terugbetalingsbeleid, je schema, je toonrichtlijnen aankan. Teams kiezen het model bovenaan een ranglijst, slaan het bouwen van hun eigen suite over, en ontdekken in productie dat ranglijstpositie en taakprestatie hoogstens losjes gecorreleerd zijn. Developers voelen de kloof al: het Stack Overflow Developer Survey van 2025 vond dat 46 procent de nauwkeurigheid van AI-tools actief wantrouwt, tegenover 33 procent die het vertrouwt [3]. Benchmarks selecteren kandidaten. Evals op je eigen data kiezen de winnaar en houden hem eerlijk.

FAQ

Wat is het verschil tussen evals en testen? Traditionele tests toetsen deterministisch gedrag: dezelfde input, dezelfde output, slagen of falen. Evals scoren probabilistische output tegen een kwaliteitslat en rapporteren percentages in plaats van absolute waarden, een slagingspercentage van 94 procent, geen groen vinkje. In de praktijk hebben AI-producten beide nodig, unittests voor de omringende code en evals voor het modelafhankelijke gedrag. De bredere discipline AI testing dekt hoe de twee samenpassen.

Hoeveel evalgevallen heb je nodig om te beginnen? Minder dan de meeste teams denken. Twintig tot vijftig goed gekozen gevallen die je hoofdtaak en bekende faalpatronen dekken, vangen echte regressies vanaf dag één. Statistisch vertrouwen verbetert met omvang, maar een imperfecte suite die bij elke wijziging draait, verslaat een perfecte suite die nooit uitgeleverd wordt. Laat hem groeien vanuit productiemislukkingen.

Zijn AI-evals alleen voor chatbots? Nee. Alles met een model in de loop heeft ze nodig: extractiepipelines, codegeneratie, RAG-systemen, en agents. Agents hebben een uitgebreide vorm nodig, agentspecifieke evaluatie, die meerstaps trajecten en toolgebruik beoordeelt in plaats van enkele antwoorden.

Bronnen

1. LangChain. "State of Agent Engineering-onderzoek onder meer dan 1.300 professionals: 52,4% draait offline-evaluaties, 37,3% draait online-evaluaties." https://www.langchain.com/state-of-agent-engineering. Geraadpleegd augustus 2026.
2. LangChain. "State of AI Agents-onderzoek onder meer dan 1.300 professionals: 39,8% gebruikte offline-evaluaties, 32,5% gebruikte online-evaluaties." https://www.langchain.com/stateofaiagents. Geraadpleegd augustus 2026.
3. Stack Overflow. "2025 Developer Survey: 46% van de developers wantrouwt de nauwkeurigheid van AI-tools, 33% vertrouwt het." https://survey.stackoverflow.co/2025/ai. Geraadpleegd augustus 2026.