Przewidywanie zachowania modelu przed wydaniem - Symulacja wdrożenia

Przed wydaniem nowego modelu laboratoria muszą rozumieć nie tylko to, co potrafi, ale też jak prawdopodobnie będzie zachowywać się w rzeczywistym użyciu, w tym gdzie może wprowadzać nowe ryzyka. Staje się to jeszcze ważniejsze wraz ze wzrostem możliwości. W ramach przeglądu bezpieczeństwa przed wdrożeniem wykorzystujemy ukierunkowane ewaluacje, kontrolowane ataki i inne testy, aby zrozumieć zachowanie modelu. Zaczęliśmy teraz używać metody symulowania wdrożeń modeli przed ich przeprowadzeniem, która dodaje uzupełniający sygnał: podobny do wdrożenia podgląd tego, jak model kandydujący może zachowywać się, zanim trafi do użytkowników.

Symulacja wdrożenia to metoda symulowania przyszłego wdrożenia, zanim ono nastąpi. Robimy to, odtwarzając wcześniejsze rozmowy w sposób chroniący prywatność za pomocą nowego modelu kandydującego. Pozwala nam to badać przed wydaniem, jak nowy model odpowiada w realistycznych kontekstach i między innymi kontrolować, czy pojawiają się nowe niepożądane zachowania oraz jak często mogą występować.

W wielu wdrożeniach modeli Thinking z serii GPT‑5 Symulacja wdrożenia poprawiła nasze szacunki wskaźników niepożądanych zachowań modelu, pomogła ujawnić nowe formy niedopasowania przed wydaniem i pomogła zmniejszyć ryzyko, że modele będą w stanie rozpoznać, iż są testowane. Zastosowaliśmy tę metodę także do wymagających wdrożeń agentowych, pokazując, że może wykraczać poza standardowy czat na bardziej złożone ustawienia agentów obejmujące użycie narzędzi, a także służyć do oceny ryzyka przed wewnętrznymi wdrożeniami modeli.

Wykorzystaliśmy już wnioski z Symulacji wdrożenia podczas rozwoju modelu, aby identyfikować ślepe punkty w tradycyjnych ewaluacjach oraz informować o środkach zaradczych i decyzjach wdrożeniowych. W miarę jak upraszczamy uruchamianie tego potoku, oczekujemy, że będzie odgrywać większą rolę w przyszłym procesie rozwoju modeli.

Ewaluacje przedwdrożeniowe stosowane w branży zwykle składają się z mieszanki syntetycznych, ręcznie napisanych lub produkcyjnych poleceń celowo wybranych jako trudne, o dużej wadze lub antagonistyczne. Ewaluacje te miały zwykle dwa powiązane cele: ocenę, jak model odpowiada podczas testów obciążeniowych w sytuacjach o bardzo małym prawdopodobieństwie wystąpienia w ruchu wdrożeniowym oraz uzyskanie ogólnego zrozumienia niepożądanych zachowań modelu, w tym znajdowanie nowych niepożądanych zachowań i przewidywanie ich częstotliwości w czasie wdrożenia.

Choć tradycyjne ewaluacje pozostają kluczowe dla pierwszego celu, Symulacja wdrożenia stanowi znaczący krok naprzód w odniesieniu do drugiego celu dla ryzyk spoza grupy rzadkich przypadków w rozkładzie (w naszych eksperymentach nie można oczekiwać, że nasze podejście zmierzy zachowania występujące rzadziej niż 1 raz na 200 000 wiadomości). Siła Symulacji wdrożenia wynika z obejścia części podstawowych wyzwań tradycyjnych ewaluacji:

• Pokrycie: trudno mieć pewność, że polecenia ewaluacyjne obejmą wszystkie możliwe typy niepożądanych zachowań modelu. Pomiar nowych typów niepożądanego zachowania wymaga tworzenia nowych ewaluacji i wiedzy, jakie szkody mierzyć. Może to wymagać dużo czasu i pracy, a ewaluacje mogą z czasem ulegać nasyceniu.
• Błędy doboru: tradycyjne ewaluacje są zwykle budowane z myślą o konkretnych niepożądanych zachowaniach modelu wybieranych w sposób faworyzujący konteksty, które już wcześniej wystąpiły. Może to sprawiać, że ich szacunki są mniej informacyjne o częstości takich zachowań w pełnym zakresie rozkładu wdrożeniowego.
• Rozpoznawalność testów przez modele: modele coraz częściej potrafią ustalić, że są testowane, co może zniekształcać ich zachowanie i nasze późniejsze pomiary ich bezpieczeństwa. Choć wiele tradycyjnych ewaluacji używanych przez nas w OpenAI także pochodzi z ruchu produkcyjnego i nie cierpi na ten problem, jest to częsta obawa dotycząca wielu tradycyjnych ewaluacji stosowanych w branży.

Główna technika stojąca za Symulacją wdrożenia jest prosta: bierzemy niedawne rozmowy z wdrożenia, usuwamy pierwotną odpowiedź asystenta ze starszego modelu i generujemy ją ponownie za pomocą modelu kandydującego do wydania. Oceniamy uzupełnienia, szukając nowych trybów awarii, i szacujemy częstotliwość niepożądanych zachowań w czasie wdrożenia na podstawie ich częstotliwości w tym rozkładzie podobnym do wdrożeniowego. Te same pomiary możemy wykonywać po wydaniu na rzeczywistym ruchu wdrożeniowym, co pozwala nam weryfikować nasze prognozy przedwdrożeniowe.

Symulacja wdrożenia znacząco łagodzi trzy wymienione wyżej ograniczenia: błąd próbkowania jest rozwiązywany przez użycie rozkładu poleceń ewaluacyjnych reprezentatywnego dla niedawnego użycia. Symulacja wdrożenia z reprezentatywnymi poleceniami może także łagodzić obawy o pokrycie: uzyskujemy większe pokrycie niepożądanych zachowań modelu po prostu przez symulowanie większego ruchu. Ten kompromis między mocą obliczeniową a pokryciem jest ważny, ponieważ sprawia, że jakość tej osi oceny ryzyka skaluje się z mocą obliczeniową, a nie z ręcznym wysiłkiem potrzebnym do zbudowania większej liczby ewaluacji. Modele także nie wydają się umieć odróżniać rozmów uzyskanych przez symulację wdrożenia od rzeczywistego ruchu wdrożeniowego.

Aby ocenić Symulację wdrożenia, wstępnie zarejestrowaliśmy prognozy częstotliwości 20 typów niepożądanych zachowań w czasie wdrożenia dla GPT‑5.4 Thinking. Przeprowadziliśmy także badania retrospektywne obejmujące inne wdrożenia modeli Thinking z serii GPT‑5. Analizowane przez nas zachowania modelu obejmują zarówno niedopasowanie, jak i kategorie niedozwolonych treści, o których informujemy w kartach systemu (np. model kłamie na temat narzędzi albo generuje niedozwolone treści seksualne). Choć w tych wynikach śledzimy tylko 20 kategorii niepożądanych zachowań modelu i szukamy jedynie nowych niedopasowanych zachowań, Symulacja wdrożenia jest ogólną techniką, którą można zastosować do symulowania dowolnej właściwości modelu w czasie wdrożenia.

Wykorzystany przez nas ruch produkcyjny także pochodził z modeli Thinking z serii GPT‑5. Przed uruchomieniem ewaluacji automatycznie usunęliśmy identyfikatory powiązane z kontami i informacje umożliwiające identyfikację. Zgodnie z naszymi zasadami prywatności analizowaliśmy tylko ruch ChatGPT od użytkowników, którzy zezwalają na używanie swoich danych do ulepszania modeli. Raportujemy wyłącznie zagregowane ustalenia z tych ewaluacji. Łącznie przeanalizowaliśmy około 1,3 miliona zanonimizowanych rozmów w ramach wdrożeń od GPT‑5 Thinking do GPT‑5.4 obejmujących okres od sierpnia 2025 do marca 2026.

Jakość przedwdrożeniowej oceny ryzyka przygotowanej przez Symulację wdrożenia oceniamy na trzy główne sposoby:

• Pokrycie taksonomii: czy audyt po wydaniu ujawnił jakieś ważne niedopasowane zachowania brakujące w naszej początkowej taksonomii złych zachowań?
• Trafność kierunkowa: czy symulacja poprawnie przewidziała, że częstość występowania znanych zachowań wzrośnie lub spadnie po wdrożeniu?
• Kalibracja wskaźników: czy nasze szacunki przedwdrożeniowe były bliskie wskaźnikom, które później zaobserwowaliśmy we wdrożeniu? Uzyskanie dobrej kalibracji wskaźników wymaga więcej niż tylko trafności kierunkowej, co czyni z tego najwyższy możliwy standard jakości.

Mierzymy także, w jakim stopniu modele potrafią rozpoznać, że są testowane podczas Symulacji wdrożenia, oraz sprawdzamy odporność naszej metody na różne formy ruchu wdrożeniowego i wymagające ustawienia użycia narzędzi.

W ramach wdrożeń modeli Thinking z serii GPT‑5 Symulacja wdrożenia przewyższyła punkty odniesienia oparte na trudnych poleceniach w określaniu rzeczywistego wskaźnika ryzyka, potrafiła ujawnić hakowanie kalkulatora przed wydaniem i wydawała się potencjalnie nieodróżnialna od wdrożenia dla modelu.

Przegląd naszych prognoz. Wizualizację wszystkich prognoz dla wdrożeń modeli Thinking z serii GPT‑5 przedstawia Rysunek 2. Prognozy dla GPT‑5.4 Thinking zostały wstępnie zarejestrowane, a pozostałe były prognozami retrospektywnymi. Łącznie nasze prognozy miały medianę błędu multiplikatywnego 1,5× (np. jeśli wskaźnik niepożądanego zachowania wynosi 10 na 100 tys., odpowiadałoby to oszacowaniu wskaźnika na 15 lub 6,67 na 100 tys.). Choć błędy pochodzące z rzadkich przypadków w kontekście naszej metody mogą w przybliżeniu występować 10× częściej, oczekujemy, że da się je znacząco ograniczyć dzięki dalszym ulepszeniom naszego potoku symulacji, o czym mówimy niżej.

Porównanie prognoz Symulacji wdrożenia z punktami odniesienia. Najważniejsze kategorie do poprawnego oszacowania w przedwdrożeniowych ocenach ryzyka to te, w których po wdrożeniu modelu występują duże zmiany częstości (np. >= 1,5×). W tym podzbiorze Symulacja wdrożenia jest znacznie lepsza od punktów odniesienia zarówno w przewidywaniu, czy dane niepożądane zachowanie wzrośnie czy spadnie pod względem częstości wraz z wdrożeniem modelu (Rysunek 3, po lewej), jak i w szacowaniu jego dokładnej częstości w czasie wdrożenia (Rysunek 3, po prawej). Używamy dwóch głównych punktów odniesienia: punktu odniesienia Trudne polecenia, który obecnie stosujemy względem kart systemu i decyzji o uruchomieniu, oraz naiwnego punktu odniesienia polegającego na użyciu wskaźników z poprzedniego wdrożenia jako szacunków dla nowego modelu.

Źródła błędu symulacji w naszym potoku. Zbadaliśmy także obecne źródła błędu w naszym potoku. W szczególności istotne błędy rzadkie zmniejszają wiarygodność potoku przy decyzjach wdrożeniowych: na przykład gdy widzimy duży przewidywany wzrost niepożądanego zachowania określonego typu, a wiadomo, że potok miewa choćby sporadyczne duże błędy, pojawia się wątpliwość, czy to wiarygodny szacunek, czy artefakt potoku. Istnieją dwa główne źródła możliwego błędu:

• Błąd wierności środowiska ponownego próbkowania: aby dokładnie szacować wskaźniki produkcyjne, nasz potok symulacji musi być możliwie realistyczny. Częściowo jest to problem inżynieryjny (próbkowanie z modelu za pomocą tych samych potoków co w ruchu produkcyjnym), a częściowo ciekawe wyzwanie dla narzędzi, które potrzebują dostępu do odczytu/zapisu względem stale zmieniających się zasobów zewnętrznych (np. wyszukiwań w internecie lub interakcji z plikami lokalnymi). Błąd wierności symulacji możemy wyizolować, porównując prognozy z rzeczywistego wdrożenia i jego symulacji (czyli symulując wdrożenie już wdrożonego modelu).
• Błąd przesunięcia rozkładu poleceń: główną obawą związaną z Symulacją wdrożenia jest to, że wdrożenie każdego modelu spowoduje przesunięcie rozkładu danych wejściowych, zwłaszcza jeśli użytkownicy dostosują się do nowych możliwości modelu. Błąd rozkładu poleceń izolujemy, porównując szacunki przy symulowaniu wdrożenia z użyciem niedawnych poleceń oraz poleceń z faktycznie zrealizowanego wdrożenia.

Jak widać na Rysunku 4, stwierdzamy, że duża część błędu w naszym potoku — zwłaszcza w przypadku błędów rzadkich — wynika obecnie z wierności symulacji. To dobra wiadomość, ponieważ oczekujemy, że wierność symulacji będzie na ogół łatwiejsza do poprawy niż ograniczenie przesunięcia rozkładu poleceń. Stwierdzamy także, że błąd przesunięcia rozkładu poleceń można ograniczyć, używając najnowszych danych z poprzedniego wdrożenia. Więcej szczegółów można znaleźć w artykule badawczym.

Automatyczny audyt znalazł jedyne nowe niedopasowanie wprowadzone w tych wdrożeniach. W badanym przez nas oknie wdrożeniowym nasz automatyczny potok audytowy oparty na symulowanych wdrożeniach ujawniłby „hakowanie kalkulatora” przed wydaniem, które było jedynym nowym niedopasowaniem zidentyfikowanym w analizowanym ruchu ChatGPT. Hakowanie kalkulatora to forma hakowania nagrody, w której model używa narzędzia przeglądarki jako kalkulatora, przedstawiając działanie jako wyszukiwanie. Nie oznacza to, że audyt na dużą skalę wychwyci każdą nową awarię, ale pokazuje, dlaczego realistyczne konteksty mają znaczenie: mogą wywoływać zachowania, których węższe zestawy ewaluacyjne mogą nigdy bezpośrednio nie ujawnić, nawet jeśli nie były obecne w pierwotnym ruchu użytym do zainicjowania symulacji.

Inną zaletą używania kontekstów podobnych do wdrożeniowych jest to, że mogą ograniczać zniekształcenia powstające, gdy modele rozpoznają, że są testowane. We wcześniejszych badaniach my, a także inne organizacje⁠(otwiera nowe okno), stwierdziliśmy, że modele często są świadome, kiedy są testowane. Na przykład modele mogą rozumować w swoim łańcuchu rozumowania o tym, pod jakim względem są testowane, co może spodobać się ewaluatorowi oraz — jeśli zachowują się niewłaściwie — czy zostaną przyłapane. Stanowi to problem dla ewaluacji dopasowania: jeśli model zachowuje się dobrze tylko dlatego, że uważa, iż jest testowany, jak wypracować pewność, że będzie zachowywał się bezpiecznie, gdy dowie się, że został wdrożony?

Pokazujemy, że Symulacja wdrożenia znacząco obniża poziomy świadomości ewaluacji wykazywane przez modele względem tradycyjnych ewaluacji, które nie opierają się na rzeczywistych danych wdrożeniowych. Mierzymy świadomość ewaluacji na trzy sposoby: prosząc model o sklasyfikowanie, czy trajektoria pochodziła z produkcji czy ewaluacji, monitorując łańcuch rozumowania pod kątem jawnych stwierdzeń o byciu ocenianym pod względem dopasowania, a także pod kątem metagamingu⁠(otwiera nowe okno): wszelkiego rozumowania o nadzorze. Symulowany ruch wdrożeniowy był bardzo podobny do rzeczywistego ruchu wdrożeniowego we wszystkich trzech miarach. Na przykład GPT‑5.2 oznaczał rzeczywisty ruch produkcyjny jako podobny do ewaluacji w 5,4% przypadków, a ruch symulowany w 5,1% przypadków, podczas gdy tradycyjne ewaluacje (takie jak SWE-Bench czy MonorepoBench, składające się głównie z przykładów syntetycznych) były klasyfikowane jako ewaluacje niemal w 100% przypadków.

Aby sprawdzić, czy metoda może wykraczać poza standardowe tryby czatu, badaliśmy także symulowanie wdrożeń dla wymagających ustawień kodowania agentowego. Konkretnie używamy 120 000 wewnętrznych trajektorii agentowych pracowników z GPT‑5.4, aby zasymulować wewnętrzne wdrożenie agentów kodujących opartych na GPT‑5.5. Służy to dwóm celom: pokazuje, jak symulacja wdrożenia może być używana także do oceny ryzyka dla wdrożeń wewnętrznych, oraz dowodzi, że dzięki starannej symulacji narzędzi można osiągnąć wysoką wierność symulacji nawet w ustawieniach agentowych.

Powyżej omówiliśmy, że wierność symulacji jest jednym z głównych źródeł błędu w naszym obecnym potoku. Jednym z wyzwań przy tworzeniu realistycznych symulacji wdrożenia jest to, że wymagają one realistycznego działania narzędzi, nawet gdy potrzebują dostępu do odczytu/zapisu do stale zmieniających się zasobów zewnętrznych (np. wyszukiwań w internecie lub interakcji z plikami lokalnymi).

Jest to szczególnie trudne w ustawieniach takich jak wdrożenia agentowe: pojedyncza trajektoria agenta może zależeć od setek wywołań narzędzi, stanu repozytorium, odpowiedzi sieciowych lub przejściowych awarii. Sprawia to, że ponowne próbkowanie z rzeczywistym dostępem do narzędzi jest zarówno trudne, jak i potencjalnie niebezpieczne. W związku z tym zamiast stosować wywołania narzędzi do systemów działających na żywo, symulujemy je za pomocą innego LLM. Pokazujemy, że nadanie temu LLM dodatkowych możliwości jest niezbędne dla realizmu, a zatem jakości szacowania.

Modelowi symulatora narzędzi przekazujemy pierwotny wynik ostatniej tury, repozytorium z czasu rozmowy, bazę danych par wywołanie-narzędzia/odpowiedź oraz konektory tylko do odczytu. W teście, w którym dyskryminator próbował odróżnić wyniki symulowane od rzeczywistych, realizm poprawił się z 11,6% współczynnika wygranych do 49,5%, blisko poziomu losowego 50%.

Jako dodatkowy dowód wierności symulacji, podczas symulowania ruchu GPT‑5.4 Codex thinking za pomocą GPT‑5.4 wskaźniki niedopasowania są mniej więcej w granicach błędu. Dla kontrastu, w naszych testach przedwdrożeniowych GPT‑5.5 był bardziej niedopasowany w większości kategorii.

Wyniki te sugerują, że Symulacja wdrożenia może obejmować złożone ustawienia agentów, gdy otaczające środowisko narzędzi jest symulowane z wystarczającą wiernością.

Naturalne pytanie brzmi, czy audytorzy zewnętrzni mogą uzyskać część tych samych korzyści bez dostępu do prywatnego ruchu produkcyjnego. Przetestowaliśmy to na 100 000 rozmów WildChat użytych jako prefiksy. WildChat był mniej dokładny niż niedawne dane produkcyjne OpenAI, ale nadal informacyjny: niedawne dane produkcyjne miały niższy średni błąd multiplikatywny niż WildChat (1,75× wobec 2,44×), a WildChat często mieścił się w przybliżeniu w granicach 3× wskaźników produkcyjnych i wskazywał lepszy model z częstością wyższą niż losowa. Ewaluacje w stylu WildChat postrzegamy jako obiecujące uzupełnienie Symulacji wdrożenia prowadzonej przez deweloperów. Więcej wyników w tym obszarze można znaleźć w tym uzupełniającym wpisie na blogu Alignment⁠(otwiera nowe okno).

Symulacja wdrożenia jest uzupełnieniem, a nie zamiennikiem ewaluacji antagonistycznych, ataków kontrolowanych i ukierunkowanej analizy ryzyk wynikających z występowania błędów rzadkich. Wykrywanie niektórych niepożądanych zachowań modelu opiera się na możliwości monitorowania łańcucha rozumowania: jeśli przyszłe modele będą rozumować mniej czytelnie, pomijać kluczowe kroki lub nauczą się ukrywać intencje, możemy nie być w stanie wykrywać tych form niepożądanego zachowania. Co więcej, skoro dane produkcyjne są prywatne, deweloperzy mają obecnie większy dostęp do reprezentatywnych kontekstów niż audytorzy zewnętrzni. Lepsze publiczne zbiory danych mogłyby zmniejszyć tę lukę.

Symulacja wdrożenia jest najbardziej użyteczna dla zachowań, które występują wystarczająco często, aby pojawić się w próbkowanych prefiksach. Awaria występująca raz na dziesięć milionów rozmów prawdopodobnie nie zostanie odkryta w przebiegu z milionem próbek, dlatego ewaluacje antagonistyczne, ataki kontrolowane i ukierunkowana analiza ryzyk wynikających z błędów rzadkich są niezbędnymi działaniami. Obecnie koncentrujemy się na symulowaniu pojedynczej odpowiedzi asystenta, ponieważ we wstępnych eksperymentach nie znaleźliśmy istotnych ulepszeń naszych szacunków dzięki symulowaniu wielu tur. Może to być ważny obszar poprawy wierności symulacji w przyszłości.

Metoda zależy także od rozkładu prefiksów — mieszanki rozmów, które są ponownie próbkowane. Ruch historyczny może nie odpowiadać temu, jak użytkownicy wchodzą w interakcje z bardziej zdolnym modelem po dużej zmianie produktu, wydaniu nowego narzędzia, wydarzeniu na świecie lub zmianie sezonowej. Analiza w pełnym artykule sugeruje, że problem ten można złagodzić, używając najnowszych dostępnych danych.

Symulacja wdrożenia to nowe podejście do przedwdrożeniowej oceny ryzyka, które pomaga laboratoriom pionierskim i ewaluatorom przewidywać, jak modele językowe mogą zachowywać się w realnym świecie, oraz rozumieć ryzyka, jakie stwarzają przed wdrożeniem. Uzupełnia istniejące ewaluacje bezpieczeństwa, ataki kontrolowane i ukierunkowaną analizę, dodając bardziej produkcyjną warstwę predykcyjną, która może poprawiać szacunki zachowań wdrożeniowych, ograniczać efekty świadomości ewaluacji i sprawiać, że prognozy przedwdrożeniowe można sprawdzić po wydaniu. Symulacja wdrożenia stosowana wraz z tradycyjnymi ewaluacjami może pomóc uczynić ocenę ryzyka modelu bardziej realistyczną, bardziej ilościową i bardziej użyteczną dla decyzji wdrożeniowych.