Slik tester du en KI-agent før én vellykket demo blir falsk trygghet

Test en KI-agent med oppgaver som har kjent starttilstand og kontrollerbart sluttresultat. For hver kjøring må du undersøke om agenten valgte riktige verktøy, brukte dem innenfor rammene og faktisk fullførte oppgaven. Vurder svaret til brukeren separat: En overbevisende bekreftelse er ikke bevis på at handlingen ble utført.

Én vellykket demo er bare én observert kjøring; OpenAIs veiledning for agentevaluering anbefaler spor når forløpet skal feilsøkes, og repeterbare datasett og evalueringskjøringer når kvalitet skal sammenlignes over tid. Gjør derfor demooppgaven om til et testtilfelle som kan kjøres på nytt, og utvid settet med situasjoner der agenten må ta andre valg.

Bygg et oppgavesett med kontrollerbar fasit

Begynn med arbeid agenten er ment å gjøre. Beskriv brukerens mål, tilgjengelige data og verktøy, samt hva som skal være sant etterpå. Fasit må gjelde resultatet i systemet, ikke bare ordene agenten forventes å bruke. Hvis flere fremgangsmåter er gyldige, skal testen tillate dem så lenge resultatet og begrensningene er de samme.

En testoppgave kan beskrives med disse feltene:

• Inngang og starttilstand: brukerforespørselen og relevante verdier i systemene før kjøringen.
• Handlingsrom: tilgjengelige verktøy, tillatelser og handlinger som krever godkjenning.
• Forventet utfall: den verdien eller tilstanden som kan kontrolleres uavhengig av agentens svar.
• Forventet kommunikasjon: hva brukeren skal få vite ved fullføring, avslag eller behov for avklaring.
• Stoppfeil: handlinger som gjør kjøringen uakseptabel, for eksempel endring av feil post.

Ta med ordinære oppgaver, manglende opplysninger og verktøy som returnerer feil. Lag også tilfeller der riktig valg er å spørre brukeren eller la være å kalle et verktøy. Ellers kan en agent få god score ved å utføre samme handling for ofte. Før et tilfelle tas inn i settet, bør en kjent gyldig løsning kunne passere kontrollene; en uklar oppgave gir et uklart testresultat.

Behold sporet fra beslutning til sluttmelding

Et spor skal gjøre det mulig å finne hvor en kjøring gikk galt. Knytt brukerens forespørsel, verktøykall og argumenter, verktøysvar, eventuelle overleveringer og sluttmeldingen til samme testtilfelle. Registrer også feil fra verktøyene. Hvis agenten ignorerer et avslag og likevel melder at oppgaven er ferdig, må begge hendelsene være synlige.

Undersøk det første avviket, ikke bare den siste setningen. Feil verktøyvalg, riktig verktøy med feil argument og riktig verktøykall med misforstått svar peker mot ulike endringer i agenten. Et vellykket kall viser dessuten bare at verktøyet godtok kallet; resultatkontrollen må avgjøre om brukerens mål ble nådd.

Tidsbruk og antall verktøykall kan være nyttige egne mål, særlig når agenten gjentar handlinger. Hold dem adskilt fra om oppgaven ble fullført. Unngå å kreve en eksakt rekkefølge på alle kall dersom ulike sekvenser kan gi samme tillatte utfall. Kontroller heller nødvendige begrensninger, som at agenten ikke endrer andre poster eller hopper over et påkrevd godkjenningspunkt.

Kontroller faktisk tilstand og velg riktig gradering

For oppgaver som endrer et system, sammenligner du tilstanden før og etter kjøringen. I Anthropics gjennomgang av agentevaluering er en flybestilling eksempelet: Agenten kan si at reisen er bestilt, mens det kontrollerbare utfallet er om reservasjonen finnes i miljøets SQL-database. Kontroller også at ingen uvedkommende reservasjon ble endret.

Bruk deterministiske tester der fasiten kan uttrykkes presist: finnes riktig post, har den riktig verdi, ble et forbudt verktøy kalt, eller ble et påkrevd argument sendt? For åpne spørsmål, som om forklaringen til brukeren er forståelig, kan en modellgraderer bruke en rubrikk med tydelige kriterier. La mennesker kontrollere utvalgte vurderinger og vanskelige tilfeller, særlig når modellgraderen innføres eller endres.

Gi resultat og kommunikasjon hver sin vurdering. «Riktig svar, ingen registrert endring» krever en annen rettelse enn «riktig endring, misvisende svar». En språkgraderer bør ikke avgjøre om en databasepost finnes når den kan kontrolleres direkte. Hvis oppgaven kan løses delvis, kan testen vise hvilke delkrav som ble oppfylt uten å kalle hele forløpet fullført.

Gjenta forsøk og klassifiser feil

Kjør forsøkene i et isolert miljø som tilbakestilles til samme starttilstand. Gjenta oppgaver der agentens valg kan variere; en enkelt bestått kjøring sier lite om hvor stabilt resultatet er. Bruk samme oppgaver og sammenlignbare betingelser når du vurderer en endring i modell, instruksjoner eller verktøyoppsett.

Sorter mislykkede kjøringer etter det som faktisk skjedde: feil verktøy, feil argument, oversett verktøyfeil, manglende tilstandsendring, uønsket sideeffekt eller uriktig sluttmelding. Ha en egen kategori for uklare oppgaver og feil i testmiljøet. Da blir det synlig om agenten trenger en rettelse, eller om testen avviste en gyldig løsning.

Legg en oppdaget feil tilbake i oppgavesettet med starttilstand og fasit. Kjør deretter både det nye tilfellet og de eksisterende oppgavene. En endring som gjør agenten flinkere til å bruke ett verktøy, kan samtidig få den til å bruke verktøyet når den burde ha spurt om avklaring.

Sett en port før produksjonssetting

Bestem beståttkrav før den nye versjonen kjøres. Feil endret post, handling uten nødvendig tillatelse og falsk melding om fullføring kan være stoppfeil. Vurder mål som formulering og tidsbruk separat, og rapporter resultater per oppgavetype og feilklasse. Ett samlet gjennomsnitt kan skjule at en viktig arbeidsflyt er blitt dårligere.

LangChains dokumentasjon om evalueringstyper beskriver testing på kuraterte datasett før utrulling og regresjonstester som sammenligner versjoner over tid. Bruk den sist godkjente versjonen som referanse, og kjør samme sett når modell, instruksjoner, verktøy eller ruting endres. Behold sporene fra kjøringene, slik at et dårligere resultat kan knyttes til en konkret beslutning i agentforløpet.

Produksjonsporten er passert når de kritiske kontrollene består, kjente feil fortsatt er rettet, og nye avvik er undersøkt. Når brukere senere avdekker en ny feiltype, kan den få et eget testtilfelle. Slik blir kravet til neste versjon konkret: Den må løse den nye oppgaven uten å miste resultatene som allerede er godkjent.

Les også:

• Slik kjøper du SpaceX-aksjen fra Norge – ASK kan ikke brukes
• YouTube-testen velger seertid, ikke klikk: slik tester du miniatyrbilder
• Coachella blir på YouTube til 2030 – eneretten fortsetter