Slik evaluerer du KI-agenter: testsett, vurderere og regresjonskontroller

Bak ethvert godt KI-produkt står en solid evalueringsprosess for KI-agenter, kjent som evals, som fanger opp feil tidlig og sikrer at agenten fungerer som den skal. Evals er avgjørende for KI-agenter som utfører høyrisikohandlinger, for eksempel refusjoner på vegne av andre.

Å bygge en slik prosess krever litt teknisk kunnskap og ferdigheter i dataanalyse. Men det er langt fra så skummelt eller utilgjengelig som det kanskje høres ut. For å hjelpe deg i gang har vi samlet seks praktiske trinn for å evaluere KI-agenter, samt vanlige misoppfatninger som ødelegger prosessen.

Hva vil det si å evaluere en KI-agent?

Å evaluere en KI-agent betyr å vurdere om den utfører oppgaver korrekt, og om beslutningene den tar, oppfyller organisasjonens krav. Rent praktisk er evalueringer av KI-agenter, eller evals, spesifikke måltall som hjelper organisasjoner med å avgjøre om agenten fungerer pålitelig nok for den tiltenkte rollen.

Tenk deg en KI-innkjøpsagent ved et produksjonsanlegg som sjekker reservedelslageret og utarbeider bestillinger for å fylle på lageret. Hvis en godkjent del ikke er tilgjengelig, eller leverandørinformasjonen er utdatert, vil agenten da flagge problemet eller anbefale en ikke-godkjent erstatning?

Og hvis du endrer systemprompten for å løse det problemet, hvordan vet du at du ikke har skapt et nytt?

Uten evaluering på plass er produktledere i praksis overlatt til å gjette. Evals gir derfor et tilbakemeldingssignal for å måle ytelse, oppdage gjentakende problemer og teste endringer med større trygghet.

Når det er sagt, kan en agentevaluering undersøke flere aspekter ved en kjøring:

• Kvaliteten på sluttresultatet
• Informasjonen agenten brukte
• Verktøyene den kalte opp
• Om den fulgte reglene som styrer atferden dens

Vanlige måltall for evaluering av KI-agenter

Evals bygger på kvalitative og kvantitative data. Kvalitativ evaluering hjelper deg med å forstå hva som skjer og hvorfor, blant annet ved at du går gjennom agentens beslutninger manuelt. Kvantitativ evaluering gjør disse observasjonene om til målbare signaler, for eksempel ved å telle hvor ofte bestemte feiltyper oppstår eller beregne hvor stor andel av oppgavene som lykkes.

Her er de grunnleggende måltallene for evaluering av KI-agenter:

• Oppgavesuksess måler om agenten oppnådde det tiltenkte resultatet, vanligvis målt som andelen kjøringer som gir gyldige resultater.
• Handlingskorrekthet måler om agenten brukte verktøy på riktig måte, valgte gyldige argumenter og respekterte tillatelser.
• Svarkvalitet vurderer om det endelige resultatet er nøyaktig, fullstendig og nyttig. Det kan omfatte faktisk korrekthet, etterlevelse av instruksjoner og om agenten underbygger beslutningene sine med den tilgjengelige informasjonen.
• Pålitelighet måler konsistens på tvers av gjentatte forsøk, varierende input og grensetilfeller.
• Kostnad og latens måler ressursene som kreves for å oppnå et vellykket resultat, inkludert kjøretid, tokenforbruk og verktøykall.

Avhengig av hva du måler, kan evals vurdere agentens ytelse fra ende til ende, utførelsesforløpet eller enkeltkomponenter som verktøykall og hentetrinn.

Trinn 1: Bestem hvordan en vellykket agentkjøring ser ut

Først må du eksplisitt beskrive hva agenten skal oppnå – altså produktkravene. Det høres selvsagt ut, men kan være overraskende vanskelig. Det finnes til og med et navn på det: spesifikasjonsgapet.

Slik bør du gå frem, ifølge Andrey Khomutov, vår seniordataforsker:

«Start med to spørsmål: ‘Hva skal til for at jobben regnes som gjort?’ og ‘Hva ville gjort en tilsynelatende vellykket kjøring uakseptabel?’

For agenter betyr det, fra et teknisk perspektiv, å sjekke både resultatet og hvordan agentene kom dit.»

En agent kan komme frem til riktig svar ved å få tilgang til en lekket fasit, eller utføre uautoriserte handlinger mens den løser oppgaven. Khomutov påpeker at svarlekkasje og usikre handlinger under evalueringer er konkrete grunner til ikke å bedømme sluttsvaret alene.

«Jeg forventer at inspeksjon av utførelsesforløpet blir en fast del av evalueringssuiter for agenter, i stedet for noe vi bare gjør når et resultat virker mistenkelig», legger han til.

Involver deretter en domeneekspert for å validere suksesskriteriene dine. Personer med praktisk kunnskap om domenet kan avgjøre om betingelsene vi setter for en KI-agent, faktisk gjenspeiler et vellykket resultat.

Trinn 2. Bygg et testsett ut fra reelle oppgaver og feil

Undersøk agentens faktiske atferd for å forstå hvordan god og dårlig ytelse ser ut. Motstå fristelsen til å starte med å generere dusinvis av tester utelukkende basert på det du tror kan gå galt.

Hamel Husain, ML-ingeniør i Parlance Lab, og Shreya Shankar, forsker innen ML-systemer og evals for anvendt KI, anbefaler å begynne med feilanalyse, en teknikk lånt fra maskinlæring og datavitenskap. Prosessen starter med en kvalitativ analyse av agentens kjøringsspor – logger som viser brukerens input, verktøykall, hentet informasjon og agentens output.

1. Gå gjennom enkeltspor og noter feil (åpen koding). La en domeneekspert inspisere agentkjøringer og skrive korte observasjoner om hva som gikk galt. Fokuser på den første betydningsfulle feilen.
2. Grupper observasjonene i feiltyper (aksial koding). Når du har nok notater, kan du bruke en LLM til å foreslå kategorier for lignende feil. Dette kan for eksempel være anbefalinger av inkompatible deler, unøyaktige lageroppslag og mislykkede overleveringer til mennesker.
3. Tell forekomstene. Plasser hver observasjon i en kategori, og bruk deretter et regneark eller en pivottabell til å beregne hvor ofte hver feiltype forekommer.
4. Prioriter hva som skal løses, ut fra både hyppighet og alvorlighetsgrad.
5. Gjør viktige feil om til testtilfeller. Lagre relevant input, startbetingelser, forventet resultat og vurderingskriterier, slik at agenten kan testes mot det samme scenarioet på nytt.

Hvor mange spor bør du undersøke? Omtrent 100, men det finnes ikke noe magisk tall. Stopp tidlig når du når teoretisk metning: punktet der gjennomgang av flere spor ikke lenger avdekker nye, meningsfulle feilmønstre.

Har du ikke lansert applikasjonen ennå? Syntetiske eksempler kan hjelpe deg med å bygge et første testsett, men reelle brukerdata bør ligge til grunn så snart de er tilgjengelige.

Bruk av benchmarker i evaluering av KI-agenter

I tillegg til å lage dine egne testtilfeller kan du bruke eksisterende samlinger av standardiserte evalueringsoppgaver, kjent som benchmarker, til å vurdere hva agenten er i stand til.

Men benchmarker er ikke ufeilbarlige. Revisjoner av SWE-bench, Epoch AIs gjennomganger av benchmarker og riktige svar som i utgangspunktet ble avvist i TheoPhysEval viser hvordan feilaktige oppgaver eller forventede svar kan forvrenge evalueringsresultatene.

Khomutov anbefaler å velge oppdaterte benchmarker som er relevante for domenet ditt, og å undersøke overraskende beståtte eller mislykkede tester før du behandler poengsummene som pålitelige bevis på agentens ytelse.

Trinn 3. Kjør agenten i et repeterbart testmiljø

Et repeterbart testmiljø er et kontrollert oppsett der du kan kjøre en KI-agent mot de samme testtilfellene under de samme startbetingelsene og sammenligne resultatene. Dette omfatter en mappe med testtilfeller, et Python-skript som kjører agenten, eller et sett med kontroller som evaluerer resultatene.

Du kan begynne med å lagre representativ input som JSON-filer og bruke et Python-skript til å kjøre agentens arbeidsflyt og kontrollere outputen med assertions. For lageragenten ved produksjonsanlegget vårt kan et repeterbart testmiljø se slik ut:

Forstørr

Slik setter du opp et repeterbart testmiljø:

1. Lagre representativ input. Bruk faktiske hendelser eller testtilfeller, og lagre dem i samme struktur som applikasjonen mottar i produksjon. I vårt scenario lagrer du en vedlikeholdsforespørsel med maskin-ID, nødvendig reservedel og vedlikeholdsdato som en JSON-fil, sammen med et øyeblikksbilde av lagerdataene og dataene om godkjente deler.
2. Kjør arbeidsflyten. Send hver input gjennom agenten, inkludert hentetrinn, verktøykall og generering av svar.
3. Registrer resultatet og sporet. Ta vare på det endelige resultatet og relevante mellomliggende handlinger (for eksempel lageroppslag), slik at du ser ikke bare om agenten feilet, men også hvor.
4. Gjenta tilfeller basert på feilens alvorlighetsgrad, hyppighet og hvor vanskelig problemet er å løse. LLM-applikasjoner er ikke-deterministiske (de kan gi ulike resultater fra identisk input), så én vellykket kjøring garanterer ikke at den neste også lykkes. Rapporter andelen vellykkede forsøk, og undersøk feilene.

For sistnevnte anbefaler Khomutov å måle pass@1 (hvor ofte agenten lykkes på ett enkelt forsøk) og pass@k (sannsynligheten for å lykkes minst én gang i løpet av et gitt antall forsøk). Hvis du rapporterer pass@k, bør du oppgi antall forsøk, siden ett riktig svar blant flere ikke betyr at agenten vet hvilket den skal velge.

Etter hvert som applikasjonen vokser, kan du bruke et testrammeverk som pytest til å organisere og kjøre tester, og vurdere å lagre store testdatasett og resultater i en database.

Trinn 4. Velg riktig bedømmer for hver kontroll

En bedømmer (også ofte kalt en evaluator) er en mekanisme i form av en kodebit, en LLM styrt av en vurderingsmatrise, eller en menneskelig kontrollør som sjekker agentens output eller handlinger mot et definert kriterium. En bedømmer returnerer en bestått/ikke bestått-vurdering og en forklaring som viser til de relevante bevisene.

Info: En vurderingsmatrise er et sett med kriterier og instruksjoner som definerer hva som regnes som et korrekt eller akseptabelt resultat.

Hvilken type bedømmer som passer, avhenger av hva du prøver å verifisere. Slik skiller de tre tilnærmingene seg fra hverandre:

Noen ganger kan ulike aspekter ved samme kjøring kreve ulike evalueringsmetoder, så du må kanskje kombinere bedømmere.

Hvordan kombinerer du bedømmere?

Du spør: «Kan resultatet verifiseres mot en kjent regel eller forventet verdi, eller krever det menneskelignende skjønn?»

• Hvis du kan verifisere resultatet eksakt, bør du starte med en kodebasert bedømmer. Kodebaserte bedømmere kan også verifisere strukturert output, gyldige feltverdier, verktøyargumenter eller den endelige tilstanden til en database.
• Hvis kontrollen krever tolkning av kontekst, bruker du LLM-as-a-judge.
• Bruk menneskelige kontrollører til domenespesifikke eller omstridte beslutninger.

Viktig! En LLM-bedømmer kan feiltolke bevis eller bruke en vurderingsmatrise feil. Da trengs et ekstra evalueringstrinn: kalibrering mot menneskelige vurderinger.

Kalibrer LLM-bedømmeren mot menneskelige vurderinger.

Kalibrering krever i bunn og grunn at en domeneekspert vurderer faktiske agentkjøringer. Eksperten sammenligner deretter sine vurderinger med LLM-ens og forbedrer vurderingsmatrisen basert på uenighetene.

Her er en kalibreringsprosess for bedømmere i fem trinn:

1. Samle inn eksempler på agentens input, output og relevante spor.
2. La en domeneekspert vurdere uavhengig om hvert eksempel oppfyller evalueringskriteriet.
3. Kjør LLM-bedømmeren på disse eksemplene.
4. Sammenlign vurderingene fra mennesket og modellen.
5. Undersøk uenighetene, og forbedre bedømmerens vurderingsmatrise før du tester den på nye eksempler.

Khomutov understreker også hvor viktig det er å teste LLM-bedømmerens konsistens separat:

«Gi den nøyaktig den samme lagrede kjøringen og de samme filene flere ganger, uten å kjøre agenten på nytt. Da kan du skille variasjon i agentens arbeid fra variasjon i vurderingen.»

Hvis samme output får ulike vurderinger, må du ikke anta at alle endringer i poengsummen skyldes agenten. Undersøk i stedet en forvirringsmatrise som viser når bedømmeren identifiserte feil korrekt, overså dem eller feilaktig flagget akseptable resultater.

Menneskelig gjennomgang er fortsatt avgjørende for å etablere referansevurderinger, avgjøre omstridte tilfeller og oppdage nye feiltyper som eksisterende bedømmere ikke er laget for å fange opp.

Trinn 5. Sammenlign versjoner og kjør regresjonskontroller

Anta at feilanalysen viser at lageragenten din ofte anbefaler ikke-godkjente reservedeler. Du endrer systemprompten slik at den krever en eksplisitt kompatibilitetskontroll. Testtilfellet som opprinnelig feilet, består nå. Men hvordan vet du at endringen ikke har påvirket andre oppgaver?

Det er her regresjonstesting kommer inn.

Regresjonstesting innebærer å kjøre tidligere vellykkede testtilfeller på nytt etter at du har endret agentens prompt, modell eller arbeidsflyt, for å sikre at endringen ikke har ført til nye feil.

1. Gjenskap den opprinnelige feilen med en lagret input fra testsettet.
2. Gjør en målrettet endring i prompten, modellen eller arbeidsflyten.
3. Kjør den feilende testen på nytt for å sjekke om problemet er løst.
4. Kjør de andre testene for å bekrefte at endringen ikke har ødelagt atferd som tidligere fungerte.
5. Gå gjennom resultatene og undersøk eventuelle nye feil.

Sammenlign referanseversjonen og den oppdaterte versjonen av agenten med de samme testtilfellene og vurderingskriteriene for å få nøyaktige resultater.

Trinn 6: Overvåk ytelsen til KI-agenten i produksjon

Evalueringen av agenten stopper ikke når du har rullet ut applikasjonen. Som Husain og Shankar forklarer, kan de samme evaluatorene som du bruker under utviklingen, også kjøres mot ekte produksjonsdata for å måle hvordan agenten presterer over tid.

Dette kalles online-evaluering, og det er én del av en bredere overvåkingsprosess i produksjon som bidrar til å avdekke tilbakevendende og tidligere ukjente feil.

Prosessen er iterativ og består av fire aktiviteter som utfyller hverandre:

• Kjør kalibrerte LLM-dommere på produksjonsspor. Ta stikkprøver av ekte agentinteraksjoner, og bruk evaluatorene du allerede har validert mot menneskelige vurderinger.
• Følg med på feilratene over tid. Bruk feilkategoriene som ble etablert under feilanalysen, til å tallfeste tilbakevendende problemer.
• Fortsett å gå gjennom spor manuelt. Automatiserte vurderere oppdager bare de problemene de er laget for å identifisere. Undersøk stikkprøver av ekte agentinteraksjoner manuelt for å avdekke nye feil eller uvanlige brukerforespørsler.
• Bruk A/B-testing til å måle forretningsresultater (bare når det er hensiktsmessig). Sammenlign ulike prompter, modeller eller arbeidsflyter ved hjelp av måltall som andel fullførte oppgaver, brukertilfredshet og tid til løsning. Prosessen bidrar til å avgjøre om en endring faktisk forbedrer produktopplevelsen, utover å bestå enkelttester.

En viktig merknad: Evalueringer trenger ikke å være finpusset til perfeksjon. De må bare være gode nok til å forbedre produktet ditt.

Vanlige misoppfatninger om evaluering av KI-agenter

• Evalueringer er bare enhetstester. Det er de ikke. Enhetstester er små, automatiserte kontroller som bare utgjør én del av evalueringen. Evalueringer omfatter også kvalitativ feilanalyse, menneskelige vurderinger, overvåking i produksjon og eksperimenter for å måle kvaliteten på applikasjonen.
• En evalueringsplattform kan gjøre alt for deg. Ferdige verktøy kan automatisere enkelte kontroller, men de kan ikke avgjøre hvilke feilmoduser (typer feil eller uønsket agentatferd) som betyr noe for produktet ditt.
• Du kan la en LLM evaluere alt. Det er en stor feilslutning. Menneskeledet feilanalyse og kalibrering av vurderere er fortsatt avgjørende, ettersom LLM-er mangler forretningskonteksten som trengs for å oppdage alle problemer.
• A/B-testing, eller ganske enkelt å bruke agenten, erstatter evalueringer. Feil. A/B-tester kan vise hvilken versjon som presterer best på utvalgte måltall, men kan ikke alene forklare de underliggende problemene.

Vanlige spørsmål om evaluering av KI-agenter

1. Hva er forskjellen mellom evaluering av KI-agenter og evaluering av LLM-er?

LLM-evaluering måler hvor godt en språkmodell utfører en gitt oppgave, for eksempel å svare på et spørsmål, oppsummere et dokument eller hente ut informasjon. Evaluering av KI-agenter vurderer et system som selvstendig utfører flere trinn for å fullføre en oppgave.

I motsetning til en typisk LLM-evaluering ser agentevaluering på både sluttresultatet og rekkefølgen av handlinger som ble utført for å oppnå det, inkludert verktøykall, beslutninger og overholdelse av forhåndsdefinerte regler.

2. Viktige måltall for evaluering av KI-agenter

Måltall for evaluering av KI-agenter faller inn i to hovedkategorier:

• Måltall for teknisk ytelse: Andel vellykkede oppgaver, korrekte handlinger, svarkvalitet, pålitelighet (pass@1 og pass@k), latens, tokenbruk og kostnad per vellykket oppgave.
• Måltall for forretning og brukeropplevelse: Kundetilfredshet (CSAT), løsningsrate for saker, eskaleringsrate, konverteringsrate, tid til fullført oppgave og andre resultater som er spesifikke for agentens rolle.

En kundestøtteagent kan for eksempel evalueres på vellykket løsning av saker og kundetilfredshet, mens en KI-innkjøpsagent kan måles på nøyaktigheten i forespørsler om lagerpåfyll, godkjenningsrater og syklustid for innkjøp.

De riktige måltallene bør gjenspeile både hvor pålitelig agenten presterer, og om arbeidet den gjør, forbedrer forretningsresultatene.

3. Hva er de beste verktøyene for å evaluere KI-agenter?

Vanlige alternativer er blant annet:

• Testrammeverk: Assert-setninger i Python og pytest er nyttige for å kjøre repeterbare testtilfeller og kontrollere eksakte betingelser, for eksempel om en agent valgte riktig verktøy eller returnerte en gyldig del-ID.
• Rammeverk for evaluering av KI-agenter: DeepEval og Googles agent-eval-verktøysett støtter mer komplekse evalueringer, inkludert kjøringsspor, LLM-baserte vurderere og automatisert regresjonstesting.
• Plattformer for evaluering og observerbarhet: LangSmith, Arize Phoenix og MLflow hjelper team med å undersøke agentatferd, administrere evalueringsdatasett, sammenligne agentversjoner og overvåke ytelsen i produksjon.

4. Hvordan automatiserer du evalueringer av KI-agenter?

Du kan automatisere evalueringer av KI-agenter ved å bygge repeterbare tester, bruke automatiserte vurderere og integrere disse kontrollene i arbeidsflytene for utvikling og produksjon:

1. Lag et evalueringsdatasett: Samle inn representative brukeroppgaver, forventede resultater, kjente feil og kjøringsspor fra agenten. Ta med kanttilfeller som mislykkede verktøykall, manglende informasjon og uautoriserte handlinger.
2. Automatiser testkjøring og vurdering: Bruk rammeverk som pytest eller DeepEval til å kjøre testtilfeller og bruke kodebaserte kontroller eller LLM-vurderere. Valider LLM-vurderere mot menneskelige vurderinger før du stoler på poengsummene deres.
3. Integrer evalueringer i CI/CD: Kjør regresjonstester automatisk på nytt når utviklere oppdaterer prompter, modeller, verktøy eller arbeidsflyten til en agent. Sammenlign resultatene med en referanseversjon, og fastsett kvalitetsterskler som stopper utgivelser når kritiske kontroller mislykkes.
4. Bruk kalibrerte vurderere på utvalgte produksjonsspor, følg feilrater og andre ytelsesmåltall, og undersøk nye feil gjennom manuell gjennomgang.