Версии моделей: как переживать обновления без сюрпризов

Однажды утром система начинает отвечать иначе. Код не менялся, промпт не трогали, данные те же. Причина почти всегда одна: обновилась модель.

Почему это происходит незаметно

Провайдеры выпускают обновления регулярно, и часть из них подтягивается автоматически, если вы обращаетесь к модели по общему имени, а не по конкретной версии.

Обновление обычно улучшает общее качество — и одновременно меняет поведение в частностях. Формулировки становятся длиннее, структура ответа немного другая, а промпт, отлаженный под прежнюю версию, работает чуть хуже.

Ломается это тише, чем обновление библиотеки: код не падает, тесты на синтаксис проходят, ошибок в журнале нет. Есть только ответы, которые стали чуть менее удачными.

Закрепляйте версию

Правило простое: в прототипе можно обращаться к общему имени, в продакшене — только к конкретной версии.

Закреплённая версия превращает обновление из события, которое с вами случается, в решение, которое вы принимаете. Разница принципиальная: во втором случае вы выбираете момент и успеваете проверить.

Обратная сторона — версии не живут вечно. Провайдеры выводят старые из обращения, обычно предупреждая заранее. Поэтому закрепление не отменяет обновлений, а переносит их в управляемый режим.

Порядок перехода

Отдельно стоит проверить структурированный вывод и вызов функций. Это самые хрупкие места: изменения там заметны не по качеству текста, а по тому, что код перестаёт разбирать ответ.

Что записывать

Версию модели — в журнал каждого запроса. Без этого поля объяснить «раньше работало лучше» невозможно, а с ним разбор занимает пять минут.

Версию промпта — рядом с кодом, в репозитории. Промпт и модель образуют пару: сравнивать качество имеет смысл только тогда, когда вы знаете обе половины.

Тестовый набор — обязательное условие

Без набора примеров переход на новую версию превращается в лотерею: кто-то посмотрел на десяток ответов, решил, что нормально, и выкатил.

Тридцати-пятидесяти примеров с эталонами достаточно, чтобы увидеть разницу в цифрах. Прогон на новой версии занимает минуты и стоит копейки — несопоставимо с ценой откатывания продакшена через неделю.

Если новая версия дала на вашем наборе результат хуже, это не повод в неё не переходить. Это повод сначала поправить промпт под неё, а потом сравнить ещё раз.

Не только качество

При смене версии проверяйте три вещи помимо содержания ответов.

**Цену.** Ставки у новых версий отличаются, иногда в большую сторону.

**Скорость.** Более способная модель обычно медленнее, и это заметно в интерфейсе.

**Лимиты.** У новых версий бывают другие пороги по запросам и токенам в минуту.

Держите возможность вернуться

Название модели должно лежать в конфигурации, а не в коде. Тогда откат — это правка одной строки и перезапуск, а не релиз.

Ту же логику полезно распространить на всё окружение вызова: модель, версия, промпт и параметры генерации собираются в одном месте. Это упрощает и переход, и сравнение, и разбор инцидентов.

Как узнать об обновлении заранее

Обновления редко бывают внезапными: провайдеры объявляют их и обычно дают срок на переход. Проблема в том, что объявление проходит мимо команды.

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

Второй источник — ваш собственный журнал. Если вы пишете версию модели по каждому запросу, неожиданная смена значения в этом поле обнаруживается автоматически. Настройте уведомление на такое изменение — оно поймает и те обновления, о которых вы пропустили объявление.

Когда версию выводят из обращения

Рано или поздно закреплённая версия перестаёт поддерживаться. Порядок действий тот же, что при обычном переходе, но с поправкой на срок.

Не откладывайте до последней недели. Если новая версия потребует правки промпта, а она потребует, вам понадобится время на подгонку и прогон тестового набора.

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

Короткий вывод

Закрепите версию, положите её в конфигурацию, записывайте в журнал и проверяйте тестовым набором перед каждым переходом. Четыре простых правила, которые превращают обновление модели из неприятного сюрприза в обычную рабочую процедуру.

Полезно фиксировать и параметры генерации рядом с версией. Температура, ограничение длины ответа и формат вывода влияют на результат не меньше, чем сама версия модели, а меняют их часто и не задумываясь. Когда все четыре величины лежат в одном месте конфигурации, сравнение двух прогонов становится честным: вы точно знаете, что именно отличалось.