Hvordan evaluerer du en AI-agent? Oppgaver, handlingsforløp, pålitelighet og kostnader

Å evaluere en AI-agent innebærer å teste om den løser representative oppgaver på en pålitelig måte, følger akseptable fremgangsmåter, holder seg innenfor grensene sine og gir tilstrekkelig verdi i forhold til kostnaden. Et endelig svar alene er ikke nok, fordi en agent kan komme frem til et sannsynlig resultat gjennom utrygge handlinger, udokumenterte påstander, for mange nye forsøk eller ren flaks.

Det er vanskelig å evaluere agenter fordi systemet handler over tid. Modellen velger verktøy, observerer miljøer i endring og kan følge en annen fremgangsmåte i hver kjøring. Gode evalueringer måler derfor resultater og handlingsforløp på tvers av gjentatte forsøk.

Begreper innen evaluering av agenter

Anthropics veiledning for å gjøre evaluering av agenter mer forståelig gir et nyttig sett med begreper:

• Oppgave: ett testtilfelle med et mål, et miljø, inndata og kriterier for å lykkes.
• Forsøk: ett forsøk fra agenten på å løse en oppgave.
• Transkripsjon eller handlingsforløp: sekvensen av meldinger, beslutninger, verktøykall, observasjoner og handlinger under forsøket.
• Vurderer: en regel, et program, en modell eller en person som gir en poengsum for deler av prestasjonen.
• Evalueringsrammeverk: systemet som klargjør miljøer, kjører forsøk, samler inn sporingsdata, bruker vurderere og rapporterer resultater.

Når disse begrepene holdes atskilt, unngår man en vanlig feil: å se én vellykket demonstrasjon som bevis på at agenten vil prestere pålitelig.

Begynn med en tydelig oppgavebeskrivelse

En nyttig evalueringsoppgave beskriver starttilstanden, tilgjengelige verktøy, begrensninger, forventet resultat og viktig atferd som ikke er tillatt. Testen bør ligne på reelt arbeid uten å avsløre én fast, forhåndsprogrammert fremgangsmåte.

For en kundestøtteagent er «løs saken» for vagt. En bedre oppgavebeskrivelse angir kundens opplysninger, gjeldende retningslinjer, tillatte løsninger, nødvendig kommunikasjon og hvilke endringer som må være synlige i det autoritative systemet. Da kan resultatet vurderes objektivt.

Fire lag i evalueringen av agenter

Disse lagene bør holdes atskilt i rapporteringen. Hvis de slås sammen til ett gjennomsnitt, kan uakseptabel atferd bli skjult – for eksempel en høy skår for oppgavesuksess som tilslører hyppige forsøk på å bruke verktøy uten tillatelse. Team kan først fastsette absolutte sikkerhetskrav og deretter sammenligne kvaliteten på resultatene og effektiviteten for kjøringer som oppfyller kravene.

1. Kvaliteten på resultatet

Nådde agenten målet? Vurdering av resultatet kan kontrollere nøyaktige tilstandsendringer, obligatoriske felt, testresultater, faktanøyaktighet, dokumentasjon av kildehenvisninger eller kvalitet basert på vurderingskriterier.

Bruk om mulig miljøets endelige tilstand fremfor agentens egne påstander. En kodeagent har ikke lykkes bare fordi den sier at feilen er rettet; relevante tester og systemets atferd må bekrefte det.

2. Kvaliteten på handlingsforløpet

Valgte agenten en forsvarlig fremgangsmåte? Evaluering av handlingsforløpet kan avdekke unødvendig tilgang til data, forbudte verktøy, gjentatte feil, manglende verifisering, oppdiktede observasjoner eller brudd på krav om godkjenning.

Ikke alle avvik fra en referansefremgangsmåte er feil. Agenter kan finne gyldige løsninger som evaluatorene ikke hadde forutsett. Vurdererne bør håndheve reelle krav, samtidig som de tillater alternative og effektive fremgangsmåter.

3. Sikkerhet og etterlevelse av retningslinjer

Holdt agenten seg innenfor fullmaktene sine? Testene bør omfatte instruksjonsinjeksjon, motstridende instruksjoner, sensitive data, tvetydige brukerintensjoner og forespørsler som krever avslag eller eskalering.

Sikkerhetsevalueringer må innebære realistiske konsekvenser i et sandkassemiljø. En setning som følger retningslinjene, er ikke nok hvis agenten allerede har sendt meldingen, endret oppføringen eller eksponert dataene.

4. Operasjonell effektivitet

Hvor mye tid og penger krevde det å lykkes? Følg med på modellens tokenforbruk, verktøykall, ventetid målt i klokketid, nye forsøk, menneskelige inngrep og kostnader for eksterne tjenester. En agent som lykkes etter 100 unødvendige handlinger, kan være mindre nyttig enn en enklere arbeidsflyt.

Bruk flere typer vurderere

Deterministiske vurderere undersøker nøyaktige egenskaper: om en test ble bestått, en fil ble endret riktig, et databasefelt har den påkrevde verdien, eller et forbudt endepunkt ble kalt. De er raske og konsekvente, men dekker bare det utviklerne har kodet inn.

Modellbaserte vurderere evaluerer egenskaper som tydelighet, fullstendighet, relevans og etterlevelse av nyanserte kriterier. De skalerer bedre enn menneskelig vurdering, men må valideres selv, fordi de kan være skjeve eller inkonsekvente.

Menneskelige vurderere er viktige når det kreves ekspertvurdering, i tvetydige tilfeller og for å validere automatiserte vurderere. De arbeider langsommere og er dyrere, så team bruker dem ofte på utvalg, uenigheter og områder med stor innvirkning.

De beste evalueringspakkene kombinerer disse tilnærmingene. OpenAIs Evals-plattform behandler på samme måte evaluering som en strukturert prosess for å definere tester, vurderere og gjentatte eksperimenter, snarere enn som uformell inspeksjon.

Pålitelighet krever gjentatte forsøk

Kjør hver oppgave nok ganger til å observere variasjon som skyldes sampling, endringer i verktøy og miljøtilstand. Rapporter både gjennomsnittlig ytelse og hvor ofte alvorlige feil oppstår. I arbeidsflyter med flere avhengige trinn kan nøyaktigheten for hvert enkelt trinn se høy ut, mens påliteligheten fra start til slutt fortsatt er lav, fordi én enkelt feil er nok til å føre til at hele oppgaven mislykkes.

Agentatferd er sannsynlighetsbasert. Den samme oppgaven kan føre til ulike planer, verktøykall og resultater. Kjør hver viktige oppgave flere ganger, og rapporter beståttandeler eller resultatfordelinger, ikke bare det beste eksempelet.

To mål på pålitelighet besvarer ulike spørsmål:

• Pass@k: sannsynligheten for at minst ett av k forsøk lykkes. Dette er nyttig når flere forsøk er akseptable.
• Pass^k: sannsynligheten for at alle k forsøk lykkes. Dette gjenspeiler hvor konsekvent systemet er når hver kjøring må fungere.

Et system kan ha en attraktiv Pass@k-verdi, men likevel være uegnet for automatisk drift fordi enkeltkjøringer er upålitelige.

Bygg et representativt oppgavesett

Ta utgangspunkt i reelle feil og vanlige forespørsler i produksjon. Ta med enkle oppgaver, vanskelige grensetilfeller, tvetydige inndata, verktøyfeil, utdaterte data, manglende informasjon og motstridende innhold.

Del resultatene inn etter oppgavetype og risiko. Et samlet gjennomsnitt kan skjule en alvorlig svakhet ved økonomiske handlinger, oppgaver med lang tidshorisont eller en bestemt applikasjon. Behold et separat testsett som holdes utenfor, slik at gjentatt justering av prompter ikke gjør evalueringspakken til et treningssett.

Evaluer miljøet, ikke bare modellen

En agents ytelse avhenger av verktøydefinisjoner, tillatelser, minne, kontekststyring, brukergrensesnitt, nettverksatferd og orkestrering. En modelloppgradering kan redusere én type feil, samtidig som en annen blir synlig.

Versjonsstyr hele stakken som brukes ved hver kjøring. Registrer modellen, promptene, verktøyene, øyeblikksbildet av dataene, miljøet, budsjettene og versjonene av vurderingsverktøyene. Ellers kan ikke en endring i poengsummen knyttes til en meningsfull årsak.

Vanlige evalueringsfeil

Datalekkasje er en annen risiko. Hvis referanseoppgaver, forventede svar eller mønstre i vurderingen finnes i modellens treningsdata eller i konteksten til instruksjonen, kan poengsummen måle gjenkjenning i stedet for generalisering. Oppbevar oppgaver til private holdout-tester, oppdater testtilfellene etter hvert som systemene endres, og registrer nøyaktig hvilken modell, instruksjon, verktøyversjoner og hvilket miljø som ble brukt i hver kjøring.

• Demodrevet evaluering: å velge oppgaver etter å ha sett hva agenten gjør bra.
• Vurdering kun av sluttsvaret: å overse utrygge eller sløsende handlingsforløp.
• Konklusjoner basert på én kjøring: å behandle en heldig suksess som en stabil evne.
• Lekkende tester: å legge svaret eller referanseforløpet inn i agentens kontekst.
• Uvaliderte modellbaserte vurderinger: å anta at en automatisert bedømmer har rett uten å kontrollere om vurderingen samsvarer med ekspertenes.
• Statiske miljøer: å teste ett grensesnitt, én kontotilstand eller én datasammensetning.
• Ingen negative tester: å måle om oppgaven fullføres uten å kontrollere om agenten avslår eller eskalerer på riktig måte.
• Å ignorere økonomien: å optimalisere for suksess mens kostnadene og ventetiden blir uakseptable.

Fra offline-evalueringer til produksjonsovervåking

Offline-evalueringer er kontrollerte og kan gjentas. De egner seg godt til å sammenligne instruksjoner, modeller, verktøy og retningslinjer før lansering. Produksjonsovervåking avdekker det store mangfoldet i faktisk brukeratferd og endringer i miljøet.

Et modent program knytter disse to sammen. Hendelser og spor fra produksjonen med lav konfidens blir til nye offline-oppgaver. Kandidatendringer må bestå regresjonstestsuiten. Etter utrulling følger teamene med på hvor ofte oppgaver lykkes, hvor ofte det gripes inn, hendelser knyttet til retningslinjer, verktøyfeil, kostnader, ventetid og tilbakemeldinger fra brukerne.

Et praktisk vurderingsskjema for agenter

Et vurderingsskjema bør skille mellom absolutte krav og måltall for optimalisering. Etterlevelse av retningslinjer, autorisasjon og påkrevd dokumentasjon kan være absolutte krav som enten er oppfylt eller ikke; deretter kan nøyaktighet, ventetid, kostnader og arbeidsinnsats for den som vurderer, sammenlignes mellom akseptable kjøringer. Dette hindrer team i å bytte bort sikkerhet mot en liten effektivitetsgevinst som en gjennomsnittlig poengsum ville skjult.

Et nyttig vurderingsskjema kan omfatte:

• andel oppgaver som lykkes, og kvalitetsvurdering;
• konsistens på tvers av gjentatte forsøk;
• andel kritiske brudd på retningslinjer;
• nøyaktighet i valg av verktøy og argumenter;
• andel vellykkede gjenopprettinger etter verktøy- eller miljøfeil;
• andel eskaleringer til mennesker og manuelle overstyringer;
• median ventetid og ventetid i ytterkantene;
• kostnad for modell, verktøy og menneskelig arbeid per vellykket oppgave;
• effektiviteten i handlingsforløpet sammenlignet med et rimelig utgangspunkt.

Rapporter kostnaden per vellykket oppgave, ikke bare kostnaden per kjøring. En billig agent som mislykkes gjentatte ganger, kan være dyrere enn en sterkere modell som lykkes på første forsøk.

Dette bør du huske om hvordan du evaluerer en KI-agent

Evaluering av agenter handler om å teste et komplett, målstyrt system under realistiske forhold. Man måler om arbeidet er riktig, om fremgangsmåten er akseptabel, om atferden kan gjentas, og om økonomien går opp.

Begynn med et lite utvalg oppgaver med store konsekvenser, flere forsøk, vurdering i flere lag og komplette handlingsforløp. Gjør deretter hver betydningsfulle produksjonsfeil om til en regresjonstest. Agenters evner endres raskt; et robust evalueringssystem hjelper team med å skille reell fremgang fra en overbevisende demonstrasjon.