Deployment Simulation: как проверить смену AI-модели до выпуска
OpenAI описала проверку новой модели на контекстах реальных диалогов. Как составить собственный replay-набор и отличить ошибку модели от сбоя API.
Как работает Deployment Simulation
16 июня 2026 года OpenAI описала метод оценки модели до выпуска: из прошлых диалогов убирают ответ прежней модели, получают ответ кандидата и оценивают нежелательное поведение. Исследование использует обезличенные данные пользователей, разрешивших улучшение моделей, и дополняет целевые тесты и red teaming. Это исследование OpenAI, а не измерение API429.
Пример replay-набора для приложения
В собственном приложении начните с задач, для которых можно проверить правильность ответа. Ниже учебный формат записи, а не результат проведённого эксперимента:
{
"case_id": "invoice-001",
"input": "Сумма счёта: 1200 RUB. Извлеки сумму и валюту.",
"expected": {"amount": 1200, "currency": "RUB"},
"checks": ["valid_json", "amount_equal", "currency_equal"]
}
Отправьте один и тот же набор текущей модели и кандидату. Храните версии моделей, параметры запроса и результат каждой проверки. В журналах отделяйте неправильный ответ от HTTP-ошибки, таймаута и отказа инструмента. Данные предварительно обезличьте, а операции инструментов выполняйте в тестовом контуре: воспроизведение не должно повторно создавать реальные заказы или платежи.
Как принять решение о переключении
| Проверка | Что записать | Решение команды |
|---|---|---|
| Правильность | Пройденные проверки по каждому примеру | Допустимый уровень регрессии |
| Ответ API | Ошибки, таймауты, задержка | Бюджет ожидания и повторов |
| Стоимость | Расход токенов и фактическая цена | Допустимая стоимость задачи |
| Инструменты | Аргументы и результат вызова | Какие действия требуют подтверждения |
Пороги выбирают до теста под требования приложения. Успешный небольшой набор не исключает редких ошибок; опасные сценарии проверяют отдельно. Перед подключением кандидата сверьте его идентификатор в каталоге моделей и формат запроса в документации API429. Схему постепенного переключения и отката нужно реализовать и проверить в своём приложении.
Комментарий API429
Сравнивайте модели на неизменном наборе входов и сохраняйте результаты отдельных проверок. Средняя оценка без примеров ошибок затрудняет решение, какую регрессию можно принять, а какую нужно исправить до переключения.
Источники и документация
Следующий шаг — на практике.
Перед интеграцией проверьте ID модели, актуальную цену и формат запроса. Доступность зависит от модели и маршрута провайдера.
