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: Klassieke unit tests vertellen je niet of je agent werkt. Non-determinisme vraagt om een andere aanpak: scenario’s in plaats van input-output paren, meerdere evaluatielagen, en een drempel die je vóór het bouwen vastlegt. De tweedaagse workshop voor developers werkt dit hands-on uit met je eigen use case.

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. Geef je functie invoer X, verwacht je output Y, check je of het klopt. Een agent is dat niet. Hetzelfde verzoek leidt elke keer tot een licht andere redenering, andere tool calls, een ander antwoord. Klassieke unit tests meten of de code correct uitvoert — ze meten niet of het taalmodel consistent en correct beslist. Dat is het probleem dat evaluatie moet oplossen.

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, zal in een andere context het verkeerde resultaat bereiken via diezelfde weg. Als je agent een offerte heeft opgesteld en verstuurd, maar de beschikbaarheid van de contactpersoon nooit heeft gecheckt, is de stap incorrect — ook al klopt de offerte. Step accuracy vereist dat je de redenering én de tool calls beoordeelt, niet alleen de einduitvoer.

Consistency — doet de agent hetzelfde over vijftig variaties van dezelfde vraag? Formuleer je vraag tien keer iets anders, wissel het tijdstip af, varieer de lengte van de invoer: bereikt de agent consequent hetzelfde type eindtoestand? Een agent die op zeven van de tien pogingen de juiste tool aanroept, is niet betrouwbaar — hij is toevallig correct.

Elke laag zegt iets wat de andere niet zegt. Task completion 90% met step accuracy 60% betekent dat je agent vaak geluk heeft, niet dat hij goed werkt.

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.

De verboden stappen zijn minstens even belangrijk als de logische. Ze beschrijven de grens tussen correct en roekeloos gedrag — en ze testen precies de randgevallen waar agents het vaakst de mist ingaan.

Minimale omvang: twintig tot vijftig scenario’s. Dekk drie 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

Dit laatste punt is de meest gemaakte fout: evalsets gebouwd uit demo-cases. Die scoren bijna altijd 100% — omdat ze de gevallen testen waarvoor je de agent hebt gebouwd, niet de gevallen die hem doen falen. Een evalset die je agent niet uitdaagt, is een evalset die je niets vertelt.

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 antwoordkwaliteit, toonmatch en consistentie. Het werkt minder goed voor feitelijke correctheid — een model dat dezelfde trainingsdata heeft gezien, maakt dezelfde fouten als rechter als als agent. En het werkt niet voor veiligheidsrisico’s: een model dat niet getraind is om jouw specifieke domeinrisico’s te herkennen, zal ze ook als rechter niet zien.

Het praktische model: automatisch scoren van 95% van je scenario’s, menselijke beoordeling van de 5% die een lage automatische score krijgt of buiten de verwachte parameters valt. Die 5% is ook je kalibratieset — je gebruikt hem om te controleren of je rubric klopt, of het beoordelende model systematisch afwijkt van je eigen oordeel.

Wat je meet

Vier metrieken geven je samen een werkbaar beeld:

• Task completion rate per categorie — niet alleen overall; een agent die op happy-path 98% scoort maar op edge cases 40%, is een ander verhaal dan zijn gemiddelde suggereert
• Foutpercentage per stap-type — welke tool calls falen het vaakst, op welk moment in de keten
• Gemiddeld aantal stappen per taak — een efficiency-indicator; meer stappen dan verwacht is een signaal dat de agent rondloopt
• Escalatierate — hoeveel procent van de gevallen kan de agent niet zelfstandig afhandelen; dit is ook je maat voor wat je aan menselijke capaciteit nodig hebt

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. Wat je wel kunt doen: vergelijk de agent met het menselijke alternatief. Als een medewerker dezelfde taak in 85% van de gevallen correct afhandelt, is een agent op 85% misschien acceptabel — afhankelijk van de kosten van de resterende 15%. Als de taak hoog-risico is (financieel, juridisch, medisch), pas je de lat aan en bouw je expliciete escalatiepaden.

Het belangrijkste principe: stel die drempel vast vóór je bouwt, niet erna. Een drempel die je achteraf vaststelt op basis van wat je agent haalt, is geen drempel — het is een rationalisatie.

Evaluatie is geen eindpunt

Een agent die vandaag 90% scoort, scoort over drie maanden 70% als de externe diensten waarmee hij werkt hun API’s hebben bijgewerkt, de gebruikers hun formuleringen hebben veranderd, of de context waarvoor hij gebouwd was is verschoven. Evaluatie is geen eenmalige poort — het is een doorlopend proces.

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.