AI-agentevaluatie

Wat is AI-agentevaluatie?

AI-agentevaluatie is de praktijk van meten of een AI-agent taken end-to-end correct voltooit, waarbij het volledige traject van beslissingen, tool-aanroepen en tussenstappen wordt gescoord, naast de uiteindelijke uitkomst. Het breidt evaluatie van één antwoord uit naar meerstaps autonoom werk, waarbij een agent een goed antwoord kan bereiken via een kapot proces, of tien stappen na een goede start kan falen. De inzet blijft stijgen omdat agents steeds capabeler worden: METR mat in 2025 dat frontier-modellen zoals Claude 3.7 Sonnet een tijdshorizon van ongeveer 50 minuten hebben bij 50% taakvoltooiing, een horizon die sinds 2019 ongeveer elke zeven maanden is verdubbeld [1].

De belangrijkste punten

• Agents hebben evaluatie op trajectniveau nodig, niet alleen op outputniveau. Een correct eindantwoord bereikt door een klantrecord te verwijderen en opnieuw aan te maken is nog steeds een mislukking.
• De drie standaardlagen zijn uitkomst (is de taak voltooid), traject (waren de stappen zinnig en veilig), en tool-gebruik (juiste tool, juiste argumenten, resultaten daadwerkelijk gebruikt).
• Kleine foutpercentages per stap stapelen zich op: 95 procent stapnauwkeurigheid over twintig stappen levert ongeveer één op drie kans op taakmislukking op, en dat is waarom agents minder betrouwbaar aanvoelen dan de modellen erin.
• Omgevingsontwerp is de helft van het werk. Reproduceerbare sandboxed omgevingen met controleerbare eindtoestanden maken agent-evals betrouwbaar; ad-hoc-demo's niet.
• Combineer offline evals met productietracing. De evalsuite voorspelt gedrag; AI-observability bevestigt het tegen echt verkeer.

Hoe het werkt

Een agent evalueren betekent een lus evalueren, geen antwoord. De agent ontvangt een taak, plant, roept tools aan, leest resultaten en itereert, dus moet de evaluatie het hele traject vastleggen. Uitkomstchecks zijn het anker: definieer een verifieerbare eindtoestand, het ticket is gesloten met de juiste resolutiecode, de pull request slaagt voor tests, de rij bestaat in de database, en toets dat programmatisch. Dit is het agent-equivalent van een acceptatietest, en het is wat de meeste gepubliceerde agentbenchmarks zoals SWE-bench-achtige suites meten. Die benchmarks laten ook zien hoe snel de grond verschuift: toen SWE-bench in 2023 lanceerde, loste het best presterende model, Claude 2, slechts 1,96 procent van echte GitHub-issues end-to-end op [2], en de Stanford HAI 2025 AI Index registreerde SWE-bench-scores die in één jaar met 67,3 procentpunt stegen [3].

Uitkomstchecks alleen verbergen gevaarlijk gedrag, dus voegen volwassen suites trajectbeoordeling toe. Hier scoor je hoe de agent er kwam: aantal stappen versus een redelijke baseline, of hij destructieve tools aanriep die hij niet nodig had, of hij herstelde van een mislukte tool-aanroep of erin bleef hangen, of hij tool-argumenten verzon. Een deel hiervan is regelgebaseerd (toets dat het delete-endpoint nooit werd aangeroepen), en de kwalitatieve rest gaat naar een LLM-judge die het traject leest tegen een rubriek. Tool-gebruik-metrieken zitten eronder: correct toolselectiepercentage, argumentgeldigheid, en of teruggegeven data daadwerkelijk de volgende stap beïnvloedde.

De infrastructuureis die teams verrast is de omgeving. Elk evalgeval heeft een reproduceerbare starttoestand nodig, een geseede database, een fixture-repository, een gemockte API, zodat runs vergelijkbaar zijn over model- en promptwijzigingen heen. Omdat agents niet-deterministisch zijn, misleiden losse runs; elk geval meerdere keren draaien en slagingspercentages rapporteren (het pass@k-patroon geleend van codegeneratie-onderzoek) geeft cijfers die je kunt vertrouwen.

Voorbeeld

Een team bouwt een supportagent die terugbetalingsverzoeken end-to-end afhandelt: bestelling opzoeken, terugbetalingsbeleid controleren, terugbetaling uitgeven via de betalings-API, en de klant e-mailen. Hun evalsuite bevat 60 scenario's, elk een geseede sandbox met een nepbestellingsdatabase en een gemockte betalings-API. Eén scenario: een bestelling buiten het venster van 30 dagen. De uitkomstcheck toetst dat er geen terugbetaling is uitgegeven en dat de klant-e-mail het beleid uitlegt. De trajectcheck toetst dat de agent de beleidstool raadpleegde voordat hij besliste, in plaats van te gokken. Wanneer ze een goedkoper model uitproberen voor de binnenste lus, blijft het uitkomstslagingspercentage op 92 procent staan, maar trajectbeoordeling laat zien dat hij in een kwart van de runs de beleidsopzoeking oversloeg en uit het geheugen antwoordde, juiste antwoorden door geluk. Ze houden het goedkopere model maar voegen een guardrail toe die een beleidsopzoeking afdwingt voor elke terugbetalingsbeslissing, en de kortsluiting verdwijnt.

Veelvoorkomende misvattingen

De klassieke fout is het chattranscript van de agent evalueren in plaats van zijn effecten. Teams lezen een gepolijst gesprek, zien de agent beweren dat hij het CRM heeft bijgewerkt, en scoren het als geslaagd zonder het CRM te controleren. Agents vertellen zelfverzekerd over werk dat ze niet deden, of verkeerd deden, en review op transcriptniveau mist precies die gevallen. Ground truth zit in de omgeving: toets op de databaserij, het API-aanroeplog, de bestandsdiff. Als je eval de eindtoestand niet programmatisch kan controleren, is het een vibe check met extra stappen.

FAQ

Hoe verschilt agentevaluatie van LLM-evals? Standaard LLM-evals beoordelen één input tegen één output. Agentevaluatie beoordeelt een reeks: planning, tool-aanroepen, statuswijzigingen, en herstelgedrag over veel modelaanroepen, beoordeeld tegen de eindtoestand van een omgeving. De single-response-methoden gelden nog steeds binnen elke stap, maar ze zijn noodzakelijk in plaats van voldoende.

Welke metrieken moet een agent-eval rapporteren? Taakslagingspercentage is de kop, idealiter als pass@k over herhaalde runs. Daaronder: stapefficiëntie tegen een baselinetraject, tool-aanroepfoutpercentage, aantal onveilige acties (dat bij nul zou moeten blokkeren voor release), kosten per taak in tokens, en latentie. Kosten doen er meer toe dan teams verwachten, want een agent die slaagt door veertig stappen brute te forceren, kan economisch onverantwoord zijn.

Veranderen multi-agentsystemen de aanpak? De lagen blijven hetzelfde maar attributie wordt moeilijker. Wanneer een orchestrator delegeert aan gespecialiseerde agents, evalueer je het systeem eerst end-to-end, dan per-agent-overdrachten om te vinden waar mislukkingen ontstaan. Tracestructuur uit je orchestratie-laag wordt het ruwe materiaal voor beide.

Bronnen

1. METR. "Frontier-modellen tonen een tijdshorizon van ongeveer 50 minuten bij 50% taakvoltooiing, sinds 2019 ongeveer elke zeven maanden verdubbeld." https://arxiv.org/abs/2503.14499. Geraadpleegd augustus 2026.
2. Jimenez et al., Princeton. "SWE-bench-lanceringsresultaten: beste model (Claude 2) loste 1,96% van echte GitHub-issues op." https://arxiv.org/abs/2310.06770. Geraadpleegd augustus 2026.
3. Stanford HAI. "2025 AI Index Report: SWE-bench-scores stegen in één jaar met 67,3 procentpunt." https://hai.stanford.edu/ai-index/2025-ai-index-report. Geraadpleegd augustus 2026.