Prevedere il comportamento del modello prima del rilascio simulando il deployment

Prima di rilasciare un nuovo modello, i laboratori devono comprendere non solo cosa può fare, ma anche come è probabile che si comporti nell’uso reale, compresi i casi in cui potrebbe introdurre nuovi rischi. Questo diventa ancora più importante con l’aumentare delle capacità. Nell’ambito della nostra revisione di sicurezza pre-deployment, sfruttiamo valutazioni mirate, red-teaming e altri controlli per comprendere il comportamento del modello. Abbiamo ora iniziato a usare un metodo per simulare i deployment dei modelli prima che avvengano, aggiungendo un segnale complementare: un’anteprima simile al deployment di come un modello candidato potrebbe comportarsi prima di raggiungere gli utenti.

Deployment Simulation è un metodo per simulare un deployment futuro prima che avvenga. Lo facciamo riproducendo conversazioni precedenti in modo da tutelare la privacy con un nuovo modello candidato. Questo ci consente di studiare come il nuovo modello risponde in contesti realistici prima del rilascio, incluso se emergono nuovi comportamenti indesiderati e con quale frequenza potrebbero comparire.

In diversi deployment Thinking della serie GPT‑5, Deployment Simulation ha migliorato le nostre stime dei tassi di comportamenti indesiderati del modello, ha aiutato a far emergere nuove forme di disallineamento prima del rilascio e ha contribuito a ridurre il rischio che i modelli riuscissero a capire di essere testati. Abbiamo applicato il metodo anche a rollout agentici complessi, mostrando che può estendersi oltre la chat standard a impostazioni di agente più complesse che coinvolgono l’uso di strumenti, e che può essere usato anche per la valutazione del rischio prima dei deployment interni dei modelli.

Abbiamo già usato gli insight di Deployment Simulation durante lo sviluppo dei modelli per individuare punti ciechi nelle valutazioni tradizionali e orientare mitigazioni e decisioni di deployment. Man mano che rendiamo la pipeline più facile da eseguire, ci aspettiamo che svolga un ruolo più ampio nel futuro processo di sviluppo dei modelli.

Le valutazioni pre-deployment usate nel settore consistono in genere in una combinazione di prompt sintetici, scritti manualmente o di produzione, selezionati intenzionalmente perché difficili, ad alta gravità o avversariali. Queste valutazioni hanno generalmente avuto due obiettivi intrecciati: valutare come il modello risponde quando viene sottoposto a stress test in situazioni con probabilità molto bassa di verificarsi nel traffico di deployment, e ottenere una comprensione generale dei comportamenti indesiderati del modello, inclusa l’individuazione di nuovi comportamenti indesiderati e la previsione delle loro frequenze al momento del deployment.

Sebbene le valutazioni tradizionali restino cruciali per il primo obiettivo, Deployment Simulation rappresenta un passo avanti significativo rispetto al secondo obiettivo per i rischi non di coda (nei nostri esperimenti, non ci si può aspettare che il nostro approccio misuri comportamenti che si verificano con frequenza inferiore a 1 messaggio su 200.000). La forza di Deployment Simulation deriva dall’aggirare alcune sfide centrali delle valutazioni tradizionali:

• Copertura: è difficile avere la certezza che i prompt di valutazione coprano tutti i possibili tipi di comportamento indesiderato del modello. Misurare nuovi tipi di comportamento indesiderato richiede di creare nuove valutazioni e di sapere quali danni misurare. Questo può richiedere molto tempo e lavoro, e le valutazioni possono saturarsi nel tempo.
• Bias di selezione: le valutazioni tradizionali sono generalmente costruite tenendo a mente specifici comportamenti indesiderati del modello, selezionati in modi che creano bias verso contesti già verificatisi in precedenza. Questo può rendere le loro stime meno informative sull’incidenza di tali comportamenti nell’intera ampiezza della distribuzione di deployment.
• Riconoscibilità come test da parte dei modelli: i modelli sono sempre più capaci di determinare di essere testati, il che può distorcere il loro comportamento e le nostre misurazioni successive della loro sicurezza. Sebbene molte delle valutazioni tradizionali che usiamo in OpenAI provengano anch’esse dal traffico di produzione e non soffrano di questo problema, si tratta di una preoccupazione comune per molte valutazioni tradizionali usate nel settore.

La tecnica principale alla base di Deployment Simulation è semplice: prendiamo conversazioni recenti dal deployment, rimuoviamo la risposta originale dell’assistente dal modello precedente e la rigeneriamo con un modello candidato da rilasciare. Valutiamo i completamenti cercando nuove modalità di fallimento e stimiamo la frequenza dei comportamenti indesiderati al momento del deployment in base alla frequenza in questa distribuzione simile al deployment. Possiamo eseguire le stesse misurazioni dopo il rilascio sul traffico reale di deployment, consentendoci di validare le nostre previsioni pre-deployment.

Deployment Simulation mitiga significativamente le tre limitazioni elencate sopra: il bias di campionamento viene affrontato usando una distribuzione di prompt di valutazione rappresentativa dell’uso recente. Deployment Simulation con prompt rappresentativi può anche mitigare le preoccupazioni sulla copertura: otteniamo una copertura maggiore dei comportamenti indesiderabili del modello semplicemente simulando più traffico. Questo trade-off tra calcolo e copertura è importante, perché fa scalare la qualità di questo asse della valutazione del rischio con il calcolo, anziché con lo sforzo manuale necessario per costruire più valutazioni. I modelli inoltre non sembrano essere in grado di distinguere tra conversazioni ottenute tramite simulazione del deployment e traffico reale di deployment.

Per valutare Deployment Simulation, abbiamo pre-registrato previsioni per la frequenza al momento del deployment di 20 tipi di comportamento indesiderabile per GPT‑5.4 Thinking. Abbiamo anche condotto studi retrospettivi su altri deployment di modelli Thinking della serie GPT‑5. I comportamenti del modello che analizziamo coprono sia il disallineamento sia categorie di contenuti non consentiti che abbiamo riportato nelle schede di sistema (ad es. il modello che mente sugli strumenti o produce contenuti sessuali non consentiti). Sebbene per questi risultati monitoriamo solo 20 categorie di comportamento indesiderato del modello e cerchiamo solo nuovi comportamenti disallineati, Deployment Simulation è una tecnica generale che potrebbe essere applicata per simulare qualsiasi proprietà del modello al momento del deployment.

Anche il traffico di produzione che abbiamo sfruttato proveniva da modelli Thinking della serie GPT‑5. Prima di eseguire le nostre valutazioni, abbiamo rimosso automaticamente gli identificatori collegati agli account e le informazioni identificabili. In conformità con la nostra Informativa sulla privacy, abbiamo analizzato solo il traffico ChatGPT degli utenti che consentono l’uso dei loro dati per migliorare i modelli. Riportiamo solo risultati aggregati di queste valutazioni. In totale, abbiamo analizzato circa 1,3 milioni di conversazioni de-identificate tra i deployment GPT‑5 Thinking e GPT‑5.4, da agosto 2025 a marzo 2026.

Valutiamo la qualità della valutazione del rischio pre-deployment prodotta da Deployment Simulation in tre modi principali:

• Copertura della tassonomia: l’auditing post-rilascio ha fatto emergere comportamenti disallineati importanti assenti dalla nostra tassonomia iniziale dei comportamenti scorretti?
• Accuratezza direzionale: la simulazione ha previsto correttamente se la prevalenza in deployment sarebbe aumentata o diminuita per i comportamenti noti?
• Calibrazione dei tassi: le nostre stime pre-deployment erano vicine ai tassi che abbiamo osservato in seguito nel deployment? Ottenere una buona calibrazione dei tassi richiede più della sola accuratezza direzionale, rendendo questo lo standard di qualità più elevato possibile.

Misuriamo anche quanto i modelli riescano a capire di trovarsi in una valutazione durante Deployment Simulation, e testiamo quanto il metodo sia robusto rispetto a diverse forme di traffico di deployment e a contesti complessi di uso degli strumenti.

Nei deployment Thinking della serie GPT‑5, Deployment Simulation ha superato le baseline basate su prompt impegnativi nel determinare il tasso di rischio effettivo, è riuscita a far emergere il calculator hacking prima del rilascio ed è apparsa potenzialmente indistinguibile dal deployment per il modello.

Panoramica delle nostre previsioni. Per una visualizzazione di tutte le previsioni per i deployment dei modelli Thinking della serie GPT‑5, si veda la Figura 2. Le previsioni per GPT‑5.4 Thinking sono state pre-registrate, mentre le altre erano previsioni retroattive. Nel complesso, le nostre previsioni avevano un errore moltiplicativo mediano di 1,5x (ad es. se il tasso di comportamento indesiderabile è 10 su 100k, questo corrisponderebbe a stimare un tasso di 15 o 6,67 su 100k). Sebbene gli errori di coda del nostro metodo possano essere circa 10 volte più grandi, ci aspettiamo che possano essere ridotti significativamente con ulteriori miglioramenti alla nostra pipeline di simulazione, come discusso di seguito.

Confronto tra le previsioni di Deployment Simulation e le baseline. Le categorie più importanti da stimare correttamente per le valutazioni del rischio pre-deployment sono quelle che presentano grandi variazioni di incidenza dopo il deployment del modello (ad es. >= 1,5x). Su questo sottoinsieme, Deployment Simulation è sostanzialmente migliore delle baseline sia nel prevedere se un certo comportamento indesiderabile aumenterà o diminuirà di prevalenza con il deployment di un modello (Figura 3, sinistra), sia nello stimarne l’esatta incidenza al momento del deployment (Figura 3, destra). Usiamo due baseline principali: una baseline Challenging Prompts, che attualmente usiamo per le schede di sistema e le decisioni di lancio, e una baseline ingenua che usa i tassi del deployment precedente come stime per il nuovo modello.

Fonti di errore di simulazione nella nostra pipeline. Abbiamo studiato anche le attuali fonti di errore nella nostra pipeline. In particolare, errori di coda ampi rendono la pipeline meno affidabile per le decisioni di deployment: per esempio, quando si vede un grande aumento previsto in un comportamento indesiderabile di un certo tipo, se è noto che la pipeline può avere anche solo occasionalmente errori grandi, sorge il dubbio che si tratti di una stima affidabile o di un artefatto della pipeline. Ci sono due principali fonti di possibile errore:

• Errore di fedeltà dell’ambiente di ricampionamento: per stimare accuratamente i tassi di produzione, la nostra pipeline di simulazione deve essere il più realistica possibile. Questo è in parte un problema ingegneristico (campionare dal modello usando le stesse pipeline usate per il traffico di produzione) e in parte una sfida interessante per gli strumenti che necessitano di accesso in lettura/scrittura a risorse esterne in continuo cambiamento (ad es. ricerche web o interazioni con file locali). Possiamo isolare l’errore di fedeltà della simulazione confrontando le previsioni di un deployment effettivo e della sua simulazione (cioè simulando il deployment del modello già distribuito).
• Errore di spostamento della distribuzione dei prompt: una preoccupazione importante con Deployment Simulation è che il deployment di qualsiasi modello causerà uno spostamento distribuzionale negli input, soprattutto se gli utenti si adattano alle nuove possibilità offerte dal modello. Isoliamo l’errore di distribuzione dei prompt confrontando le stime quando simuliamo il deployment usando prompt recenti rispetto a prompt del deployment realizzato.

Come si vede nella Figura 4, troviamo che una grande frazione dell’errore nella nostra pipeline, soprattutto per gli errori di coda, è attualmente dovuta alla fedeltà della simulazione. Questa è una buona notizia, perché ci aspettiamo che la fedeltà della simulazione sia in generale più facile da migliorare rispetto alla riduzione dello spostamento della distribuzione dei prompt. Troviamo anche che l’errore di spostamento della distribuzione dei prompt può essere ridotto usando i dati più recenti del deployment precedente. Maggiori dettagli sono disponibili nel paper di ricerca.

L’auditing automatizzato ha trovato l’unico nuovo disallineamento introdotto in questi deployment. Nella finestra di deployment che abbiamo studiato, la nostra pipeline di auditing automatizzato basata su deployment simulati avrebbe fatto emergere il “calculator hacking” prima del rilascio, che era l’unico disallineamento nuovo identificato nel traffico ChatGPT analizzato. Il calculator hacking è una forma di reward hacking in cui il modello usa uno strumento browser come calcolatrice presentando l’azione come una ricerca. Questo non significa che l’auditing su larga scala intercetterà ogni nuovo fallimento, ma mostra perché i contesti realistici contano: possono evocare comportamenti che insiemi di valutazione più ristretti potrebbero non far mai emergere direttamente, anche se non erano presenti nel traffico originale usato per inizializzare la simulazione.

Un altro vantaggio dell’uso di contesti simili al deployment è che possono ridurre le distorsioni che sorgono quando i modelli riconoscono di essere testati. In ricerche precedenti, noi così come altri⁠(si apre in una nuova finestra) abbiamo riscontrato che i modelli sono spesso consapevoli di quando vengono testati. Per esempio, i modelli possono ragionare nella loro chain of thought su cosa viene testato, cosa potrebbe gradire un valutatore e, se si comportano male, se verranno scoperti. Questo pone un problema per le valutazioni di allineamento: se un modello si comporta bene solo perché pensa di essere testato, come possiamo acquisire fiducia che si comporterà in sicurezza una volta appreso di essere stato distribuito?

Mostriamo che Deployment Simulation riduce sostanzialmente i livelli di consapevolezza della valutazione esibiti dai modelli rispetto alle valutazioni tradizionali non basate su dati reali di deployment. Misuriamo la consapevolezza della valutazione in tre modi: chiedendo a un modello di classificare se una traiettoria proviene dalla produzione o da una valutazione, monitorando la chain of thought per affermazioni esplicite sull’essere valutato per l’allineamento, nonché per il metagaming⁠(si apre in una nuova finestra): qualsiasi ragionamento sulla supervisione. Il traffico di deployment simulato corrispondeva da vicino al traffico reale di deployment in tutte e tre le misure. Per esempio, GPT‑5.2 ha etichettato il traffico reale di produzione come simile a una valutazione nel 5,4% dei casi e il traffico simulato nel 5,1% dei casi, mentre le valutazioni tradizionali (come SWE-Bench o MonorepoBench, composte principalmente da esempi sintetici) sono state classificate come valutazioni quasi il 100% delle volte.

Per testare se il metodo potesse estendersi oltre le modalità chat standard, abbiamo studiato anche la simulazione di deployment per contesti impegnativi di coding agentico. In particolare, usiamo 120.000 traiettorie agentiche interne di dipendenti da GPT‑5.4 per simulare il deployment interno di agenti di coding basati su GPT‑5.5. Questo serve a due scopi: mostra come la simulazione del deployment possa essere usata anche per la valutazione del rischio dei deployment interni e dimostra che è possibile rendere elevata la fedeltà della simulazione anche in contesti agentici tramite un’attenta simulazione degli strumenti.

Sopra abbiamo discusso che la fedeltà della simulazione è una delle principali fonti di errore nella nostra pipeline attuale. Una delle sfide nel rendere realistiche le simulazioni di deployment è che richiede che gli strumenti agiscano in modi realistici, anche quando necessitano di accesso in lettura/scrittura a risorse esterne in continuo cambiamento (ad es. ricerche web o interazioni con file locali).

Questo è particolarmente difficile per impostazioni come i deployment agentici: una singola traiettoria di agente può dipendere da centinaia di chiamate a strumenti, dallo stato del repository, da risposte di rete o da guasti transitori. Questo rende il ricampionamento con accesso reale agli strumenti sia difficile sia potenzialmente pericoloso. Alla luce di ciò, invece di applicare chiamate a strumenti a sistemi live, le simuliamo con un altro LLM. Mostriamo che dare a questo LLM funzionalità aggiuntive è essenziale per il realismo e quindi per la qualità della stima.

Forniamo al modello simulatore di strumenti il rollout originale dell’ultimo turno, il repository al momento della conversazione, un database di coppie chiamata/risposta degli strumenti e connettori di sola lettura. In un test in cui un discriminatore ha cercato di distinguere i rollout simulati da quelli reali, il realismo è migliorato da un tasso di vittoria dell’11,6% al 49,5%, vicino al livello casuale del 50%.

Come ulteriore evidenza della fedeltà della simulazione, quando si simula il traffico GPT‑5.4 Codex thinking con GPT‑5.4, i tassi di disallineamento sono, praticamente, entro le barre di errore. Al contrario, nei nostri test pre-deployment GPT‑5.5 era più disallineato nella maggior parte delle categorie.

Questi risultati suggeriscono che Deployment Simulation può estendersi a impostazioni di agente complesse quando l’ambiente di strumenti circostante è simulato con fedeltà sufficiente.

Una domanda naturale è se gli auditor esterni possano ottenere alcuni degli stessi benefici senza accesso al traffico privato di produzione. Lo abbiamo testato con 100.000 conversazioni WildChat usate come prefissi. WildChat è stato meno accurato dei dati di produzione recenti di OpenAI, ma comunque informativo: i dati di produzione recenti avevano un errore moltiplicativo medio inferiore rispetto a WildChat (1,75× vs 2,44×), mentre WildChat spesso restava entro circa 3× dei tassi di produzione e identificava il modello migliore con tassi superiori al caso. Consideriamo le valutazioni in stile WildChat un complemento promettente a Deployment Simulation eseguita dagli sviluppatori. Per ulteriori risultati su questo punto, si veda questo post del blog Alignment⁠(si apre in una nuova finestra) di accompagnamento.

Deployment Simulation è un complemento, non un sostituto, delle valutazioni avversariali, del red-teaming e dell’analisi mirata dei rischi di coda. Il rilevamento di alcuni comportamenti indesiderati del modello si basa sulla monitorabilità della chain of thought: se i modelli futuri ragionano in modo meno leggibile, omettono passaggi chiave o imparano a oscurare l’intento, potremmo non essere in grado di rilevare queste forme di comportamento indesiderabile. Inoltre, poiché i dati di produzione sono privati, gli sviluppatori hanno attualmente un accesso più forte a contesti rappresentativi rispetto agli auditor esterni. Dataset pubblici migliori potrebbero ridurre questo divario.

Deployment Simulation è più utile per i comportamenti che si verificano abbastanza spesso da apparire nei prefissi campionati. È improbabile che un fallimento che si verifica una volta ogni dieci milioni di conversazioni venga scoperto in un’esecuzione da un milione di campioni, quindi le valutazioni avversariali, il red-teaming e l’analisi mirata dei rischi di coda restano necessari. Attualmente ci concentriamo sulla simulazione di una singola risposta dell’assistente, poiché negli esperimenti preliminari non abbiamo riscontrato miglioramenti significativi alle nostre stime simulando più turni. Questa potrebbe essere un’area importante per migliorare la fedeltà della simulazione in futuro.

Il metodo dipende anche dalla distribuzione dei prefissi: il mix di conversazioni che vengono ricampionate. Il traffico storico potrebbe non corrispondere al modo in cui gli utenti interagiscono con un modello più capace dopo un grande cambiamento di prodotto, il rilascio di un nuovo strumento, un evento mondiale o uno spostamento stagionale. L’analisi nel paper completo suggerisce che questo problema può essere mitigato usando i dati più recenti disponibili.

La simulazione del deployment è un nuovo approccio alla valutazione del rischio pre-deployment che aiuta i laboratori di frontiera e i valutatori a prevedere come i modelli linguistici potrebbero comportarsi nel mondo reale e a comprendere i rischi che pongono prima del deployment. Integra le valutazioni di sicurezza esistenti, il red-teaming e l’analisi mirata aggiungendo uno strato di previsione più simile alla produzione, che può migliorare le stime del comportamento in deployment, ridurre gli effetti di consapevolezza della valutazione e rendere verificabili dopo il rilascio le previsioni pre-deployment. Usata insieme alle valutazioni tradizionali, Deployment Simulation può contribuire a rendere la valutazione del rischio dei modelli più realistica, più quantitativa e più utile per le decisioni di deployment.