Смена языковой модели в работающей системе занимает 3–4 недели и 44 часа инженера, если между системой и моделью стоит адаптер, а у вас есть набор размеченных примеров. Если ни того, ни другого нет, та же задача превращается в 88 часов и 6–8 недель — не потому, что новая модель хуже, а потому, что придётся заново находить в коде все места, где старая была вписана намертво.
Важно понимать, что именно занимает время. Подключить другого поставщика — это несколько часов. Убедиться, что система после этого работает не хуже, — это всё остальное. Модель не даёт гарантий воспроизводимости: та же инструкция у другого поставщика даёт ответ другой длины, другого оформления и с другой склонностью додумывать недостающее. Поэтому миграция — это в первую очередь измерение, а не программирование.
Ниже — четыре места, которые ломаются всегда, способ за полчаса проверить, есть ли у вас адаптер, порядок переключения из четырёх ступеней, расчёт по часам и деньгам и чек-лист готовности из восьми пунктов. Ставка инженера в расчётах — 3 000 ₽/час, методиста базы знаний — 900 ₽/час.
Четыре места, которые ломаются при смене
Показательно, что ни одно из них не относится к смыслу ответов. Смысл обычно переносится нормально: модели сопоставимого класса примерно одинаково понимают, что от них хотят. Ломается форма — и именно на форме держится вся автоматика вокруг.
| Что ломается | Как это выглядит в бою | Что с этим делать |
|---|---|---|
| Формат ответа | Модель возвращает то же по смыслу, но иначе по форме: пояснение перед структурой, другое оформление списка, лишняя вежливая фраза. Разбор ответа падает или молча берёт не то поле | Валидация ответа в одном месте плюс один повтор с уточнением формата; при втором отказе — передача человеку |
| Вызов внешних инструментов | Инструмент не вызывается вовсе или вызывается с пустыми аргументами: у поставщиков разный формат описания функций и разная охота ими пользоваться | Описания инструментов держать в адаптере в одном экземпляре и переводить в формат поставщика внутри драйвера |
| Длина контекста | Ответ по базе знаний внезапно теряет часть источников: одна модель при переполнении обрезает молча, другая отказывается отвечать | Считать длину запроса до отправки и явно решать, что выкидывать, а не полагаться на поведение модели |
| Поведение на том же промпте | Меняются длина ответа, тон и склонность додумывать. В массовых сценариях незаметно, в редких — даёт рост ошибок | Прогон регресс-набора и подгонка промптов: 10 часов работы, которые нельзя пропустить |
Отдельно про длину контекста: разница в размере окна между кандидатами — это не абстрактная характеристика из описания, а прямое влияние на то, сколько фрагментов базы знаний попадёт в запрос. Что такое окно и как оно расходуется, разобрано в отдельной заметке про контекстное окно модели; при миграции это первое, что нужно сверить у старого и нового кандидата.
Схема потока слева направо: «Запрос» → «Сборка контекста» → «Модель» → «Разбор ответа» → «Действие в системе». Четыре узла отмечены заметными маркерами и подписаны: «формат ответа», «вызов внешних инструментов», «длина контекста», «поведение на том же промпте». Под каждым маркером короткая подпись последствия: «парсер падает», «инструмент не вызван», «часть источников потеряна», «рост ошибок в редких сценариях». Чертёжный стиль, подписи по-русски.
Есть ли у вас адаптер: проверка за полчаса
Наличие адаптера обычно утверждают, но редко проверяют. Пять вопросов, каждый из которых имеет однозначный ответ; задавать их надо тому, кто писал систему, и просить показать, а не рассказать.
- 1Поиск по коду находит имя поставщика или адрес его сервиса где-нибудь, кроме одного модуля? Если да — адаптера нет, есть привычка обращаться к модели напрямую.
- 2Смена поставщика требует выкладки кода или это значение в настройке? Правильный ответ — настройка, иначе переключение всегда будет событием, а не операцией.
- 3Разбор ответа модели встречается в одном месте или в нескольких обработчиках? Каждое лишнее место — это плюс два-три часа на миграции и один незамеченный дефект.
- 4Описания внешних инструментов лежат в одном экземпляре или продублированы внутри промптов? Дубли переносятся руками и расходятся между собой на первой же правке.
- 5Есть ли собственный журнал вызовов — запрос, ответ, время, число токенов? Если единственный источник этих данных находится в кабинете поставщика, после ухода сравнивать будет не с чем.
Если сценарии собраны визуально в конструкторе платформы, адаптер до них не достаёт: он прячет вызов модели, а конструктор находится слоем выше. При переезде такие сценарии пересобираются руками на другой платформе, и это самая дорогая часть работы. Как эта разница выглядит в деньгах на примере двух российских платформ, разобрано в сравнении GigaChat и YandexGPT.
Регресс-набор и порядок переключения
Смена модели — это изменение, которое нельзя проверить глазами. Ответы на десяти вопросах, заданных вручную, ничего не доказывают: они покажут, что система в принципе отвечает, но не покажут, что она перестала правильно вести себя в двадцати редких сценариях. Поэтому условие приёмки формулируется просто: переход принимается по результату прогона одного и того же фиксированного набора примеров до и после.
Рабочий размер — 180 примеров, разложенных по корзинам: типовые обращения, ранее найденные ошибки, денежные и правовые темы, редкие формы документов, провокационные вопросы. Устройство набора, пороги допуска и стоимость прогонов разобраны в отдельном материале про регресс-набор при обновлениях. Здесь важно одно: набор должен существовать до начала миграции и лежать у заказчика. Собранный в процессе перехода набор бесполезен — сравнивать будет не с чем.
Не средняя оценка, а конкретные примеры. Если после смены модели упало 5–15 примеров и все они про формат ответа — это нормальный ход работы, чинится подгонкой промптов. Если упал хотя бы один пример из корзины денежных и правовых тем — переход не принимается до разбора причины, независимо от того, насколько хороша общая картина. Замер качества на потоке это не заменяет: методика измерения качества на своих данных отвечает на другой вопрос — какова доля ошибок вообще, а не что именно сломалось.
Когда набор готов, начинается само переключение — оно состоит из четырёх ступеней. Ступени идут именно в этом порядке, и пропуск любой из них экономит часы, но возвращает риск остановки процесса. Общая логика: сначала новая модель отвечает в лаборатории, потом отвечает вхолостую на живом потоке, потом отвечает части клиентов, и только потом — всем.
- 1Ступень 1. Параллельный прогон на выборке
Обе модели получают одни и те же 180 примеров, ответы складываются рядом. Разбираются только расхождения — обычно это 15–40 строк. Результат: список правок промптов и понимание, какие сценарии придётся подгонять. 12 часов работы.
- 2Ступень 2. Теневой режим, пять рабочих дней
Новая модель получает настоящий поток, но её ответы никуда не уходят — они пишутся в журнал. Клиентам отвечает старая. Здесь всплывает то, чего не было в выборке: редкие формы документов, длинные обращения, странные вложения. 8 часов на включение и разбор.
- 3Ступень 3. Десять процентов трафика, одна неделя
Часть обращений уходит на новую модель по-настоящему. Смотрим не на качество ответов — его уже измерили, — а на эксплуатацию: лимиты поставщика, время ответа, поведение при пиковой нагрузке, счёт за токены против ожидаемого. 4 часа наблюдения.
- 4Ступень 4. Полный переход и регресс интеграций
Переключается весь поток, старый драйвер остаётся на месте ещё месяц — это бесплатная страховка. Отдельно прогоняются интеграции: запись в CRM, вложения, уведомления. 4 часа.
Горизонтальная лента на 3–4 недели с четырьмя ступенями, нарисованными как расширяющиеся полосы. Ступень 1 «Параллельный прогон, 180 примеров, 12 ч», ступень 2 «Теневой режим, 5 рабочих дней, 8 ч», ступень 3 «10 % трафика, неделя, 4 ч», ступень 4 «Полный переход, 4 ч». Под лентой сквозная штриховая линия с подписью «старый драйвер остаётся ещё месяц». Чертёжный стиль, подписи по-русски.
Сколько это стоит и сколько занимает
Расчёт для системы, у которой адаптер и регресс-набор уже есть. Это не «идеальный случай», а нормальное состояние системы, собранной с расчётом на смену поставщика.
В опорной статье кластера тот же переезд оценён в 34 часа — там считалась замена драйвера с однократным замером, без теневого прогона и поэтапного переключения. Разница в 10 часов — цена того, что переход принимается по цифрам, а не по ощущению. Полный разбор шести критериев выбора и цены каждого — в статье про выбор языковой модели для бизнеса.
| Состояние системы | Инженерных часов | Деньги | Календарный срок |
|---|---|---|---|
| Адаптер и регресс-набор есть | 44 | 132 000 ₽ | 3–4 недели |
| Адаптера нет, вызовы разбросаны по коду | 88 | 264 000 ₽ | 6–8 недель |
| Сценарии собраны в конструкторе платформы | 154 | 462 000 ₽ | 8–10 недель |
| Регресс-набора нет — добавляется к любой строке выше | +50 | +91 200 ₽ | +1 неделя |
Последняя строка — самая обидная. Набор из 180 примеров с эталонами собирается за 50 часов и 91 200 ₽ силами методиста и инженера, и собирать его в момент миграции поздно: вы получите набор, отражающий уже изменённую систему. Именно поэтому привязка к одному поставщику снимается не в момент ухода, а на старте проекта.
Сравнение в три колонки одинаковой ширины. Колонка «С адаптером и набором»: «44 часа», «132 000 ₽», «3–4 недели». Колонка «Без адаптера»: «88 часов», «264 000 ₽», «6–8 недель». Колонка «Сценарии в конструкторе»: «154 часа», «462 000 ₽», «8–10 недель». Под колонками сноска: «Нет регресс-набора — плюс 50 часов и 91 200 ₽ к любому варианту». Чертёжный стиль, подписи по-русски.
Чек-лист: система готова к смене модели
Восемь пунктов, каждый проверяется показом, а не рассказом. Считайте выполненными только те, которые вам продемонстрировали.
- 1Все обращения к модели идут через один модуль; имени поставщика вне него в коде нет.
- 2Поставщик и модель задаются настройкой, смена не требует выкладки кода.
- 3Разбор ответа и валидация полей находятся в одном месте, поведение при невалидном ответе описано.
- 4Описания внешних инструментов хранятся в одном экземпляре и переводятся в формат поставщика внутри драйвера.
- 5Промпты лежат в хранилище с версиями и датами, а не только в кабинете платформы.
- 6Есть регресс-набор из 180 примеров с эталонными ответами, и он лежит у заказчика.
- 7Есть собственный журнал вызовов минимум за 30 дней: запрос, ответ, время, число токенов.
- 8Есть драйвер второго поставщика, проверенный не позже трёх месяцев назад.
Правило чтения простое: не выполнены один-два пункта — планируйте 44 часа с небольшим запасом. Не выполнены три и больше — планируйте 88 часов и объясните это владельцу процесса до начала работ, а не после.
Когда менять модель не надо
Миграция — не самоцель, и у неё есть три частых ложных повода. Все три выглядят убедительно и все три обходятся в 132 000 ₽ без результата.
- Вышла новая версия, все хвалят. Обновление версии у того же поставщика — это не миграция, а повод прогнать регресс-набор за 3 240 ₽. Менять поставщика ради версии смысла нет.
- Качество упало. Сначала проверьте, не изменилось ли что-то у вас: база знаний, промпты, состав обращений. Признаки настоящей деградации качества со временем отличаются от последствий собственной правки, и в половине случаев виноват не поставщик.
- Другой поставщик дешевле на 15 %. Считайте полный счёт, а не цену за тысячу токенов. При счёте 62 400 ₽ в месяц экономия в 15 % — это 9 360 ₽ в месяц, то есть миграция за 132 000 ₽ окупается за четырнадцать месяцев. На объёме втрое больше решение меняется на противоположное.
Систему, которую нельзя перевести на другую модель за месяц, придётся переписывать целиком в тот момент, когда переводить будет уже поздно.
