En felles håndbok for pålitelige tredjepartsevalueringer

Uavhengige, pålitelige tredjepartsevalueringer spiller en kritisk rolle⁠ i å styrke sikkerhetsøkosystemet. Disse evalueringene gjennomføres på frontier-modeller for å gi ytterligere bevis for påstander om kritiske evner og sikkerhetstiltak. I dette innlegget deler vi lærdommer vi har gjort oss så langt, og anbefaler tilnærminger for å utforme evalueringer som på en gyldig måte kan vurdere frontier-modeller, og som vi håper kan bidra til å informere fremvoksende standarder på området.

Tidligere behandlet mange evalueringer modeller som chatboter: evalueringen promptet en modell som om den var en bruker som stilte et spørsmål, modellen svarte, og en evaluator vurderte resultatet. Dagens frontier-modeller kan gjøre mye mer: de kan bruke verktøy, holde styr på informasjon over mange trinn og handle innenfor en større arbeidsflyt. Dette betyr at ytelsen ikke bare avhenger av modellen, men også av miljøet der oppgaven finner sted, og av oppsettet som legger til rette for handlingene dens. Dette omkringliggende oppsettet, som vi kaller «rammeverk», kan endre sentrale aspekter ved systemets ytelse, inkludert hvordan det bruker verktøy, holder styr på informasjon eller henter seg inn etter feil.

Dette endrer hvordan evalueringer må gjennomføres, og hva lesere bør se etter i evalueringsrapporter. Etter vårt syn beskriver de mest nyttige rapportene eksplisitt to ting utover selve resultatet: For det første spesifiserer de hvilken påstand evalueringsoppsettet var utformet for å teste, og for det andre deler de tilgjengelige bevis for at evalueringsresultatet er gyldig.

Påstander som testes i evalueringer, faller vanligvis i én av tre kategorier¹:

• Fremkalling av evner: Kan en modell plausibelt produsere evnen som evalueres? 
• Ytelse for sikkerhetstiltak: Hvor robuste er de testede sikkerhetstiltakene mot atferden eller angrepet som evalueres?
• Sammenligning: Hvordan presterer ulike modeller under tilsvarende betingelser?

Evalueringsrapporter må også forklare hvordan evaluatorer kontrollerte for effekter som kan påvirke gyldigheten av et resultat. Disse inkluderer:

• Reward hacking: Å utnytte snarveier i oppgaven eller poenggiveren, slik at systemet får uttelling uten å demonstrere atferden evalueringen er ment å måle.
• Avslag: Å avslå på måter som skjuler atferden som testes.
• Kontaminering: Å prestere for godt fordi evalueringsoppgaver, svar eller nære varianter forekom i treningsdata eller kunne oppdages under evalueringen, for eksempel gjennom nettlesing.
• Defekte problemer: Å prestere for dårlig fordi oppgavene er ugyldige. Årsaker kan inkludere urettferdig poengsetting (f.eks. at riktig svar krever uuttalte implementasjonsdetaljer) og uløselige miljøer (f.eks. manglende kritiske filer eller upålitelige verktøy).
• Sandbagging: Bevisst underprestasjon når de viser bevissthet om at de blir evaluert.

Vi har observert at rollen til rammeverk er spesielt viktig for systemer som handler over lengre trajektorier. Når modeller kan bruke verktøy, opprettholde tilstand og hente seg inn etter feil over mange trinn, kan rammeverk endre det observerte ytelsesnivået, og til og med avgjøre om evnen som vurderes i det hele tatt kommer til syne i evalueringen. For eksempel kan et rammeverk som bevarer tilstand og prøver mislykkede handlinger på nytt, la en modell fullføre en flertrinnsoppgave som den samme modellen aldri fullfører i et enklere rammeverk.

I tabellen nedenfor skiller vi mellom tre typer påstander evaluatorer kan ønske å fremsette, og hvilket rammeverk vi mener hver type påstand krever.

Påstander om evner er bare så sterke som fremkallingen bak dem: evaluatorer må velge rammeverk som passer best til oppgaven og evnen evalueringen forsøker å måle. Et standardisert rammeverk kan være riktig for å sammenligne systemer under identiske betingelser, men det kan undervurdere evner når det utelater spesifikke rammeverk-funksjoner som hjelper modellen med å utføre oppgaven. For eksempel viser GPT‑5.5s ytelse på OpenAIs cyberintervaller hvordan et valg av rammeverk kan endre målt evne vesentlig på oppgaver som krever langvarig, flertrinns bruk av verktøy: modellen presterer bedre når rammeverk bruker kompaktering⁠ for å bevare oppgaverelevant kontekst etter hvert som interaksjonen blir lengre. Dette viser at for visse modeller vil et rammeverk som utelater kompaktering, fremkalle for lite ytelse.

Andre publiserte evalueringer² viser også at valg av rammeverk og budsjett endrer evalueringsresultater. Økt testtidsberegning kan endre betydelig hvilken evne en evaluering fremkaller, særlig i domener der suksess er lett å verifisere, som mange cyberoppgaver. I UK AISIs evaluering av cyberintervaller⁠(åpnes i et nytt vindu) forbedret en økning i budsjettet fra 10M til 100M token ytelsen med opptil 59 %, og ytelsen økte fortsatt ved det høyeste testede budsjettet. Å beskrive dette gjør evalueringen lettere å tolke: det viser leserne hvordan resultatet avhenger av det testede fremkallingsoppsettet. Når ytelsen fortsatt forbedres med ekstra budsjett, bør poengsummen beskrives som ytelse under det rammeverket og budsjettet, ikke som et målt tak for evne. Evne er ofte ressursavhengig snarere enn en fast størrelse som kan måles rent én gang for alle. Der suksess kan måles på tvers av gjentatte forsøk, bør rapporter også vurdere forventet kostnad per vellykket løsning, ikke bare suksessrate ved et fast tokenbudsjett. Dette kan gjøre alvorlighetsgrad lettere å tolke: en lav suksessrate kan fortsatt være praktisk betydningsfull hvis kostnaden ved gjentatte forsøk ligger innenfor den relevante trusselmodellen. For påstander om evner er unngåelig underfremkalling en målefeil: hvis rammeverk eller budsjett hindrer systemet i å vise atferd det ellers kunne produsert, måler poengsummen ikke evnen det hevdes å måle. Der evaluatorer har presset fremkallingen så langt det er praktisk mulig og ytelsen fortsatt forbedres, bør rapporter si dette tydelig og gjøre det klart at resultatet bare er et nedre grense-estimat.

Testing av sikkerhetstiltak kan undervurdere om et angrep kan lykkes, og hvor alvorlig det kan bli, når man ikke tar hensyn til ressursene som er tilgjengelige for angripere, inkludert tilpassede rammeverk. I UK AISIs cyberevaluering av GPT‑5.5⁠(åpnes i et nytt vindu) fant deres ekspertbaserte red teaming en universell jailbreak som fremkalte regelstridig cyberinnhold på tvers av de ondsinnede forespørslene OpenAI leverte, inkludert i agentiske flerturnsinnstillinger. De brukte Codex til å lage et tilpasset rammeverk for å styrke modellens angrepsytelse: det bygget inn et gjenbrukbart mønster for å omgå sikkerhetstiltak i interaksjonen, bevarte dette mønsteret på tvers av turer og blokker, og brukte det på tvers av de ondsinnede cyberforespørslene OpenAI leverte. Testing av sikkerhetstiltak bør samsvare med angriperen. Hvis påstanden gjelder robusthet mot ekspertmisbruk, bør testen evaluere den sterkeste troverdige ende-til-ende-angrepsstrategien innenfor et definert budsjett, inkludert ethvert rammeverk som trengs for å bevare og gjenbruke den strategien. Ellers risikerer resultatene feilkalibrering: de kan bare underbygge en snevrere påstand om motstand mot enklere prompting, de kan overse både hvor alvorlig angrepet blir og sannsynligheten for at det lykkes når fremkallingsmetoden operasjonaliseres, og de kan også overvurdere hvor sannsynlig eller alvorlig et problem er hvis det gis for stort budsjett.

Det finnes tid og sted for sammenligninger med standardiserte rammeverk, men evaluatorer bør være eksplisitte om hvorfor det er passende å bruke et konsistent sett med rammeverk og hvilken påstand det kan underbygge. METRs evaluering av tidshorisont⁠(åpnes i et nytt vindu) er et eksempel på et bredere, passende fast evalueringsoppsett: det er utformet for å produsere sammenlignbare resultater på tvers av systemene det evaluerer. METR definerer et felles utfall, den typiske varigheten for en menneskelig oppgave der en AI-agent forventes å lykkes med et gitt pålitelighetsnivå. Det bruker en delt oppgavesuite, poengsettingsmetode, tilpasningsmetode og et lite sett med gjenbrukbare støttestrukturer som Triframe og ReAct⁠(åpnes i et nytt vindu) innenfor hver gruppe av estimater som rapporteres sammen. Da METR utvidet oppgavesuiten og flyttet evalueringsinfrastrukturen fra et rammeverk kalt Vivaria til et kalt Inspect, rapporterte de endringen (Time Horizon 1.1-oppdatering⁠(åpnes i et nytt vindu)) og evaluerte modeller på nytt under det nye evalueringsoppsettet. Det er verdien av et standardisert evalueringsoppsett, inkludert et konsistent sett med rammeverk: det kan gjøre lesere trygge på at en forskjell i poengsummer faktisk gjenspeiler en forskjell mellom systemene som sammenlignes, snarere enn en endring i måleoppsettet.

Vi anbefaler at tredjeparts evalueringsrapporter oppgir hvilken type påstand evalueringsoppsettet er ment å underbygge; beskriver hvor tett det som ble testet gjenspeiler den bredere påstanden; beskriver rammeverkvalgene som formet resultatet; redegjør for når disse valgene endres mellom evalueringer; og inkluderer støttende bevis som viser hvordan resultatet ble produsert og hvor godt det generaliserer til påstanden.

Etter hvert som modeller blir mer kapable, blir evalueringspoeng lettere å feiltolke. Sammenlignet med reelle evner kan evalueringspoeng bli kunstig redusert hvis en modell gjenkjenner at den blir evaluert og strategisk underpresterer. De kan bli oppblåst hvis modellen utnytter en snarvei i oppgaven, prompten, poenggiveren eller rammeverk. De kan også forvrenges av kontaminering (der en modell allerede kjenner eller kan finne et svar uten å løse oppgaven) eller av «defekte» problemer som er tvetydige, feilpoengsatt, uløselige eller sårbare for utilsiktede snarveier. Evalueringsrapporter bør derfor kombinere overskriftspoeng med en diskusjon av disse farene, slik at lesere kan vurdere om poengsummene gjenspeiler den tilsiktede atferden.

Rammeverk, budsjetter, verktøy, poengsettingsregler, monitorer og gjennomgangsprosedyrer påvirker alle om en agent løser den tilsiktede oppgaven, unngår den, memorerer den eller finner en vei rundt den. En pålitelig rapport gjør disse kontrollene synlige: evaluatorer bør gjennomgå eksempler for denne typen atferd hver gang en vurdering kjøres.

Reward hacking

Reward hacking betyr å oppnå høye evalueringspoeng på måter som ikke gjenspeiler den tilsiktede evnen. Her er bekymringen at systemet får uttelling ved å utnytte oppgaven, poenggiveren, prompten eller rammeverk, snarere enn ved å gjøre arbeidet evalueringen var ment å måle. METRs evaluering av GPT 5.4⁠(åpnes i et nytt vindu) viser hvorfor dette er viktig: selv om modellen lyktes på oppgaver i en takt som ved første gjennomgang ville ha tilsvarte en tidshorisont på omtrent 13 timer, viste menneskelig gjennomgang at noen av disse suksessene kom fra reward hacking, og da resultatene ble revidert for bare å ta hensyn til tilfeller uten reward hacking, falt estimatet til omtrent 6 timer. Evaluatorer bør vurdere behovet for slike justeringer og, når de er nødvendige, rapportere dem tydelig: et evneestimat er langt mer nyttig når lesere kan se hvilke tilsynelatende suksesser som ble diskvalifisert, hvorfor de ble diskvalifisert, og hvor mye resultatet avhenger av den vurderingen.

Avslag

Modeller kan også underprestere i evneevalueringer på grunn av sikkerhetstiltak. En modell kan ha lavere evalueringsytelse enn den er i stand til fordi den avslår evalueringsoppgaver i stedet for å fullføre dem. Rapporter bør derfor forklare om avslag var en del av evalueringsresultatene, og hvis ja, hvor mange eksempler som ble kompromittert på grunn av dem.

Kontaminering

Kontaminering er viktigst for offentlige eller gjenbrukte benchmarker⁠. Hvis oppgaver, svar eller nære varianter forekommer i treningsdata eller kan finnes av en agent med nettlesing, kan ytelsen gjenspeile memorering eller gjenfinning snarere enn modellens ytelse. Evaluatorer bør der det er mulig foretrekke private eller nylig konstruerte oppgaver og teste om modeller gjengir oppgavespesifikke detaljer før de løser oppgaven.

Defekte problemer

Defekte problemer omfatter situasjoner som for eksempel et problem som ved et uhell ikke kan løses. Defekte problemer er vanlige nok⁠(åpnes i et nytt vindu) til at de bør behandles som en standard risiko for gyldighet. De omfatter feil fasit, tvetydige prompter, manglende filer, ustabile tjenester, urettferdige poengsettingskriterier og miljøer som eksponerer snarveier som skjulte svarfiler eller lagerhistorikk som inneholder fasit-patchen.

Sandbagging

Sandbagging fra en modell eller et system betyr strategisk underprestasjon når sterk ytelse ville komme i konflikt med et mål. Apollos evaluering av GPT‑5.5⁠(åpnes i et nytt vindu) testet dette ved å skape en kontekst der modellen forsto at høye evalueringspoeng kunne utløse avlæring eller blokkere distribusjon. GPT‑5.5 svarte fortsatt riktig, noe som tyder på lite atferdsmessig bevis for strategisk underprestasjon³. Men deres gjennomgang av resonneringsspor la til viktig kontekst: Apollo fant moderate eller sterkere tegn på bevissthet om alignment-evaluering i 52 % av eksemplene under sandbagging-betingelsen, sammenlignet med 0 % i kontrafaktiske tilfeller. Dette beviset kompliserer tolkningen av resultatet, men gir til syvende og sist leserne mer signal: leserne kan se både det betryggende atferdsresultatet og grunnen til å være forsiktig med å overtolke det.

Sterke påstander krever både riktig rammeverk for å fremkalle atferden og gyldighetskontroller som viser at resultatet er solid. Vårt syn på at rammeverk og gyldighetskontroller er en del av evalueringsresultatet, former hvordan vi i praksis støtter tredjepartsevalueringer: 

• Vi deler spesifikk veiledning om maksimal fremkalling med evaluatorer.
• Vi ber evaluatorer av evner om å bruke Codex som et felles minimum for OpenAI-modeller: tester bør i det minste kjøre en baseline gjennom det samme agentiske grensesnittet brukere sannsynligvis vil støtte seg på, ikke bare gjennom et nedstrippet modellgrensesnitt.
• Vi gjør også resonneringsspor og andre mellomliggende artefakter tilgjengelige der de trengs for å vurdere bedrag, sandbagging eller evalueringsbevissthet. METR og Apollo har brukt denne tilgangen i OpenAI-evalueringer siden GPT‑5. 
• Til slutt prioriterer vi forskning for å forstå dypere når og hvordan valg av rammeverk endrer resultater vesentlig, fra konteksthåndtering og verktøytilgang til atferd ved nye forsøk, poengsetting og ressursbudsjetter.

Disse anbefalingene er ikke bare ment å forbedre individuelle evalueringsrapporter, men også å informere fremvoksende nasjonale ⁠(åpnes i et nytt vindu)og internasjonale ⁠(åpnes i et nytt vindu)standarder for evaluering og rapportering av frontier-AI. Fremover bør standarder for tredjepartsevaluering kreve nok detaljer til at beslutningstakere kan forstå hvilke påstander de spesifikke evalueringene underbygger, hvilket system som ble testet, hvordan resultatet ble fremkalt, og hvordan evaluatorer kontrollerte gyldigheten. For frontiersystemer som testes på oppgaver der agentiske evner er viktige, bør detaljene inkludere (med forbehold om eventuelle sikkerhets- eller konfidensialitetshensyn):

• Påstanden: om evalueringen sammenligner systemer, estimerer et tak for evne eller tester sikkerhetstiltak.
• Evalueringsinnhold: nok detaljer om oppgavene eller oppgavefordelingen til at lesere kan forstå hvilke ferdigheter, atferder eller feilmoduser evalueringen faktisk tester.
• Det testede systemet: modellen, resonneringsinnstillingen, verktøytilgangen, rammeverk og sikkerhetstiltakene.
• Budsjettet: turer, token, forsøk/nye forsøk, veggklokketid, inferenskostnad og der det er relevant forventet kostnad per vellykket løsning.
• Fremkallingsmetoder: valg av rammeverk brukt for å hente frem resultatet, og hvor tett det som ble testet gjenspeiler den bredere påstanden som fremsettes.
• Gyldighetskontroller: hvordan vurderere så etter reward hacking, evalueringsbevissthet, kontaminering, avslag, sandbagging og annen atferd som kunne undergrave resultatet, inkludert hvordan bekreftede tilfeller påvirket poengsetting eller tolkning.

Standarder som utelater valg av rammeverk eller gyldighetskontroller kan undervurdere hva et system kan gjøre eller overvurdere tilliten til en sikkerhetspåstand. Å bygge sterke rammeverk og fremkallingsmetoder er fortsatt et åpent forskningsområde og bør være et fokus for videre undersøkelse og investering.