Modelgedrag vóór release voorspellen door implementatie te simuleren

Voordat labs een nieuw model uitbrengen, moeten ze niet alleen begrijpen wat het kan, maar ook hoe het zich waarschijnlijk zal gedragen in de praktijk, inclusief waar het nieuwe risico’s kan introduceren. Dit wordt nog belangrijker naarmate de capaciteiten toenemen. Als onderdeel van onze veiligheidsbeoordeling vóór implementatie gebruiken we gerichte evaluaties, red-teaming en andere controles om modelgedrag te begrijpen. We zijn nu begonnen met het gebruiken van een methode om modelimplementaties te simuleren voordat ze plaatsvinden, wat een aanvullend signaal toevoegt: een implementatieachtige preview van hoe een kandidaatmodel zich kan gedragen voordat het gebruikers bereikt.

Deployment Simulation is een methode om een toekomstige implementatie te simuleren voordat die plaatsvindt. We doen dit door eerdere gesprekken op een privacybeschermende manier opnieuw af te spelen met een nieuw kandidaatmodel. Zo kunnen we vóór release bestuderen hoe het nieuwe model reageert in realistische contexten, inclusief of er nieuw ongewenst gedrag ontstaat en hoe vaak dat kan voorkomen.

Over meerdere implementaties van Thinking-modellen uit de GPT‑5‑serie verbeterde Deployment Simulation onze schattingen van percentages ongewenst modelgedrag, hielp het nieuwe vormen van misalignment vóór release aan het licht te brengen en hielp het het risico te verminderen dat modellen konden merken dat ze werden getest. We hebben de methode ook toegepast op uitdagende agentic roll-outs, waarbij we lieten zien dat ze verder kan gaan dan standaardchat naar complexere agent-omgevingen met toolgebruik, en ook kan worden gebruikt voor risicobeoordeling vóór interne modelimplementaties.

We hebben inzichten uit Deployment Simulation al tijdens modelontwikkeling gebruikt om blinde vlekken in traditionele evaluaties te identificeren en mitigaties en implementatiebeslissingen te informeren. Naarmate we de pipeline eenvoudiger uitvoerbaar maken, verwachten we dat deze een grotere rol gaat spelen in het toekomstige proces voor modelontwikkeling.

Evaluaties vóór implementatie die in de sector worden gebruikt, bestaan doorgaans uit een mix van synthetische, handmatig geschreven of productieprompts die opzettelijk zijn geselecteerd omdat ze moeilijk, ernstig of adversarieel zijn. Deze evaluaties hadden doorgaans twee verweven doelen: beoordelen hoe het model reageert wanneer het onder druk wordt getest in situaties die zeer weinig kans hebben om in implementatieverkeer voor te komen, en een algemeen begrip krijgen van ongewenst modelgedrag, inclusief het vinden van nieuw ongewenst gedrag en het voorspellen van de frequenties daarvan tijdens implementatie.

Hoewel traditionele evaluaties cruciaal blijven voor het eerste doel, vormt Deployment Simulation een belangrijke stap vooruit voor het tweede doel bij risico’s buiten de long tail (in onze experimenten kan van onze aanpak niet worden verwacht dat die gedrag meet dat minder vaak voorkomt dan 1 op 200.000 berichten). De kracht van Deployment Simulation komt voort uit het omzeilen van enkele kernuitdagingen van traditionele evaluaties:

• Dekking: het is moeilijk om er zeker van te zijn dat evaluatieprompts alle mogelijke typen ongewenst modelgedrag dekken. Het meten van nieuwe typen ongewenst gedrag vereist het maken van nieuwe evaluaties en weten welke schade moet worden gemeten. Dit kan tijd- en arbeidsintensief zijn, en evaluaties kunnen na verloop van tijd verzadigd raken.
• Selectiebias: traditionele evaluaties worden doorgaans gebouwd met specifieke ongewenste modelgedragingen in gedachten, geselecteerd op manieren die een bias richting eerder voorgekomen contexten introduceren. Dit kan hun schattingen minder informatief maken over de incidentie van dergelijk gedrag over de volledige breedte van de implementatiedistributie.
• Herkenbaarheid als test voor modellen: modellen zijn er steeds beter toe in staat te bepalen dat ze worden getest, wat hun gedrag en onze daaropvolgende metingen van hun veiligheid kan vertekenen. Hoewel veel van de traditionele evaluaties die we bij OpenAI gebruiken ook uit productieverkeer komen en geen last hebben van dit probleem, is dit een veelvoorkomende zorg bij veel traditionele evaluaties die in de sector worden gebruikt.

De belangrijkste techniek achter Deployment Simulation is eenvoudig: we nemen recente gesprekken uit de implementatie, verwijderen het oorspronkelijke assistentantwoord van het oudere model en genereren het opnieuw met een kandidaatmodel dat zal worden uitgebracht. We evalueren de gegenereerde antwoorden door te zoeken naar nieuwe faalmodi en schatten de frequentie van ongewenst gedrag tijdens implementatie op basis van de frequentie in deze implementatieachtige distributie. We kunnen dezelfde metingen na release uitvoeren op echt implementatieverkeer, waardoor we onze voorspellingen vóór implementatie kunnen valideren.

Deployment Simulation ondervangt de drie hierboven genoemde beperkingen grotendeels: samplingbias wordt aangepakt door een distributie van evaluatieprompts te gebruiken die representatief is voor recent gebruik. Deployment Simulation met representatieve prompts kan ook zorgen over dekking beperken: we krijgen een bredere dekking van ongewenst modelgedrag door simpelweg meer verkeer te simuleren. Deze afweging tussen compute en dekking is belangrijk, omdat hierdoor de kwaliteit van dit onderdeel van risicobeoordeling opschaalt met rekenkracht, in plaats van met de handmatige inspanning die nodig is om meer evaluaties te bouwen. Modellen lijken ook geen onderscheid te kunnen maken tussen gesprekken die via deployment simulation zijn verkregen en echt implementatieverkeer.

Om Deployment Simulation te evalueren, hebben we voorspellingen vooraf geregistreerd voor de frequentie tijdens implementatie van 20 typen ongewenst gedrag voor GPT‑5.4 Thinking. We hebben ook retrospectieve studies uitgevoerd over andere implementaties van Thinking-modellen uit de GPT‑5‑serie. Het modelgedrag dat we analyseren omvat zowel misalignment als categorieën van niet-toegestane content waarover we in systeemkaarten hebben gerapporteerd (bijv. dat het model liegt over tools of niet-toegestane seksuele content genereert). Hoewel we voor deze resultaten slechts 20 categorieën ongewenst modelgedrag volgen en alleen naar nieuw misaligned gedrag zoeken, is Deployment Simulation een algemene techniek die kan worden toegepast om elke modeleigenschap tijdens implementatie te simuleren.

Het productieverkeer dat we gebruikten kwam ook van Thinking-modellen uit de GPT‑5‑serie. Voordat we onze evaluaties uitvoerden, verwijderden we automatisch accountgekoppelde identifiers en identificeerbare informatie. In overeenstemming met ons privacybeleid analyseerden we alleen ChatGPT‑verkeer van gebruikers die toestaan dat hun gegevens worden gebruikt voor modelverbeteringen. We rapporteren alleen geaggregeerde bevindingen uit deze evaluaties. In totaal analyseerden we ongeveer 1,3 miljoen gedeïdentificeerde gesprekken over implementaties van GPT‑5 Thinking tot en met GPT‑5.4, van augustus 2025 tot maart 2026.

We beoordelen de kwaliteit van de risicobeoordeling vóór implementatie die Deployment Simulation oplevert op drie hoofdmanieren:

• Taxonomiedekking: bracht auditing na release belangrijke misaligned gedragingen aan het licht die ontbraken in onze initiële taxonomie van ongewenst gedrag?
• Directionele nauwkeurigheid: voorspelde de simulatie correct of de prevalentie tijdens implementatie zou toenemen of afnemen voor bekende gedragingen?
• Kalibratie van percentages: lagen onze schattingen vóór implementatie dicht bij de percentages die we later in de implementatie waarnamen? Goede kalibratie van percentages vereist meer dan directionele nauwkeurigheid, waardoor dit de hoogst mogelijke kwaliteitsstandaard is.

We meten ook in hoeverre modellen kunnen merken dat ze zich tijdens Deployment Simulation in een evaluatie bevinden, en testen hoe robuust de methode is voor verschillende vormen van implementatieverkeer en uitdagende omgevingen met toolgebruik.

Over implementaties van Thinking-modellen uit de GPT‑5‑serie presteerde Deployment Simulation beter dan baselines met uitdagende prompts bij het bepalen van het werkelijke risicopercentage, kon het calculator hacking vóór release aan het licht brengen en leek het voor het model mogelijk niet te onderscheiden van implementatie.

Overzicht van onze voorspellingen. Zie Figuur 2 voor een visualisatie van alle voorspellingen voor implementaties van Thinking-modellen uit de GPT‑5‑serie. De voorspellingen voor GPT‑5.4 Thinking werden vooraf geregistreerd, terwijl de andere retroactieve voorspellingen waren. Geaggregeerd hadden onze voorspellingen een mediane multiplicatieve fout van 1,5x (bijv. als het percentage ongewenst gedrag 10 per 100k is, zou dit overeenkomen met een geschat percentage van 15 of 6,67 per 100k). Hoewel tailfouten van onze methode grofweg 10x groter kunnen zijn, verwachten we dat ze aanzienlijk kunnen worden verminderd met verdere verbeteringen aan onze simulatiepipeline, zoals hieronder besproken.

Voorspellingen van Deployment Simulation vergelijken met baselines. De belangrijkste categorieën om correct te schatten voor risicobeoordelingen vóór implementatie zijn die met grote veranderingen in incidentie na de implementatie van het model (bijv. >= 1,5x). Op deze subset is Deployment Simulation aanzienlijk beter dan baselines, zowel in het voorspellen of een bepaald ongewenst gedrag in prevalentie zal toe- of afnemen bij de implementatie van een model (Figuur 3, links), als in het schatten van de exacte incidentie tijdens implementatie (Figuur 3, rechts). We gebruiken twee belangrijke baselines: een baseline met Challenging Prompts die we momenteel gebruiken voor systeemkaarten en lanceringsbeslissingen, en een naïeve baseline waarbij percentages uit de vorige implementatie worden gebruikt als schattingen voor het nieuwe model.

Bronnen van simulatiefouten in onze pipeline. We hebben ook de huidige foutbronnen in onze pipeline bestudeerd. Specifiek maken grote tailfouten de pipeline minder betrouwbaar voor implementatiebeslissingen: als men bijvoorbeeld een grote voorspelde toename ziet in ongewenst gedrag van een bepaald type en bekend is dat de pipeline zelfs af en toe grote fouten maakt, roept dat twijfel op of dit een betrouwbare schatting is of een artefact van de pipeline. Er zijn twee hoofdbronnen van mogelijke fouten:

• Fout door gebrekkige getrouwheid van de resamplingomgeving: om productiepercentages nauwkeurig te schatten, moet onze simulatiepipeline zo realistisch mogelijk zijn. Dit is deels een engineeringprobleem (samplen uit het model met dezelfde pipelines die voor productieverkeer worden gebruikt), en deels een interessante uitdaging voor tools die lees-/schrijftoegang nodig hebben tot externe resources die voortdurend veranderen (bijv. webzoekopdrachten of interactie met lokale bestanden). We kunnen de simulatiegetrouwheidsfout isoleren door voorspellingen van een daadwerkelijke implementatie te vergelijken met de simulatie daarvan (dat wil zeggen: de implementatie van het al geïmplementeerde model simuleren).
• Fout door promptdistributieverschuiving: een belangrijke zorg bij Deployment Simulation is dat elke modelimplementatie een distributieverschuiving in inputs veroorzaakt, vooral als gebruikers zich aanpassen aan nieuwe modelmogelijkheden. We isoleren promptdistributiefouten door schattingen te vergelijken wanneer de implementatie wordt gesimuleerd met recente prompts versus prompts uit de gerealiseerde implementatie.

Zoals te zien is in Figuur 4, constateren we dat een groot deel van de fout in onze pipeline—vooral bij tailfouten—momenteel te wijten is aan simulatiegetrouwheid. Dit is goed nieuws, omdat we verwachten dat simulatiegetrouwheid over het algemeen makkelijker te verbeteren is dan het verminderen van promptdistributieverschuiving. We constateren ook dat de fout door promptdistributieverschuiving kan worden verminderd door de meest recente gegevens uit de vorige implementatie te gebruiken. Meer details zijn te vinden in het onderzoekspaper.

Geautomatiseerde auditing vond de enige nieuwe misalignment die in deze implementaties werd geïntroduceerd. In het implementatievenster dat we bestudeerden, zou onze geautomatiseerde auditingpipeline op basis van gesimuleerde implementaties ‘calculator hacking’ vóór release aan het licht hebben gebracht, wat de enige nieuwe misalignment was die we in het geanalyseerde ChatGPT‑verkeer identificeerden. Calculator hacking is een vorm van reward hacking waarbij het model een browsertool als rekenmachine gebruikt terwijl het de actie presenteert als een zoekopdracht. Dit betekent niet dat auditing op grote schaal elke nieuwe fout zal vangen, maar het laat zien waarom realistische contexten ertoe doen: ze kunnen gedragingen uitlokken die smallere evaluatiesets mogelijk nooit direct aan het licht brengen, zelfs als ze niet aanwezig waren in het oorspronkelijke verkeer waarmee de simulatie werd gevoed.

Een ander voordeel van het gebruik van implementatieachtige contexten is dat ze vertekeningen kunnen verminderen die ontstaan wanneer modellen herkennen dat ze worden getest. In eerder onderzoek hebben wij en ook anderen⁠(opent in een nieuw venster) vastgesteld dat modellen zich vaak bewust zijn van wanneer ze worden getest. Modellen kunnen bijvoorbeeld in hun chain-of-thought redeneren over waarop ze worden getest, wat een evaluator mogelijk wil, en – als ze zich misdragen – of ze betrapt zullen worden. Dit vormt een probleem voor alignment-evaluaties: als een model zich alleen goed gedraagt omdat het denkt dat het wordt getest, hoe krijgen we dan vertrouwen dat het zich veilig zal gedragen zodra het leert dat het is geïmplementeerd?

We laten zien dat Deployment Simulation de niveaus van evaluatiebewustzijn die modellen vertonen aanzienlijk verlaagt ten opzichte van traditionele evaluaties die niet op echte implementatiegegevens zijn gebaseerd. We meten evaluatiebewustzijn op drie manieren: door een model te vragen te classificeren of een traject uit productie of uit een evaluatie kwam, door chain-of-thought te monitoren op expliciete uitspraken over alignment-evaluatie, en op metagaming⁠(opent in een nieuw venster): elke redenering over toezicht. Gesimuleerd implementatieverkeer kwam op alle drie de metingen nauw overeen met echt implementatieverkeer. GPT‑5.2 labelde bijvoorbeeld echt productieverkeer in 5,4% van de gevallen als evaluatieachtig en gesimuleerd verkeer in 5,1% van de gevallen, terwijl traditionele evaluaties (zoals SWE-Bench of MonorepoBench, die voornamelijk uit synthetische voorbeelden bestaan) bijna 100% van de tijd als evaluaties werden geclassificeerd.

Om te testen of de methode verder kon gaan dan standaard chatmodi, bestudeerden we ook het simuleren van implementaties voor uitdagende omgevingen voor agentic programmeren. Specifiek gebruiken we 120.000 interne agentic trajecten van medewerkers uit GPT‑5.4 om de interne implementatie van coding agents op basis van GPT‑5.5 te simuleren. Dit dient twee doelen: het laat zien hoe deployment simulation ook kan worden gebruikt voor risicobeoordeling van interne implementaties, en het toont aan dat het mogelijk is om hoge simulatiegetrouwheid te bereiken, zelfs in agentic omgevingen, via zorgvuldige toolsimulatie.

Hierboven bespraken we dat simulatiegetrouwheid een van de belangrijkste foutbronnen in onze huidige pipeline is. Een van de uitdagingen bij het realistisch maken van implementatiesimulaties is dat tools zich realistisch moeten gedragen, zelfs wanneer ze lees-/schrijftoegang nodig hebben tot externe resources die voortdurend veranderen (bijv. webzoekopdrachten of interactie met lokale bestanden).

Dit is vooral uitdagend voor omgevingen zoals agentic implementaties: één enkel agent-traject kan afhangen van honderden toolcalls, repository-status, netwerkreacties of tijdelijke storingen. Dit maakt opnieuw samplen met echte tooltoegang zowel uitdagend als potentieel gevaarlijk. Daarom simuleren we toolcalls met een andere LLM in plaats van ze toe te passen op live systemen. We laten zien dat het geven van extra affordances aan deze LLM essentieel is voor realisme en daarmee voor de kwaliteit van de schatting.

We geven het tool-simulator-model de oorspronkelijke rollout in de laatste beurt, de repository van het moment van het gesprek, een database met toolcall-/antwoordparen en alleen-lezen connectors. In een test waarin een discriminator probeerde gesimuleerde rollouts van echte rollouts te onderscheiden, verbeterde het realisme van een winpercentage van 11,6% naar 49,5%, dicht bij het kansniveau van 50%.

Als extra bewijs voor simulatiegetrouwheid liggen de misalignmentpercentages, bij het simuleren van GPT‑5.4 Codex thinking-verkeer met GPT‑5.4, nagenoeg binnen de foutmarges. Daarentegen was GPT‑5.5 in onze tests vóór implementatie in de meeste categorieën meer misaligned.

Deze resultaten suggereren dat Deployment Simulation kan worden uitgebreid naar complexe agent-omgevingen wanneer de omringende toolomgeving met voldoende getrouwheid wordt gesimuleerd.

Een logische vraag is of externe auditors enkele van dezelfde voordelen kunnen krijgen zonder toegang tot privé-productieverkeer. We testten dit met 100.000 WildChat-gesprekken die als prefixes werden gebruikt. WildChat was minder nauwkeurig dan recente productiegegevens van OpenAI, maar nog steeds informatief: recente productiegegevens hadden een lagere gemiddelde multiplicatieve fout dan WildChat (1,75× versus 2,44×), terwijl WildChat vaak binnen grofweg 3× van productiepercentages bleef en vaker dan op basis van toeval het betere model identificeerde. We zien evaluaties in WildChat-stijl als een veelbelovende aanvulling op Deployment Simulation die door ontwikkelaars wordt uitgevoerd. Zie deze begeleidende Alignment-blogpost⁠(opent in een nieuw venster) voor meer resultaten over dit punt.

Deployment Simulation is een aanvulling op, geen vervanging voor, adversariële evaluaties, red-teaming en gerichte tailrisicoanalyse. De detectie van sommige ongewenste modelgedragingen steunt op monitorbaarheid van chain-of-thought: als toekomstige modellen minder leesbaar redeneren, belangrijke stappen weglaten of leren intenties te verhullen, kunnen we deze vormen van ongewenst gedrag mogelijk niet detecteren. Bovendien hebben ontwikkelaars, omdat productiegegevens privé zijn, momenteel betere toegang tot representatieve contexten dan externe auditors. Betere openbare datasets zouden die kloof kunnen verkleinen.

Deployment Simulation is het nuttigst voor gedragingen die vaak genoeg voorkomen om in gesamplede prefixes te verschijnen. Een fout die één keer per tien miljoen gesprekken voorkomt, wordt waarschijnlijk niet ontdekt in een run met een miljoen samples, dus adversariële evaluaties, red-teaming en gerichte tailrisicoanalyse blijven noodzakelijk. We richten ons momenteel op het simuleren van één enkel assistentantwoord, omdat we in voorlopige experimenten geen betekenisvolle verbeteringen in onze schattingen vonden door meerdere beurten te simuleren. Dit kan in de toekomst een belangrijk gebied zijn om de simulatiegetrouwheid te verbeteren.

De methode hangt ook af van de prefixdistributie—de mix van gesprekken die opnieuw worden gesampled. Historisch verkeer komt mogelijk niet overeen met hoe gebruikers omgaan met een capabeler model na een grote productwijziging, nieuwe toolrelease, wereldgebeurtenis of seizoensverschuiving. Analyse in het volledige paper suggereert dat dit probleem kan worden beperkt door de meest recente beschikbare gegevens te gebruiken.

Deployment Simulation is een nieuwe aanpak voor risicobeoordeling vóór implementatie die grensverleggende labs en evaluatoren helpt voorspellen hoe taalmodellen zich in de echte wereld kunnen gedragen en de risico’s die ze vormen al vóór implementatie te begrijpen. Het vult bestaande veiligheidsevaluaties, red-teaming en gerichte analyse aan door een voorspellingslaag toe te voegen die dichter bij productie ligt en schattingen van implementatiegedrag kan verbeteren, effecten van evaluatiebewustzijn kan verminderen en voorspellingen vóór implementatie na release controleerbaar kan maken. Samen met traditionele evaluaties kan Deployment Simulation helpen om modelrisicobeoordeling realistischer, kwantitatiever en nuttiger te maken voor implementatiebeslissingen.