Прогнозиране на поведението на модела преди пускане чрез симулиране на внедряване

Преди да пуснат нов модел, лабораториите трябва да разберат не само какво може да прави, но и как е вероятно да се държи при реална употреба, включително къде може да внесе нови рискове. Това става още по-важно с нарастването на възможностите. Като част от нашия преглед на безопасността преди внедряване използваме целеви оценки, red-teaming и други проверки, за да разберем поведението на модела. Вече започнахме да използваме метод за симулиране на внедрявания на модели, преди те да се случат, който добавя допълващ сигнал: подобен на внедряване предварителен поглед върху това как кандидат-моделът може да се държи, преди да достигне до потребителите.

Deployment Simulation е метод за симулиране на бъдещо внедряване, преди то да се случи. Правим това, като възпроизвеждаме предишни разговори по начин, запазващ поверителността, с нов кандидат-модел. Това ни позволява да изучим как новият модел отговаря в реалистични контексти преди пускането, включително дали възникват нови нежелани поведения и колко често може да се появяват.

В множество внедрявания на Thinking от серията GPT‑5 Deployment Simulation подобри оценките ни за честотите на нежелано поведение на модела, помогна да се открият нови форми на несъгласуваност преди пускане и помогна да се намали рискът моделите да разберат, че биват тествани. Приложихме метода и към трудни агентни внедрявания, показвайки, че той може да се разшири отвъд стандартния чат към по-сложни агентни настройки с използване на инструменти и да се използва за оценка на риска преди вътрешни внедрявания на модели.

Вече използвахме прозрения от Deployment Simulation по време на разработването на модели, за да идентифицираме слепи петна в традиционните оценки и да информираме мерките за смекчаване и решенията за внедряване. С улесняването на изпълнението на конвейера очакваме той да играе по-голяма роля в бъдещия процес на разработване на модели.

Оценките преди внедряване, използвани в индустрията, обикновено се състоят от комбинация от синтетични, ръчно написани или производствени подкани, умишлено избрани да бъдат трудни, с висока тежест или адверсариални. Тези оценки обикновено имат две взаимосвързани цели: да оценят как моделът отговаря при стрес тестове в ситуации с много малък шанс да възникнат в трафика при внедряване, и да дадат общо разбиране за нежеланите поведения на модела, включително откриване на нови нежелани поведения и прогнозиране на честотите им по време на внедряване.

Докато традиционните оценки остават решаващи за първата цел, Deployment Simulation представлява значителна крачка напред по отношение на втората цел за рискове извън опашката (в нашите експерименти не може да се очаква подходът ни да измерва поведения с честота под 1 на 200 000 съобщения). Силата на Deployment Simulation идва от заобикалянето на някои основни предизвикателства при традиционните оценки:

• Покритие: трудно е да сме уверени, че подканите за оценка ще покрият всички възможни типове нежелано поведение на модела. Измерването на нови типове нежелано поведение изисква създаване на нови оценки и знание кои вреди да се измерват. Това може да изисква много време и труд, а оценките могат да се наситят с времето.
• Пристрастия при подбора: традиционните оценки обикновено се изграждат с мисъл за конкретни нежелани поведения на модела и се подбират по начини, които изместват към вече възниквали контексти. Това може да направи оценките им по-малко информативни за честотата на такива поведения в пълния обхват на разпределението при внедряване.
• Разпознаваемост като тестове от моделите: моделите все по-често могат да определят, че биват тествани, което може да изкриви поведението им и последващите ни измервания на безопасността им. Макар много от традиционните оценки, които използваме в OpenAI, също да са извлечени от производствен трафик и да не страдат от този проблем, това е общо притеснение за много традиционни оценки, използвани в индустрията.

Основната техника зад Deployment Simulation е проста: вземаме скорошни разговори от внедряване, премахваме оригиналния отговор на асистента от по-стария модел и го генерираме наново с кандидат-модел, който ще бъде пуснат. Оценяваме завършванията, като търсим нови режими на отказ, и оценяваме честотата на нежелано поведение по време на внедряване въз основа на честотата в това подобно на внедряване разпределение. Можем да извършим същите измервания след пускането върху реален трафик от внедряването, което ни позволява да валидираме прогнозите си преди внедряване.

Deployment Simulation значително смекчава трите ограничения, изброени по-горе: извадковото пристрастие се адресира чрез използване на разпределение на подкани за оценка, представително за скорошната употреба. Deployment Simulation с представителни подкани може също да смекчи притесненията за покритието: получаваме по-голямо покритие на нежелани поведения на модела, като просто симулираме повече трафик. Този компромис между изчисления и покритие е важен, защото кара качеството на тази ос на оценката на риска да се мащабира с изчислителните ресурси, а не с ръчните усилия, нужни за изграждане на повече оценки. Моделите също изглежда не могат да различат разговорите, получени чрез симулация на внедряване, от реалния трафик при внедряване.

За да оценим Deployment Simulation, предварително регистрирахме прогнози за честотата по време на внедряване на 20 типа нежелано поведение за GPT‑5.4 Thinking. Проведохме и ретроспективни проучвания в други внедрявания на Thinking модели от серията GPT‑5. Поведението на модела, което анализираме, обхваща както категории на несъгласуваност, така и категории забранено съдържание, за които докладваме в карти на системата (напр. моделът лъже за инструменти или извежда забранено сексуално съдържание). Макар за тези резултати да проследяваме само 20 категории нежелано поведение на модела и да търсим само нови несъгласувани поведения, Deployment Simulation е обща техника, която може да се приложи за симулиране на всяко свойство на модела по време на внедряване.

Производственият трафик, който използвахме, също беше от Thinking модели от серията GPT‑5. Преди да изпълним оценките, автоматично премахнахме свързани с акаунти идентификатори и идентифицируема информация. В съответствие с нашата политика за поверителност анализирахме само трафик от ChatGPT от потребители, които позволяват данните им да се използват за подобрения на модела. Докладваме само агрегирани констатации от тези оценки. Общо анализирахме приблизително 1,3 милиона деидентифицирани разговора в рамките на внедрявания от GPT‑5 Thinking до GPT‑5.4, обхващащи периода от август 2025 г. до март 2026 г.

Оценяваме качеството на оценката на риска преди внедряване, произведена от Deployment Simulation, по три основни начина:

• Покритие на таксономията: откри ли одитът след пускане важни несъгласувани поведения, липсващи в първоначалната ни таксономия на лошо поведение?
• Посочна точност: предсказа ли симулацията правилно дали разпространението при внедряване ще се увеличи или намали за известни поведения?
• Калибриране на честотата: бяха ли нашите оценки преди внедряване близки до честотите, които по-късно наблюдавахме при внедряването? Постигането на добро калибриране на честотата изисква повече от посочна точност, което го прави най-високия възможен стандарт за качество.

Измерваме също доколко моделите могат да разберат, че са в оценка по време на Deployment Simulation, и тестваме колко устойчив е методът към различни форми на трафик при внедряване и към трудни настройки за използване на инструменти.

Във внедрявания на Thinking от серията GPT‑5 Deployment Simulation надмина базовите линии с трудни подкани при определяне на действителната честота на риска, успя да открие хакване на калкулатора преди пускане и изглеждаше потенциално неразличима от внедряване за модела.

Преглед на нашите прогнози. За визуализация на всички прогнози за внедрявания на Thinking модели от серията GPT‑5 вижте Фигура 2. Прогнозите за GPT‑5.4 Thinking бяха предварително регистрирани, докато останалите бяха ретроактивни прогнози. В агрегат нашите прогнози имаха медианна мултипликативна грешка от 1,5x (напр. ако честотата на нежелано поведение е 10 на 100k, това би съответствало на оценка за честота 15 или 6,67 на 100k). Макар опашните грешки на метода ни да могат да бъдат приблизително 10 пъти по-големи, очакваме те да бъдат значително намалени с допълнителни подобрения на нашия симулационен конвейер, както е обсъдено по-долу.

Сравняване на прогнозите на Deployment Simulation с базови линии. Най-важните категории за правилно оценяване при оценките на риска преди внедряване са тези, които имат големи промени в честотата след внедряването на модела (напр. >= 1,5x). В тази подгрупа Deployment Simulation е съществено по-добра от базовите линии както при прогнозиране дали дадено нежелано поведение ще се увеличи или намали по разпространение с внедряването на модела (Фигура 3, вляво), така и при оценяване на точната му честота по време на внедряване (Фигура 3, вдясно). Използваме две основни базови линии: базова линия Challenging Prompts, която в момента използваме за карти на системата и решения за пускане, и наивна базова линия, използваща честоти от предишното внедряване като оценки за новия модел.

Източници на симулационна грешка в нашия конвейер. Проучихме и текущите източници на грешка в нашия конвейер. По-конкретно, големите опашни грешки правят конвейера по-малко надежден за решения за внедряване: например, когато се вижда голямо прогнозирано увеличение на нежелано поведение от определен тип, ако е известно, че конвейерът има дори случайни големи грешки, възниква съмнение дали това е надеждна оценка или артефакт на конвейера. Има два основни източника на възможна грешка:

• Грешка във вярността на средата за повторна извадка: за да оценява точно производствените честоти, нашият симулационен конвейер трябва да бъде възможно най-реалистичен. Това е отчасти инженерен проблем (семплиране от модела чрез същите конвейери, използвани за производствен трафик), и отчасти интересно предизвикателство за инструменти, които се нуждаят от достъп за четене/запис до външни ресурси, които постоянно се променят (напр. уеб търсения или взаимодействие с локални файлове). Можем да изолираме грешката във вярността на симулацията, като сравним прогнозите от действително внедряване и неговата симулация (т.е. симулираме внедряването на вече внедрения модел).
• Грешка от изместване на разпределението на подканите: основно притеснение при Deployment Simulation е, че внедряването на всеки модел ще причини разпределително изместване във въвежданите данни, особено ако потребителите се адаптират към новите възможности на модела. Изолираме грешката в разпределението на подканите, като сравняваме оценки при симулиране на внедряването с използване на скорошни подкани спрямо подкани от реализираното внедряване.

Както се вижда във Фигура 4, установяваме, че голяма част от грешката в нашия конвейер – особено при опашните грешки – понастоящем се дължи на вярността на симулацията. Това е добра новина, тъй като очакваме вярността на симулацията обикновено да е по-лесна за подобряване, отколкото намаляването на изместването в разпределението на подканите. Установяваме също, че грешката от изместване на разпределението на подканите може да бъде намалена чрез използване на най-новите данни от предишното внедряване. Повече подробности могат да бъдат намерени в научната статия.

Автоматизираният одит откри единствената нова несъгласуваност, въведена в тези внедрявания. В прозореца на внедряване, който проучихме, нашият автоматизиран одитен конвейер, базиран на симулирани внедрявания, би открил „хакване на калкулатора“ преди пускане, което беше единствената нова несъгласуваност, идентифицирана от нас в анализирания трафик на ChatGPT. Хакването на калкулатора е форма на хакване на наградата, при която моделът използва браузърен инструмент като калкулатор, докато представя действието като търсене. Това не означава, че мащабният одит ще улови всеки нов дефект, но показва защо реалистичните контексти са важни: те могат да предизвикат поведения, които по-тесните набори за оценка може никога да не изведат директно, дори ако не са присъствали в оригиналния трафик, използван за сийдване на симулацията.

Друго предимство на използването на подобни на внедряване контексти е, че те могат да намалят изкривяванията, възникващи, когато моделите разпознаят, че биват тествани. В предишни изследвания ние, както и други⁠(отваря се в нов прозорец), установихме, че моделите често осъзнават кога биват тествани. Например моделите може да разсъждават в своето логическо мислене за това върху какво биват тествани, какво би харесал оценителят и – ако се държат неправилно – дали ще бъдат хванати. Това създава проблем за оценките на съгласуването: ако един модел се държи добре само защото мисли, че бива тестван, как да изградим увереност, че ще се държи безопасно, след като научи, че е внедрен?

Показваме, че Deployment Simulation значително намалява нивата на осъзнатост за оценяване, проявявани от моделите, спрямо традиционните оценки, които не се базират на реални данни от внедряване. Измерваме осъзнатостта за оценяване по три начина: като искаме от модел да класифицира дали дадена траектория идва от производство или оценка, като наблюдаваме логическото мислене за явни твърдения за оценяване на съгласуването, както и за метагейминг⁠(отваря се в нов прозорец): всякакво разсъждение за надзор. Симулираният трафик при внедряване много близко съвпадаше с реалния трафик при внедряване и по трите мерки. Например GPT‑5.2 маркира реалния производствен трафик като подобен на оценка в 5,4% от случаите и симулирания трафик в 5,1% от случаите, докато традиционните оценки (като SWE-Bench или MonorepoBench, които са съставени предимно от синтетични примери) бяха класифицирани като оценки почти 100% от времето.

За да тестваме дали методът може да се разшири отвъд стандартните чат режими, проучихме и симулиране на внедрявания за трудни настройки на агентно кодиране. По-конкретно използваме 120 000 вътрешни агентни траектории на служители от GPT‑5.4, за да симулираме вътрешното внедряване на агенти за кодиране, базирани на GPT‑5.5. Това служи на две цели: показва как симулацията на внедряване може да се използва и за оценка на риска при вътрешни внедрявания, и демонстрира, че е възможно вярността на симулацията да бъде висока дори в агентни настройки чрез внимателна симулация на инструменти.

По-горе обсъдихме, че вярността на симулацията е един от основните източници на грешка в текущия ни конвейер. Едно от предизвикателствата при правенето на симулациите на внедряване реалистични е, че това изисква инструментите да действат по реалистични начини, дори когато им е нужен достъп за четене/запис до външни ресурси, които постоянно се променят (напр. уеб търсения или взаимодействие с локални файлове).

Това е особено трудно за настройки като агентни внедрявания: една траектория на агент може да зависи от стотици извиквания на инструменти, състояние на хранилище, мрежови отговори или преходни откази. Това прави повторната извадка с реален достъп до инструменти едновременно трудно и потенциално опасно. С оглед на това, вместо да прилагаме извиквания на инструменти към живи системи, ги симулираме с друг голям езиков модел. Показваме, че предоставянето на допълнителни възможности на този голям езиков модел е съществено за реализма и следователно за качеството на оценката.

Даваме на модела симулатор на инструменти оригиналното разгръщане на последния ход, хранилището от момента на разговора, база данни от двойки извикване на инструмент/отговор и конектори само за четене. В тест, при който дискриминатор се опита да различи симулирани от реални разгръщания, реализмът се подобри от 11,6% процент на победа до 49,5%, близо до нивото на случайност от 50%.

Като допълнително доказателство за вярността на симулацията, при симулиране на трафик на структурирано анализиране от GPT‑5.4 Codex с GPT‑5.4 честотите на несъгласуваност са почти в рамките на интервалите на грешка. За разлика от това, в нашето тестване преди внедряване GPT‑5.5 беше по-несъгласуван в повечето категории.

Тези резултати предполагат, че Deployment Simulation може да се разшири до сложни агентни настройки, когато околната инструментална среда се симулира с достатъчна вярност.

Естествен въпрос е дали външните одитори могат да получат част от същите ползи без достъп до частен производствен трафик. Тествахме това със 100 000 разговора от WildChat, използвани като префикси. WildChat беше по-малко точен от скорошните производствени данни на OpenAI, но все пак информативен: скорошните производствени данни имаха по-ниска средна мултипликативна грешка от WildChat (1,75× срещу 2,44×), докато WildChat често оставаше в рамките на приблизително 3× от производствените честоти и идентифицираше по-добрия модел с честоти над случайността. Виждаме оценките в стил WildChat като обещаващо допълнение към Deployment Simulation, изпълнявана от разработчиците. Вижте тази придружаваща публикация в блога Alignment⁠(отваря се в нов прозорец) за повече резултати по този въпрос.

Deployment Simulation е допълнение към, а не заместител на, адверсариалните оценки, red-teaming и целевия анализ на рискове от опашката. Откриването на някои нежелани поведения на модела разчита на наблюдаемост на логическото мислене: ако бъдещи модели разсъждават по-малко четливо, пропускат ключови стъпки или се научат да прикриват намерение, може да не можем да откриваме тези форми на нежелано поведение. Освен това, тъй като производствените данни са частни, разработчиците в момента имат по-силен достъп до представителни контексти от външните одитори. По-добри публични набори от данни биха могли да стеснят тази разлика.

Deployment Simulation е най-полезна за поведения, които се срещат достатъчно често, за да се появят в семплирани префикси. Дефект, който се случва веднъж на десет милиона разговора, е малко вероятно да бъде открит в изпълнение с милион извадки, така че адверсариалните оценки, red-teaming и целевият анализ на рискове от опашката остават необходими. В момента се фокусираме върху симулиране на един отговор на асистента, тъй като в предварителни експерименти не открихме значими подобрения в оценките си чрез симулиране на множество ходове. Това може да бъде важна област за подобряване на вярността на симулацията в бъдеще.

Методът зависи и от разпределението на префиксите — сместа от разговори, от които се прави повторна извадка. Историческият трафик може да не съответства на начина, по който потребителите взаимодействат с по-способен модел след голяма продуктова промяна, пускане на нов инструмент, световно събитие или сезонна промяна. Анализът в пълната статия предполага, че този проблем може да бъде смекчен чрез използване на най-новите налични данни.

Симулацията на внедряване е нов подход към оценката на риска преди внедряване, който помага на водещи лаборатории и оценители да прогнозират как езиковите модели могат да се държат в реалния свят и да разберат рисковете, които създават, преди внедряване. Тя допълва съществуващите оценки на безопасността, red-teaming и целевия анализ, като добавя по-близък до производството слой за прогнозиране, който може да подобри оценките за поведението при внедряване, да намали ефектите от осъзнатостта за оценяване и да направи прогнозите преди внедряване проверими след пускането. Използвана заедно с традиционните оценки, Deployment Simulation може да помогне оценката на риска на модела да стане по-реалистична, по-количествена и по-полезна за решенията за внедряване.