Как переходить между поставщиками ИИ без переписывания

Почему это возникает раньше, чем ждут команды

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

Спрячьте поставщика за одной дверью

Самое действенное решение — держать все обращения к модели за одним внутренним интерфейсом. Приложение просит дополнение, классификацию или эмбеддинг; один модуль знает, какой поставщик и какой SDK на это отвечают. Это не большая абстракция, и она не должна пытаться стать универсальной обёрткой — ей достаточно быть единственным местом, где встречаются имена, параметры и форматы ответов конкретного вендора.

Чаще всего за эту черту протекают две вещи: обработка ошибок и стриминг. Ответы о превышении лимита, семантика повторов и форматы кусочков потока у поставщиков различаются, и код, который ветвится по конкретному типу ошибки вендора или разбирает его формат потока напрямую, — это код, который вы перепишете. Нормализуйте и то и другое на границе: приложение должно видеть ваши собственные типы ошибок и ваши собственные события потока.

Владейте промптами, примерами и оценкой

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

Набор для оценки — та часть, которая вообще делает миграцию решаемым вопросом. С фиксированным набором реалистичных запросов и записанными критериями приёмки переход превращается в эксперимент: прогнать обе, сравнить, решить. Без него у вопроса «достаточно ли хороша новая модель?» нет ответа, кроме мнения, и команды либо остаются на месте из страха, либо переходят и узнают о регрессиях от клиентов.

Что действительно тяжело перенести

Будьте честны насчёт частей, которые не сводятся к замене клиента. Дообученная модель не переносится: новый поставщик означает переобучение, для которого нужен датасет, который вы, надеемся, сохранили. С эмбеддингами хуже, чем кажется: векторы разных моделей несопоставимы, поэтому смена эмбеддинг-модели означает пересчёт и переиндексацию всего корпуса, а при невозможности простоя — параллельную работу обеих во время перехода. Всё, что опирается на фирменную возможность поставщика — размещённая абстракция ассистента, проприетарное расширение вызова инструментов, механизм кэширования с собственной семантикой, — это переписывание соответствующей функции, и стоит знать, что из этого вы приняли, до того как понадобится уходить.

Дешёвая страховка

Три привычки держат дверь открытой почти бесплатно. Сделайте модель настройкой уровня окружения, а не константой, чтобы переключиться на другую без деплоя. Логируйте имя и версию модели с каждым запросом, чтобы при сдвиге качества понимать, не поменялась ли модель под вами. И время от времени прогоняйте набор для оценки на альтернативном поставщике — раза в квартал более чем достаточно. Одно это упражнение показывает, работает ли аварийный выход на самом деле, превращает предположение в измерение и обычно вскрывает одну-две протечки за границу, пока их дёшево заделать.

Маршрутизация — стратегия, а не только запасной путь

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