Prédire le comportement des modèles avant publication en simulant le déploiement

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 dans une utilisation réelle, y compris les situations où il pourrait introduire de nouveaux risques. Cela devient encore plus important à mesure que les capacités augmentent. Dans le cadre de notre revue de sécurité avant déploiement, nous nous appuyons sur des évaluations ciblées, du red-teaming et d’autres vérifications afin de comprendre le comportement du modèle. Nous avons désormais commencé à utiliser une méthode pour simuler les déploiements de modèles avant qu’ils n’aient lieu, ce qui ajoute un signal complémentaire : un aperçu, proche d’un déploiement, de la manière 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 n’ait lieu. Nous procédons en rejouant des conversations précédentes d’une manière respectueuse de 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 sa publication, y compris si de nouveaux comportements indésirables émergent et à quelle fréquence ils peuvent apparaître.

Sur 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 publication et contribué à réduire le risque que les modèles puissent comprendre qu’ils étaient testés. Nous avons également appliqué la méthode à des lancements agentiques difficiles, montrant qu’elle peut dépasser le chat standard pour s’étendre à des environnements d’agents 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 des modèles pour identifier 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 des modèles.

Les évaluations préalables au déploiement utilisées dans le secteur consistent généralement en un mélange de prompts synthétiques, rédigés manuellement ou issus de la production, sélectionnés intentionnellement pour être difficiles, très sévères ou adversariaux. Ces évaluations ont généralement eu deux objectifs liés : évaluer comment le modèle répond lorsqu’il est soumis à des tests de résistance dans des situations ayant une très faible probabilité d’apparaître 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 leur fréquence au moment du déploiement.

Si les évaluations traditionnelles restent cruciales pour le premier objectif, la Simulation de déploiement représente une avancée importante pour le second en ce qui concerne les risques non marginaux (dans nos expériences, notre approche ne peut pas être censée mesurer 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 centraux des évaluations traditionnelles :

• Couverture : il est difficile d’avoir confiance dans le fait que les prompts d’évaluation couvriront tous les types possibles de comportements indésirables du modèle. Mesurer de nouveaux types de comportements indésirables nécessite 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 saturer avec le temps.
• Biais de sélection : les évaluations traditionnelles sont généralement construites en gardant à l’esprit des comportements indésirables précis du modèle, sélectionnés de façon à favoriser les contextes déjà observés. Cela peut rendre leurs estimations moins informatives sur l’incidence de tels comportements dans toute l’étendue de la distribution de déploiement.
• Reconnaissance comme 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 fausser leur comportement et nos mesures ultérieures de leur sécurité. Même si 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 le secteur.

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 d’échec, et estimons la fréquence des comportements indésirables au moment du déploiement à partir de leur fréquence dans cette distribution proche d’un déploiement. Nous pouvons effectuer les mêmes mesures après publication sur le trafic réel de déploiement, ce qui nous permet de valider nos prévisions avant déploiement.

La Simulation de déploiement atténue nettement les trois limites énumérées ci-dessus : le biais d’échantillonnage est traité en utilisant une distribution de prompts d’évaluation représentative de l’usage récent. La Simulation de déploiement avec des prompts représentatifs peut aussi atténuer les préoccupations liées à la couverture : nous obtenons une meilleure couverture des comportements indésirables des modèles en simulant simplement davantage de trafic. Ce compromis entre calcul et couverture est important, car il fait évoluer la qualité de cet axe de l’évaluation des risques avec le calcul, plutôt qu’avec l’effort manuel nécessaire pour construire davantage 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.

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 également 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 le désalignement et les catégories de contenu non autorisé que nous signalons dans les fiches système (par exemple, le modèle qui ment au sujet des outils ou qui produit du contenu sexuel non autorisé). Bien que, pour ces résultats, nous ne suivions que 20 catégories de comportements indésirables des modèles et ne recherchions 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 n’importe quelle propriété d’un modèle au moment du déploiement.

Le trafic de production que nous avons exploité provenait également de modèles Thinking de la série GPT‑5. Avant d’exécuter nos évaluations, nous avons automatiquement supprimé les identifiants liés aux comptes et les informations 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 l’amélioration des modèles. Nous ne communiquons que des résultats agrégés issus de ces évaluations. Au total, nous avons analysé environ 1,3 million de conversations désidentifiées sur les déploiements de GPT‑5 Thinking à GPT‑5.4, couvrant la période d’août 2025 à mars 2026.

Nous évaluons la qualité de l’évaluation des risques avant déploiement produite par la Simulation de déploiement de trois manières principales :

• Couverture de la taxonomie : l’audit post-publication a-t-il fait émerger 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 les comportements connus ?
• Calibration des taux : nos estimations avant déploiement étaient-elles proches des taux que nous avons observés plus tard en déploiement ? Obtenir une bonne calibration des taux exige davantage que l’exactitude directionnelle, ce qui en fait le niveau de qualité le plus élevé possible.

Nous mesurons également dans quelle mesure les modèles sont capables de savoir qu’ils sont dans une évaluation pendant la Simulation de déploiement, et testons la robustesse de la méthode face à différentes formes de trafic de déploiement et à des environnements difficiles d’utilisation d’outils.

Sur les déploiements Thinking de la série GPT‑5, la Simulation de déploiement a surpassé les références à prompts difficiles pour déterminer le taux de risque réel, a pu faire émerger le piratage de calculatrice avant publication, et semblait 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étrospectives. Dans l’ensemble, nos prédictions présentaient une erreur multiplicative médiane de 1,5x (par exemple, si le taux de comportement indésirable est de 10 pour 100 k, cela correspondrait à l’estimation d’un taux de 15 ou de 6,67 pour 100 k). Bien que les erreurs de queue de notre méthode puissent être environ 10 fois plus importantes, nous pensons qu’elles peuvent être nettement réduites grâce à de nouvelles améliorations de notre pipeline de simulation, comme indiqué ci-dessous.

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 avant déploiement sont celles dont l’incidence change fortement après le déploiement du modèle (par exemple >= 1,5x). Sur ce sous-ensemble, la Simulation de déploiement est nettement meilleure que les références, à la fois pour prédire si un certain comportement indésirable augmentera ou diminuera en prévalence avec le déploiement d’un modèle (figure 3, gauche), et pour estimer son incidence exacte au moment du déploiement (figure 3, droite). Nous utilisons deux références principales : une référence Challenging Prompts, que nous utilisons actuellement pour les fiches système et les décisions de lancement, et une référence naïve consistant à utiliser les taux du déploiement précédent comme estimations pour le nouveau modèle.

Sources d’erreur de simulation dans notre pipeline. Nous avons également étudié les sources actuelles d’erreur dans notre pipeline. Plus précisément, de grandes erreurs de queue rendent le pipeline moins fiable pour les décisions de déploiement : par exemple, lorsqu’on observe une forte augmentation prédite d’un certain type de comportement indésirable, si le pipeline est connu pour produire même occasionnellement de grandes erreurs, cela fait douter du caractère fiable de l’estimation ou du fait qu’elle soit un artefact du pipeline. Il existe deux principales sources d’erreur possibles :

• Erreur de fidélité de l’environnement de rééchantillonnage : pour estimer précisément 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 avec les mêmes pipelines que ceux utilisés 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 (par exemple les recherches web ou l’interaction avec des fichiers locaux). Nous pouvons isoler l’erreur de fidélité de la simulation en comparant les prédictions issues 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 distribution des prompts : une préoccupation majeure avec la Simulation de déploiement est que le déploiement de n’importe quel modèle entraînera un changement 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 prompts en comparant les estimations lorsque nous simulons le déploiement avec des prompts récents ou avec des prompts du déploiement réalisé.

Comme le montre la figure 4, nous constatons qu’une grande partie de l’erreur de notre pipeline, en particulier pour les erreurs de queue, est actuellement due à la fidélité de la simulation. C’est une bonne nouvelle, car nous pensons que la fidélité de la simulation est généralement plus facile à améliorer que la réduction du décalage de distribution des prompts. Nous constatons également que l’erreur liée au décalage de distribution des prompts peut être réduite en utilisant les données les plus récentes du déploiement précédent. On trouvera davantage de détails dans l’article de recherche.

L’audit automatisé a trouvé 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 émerger le « piratage de calculatrice » avant publication, qui était le seul désalignement inédit que nous avons identifié dans le trafic ChatGPT analysé. Le piratage de calculatrice est une forme de reward hacking qui implique que le modèle utilise un outil de navigateur comme calculatrice tout en présentant l’action comme une recherche. Cela ne signifie pas que l’audit à grande échelle détectera chaque nouvel échec, mais cela montre pourquoi les contextes réalistes comptent : ils peuvent susciter des comportements que des ensembles d’évaluation plus étroits pourraient ne jamais faire émerger directement, même s’ils n’étaient pas présents dans le trafic original utilisé pour amorcer la simulation.

Un autre avantage de l’utilisation de contextes proches d’un déploiement est qu’ils peuvent réduire les distorsions qui apparaissent lorsque les modèles reconnaissent qu’ils sont testés. Dans des recherches antérieures, nous, ainsi que d’autres⁠(ouverture dans une nouvelle fenêtre), avons constaté que les modèles savent souvent quand 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, sur le fait qu’ils seront ou non pris. Cela pose un problème pour les évaluations d’alignement : si un modèle ne se comporte bien que parce qu’il pense être testé, comment pouvons-nous être sûrs qu’il se comportera de façon sûre une fois qu’il saura qu’il a été déployé ?

Nous montrons que la Simulation de déploiement réduit nettement les niveaux de conscience de l’évaluation manifestés par les modèles par rapport aux évaluations traditionnelles qui ne reposent pas sur des données réelles de déploiement. Nous mesurons la conscience de l’évaluation de trois manières : en demandant à un modèle de classer si une trajectoire provient de la production ou d’une évaluation, en surveillant le raisonnement détaillé (« chain-of-thought ») pour repérer des déclarations explicites indiquant qu’il est évalué pour l’alignement, ainsi que pour le metagaming⁠(ouverture dans une nouvelle fenêtre) : tout raisonnement portant sur la supervision. Le trafic de déploiement simulé correspondait étroitement au trafic réel de déploiement sur les trois mesures. Par exemple, GPT‑5.2 a qualifié le trafic réel de production de proche d’une évaluation dans 5,4 % des cas et le trafic simulé dans 5,1 % des cas, tandis que les évaluations traditionnelles (comme SWE-Bench ou MonorepoBench, principalement composées d’exemples synthétiques) étaient classées comme évaluations presque 100 % du temps.

Pour tester si la méthode pouvait s’étendre au-delà des modes de chat standard, nous avons également étudié la simulation de déploiements pour des environnements 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 comment la simulation de déploiement peut aussi être utilisée pour l’évaluation des risques dans les déploiements internes, et démontrer qu’il est possible d’obtenir une fidélité de simulation élevée même dans des environnements agentiques grâce à une simulation soigneuse des outils.

Nous avons indiqué 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 (par exemple les recherches web ou l’interaction avec des fichiers locaux).

C’est particulièrement difficile dans des environnements tels que 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. Dans cette optique, au lieu d’appliquer des appels d’outils à des systèmes en direct, nous les simulons avec un autre LLM. Nous montrons que donner à ce LLM des possibilités supplémentaires est essentiel au 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 essayait 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 %, proche du niveau de hasard de 50 %.

Comme preuve supplémentaire de fidélité de la simulation, lorsque nous simulons le trafic de raisonnement GPT‑5.4 Codex avec GPT‑5.4, les taux de désalignement sont, à peu de chose près, dans les barres d’erreur. À l’inverse, dans nos tests avant déploiement, GPT‑5.5 était plus désaligné dans la plupart des 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 autour d’eux est simulé avec une fidélité suffisante.

Une question naturelle est de savoir si les auditeurs externes peuvent obtenir certains des mêmes bénéfices 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 récentes de production d’OpenAI, mais restait informatif : les données récentes de production avaient une erreur multiplicative moyenne plus faible que WildChat (1,75× contre 2,44×), tandis que WildChat restait souvent dans une marge 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 type WildChat comme un complément prometteur à la Simulation de déploiement exécutée par les développeurs. Voir cet article de blog Alignment⁠(ouverture dans une nouvelle fenêtre) compagnon pour plus de résultats sur ce point.

La Simulation de déploiement est un complément, et non un substitut, aux évaluations adversariales, au red-teaming et à l’analyse ciblée des risques de queue. La détection de certains comportements indésirables des modèles repose sur la surveillabilité du raisonnement détaillé (« chain-of-thought ») : si les futurs modèles raisonnent de façon moins lisible, omettent des étapes clés ou apprennent à dissimuler leur intention, nous pourrions ne pas être capables de détecter ces formes de comportement indésirable. En outre, comme les données de production sont privées, les développeurs disposent actuellement d’un accès plus solide à des contextes représentatifs que les auditeurs externes. De meilleurs jeux de données publics pourraient réduire cet écart.

La Simulation de déploiement est la plus utile pour les comportements qui surviennent assez souvent pour apparaître dans les préfixes échantillonnés. Un échec qui survient une fois sur dix millions de conversations a peu de chances d’être découvert dans une exécution d’un million d’échantillons ; les évaluations adversariales, le red-teaming et l’analyse ciblée des risques de queue restent 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 constaté d’améliorations significatives de nos estimations en simulant plusieurs tours. Cela pourrait être 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, c’est-à-dire du mélange de conversations rééchantillonnées. Le trafic historique peut ne pas correspondre à la manière 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 une variation saisonnière. L’analyse présentée dans l’article complet suggère que ce problème peut être atténué en utilisant les données les plus récentes disponibles.

La simulation de déploiement est une nouvelle approche de l’évaluation des risques avant déploiement, qui aide les laboratoires de pointe et les évaluateurs à prédire comment les modèles de langage peuvent 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é, le red-teaming et les analyses ciblées existants en ajoutant une couche de prédiction plus proche de la production, capable d’améliorer les estimations du comportement en déploiement, de réduire les effets de conscience de l’évaluation et de rendre vérifiables après publication les prédictions faites avant déploiement. Utilisée aux côtés des évaluations traditionnelles, la Simulation de déploiement peut contribuer à rendre l’évaluation des risques des modèles plus réaliste, plus quantitative et plus utile pour les décisions de déploiement.