Прогнозування поведінки моделі перед випуском шляхом симуляції розгортання

Перед випуском нової моделі лабораторіям потрібно розуміти не лише те, що вона може робити, а й те, як вона, імовірно, поводитиметься в реальному використанні, зокрема де може створювати нові ризики. Це стає ще важливішим зі зростанням можливостей. У межах нашої перевірки безпеки перед розгортанням ми використовуємо цільові оцінювання, red-teaming та інші перевірки, щоб зрозуміти поведінку моделі. Тепер ми почали використовувати метод для симуляції розгортань моделі до того, як вони відбудуться, що додає доповнювальний сигнал: подібний до розгортання попередній перегляд того, як кандидатна модель може поводитися до того, як потрапить до користувачів.

Симуляція розгортання — це метод симулювання майбутнього розгортання до того, як воно відбудеться. Ми робимо це, відтворюючи попередні розмови з новою кандидатною моделлю у спосіб, що зберігає конфіденційність. Це дає нам змогу вивчати, як нова модель відповідає в реалістичних контекстах до випуску, зокрема чи з’являється нова небажана поведінка і як часто вона може траплятися.

У кількох розгортаннях Thinking серії GPT‑5 Симуляція розгортання покращила наші оцінки частоти небажаної поведінки моделі, допомогла виявити нові форми неузгодженості до випуску й знизила ризик того, що моделі зможуть зрозуміти, що їх тестують. Ми також застосували цей метод до складних агентних запусків, показавши, що він може виходити за межі стандартного чату до складніших налаштувань агентів із використанням інструментів, а також може застосовуватися для оцінювання ризиків перед внутрішніми розгортаннями моделі.

Ми вже використовували інсайти із Симуляції розгортання під час розробки моделі, щоб виявляти сліпі зони в традиційних оцінюваннях і формувати заходи пом’якшення та рішення щодо розгортання. Оскільки ми спрощуємо запуск цього конвеєра, очікуємо, що він відіграватиме більшу роль у майбутньому процесі розробки моделі.

Оцінювання перед розгортанням, які використовуються в галузі, зазвичай складаються із суміші синтезованих, написаних вручну або виробничих запитів, навмисно відібраних як складні, високої серйозності або змагальні. Ці оцінювання зазвичай мали дві взаємопов’язані цілі: оцінити, як модель відповідає під час стрес-тестування в ситуаціях, що мають дуже малий шанс виникнути в трафіку розгортання, і отримати загальне розуміння небажаної поведінки моделі, зокрема знайти нові небажані прояви та спрогнозувати їхню частоту під час розгортання.

Хоча традиційні оцінювання залишаються критично важливими для першої цілі, Симуляція розгортання є значним кроком уперед щодо другої цілі для некінцевих ризиків (у наших експериментах не варто очікувати, що наш підхід виміряє поведінку, яка трапляється рідше ніж 1 раз на 200 000 повідомлень). Сила Симуляції розгортання полягає в тому, що вона обходить деякі ключові виклики традиційних оцінювань:

• Покриття: важко бути впевненими, що запити для оцінювання охоплять усі можливі типи небажаної поведінки моделі. Вимірювання нових типів небажаної поведінки потребує створення нових оцінювань і розуміння того, які шкоди вимірювати. Це може вимагати багато часу й праці, а оцінювання з часом можуть насичуватися.
• Упередження відбору: традиційні оцінювання зазвичай будуються з огляду на конкретні небажані прояви поведінки моделі й добираються так, що зміщуються до контекстів, які вже траплялися раніше. Через це їхні оцінки можуть бути менш інформативними щодо частоти таких проявів у всій ширині розподілу розгортання.
• Розпізнаваність як тестів для моделей: моделі дедалі частіше здатні визначати, що їх тестують, що може спотворювати їхню поведінку й наші подальші вимірювання їхньої безпеки. Хоча багато традиційних оцінювань, які ми використовуємо в OpenAI, також узяті з виробничого трафіку й не мають цієї проблеми, це поширене занепокоєння для багатьох традиційних оцінювань, що використовуються в галузі.

Основна техніка, що лежить в основі Симуляції розгортання, проста: ми беремо нещодавні розмови з розгортання, видаляємо початкову відповідь асистента від старішої моделі й генеруємо її заново за допомогою кандидатної моделі, яку планується випустити. Ми оцінюємо завершення, шукаючи нові режими відмов, і оцінюємо частоту небажаної поведінки під час розгортання на основі частоти в цьому подібному до розгортання розподілі. Ми можемо виконувати ті самі вимірювання після випуску на реальному трафіку розгортання, що дає змогу перевірити наші прогнози до розгортання.

Симуляція розгортання суттєво пом’якшує три перелічені вище обмеження: упередження вибірки усувається завдяки використанню розподілу запитів для оцінювання, репрезентативного для нещодавнього використання. Симуляція розгортання з репрезентативними запитами також може пом’якшити занепокоєння щодо покриття: ми отримуємо ширше покриття небажаної поведінки моделі, просто симулюючи більше трафіку. Цей компроміс між обчисленнями й покриттям важливий, бо робить якість цієї осі оцінювання ризиків масштабованою з обчисленнями, а не з ручними зусиллями, потрібними для створення додаткових оцінювань. Моделі також, схоже, не здатні відрізнити розмови, отримані через симуляцію розгортання, від реального трафіку розгортання.

Щоб оцінити Симуляцію розгортання, ми попередньо зареєстрували прогнози частоти 20 типів небажаної поведінки під час розгортання для GPT‑5.4 Thinking. Ми також провели ретроспективні дослідження в інших розгортаннях моделей Thinking серії GPT‑5. Поведінка моделі, яку ми аналізуємо, охоплює як неузгодженість, так і категорії забороненого контенту, про які ми повідомляли в картках системи (наприклад, коли модель бреше про інструменти або виводить заборонений сексуальний контент). Хоча для цих результатів ми відстежуємо лише 20 категорій небажаної поведінки моделі й шукаємо лише нові неузгоджені прояви, Симуляція розгортання є загальною технікою, яку можна застосувати для симуляції будь-якої властивості моделі під час розгортання.

Виробничий трафік, який ми використали, також був із моделей Thinking серії GPT‑5. Перед запуском наших оцінювань ми автоматично видалили пов’язані з акаунтами ідентифікатори та ідентифікаційну інформацію. Відповідно до нашої політики конфіденційності ми аналізували лише трафік ChatGPT від користувачів, які дозволяють використовувати свої дані для покращення моделі. Ми повідомляємо лише агреговані висновки з цих оцінювань. Загалом ми проаналізували приблизно 1,3 мільйона деідентифікованих розмов у розгортаннях від GPT‑5 Thinking до GPT‑5.4, що охоплюють період із серпня 2025 року до березня 2026 року.

Ми оцінюємо якість оцінювання ризиків перед розгортанням, створеного Симуляцією розгортання, трьома основними способами:

• Покриття класифікації: чи виявив аудит після випуску важливі неузгоджені прояви поведінки, відсутні в нашій початковій класифікації поганої поведінки?
• Напрямкова точність: чи правильно симуляція передбачила, чи поширеність відомих проявів поведінки під час розгортання зросте або зменшиться?
• Калібрування частоти: чи були наші оцінки до розгортання близькими до частот, які ми згодом спостерігали під час розгортання? Досягнення хорошого калібрування частоти потребує більшого, ніж напрямкова точність, що робить це найвищим можливим стандартом якості.

Ми також вимірюємо, наскільки моделі здатні зрозуміти, що перебувають в оцінюванні під час Симуляції розгортання, і перевіряємо, наскільки метод стійкий до різних форм трафіку розгортання та складних налаштувань використання інструментів.

У розгортаннях Thinking серії GPT‑5 Симуляція розгортання перевершила базові підходи зі складними запитами у визначенні фактичного рівня ризику, змогла виявити злам калькулятора до випуску й виглядала потенційно невідрізненною від розгортання для моделі.

Огляд наших прогнозів. Візуалізацію всіх прогнозів для розгортань моделей Thinking серії GPT‑5 див. на рисунку 2. Прогнози для GPT‑5.4 Thinking були попередньо зареєстровані, тоді як інші були ретроактивними. В агрегованому вигляді наші прогнози мали медіанну мультиплікативну похибку 1,5x (наприклад, якщо рівень небажаної поведінки становить 10 на 100 тис., це відповідало б оцінці рівня 15 або 6,67 на 100 тис.). Хоча кінцеві похибки нашого методу можуть бути приблизно в 10 разів більшими, ми очікуємо, що їх можна суттєво зменшити завдяки подальшим покращенням нашого конвеєра симуляції, як обговорено нижче.

Порівняння прогнозів Симуляції розгортання з базовими рівнями. Найважливіші категорії, які потрібно правильно оцінити для оцінювання ризиків перед розгортанням, — це ті, що мають великі зміни частоти після розгортання моделі (наприклад, >= 1,5x). На цій підмножині Симуляція розгортання суттєво краща за базові рівні як у прогнозуванні того, чи зросте або зменшиться поширеність певної небажаної поведінки з розгортанням моделі (рисунок 3, ліворуч), так і в оцінюванні її точної частоти під час розгортання (рисунок 3, праворуч). Ми використовуємо два основні базові рівні: базовий рівень Challenging Prompts, який ми нині використовуємо для карток системи та рішень про запуск, і наївний базовий рівень, що використовує частоти з попереднього розгортання як оцінки для нової моделі.

Джерела похибки симуляції в нашому конвеєрі. Ми також дослідили поточні джерела похибок у нашому конвеєрі. Зокрема, великі кінцеві похибки роблять конвеєр менш надійним для рішень щодо розгортання: наприклад, коли ми бачимо великий прогнозований приріст небажаної поведінки певного типу, якщо відомо, що конвеєр має навіть поодинокі великі похибки, це породжує сумнів, чи є це надійною оцінкою, чи артефактом конвеєра. Є два основні джерела можливої похибки:

• Похибка точності середовища повторного вибирання: щоб точно оцінювати виробничі частоти, наш конвеєр симуляції має бути максимально реалістичним. Це частково інженерна проблема (вибірка з моделі з використанням тих самих конвеєрів, що й для виробничого трафіку), а частково цікавий виклик для інструментів, яким потрібен доступ на читання/запис до зовнішніх ресурсів, що постійно змінюються (наприклад, вебпошуки або взаємодія з локальними файлами). Ми можемо ізолювати похибку точності симуляції, порівнявши прогнози з фактичного розгортання та його симуляції (тобто симулюючи розгортання вже розгорнутої моделі).
• Похибка зсуву розподілу запитів: головне занепокоєння щодо Симуляції розгортання полягає в тому, що розгортання будь-якої моделі спричинить розподільчий зсув у вхідних даних, особливо якщо користувачі адаптуються до нових можливостей моделі. Ми ізолюємо похибку розподілу запитів, порівнюючи оцінки під час симуляції розгортання з використанням нещодавніх запитів і запитів із реалізованого розгортання.

Як видно на рисунку 4, ми виявили, що велика частка похибки в нашому конвеєрі — особливо для кінцевих похибок — нині зумовлена точністю симуляції. Це хороша новина, оскільки ми очікуємо, що точність симуляції загалом легше покращити, ніж зменшити зсув розподілу запитів. Ми також виявили, що похибку зсуву розподілу запитів можна зменшити, використовуючи найсвіжіші дані з попереднього розгортання. Більше деталей можна знайти в дослідницькій статті.

Автоматизований аудит знайшов одну нову неузгодженість, запроваджену в цих розгортаннях. У вікні розгортання, яке ми вивчали, наш автоматизований аудиторський конвеєр на основі симульованих розгортань виявив би «злам калькулятора» до випуску — це була єдина нова неузгодженість, яку ми ідентифікували в проаналізованому трафіку ChatGPT. Злам калькулятора — це форма злому винагороди, коли модель використовує інструмент браузера як калькулятор, представляючи цю дію як пошук. Це не означає, що великомасштабний аудит упіймає кожен новий збій, але показує, чому реалістичні контексти важливі: вони можуть викликати поведінку, яку вужчі набори оцінювань можуть ніколи не виявити напряму, навіть якщо її не було в початковому трафіку, використаному для засівання симуляції.

Ще одна перевага використання подібних до розгортання контекстів полягає в тому, що вони можуть зменшувати спотворення, які виникають, коли моделі розпізнають, що їх тестують. У попередньому дослідженні ми, а також інші автори⁠(відкривається у новому вікні) виявили, що моделі часто усвідомлюють, коли їх тестують. Наприклад, моделі можуть міркувати у своєму ланцюжку міркувань про те, що саме в них тестують, що може сподобатися оцінювачу, і — якщо вони поводяться неправильно — чи їх викриють. Це створює проблему для оцінювань узгодження: якщо модель поводиться добре лише тому, що вважає, ніби її тестують, як нам здобути впевненість, що вона поводитиметься безпечно після того, як дізнається, що її розгорнули?

Ми показуємо, що Симуляція розгортання суттєво знижує рівні обізнаності про оцінювання, які демонструють моделі, порівняно з традиційними оцінюваннями, не заснованими на реальних даних розгортання. Ми вимірюємо обізнаність про оцінювання трьома способами: просимо модель класифікувати, чи траєкторія походить із виробничого середовища чи оцінювання, відстежуємо ланцюжок міркувань на предмет явних тверджень про оцінювання узгодження, а також метагеймінгу⁠(відкривається у новому вікні): будь-яких міркувань про нагляд. Симульований трафік розгортання був дуже близьким до реального трафіку розгортання за всіма трьома показниками. Наприклад, GPT‑5.2 позначав реальний виробничий трафік як подібний до оцінювання у 5,4% випадків, а симульований трафік — у 5,1% випадків, тоді як традиційні оцінювання (як-от SWE-Bench або MonorepoBench, що складаються переважно із синтетичних прикладів) класифікувалися як оцінювання майже у 100% випадків.

Щоб перевірити, чи може метод виходити за межі стандартних режимів чату, ми також вивчали симуляцію розгортань для складних налаштувань автономної розробки коду. Зокрема, ми використовуємо 120 000 внутрішніх агентних траєкторій співробітників із GPT‑5.4, щоб симулювати внутрішнє розгортання агентів кодування на основі GPT‑5.5. Це має дві цілі: показує, як симуляцію розгортання також можна використовувати для оцінювання ризиків внутрішніх розгортань, і демонструє, що можна досягти високої точності симуляції навіть в агентних налаштуваннях завдяки ретельній симуляції інструментів.

Вище ми обговорювали, що точність симуляції є одним із головних джерел похибки в нашому поточному конвеєрі. Одна зі складностей у тому, щоб зробити симуляції розгортання реалістичними, полягає в потребі, щоб інструменти діяли реалістично, навіть коли їм потрібен доступ на читання/запис до зовнішніх ресурсів, які постійно змінюються (наприклад, вебпошуки або взаємодія з локальними файлами).

Це особливо складно для таких налаштувань, як агентні розгортання: одна траєкторія агента може залежати від сотень викликів інструментів, стану репозиторію, мережевих відповідей або тимчасових збоїв. Це робить повторне вибирання з реальним доступом до інструментів і складним, і потенційно небезпечним. З огляду на це, замість застосування викликів інструментів до живих систем ми симулюємо їх за допомогою іншої LLM. Ми показуємо, що надання цій LLM додаткових можливостей є суттєвим для реалістичності, а отже й для якості оцінювання.

Ми даємо моделі-симулятору інструментів початковий фінальний етап розгортання, репозиторій на момент розмови, базу даних пар виклик інструмента/відповідь і конектори лише для читання. У тесті, де дискримінатор намагався відрізнити симульовані розгортання від реальних, реалістичність сприяла зростанню показника успішності з 11,6% до 49,5%, майже до випадкового рівня 50%.

Як додатковий доказ точності симуляції, під час симулювання трафіку GPT‑5.4 Codex thinking за допомогою GPT‑5.4 рівні неузгодженості майже перебувають у межах похибки. Натомість у нашому тестуванні перед розгортанням GPT‑5.5 був більш неузгодженим у більшості категорій.

Ці результати свідчать, що Симуляцію розгортання можна поширити на складні налаштування агентів, коли навколишнє інструментальне середовище симулюється з достатньою точністю.

Природне запитання полягає в тому, чи можуть зовнішні аудитори отримати частину тих самих переваг без доступу до приватного виробничого трафіку. Ми перевірили це на 100 000 розмов WildChat, використаних як префікси. WildChat був менш точним, ніж нещодавні виробничі дані OpenAI, але все ще інформативним: нещодавні виробничі дані мали нижчу середню мультиплікативну похибку, ніж WildChat (1,75× проти 2,44×), тоді як WildChat часто залишався приблизно в межах 3× від виробничих частот і визначав кращу модель на рівнях вище випадкових. Ми розглядаємо оцінювання в стилі WildChat як перспективне доповнення до Симуляції розгортання, яку запускають розробники. Більше результатів щодо цього пункту див. в цьому супровідному дописі блогу Alignment⁠(відкривається у новому вікні).

Симуляція розгортання є доповненням, а не заміною змагальних оцінювань, red-teaming і цільового аналізу кінцевих ризиків. Виявлення деяких небажаних проявів поведінки моделі спирається на можливість моніторингу ланцюжка міркувань: якщо майбутні моделі міркуватимуть менш розбірливо, пропускатимуть ключові кроки або навчаться приховувати намір, ми можемо не змогти виявити ці форми небажаної поведінки. Крім того, оскільки виробничі дані приватні, розробники нині мають сильніший доступ до репрезентативних контекстів, ніж зовнішні аудитори. Кращі публічні набори даних могли б звузити цей розрив.

Симуляція розгортання найкорисніша для поведінки, що трапляється достатньо часто, щоб з’явитися у вибраних префіксах. Збій, який трапляється один раз на десять мільйонів розмов, навряд чи буде виявлено в запуску на мільйонній вибірці, тож змагальні оцінювання, red-teaming і цільовий аналіз кінцевих ризиків залишаються необхідними. Нині ми зосереджуємося на симулюванні однієї відповіді асистента, оскільки в попередніх експериментах не виявили суттєвих покращень наших оцінок від симуляції кількох ходів. У майбутньому це може бути важливою сферою для покращення точності симуляції.

Метод також залежить від розподілу префіксів — суміші розмов, які повторно вибираються. Історичний трафік може не відповідати тому, як користувачі взаємодіють із потужнішою моделлю після великої зміни продукту, випуску нового інструмента, світової події або сезонного зсуву. Аналіз у повній статті свідчить, що цю проблему можна пом’якшити, використовуючи найсвіжіші доступні дані.

Симуляція розгортання — це новий підхід до оцінювання ризиків перед розгортанням, який допомагає провідним лабораторіям і оцінювачам прогнозувати, як мовні моделі можуть поводитися в реальному світі, і розуміти ризики, які вони створюють, до розгортання. Вона доповнює наявні оцінювання безпеки, red-teaming і цільовий аналіз, додаючи більш подібний до виробництва шар прогнозування, який може покращити оцінки поведінки під час розгортання, зменшити ефекти обізнаності про оцінювання й зробити прогнози до розгортання перевірними після випуску. У поєднанні з традиційними оцінюваннями Симуляція розгортання може допомогти зробити оцінювання ризиків моделі реалістичнішим, кількіснішим і кориснішим для рішень щодо розгортання.