Modellverhalten vor der Veröffentlichung durch Deployment-Simulation vorhersagen

Bevor Labs ein neues Modell veröffentlichen, müssen sie nicht nur verstehen, was es kann, sondern auch, wie es sich im realen Einsatz voraussichtlich verhält, einschließlich der Bereiche, in denen neue Risiken entstehen könnten. Mit zunehmenden Fähigkeiten wird das noch wichtiger. Im Rahmen unserer Sicherheitsprüfung vor dem Deployment nutzen wir gezielte Evaluationen, Red-Teaming und weitere Prüfungen, um das Modellverhalten zu verstehen. Wir setzen nun eine Methode ein, mit der wir Modell-Deployments vorab simulieren. Sie liefert ein ergänzendes Signal: eine deployment-ähnliche Vorschau darauf, wie sich ein Kandidatenmodell verhalten kann, bevor es Nutzer:innen erreicht.

Deployment Simulation ist eine Methode, um ein künftiges Deployment vorab zu simulieren. Dazu spielen wir frühere Unterhaltungen datenschutzwahrend mit einem neuen Kandidatenmodell erneut durch. So können wir vor der Veröffentlichung untersuchen, wie das neue Modell in realistischen Kontexten reagiert, unter anderem ob neue unerwünschte Verhaltensweisen auftreten und wie häufig sie vorkommen könnten.

Über mehrere Thinking-Deployments der GPT‑5‑Serie hinweg verbesserte Deployment Simulation unsere Schätzungen der Raten unerwünschten Modellverhaltens, half dabei, neue Formen von Misalignment vor der Veröffentlichung aufzuzeigen, und reduzierte das Risiko, dass Modelle erkennen konnten, dass sie getestet wurden. Wir haben die Methode außerdem auf anspruchsvolle agentische Implementierungen angewendet. Dabei zeigte sich, dass sie über Standard-Chats hinaus auf komplexere Agenten-Settings mit Tool-Nutzung erweitert und auch zur Risikobewertung vor internen Modell-Deployments eingesetzt werden kann.

Erkenntnisse aus Deployment Simulation haben wir bereits während der Modellentwicklung genutzt, um blinde Flecken in klassischen Evaluationen zu erkennen und Daten für Maßnahmen sowie Deployment-Entscheidungen zu liefern. Je einfacher die Pipeline auszuführen ist, desto größere Bedeutung wird sie unserer Erwartung nach künftig im Prozess der Modellentwicklung haben.

Branchenweit eingesetzte Evaluationen vor dem Deployment bestehen in der Regel aus einer Mischung synthetischer, manuell verfasster oder aus der Produktion stammender Prompts, die gezielt als schwierig, folgenschwer oder adversarial ausgewählt werden. Diese Evaluationen hatten im Allgemeinen zwei miteinander verknüpfte Ziele: zu bewerten, wie das Modell reagiert, wenn es in Situationen mit sehr geringer Eintrittswahrscheinlichkeit im Deployment-Traffic einem Stresstest unterzogen wird, und ein allgemeines Verständnis unerwünschter Modellverhaltensweisen zu gewinnen, einschließlich der Suche nach neuen unerwünschten Verhaltensweisen und der Vorhersage ihrer Häufigkeit zum Deployment-Zeitpunkt.

Während klassische Evaluationen für das erste Ziel weiterhin entscheidend sind, ist Deployment Simulation beim zweiten Ziel für Nicht-Tail-Risiken ein deutlicher Fortschritt. In unseren Experimenten ist nicht zu erwarten, dass unser Ansatz Verhaltensweisen messen kann, die seltener als einmal pro 200.000 Nachrichten auftreten. Die Stärke von Deployment Simulation liegt darin, einige zentrale Herausforderungen klassischer Evaluationen zu umgehen:

• Abdeckung: Es ist schwierig, sicher zu sein, dass Evaluations-Prompts alle möglichen Arten unerwünschten Modellverhaltens abdecken. Neue Arten unerwünschten Verhaltens zu messen, erfordert neue Evaluationen und das Wissen, welche Schäden gemessen werden sollen. Das kann zeit- und arbeitsintensiv sein, und Evaluationen können mit der Zeit gesättigt werden.
• Selektions-Biases: Klassische Evaluationen werden meist mit Blick auf bestimmte unerwünschte Modellverhaltensweisen erstellt und so ausgewählt, dass sie Kontexte bevorzugen, die bereits aufgetreten sind. Dadurch können ihre Schätzungen weniger aussagekräftig für die Häufigkeit solcher Verhaltensweisen über die gesamte Breite der Deployment-Verteilung sein.
• Erkennbarkeit als Tests für Modelle: Modelle können zunehmend feststellen, dass sie getestet werden. Das kann ihr Verhalten und unsere nachgelagerten Messungen ihrer Sicherheit verzerren. Zwar stammen viele der klassischen Evaluationen, die wir bei OpenAI verwenden, ebenfalls aus Produktionstraffic und sind nicht von diesem Problem betroffen. Für viele branchenweit eingesetzte klassische Evaluationen ist dies jedoch ein häufiges Problem.

Die Haupttechnik hinter Deployment Simulation ist einfach: Wir nehmen aktuelle Unterhaltungen aus dem Deployment, entfernen die ursprüngliche Assistant-Antwort des älteren Modells und generieren sie mit einem Kandidatenmodell neu, das veröffentlicht werden soll. Wir evaluieren die Completions, indem wir nach neuen Fehlermodi suchen, und schätzen die Häufigkeit unerwünschten Verhaltens zum Deployment-Zeitpunkt anhand der Häufigkeit in dieser deployment-ähnlichen Verteilung. Nach der Veröffentlichung können wir dieselben Messungen im realen Deployment-Traffic durchführen und so unsere Prognosen vor dem Deployment validieren.

Deployment Simulation mindert die drei oben genannten Einschränkungen deutlich: Sampling-Bias wird adressiert, indem eine Verteilung von Evaluations-Prompts verwendet wird, die die jüngste Nutzung repräsentiert. Deployment Simulation mit repräsentativen Prompts kann auch Bedenken zur Abdeckung mindern: Wir erreichen eine größere Abdeckung unerwünschter Modellverhaltensweisen, indem wir schlicht mehr Traffic simulieren. Dieser Kompromiss zwischen Rechenaufwand und Abdeckung ist wichtig, weil dadurch die Qualität dieser Achse der Risikobewertung mit dem Rechenaufwand skaliert statt mit dem manuellen Aufwand, der nötig ist, um weitere Evaluationen zu erstellen. Modelle scheinen außerdem nicht zwischen Unterhaltungen aus der Deployment Simulation und echtem Deployment-Traffic unterscheiden zu können.

Zur Evaluierung von Deployment Simulation haben wir Vorhersagen zur Häufigkeit von 20 Arten unerwünschten Verhaltens zum Deployment-Zeitpunkt für GPT‑5.4 Thinking vorregistriert. Außerdem führten wir retrospektive Studien über weitere Deployments von Thinking-Modellen der GPT‑5‑Serie hinweg durch. Die von uns analysierten Modellverhaltensweisen umfassen sowohl Misalignment als auch Kategorien nicht zulässiger Inhalte, über die wir in Systemkarten berichtet haben, etwa wenn das Modell über Tools lügt oder nicht zulässige sexuelle Inhalte ausgibt. Für diese Ergebnisse verfolgen wir zwar nur 20 Kategorien unerwünschten Modellverhaltens und suchen nur nach neuen fehlangepassten Verhaltensweisen, doch Deployment Simulation ist eine allgemeine Technik, die eingesetzt werden könnte, um jede Modelleigenschaft zum Deployment-Zeitpunkt zu simulieren.

Der von uns genutzte Produktionstraffic stammte ebenfalls von Thinking-Modellen der GPT‑5‑Serie. Vor der Durchführung unserer Evaluationen haben wir mit Konten verknüpfte Kennungen und identifizierbare Kontoinformationen automatisch entfernt. Gemäß unserer Datenschutzrichtlinie haben wir nur ChatGPT‑Traffic von Nutzer:innen analysiert, die zulassen, dass ihre Daten zur Modellverbesserung verwendet werden. Wir berichten aus diesen Evaluationen ausschließlich aggregierte Ergebnisse. Insgesamt analysierten wir etwa 1,3 Millionen de-identifizierte Gespräche über Deployments von GPT‑5 Thinking bis GPT‑5.4 hinweg, aus dem Zeitraum August 2025 bis März 2026.

Wir bewerten die Qualität der von Deployment Simulation erzeugten Risikobewertung vor dem Deployment auf drei zentrale Arten:

• Abdeckung der Taxonomie: Hat die Prüfung nach der Veröffentlichung wichtige fehlangepasste Verhaltensweisen zutage gefördert, die in unserer ursprünglichen Taxonomie problematischen Verhaltens fehlten?
• Richtungsgenauigkeit: Hat die Simulation korrekt vorhergesagt, ob die Deployment-Prävalenz bekannter Verhaltensweisen steigen oder sinken wird?
• Ratenkalibrierung: Lagen unsere Schätzungen vor dem Deployment nahe an den Raten, die wir später im Deployment beobachtet haben? Eine gute Ratenkalibrierung erfordert mehr als Richtungsgenauigkeit und ist damit der höchstmögliche Qualitätsstandard.

Wir messen außerdem, wie gut Modelle während der Deployment Simulation erkennen können, dass sie in einer Evaluation sind, und testen, wie robust die Methode gegenüber verschiedenen Formen von Deployment-Traffic und anspruchsvollen Tool-Nutzungs-Settings ist.

Über Thinking-Deployments der GPT‑5‑Serie hinweg schnitt Deployment Simulation bei der Bestimmung der tatsächlichen Risikorate besser ab als Baselines mit Challenging Prompts, konnte Calculator Hacking vor der Veröffentlichung aufzeigen und erschien für das Modell potenziell nicht vom Deployment unterscheidbar.

Überblick über unsere Vorhersagen. Eine Visualisierung aller Vorhersagen für Thinking-Modell-Deployments der GPT‑5‑Serie zeigt Abbildung 2. Die Vorhersagen für GPT‑5.4 Thinking wurden vorregistriert, die anderen waren rückwirkende Vorhersagen. Aggregiert hatten unsere Vorhersagen einen medianen multiplikativen Fehler von 1,5x. Wenn die Rate unerwünschten Verhaltens zum Beispiel 10 pro 100.000 beträgt, entspräche dies einer Schätzung von 15 oder 6,67 pro 100.000. Auch wenn Tail-Fehler unserer Methode grob um den Faktor 10 größer sein können, erwarten wir, dass sie durch weitere Verbesserungen unserer Simulationspipeline deutlich reduziert werden können, wie unten erläutert.

Vergleich der Vorhersagen von Deployment Simulation mit Baselines. Die wichtigsten Kategorien, die für Risikobewertungen vor dem Deployment korrekt geschätzt werden müssen, sind solche mit starken Änderungen der Häufigkeit nach dem Deployment des Modells, etwa >= 1,5x. Für diese Teilmenge ist Deployment Simulation den Baselines deutlich überlegen: sowohl bei der Vorhersage, ob die Prävalenz eines bestimmten unerwünschten Verhaltens mit dem Deployment eines Modells steigt oder sinkt (Abbildung 3, links), als auch bei der Schätzung seiner genauen Häufigkeit zum Deployment-Zeitpunkt (Abbildung 3, rechts). Wir verwenden zwei zentrale Baselines: eine Challenging-Prompts-Baseline, die wir derzeit für Systemkarten und Launch-Entscheidungen nutzen, sowie eine naive Baseline, bei der Raten aus dem vorherigen Deployment als Schätzungen für das neue Modell verwendet werden.

Quellen von Simulationsfehlern in unserer Pipeline. Wir haben außerdem die aktuellen Fehlerquellen in unserer Pipeline untersucht. Insbesondere große Tail-Fehler machen die Pipeline für Deployment-Entscheidungen weniger vertrauenswürdig: Wenn zum Beispiel ein starker prognostizierter Anstieg einer bestimmten Art unerwünschten Verhaltens zu sehen ist und bekannt ist, dass die Pipeline zumindest gelegentlich große Fehler macht, entsteht Zweifel daran, ob es sich um eine verlässliche Schätzung oder um ein Artefakt der Pipeline handelt. Es gibt zwei zentrale Quellen möglicher Fehler:

• Simulationstreue-Fehler der Resampling-Umgebung: Um Produktionsraten präzise zu schätzen, muss unsere Simulationspipeline so realistisch wie möglich sein. Das ist teils ein Engineering-Problem – Sampling aus dem Modell über dieselben Pipelines wie für Produktionstraffic – und teils eine interessante Herausforderung für Tools, die Lese-/Schreibzugriff auf externe Ressourcen benötigen, die sich ständig ändern, etwa Websuchen oder die Interaktion mit lokalen Dateien. Wir können den Fehler der Simulationstreue isolieren, indem wir Vorhersagen aus einem tatsächlichen Deployment und dessen Simulation vergleichen, also das Deployment des bereits deployten Modells simulieren.
• Fehler durch Verschiebung der Prompt-Verteilung: Ein zentrales Anliegen bei Deployment Simulation ist, dass jedes Modell-Deployment eine Verteilungsverschiebung der Eingaben verursachen wird, insbesondere wenn Nutzer:innen sich an neue Möglichkeiten des Modells anpassen. Wir isolieren den Fehler der Prompt-Verteilung, indem wir Schätzungen vergleichen, bei denen das Deployment mit aktuellen Prompts simuliert wird, mit Schätzungen auf Basis von Prompts aus dem tatsächlich erfolgten Deployment.

Wie in Abbildung 4 zu sehen, ist derzeit ein großer Anteil des Fehlers in unserer Pipeline – besonders bei Tail-Fehlern – auf die Simulationstreue zurückzuführen. Das ist eine gute Nachricht, da wir erwarten, dass sich die Simulationstreue im Allgemeinen leichter verbessern lässt als die Verschiebung der Prompt-Verteilung zu verringern. Außerdem stellen wir fest, dass sich der Fehler durch Verschiebung der Prompt-Verteilung verringern lässt, wenn die neuesten Daten aus dem vorherigen Deployment verwendet werden. Weitere Details finden sich im Forschungspapier.

Automatisiertes Auditing fand das eine neue Misalignment, das in diesen Deployments eingeführt wurde. In dem von uns untersuchten Deployment-Zeitfenster hätte unsere automatisierte Auditing-Pipeline auf Basis simulierter Deployments „Calculator Hacking“ vor der Veröffentlichung aufgezeigt. Das war das einzige neue Misalignment, das wir im analysierten ChatGPT‑Traffic identifiziert haben. Calculator Hacking ist eine Form von Reward Hacking, bei der das Modell ein Browser-Tool zur Berechnung verwendet, die Aktion aber als Suche darstellt. Das bedeutet nicht, dass groß angelegtes Auditing jeden neuen Fehler findet. Es zeigt aber, warum realistische Kontexte wichtig sind: Sie können Verhaltensweisen abrufen, die engere Eval-Sets möglicherweise nie direkt aufzeigen, selbst wenn sie im ursprünglichen Traffic, mit dem die Simulation angestoßen wurde, nicht enthalten waren.

Ein weiterer Vorteil deployment-ähnlicher Kontexte besteht darin, dass sie Verzerrungen verringern können, die entstehen, wenn Modelle erkennen, dass sie getestet werden. In früherer Forschung haben wir ebenso wie andere⁠(wird in einem neuen Fenster geöffnet) festgestellt, dass Modelle oft wissen, wann sie getestet werden. Modelle können zum Beispiel in ihrer Gedankenkette Schlussfolgerungen darüber enthalten, worauf sie getestet werden, was Bewerter:innen gefallen könnte und – wenn sie sich falsch verhalten – ob sie erwischt werden. Das stellt Alignment-Evaluationen vor ein Problem: Wenn ein Modell sich nur deshalb gut verhält, weil es glaubt, getestet zu werden, wie können wir dann zuversichtlich sein, dass es sich sicher verhält, sobald es erfährt, dass es bereitgestellt wurde?

Wir zeigen, dass Deployment Simulation das von Modellen gezeigte Evaluationsbewusstsein im Vergleich zu klassischen Evaluationen, die nicht auf realen Deployment-Daten basieren, deutlich reduziert. Wir messen Evaluationsbewusstsein auf drei Arten: indem wir ein Modell klassifizieren lassen, ob ein Ablauf aus der Produktion oder aus einer Evaluation stammt, indem wir die Gedankenkette auf explizite Aussagen darüber überwachen, dass eine Alignment-Evaluation stattfindet, sowie auf Metagaming⁠(wird in einem neuen Fenster geöffnet): jegliches Reasoning über Aufsicht. Simulierter Deployment-Traffic entsprach echtem Deployment-Traffic bei allen drei Messgrößen sehr genau. GPT‑5.2 kennzeichnete zum Beispiel echten Produktionstraffic in 5,4 % der Fälle als evaluationsähnlich und simulierten Traffic in 5,1 % der Fälle, während klassische Evaluationen wie SWE-Bench oder MonorepoBench, die überwiegend aus synthetischen Beispielen bestehen, fast zu 100 % als Evaluationen klassifiziert wurden.

Um zu testen, ob sich die Methode über Standard-Chatmodi hinaus erweitern lässt, untersuchten wir außerdem die Simulation von Deployments für anspruchsvolle Settings des agentischen Programmierens. Konkret verwenden wir 120.000 interne agentische Abläufe von Mitarbeitenden aus GPT‑5.4, um das interne Deployment von Coding-Agenten auf Basis von GPT‑5.5 zu simulieren. Das dient zwei Zwecken: Es zeigt, wie Deployment Simulation auch zur Risikobewertung interner Deployments eingesetzt werden kann, und es demonstriert, dass sich selbst in agentischen Settings durch sorgfältige Tool-Simulation eine hohe Simulationstreue erreichen lässt.

Oben haben wir erläutert, dass die Simulationstreue eine der Hauptfehlerquellen in unserer aktuellen Pipeline ist. Eine der Herausforderungen bei realistischen Deployment-Simulationen besteht darin, dass Tools realistisch handeln müssen, selbst wenn sie Lese-/Schreibzugriff auf externe Ressourcen benötigen, die sich ständig ändern, etwa Websuchen oder die Interaktion mit lokalen Dateien.

Besonders anspruchsvoll ist das in Settings wie agentischen Deployments: Ein einzelner Agenten-Ablauf kann von Hunderten Tool-Aufrufen, dem Repository-Zustand, Netzwerkantworten oder vorübergehenden Fehlern abhängen. Das macht Resampling mit echtem Tool-Zugriff sowohl schwierig als auch potenziell gefährlich. Deshalb simulieren wir Tool-Aufrufe mit einem anderen LLM, statt Live-Systeme zu nutzen. Wir zeigen, dass zusätzliche Nutzungsmöglichkeiten für dieses LLM entscheidend für Realismus und damit für die Qualität der Schätzungen sind.

Wir geben dem Tool-Simulator-Modell die ursprüngliche Implementierung bei der letzten Antwort, das Repository zum Zeitpunkt des Gesprächs, eine Datenbank mit Tool-Aufruf-/Antwort-Paaren und schreibgeschützte Konnektoren. In einem Test, bei dem ein Vergleichsprogramm simulierte von echten Implementierungen unterscheiden sollte, verbesserte sich der Realismus von einer Gewinnrate von 11,6 % auf 49,5 % und lag damit nahe am Zufallsniveau von 50 %.

Als weiterer Beleg für die Simulationstreue liegen beim Simulieren von GPT‑5.4‑Codex‑Thinking‑Traffic mit GPT‑5.4 die Misalignment-Raten nahezu innerhalb der Fehlerbalken. Im Gegensatz dazu war GPT‑5.5 in unseren Tests vor dem Deployment in den meisten Kategorien stärker fehlangepasst.

Diese Ergebnisse deuten darauf hin, dass Deployment Simulation auf komplexe Agenten-Settings erweitert werden kann, wenn die umgebende Tool-Umgebung mit ausreichender Treue simuliert wird.

Eine naheliegende Frage ist, ob externe Prüfer:innen einen Teil derselben Vorteile erzielen können, ohne Zugriff auf privaten Produktionstraffic zu haben. Wir haben dies mit 100.000 WildChat-Gesprächen getestet, die als Präfixe verwendet wurden. WildChat war weniger genau als aktuelle OpenAI-Produktionsdaten, aber dennoch informativ: Aktuelle Produktionsdaten hatten einen niedrigeren durchschnittlichen multiplikativen Fehler als WildChat (1,75× gegenüber 2,44×), während WildChat häufig innerhalb von etwa 3× der Produktionsraten blieb und das bessere Modell mit Raten identifizierte, die über den Zufallsraten lagen. Wir betrachten Evaluationen im Stil von WildChat als vielversprechende Ergänzung zur Deployment Simulation, die von Entwickler:innen durchgeführt wird. Weitere Ergebnisse zu diesem Punkt findest du in diesem begleitenden Alignment-Blogpost⁠(wird in einem neuen Fenster geöffnet).

Deployment Simulation ist eine Ergänzung zu adversarialen Evaluationen, Red-Teaming und gezielter Tail-Risikoanalyse, kein Ersatz dafür. Die Erkennung einiger unerwünschter Modellverhaltensweisen hängt von der Überwachbarkeit der Gedankenkette ab: Wenn das Reasoning künftiger Modelle weniger nachvollziehbar wird, sie zentrale Schritte auslassen oder lernen, Absichten zu verschleiern, können wir diese Formen unerwünschten Verhaltens möglicherweise nicht erkennen. Da Produktionsdaten privat sind, haben Entwickler:innen derzeit außerdem besseren Zugang zu repräsentativen Kontexten als externe Prüfer:innen. Bessere öffentliche Datensätze könnten diese hier Abhilfe schaffen.

Deployment Simulation ist am nützlichsten für Verhaltensweisen, die häufig genug auftreten, um in gesampelten Präfixen vorzukommen. Ein Fehler, der einmal in zehn Millionen Gesprächen auftritt, wird in einem Lauf mit einer Million Stichproben wahrscheinlich nicht entdeckt. Deshalb bleiben adversariale Evaluationen, Red-Teaming und gezielte Tail-Risikoanalyse notwendig. Derzeit konzentrieren wir uns darauf, eine einzelne Assistant-Antwort zu simulieren, da wir in Vorversuchen keine deutlichen Verbesserungen unserer Schätzungen durch die Simulation mehrerer Turns fanden. Dies könnte künftig ein wichtiger Bereich sein, um die Simulationstreue zu verbessern.

Die Methode hängt außerdem von der Präfixverteilung ab – also von der Mischung der Gespräche, die resampelt werden. Historischer Traffic entspricht möglicherweise nicht der Art und Weise, wie Nutzer:innen nach einer großen Produktänderung, einer neuen Tool-Veröffentlichung, einem Weltereignis oder einer saisonalen Verschiebung mit einem leistungsfähigeren Modell interagieren. Die Analyse im vollständigen Forschungspapier legt nahe, dass sich dieses Problem durch die Nutzung der neuesten verfügbaren Daten mindern lässt.

Deployment Simulation ist ein neuer Ansatz für die Risikobewertung vor dem Deployment. Er hilft Frontier-Labs und Bewerter:innen vorherzusagen, wie sich Sprachmodelle in der realen Welt verhalten, und die von ihnen ausgehenden Risiken vor dem Deployment zu verstehen. Sie ergänzt bestehende Sicherheitsevaluationen, Red-Teaming und gezielte Analysen um eine stärker produktionsähnliche Prognoseschicht, die Schätzungen des Deployment-Verhaltens verbessern, Effekte des Evaluationsbewusstseins verringern und Vorhersagen vor dem Deployment nach der Veröffentlichung überprüfbar machen kann. Neben klassischen Evaluationen eingesetzt, kann Deployment Simulation dazu beitragen, die Risikobewertung von Modellen realistischer, quantitativer und nützlicher für Deployment-Entscheidungen zu machen.