Zo evalueer je AI-agenten: kijk naar het hele traject

Een AI-agent evalueer je door te controleren of die een concreet gebruikersdoel haalt én hoe hij daar komt. Alleen het eindantwoord beoordelen is te mager: een overtuigend antwoord kan fouten in tussenstappen, toolaanroepen of gevolgde voorwaarden verhullen. Voor ontwikkelaars en technische leiders is een vaste evaluatiewerkwijze daarom nuttiger dan een losse geslaagde run.

Een herhaalbare evaluatie begint met een gebruikersreis

Begin bij een kritieke gebruikersreis: leg vast voor wie de agent werkt, welk doel die persoon heeft, aan welke beperkingen de agent moet voldoen en waaraan je succes herkent. Google adviseert om iedere voorwaarde in die reis om te zetten in een afzonderlijk evaluatiepunt. Zo wordt een algemene vraag als ‘werkt de agent?’ een reeks concrete controles.

De werkwijze, stap voor stap

1. Leg het gebruikersdoel en de succesvoorwaarden vast. Beschrijf de gebruiker, het doel, de beperkingen en de manier waarop je controleert of de taak is geslaagd. Maak van iedere voorwaarde een afzonderlijke controle. Google werkt deze aanpak uit in zijn handleiding voor het evalueren van AI-agenten.
2. Maak scenario’s voor verwachte routes en randgevallen. Test zowel de normale route als situaties waarin informatie ontbreekt, onvolledig is of anders loopt dan verwacht. Google adviseert om met gesimuleerde gebruikers te beginnen en later echte productietraces toe te voegen. Zo kun je al evalueren voordat er veel productiegegevens zijn.
3. Bekijk de uitvoeringstraces voordat je fouten automatiseert. Een trace is het uitvoeringsspoor van een agent: bijvoorbeeld de prompts, tussenstappen, argumenten voor toolaanroepen en uiteindelijke uitvoer. Bekijk zulke traces eerst handmatig en zet terugkerende foutpatronen daarna om in herhaalbare controles. Daarmee voorkom je dat je een score ziet dalen zonder te begrijpen waar de agent vastloopt.
4. Maak runs vergelijkbaar door variatie in te perken. Agenten kunnen bij dezelfde taak verschillende uitvoeringspaden volgen. Braintrust adviseert daarom meerdere trials per taak en gecontroleerde afhankelijkheden, zoals stubdiensten of snapshots van data. Een sandbox en nagebootste fouten — bijvoorbeeld time-outs, onjuist gevormde antwoorden of ontbrekende velden — kunnen ook helpen om herstelgedrag te testen. Het aantal trials kies je voor je eigen evaluatie; de Braintrust-gids stelt daarvoor geen universeel getal vast.
5. Combineer verschillende soorten controles. Google onderscheidt unittests, deterministische metrieken, rubrieken voor LLM-beoordelaars en integratietests. Ze leggen verschillende problemen bloot: een unittests controleert een afzonderlijk onderdeel, een deterministische metriek een vooraf vastgelegde uitkomst en een integratietest de samenwerking tussen onderdelen. Een LLM-beoordelaar kan antwoorden aan de hand van een rubric beoordelen; vergelijk zulke automatische scores met handmatig beoordeelde traces.
6. Test LLM-beoordelaars op presentatiedruk. IBM Technology beschrijft positionele bias, waarbij de volgorde van antwoorden het oordeel beïnvloedt, en bias voor langere antwoorden of voor een antwoord dat het beoordelende model zelf heeft gemaakt. Verwissel de antwoordposities en kijk of het oordeel verandert: die proef richt zich specifiek op positionele bias. Zahra Ashktorab bespreekt in de Engelstalige IBM Technology-video ook rubricbeoordeling en paarsgewijze vergelijking.
7. Houd de testset stabiel en bewaak regressies. Vergelijk aanpassingen aan de agent met dezelfde vaste testset en verander bij het afstellen één variabele tegelijk. Neem naast antwoordkwaliteit ook operationele metrieken mee, zoals latency, tokengebruik, API-kosten en het aantal toolaanroepen. Google beschrijft een CI/CD-poort met een algemene slaagdrempel en blokkering bij regressies in eerder geslaagde kernmetingen; 95% is daarbij een voorbeeld, geen algemene norm.
8. Gebruik productiebevindingen om tests bij te werken. Online evaluatie kan live interacties en uitkomsten volgen. Microsoft beschrijft hoe bevindingen daaruit kunnen worden gebruikt om offline testdata aan te vullen. Zo kunnen onverwachte situaties uit de praktijk terugkomen in volgende evaluaties en regresstests.