Новая модель вышла: как перейти без поломки продукта
Новая модель почти всегда обещает больше качества и меньшую цену. Переключить продакшен в день релиза легко, но риск часто скрывается не в красивом ответе, а в формате, задержке, лимитах и редком исключении. Безопасная миграция — это управляемый эксперимент с заранее заданным решением «оставить, расширить или откатить», а не вера в график из анонса.
Сформулируйте причину перехода
Запишите, какую проблему должна решить новинка: пропуски в длинном документе, стоимость повторных вызовов, медленная обработка или отсутствующая функция. Если текущая модель уже даёт принятый результат, «вышла новая» не является достаточным основанием. Опишите целевой показатель и порог, после которого переход окупается.
Разделите качество и совместимость. Модель может быть точнее, но сломать JSON-парсер, тон письма или вызов инструмента. Оба измерения нужны в решении.
Подготовьте контрольную выборку
Возьмите двадцать–тридцать обезличенных запросов из реального процесса. Включите обычный сценарий, длинный вход, вопрос без ответа, конфликтующие инструкции, смешение языков и данные, на которых старая версия ошибалась. Для каждого укажите эталон, обязательные поля и недопустимый результат.
Не меняйте промпт и параметры во время сравнения. Запустите старую и новую модель бок о бок, сохраните необработанные ответы, версию, дату и число попыток. Оцените факты, полноту, корректный отказ, формат и время редактора до принятого результата.
Проверьте формат и контекст
Если продукт разбирает JSON, проверьте обязательные ключи, порядок, кавычки, числовые типы и лишний текст. Для function calling протестируйте названия инструментов, схему аргументов и реакцию на ошибку. Для длинных документов поставьте маркеры в начале, середине и конце и убедитесь, что исключения не исчезают.
Отдельно проверьте русский язык: склонения, даты, десятичный разделитель, идентификаторы и смешение кириллицы с латиницей. Связный стиль не компенсирует изменённое число или пропущенное «не».
Посчитайте реальную стоимость
Сравнивайте цену принятого результата, а не одного токена. Включите входной и выходной объём, повторы, кэш, хранение файлов, время проверки и исправления. Новая модель может писать длиннее и съесть экономию меньшей ставки. Для расчёта используйте реальный трафик, а не пример из релиза.
Измерьте задержку первого токена и полный маршрут до готового ответа. Для чата и голосового интерфейса более умная, но медленная модель может ухудшить опыт. Проверьте лимиты параллельных запросов и поведение при пике.
Сверьте условия доступа
Зафиксируйте канал — API, веб-интерфейс или командный тариф — и точный идентификатор версии. Уточните контекст, регион, хранение истории, доступ к инструментам и срок поддержки. Одинаковое название не гарантирует одинаковые ограничения. Если модель в preview, добавьте резервный маршрут и владельца миграции.
Сделайте адаптер
Спрячьте имя модели и параметры за единым интерфейсом приложения. Конфигурация должна меняться в одном месте, а журнал — сохранять фактическую версию. Так смена кандидата не превращается в переписывание промптов, тестов и интеграций. Старую модель не удаляйте до окончания периода наблюдения.
Запустите канарейку
Сначала направьте новую версию на тестовый трафик или 5–10% внутренних запросов. Сравнивайте ошибки, ручные правки, стоимость, задержку и жалобы с контрольной группой. Не включайте канарейку для всех чувствительных документов без проверки политики хранения.
Порог остановки задайте заранее: невалидный формат, рост фактических ошибок, вызов запрещённого инструмента или превышение бюджета. При срабатывании переключение назад должно занимать одну настройку. Сохраните пример сбоя, а не только успешные ответы.
Расширяйте постепенно
Если канарейка стабильна, увеличивайте долю по этапам. После каждого шага повторяйте контрольные вопросы и проверяйте новый тип данных. Не расширяйте охват сразу после одного хорошего дня: редкие ошибки проявляются на длинном хвосте запросов.
Через неделю сравните медиану и худший случай. Через две недели повторите три задачи на новых входах. Если улучшение существует только на рабочем наборе, вернитесь к тестированию промпта или данных.
Проведите репетицию отката
Откат стоит проверять до канарейки, а не во время инцидента. В тестовой среде поменяйте конфигурацию на новую, отправьте несколько запросов, затем верните старый идентификатор и убедитесь, что журнал показывает фактическую версию. Проверьте также незавершённый запрос, очередь и кэш: часть результата может прийти уже после переключения. Зафиксируйте время возврата и список ручных действий. Если для отката нужно менять код, искать секреты или перезапускать несколько сервисов, миграция ещё не готова. Одной настройки и понятного владельца обычно достаточно для обратимого пилота.
Когда можно перейти быстрее
Быстрый переход допустим для прототипа, внутреннего инструмента с обратимым результатом и мягкими требованиями к формату. Нужны резервная версия, чистые тестовые данные и готовность откатить конфигурацию. Даже внутри одного семейства проверьте изменение отказов и лимитов.
Когда лучше подождать
Пауза нужна для критичного продакшена с платящими клиентами, строгим SLA, юридическими документами и необратимыми действиями. Без контрольного набора и владельца миграции вы не узнаете, стало ли лучше. Модель, помеченная preview или experimental, не должна быть единственной зависимостью.
Чек-лист перехода
- Причина и измеримый порог перехода записаны.
- Есть обезличенная выборка с краевыми случаями.
- Старая и новая версии запущены в одинаковых условиях.
- Проверены формат, инструменты, русский язык и контекст.
- Посчитаны стоимость принятого результата и задержка.
- Канал доступа, версия и политика хранения зафиксированы.
- Конфигурация скрыта за адаптером, резерв сохранён.
- Канарейка имеет метрики, стоп-условия и быстрый откат.
Переход стоит делать не потому, что модель новее, а когда собственный тест показывает измеримую пользу без неприемлемого роста риска. Такой процесс позволяет пользоваться улучшениями и не ставить рабочий продукт на удачу одного релизного дня.