Hoe je een AI-agent evalueert voor productie

Voor wie? Developers die een AI-agent hebben gebouwd en willen weten of die agent goed genoeg werkt om in productie te draaien — of om te begrijpen waarom hij dat niet doet.

Kort: Unit tests zeggen niet of je agent werkt. Non-determinisme vraagt scenario’s in plaats van input-output paren, meerdere evaluatielagen, en een drempel vóór het bouwen. De workshop voor developers werkt dit hands-on uit.

Je agent heeft een taak die hij uitvoert via een reeks stappen. Je hebt hem getest, hij doet wat je verwacht. De vraag die je dan moet stellen: hoe weet je of hij dat ook doet over vijftig variaties van dezelfde invoer, op een maandag om 8u30 wanneer één van de externe diensten trager reageert dan gewoonlijk?

Reguliere software is deterministisch. Invoer X geeft output Y. Agents niet. Hetzelfde verzoek leidt tot verschillende redeneringen en antwoorden. Unit tests meten of code correct loopt, niet of het taalmodel consistent beslist. Evaluatie lost dit op.

Dit artikel legt de drie evaluatielagen uit, hoe je een evalset bouwt die echt iets zegt, en wanneer een agent goed genoeg is om te deployen.

Drie lagen, drie vragen

Een goede evaluatie beantwoordt drie afzonderlijke vragen. Je kunt ze niet samenvoegen tot één metriek.

Task completion — heeft de agent de taak afgerond? Dit is binair: ja of nee. De agent moest een afspraak plannen. Staat die in de agenda? Dan is de taak afgerond. Dit meet je geautomatiseerd door te checken of de verwachte eindtoestand bereikt is.

Step accuracy: Klopten de tussenliggende stappen? Een agent die het juiste resultaat bereikt via de verkeerde weg, bereikt in andere contexten het verkeerde resultaat. Als je agent een offerte verstuurt zonder beschikbaarheid te checken, is de stap fout, ook al klopt de offerte. Step accuracy vereist beoordeling van redenering en tool calls, niet alleen einduitvoer.

Consistency: Doet de agent hetzelfde over variaties? Formuleer de vraag 10x anders, wissel tijdstip en invoerlengte: bereikt de agent consistent hetzelfde eindresultaat? Een agent die op 7 van 10 pogingen goed aanroept, is niet betrouwbaar; hij is soms geluk.

Elke laag zegt iets anders. Task completion 90% met step accuracy 60% betekent geluk, niet kwaliteit.

Een evalset bouwen die echt iets zegt

Een evalset voor agents is geen collectie van input-output paren. Het zijn scenario’s. Elk scenario beschrijft: de invoer, het verwachte einddoel, een lijst van stappen die logisch zijn, en een lijst van stappen die verboden zijn.

Voorbeeld: je agent plant afspraken. Scenario: een gebruiker vraagt een vergadering te plannen voor morgen om 14u. Verwacht einddoel: afspraak staat bevestigd in de agenda. Logische stap: agenda-API aanroepen om beschikbaarheid te checken. Verboden stap: afspraak aanmaken zonder beschikbaarheid te hebben gecheckt.

Verboden stappen zijn minstens zo belangrijk als logische. Ze beschrijven de grens tussen correct en roekeloos gedrag en testen randgevallen waar agents falen.

Minimale omvang: 20 tot 50 scenario’s. Dekt 3 categorieën:

• Happy path — invoer die recht op het doel afgaat
• Edge cases — ontbrekende context, ambigue formuleringen, conflicterende instructies
• Bewust moeilijke invoer — gesimuleerde tool failures, invoer met typefouten, vragen die buiten de scope van de agent vallen

De meest gemaakte fout: evalsets uit demo-cases. Diese scoren 100% omdat ze de gevallen testen waarvoor je bouwde, niet waar de agent faalt. Een evalset die je agent niet uitdaagt, vertelt niets.

Automatisch scoren: LLM-as-judge

Menselijke beoordeling is te traag om al je scenario’s bij elke release te doorlopen. De praktische oplossing: gebruik een tweede taalmodel om de uitvoer van het eerste te beoordelen.

Je schrijft een rubric: een beschrijving van wat een correcte uitvoer is, per criterium. Heeft de agent de juiste tool gekozen? Sluit het antwoord aan bij de toon van de instructies? Is de redenering consistent met de eindactie? Het beoordelende model geeft per criterium een score met motivatie.

Dit werkt goed voor kwaliteit, toon en consistentie. Minder goed voor feiten: een model met dezelfde trainingsdata maakt dezelfde fouten als rechter als agent. Het werkt niet voor veiligheidsrisico’s: een model dat jouw domeinrisico’s niet kent, ziet ze niet als rechter.

Praktisch model: automatisch scoren van 95% van scenario’s, menselijk beoordelen van de 5% met lage scores of buiten parameters. Die 5% is je kalibratieset: controle of rubric klopt en of het model systematisch afwijkt van je oordeel.

Wat je meet

Vier metrieken geven je samen een werkbaar beeld:

1. Task completion rate per categorie (niet alleen overall; 98% happy-path met 40% edge cases is ander verhaal dan gemiddelde)
2. Foutpercentage per stap-type (welke tool calls falen vaakst, op welk moment)
3. Gemiddeld aantal stappen per taak (efficiency-indicator; meer dan verwacht is signaal dat de agent rondloopt)
4. Escalatierate (hoeveel procent kan de agent niet zelfstandig afhandelen; bepaalt benodigde menselijke capaciteit)

Kosten per taak en latency horen ook in dit beeld, maar zijn instrumenteel: ze bepalen of je agent schaalbaar is, niet of hij correct is.

Wanneer is goed genoeg goed genoeg

Er is geen absolute drempel. Vergelijk de agent met menselijk alternatief. Als een medewerker 85% correct doet, kan een agent op 85% acceptabel zijn (afhankelijk van kosten van de 15%). Bij hoog-risico taken (financieel, juridisch, medisch) pas je de lat aan en bouw je escalatiepaden.

Kernprincipe: stel de drempel vast vóór het bouwen, niet erna. Een drempel achteraf, op basis van wat je agent haalt, is geen drempel; het is een rationalisatie.

Evaluatie is geen eindpunt

Een agent die vandaag 90% scoort, kan over 3 maanden 70% scoren als externe API’s wijzigen, gebruikers hun taal veranderen of de context verschuift. Evaluatie is geen eenmalige poort; het is doorlopend.

Dat begint met een evalset die niet jouw demo test, maar jouw edge cases. En met een drempel die je verdedigt tegenover de risico’s van de use case, niet tegenover wat haalbaar voelt na een week bouwen.

In de tweedaagse workshop voor developers bouw je een evalset voor je eigen agent, stel je een LLM-as-judge rubric op en kalibreer je hem op menselijke beoordelingen. Je vertrekt met een evaluatieproces dat je in productie kunt draaien.