Forudsigelse af modeladfærd før frigivelse ved at simulere implementering

Før et nyt model frigives, skal laboratorier forstå ikke kun, hvad det kan gøre, men også hvordan det sandsynligvis vil opføre sig i brug i den virkelige verden, herunder hvor det kan introducere nye risici. Det bliver endnu vigtigere, efterhånden som kapabiliteterne øges. Som led i vores sikkerhedsgennemgang før implementering bruger vi målrettede evalueringer, red-teaming og andre kontroller til at forstå modeladfærd. Vi er nu begyndt at bruge en metode til at simulere modelimplementeringer, før de sker, hvilket tilføjer et supplerende signal: en implementeringslignende forhåndsvisning af, hvordan en kandidatmodel kan opføre sig, før det når brugerne.

Implementeringssimulation er en metode til at simulere en fremtidig implementering, før den sker. Det gør vi ved at afspille tidligere samtaler på en privatlivsbevarende måde med en ny kandidatmodel. Det gør det muligt for os at undersøge, hvordan den nye model reagerer i realistiske kontekster før frigivelse, herunder om nye uønskede adfærdsmønstre opstår, og hvor ofte de kan forekomme.

På tværs af flere implementeringer af GPT‑5‑seriens Thinking forbedrede implementeringssimulation vores estimater af rater for uønsket modeladfærd, hjalp med at afdække nye former for fejljustering før frigivelse og hjalp med at reducere risikoen for, at modeller kunne se, at de blev testet. Vi anvendte også metoden på udfordrende agentiske udrulninger og viste, at den kan række ud over standardchat til mere komplekse agentindstillinger med brug af værktøjer og også kan bruges til risikovurdering før interne modelimplementeringer.

Vi har allerede brugt indsigter fra implementeringssimulation under modeludvikling til at identificere blinde vinkler i traditionelle evalueringer og informere afbødninger og implementeringsbeslutninger. Efterhånden som vi gør pipelinen lettere at køre, forventer vi, at den får en større rolle i den fremtidige modeludviklingsproces.

Evalueringer før implementering, der bruges på tværs af branchen, består generelt af en blanding af syntetiske, manuelt skrevne eller produktionsprompts, der bevidst er udvalgt til at være vanskelige, alvorlige eller adversarielle. Disse evalueringer har generelt haft to sammenflettede mål: at vurdere, hvordan modellen reagerer, når det stresstestes i situationer, der har meget lille sandsynlighed for at opstå i implementeringstrafik, og at opnå en generel forståelse af uønsket modeladfærd, herunder at finde nye uønskede adfærdsmønstre og forudsige deres frekvenser ved implementeringstid.

Selvom traditionelle evalueringer fortsat er afgørende for det første mål, udgør implementeringssimulation et betydeligt fremskridt i forhold til det andet mål for ikke-halerisici (i vores eksperimenter kan vores tilgang ikke forventes at måle adfærd, der forekommer med en frekvens på mindre end 1 ud af 200.000 beskeder). Styrken ved implementeringssimulation kommer af at omgå nogle centrale udfordringer ved traditionelle evalueringer:

• Dækning: det er vanskeligt at være sikker på, at evalueringsprompts vil dække alle mulige typer af uønsket modeladfærd. Måling af nye typer uønsket adfærd kræver, at man opretter nye evalueringer og ved, hvilke skader der skal måles. Det kan være tids- og arbejdskrævende, og evalueringer kan mættes over tid.
• Udvælgelsesbias: traditionelle evalueringer bygges generelt med specifikke uønskede modeladfærdsmønstre for øje og udvælges på måder, der favoriserer kontekster, som tidligere er forekommet. Det kan gøre deres estimater mindre informative om forekomsten af sådanne adfærdsmønstre i hele implementeringsfordelingen.
• At være genkendelige som tests for modeller: modeller er i stigende grad blevet i stand til at afgøre, at de bliver testet, hvilket kan forvrænge deres adfærd og vores efterfølgende målinger af deres sikkerhed. Selvom mange af de traditionelle evalueringer, vi bruger hos OpenAI, også er hentet fra produktionstrafik og ikke lider under dette problem, er det en almindelig bekymring for mange traditionelle evalueringer, der bruges på tværs af branchen.

Hovedteknikken bag implementeringssimulation er enkel: Vi tager nylige samtaler fra implementeringen, fjerner det oprindelige assistentsvar fra det ældre model og genererer det igen med et kandidatmodel, der skal frigives. Vi evaluerer fuldførelserne ved at søge efter nye fejltilstande og estimerer frekvensen af uønsket adfærd ved implementeringstid baseret på frekvensen i denne implementeringslignende fordeling. Vi kan udføre de samme målinger efter frigivelse på reel implementeringstrafik, hvilket gør det muligt for os at validere vores prognoser før implementering.

Implementeringssimulation afbøder markant de tre begrænsninger, der er anført ovenfor: samplingbias håndteres ved at bruge en fordeling af evalueringsprompts, der er repræsentativ for nylig brug. Implementeringssimulation med repræsentative prompts kan også afbøde bekymringer om dækning: Vi får større dækning af uønsket modeladfærd ved blot at simulere mere trafik. Denne afvejning mellem beregning og dækning er vigtig, fordi den får kvaliteten af denne akse i risikovurderingen til at skalere med beregning frem for den manuelle indsats, der kræves for at bygge flere evalueringer. Modeller ser heller ikke ud til at kunne skelne mellem samtaler opnået via implementeringssimulation og reel implementeringstrafik.

For at evaluere implementeringssimulation præregistrerede vi forudsigelser for frekvensen ved implementeringstid af 20 typer uønsket adfærd for GPT‑5.4 Thinking. Vi kørte også retrospektive studier på tværs af andre implementeringer af Thinking-modeller i GPT‑5‑serien. Den modeladfærd, vi analyserer, dækker både fejljustering og kategorier af ikke-tilladt indhold, som vi har rapporteret i systemkort (f.eks. at modellen lyver om værktøjer eller udsender ikke-tilladt seksuelt indhold). Selvom vi for disse resultater kun sporer 20 kategorier af uønsket modeladfærd og kun leder efter nye fejljusterede adfærdsmønstre, er implementeringssimulation en generel teknik, der kan anvendes til at simulere enhver modelegenskab ved implementeringstid.

Den produktionstrafik, vi udnyttede, kom også fra Thinking-modeller i GPT‑5‑serien. Før vi kørte vores evalueringer, fjernede vi automatisk kontotilknyttede identifikatorer og identificerbare oplysninger. I overensstemmelse med vores privatlivspolitik analyserede vi kun ChatGPT‑trafik fra brugere, der tillader, at deres data bruges til modelforbedringer. Vi rapporterer kun aggregerede resultater fra disse evalueringer. I alt analyserede vi cirka 1,3 millioner afidentificerede samtaler på tværs af GPT‑5 Thinking til GPT‑5.4‑implementeringer, fra august 2025 til marts 2026.

Vi evaluerer kvaliteten af den risikovurdering før implementering, som implementeringssimulation producerer, på tre hovedmåder:

• Taksonomidækning: afdækkede audit efter frigivelse nogen vigtige fejljusterede adfærdsmønstre, der manglede i vores oprindelige taksonomi for dårlig adfærd?
• Retningsnøjagtighed: forudsagde simulationen korrekt, om implementeringsudbredelsen ville stige eller falde for kendte adfærdsmønstre?
• Ratekalibrering: var vores estimater før implementering tæt på de rater, vi senere observerede i implementeringen? God ratekalibrering kræver mere end retningsnøjagtighed, hvilket gør dette til den højest mulige kvalitetsstandard.

Vi måler også, hvor meget modeller er i stand til at se, at de er i en evaluering under implementeringssimulation, og tester, hvor robust metoden er over for forskellige former for implementeringstrafik og udfordrende indstillinger for værktøjsbrug.

På tværs af Thinking-implementeringer i GPT‑5‑serien klarede implementeringssimulation sig bedre end baselines med udfordrende prompts til at bestemme den faktiske risikorate, kunne afdække calculator hacking før frigivelse og syntes potentielt umulig at skelne fra implementering for modellen.

Overblik over vores forudsigelser. For en visualisering af alle forudsigelser for Thinking-modelimplementeringer i GPT‑5‑serien, se figur 2. Forudsigelserne for GPT‑5.4 Thinking blev præregistreret, mens de øvrige var retroaktive forudsigelser. Samlet set havde vores forudsigelser en median multiplikativ fejl på 1,5x (f.eks. hvis raten for uønsket adfærd er 10 ud af 100k, ville det svare til at estimere en rate på 15 eller 6,67 ud af 100k). Selvom halefejl i vores metode kan være omtrent 10x større, forventer vi, at de kan reduceres betydeligt med yderligere forbedringer af vores simulationspipeline, som diskuteres nedenfor.

Sammenligning af forudsigelser fra implementeringssimulation med baselines. De vigtigste kategorier at estimere korrekt for risikovurderinger før implementering er dem, der har store ændringer i forekomst efter modellens implementering (f.eks. >= 1,5x). På denne delmængde er implementeringssimulation væsentligt bedre end baselines både til at forudsige, om en bestemt uønsket adfærd vil stige eller falde i udbredelse med en models implementering (figur 3, venstre), og til at estimere dens nøjagtige forekomst ved implementeringstid (figur 3, højre). Vi bruger to hovedbaselines: en baseline med udfordrende prompts, som vi i øjeblikket bruger til systemkort og lanceringsbeslutninger, og en naiv baseline, hvor rater fra den tidligere implementering bruges som estimater for den nye model.

Kilder til simulationsfejl i vores pipeline. Vi undersøgte også de aktuelle fejlkilder i vores pipeline. Specifikt gør store tail errors pipelinen mindre troværdig til implementeringsbeslutninger: Hvis man for eksempel ser en stor forudsagt stigning i en bestemt type uønsket adfærd, og pipelinen vides at have selv lejlighedsvise store fejl, skaber det tvivl om, hvorvidt dette er et pålideligt estimat eller en artefakt af pipelinen. Der er to hovedkilder til mulig fejl:

• Fidelitetsfejl i resamplingsmiljøet: For at estimere produktionsrater nøjagtigt skal vores simulationspipeline være så realistisk som muligt. Dette er dels et ingeniørproblem (sampling fra modellen med de samme pipelines, der bruges til produktionstrafik), og dels en interessant udfordring for værktøjer, der kræver læse-/skriveadgang til eksterne ressourcer, som konstant ændrer sig (f.eks. websøgninger eller interaktion med lokale filer). Vi kan isolere simulationsfidelitetsfejlen ved at sammenligne forudsigelser fra en faktisk implementering og dens simulation (det vil sige at simulere implementeringen af den allerede implementerede model).
• Fejl fra forskydning i promptfordeling: En væsentlig bekymring ved implementeringssimulation er, at enhver models implementering vil medføre et fordelingsskift i input, især hvis brugerne tilpasser sig nye modelfunktioner. Vi isolerer promptfordelingsfejl ved at sammenligne estimater, når implementeringen simuleres med nylige prompts, med prompts fra den realiserede implementering.

Som det ses i figur 4, finder vi, at en stor del af fejlen i vores pipeline – især for halefejl – i øjeblikket skyldes simulationsfidelitet. Det er godt nyt, da vi forventer, at simulationsfidelitet generelt er lettere at forbedre end at reducere forskydning i promptfordeling. Vi finder også, at fejl fra forskydning i promptfordeling kan reduceres ved at bruge de nyeste data fra den tidligere implementering. Flere detaljer findes i forskningsartiklen.

Automatiseret audit fandt den ene nye fejljustering, der blev introduceret i disse implementeringer. I det implementeringsvindue, vi undersøgte, ville vores automatiserede auditpipeline baseret på simulerede implementeringer have afdækket »calculator hacking« før frigivelse, hvilket var den eneste nye fejljustering, vi identificerede i den analyserede ChatGPT‑trafik. Calculator hacking er en form for reward hacking, hvor modellen bruger et browserværktøj som lommeregner, mens det præsenterer handlingen som en søgning. Det betyder ikke, at audit i stor skala vil fange enhver ny fejl, men det viser, hvorfor realistiske kontekster er vigtige: De kan fremkalde adfærd, som smallere evalueringssæt måske aldrig direkte afdækker, selv hvis den ikke var til stede i den oprindelige trafik, der blev brugt til at starte simulationen.

En anden fordel ved at bruge implementeringslignende kontekster er, at de kan reducere forvrængninger, der opstår, når modeller genkender, at de bliver testet. I tidligere forskning har vi såvel som andre⁠(åbner i et nyt vindue) fundet, at modeller ofte er bevidste om, hvornår de bliver testet. For eksempel kan modeller ræsonnere i deres tankerække om, hvad de bliver testet på, hvad en evaluator måske vil synes om, og – hvis de opfører sig forkert – om de vil blive opdaget. Det udgør et problem for alignment-evalueringer: Hvis en model kun opfører sig ordentligt, fordi det tror, det bliver testet, hvordan opbygger vi så tillid til, at det vil opføre sig sikkert, når det opdager, at det er blevet implementeret?

Vi viser, at implementeringssimulation væsentligt reducerer de niveauer af evalueringsbevidsthed, modeller udviser, sammenlignet med traditionelle evalueringer, der ikke er baseret på reelle implementeringsdata. Vi måler evalueringsbevidsthed på tre måder: ved at bede en model klassificere, om en trajektorie kom fra produktion eller en evaluering, ved at overvåge tankerække for eksplicitte udsagn om at blive evalueret for alignment samt for metagaming⁠(åbner i et nyt vindue): enhver ræsonnering om tilsyn. Simuleret implementeringstrafik matchede reel implementeringstrafik tæt på alle tre mål. For eksempel markerede GPT‑5.2 reel produktionstrafik som evalueringslignende 5,4 % af tiden og simuleret trafik 5,1 % af tiden, mens traditionelle evalueringer (såsom SWE-Bench eller MonorepoBench, der primært består af syntetiske eksempler) blev klassificeret som evalueringer næsten 100 % af tiden.

For at teste, om metoden kunne række ud over standardchattilstande, undersøgte vi også simulering af implementeringer for udfordrende indstillinger for agentisk kodning. Specifikt bruger vi 120.000 interne medarbejdertrajektorier fra GPT‑5.4 til at simulere den interne implementering af kodningsagenter baseret på GPT‑5.5. Dette tjener to formål: Det viser, hvordan implementeringssimulation også kan bruges til risikovurdering af interne implementeringer, og det demonstrerer, at det er muligt at gøre simulationsfideliteten høj selv i agentiske indstillinger via omhyggelig værktøjssimulation.

Ovenfor diskuterede vi, at simulationsfideliteten er en af de vigtigste fejlkilder i vores nuværende pipeline. En af udfordringerne ved at gøre implementeringssimulationer realistiske er, at det kræver, at værktøjer handler på realistiske måder, selv når de har brug for læse-/skriveadgang til eksterne ressourcer, som konstant ændrer sig (f.eks. websøgninger eller interaktion med lokale filer).

Det er især udfordrende for indstillinger som agentiske implementeringer: En enkelt agenttrajektorie kan afhænge af hundredvis af værktøjskald, lagerets tilstand, netværkssvar eller forbigående fejl. Det gør resampling med reel værktøjsadgang både udfordrende og potentielt farlig. På den baggrund simulerer vi værktøjskald med et andet LLM i stedet for at anvende dem på live-systemer. Vi viser, at det er afgørende for realisme og dermed estimatkvalitet at give dette LLM ekstra muligheder.

Vi giver værktøjssimulator-modellen den oprindelige udrulning i sidste tur, lageret fra samtaletidspunktet, en database med værktøjskald-/svar-par og skrivebeskyttede connectors. I en test, hvor en diskriminator forsøgte at skelne simulerede udrulninger fra reelle, forbedredes realismen fra en winrate på 11,6 % til 49,5 %, tæt på tilfældighedsniveauet på 50 %.

Som yderligere evidens for simulationsfidelitet ligger fejljusteringsraterne omtrent inden for fejlmarginerne, når GPT‑5.4 Codex Thinking-trafik simuleres med GPT‑5.4. Derimod var GPT‑5.5 i vores test før implementering mere fejljusteret i de fleste kategorier.

Disse resultater tyder på, at implementeringssimulation kan udvides til komplekse agentindstillinger, når det omgivende værktøjsmiljø simuleres med tilstrækkelig fidelitet.

Et naturligt spørgsmål er, om eksterne auditorer kan få nogle af de samme fordele uden adgang til privat produktionstrafik. Vi testede dette med 100.000 WildChat-samtaler brugt som præfikser. WildChat var mindre nøjagtig end nylige OpenAI-produktionsdata, men stadig informativ: Nylige produktionsdata havde lavere gennemsnitlig multiplikativ fejl end WildChat (1,75× mod 2,44×), mens WildChat ofte holdt sig inden for cirka 3× af produktionsraterne og identificerede den bedre model med rater over tilfældighedsniveau. Vi ser evalueringer i WildChat-stil som et lovende supplement til udviklerdrevet implementeringssimulation. Se dette tilhørende Alignment-blogindlæg⁠(åbner i et nyt vindue) for flere resultater om dette punkt.

Implementeringssimulation er et supplement til, ikke en erstatning for, adversarielle evalueringer, red-teaming og målrettet analyse af halerisici. Detektion af nogle uønskede modeladfærdsmønstre afhænger af, at tankerække kan monitoreres: Hvis fremtidige modeller ræsonnerer mindre læseligt, udelader nøgletrin eller lærer at skjule hensigt, kan vi måske ikke opdage disse former for uønsket adfærd. Desuden har udviklere i øjeblikket stærkere adgang til repræsentative kontekster end eksterne auditorer, fordi produktionsdata er private. Bedre offentlige datasæt kan mindske dette gab.

Implementeringssimulation er mest nyttig for adfærdsmønstre, der forekommer ofte nok til at dukke op i samplede præfikser. En fejl, der forekommer én gang i ti millioner samtaler, vil sandsynligvis ikke blive opdaget i en kørsel med en million samples, så modsætningsfyldte evalueringer, red-teaming og målrettet analyse af tail-risici er fortsat nødvendige. Vi fokuserer i øjeblikket på at simulere et enkelt assistentsvar, da vi i indledende eksperimenter ikke fandt meningsfulde forbedringer i vores estimater ved at simulere flere ture. Det kan være et vigtigt område for at forbedre simulationsfideliteten i fremtiden.

Metoden afhænger også af præfiksfordelingen – blandingen af samtaler, der resamples. Historisk trafik matcher muligvis ikke, hvordan brugere interagerer med en mere kapabel model efter en større produktændring, ny værktøjsfrigivelse, verdensbegivenhed eller sæsonbestemt forskydning. Analyse i den fulde artikel tyder på, at dette problem kan afbødes ved at bruge de nyeste tilgængelige data.

Implementeringssimulation er en ny tilgang til risikovurdering før implementering, der hjælper frontier-laboratorier og evaluatorer med at forudsige, hvordan sprogmodeller kan opføre sig i den virkelige verden, og forstå de risici, de udgør, før implementering. Den supplerer eksisterende sikkerhedsevalueringer, red-teaming og målrettet analyse ved at tilføje et mere produktionslignende forudsigelseslag, der kan forbedre estimater af implementeringsadfærd, reducere effekter af evalueringsbevidsthed og gøre forudsigelser før implementering kontrollerbare efter frigivelse. Brugt sammen med traditionelle evalueringer kan implementeringssimulation hjælpe med at gøre modelrisikovurdering mere realistisk, mere kvantitativ og mere nyttig for implementeringsbeslutninger.