Prédire le comportement des modèles avant leur publication en simulant le déploiement
Utiliser des contextes de conversation réalistes pour mieux estimer les comportements indésirables des modèles avant leur publication.
Avant de publier un nouveau modèle, les laboratoires doivent comprendre non seulement ce qu’il peut faire, mais aussi comment il est susceptible de se comporter en situation réelle, y compris les nouveaux risques qu’il pourrait introduire. Cela devient encore plus important à mesure que les capacités augmentent. Dans le cadre de notre examen de sécurité préalable au déploiement, nous utilisons des évaluations ciblées, l'approche de l'équipe rouge et d’autres vérifications pour comprendre le comportement des modèles. Nous avons maintenant commencé à utiliser une méthode pour simuler les déploiements de modèles avant qu’ils aient lieu, ce qui ajoute un signal complémentaire : un aperçu de type déploiement de la façon dont un modèle candidat pourrait se comporter avant d’atteindre les utilisateurs.
La Simulation de déploiement est une méthode permettant de simuler un déploiement futur avant qu’il ait lieu. Nous le faisons en rejouant des conversations précédentes, d’une manière qui préserve la confidentialité, avec un nouveau modèle candidat. Cela nous permet d’étudier comment le nouveau modèle répond dans des contextes réalistes avant la publication, notamment si de nouveaux comportements indésirables émergent et à quelle fréquence ils pourraient apparaître.
Dans plusieurs déploiements Thinking de la série GPT‑5, la Simulation de déploiement a amélioré nos estimations des taux de comportements indésirables des modèles, aidé à faire émerger de nouvelles formes de désalignement avant la publication et contribué à réduire le risque que les modèles puissent savoir qu’ils étaient testés. Nous avons aussi appliqué la méthode à des déploiements agentiques difficiles, montrant qu’elle peut aller au-delà du clavardage standard vers des environnements d’agent plus complexes impliquant l’utilisation d’outils, et qu’elle peut aussi servir à l’évaluation des risques avant des déploiements internes de modèles.
Nous avons déjà utilisé les enseignements de la Simulation de déploiement pendant le développement de modèles pour repérer les angles morts des évaluations traditionnelles et éclairer les mesures d’atténuation ainsi que les décisions de déploiement. À mesure que nous rendons le pipeline plus facile à exécuter, nous nous attendons à ce qu’il joue un rôle plus important dans le futur processus de développement de modèles.
Les évaluations préalables au déploiement utilisées dans l’industrie consistent généralement en un mélange d’invites synthétiques, rédigées manuellement ou issues de la production, choisies délibérément parce qu’elles sont difficiles, très graves ou contreproductives. Ces évaluations ont généralement eu deux objectifs entremêlés : évaluer la façon dont le modèle répond lorsqu’il est soumis à des tests de résistance dans des situations très peu susceptibles de se produire dans le trafic de déploiement, et acquérir une compréhension générale des comportements indésirables du modèle, notamment en trouvant de nouveaux comportements indésirables et en prédisant leurs fréquences au moment du déploiement.
Même si les évaluations traditionnelles demeurent essentielles pour le premier objectif, la Simulation de déploiement représente une avancée importante pour le second objectif dans le cas des risques non extrêmes (dans nos expériences, on ne peut pas s’attendre à ce que notre approche mesure des comportements dont la fréquence est inférieure à 1 message sur 200 000). La force de la Simulation de déploiement vient du fait qu’elle contourne certains défis fondamentaux des évaluations traditionnelles :
- Couverture : il est difficile d’être certain que les invites d’évaluation couvriront tous les types possibles de comportements indésirables du modèle. Mesurer de nouveaux types de comportements indésirables exige de créer de nouvelles évaluations et de savoir quels préjudices mesurer. Cela peut demander beaucoup de temps et de travail, et les évaluations peuvent se saturer avec le temps.
- Biais de sélection : les évaluations traditionnelles sont généralement conçues en fonction de comportements indésirables précis du modèle, sélectionnés de manières qui favorisent des contextes déjà observés. Cela peut rendre leurs estimations moins informatives quant à l’incidence de tels comportements dans toute l’étendue de la distribution de déploiement.
- Reconnaissables comme des tests par les modèles : les modèles sont de plus en plus capables de déterminer qu’ils sont testés, ce qui peut déformer leur comportement et nos mesures en aval de leur sécurité. Bien que bon nombre des évaluations traditionnelles que nous utilisons chez OpenAI proviennent aussi du trafic de production et ne souffrent pas de ce problème, il s’agit d’une préoccupation courante pour de nombreuses évaluations traditionnelles utilisées dans l’industrie.
La principale technique derrière la Simulation de déploiement est simple : nous prenons des conversations récentes issues du déploiement, retirons la réponse originale de l’assistant provenant de l’ancien modèle, puis la régénérons avec un modèle candidat à publier. Nous évaluons les complétions en recherchant de nouveaux modes de défaillance, puis estimons la fréquence des comportements indésirables au moment du déploiement d’après leur fréquence dans cette distribution de type déploiement. Nous pouvons effectuer les mêmes mesures après la publication sur le trafic réel de déploiement, ce qui nous permet de valider nos prévisions préalables au déploiement.
La Simulation de déploiement atténue considérablement les trois limites énumérées ci-dessus : le biais d’échantillonnage est traité en utilisant une distribution d’invites d’évaluation représentative de l’utilisation récente. La Simulation de déploiement avec des invites représentatives peut aussi atténuer les préoccupations de couverture : nous obtenons une meilleure couverture des comportements indésirables du modèle simplement en simulant davantage de trafic. Ce compromis entre calcul et couverture est important, car il fait évoluer la qualité de cet axe d’évaluation des risques avec le calcul, plutôt qu’avec l’effort manuel nécessaire pour créer plus d’évaluations. Les modèles ne semblent pas non plus capables de distinguer les conversations obtenues par simulation de déploiement du trafic réel de déploiement.
Figure 1 : Aperçu de notre pipeline de Simulation de déploiement
Domaine | Évaluations traditionnelles | Simulation de déploiement |
Couverture | Meilleures pour les risques de faible prévalence, mais de grande gravité, dont nous voulons nous assurer la couverture | Meilleure pour comprendre l’éventail des risques que nous sommes susceptibles de voir dans le trafic de déploiement |
Représentativité / biais | Axées sur l’évaluation de risques passés ou prévus ciblés, même pour des comportements dont la prévalence est extrêmement faible en déploiement | Représentative des risques qui dépassent une certaine prévalence dans le trafic de déploiement actuel |
Conscience de l’évaluation | Indices de test potentiellement évidents (p. ex. avec des données synthétiques), sauf si les évaluations sont créées avec des données de déploiement | Le contexte de type déploiement semble atténuer considérablement la conscience de l’évaluation |
Effort | Les distributions d’invites et configurations personnalisées exigent beaucoup plus d’effort manuel | Exige un coût d’infrastructure ponctuel, puis réutilise les préfixes issus du déploiement et les correcteurs liés aux comportements indésirables connus |
Comparaison générale entre les évaluations traditionnelles et la Simulation de déploiement
Pour évaluer la Simulation de déploiement, nous avons préenregistré des prédictions sur la fréquence au moment du déploiement de 20 types de comportements indésirables pour GPT‑5.4 Thinking. Nous avons aussi mené des études rétrospectives sur d’autres déploiements de modèles Thinking de la série GPT‑5. Les comportements de modèles que nous analysons couvrent à la fois des catégories de désalignement et de contenu interdit que nous signalons dans les fiches système (p. ex. le modèle qui ment au sujet des outils ou qui produit du contenu sexuel interdit). Même si, pour ces résultats, nous ne suivons que 20 catégories de comportements indésirables du modèle et ne cherchons que de nouveaux comportements désalignés, la Simulation de déploiement est une technique générale qui pourrait être appliquée pour simuler toute propriété d’un modèle au moment du déploiement.
Le trafic de production que nous avons utilisé provenait aussi de modèles Thinking de la série GPT‑5. Avant d’exécuter nos évaluations, nous avons automatiquement retiré les identifiants liés aux comptes et les renseignements identifiables. Conformément à notre politique de confidentialité, nous n’avons analysé que le trafic ChatGPT des utilisateurs qui autorisent l’utilisation de leurs données pour améliorer les modèles. Nous ne rapportons que des résultats agrégés de ces évaluations. Au total, nous avons analysé environ 1,3 million de conversations dépersonnalisées couvrant les déploiements de GPT‑5 Thinking à GPT‑5.4, d’août 2025 à mars 2026.
Nous évaluons la qualité de l’évaluation des risques préalable au déploiement produite par la Simulation de déploiement de trois grandes façons :
- Couverture de la taxonomie : l’audit après publication a-t-il fait ressortir des comportements désalignés importants absents de notre taxonomie initiale des mauvais comportements?
- Exactitude directionnelle : la simulation a-t-elle correctement prédit si la prévalence au déploiement augmenterait ou diminuerait pour des comportements connus?
- Étalonnage des taux : nos estimations préalables au déploiement étaient-elles proches des taux que nous avons observés plus tard lors du déploiement? Un bon étalonnage des taux exige plus que l’exactitude directionnelle, ce qui en fait la norme de qualité la plus élevée possible.
Nous mesurons aussi dans quelle mesure les modèles peuvent savoir qu’ils sont dans une évaluation pendant la Simulation de déploiement, et nous testons la robustesse de la méthode à différentes formes de trafic de déploiement et à des contextes difficiles d’utilisation d’outils.
Dans les déploiements Thinking de la série GPT‑5, la Simulation de déploiement a surpassé les références fondées sur des invites difficiles pour déterminer le taux de risque réel, a permis de faire émerger le piratage de calculatrice avant la publication et a semblé potentiellement indiscernable d’un déploiement pour le modèle.
Aperçu de nos prédictions. Pour une visualisation de toutes les prédictions concernant les déploiements de modèles Thinking de la série GPT‑5, voir la figure 2. Les prédictions pour GPT‑5.4 Thinking ont été préenregistrées, tandis que les autres étaient des prédictions rétroactives. Dans l’ensemble, nos prédictions présentaient une erreur multiplicative médiane de 1,5x (p. ex. si le taux de comportements indésirables est de 10 sur 100 k, cela correspondrait à une estimation de 15 ou de 6,67 sur 100 k). Même si les erreurs extrêmes de notre méthode peuvent être environ 10 fois plus grandes, nous pensons qu’elles peuvent être considérablement réduites grâce à d’autres améliorations de notre pipeline de simulation, comme il est expliqué ci-dessous.
Figure 2. Prédictions de fréquence de la Simulation de déploiement pour les comportements indésirables au moment du déploiement, fondées sur des données de déploiement antérieures. La notation 5.1 → 5 indique que nous échantillonnons à nouveau des préfixes de GPT‑5 avec GPT‑5.1, c’est-à-dire que nous simulons le déploiement de GPT‑5.1 à partir de données de GPT‑5. Le taux le plus élevé de comportement mal aligné était le « piratage de calculatrice » dans GPT‑5.1, dont nous avons discuté précédemment(s'ouvre dans une nouvelle fenêtre).
Comparaison des prédictions de la Simulation de déploiement aux références. Les catégories les plus importantes à estimer correctement pour les évaluations des risques préalables au déploiement sont celles qui présentent de grands changements d’incidence après le déploiement du modèle (p. ex. ≥ 1,5x). Dans ce sous-ensemble, la Simulation de déploiement est nettement meilleure que les références, tant pour prédire si un comportement indésirable donné augmentera ou diminuera en prévalence avec le déploiement d’un modèle (figure 3, gauche) que pour estimer son incidence exacte au moment du déploiement (figure 3, droite). Nous utilisons deux principales références : une référence d’invites difficiles que nous utilisons actuellement pour les fiches système et les décisions de lancement, et une référence naïve qui consiste à utiliser les taux du déploiement précédent comme estimations pour le nouveau modèle.
Figure 3. La Simulation de déploiement prédit mieux que les évaluations statiques à la fois la direction des changements d’incidence (gauche) et les taux exacts en production (droite).
Sources d’erreur de simulation dans notre pipeline. Nous avons aussi étudié les sources actuelles d’erreur dans notre pipeline. Plus précisément, les grandes erreurs extrêmes rendent le pipeline moins fiable pour les décisions de déploiement : par exemple, lorsqu’on observe une forte hausse prédite d’un comportement indésirable d’un certain type, si l’on sait que le pipeline produit même occasionnellement de grandes erreurs, cela soulève un doute quant à savoir s’il s’agit d’une estimation fiable ou d’un artefact du pipeline. Il existe deux principales sources d’erreur possibles :
- Erreur de fidélité de l’environnement de rééchantillonnage : pour estimer avec exactitude les taux de production, notre pipeline de simulation doit être aussi réaliste que possible. Il s’agit en partie d’un problème d’ingénierie (échantillonner à partir du modèle en utilisant les mêmes pipelines que pour le trafic de production), et en partie d’un défi intéressant pour les outils qui ont besoin d’un accès en lecture/écriture à des ressources externes en constante évolution (p. ex. recherches Web ou interaction avec des fichiers locaux). Nous pouvons isoler l’erreur de fidélité de simulation en comparant les prédictions d’un déploiement réel et de sa simulation (c’est-à-dire en simulant le déploiement du modèle déjà déployé).
- Erreur de décalage de la distribution des invites : une préoccupation majeure avec la Simulation de déploiement est que le déploiement de tout modèle entraînera un décalage distributionnel des entrées, surtout si les utilisateurs s’adaptent aux nouvelles possibilités offertes par le modèle. Nous isolons l’erreur de distribution des invites en comparant les estimations lorsque nous simulons le déploiement avec des invites récentes plutôt qu’avec des invites du déploiement réalisé.
Comme le montre la figure 4, nous constatons qu’une grande partie de l’erreur dans notre pipeline — surtout pour les erreurs extrêmes — est actuellement due à la fidélité de la simulation. C’est une bonne nouvelle, car nous nous attendons à ce que la fidélité de la simulation soit généralement plus facile à améliorer que la réduction du décalage de la distribution des invites. Nous constatons aussi que l’erreur de décalage de la distribution des invites peut être réduite en utilisant les données les plus récentes du déploiement précédent. On trouvera plus de détails dans l’article de recherche.
Figure 4 : La fidélité de l’environnement de rééchantillonnage semble être la plus grande source d’erreur dans nos estimations, surtout pour les erreurs les plus extrêmes.
L’audit automatisé a détecté le seul nouveau désalignement introduit dans ces déploiements. Dans la fenêtre de déploiement que nous avons étudiée, notre pipeline d’audit automatisé fondé sur des déploiements simulés aurait fait ressortir le « piratage de calculatrice » avant la publication, soit le seul nouveau désalignement que nous avons identifié dans le trafic ChatGPT analysé. Le piratage de calculatrice est une forme de piratage de récompense qui consiste pour le modèle à utiliser un outil de navigation comme calculatrice tout en présentant l’action comme une recherche. Cela ne signifie pas que l’audit à grande échelle détectera chaque nouvelle défaillance, mais cela montre pourquoi les contextes réalistes comptent : ils peuvent susciter des comportements que des ensembles d’évaluation plus étroits ne feraient peut-être jamais apparaître directement, même s’ils n’étaient pas présents dans le trafic original utilisé pour amorcer la simulation.
Un autre avantage des contextes de type déploiement est qu’ils peuvent réduire les distorsions qui surviennent lorsque les modèles reconnaissent qu’ils sont testés. Dans des recherches antérieures, nous, ainsi que d’autres(s'ouvre dans une nouvelle fenêtre), avons constaté que les modèles savent souvent lorsqu’ils sont testés. Par exemple, les modèles peuvent raisonner dans leur raisonnement détaillé (« chain-of-thought ») sur ce sur quoi ils sont testés, ce qu’un évaluateur pourrait apprécier et, s’ils se comportent mal, s’ils seront pris. Cela pose un problème pour les évaluations d’alignement : si un modèle se comporte bien uniquement parce qu’il pense être testé, comment pouvons-nous être sûrs qu’il se comportera de façon sécuritaire lorsqu’il apprendra qu’il a été déployé?
Nous montrons que la Simulation de déploiement réduit considérablement les niveaux de conscience de l’évaluation affichés par les modèles par rapport aux évaluations traditionnelles qui ne reposent pas sur des données de déploiement réelles. Nous mesurons la conscience de l’évaluation de trois façons : en demandant à un modèle de classer une trajectoire comme provenant de la production ou d’une évaluation, en surveillant le raisonnement détaillé (« chain-of-thought ») pour repérer les déclarations explicites indiquant qu’il est évalué pour l’alignement, ainsi que le métajeu(s'ouvre dans une nouvelle fenêtre) : tout raisonnement au sujet de la supervision. Le trafic de déploiement simulé correspondait étroitement au trafic réel de déploiement selon les trois mesures. Par exemple, GPT‑5.2 a étiqueté le trafic réel de production comme ressemblant à une évaluation 5,4 % du temps et le trafic simulé 5,1 % du temps, tandis que les évaluations traditionnelles (comme SWE-Bench ou MonorepoBench, composées principalement d’exemples synthétiques) ont été classées comme des évaluations presque 100 % du temps.
Figure 5. Comparaison de la conscience de l’évaluation : le trafic réel de production et le trafic simulé affichent des taux semblables pour la détection d’évaluation, la conscience verbalisée de l’évaluation d’alignement et le métajeu, tandis que les ensembles de données d’évaluation traditionnels rapportent des taux beaucoup plus élevés.
Pour vérifier si la méthode pouvait aller au-delà des modes de clavardage standard, nous avons aussi étudié la simulation de déploiements dans des contextes difficiles de programmation agentique. Plus précisément, nous utilisons 120 000 trajectoires agentiques internes d’employés issues de GPT‑5.4 pour simuler le déploiement interne d’agents de programmation fondés sur GPT‑5.5. Cela sert deux objectifs : montrer que la simulation de déploiement peut aussi être utilisée pour l’évaluation des risques des déploiements internes, et démontrer qu’il est possible d’atteindre une grande fidélité de simulation même dans des contextes agentiques grâce à une simulation prudente des outils.
Nous avons expliqué plus haut que la fidélité de la simulation est l’une des principales sources d’erreur dans notre pipeline actuel. L’un des défis pour rendre les simulations de déploiement réalistes est qu’elles exigent que les outils agissent de façon réaliste, même lorsqu’ils ont besoin d’un accès en lecture/écriture à des ressources externes en constante évolution (p. ex. recherches Web ou interaction avec des fichiers locaux).
C’est particulièrement difficile dans des contextes comme les déploiements agentiques : une seule trajectoire d’agent peut dépendre de centaines d’appels d’outils, de l’état d’un dépôt, de réponses réseau ou de défaillances transitoires. Cela rend le rééchantillonnage avec un accès réel aux outils à la fois difficile et potentiellement dangereux. Compte tenu de cela, au lieu d’appliquer les appels d’outils à des systèmes en direct, nous les simulons avec un autre LLM. Nous montrons qu’il est essentiel de donner des possibilités supplémentaires à ce LLM pour assurer le réalisme et donc la qualité de l’estimation.
Nous donnons au modèle simulateur d’outils le déploiement original du dernier tour, le dépôt au moment de la conversation, une base de données de paires appel d’outil/réponse et des connecteurs en lecture seule. Dans un test où un discriminateur tentait de distinguer les déploiements simulés des déploiements réels, le réalisme est passé d’un taux de victoire de 11,6 % à 49,5 %, près du niveau de hasard de 50 %.
Figure 6 : On peut rendre le réalisme du rééchantillonnage presque indiscernable de l’échantillonnage réel, même dans des contextes très axés sur les outils, lorsque les appels d’outils sont simulés avec des possibilités accrues.
Comme preuve supplémentaire de fidélité de simulation, lorsque nous simulons le trafic de raisonnement GPT‑5.4 Codex avec GPT‑5.4, les taux de désalignement sont, à peu près, dans les marges d’erreur. À l’inverse, dans nos tests préalables au déploiement, GPT‑5.5 était plus désaligné dans la plupart des catégories.
Figure 7 : Avec la simulation d’outils, les taux de comportement pour les conversations rééchantillonnées avec GPT‑5.4 et le trafic de production réel de GPT‑5.4 sont assez semblables, ce qui indique une grande fidélité de l’environnement de rééchantillonnage. Consultez la fiche système GPT‑5.5(s'ouvre dans une nouvelle fenêtre) pour plus de contexte sur les catégories.
Ces résultats suggèrent que la Simulation de déploiement peut s’étendre à des environnements d’agents complexes lorsque l’environnement d’outils qui l’entoure est simulé avec une fidélité suffisante.
Une question naturelle est de savoir si les auditeurs externes peuvent obtenir certains des mêmes avantages sans accès au trafic privé de production. Nous avons testé cela avec 100 000 conversations WildChat utilisées comme préfixes. WildChat était moins précis que les données de production récentes d’OpenAI, mais demeurait informatif : les données de production récentes présentaient une erreur multiplicative moyenne plus faible que WildChat (1,75× contre 2,44×), tandis que WildChat restait souvent dans un facteur d’environ 3× des taux de production et identifiait le meilleur modèle à des taux supérieurs au hasard. Nous considérons les évaluations de style WildChat comme un complément prometteur à la Simulation de déploiement menée par les développeurs. Consultez ce billet connexe du blogue Alignment(s'ouvre dans une nouvelle fenêtre) pour obtenir plus de résultats sur ce point.
La Simulation de déploiement complète les évaluations adversariales, le red teaming et l’analyse ciblée des risques extrêmes; elle ne les remplace pas. La détection de certains comportements indésirables du modèle repose sur la possibilité de surveiller le raisonnement détaillé (« chain-of-thought ») : si les modèles futurs raisonnent de façon moins lisible, omettent des étapes clés ou apprennent à dissimuler leur intention, nous pourrions ne pas être en mesure de détecter ces formes de comportements indésirables. De plus, comme les données de production sont privées, les développeurs ont actuellement un meilleur accès à des contextes représentatifs que les auditeurs externes. De meilleurs ensembles de données publics pourraient réduire cet écart.
La Simulation de déploiement est surtout utile pour les comportements qui se produisent assez souvent pour apparaître dans les préfixes échantillonnés. Une défaillance qui survient une fois sur dix millions de conversations a peu de chances d’être découverte dans une exécution d’un million d’échantillons; les évaluations adversariales, le red teaming et l’analyse ciblée des risques extrêmes demeurent donc nécessaires. Nous nous concentrons actuellement sur la simulation d’une seule réponse de l’assistant, car dans des expériences préliminaires, nous n’avons pas observé d’améliorations significatives de nos estimations en simulant plusieurs tours. Il pourrait s’agir d’un axe important pour améliorer la fidélité de la simulation à l’avenir.
La méthode dépend aussi de la distribution des préfixes, soit le mélange de conversations qui sont rééchantillonnées. Le trafic historique pourrait ne pas correspondre à la façon dont les utilisateurs interagissent avec un modèle plus capable après un changement majeur de produit, le lancement d’un nouvel outil, un événement mondial ou un changement saisonnier. L’analyse présentée dans l’article complet suggère que ce problème peut être atténué en utilisant les données disponibles les plus récentes.
La simulation de déploiement est une nouvelle approche d’évaluation des risques préalable au déploiement qui aide les laboratoires de pointe et les évaluateurs à prédire comment les modèles de langage pourraient se comporter dans le monde réel et à comprendre les risques qu’ils posent avant le déploiement. Elle complète les évaluations de sécurité existantes, le red teaming et les analyses ciblées en ajoutant une couche de prédiction plus proche de la production, qui peut améliorer les estimations du comportement au déploiement, réduire les effets de conscience de l’évaluation et rendre les prédictions préalables au déploiement vérifiables après la publication. Utilisée avec les évaluations traditionnelles, la Simulation de déploiement peut aider à rendre l’évaluation des risques des modèles plus réaliste, plus quantitative et plus utile pour les décisions de déploiement.


