Модель придётся менять. Не «возможно», а придётся: изменятся цены, выйдет версия лучше, поставщик изменит условия или станет недоступен. Вопрос только в том, займёт это день или месяц.
Разница определяется тем, что сделано до необходимости менять. После — поздно: если система привязана к конкретной модели, миграция превращается в отдельный проект с непредсказуемым сроком.
Что ломается при смене
Интерфейс — наименьшая из проблем и решается шлюзом. Ломается другое.
Промпты. Формулировка, отлично работавшая на одной модели, на другой даёт худший результат. Модели по-разному реагируют на структуру инструкции, на примеры, на порядок изложения.
Соблюдение формата. Разные модели по-разному держат схему ответа. Конвейер, полагавшийся на строгий формат, начинает ловить сбои разбора — «Структурированный вывод модели».
Многословность. Одна модель отвечает кратко, другая развёрнуто. Меняются и стоимость, и вид результата для пользователя.
Стиль отказов. Модели по-разному отказываются отвечать. То, на что одна отвечала спокойно, другая может отклонить.
Длина контекста. Если новая принимает меньше, придётся менять то, сколько текста передаётся.
Скорость. Влияет на пользовательские сценарии и на настройки таймаутов.
Токенизация. Один и тот же текст даёт разное число токенов у разных моделей — расчёт стоимости меняется даже при одинаковой цене за токен.
Отдельно про эмбеддинги. Смена модели векторизации требует переиндексации всего корпуса: векторы разных моделей несравнимы — «Эмбеддинги для русского». Это не миграция, а отдельная операция.
Что подготовить заранее
Четыре вещи, каждая недорогая, вместе превращающие миграцию в рутину.
1. Единая точка обращения. Все вызовы через один слой. Без этого всё остальное бессмысленно.
2. Контрольный набор. 50–100 реальных задач с известным правильным результатом. Главный инструмент миграции: он отвечает на вопрос «стало ли хуже» за часы — «Тестирование модели на своей задаче».
3. Промпты отдельно от кода. С версиями и возможностью иметь разные варианты под разные модели — «Версионирование промптов».
4. Журнал обращений. Чтобы сравнивать поведение до и после на реальных запросах.
Порядок миграции
Шаг 1. Прогнать контрольный набор на новой модели со старыми промптами. Это опорная точка: видно, где просело.
Шаг 2. Подстроить промпты там, где просело, и прогнать снова. Часто разрыв закрывается именно здесь, без смены решения.
Шаг 3. Проверить формат отдельно, если конвейер на него опирается. Доля нарушений схемы — самостоятельная метрика.
Шаг 4. Посчитать стоимость на реальных объёмах: другая токенизация и другая многословность меняют счёт.
Шаг 5. Проверить под нагрузкой, если поток заметный — «Нагрузочное тестирование».
Шаг 6. Переключить частично. Небольшую долю потока на новую модель, сравнить поведение на реальных запросах.
Шаг 7. Переключить полностью, сохранив возможность вернуться.
Шаг 8. Не убирать старую модель сразу. Неделя-две параллельной доступности — дешёвая страховка.
Разбор: миграция, которая едва не сорвалась
Задача. Конвейер обработки документов: извлечение полей в строгом формате. Смена модели по причине изменения цен.
Шаг 1 показал. На контрольном наборе из 120 документов новая модель дала результат чуть хуже по доле верно извлечённых полей. Разница выглядела приемлемой.
Что едва не пропустили. Доля верных полей упала незначительно, а доля ответов, нарушивших схему, выросла в несколько раз. Эта метрика считалась отдельно — и только поэтому её увидели.
В конвейере нарушение схемы означало отправку операции в очередь разбора. То есть формально качество почти не изменилось, а фактически нагрузка на людей выросла бы заметно.
Что сделали. Разобрали нарушения: новая модель чаще добавляла пояснение перед структурой ответа. Перешли на передачу схемы вместо просьбы в промпте — модель это поддерживала, просто изначально использовался старый способ.
После этого доля нарушений стала ниже, чем была на прежней модели.
Второе, что нашли на шаге 4. Стоимость операции оказалась выше расчётной примерно на четверть, хотя цена за токен была ниже. Причина — другая токенизация: русский текст разбивался на большее число токенов.
Пересчитали. Выигрыш остался, но вдвое меньше ожидаемого — и это уже было честное основание для решения, а не приятное заблуждение.
Итог. Миграция заняла два дня вместо запланированного одного. Оба дня ушли на то, что обнаружилось при проверке, — и без проверки обнаружилось бы в эксплуатации.
Что стоит забрать. Общая доля верных ответов — недостаточная метрика для миграции. Считать надо отдельно: соблюдение формата, стоимость операции на реальных текстах, поведение на нестандартных входах.
Частичная миграция
Часто лучший вариант — не менять модель целиком.
По шагам конвейера. Классификация на дешёвой, сложное рассуждение на прежней. Проверяется по классам задач.
По доле потока. Часть запросов на новую модель, сравнение поведения на реальных данных.
По типу задач. Массовые простые — на новую, редкие сложные — на прежнюю.
Требует общего слоя доступа, но даёт возможность мигрировать постепенно и с возвратом на любом шаге.
Частые вопросы
Что нужно, чтобы смена модели не превратилась в проект?
Четыре вещи, подготовленные заранее: все обращения через одно место в коде, контрольный набор реальных задач с известными результатами, промпты отдельно от кода и журнал обращений. С ними миграция занимает день-два, без них — недели.
Будут ли работать старые промпты на новой модели?
Частично. Формулировка, отлично работавшая на одной модели, на другой обычно даёт результат хуже: модели по-разному реагируют на структуру инструкции и примеры. Разумный порядок — сначала прогнать как есть, чтобы увидеть опорную точку, затем подстраивать там, где просело.
Как понять, что новая модель не хуже?
Прогнать контрольный набор и сравнить по нескольким метрикам отдельно: доля верных ответов, соблюдение строгого формата, поведение на нестандартных входах, стоимость операции. Общая доля верных ответов может почти не измениться, а доля нарушений формата вырасти в разы — и в конвейере это критично.
Изменится ли стоимость, если цена за токен ниже?
Не обязательно в ожидаемую сторону. Разные модели по-разному разбивают текст на токены, и русский текст может давать заметно больше токенов у одной модели, чем у другой. Считать нужно на своих реальных текстах, а не по прайсу.
Нужно ли переиндексировать документы при смене модели?
При смене генеративной модели — нет. При смене модели векторизации — да, весь корпус: векторы разных моделей несравнимы между собой. Это стоит планировать отдельно, потому что на больших объёмах операция заметная.
Можно ли мигрировать постепенно?
Да, и это обычно разумнее: переключить часть шагов конвейера или часть потока, сравнить поведение на реальных данных и расширять долю. Требует общего слоя доступа к моделям, зато позволяет вернуться назад на любом шаге.
Что дальше
Слой, без которого миграция невозможна, — «Шлюз моделей». Как собрать контрольный набор — «Тестирование модели на своей задаче». Как хранить промпты, чтобы их можно было менять под модель, — «Версионирование промптов».
Подготовка системы к смене моделей и проведение миграции — часть работы по разработке и внедрению ИИ.