Förutse modellbeteenden före driftsättning genom att simulera driftsättningen

Innan en ny modell lanseras behöver utvecklare förstå både vad modellen kan göra och hur den sannolikt kommer att bete sig i praktiken, inklusive vilka nya risker den kan medföra. Det blir allt viktigare i takt med att modellernas förmågor utvecklas. Som en del av säkerhetsgranskningen inför driftsättning använder vi riktade utvärderingar, red teaming och andra kontroller för att förstå modellens beteende. Vi har nu även börjat använda en metod för att simulera driftsättningar innan de sker. Den ger ytterligare en signal: en förhandsbild av hur en kandidatmodell kan komma att bete sig vid driftsättning innan den når användarna.

Deployment Simulation är en metod för att simulera en framtida driftsättning innan den sker. Det gör vi genom att, på ett integritetsskyddande sätt, återspela tidigare konversationer med en ny kandidatmodell. På så sätt kan vi undersöka hur den nya modellen reagerar i realistiska användningssituationer innan den lanseras, bland annat om nya oönskade beteenden uppstår och hur ofta de förekommer.

I flera driftsättningar av GPT‑5‑seriens resonemangsmodeller gav Deployment Simulation mer träffsäkra uppskattningar av hur ofta modellerna uppvisade oönskade beteenden, hjälpte oss att upptäcka nya former av avvikande beteende före lansering och minskade risken för att modellerna skulle förstå att de testades. Vi tillämpade också metoden på krävande AI-agentsscenarier och visade att den fungerar även utanför vanliga chattinteraktioner – i mer komplexa scenarier där modellerna använder verktyg. Metoden kan dessutom användas för riskbedömningar inför interna driftsättningar av modeller.

Vi har redan använt insikter från Deployment Simulation under modellutvecklingen för att identifiera brister i traditionella utvärderingsmetoder och som underlag för åtgärder och beslut inför driftsättning. I takt med att metoden blir enklare att använda förväntar vi oss att den kommer att spela en allt större roll i framtida modellutveckling.

Säkerhetsutvärderingar som genomförs inför driftsättning består i regel av en kombination av syntetiska promptar, manuellt skrivna promptar och promptar från produktionsmiljöer som medvetet har valts ut eftersom de är svåra, innebär hög risk eller är utformade för att utmana modellen. Dessa utvärderingar har i allmänhet haft två nära sammanlänkade syften: dels att bedöma hur modellen reagerar när den utsätts för situationer som är avsedda att tänja på dess gränser men som har mycket liten sannolikhet att uppstå i verklig användning, och dels att skapa en bredare förståelse för oönskade modellbeteenden. Det omfattar bland annat att identifiera nya typer av oönskade beteenden och uppskatta hur ofta de kan förväntas uppträda efter driftsättning.

Traditionella utvärderingar är fortfarande avgörande för det första syftet. När det gäller det andra syftet innebär Deployment Simulation däremot ett betydande framsteg för risker som inte är extremt sällsynta (i våra experiment kan metoden inte förväntas mäta beteenden som förekommer mer sällan än i ett av 200 000 meddelanden). Deployment Simulations styrka ligger i att metoden kringgår några av de grundläggande begränsningarna med traditionella utvärderingar:

• Täckning: Det är svårt att vara säker på att utvärderingspromptarna täcker in alla typer av oönskade modellbeteenden. För att kunna mäta nya typer av oönskade beteenden behöver man både utveckla nya utvärderingar och veta vilka risker som ska mätas. Det kan vara både tids- och arbetskrävande, och med tiden kan utvärderingarna förlora sin effektivitet.
• Urvalsbias: Traditionella utvärderingar utformas vanligtvis med specifika oönskade modellbeteenden i åtanke och bygger därför på ett urval av situationer där sådana beteenden redan har observerats. Det kan göra dem mindre träffsäkra när det gäller att uppskatta hur ofta dessa beteenden förekommer i hela spektrumet av situationer som modellen möter efter driftsättning.
• Modeller känner igen att de testas: Modeller har blivit allt bättre på att avgöra om de utvärderas, vilket kan påverka deras beteende och därmed våra mätningar av modellernas säkerhet. Många av de traditionella utvärderingar vi använder på OpenAI bygger visserligen på data från produktionsmiljöer och påverkas därför inte av detta, men det är ett vanligt problem för många traditionella utvärderingar i branschen.

Grundprincipen bakom Deployment Simulation är enkel: Vi använder nyligen genomförda konversationer från produktionsmiljön, tar bort den ursprungliga assistentens svar från den äldre modellen och låter i stället en kandidatmodell som ännu inte har lanserats generera ett nytt svar. Därefter utvärderar vi svaren för att identifiera nya typer av oönskade beteenden och uppskattar hur ofta de kan förväntas uppstå vid driftsättning utifrån hur ofta de förekommer i den simulerade driftsättningen. Efter lanseringen kan vi göra samma mätningar på verklig produktionstrafik och på så sätt validera våra prognoser inför driftsättning.

Deployment Simulation minskar avsevärt de tre begränsningar som beskrivits ovan. Risken för ett snedvridet urval minskar genom att använda ett urval av utvärderingspromptar som speglar den senaste användningen. Genom att använda representativa promptar kan Deployment Simulation också fånga upp fler typer av oönskade modellbeteenden genom att helt enkelt simulera mer trafik. Den här avvägningen mellan beräkningsresurser och täckning är viktig, eftersom kvaliteten på den här delen av riskbedömningen kan förbättras genom ökade beräkningsresurser, i stället för genom det manuella arbete som krävs för att ta fram fler utvärderingar. Modellerna verkar dessutom inte kunna skilja mellan konversationer från Deployment Simulation och verkliga konversationer från produktionsmiljön.

För att utvärdera Deployment Simulation registrerade vi i förväg våra prognoser för hur ofta 20 typer av oönskade beteenden skulle förekomma vid driftsättningen av GPT‑5.4 Thinking. Vi genomförde också retrospektiva studier av tidigare driftsättningar av andra Thinking-modeller i GPT‑5‑serien. De modellbeteenden vi analyserar omfattar både beteenden där modellen avviker från sitt avsedda syfte och kategorier av otillåtet innehåll som vi tidigare har redovisat i våra systemkort (till exempel att modellen ljuger om sina verktyg eller genererar otillåtet sexuellt innehåll). I de här resultaten följer vi endast 20 kategorier av oönskade modellbeteenden och letar enbart efter nya beteenden där modellen avviker från sitt avsedda syfte. Deployment Simulation är dock en generell metod som kan användas för att simulera vilken modellegenskap som helst vid driftsättning.

Den produktionstrafik vi använde kom också från resonemangsmodeller i GPT‑5‑serien. Innan vi genomförde utvärderingarna tog vi automatiskt bort kontokopplade identifierare och annan identifierbar information. I enlighet med vår integritetspolicy analyserade vi endast ChatGPT‑konversationer från användare som har samtyckt till att deras data används för att förbättra modellerna. Vi redovisar endast aggregerade resultat från dessa utvärderingar. Totalt analyserade vi cirka 1,3 miljoner avidentifierade konversationer från driftsättningarna av GPT‑5 Thinking till GPT‑5.4 under perioden augusti 2025 till mars 2026.

Vi utvärderar kvaliteten på den riskbedömning före distribution som distributionssimulering ger på tre huvudsakliga sätt:

• Taxonomitäckning: visade granskningar efter lanseringen på några viktiga former av avvikande beteende som saknades i vår ursprungliga taxonomi över oönskade beteenden?
• Riktningsnoggrannhet: förutsade simuleringen korrekt om förekomsten vid distribution skulle öka eller minska för kända beteenden?
• Frekvenskalibrering: låg våra uppskattningar före distribution nära de frekvenser vi senare observerade i distributionen? Att uppnå god frekvenskalibrering kräver mer än riktningsnoggrannhet, vilket gör detta till den högsta möjliga kvalitetsstandarden.

Vi undersöker också i vilken utsträckning modellerna förstår att de utvärderas när Deployment Simulation används, och testar hur robust metoden är vid olika typer av produktionstrafik och i miljöer med omfattande verktygsanvändning.

I driftsättningar av GPT‑5‑seriens resonemangsmodeller gav Deployment Simulation bättre uppskattningar av den faktiska risknivån än jämförelsemetoder baserade på utmanande promptar, kunde identifiera ”calculator hacking” före lanseringen och verkade vara omöjlig för modellen att skilja från verklig driftsättning.

Översikt över våra prognoser. Figur 2 visar samtliga prognoser för driftsättningar av GPT‑5‑seriens resonemangsmodeller. Prognoserna för GPT‑5.4 Thinking förregistrerades, medan övriga togs fram i efterhand. Sammantaget hade våra prognoser ett medianbaserat multiplikativt fel på 1,5 gånger (om ett oönskat beteende till exempel förekommer 10 gånger per 100 000 meddelanden skulle det motsvara en uppskattning på 15 eller 6,67 per 100 000). Även om de största felen i vår metod kan vara ungefär tio gånger större bedömer vi att de kan minskas avsevärt genom fortsatta förbättringar av simuleringspipelinen, vilket vi diskuterar nedan.

Jämförelse mellan Deployment Simulations prognoser och jämförelsemetoder. De viktigaste kategorierna att uppskatta korrekt inför en riskbedömning före driftsättning är de där förekomsten förändras mest efter att modellen har driftsatts (till exempel med minst 1,5 gånger). För dessa kategorier ger Deployment Simulation betydligt bättre resultat än jämförelsemetoderna, både när det gäller att förutsäga om ett visst oönskat beteende kommer att bli vanligare eller ovanligare efter driftsättningen (figur 3, vänster) och att uppskatta hur ofta det faktiskt förekommer efter driftsättningen (figur 3, höger). Vi använder två huvudsakliga jämförelsemetoder: Challenging Prompts, som vi för närvarande använder i systemkort och som underlag för lanseringsbeslut, samt en enkel referensmetod där förekomsten i den föregående driftsättningen används som uppskattning för den nya modellen.

Felkällor i vår simuleringspipeline. Vi har också undersökt vilka felkällor som finns i den nuvarande simuleringspipelinen. Framför allt gör stora fel i extremfallen att pipeline-resultaten blir mindre tillförlitliga som underlag för beslut om driftsättning. Om pipelinen till exempel förutspår en kraftig ökning av ett visst oönskat beteende, men samtidigt är känd för att ibland ge stora fel, blir det svårt att avgöra om uppskattningen är tillförlitlig eller om den bara är ett resultat av hur pipelinen fungerar. Det finns två huvudsakliga felkällor:

• Fel som beror på hur väl simuleringen återspeglar verkligheten: För att kunna uppskatta förekomsten i produktionsmiljön korrekt behöver vår simuleringspipeline efterlikna verkliga förhållanden så nära som möjligt. Det är delvis en teknisk utmaning (att sampla modellen med samma pipeline som används för produktionstrafik) och delvis en utmaning för verktyg som behöver läs- och skrivåtkomst till externa resurser som ständigt förändras, till exempel webbsökningar eller lokala filer. Vi kan isolera den här felkällan genom att jämföra prognoser från en faktisk driftsättning med motsvarande simulering, det vill säga genom att simulera driftsättningen av en modell som redan har driftsatts.
• Fel som orsakas av förändringar i promptfördelningen: En viktig fråga när det gäller Deployment Simulation är att en ny modell kan förändra fördelningen av inkommande promptar, särskilt om användarna anpassar sig till modellens nya möjligheter. Vi kan isolera den här felkällan genom att jämföra uppskattningar som bygger på simuleringar med nyligen insamlade promptar med uppskattningar som bygger på promptar från den faktiska driftsättningen.

Som figur 4 visar beror en stor del av felen i vår pipeline – särskilt de största felen – för närvarande på hur väl simuleringen återspeglar verkligheten. Det är positivt, eftersom vi bedömer att det generellt är lättare att förbättra simuleringens realism än att minska fel som orsakas av förändringar i promptfördelningen. Vi ser också att den typen av fel kan minskas genom att använda den senaste datan från den föregående driftsättningen. Mer information finns i forskningsartikeln.

Automatiserad granskning identifierade det enda nya avvikande beteendet i dessa driftsättningar. Under den driftsättningsperiod vi undersökte skulle vår automatiserade granskningspipeline, som bygger på simulerade driftsättningar, ha identifierat ”calculator hacking” före lanseringen. Det var också det enda nya avvikande beteende som vi identifierade i den analyserade ChatGPT‑trafiken. "Calculator hacking" är en form av "reward hacking" där modellen använder ett webbläsarverktyg som miniräknare samtidigt som den framställer åtgärden som en webbsökning. Det innebär inte att storskalig automatiserad granskning kommer att upptäcka varje nytt felbeteende, men det visar varför realistiska användningssituationer är viktiga: de kan framkalla beteenden som mer begränsade utvärderingsuppsättningar aldrig fångar upp, även om de inte förekom i den ursprungliga trafiken som användes för att initiera simuleringen.

En annan fördel med att använda driftsättningsliknande användningssituationer är att de kan minska de snedvridningar som uppstår när modeller inser att de utvärderas. I tidigare forskning har både vi och andra⁠(öppnas i ett nytt fönster) forskare visat att modeller ofta är medvetna om när de testas. Modeller kan till exempel resonera i sin tankekedja om vad de testas på, vad en utvärderare vill se och – om de uppvisar oönskade beteenden – om de riskerar att bli upptäckta. Det här skapar ett problem för utvärderingar av modellanpassning: Om en modell bara beter sig väl eftersom den tror att den testas, hur kan vi då vara säkra på att den fortsätter att bete sig säkert när den inser att den har tagits i drift?

Vi visar att Deployment Simulation kraftigt minskar modellernas medvetenhet om att de utvärderas jämfört med traditionella utvärderingar som inte bygger på verkliga driftsättningsdata. Vi mäter denna medvetenhet på tre sätt: genom att be en modell avgöra om en interaktion kommer från produktionsmiljön eller från en utvärdering, genom att analysera modellens tankekedja efter uttryckliga uttalanden om att den utvärderas för modellanpassning och genom att identifiera metagaming⁠(öppnas i ett nytt fönster), det vill säga resonemang om övervakning eller utvärdering. Den simulerade driftsättningstrafiken överensstämde nära med den verkliga produktionstrafiken enligt samtliga tre mått. GPT‑5.2 klassificerade till exempel verklig produktionstrafik som utvärderingsliknande i 5,4 % av fallen och simulerad trafik i 5,1 % av fallen, medan traditionella utvärderingar (som SWE-Bench och MonorepoBench, vilka huvudsakligen består av syntetiska exempel) klassificerades som utvärderingar i nästan 100 % av fallen.

För att undersöka om metoden även fungerar utanför vanliga chattinteraktioner studerade vi också hur den fungerar för krävande AI-agentsscenarier inom kodutveckling. Närmare bestämt använde vi 120 000 interna AI-agentinteraktioner från GPT‑5.4 för att simulera den interna driftsättningen av kodningsagenter baserade på GPT‑5.5. Det fyller två syften: dels visar det hur Deployment Simulation kan användas för riskbedömningar inför interna driftsättningar, dels visar det att det går att uppnå hög simuleringsrealism även i AI-agentsscenarier genom noggrann simulering av verktyg.

Ovan diskuterade vi att simuleringstrohet är en av de huvudsakliga felkällorna i vår nuvarande pipeline. En av utmaningarna med att göra distributionssimuleringar realistiska är att det kräver att verktyg agerar på realistiska sätt, även när de behöver läs-/skrivåtkomst till externa resurser som ständigt förändras (t.ex. webbsökningar eller interaktion med lokala filer).

Detta är särskilt utmanande i AI-agentsscenarier: en enskild AI-agentinteraktion kan bero på hundratals verktygsanrop, kodarkivets aktuella tillstånd, nätverkssvar eller tillfälliga fel. Därför är det både svårt och potentiellt riskfyllt att sampla om med direkt åtkomst till verkliga verktyg. I stället för att låta verktygsanropen köras mot verkliga system simulerar vi dem med hjälp av en annan LLM. Vi visar att det är avgörande för simuleringens realism – och därmed för kvaliteten på uppskattningarna – att ge denna LLM utökade möjligheter.

För att simulera verktygen ger vi modellen tillgång till den ursprungliga körningen för den sista interaktionen, den version av kodarkivet som användes vid tidpunkten för konversationen, en databas med tidigare verktygsanrop och tillhörande svar samt kopplingar till externa resurser med läsbehörighet. I ett test där en klassificeringsmodell skulle avgöra om en interaktion var simulerad eller verklig blev simuleringen så realistisk att modellen endast lyckades skilja simulerade interaktioner från verkliga i 49,5 % av fallen – mycket nära slumpnivån på 50 %.

När vi simulerade GPT‑5.4 Codex Thinking-trafik med GPT‑5.4 låg de uppskattade nivåerna av beteenden som avvek från modellens avsedda syfte i stort sett inom felmarginalerna för de faktiska nivåerna, vilket utgör ytterligare belägg för simuleringens realism.

Resultaten tyder på att Deployment Simulation även kan användas i komplexa AI-agentsscenarier, förutsatt att den omgivande verktygsmiljön simuleras med tillräcklig realism.

En naturlig fråga är om externa granskare kan uppnå några av samma fördelarna utan tillgång till privat produktionstrafik. För att undersöka detta använde vi 100 000 WildChat-konversationer som prefix. WildChat gav mindre träffsäkra resultat än OpenAIs senaste produktionstrafik, men visade sig ändå vara användbart: den genomsnittliga multiplikativa felkvoten var lägre för den senaste produktionstrafiken än för WildChat (1,75× jämfört med 2,44×), samtidigt som WildChat ofta låg inom ungefär tre gånger de faktiska produktionsnivåerna och oftare än slumpen pekade ut den bättre modellen. Vi ser utvärderingar baserade på WildChat som ett lovande komplement till Deployment Simulation som genomförs av modellutvecklarna. Läs mer i det här kompletterande blogginlägget om Alignment⁠(öppnas i ett nytt fönster).

Deployment Simulation är ett komplement till – inte en ersättning för – utvärderingar med avsiktligt utmanande testfall, red teaming och riktade analyser av sällsynta risker. Vissa oönskade modellbeteenden kan bara upptäckas om modellens tankekedja går att följa. Om framtida modeller resonerar mindre tydligt, utelämnar viktiga steg eller lär sig att dölja sina avsikter kan det bli svårare att upptäcka sådana oönskade modellbeteenden. Eftersom produktionsdata inte är offentligt har modellutvecklare i dagsläget bättre tillgång till representativa användningssituationer än externa granskare. Offentligt tillgängliga datamängder av högre kvalitet skulle kunna minska den skillnaden.

Deployment Simulation fungerar bäst för beteenden som är tillräckligt vanliga för att förekomma i de prefix som samplas. Ett fel som bara uppstår en gång på tio miljoner konversationer kommer sannolikt inte att upptäckas i en simulering med en miljon stickprov. Därför behövs fortfarande utvärderingar med avsiktligt utmanande testfall, red teaming och riktade analyser av sällsynta risker. För närvarande simulerar vi endast ett assistantsvar, eftersom våra inledande experiment inte visade att simulering av flera interaktioner gav några meningsfulla förbättringar av träffsäkerheten i våra uppskattningar. Att simulera flera interaktioner kan dock bli en viktig del i det fortsatta arbetet med att förbättra simuleringens realism.

Metoden är också beroende av prefixfördelningen, det vill säga vilka typer av konversationer som samplas. Historisk produktionstrafik speglar inte alltid hur användare interagerar med en mer kapabel modell efter större produktförändringar, lanseringar av nya verktyg, större nyhetshändelser eller säsongsskiften. Den fullständiga forskningsartikeln tyder på att problemet kan begränsas genom att använda den senaste tillgängliga datan.

Deployment Simulation är en ny metod för riskbedömning före driftsättning som hjälper ledande AI-laboratorier och externa utvärderare att förutse hur språkmodeller kommer att bete sig efter driftsättningen och att förstå vilka risker de kan medföra redan innan de tas i drift. Metoden kompletterar befintliga säkerhetsutvärderingar, red teaming och riktade analyser genom att tillföra ett prediktionslager som bygger på användningsmönster från produktionsmiljön. Det ger bättre uppskattningar av hur modeller beter sig efter driftsättning, minskar effekterna av att modeller inser att de utvärderas och gör det möjligt att jämföra prognoser före driftsättning med det faktiska utfallet efter lanseringen. Tillsammans med traditionella utvärderingar kan Deployment Simulation göra riskbedömningar av modeller mer realistiska, mer kvantitativa och ge ett bättre beslutsunderlag inför driftsättning.