Hvordan evaluerer man en AI-agent? Opgaver, forløb, pålidelighed og omkostninger

Evaluering af en AI-agent handler om at teste, om den løser repræsentative opgaver pålideligt, følger acceptable fremgangsmåder, holder sig inden for sine grænser og skaber tilstrækkelig værdi i forhold til omkostningerne. Et endeligt svar er ikke nok, for en agent kan nå frem til et plausibelt resultat gennem usikre handlinger, udokumenterede påstande, for mange gentagelser eller rent held.

Det er vanskeligt at evaluere agenter, fordi systemet handler over tid. Modellen vælger værktøjer, observerer miljøer, der ændrer sig, og kan følge en anden vej i hver kørsel. Effektive evalueringer måler derfor både resultater og forløb på tværs af gentagne forsøg.

Terminologien inden for evaluering af agenter

Anthropics vejledning til at afmystificere evaluering af agenter giver et nyttigt sæt begreber:

• Opgave: én test med et mål, et miljø, input og succeskriterier.
• Forsøg: ét forsøg fra agentens side på at løse en opgave.
• Transskription eller forløb: rækkefølgen af beskeder, beslutninger, værktøjskald, observationer og handlinger under forsøget.
• Bedømmer: en regel, et program, en model eller en person, der vurderer en del af præstationen.
• Evalueringsramme: systemet, der klargør miljøer, kører forsøg, indsamler spor, bruger bedømmere og rapporterer resultater.

Når disse begreber holdes adskilt, undgår man en almindelig fejl: at betragte én vellykket demonstration som bevis på, at agenten vil præstere pålideligt.

Begynd med en tydelig opgavebeskrivelse

En nyttig evalueringsopgave beskriver starttilstanden, de tilgængelige værktøjer, begrænsningerne, det forventede resultat og vigtig adfærd, der er forbudt. Testen bør ligne virkeligt arbejde uden at afsløre én bestemt, forudbestemt fremgangsmåde.

For en supportagent er »løs supportsagen« for upræcist. En bedre opgave angiver kundens journal, den relevante politik, de tilladte løsninger, den nødvendige kommunikation og hvilke ændringer der skal fremgå af det primære registreringssystem. Derefter kan opgaven bedømmes objektivt.

Fire lag i evalueringen af agenter

Disse lag bør holdes adskilt i rapporteringen. Hvis de samles i ét gennemsnit, kan uacceptabel adfærd blive skjult – for eksempel hvis en høj succesrate for opgaver dækker over hyppige forsøg på at bruge værktøjer uden tilladelse. Teams kan først fastlægge ufravigelige sikkerhedskrav og derefter sammenligne kvaliteten af resultaterne og effektiviteten blandt de kørsler, der opfylder kravene.

1. Kvaliteten af resultatet

Nåede agenten målet? Bedømmere af resultater kan kontrollere præcise tilstandsændringer, obligatoriske felter, testresultater, faktuel nøjagtighed, dokumentation for kildehenvisninger eller kvalitet vurderet ud fra en bedømmelsesrubrik.

Brug så vidt muligt miljøets endelige tilstand frem for agentens egne påstande. En kodeagent er ikke lykkedes, blot fordi den siger, at fejlen er rettet; det skal bekræftes af de relevante test og systemets adfærd.

2. Kvaliteten af forløbet

Valgte agenten en hensigtsmæssig fremgangsmåde? Evaluering af forløbet kan afsløre unødvendig adgang til data, forbudte værktøjer, gentagne fejl, manglende verifikation, opdigtede observationer eller overtrædelser af godkendelseskrav.

Ikke enhver afvigelse fra en referencevej er en fejl. Agenter kan finde gyldige løsninger, som evaluatorerne ikke havde forudset. Bedømmere bør håndhæve reelle krav, men samtidig tillade alternative og effektive fremgangsmåder.

3. Sikkerhed og overholdelse af politikker

Holdt agenten sig inden for sine beføjelser? Testene bør omfatte prompt injection, modstridende instruktioner, følsomme data, tvetydige brugerhensigter samt anmodninger, der kræver afslag eller eskalering.

Sikkerhedsevalueringer kræver realistiske konsekvenser i et sandkassemiljø. En sætning, der overholder politikken, er ikke nok, hvis agenten allerede har sendt beskeden, ændret registreringen eller videregivet dataene.

4. Driftseffektivitet

Hvor meget tid og hvor mange penge krævede det at lykkes? Følg forbruget af modeltokens, værktøjskald, samlet svartid, gentagne forsøg, menneskelige indgreb og omkostninger til eksterne tjenester. En agent, der først lykkes efter 100 unødvendige handlinger, kan være mindre nyttig end en enklere arbejdsgang.

Brug flere typer bedømmere

Deterministiske bedømmere undersøger præcise egenskaber: om en test blev bestået, om en fil blev ændret korrekt, om et databasefelt har den krævede værdi, eller om et forbudt slutpunkt blev kaldt. De er hurtige og ensartede, men dækker kun det, udviklerne koder ind.

Modelbaserede bedømmere vurderer egenskaber som tydelighed, fuldstændighed, relevans og overholdelse af nuancerede kriterier. De kan skaleres bedre end menneskelig vurdering, men skal selv valideres, fordi de kan være forudindtagede eller inkonsekvente.

Menneskelige bedømmere er vigtige, når der kræves ekspertvurdering, i tvetydige tilfælde og ved validering af automatiserede bedømmere. De er langsommere og dyrere, så teams bruger dem ofte på stikprøver, uenigheder og områder med stor effekt.

De stærkeste evalueringssuiter kombinerer disse metoder. OpenAI’s evalueringsplatform behandler på samme måde evaluering som en struktureret proces til at definere tests, bedømmere og gentagne forsøg frem for uformel gennemgang.

Pålidelighed kræver gentagne forsøg

Kør hver opgave tilstrækkeligt mange gange til at observere variation som følge af sampling, skiftende værktøjer og miljøtilstand. Rapportér både den gennemsnitlige ydeevne og hyppigheden af alvorlige fejl. I arbejdsgange med flere indbyrdes afhængige trin kan nøjagtigheden for hvert trin se høj ud, mens pålideligheden fra start til slut stadig er lav, fordi én enkelt fejl er nok til at afspore hele opgaven.

Agenters adfærd er probabilistisk. Den samme opgave kan føre til forskellige planer, værktøjskald og resultater. Kør hver vigtig opgave flere gange, og rapportér beståelsesprocenter eller scorefordelinger, ikke kun det bedste eksempel.

To mål for pålidelighed besvarer forskellige spørgsmål:

• Pass@k: sandsynligheden for, at mindst ét af k forsøg lykkes. Det er nyttigt, når flere forsøg er acceptable.
• Pass^k: sandsynligheden for, at alle k forsøg lykkes. Det afspejler ensartethed, når hver kørsel skal fungere.

Et system kan have en attraktiv pass@k-værdi og stadig være uegnet til automatisk drift, fordi de enkelte kørsler er upålidelige.

Sammensæt et repræsentativt opgavesæt

Tag udgangspunkt i reelle fejl og almindelige produktionsforespørgsler. Medtag enkle opgaver, vanskelige randtilfælde, tvetydige input, værktøjsfejl, forældede data, manglende oplysninger og indhold, der forsøger at manipulere systemet.

Opdel resultaterne efter opgavetype og risiko. Et samlet gennemsnit kan skjule en alvorlig svaghed ved finansielle handlinger, opgaver med lang tidshorisont eller en bestemt applikation. Bevar et separat testsæt, så gentagen justering af prompts ikke gør evalueringssuiten til et træningssæt.

Evaluér miljøet, ikke kun modellen

En agents ydeevne afhænger af værktøjsdefinitioner, tilladelser, hukommelse, kontexthåndtering, brugergrænseflade, netværksadfærd og orkestrering. En modelopgradering kan reducere én fejl og samtidig gøre en anden synlig.

Versionsstyr hele den stak, der bruges ved hver kørsel. Registrér modellen, prompts, værktøjer, datasnapshot, miljø, budgetter og versioner af bedømmerne. Ellers kan en ændring i scoren ikke føres tilbage til en meningsfuld årsag.

Almindelige evalueringsfejl

Dat læk er en anden risiko. Hvis benchmarkopgaver, forventede svar eller mønstre i bedømmelsen findes i modellens træningsdata eller promptkontekst, kan scoren afspejle genkendelse snarere end generalisering. Hold opgaver til test uden for træningsdataene private, opdater testtilfældene, efterhånden som systemerne ændrer sig, og registrer den præcise model, prompt, værktøjsversioner og det miljø, der blev brugt ved hver kørsel.

• Demodrevet evaluering: at vælge opgaver, efter man har set, hvad agenten er god til.
• Bedømmelse udelukkende af det endelige svar: at se bort fra usikre eller ressourcespildende forløb.
• Konklusioner baseret på én enkelt kørsel: at betragte et heldigt resultat som en stabil evne.
• Test med datalæk: at placere svaret eller referenceforløbet i agentens kontekst.
• Uvaliderede modelbaserede bedømmere: at gå ud fra, at en automatisk bedømmer har ret, uden at kontrollere, om den er enig med eksperter.
• Statiske miljøer: at teste én enkelt grænseflade, kontotilstand eller datasammensætning.
• Ingen negative test: at måle, om opgaven bliver løst, uden at kontrollere, om agenten afviser eller eskalerer på passende vis.
• Ignorerede økonomiske forhold: at optimere succesraten, mens omkostninger og svartider bliver uacceptable.

Fra offlineevaluering til overvågning i produktion

Offlineevalueringer er kontrollerede og kan gentages. De egner sig godt til at sammenligne prompts, modeller, værktøjer og politikker før lancering. Overvågning i produktion afdækker den lange hale af faktisk brugeradfærd og ændringer i miljøet.

Et modent program forbinder de to. Hændelser og spor fra produktionen med lav konfidens bliver til nye offlineopgaver. Kandidatændringer skal bestå regressionstestsuiten. Efter udrulning overvåger teams opgavesucces, hyppigheden af indgreb, politikrelaterede hændelser, værktøjsfejl, omkostninger, svartider og brugerfeedback.

Et praktisk scorekort for agenter

Et scorekort bør skelne mellem ufravigelige krav og optimeringsmålinger. Overholdelse af politikker, autorisation og påkrævet dokumentation kan være krav, der enten er opfyldt eller ikke opfyldt; derefter kan nøjagtighed, svartid, omkostninger og den indsats, der kræves af bedømmeren, sammenlignes på tværs af acceptable kørsler. Det forhindrer teams i at bytte en lille effektivitetsgevinst for en forringelse af sikkerheden, som en gennemsnitsscore ville skjule.

Et nyttigt scorekort kan omfatte:

• succesrate for opgaver og kvalitetsscore;
• konsistens på tværs af gentagne forsøg;
• hyppighed af kritiske politikovertrædelser;
• nøjagtighed i valg af værktøjer og argumenter;
• genopretningsrate efter fejl i værktøjer eller miljø;
• hyppighed af eskalering til mennesker og manuelle tilsidesættelser;
• median- og haleforsinkelse;
• omkostninger til model, værktøjer og mennesker pr. vellykket opgave;
• forløbets effektivitet sammenlignet med en rimelig baseline.

Rapportér omkostningen pr. vellykket opgave, ikke kun omkostningen pr. kørsel. En billig agent, der gentagne gange fejler, kan være dyrere end en stærkere model, der lykkes i første forsøg.

Husk dette om evaluering af en AI-agent

Evaluering af agenter er disciplinen, der består i at teste et komplet, målorienteret system under realistiske forhold. Den måler, om arbejdet er korrekt, om fremgangsmåden er acceptabel, om adfærden kan gentages, og om økonomien hænger sammen.

Begynd med et lille sæt vigtige opgaver, flere forsøg, bedømmere i flere lag og komplette forløb. Gør derefter enhver betydningsfuld fejl i produktionen til en regressionstest. Agenters evner ændrer sig hurtigt; et holdbart evalueringssystem gør det muligt for teams at skelne reel fremgang fra en overbevisende demo.