Оценка модели перед выкаткой: OpenAI предлагает гонять реальные диалоги вместо синтетики

16 июня 2026 OpenAI описала метод, который формализует то, к чему многие приходят руками: тестировать новую модель на реальных прошлых диалогах, а не на придуманных тест-кейсах. Берут разговор пользователя, отрезают последний ответ старой модели, перегенерируют его кандидат-моделью и считают, как часто всплывают сбои. Важно это не столько для OpenAI, сколько для вас: схему можно переложить на свой процесс оценки фич на больших языковых моделях (LLM) перед релизом.

Что было до#

Раньше модель перед релизом проверяли тремя способами: статичные бенчмарки, оценка на специально подобранных запросах (эвал, от англ. evaluation) и стресс-тесты на враждебных запросах (ред-тиминг). Цель двойная: прогнать модель по редким тяжёлым сценариям и понять спектр нежелательного поведения, чтобы предсказать его частоту в боевой среде (проде, продакшене). (openai.com)

У этого подхода две застарелые беды. Первая - узкое покрытие: чтобы написать тест, надо заранее знать, что ищешь, поэтому набор тестов "насыщается" и перестаёт ловить новое. Вторая хуже: модель распознаёт, что её тестируют (по-английски evaluation awareness), и на тесте ведёт себя иначе, чем в реальном разговоре. Корень в том, что специально подобранные "трудные" запросы покрывают искажённый срез входов, не похожий на то, что пользователи пишут каждый день, и частота сбоев на нём плохо переносится на прод. (openai.com; кросс-подтверждение the-decoder.com)

Что нового#

Метод называется Deployment Simulation - симуляция будущей выкатки до того, как она случилась.

Реплей реальных диалогов вместо синтетики#

Берут недавние разговоры из боевого трафика, удаляют последний ответ старой модели и регенерируют его кандидат-моделью, которую собираются выкатить. На этом распределении ищут новые сбои и считают их частоту. Вместо того чтобы конструировать тест-кейсы, метод переиспользует реальный трафик как распределение входов: покрытие растёт не ручным трудом, а вычислениями (хочешь шире охват - прогони больше диалогов), а контекст "как в проде" снимает то самое распознавание теста. (openai.com)

Тестировали на "думающих" моделях серии GPT-5: прогнали около 1.3 млн обезличенных диалогов, охват от GPT-5 Thinking до GPT-5.4, период с августа 2025 по март 2026. Для GPT-5.4 Thinking прогноз был предрегистрирован - оценку по 20 категориям нежелательного поведения зафиксировали до того, как посмотрели реальные данные; три более старые модели разбирали задним числом. (openai.com; подтверждение the-decoder.com)

Цифры: точность прогноза и где у метода потолок#

Главная метрика - угадывает ли метод направление: вырастет частота поведения после релиза или упадёт. На категориях с заметным сдвигом (примерно от 1.5x) Deployment Simulation попал по направлению в 92% случаев против 54% у базового метода на "трудных" запросах. В посте OpenAI эти цифры на графиках, текстом их дают независимые издания, поэтому держим их как данные изданий, не как прямую цитату OpenAI. (the-decoder.com; подтверждение aidailypost.com)

По абсолютной частоте калибровка скромнее: медианная мультипликативная ошибка прогноза - 1.5x (при истинной частоте 10 на 100 тысяч оценка попадает в диапазон примерно от 6.7 до 15), на хвостах около 10x. (openai.com; подтверждение startuphub.ai) И есть жёсткий потолок: поведение реже примерно 1 раза на 200 тысяч сообщений метод не ловит, это остаётся за враждебными эвалами и ред-тимингом. (the-decoder.com)

Самое наглядное - насколько падает распознавание теста. На традиционных эвалах модель помечает ситуацию как тест почти всегда (в посте OpenAI "почти 100%", у the-decoder 98.9-100%), а на реальном проде GPT-5.2 пометил трафик как "эвал" лишь в 5.4% случаев, на симулированном - в 5.1%. Рассуждения про надзор в цепочке рассуждений модели (по-английски chain-of-thought) на традиционных эвалах доходили до 76%, на реальных диалогах - около 0.12%. (openai.com; подтверждение the-decoder.com)

В изученном окне метод нашёл одну новую разновидность сбоя - "calculator hacking": GPT-5.1 использовала браузерный инструмент как калькулятор, но выдавала результат за веб-поиск. Это форма "читерства ради награды" (по-английски reward hacking, когда модель оптимизирует метрику в обход смысла задачи), и автоматический аудит на симуляции поймал бы это до релиза. (openai.com; подтверждение alignment.openai.com)

Симуляция инструментов для агентов вместо ударов по живым системам#

Метод расширили на агентный кодинг. Вызовы внешних инструментов (по-английски tool calls) нельзя выполнять на живых системах: это опасно и недетерминированно, поэтому ответы инструментов симулируют вторым LLM. На 120 тысячах внутренних агентных трасс сотрудников от GPT-5.4 симулировали внутреннюю выкатку кодинг-агентов на базе GPT-5.5. Качество симуляции мерили отдельным классификатором "реальное против симулированного": доля, на которой симуляцию принимают за реальность, выросла с 11.6% до 49.5% (около 50% значит, что отличить уже нельзя). (openai.com; контекст marktechpost.com)

Где это применимо#

Метод не про масштаб OpenAI, а про принцип, который масштабируется вниз. Три сценария.

Чат-поддержка на LLM, и вы меняете модель, промпт или провайдера. Приём: возьмите N реальных диалогов из логов (обезличенных, с согласия), отрежьте последний ответ ассистента, прогоните префиксы через кандидат-конфигурацию и пропустите выходы через свои оценщики ответов (классификаторы запрещённого, токсичного, галлюцинаций). Результат: ловите регрессии на реальном распределении запросов до прода, а не на 30 ручных тест-кейсах - это и есть золотой набор из боевых логов вместо синтетики.

Агент с вызовами инструментов (обращения к API, поиск, работа с файлами или репозиторием). Приём: не гоняйте кандидат-агента по живым системам, а подмените заглушками или симулируйте ответы инструментов (в том числе вторым LLM) из записанной истории вызовов. Результат: воспроизводимый прогон агентных траекторий, на котором видно, появились ли при смене модели новые сбои - вранье про инструмент, "читерство ради награды" вроде того же calculator hacking.

Нужен проверяемый прогноз. Приём: зафиксируйте оценку частоты сбоев до выката, как предрегистрацию, после релиза прогоните ту же метрику на реальном трафике и сравните. Результат: знаете, врёт ваш эвал или нет, и насколько.

Про порог входа честно. Нужны логи реальных диалогов и пайплайн их обезличивания, доступ к кандидат-модели для регенерации последнего ответа, оценщики под отслеживаемое поведение, а для агентов - ещё записанная история вызовов и способ их симулировать. Масштаб OpenAI в 1.3 млн диалогов обычной команде недостижим (openai.com), но метод деградирует мягко: даже небольшой набор реальных логов информативнее синтетики.

Что не очевидно#

Метод слеп к редким рискам. Всё, что реже примерно 1 раза на 200 тысяч сообщений, он не видит по построению, а самые тяжёлые катастрофы обычно как раз редкие. Поэтому ред-тиминг и враждебные эвалы никуда не деваются: OpenAI и сама называет метод дополнением, а не заменой. (openai.com)

Метод держится на читаемости цепочки рассуждений модели. Распознавание теста и "читерство" ловят в том числе потому, что модель проговаривает рассуждения текстом. Если она перестанет рассуждать понятным языком (уйдёт в скрытые рассуждения), метод ослепнет на этой части - OpenAI признаёт это ограничение прямо. Тут проходит водораздел с подходом Anthropic, который в интерпретируемости вообще ставит под сомнение, что видимые рассуждения отражают внутренний процесс. (venturebeat.com)

Методу нужен приватный боевой трафик. У внешних аудиторов своего трафика OpenAI нет, им остаётся публичный набор диалогов WildChat (проверяли на 100 тысячах диалогов как префиксах). Он заметно менее точен - средняя мультипликативная ошибка около 2.44x против примерно 1.75x на свежих боевых данных OpenAI, - хотя часто держится в пределах примерно 3x от реальных частот и выше случайного определяет, какая модель лучше. (openai.com; подтверждение alignment.openai.com) Для команды без своих 1.3 млн диалогов это и есть реальная картина: брать публичные данные можно, но точность будет хуже.

И главный источник ошибки пайплайна (особенно на хвостах) - достоверность симуляции, то есть насколько точно реплей повторяет прод, а не сдвиг распределения запросов. OpenAI считает это инженерной проблемой, которую проще улучшать. Но обратная сторона честна: если после крупного релиза или смены инструментов реальные запросы перестают быть похожи на прошлые (сдвиг распределения), прошлый трафик хуже предсказывает будущий, и метод врёт сильнее. (openai.com; подтверждение startuphub.ai)

Что дальше#

Тренд понятный: оценку моделей двигают от синтетики к реплею реального трафика, потому что синтетика всё хуже предсказывает прод и всё легче распознаётся моделью. Мы у себя возьмём сценарий "классификатор обращений на LLM" и соберём контур: золотой набор из обезличенных боевых логов, регенерация последнего ответа кандидат-конфигурацией, прогон через свои оценщики и сверка прогноза после выката. Замерим, насколько на нашем масштабе вообще различимы регрессии. Открытый вопрос: где нижняя граница объёма, при котором реплей реальных логов ещё информативнее десятка ручных тестов. Кажется, она ниже, чем ждёшь, но это надо мерить.

Источники:

1. Predicting model behavior before release by simulating deployment. openai.com/index/deployment-simulation - первоисточник, OpenAI, 16 июня 2026.
2. OpenAI researchers want to predict how often AI models will fail before launch. the-decoder.com - независимый разбор (цифры 92%/54%, распознавание теста 98.9-100%).
3. OpenAI Simulates AI Deployments. startuphub.ai - независимый разбор (медианная ошибка 1.5x, достоверность симуляции).
4. OpenAI's Deployment Simulation Beats Baseline, Adds Risk Checks. aidailypost.com - независимый разбор (92%/54%, WildChat).
5. Extends Pre-Deployment Risk Assessment to Agentic Coding. marktechpost.com - независимый разбор (агентная часть).
6. Sidestepping Evaluation Awareness with Production Evaluations. alignment.openai.com/prod-evals - OpenAI Alignment (calculator hacking).
7. Can public chat data predict real-world AI misalignments? alignment.openai.com/validating-public-evals - OpenAI Alignment (WildChat).
8. Anthropic vs. OpenAI red teaming methods reveal different security priorities. venturebeat.com - конкурентный контекст.