«Testene består.» «Den får 92 % på evalueringene våre.» «Modellen topper benchmarken.» Hver av disse setningene brukes som en grunn til å stole på en AI-agent, og de oppfattes ofte som den samme grunnen. De er tre forskjellige. En test, en evaluering og en benchmark undersøker forskjellige ting, gir forskjellige typer resultater og støtter forskjellige beslutninger, og mye av det som går galt når en agent skal vurderes, skyldes at den ene blir tatt for den andre.
Dette innlegget setter de tre ved siden av hverandre. Eksempelet hele veien er en agent som behandler refusjonskrav: Den leser et krav, slår opp bestillingen og salgsvilkårene, og refunderer, avslår eller sender kravet videre til et menneske.
Tre spørsmål
| Spør | Avgjør | |
|---|---|---|
| Test | Gjør koden det vi skrev den for å gjøre? | Om en kodeendring tas inn |
| Evaluering | Gjør agenten jobben vår, og hvor ofte? | Om en versjon slippes ut |
| Benchmark | Hvordan er denne modellen sammenlignet med andre? | Hvilke modeller som prøves først |
De skiller seg også i hva de undersøker, og i hva slags svar de gir. En test undersøker koden rundt modellen, og resultatet er bestått eller ikke bestått. En evaluering undersøker agenten din på dine egne oppgaver, og resultatet er en andel, målt mot en terskel. En benchmark undersøker en modell på oppgaver som noen andre har valgt og offentliggjort, og resultatet er en poengsum på en ledertavle.
Ordene brukes mindre strengt enn tabellen antyder. Anthropics veiledning om evaluering av agenter definerer en evaluering som en test av et AI-system («a test for an AI system»), en benchmark er selv en type evaluering, og testsuiter dukker opp inne i evalueringer som vurderingsmetode. Betegnelsene vil derfor fortsette å gli over i hverandre. Det gjør ikke de tre spørsmålene, og for ethvert tall du får presentert, er det nyttigste å vite hvilket av dem det svarer på.
En test kontrollerer kode
I programvareutvikling har en test en fast betydning. Boken Software Engineering at Google beskriver den enkleste testen som én bestemt oppførsel, bestemte inndata, et observerbart resultat og et kontrollert miljø. Samme inndata gir samme resultat hver gang, så utfallet er bestått eller ikke bestått, og en test som feiler, viser en feil: Noen retter koden, eller testen, til den består.
Testing behandler variasjon som en feil. En test som består i én kjøring og feiler i den neste uten at koden er endret, kalles ustabil («flaky»), og den samme boken skriver ut fra erfaring at testene begynner å miste verdien sin når andelen ustabile kjøringer nærmer seg 1 % («as you approach 1% flakiness, the tests begin to lose value»).
Mesteparten av en agent er kode av denne typen. I eksempelet: funksjonen som regner ut beløpet fra bestillingen, parseren som leser modellens strukturerte svar, verktøyet som utfører utbetalingen, og regelen om at et beløp over en grense går til et menneske. Alt dette testes som annen programvare, ved hver kodeendring. Det gjelder også kontrollene som holder en agent innenfor reglene sine. Innlegget vårt om juridisk kompetanse argumenterer for at en regel som betyr noe, må håndheves utenfor modellen. Det som ligger utenfor modellen, er kode, og kode kan testes.
Det en test ikke kan fortelle deg, er om agentens skjønn er godt: om den forsto kravet, brukte riktig punkt i vilkårene og ga kunden et riktig svar. Det kommer fra en språkmodell, og en modell gir ikke samme svar på samme inndata. Atil mfl. satte opp fem modeller for deterministiske svar, og nøyaktigheten varierte likevel med opptil 15 % mellom kjøringer av de samme oppgavene. En test som stiller krav til hva en modell sier i én kjøring, er enten ustabil eller løs nok til å slippe gjennom svar som er feil.
En evaluering måler agenten din på dine oppgaver
En evaluering gjør den målingen en test ikke kan gjøre. Det den undersøker, er hele systemet (modellen, prompten, verktøyene og koden rundt dem), og oppgavene er dine egne: reelle refusjonskrav, hvert med en fastsatt måte å avgjøre om utfallet er godt nok.
Tre ting skiller den fra en test.
Den gjentas. Anthropics veiledning forklarer hvorfor: Modellens svar varierer fra kjøring til kjøring, så hver oppgave kjøres flere ganger for å gi mer konsistente resultater («we run multiple trials to produce more consistent results»). Hvert tilfelle kjøres flere ganger, mens en test kjøres én gang.
Resultatet er en andel. Svaret er hvor ofte, og det kan ligge langt fra svaret på om. 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. Om en gitt andel er god nok, er en beslutning som tas på forhånd, som en terskel. En test som feiler, betyr en feil. Et evalueringsresultat under terskelen betyr at en utgivelse venter, og at noen leser feilene.
Vurderingen kan kreve skjønn. Kode vurderer alt en regel kan avgjøre, som beløpet som ble refundert. Om forklaringen kunden fikk, er riktig, krever en språkmodell som dommer, kontrollert mot en person som kan arbeidet.
En evalueringssuite som kjører ved hver endring og stopper en utgivelse, ligner mye på en testsuite, og den samme veiledningen sier at regresjonstilfellene skal bestås nesten hver gang («should have a nearly 100% pass rate»). Det er her de to oftest forveksles. Forskjellen ligger i det som måles: oppførsel, målt på et utvalg av tilfeller og kjøringer, med en feilmargin. Innlegget vårt om evalueringer viser hvordan en slik suite bygges.
En benchmark sammenligner modeller på andres oppgaver
En benchmark er en evaluering som mange deler. Et utkast til retningslinjer fra NIST beskriver den som en kombinasjon av et datasett og en måleparameter, som et forskningsmiljø bruker som felles rammeverk for å sammenligne metoder («used by a community of researchers as a shared framework for the comparison of methods»). Fordi oppgavene og poengberegningen er faste og offentlige, kan resultater sammenlignes mellom modeller og over tid. Ingenting annet gir det: Når en leverandør slipper en ny modell, er benchmarkresultatene det første holdepunktet for om den er verdt å prøve.
De samme egenskapene begrenser hva et resultat sier om agenten din.
Oppgavene er ikke dine. I tau-bench betjener en agent simulerte kunder hos en butikk og et flyselskap, etter retningslinjer som er skrevet for benchmarken. Dine refusjonskrav følger dine egne salgsvilkår. Kapoor mfl. kaller valget av en modell til en anvendelse for «downstream evaluation», og advarer om at benchmarker som er laget for å evaluere modeller, kan være misvisende når de brukes til det. Om en benchmark måler det den sies å måle, er også mindre avklart enn en ledertavle gir inntrykk av: En gjennomgang av 445 LLM-benchmarker utført av 29 eksperter fant mønstre i hva de måler, i oppgavene og i poengberegningen som undergraver gyldigheten av påstandene som bygges på dem («undermine the validity of the resulting claims»).
Offentlige oppgaver lekker, og vurderingen har feil. I februar 2026 sluttet OpenAI å rapportere modellenes resultater på SWE-bench Verified, en kodebenchmark selskapet selv publiserte i 2024. Alle de ledende modellene det testet, hadde sett i hvert fall noen av benchmarkens oppgaver og løsninger under trening. Og i en gjennomgang av oppgavene modellene ofte mislyktes på, hadde minst 59,4 % av de gjennomgåtte oppgavene testtilfeller med feil, som avviste funksjonelt riktige løsninger. Konklusjonen var at forbedringer på SWE-bench Verified ikke lenger gjenspeiler reelle forbedringer i modellenes evne til programvareutvikling («no longer reflect meaningful improvements in models' real-world software development abilities»).
Resultatet avhenger av oppsettet. En benchmark kjører en modell inne i et rammeverk, på noens infrastruktur. Anthropic målte effekten av én slik innstilling, dataressursene hver oppgave får: Mellom det rauseste og det knappeste oppsettet flyttet den samme modellens resultat på Terminal-Bench 2.0 seg med 6 prosentpoeng. Konklusjonen var at forskjeller på under 3 prosentpoeng på en ledertavle bør møtes med skepsis til oppsettet er dokumentert og likt («leaderboard differences below 3 percentage points deserve skepticism until the eval configuration is documented and matched»).
Ingenting av dette gjør benchmarker ubrukelige. Det gjør dem til en måte å velge hvilke modeller som skal prøves, og ikke mer enn det.
Når den ene tas for den andre
En benchmark tatt for en evaluering. «Modellen leder ledertavlen, så agenten kommer til å fungere.» Modellen er én del av agenten, og ledertavlen har ingen av dine oppgaver.
Tester tatt for en evaluering. «Alle testene består» sier at koden er riktig. Det sier ingenting om hvor ofte agenten avgjør et krav riktig. Selv der arbeidet er kode, er beståtte tester noe snevrere enn godt nok arbeid. På SWE-bench Verified teller en løsning når prosjektets tester består. METR lot fire vedlikeholdere av tre av disse prosjektene gå gjennom 296 endringsforslag (pull requests) skrevet av agenter, og omtrent halvparten av dem som besto testene, ville ikke blitt tatt inn. METR legger til at agentene ikke fikk mulighet til å svare på en gjennomgang, slik en menneskelig utvikler ville gjort.
En evaluering tatt for en test. Denne får mindre oppmerksomhet. Sett at ingen refusjon over grensen kan utbetales uten at et menneske godkjenner den, og at evalueringssuiten viser at agenten sender slike krav videre i 97 % av kjøringene. Da er måleinstrumentet feil. En regel som må holde hver gang, måles ikke som en andel: Den håndheves i kode, som en kontroll, og kontrollen testes. Evalueringer er til det som er overlatt til modellens skjønn.
Et tall uten oppgavene sine. «Agenten vår er 95 % nøyaktig.» På hvilke oppgaver, vurdert hvordan, og kjørt hvor mange ganger? Uten det er tallet verken en evaluering du kan kontrollere, eller en benchmark du kan sammenligne med.
Hvordan de tre virker sammen
I et prosjekt har hver av dem sin plass.
- Benchmarker, for å velge ut kandidater. To eller tre modeller, valgt med pris, hastighet og vilkår for databehandling ved siden av resultatene.
- Tester, hele veien. Hvert verktøy, hver parser, hver tillatelse og hver kontroll, ved hver kodeendring.
- Evalueringer, for å avgjøre. Kandidatene sammenlignes på dine egne tilfeller, inne i agenten din. Deretter kjører hver endring i en prompt, en modell eller et verktøy suiten, og et resultat under terskelen stopper utgivelsen.
Den samme rekkefølgen gjelder når en leverandør slipper en ny modell. Benchmarkene sier om den er verdt å prøve. Evalueringssuiten sier om dere bør bytte til den. Testene sier at koden rundt den fortsatt gjør det den gjorde.
Illustrasjon av hva en benchmark, tester og evalueringer hver for seg sier når en ny modell slippes, for en agent som behandler refusjonskrav. På en offentlig benchmark med felles oppgaver tar den nye modellen førsteplassen, 2,8 poeng foran den nåværende. Agentens 212 tester kjøres, hver én gang, og alle består, som før. Deretter kjører evalueringssuiten ti av virksomhetens egne tilfeller åtte ganger hver på den nye modellen. Seks av de åtti kjøringene feiler, som gir 92,5 %, under de 95 % en utgivelse krever og under den nåværende modellens 96,3 %. De tre settes så side om side. Benchmarken sier at modellen er verdt å prøve, testene at koden holder, og evalueringene at byttet venter.
Spørsmål du bør stille
Enten dere bygger en agent selv eller kjøper en, viser disse spørsmålene hvilken av de tre en påstand hviler på.
- Når noen sier at agenten er testet, ble kode kontrollert eller oppførsel målt?
- Hvem sine oppgaver kommer dette tallet fra, og kan du se dem?
- Hvor mange ganger ble hver oppgave kjørt, og hvor ofte besto alle kjøringene?
- Hvilke regler håndheves i kode og testes, og hvilke blir bare målt?
- For et benchmarkresultat: Hvem kjørte det, i hvilket oppsett, og blir benchmarken fortsatt vedlikeholdt?
- Hvilken av de tre avgjør om en endring slippes ut?
En benchmark kan fortelle deg hvor du bør begynne, og tester at delene virker. Om en agent gjør jobben din, er noe bare evalueringer på dine egne oppgaver kan vise. Hver agent vi bygger, leveres med sine egne, laget av dine reelle oppgaver.