Hoe evalueer je een AI-agent? Taken, trajecten, betrouwbaarheid en kosten

Een AI-agent evalueren betekent testen of die representatieve taken betrouwbaar uitvoert, aanvaardbare routes volgt, binnen de gestelde grenzen blijft en voldoende waarde levert voor de kosten. Alleen het eindantwoord volstaat niet: een agent kan ook via onveilige handelingen, ongefundeerde beweringen, buitensporig veel nieuwe pogingen of puur geluk tot een aannemelijk resultaat komen.

Het evalueren van agents is lastig omdat het systeem gedurende langere tijd handelt. Het model kiest tools, neemt veranderende omgevingen waar en kan bij elke uitvoering een andere route volgen. Effectieve evaluaties meten daarom resultaten en trajecten over herhaalde tests heen.

De terminologie van agentevaluaties

Anthropics gids om evaluaties van agents inzichtelijk te maken biedt een bruikbare verzameling termen:

• Taak: één testgeval met een doel, een omgeving, invoer en succescriteria.
• Poging: één poging van de agent om een taak uit te voeren.
• Transcript of traject: de reeks berichten, beslissingen, toolaanroepen, waarnemingen en handelingen tijdens de poging.
• Beoordelaar: een regel, programma, model of persoon die een deel van de prestaties beoordeelt.
• Evaluatieharnas: het systeem dat omgevingen voorbereidt, pogingen uitvoert, sporen verzamelt, beoordelaars inschakelt en resultaten rapporteert.

Door deze begrippen uit elkaar te houden, voorkom je een veelgemaakte fout: één geslaagde demonstratie zien als bewijs dat de agent betrouwbaar zal presteren.

Begin met een duidelijke taakspecificatie

Een bruikbare evaluatietaak beschrijft de begintoestand, beschikbare tools, beperkingen, het verwachte resultaat en belangrijk gedrag dat verboden is. De test moet op echt werk lijken, zonder één vast voorgeschreven pad prijs te geven.

Voor een ondersteuningsagent is ‘los het ticket op’ te vaag. Een betere taak vermeldt de gegevens van de klant, het toepasselijke beleid, toegestane oplossingen, vereiste communicatie en welke wijzigingen zichtbaar moeten zijn in het bronsysteem. De taak kan dan objectief worden beoordeeld.

Vier lagen van agentevaluatie

Deze lagen moeten in rapportages gescheiden blijven. Als je ze samenvoegt tot één gemiddelde, kan onaanvaardbaar gedrag buiten beeld blijven, bijvoorbeeld een hoge taakscore die verhult dat de agent vaak onbevoegd tools probeert te gebruiken. Teams kunnen eerst strikte veiligheidsvoorwaarden vaststellen en vervolgens de kwaliteit en efficiëntie van de resultaten vergelijken voor de uitvoeringen die aan die voorwaarden voldoen.

1. Kwaliteit van het resultaat

Heeft de agent het doel bereikt? Beoordelaars van resultaten kunnen exacte toestandswijzigingen, verplichte velden, testresultaten, feitelijke juistheid, onderbouwing met citaten of kwaliteit op basis van beoordelingscriteria controleren.

Gebruik waar mogelijk de uiteindelijke toestand van de omgeving in plaats van de bewering van de agent zelf. Een programmeeragent is niet geslaagd alleen omdat die zegt dat de bug is verholpen; de relevante tests en het gedrag moeten dat bevestigen.

2. Kwaliteit van het traject

Heeft de agent een verstandige route gevolgd? Een trajectevaluatie kan onnodige toegang tot gegevens, verboden tools, herhaalde mislukkingen, overgeslagen controles, verzonnen waarnemingen of schendingen van goedkeuringsvereisten opsporen.

Niet elke afwijking van een referentieroute is een fout. Agents kunnen geldige oplossingen vinden waarmee beoordelaars geen rekening hadden gehouden. Beoordelaars moeten echte vereisten handhaven, maar ook alternatieve, efficiënte aanpakken toestaan.

3. Veiligheid en naleving van beleid

Bleef de agent binnen zijn bevoegdheden? Tests moeten promptinjecties, tegenstrijdige instructies, gevoelige gegevens, onduidelijke gebruikersintenties en verzoeken die om weigering of opschaling vragen, omvatten.

Veiligheidsevaluaties moeten in een sandbox realistische gevolgen hebben. Een zin die aan het beleid voldoet, is niet genoeg als de agent het bericht al heeft verstuurd, het dossier heeft gewijzigd of de gegevens heeft blootgelegd.

4. Operationele efficiëntie

Hoeveel tijd en geld waren nodig om succes te behalen? Houd het aantal modeltokens en toolaanroepen, de verstreken tijd, nieuwe pogingen, menselijke tussenkomsten en de kosten van externe diensten bij. Een agent die pas na 100 onnodige handelingen slaagt, is mogelijk minder nuttig dan een eenvoudigere werkwijze.

Gebruik verschillende soorten beoordelaars

Beoordelaars op basis van vaste regels controleren exacte eigenschappen: of een test is geslaagd, of een bestand correct is gewijzigd, of een databaseveld de vereiste waarde heeft en of een verboden eindpunt is aangeroepen. Ze zijn snel en consistent, maar beoordelen alleen wat ontwikkelaars hebben vastgelegd.

Beoordelaars op basis van een model beoordelen eigenschappen als helderheid, volledigheid, relevantie en het naleven van genuanceerde criteria. Ze zijn beter schaalbaar dan menselijke beoordeling, maar moeten zelf worden gevalideerd omdat ze bevooroordeeld of inconsistent kunnen zijn.

Menselijke beoordelaars zijn belangrijk voor deskundige oordelen, dubbelzinnige gevallen en het valideren van geautomatiseerde beoordelaars. Ze zijn trager en duurder, dus teams zetten ze vaak in bij steekproeven, meningsverschillen en domeinen met grote impact.

De sterkste evaluatiesuites combineren deze benaderingen. Het evaluatieplatform van OpenAI beschouwt evaluatie eveneens als een gestructureerd proces voor het definiëren van tests en beoordelaars en het uitvoeren van herhaalde experimenten, in plaats van als een informele inspectie.

Betrouwbaarheid vereist herhaalde proeven

Voer elke taak vaak genoeg uit om variabiliteit door steekproeftrekking, veranderende tools en de toestand van de omgeving waar te nemen. Rapporteer zowel de gemiddelde prestaties als hoe vaak ernstige fouten optreden. Bij workflows met meerdere afhankelijke stappen kan de nauwkeurigheid per stap hoog lijken, terwijl de betrouwbaarheid van begin tot eind laag blijft, omdat één fout al genoeg is om de hele taak te laten ontsporen.

Agentgedrag is probabilistisch. Dezelfde taak kan tot verschillende plannen, toolaanroepen en resultaten leiden. Voer elke belangrijke taak meerdere keren uit en rapporteer slagingspercentages of scoreverdelingen, niet alleen het beste voorbeeld.

Twee betrouwbaarheidsmaten geven antwoord op verschillende vragen:

• Pass@k: de kans dat ten minste één van de k pogingen slaagt. Dit is nuttig wanneer meerdere pogingen aanvaardbaar zijn.
• Pass^k: de kans dat alle k pogingen slagen. Dit weerspiegelt de consistentie wanneer elke uitvoering moet werken.

Een systeem kan een aantrekkelijke pass@k-score hebben en toch ongeschikt zijn voor automatische werking, omdat afzonderlijke uitvoeringen onbetrouwbaar zijn.

Stel een representatieve verzameling taken samen

Begin met echte fouten en veelvoorkomende productieverzoeken. Neem eenvoudige taken, lastige randgevallen, dubbelzinnige invoer, toolfouten, verouderde gegevens, ontbrekende informatie en adversariële inhoud op.

Segmenteer de resultaten naar taaktype en risico. Een algemeen gemiddelde kan een ernstige zwakte verhullen bij financiële handelingen, taken met een lange tijdshorizon of een specifieke toepassing. Houd een aparte testset achter de hand, zodat herhaaldelijk bijstellen van prompts de evaluatiesuite niet in een trainingsset verandert.

Evalueer de omgeving, niet alleen het model

De prestaties van een agent zijn afhankelijk van tooldefinities, machtigingen, geheugen, contextbeheer, de gebruikersinterface, netwerkgedrag en orkestratie. Een modelupgrade kan de ene fout verminderen, maar tegelijk een andere aan het licht brengen.

Leg de versie vast van de volledige stack die voor elke uitvoering wordt gebruikt. Noteer het model, de prompts, tools, momentopname van de gegevens, omgeving, budgetten en versies van beoordelaars. Anders is een scoreverandering niet terug te voeren op een betekenisvolle oorzaak.

Veelvoorkomende evaluatiefouten

Dataverlies is een ander risico. Als benchmarktaken, verwachte antwoorden of beoordelingspatronen voorkomen in de trainingsgegevens of promptcontext van het model, kan de score eerder herkenning meten dan generalisatie. Houd afgeschermde testtaken achter de hand, werk de testgevallen bij naarmate systemen veranderen en noteer voor elke uitvoering precies welk model, welke prompt- en toolversies en welke omgeving zijn gebruikt.

• Evaluatie op basis van demo’s: taken kiezen nadat je hebt gezien waar de agent goed in is.
• Alleen het eindantwoord beoordelen: onveilige of verspillende trajecten negeren.
• Conclusies op basis van één uitvoering: een toevallig succes beschouwen als een stabiele vaardigheid.
• Lekkende tests: het antwoord of het referentietraject in de context van de agent plaatsen.
• Niet-gevalideerde modelbeoordelaars: ervan uitgaan dat een geautomatiseerde beoordelaar gelijk heeft zonder de overeenstemming met experts te controleren.
• Statische omgevingen: één interface, accountstatus of gegevensindeling testen.
• Geen negatieve tests: meten of een taak wordt voltooid zonder te controleren of de agent op gepaste wijze weigert of de taak opschaalt.
• Economie negeren: het succes optimaliseren terwijl de kosten en latentie onbruikbaar hoog oplopen.

Van offline-evaluaties naar monitoring in productie

Offline-evaluaties zijn gecontroleerd en herhaalbaar. Ze zijn ideaal om prompts, modellen, tools en beleidsregels vóór de release met elkaar te vergelijken. Monitoring in productie brengt de grote variatie aan daadwerkelijk gebruikersgedrag en veranderingen in de omgeving aan het licht.

Een volwassen programma verbindt beide. Incidenten en productietrajecten met een lage betrouwbaarheid worden nieuwe offline taken. Kandidaatwijzigingen moeten slagen voor de regressietestsuite. Na de implementatie houden teams het succespercentage van taken, interventiepercentages, beleidsincidenten, toolfouten, kosten, latentie en gebruikersfeedback in de gaten.

Een praktische scorekaart voor agents

Een scorekaart moet harde voorwaarden onderscheiden van optimalisatiemaatstaven. Naleving van beleid, autorisatie en vereist bewijsmateriaal kunnen voorwaarden zijn waaraan wel of niet wordt voldaan. Vervolgens kunnen nauwkeurigheid, latentie, kosten en de inspanning van beoordelaars worden vergeleken tussen acceptabele uitvoeringen. Zo voorkomen teams dat ze een kleine efficiëntiewinst inruilen voor een terugval in veiligheid die door een gemiddelde score verborgen zou blijven.

Een bruikbare scorekaart kan het volgende bevatten:

• succespercentage van taken en kwaliteitsscore;
• consistentie bij herhaalde tests;
• percentage ernstige beleidsschendingen;
• nauwkeurigheid van toolselectie en argumenten;
• herstelpercentage na fouten met tools of in de omgeving;
• percentage menselijke escalaties en ingrepen;
• mediane latentie en latentie in de uitschieters;
• kosten voor model, tools en menselijke inzet per geslaagde taak;
• efficiëntie van het traject vergeleken met een redelijke referentie.

Rapporteer de kosten per geslaagde taak, niet alleen de kosten per uitvoering. Een goedkope agent die herhaaldelijk faalt, kan duurder uitvallen dan een krachtiger model dat de taak in één keer goed uitvoert.

Wat je moet onthouden over de evaluatie van een AI-agent

Agent-evaluatie is het systematisch testen van een volledig, doelgericht systeem onder realistische omstandigheden. Je meet of het werk correct wordt uitgevoerd, of de gevolgde aanpak aanvaardbaar is, of het gedrag herhaalbaar is en of de kosten in verhouding staan tot het resultaat.

Begin met een kleine set belangrijke taken, meerdere tests, beoordelaars op verschillende niveaus en volledige trajecten. Maak vervolgens van elke betekenisvolle fout in productie een regressietest. De capaciteiten van agents veranderen snel; met een duurzaam evaluatiesysteem kunnen teams echte vooruitgang onderscheiden van een overtuigende demo.