En demo viser at en AI-agent kan løse en oppgave én gang. I produksjon er spørsmålet et annet: Løser den oppgaven hver gang, og gjør den det fortsatt etter at prompten, modellen eller et verktøy er endret?
Evalueringer svarer på det spørsmålet. En evalueringssuite er et sett av dine egne oppgaver, hver med en fastsatt måte å avgjøre om agentens resultat er godt nok, og den kjøres på nytt ved hver endring. Dette innlegget handler om hvorfor det trengs, hvordan du bygger en suite du kan stole på, og hvor belegget for evalueringer er tynnere enn det ofte fremstilles.
Hvorfor en vellykket demo ikke er bevis
Tre målte egenskaper ved språkmodeller gjør én vellykket kjøring til en dårlig rettesnor.
Samme inndata gir ikke samme svar. Atil mfl. satte opp fem modeller for deterministiske svar og kjørte de samme oppgavene ti ganger hver. Nøyaktigheten varierte med opptil 15 % mellom kjøringene, og ingen av modellene ga repeterbar nøyaktighet på tvers av alle oppgavene.
Modellen kan endre seg under samme navn. Gao, Liang og Guestrin testet kommersielle API-er som tilbyr åpne modeller, og fant at 11 av 31 endepunkter leverte en annen fordeling av svar enn referansevektene. Modeller som leveres som tjeneste, fases også ut etter leverandørens tidsplan: Anthropic forplikter seg for eksempel til minst 60 dagers varsel. Et system som bygger på en slik modell, vil måtte bytte til en annen, mer enn én gang.
Feil forplanter seg fra steg til steg. En agent planlegger, kaller verktøy og handler over mange steg, så en liten feilrate per steg blir en stor feilrate per oppgave. I tau-bench løste en agent som klarte over 60 % av kundeserviceoppgavene på ett forsøk, færre enn 25 % av dem åtte ganger på rad. En Princeton-studie publisert på ICML 2026 fant at 24 måneder med nye modeller ga jevn fremgang i nøyaktighet, men bare beskjeden fremgang i pålitelighet.
De som drifter agenter i produksjon, rapporterer det samme. I en studie av 86 agentsystemer i drift var pålitelighet den største flaskehalsen i utviklingen, og tre firedeler av teamene som ble intervjuet, evaluerte uten et fast sett med testtilfeller. I en leverandørundersøkelse blant 1 340 utviklere var kvalitet den hyppigst nevnte hindringen for produksjonssetting, og 29,5 % av respondentene evaluerte ikke i det hele tatt.
Et team i den situasjonen utvikler i mørket: En endring i en prompt, en modell eller et verktøy kan rette opp det tilfellet den var ment for, og ødelegge to andre, og den første som oppdager det, er en bruker.
Illustrasjon av en evalueringssuite for en agent for kontraktsgjennomgang. Ett tilfelle består i én enkelt kjøring. Kjørt åtte ganger feiler det samme tilfellet to ganger. I en suite med ti tilfeller, hvert kjørt åtte ganger, er det det eneste tilfellet som ikke består hver kjøring. En rettelse får det tilfellet til å bestå, men ødelegger to andre, og utgivelseskontrollen stopper den. Den reviderte rettelsen består alle ti tilfellene og slippes ut. En ny feil i produksjon blir deretter det ellevte tilfellet.
Hva det ikke finnes belegg for
Vi lette etter en kontrollert studie som viser at team med evalueringer leverer raskere, eller har færre regresjoner, enn team uten. Vi fant ingen. Argumentet for evalueringer hviler på mekanismene over og på erfaringene til dem som bygger slike systemer, ikke på en målt sammenligning.
Evalueringer er heller ingen garanti. I september 2025 beskrev Anthropic tre infrastrukturfeil som svekket svarene fra modellene deres over flere uker, og skrev at selskapets egne evalueringer ikke fanget opp svekkelsen brukerne rapporterte. En suite beskytter bare den oppførselen den dekker. Det er en grunn til å bygge den på reell bruk og til å fortsette å følge med på produksjon, og det er det resten av innlegget handler om.
Start med reelle feil
De første tilfellene bør komme fra dine egne oppgaver og de feilene du allerede har sett, ikke fra en offentlig benchmark. Anthropics veiledning er at 20 til 50 enkle oppgaver hentet fra reelle feil er en god start, og at en god oppgave er en der to fageksperter uavhengig av hverandre ville kommet til samme konklusjon om bestått eller ikke bestått.
Det finnes en forskningsmessig grunn til å starte der. Shankar mfl. observerte at folk trenger kriterier for å vurdere svar, men at det er vurderingen av svar som hjelper dem å definere kriteriene. Ingen kan fullt ut spesifisere hva «godt» betyr før de har sett hva systemet produserer. Derfor må en person som kan fagområdet, lese reelle svar, skrive ned hva som er galt med dem, og gruppere notatene i feiltyper. De feiltypene blir evalueringstilfellene.
La kode vurdere der en regel kan avgjøre
Det finnes tre typer vurdering, og den samme veiledningen setter dem i rekkefølge: deterministisk vurdering der det er mulig, en språkmodell der det er nødvendig, og mennesker til å validere begge.
- Kode avgjør alt en regel kan avgjøre: et beregnet beløp, et påkrevd felt, en oppgitt kilde som må finnes, et verktøy som ikke skal kalles. Det er raskt, billig og repeterbart.
- En språkmodell som dommer tar det som krever skjønn: om et sammendrag er tro mot kilden, om et svar faktisk besvarer spørsmålet.
- En person som kan fagområdet, setter standarden de to andre kontrolleres mot.
En modell som brukes som dommer, er en klassifikator og må valideres som en. Sammenlign dommene dens med ekspertens på tilfeller den ikke er justert på, og se på hvor mange reelle feil den fanger og hvor mange gode svar den slipper gjennom, ikke på samlet enighet. Regnestykket viser hvorfor: Hvis 1 av 20 svar er feil, er en dommer som slipper alt gjennom, enig med eksperten om de 19 andre og oppdager ingenting. En dommer er også lettere å validere når den svarer på ett smalt spørsmål, enn når den gir poeng for flere egenskaper samtidig.
Ha to suiter, og les tallene ærlig
Anthropics veiledning skiller regresjonsevalueringer, som skal bestås nesten hver gang og fungerer som utgivelseskontroll, fra evalueringer av det agenten ennå ikke mestrer, som starter med lav beståttandel og viser hva som bør forbedres. Blandes de, skjuler den ene signalet fra den andre.
Små suiter kan ikke se små forskjeller. Som mål på hvor godt agenten gjør det generelt, er en suite et utvalg av oppgavene den vil møte, og et utvalg på 50 gir stor feilmargin: Med en beståttandel på 80 % er den omtrent 11 prosentpoeng i hver retning. En suite av den størrelsen forteller deg at noe gikk i stykker. Den kan ikke skille 80 % fra 85 %. Det praktiske mottrekket, fra Anthropics veiledning om statistikk, er parvis sammenligning: Kjør den gamle og den nye versjonen på de samme tilfellene, og se på hvilke tilfeller som endret seg.
Les så feilene. Et tall ingen har åpnet, er ikke et funn.
For agenter: vurder resultatet, gjenta kjøringen, rapporter kostnaden
Vurder resultatet. Anthropics råd er å vurdere det agenten produserte, ikke veien den tok: fakturalinjene, posten i databasen, filen. Flere veier kan være gyldige, og en kontroll av den eksakte rekkefølgen av verktøykall underkjenner kjøringer som var riktige. Sporet brukes til det resultatet ikke kan vise: hvor en kjøring gikk galt, og regler som må holde underveis, som et verktøy som aldri skal kalles.
Gjenta kjøringen. Fordi kjøringer er forskjellige, kjøres hver oppgave flere ganger. For en agent som arbeider uten tilsyn, er tallet som betyr noe, hvor ofte alle kjøringene lykkes, ikke om én av dem gjør det.
Rapporter kostnad sammen med suksess. Tokens, verktøykall og tidsbruk per oppgave hører hjemme ved siden av beståttandelen, målt på de samme tilfellene. Det er det som lar deg godta eller avvise en billigere eller raskere modell på grunnlag av data.
Offentlige ledertavler erstatter ikke dette. En gjennomgang av ti mye brukte agent-benchmarker fant validitetsproblemer i de fleste av dem; i én ble en agent som returnerte tomme svar, registrert med suksess på 38 % av oppgavene. Ledertavler hjelper deg å velge ut kandidater. Om en agent kan gjøre jobben din, er noe bare dine egne tilfeller kan vise.
Kjør dem ved hver endring
En suite er verdt innsatsen når den kjører uten at noen må bestemme seg for å kjøre den.
- Før en utgivelse. Hver endring i en prompt, en modellversjon, et verktøy eller oppsettet for gjenfinning kjører regresjonssuiten, og et resultat under terskelen stopper utgivelsen. GitHub beskriver at de kjører mer enn 4 000 offline-tester for Copilot, de fleste i CI-pipelinen.
- Etter en utgivelse. Ta stikkprøver av kjøringer i produksjon, vurder dem, og gå gjennom det brukerne melder fra om.
- Tilbake i suiten. Hver feil som oppdages i produksjon, blir et nytt tilfelle, slik at samme feil ikke kan slippe ut to ganger.
Det er også dette som gjør en modelloppgradering til rutinearbeid. Når en leverandør faser ut en modell, besvares spørsmålet «er den nye minst like god på våre oppgaver?» ved å kjøre suiten, ikke med stikkprøver.
Evalueringer er også dokumentasjonen din
Det finnes enda en grunn til å ta vare på evalueringsresultatene: De er dokumentasjon du kan legge frem for andre. De ansatte som blir bedt om å overlate arbeid til en agent, og kundene den betjener, kan med rette spørre hvordan du vet at den er pålitelig. En demo svarer ikke på det, og det gjør heller ikke «vi har testet den». Resultatene fra en suite gjør det: De viser hvilke oppgaver agenten ble testet på, hvordan hvert resultat ble vurdert, og hvor ofte den besto, med dato på hver kjøring.
Den samme dokumentasjonen teller når noe går galt. I Moffatt mot Air Canada (2024) holdt en kanadisk tvisteløsningsnemnd flyselskapet ansvarlig for feil informasjon chatboten ga en kunde, og fant at selskapet ikke hadde utvist rimelig aktsomhet for å sikre at chatboten var nøyaktig («did not take reasonable care to ensure its chatbot was accurate»). Evalueringsresultatene er dokumentasjonen på aktsomheten du har vist.
For noen systemer er det også en rettslig plikt å teste slik. Etter EUs KI-forordning (artikkel 9 nr. 8) skal høyrisikosystemer testes mot måleparametere og sannsynlighetsterskler som er definert på forhånd og tilpasset systemets tiltenkte formål («prior defined metrics and probabilistic thresholds»). Det er en beskrivelse av en evalueringssuite. Plikten gjelder leverandører av høyrisikosystemer, og et system er høyrisiko på grunn av hva det brukes til, ikke hvem som har laget modellen det bygger på. Dette er generell informasjon, ikke juridisk rådgivning.
Spørsmål du bør stille
Enten dere bygger en agent selv eller kjøper en, skiller disse spørsmålene en suite som beskytter dere, fra en som bare tar seg godt ut i en presentasjon.
- Hvilke reelle feil er tilfellene bygget på?
- Hvem avgjorde hva som regnes som riktig, og kan de fagområdet?
- Hvordan ble hver automatiske dommer kontrollert mot den personens vurderinger?
- Hvor mange ganger kjøres hver oppgave, og hvor ofte består alle kjøringene?
- Hva skjer med en utgivelse som havner under terskelen?
- Når leste noen feilene sist?
Uten evalueringer er en agent fortsatt et eksperiment. Hver agent vi bygger, leveres med sine egne: dine reelle oppgaver, gjort om til evalueringstilfeller som måler nøyaktighet, robusthet og kostnad før lansering, og som hver endring må bestå etterpå.