Sådan evaluerer du AI-agenter: testsæt, bedømmere og regressionstjek

Bag ethvert godt AI-produkt står en solid evalueringsproces for AI-agenter, kendt som evals, der fanger fejl tidligt og sikrer, at agenten fungerer korrekt. Evals er afgørende for AI-agenter, der udfører højrisikohandlinger som refusioner på andres vegne.

Det kræver en vis teknisk viden og dataanalytiske færdigheder at opbygge den proces. Men det er langtfra så skræmmende eller utilgængeligt, som det måske lyder. For at hjælpe dig i gang har vi samlet seks praktiske trin til evaluering af AI-agenter samt almindelige misforståelser, der ødelægger processen.

Hvad vil det sige at evaluere en AI-agent?

At evaluere en AI-agent betyder at vurdere, om den udfører opgaver korrekt, og om dens beslutninger lever op til organisationens krav. I praksis er evalueringer af AI-agenter, eller evals, specifikke målepunkter, der hjælper organisationer med at afgøre, om agenten fungerer pålideligt nok til den rolle, den er tiltænkt.

Forestil dig en AI-indkøbsagent på en fabrik, der tjekker lagerbeholdningen af reservedele og udarbejder genbestillingsanmodninger. Hvis en godkendt del ikke er tilgængelig, eller leverandøroplysningerne er forældede, vil agenten så markere problemet eller anbefale en ikke-godkendt erstatning?

Og hvis du ændrer dens systemprompt for at løse det problem, hvordan ved du så, at du ikke har skabt et nyt?

Uden evaluering er produktchefer i bund og grund overladt til at gætte. Evals giver derfor et feedbacksignal, der gør det muligt at måle ydeevne, opdage tilbagevendende problemer og teste ændringer med større sikkerhed.

Når det er sagt, kan en agentevaluering undersøge flere aspekter af en kørsel:

• Kvaliteten af det endelige resultat
• De oplysninger, agenten brugte
• De værktøjer, den kaldte
• Om den fulgte de regler, der styrer dens adfærd

Almindelige målepunkter til evaluering af AI-agenter

Evals arbejder med kvalitative og kvantitative data. Kvalitativ evaluering hjælper dig med at forstå, hvad der sker og hvorfor, bl.a. ved manuelt at gennemgå agentens beslutninger. Kvantitativ evaluering omsætter disse observationer til målbare signaler, f.eks. ved at tælle, hvor ofte bestemte fejltyper forekommer, eller ved at beregne andelen af vellykkede opgaver.

Her er listen over grundlæggende målepunkter til evaluering af AI-agenter:

• Opgavesucces måler, om agenten opnåede det tilsigtede resultat; det måles som regel som den procentdel af kørsler, der giver gyldige resultater.
• Handlingskorrekthed måler, om agenten brugte værktøjerne hensigtsmæssigt, valgte gyldige argumenter og overholdt tilladelser.
• Svarkvalitet vurderer, om det endelige output er præcist, fyldestgørende og nyttigt. Det kan omfatte faktuel korrekthed, overholdelse af instruktioner, og om agenten underbygger sine beslutninger med de tilgængelige oplysninger.
• Pålidelighed måler konsistensen på tværs af gentagne forsøg, varierende input og grænsetilfælde.
• Omkostninger og latenstid måler de ressourcer, der kræves for at opnå et vellykket resultat, herunder eksekveringstid, tokenforbrug og værktøjskald.

Afhængigt af hvad du måler, kan evals vurdere en agents samlede ydeevne fra start til slut, dens eksekveringsforløb eller individuelle komponenter som værktøjskald og hentningstrin.

Trin 1: Afgør, hvordan en vellykket agentkørsel ser ud

Beskriv først eksplicit, hvad agenten skal opnå – produktkravene. Det lyder indlysende, men kan være overraskende svært. Der er endda et navn for det: specifikationskløften.

Sådan griber du det an ifølge Andrey Khomutov, vores senior data scientist:

“Start med to spørgsmål: “Hvad ville tælle som at have udført opgaven?” og “Hvad ville gøre en tilsyneladende vellykket kørsel uacceptabel?”

For agenter betyder det teknisk set, at man tjekker både resultatet og den måde, agenterne nåede frem til det på.”

En agent kan nå frem til det korrekte svar ved at tilgå en lækket facitliste eller udføre uautoriserede handlinger, mens den løser sin opgave. Khomutov påpeger, at svarlækage og usikre handlinger under evalueringer er konkrete grunde til ikke kun at bedømme det endelige svar.

“Jeg forventer, at inspektion af forløbet bliver en fast del af eval-suiter til agenter i stedet for noget, vi kun gør, når et resultat ser mistænkeligt ud,” tilføjer han.

Inddrag derefter en domæneekspert til at validere dine succeskriterier. Personer med praktisk kendskab til domænet kan vurdere, om de betingelser, vi opstiller for en AI-agent, afspejler et vellykket resultat.

Trin 2. Opbyg et testsæt ud fra reelle opgaver og fejl

Undersøg agentens faktiske adfærd for at forstå, hvordan god og dårlig ydeevne ser ud. Modstå fristelsen til at starte med at generere snesevis af tests, der udelukkende bygger på, hvad du tror, der kan gå galt.

Hamel Husain, ML-ingeniør hos Parlance Lab, og Shreya Shankar, forsker i ML-systemer og evals af anvendt AI, anbefaler at begynde med fejlanalyse, en teknik lånt fra maskinlæring og datavidenskab. Processen starter med en kvalitativ analyse af agentens eksekveringsspor – registreringer, der viser brugerens input, værktøjskald, hentede oplysninger og agentens output.

1. Gennemgå individuelle spor, og annotér fejl (åben kodning). Lad en domæneekspert inspicere agentkørsler og skrive korte observationer om, hvad der gik galt. Fokusér på den første betydningsfulde fejl.
2. Gruppér observationer i fejltyper (aksial kodning). Når du har nok noter, kan du bruge en LLM til at foreslå kategorier for lignende fejl. Det kan f.eks. være anbefalinger af inkompatible dele, unøjagtig hentning af lagerdata og mislykkede overdragelser til mennesker.
3. Tæl forekomsterne. Tildel hver observation en kategori, og brug derefter et regneark eller en pivottabel til at beregne, hvor ofte hver fejltype forekommer.
4. Prioritér, hvad der skal håndteres, ud fra både hyppighed og alvorlighed.
5. Gør vigtige fejl til testcases. Gem det relevante input, startbetingelserne, det forventede resultat og bedømmelseskriterierne, så agenten kan testes mod det samme scenarie igen.

Hvor mange spor bør du undersøge? Omkring 100, men der findes ikke noget magisk tal. Stop tidligt, når du når teoretisk mætning: det punkt, hvor gennemgang af yderligere spor ikke længere afslører nye, betydningsfulde fejlmønstre.

Har du ikke lanceret applikationen endnu? Syntetiske eksempler kan hjælpe med at opbygge et første testsæt, men reelle brugerdata bør indgå i det, så snart de bliver tilgængelige.

Brugen af benchmarks i evaluering af AI-agenter

Ud over at oprette dine egne testcases kan du bruge eksisterende samlinger af standardiserede evalueringsopgaver, kendt som benchmarks, til at vurdere agenters evner.

Men benchmarks er ikke ufejlbarlige. Revisioner af SWE-bench, Epoch AI's gennemgange af benchmarks og korrekte svar, der i første omgang blev afvist i TheoPhysEval, viser, hvordan fejlbehæftede opgaver eller forventede svar kan forvride evalueringsresultater.

Som Khomutov anbefaler, bør du vælge opdaterede benchmarks, der er relevante for dit domæne, og undersøge overraskende beståede eller fejlede opgaver, før du betragter scorerne som pålidelig dokumentation for agentens ydeevne.

Trin 3. Kør agenten i et reproducerbart testmiljø

Et reproducerbart testmiljø er en kontrolleret opsætning, hvor du kan køre en AI-agent mod de samme testcases under de samme startbetingelser og sammenligne resultaterne. Det kan omfatte en mappe med testcases, et Python-script, der kører agenten, eller et sæt kontroller, der evaluerer resultaterne.

Du kan starte med at gemme repræsentative input som JSON-filer og bruge et Python-script til at udføre din agents arbejdsproces og kontrollere dens output med assertions. For lageragenten på vores fabrik kunne et reproducerbart testmiljø se sådan ud:

Udvid

Følg disse trin for at opsætte et reproducerbart testmiljø:

1. Gem repræsentative input. Opbevar faktiske hændelser eller testcases i den samme struktur, som din applikation modtager i produktion. I vores scenarie ville du gemme en vedligeholdelsesanmodning med maskinens ID, den nødvendige reservedel og vedligeholdelsesdatoen som en JSON-fil sammen med et øjebliksbillede af lagerbeholdningen og data om godkendte dele.
2. Udfør arbejdsprocessen. Kør hvert input gennem agenten, inklusive dens hentningstrin, værktøjskald og generering af svar.
3. Registrér resultatet og sporet. Gem det endelige output og relevante mellemliggende handlinger (f.eks. lageropslag), så du ikke kun kan se, om agenten fejlede, men også hvor.
4. Gentag testcases ud fra fejlens alvorlighed og hyppighed, og hvor svært problemet er at løse. LLM-applikationer er ikke-deterministiske (de kan give forskellige resultater ud fra identiske input), så én vellykket kørsel garanterer ikke, at den næste også lykkes. Rapportér andelen af vellykkede forsøg, og undersøg fejlene.

Til sidstnævnte anbefaler Khomutov at måle pass@1 (hvor ofte agenten lykkes ved et enkelt forsøg) og pass@k (sandsynligheden for at lykkes mindst én gang inden for et angivet antal forsøg). Hvis du rapporterer pass@k, skal du angive antallet af forsøg, da ét korrekt svar blandt flere ikke betyder, at agenten ved, hvilket den skal vælge.

Efterhånden som din applikation vokser, kan du bruge et testframework som pytest til at organisere og køre tests og overveje at gemme store testdatasæt og resultater i en database.

Trin 4. Vælg den rette bedømmer til hver kontrol

En bedømmer (ofte også kaldet en evaluator) er en mekanisme i form af et stykke kode, en LLM styret af en bedømmelsesrubrik eller en menneskelig reviewer, der kontrollerer en agents output eller handling i forhold til et defineret kriterium. En bedømmer returnerer en bestået/ikke bestået-vurdering og en forklaring, der angiver det relevante belæg.

Info: En bedømmelsesrubrik er et sæt kriterier og instruktioner, der definerer, hvad der tæller som et korrekt eller acceptabelt resultat.

Den rette type bedømmer afhænger af, hvad du forsøger at verificere. Her er en sammenligning af de tre tilgange:

Nogle gange kræver forskellige aspekter af den samme kørsel forskellige evalueringsmetoder, så du kan få brug for at kombinere bedømmere.

Hvordan kombinerer man bedømmere?

Du spørger: “Kan resultatet verificeres i forhold til en kendt regel eller en forventet værdi, eller kræver det menneskelignende dømmekraft?”

• Hvis du kan verificere resultatet præcist, skal du starte med en kodebaseret bedømmer. Kodebaserede bedømmere kan også verificere strukturerede output, gyldige feltværdier, værktøjsargumenter eller den endelige tilstand af en database.
• Hvis kontrollen kræver fortolkning af kontekst, skal du bruge LLM-as-a-judge.
• Brug menneskelige reviewere til domænespecifikke eller omstridte beslutninger.

Vigtigt! En LLM-bedømmer kan fejlfortolke belæg eller anvende en rubrik forkert. Den kræver derfor et ekstra evalueringstrin: kalibrering i forhold til menneskelige vurderinger.

Kalibrér LLM-bedømmeren i forhold til menneskelige vurderinger.

Kalibrering kræver grundlæggende, at en domæneekspert vurderer faktiske agentkørsler. Eksperten sammenligner derefter sine vurderinger med LLM'ens og forfiner bedømmelsesrubrikken ud fra uenighederne.

Her er en kalibreringsproces for bedømmere i fem trin:

1. Indsaml eksempler på agentens input, output og relevante spor.
2. Lad en domæneekspert uafhængigt vurdere, om hvert eksempel opfylder evalueringskriteriet.
3. Kør LLM-bedømmeren på disse eksempler.
4. Sammenlign menneskets og modellens vurderinger.
5. Undersøg uenigheder, og forfin bedømmerens rubrik, før du tester den på nye eksempler.

Khomutov understreger også vigtigheden af at teste LLM-bedømmerens konsistens separat:

“Giv den præcis den samme gemte kørsel og de samme filer flere gange uden at køre agenten igen. Det gør det muligt at skelne variation i agentens arbejde fra variation i bedømmelsen.”

Hvis det samme output får forskellige vurderinger, skal du ikke gå ud fra, at enhver ændring i scoren skyldes agenten. Undersøg i stedet en konfusionsmatrix, der viser, hvornår bedømmeren korrekt identificerede fejl, overså dem eller fejlagtigt markerede acceptable output.

Menneskelig gennemgang er fortsat afgørende for at fastlægge referencevurderinger, afgøre omstridte tilfælde og opdage nye fejltyper, som eksisterende bedømmere ikke er designet til at opfange.

Trin 5. Sammenlign versioner, og kør regressionstjek

Antag, at fejlanalysen viser, at din lageragent ofte anbefaler ikke-godkendte reservedele. Du ændrer dens systemprompt, så den kræver et eksplicit kompatibilitetstjek. Det oprindeligt fejlende tilfælde består nu. Men hvordan ved du, at ændringen ikke har påvirket andre opgaver?

Det er her, regressionstest kommer ind i billedet.

Regressionstest betyder, at man genkører tidligere beståede testcases efter at have ændret en agents prompt, model eller arbejdsproces for at sikre, at ændringen ikke har medført nye fejl.

1. Genskab den oprindelige fejl med et gemt input fra testsættet.
2. Foretag en målrettet ændring af prompten, modellen eller arbejdsprocessen.
3. Kør den fejlende test igen for at kontrollere, om problemet er løst.
4. Kør de øvrige tests for at bekræfte, at ændringen ikke har ødelagt adfærd, der tidligere fungerede.
5. Gennemgå resultaterne, og undersøg eventuelle nye fejl.

Sammenlign baseline-agenten og den opdaterede agent med de samme testcases og bedømmelseskriterier for at få præcise resultater.

Trin 6: Overvåg AI-agentens ydeevne i produktion

Evalueringen af agenten stopper ikke, når du har udrullet din applikation. Som Husain og Shankar forklarer, kan de samme evaluatorer, som du bruger under udviklingen, også køres på rigtige produktionsdata for at måle, hvordan din agent klarer sig over tid.

Dette kaldes onlineevaluering, og det er en del af en bredere proces for produktionsovervågning, som hjælper med at afdække tilbagevendende og hidtil ukendte fejl.

Processen er iterativ og består af fire komplementære aktiviteter:

• Kør kalibrerede LLM-dommere på produktionstraces. Udtag stikprøver af rigtige agentinteraktioner, og anvend de evaluatorer, du allerede har valideret mod menneskelige vurderinger.
• Følg fejlraterne over tid. Brug de fejlkategorier, der blev fastlagt under fejlanalysen, til at kvantificere tilbagevendende problemer.
• Bliv ved med at gennemgå traces manuelt. Automatiske bedømmere opdager kun de problemer, de er designet til at identificere. Gennemgå manuelt stikprøver af rigtige agentinteraktioner for at afdække nye fejl eller usædvanlige brugeranmodninger.
• Brug A/B-test til at måle forretningsresultater (kun når det er relevant). Sammenlign forskellige prompts, modeller eller arbejdsprocesser ved hjælp af målinger som opgavegennemførelse, brugertilfredshed og løsningstid. Processen hjælper med at afgøre, om en ændring forbedrer den faktiske produktoplevelse – ud over at bestå individuelle tests.

En vigtig bemærkning: Evalueringer behøver ikke at være finpudsede til perfektion. De skal blot være gode nok til at forbedre dit produkt.

Almindelige misforståelser om evaluering af AI-agenter

• Evalueringer er bare enhedstests. Det er de ikke. Enhedstests er små, automatiserede kontroller, der kun udgør én del af evalueringen. Evalueringer omfatter også kvalitativ fejlanalyse, menneskelige vurderinger, produktionsovervågning og eksperimenter, der måler applikationens kvalitet.
• En evalueringsplatform kan klare det hele for dig. Standardværktøjer kan automatisere visse kontroller, men de kan ikke afgøre, hvilke fejltilstande (typer af fejl eller uønsket agentadfærd) der har betydning for dit produkt.
• Du kan lade en LLM evaluere alt. Det er en stor fejlslutning. Menneskeledet fejlanalyse og kalibrering af bedømmere er fortsat afgørende, da LLM'er mangler den forretningskontekst, der skal til for at opdage alle problemer.
• A/B-test eller blot brug af agenten erstatter evalueringer. Forkert. A/B-tests kan vise, hvilken version der klarer sig bedst på udvalgte målinger, men de kan ikke i sig selv forklare de underliggende problemer.

Ofte stillede spørgsmål om evaluering af AI-agenter

1. Hvad er forskellen på evaluering af AI-agenter og evaluering af LLM'er?

LLM-evaluering måler, hvor godt en sprogmodel udfører en given opgave, f.eks. at besvare et spørgsmål, opsummere et dokument eller udtrække information. Evaluering af AI-agenter vurderer et system, der selvstændigt udfører flere trin for at fuldføre en opgave.

I modsætning til en typisk LLM-evaluering undersøger agentevaluering både det endelige resultat og rækken af handlinger, der blev udført for at nå det, herunder værktøjskald, beslutninger og overholdelse af foruddefinerede regler.

2. Vigtige målinger til evaluering af AI-agenter

Målinger til evaluering af AI-agenter falder i to overordnede kategorier:

• Tekniske ydeevnemålinger: Succesrate for opgaver, korrekthed af handlinger, svarkvalitet, pålidelighed (pass@1 og pass@k), latenstid, tokenforbrug og omkostning pr. gennemført opgave.
• Målinger for forretning og brugeroplevelse: Kundetilfredshed (CSAT), løsningsrate for sager, eskaleringsrate, konverteringsrate, tid til opgavegennemførelse og andre resultater, der er specifikke for agentens rolle.

For eksempel kan en kundesupportagent evalueres på, om sagerne bliver løst, og på kundetilfredshed, mens en AI-indkøbsagent kan måles på nøjagtigheden af genbestillingsanmodninger, godkendelsesrater og indkøbscyklustid.

De rette målinger bør afspejle både hvor pålideligt agenten præsterer, og om dens arbejde forbedrer forretningsresultaterne.

3. Hvilke værktøjer er bedst til at evaluere AI-agenter?

Almindelige muligheder omfatter:

• Testframeworks: Python-assertions og pytest er nyttige til at køre gentagelige testcases og kontrollere præcise betingelser, f.eks. om en agent valgte det rigtige værktøj eller returnerede et gyldigt del-ID.
• Frameworks til evaluering af AI-agenter: DeepEval og Googles agent-eval toolkit understøtter mere komplekse evalueringer, herunder eksekveringstraces, LLM-baserede bedømmere og automatiseret regressionstest.
• Evaluerings- og observabilitetsplatforme: LangSmith, Arize Phoenix og MLflow hjælper teams med at undersøge agenters adfærd, administrere evalueringsdatasæt, sammenligne agentversioner og overvåge ydeevnen i produktion.

4. Hvordan automatiserer man evalueringer af AI-agenter?

Du kan automatisere evalueringer af AI-agenter ved at bygge gentagelige tests, anvende automatiske bedømmere og integrere disse kontroller i arbejdsprocesserne for udvikling og produktion:

1. Opret et evalueringsdatasæt: Indsaml repræsentative brugeropgaver, forventede resultater, kendte fejl og agentens eksekveringstraces. Medtag grænsetilfælde som mislykkede værktøjskald, manglende information og uautoriserede handlinger.
2. Automatisér testkørsel og bedømmelse: Brug frameworks som pytest eller DeepEval til at køre testcases og anvende kodebaserede kontroller eller LLM-bedømmere. Valider LLM-bedømmere mod menneskelige vurderinger, før du stoler på deres scorer.
3. Integrer evalueringer i CI/CD: Kør automatisk regressionstests igen, når udviklere opdaterer en agents prompts, modeller, værktøjer eller arbejdsproces. Sammenlign resultaterne med en baseline, og fastsæt kvalitetstærskler, der forhindrer udgivelser, når kritiske kontroller fejler.
4. Anvend kalibrerede bedømmere på stikprøver af produktionstraces, følg fejlrater og andre ydeevnemålinger, og undersøg nye fejl gennem manuel gennemgang.