Переносимость: как не зависеть от одного поставщика
Вопрос «что будет, если поставщик закроется» звучит абстрактно ровно до того момента, когда он становится актуальным. Хорошая новость: подготовка стоит недорого, если делать её сразу.
Что должно лежать в конфигурации
Пять значений, которых не должно быть в коде: адрес API, ключ, название модели, версия модели и параметры генерации.
Как только они читаются из окружения, смена поставщика превращается в правку файла конфигурации и перезапуск. Пока они зашиты в коде, это релиз с тестированием и риском.
Проверить себя просто: попробуйте переключить продукт на другую модель, не открывая редактор кода. Если не получается — вы знаете, с чего начать.
Что должно оставаться вашим
**Промпты.** В репозитории, с историей изменений. Промпт — такая же часть системы, как запрос к базе данных.
**Тестовый набор.** Примеры с эталонными ответами. Без него сравнить нового поставщика со старым нечем.
**Логика повторов и резерва.** Если она реализована только настройками в чужом кабинете, при переезде её придётся писать заново.
**Журнал расхода.** Хотя бы агрегированный, на своей стороне.
**Слой вызова модели.** Одна функция, за которой спрятаны все обращения.
Самое уязвимое место
Данные и индексы. Пока документы и векторные представления лежат у вас, смена поставщика — это пересчёт, который занимает часы. Если они существуют только в чужом сервисе, вы вывозите оттуда не конфигурацию, а всю систему.
Отсюда практическое правило: исходные документы всегда хранятся на вашей стороне, а индекс должен собираться из них заново одной командой.
Как оценить стоимость переезда
Раз в полгода задавайте себе пять вопросов и честно отвечайте.
- Сколько мест в коде придётся изменить?
- Есть ли набор примеров, чтобы сравнить качество?
- Сколько времени займёт пересборка индекса?
- Где лежат промпты и кто помнит, почему они такие?
- Что придётся согласовывать с бухгалтерией?
Если суммарный ответ выходит за пределы нескольких дней, зависимость выше, чем стоило бы.
Чего не нужно делать
Не стройте абстракцию на все случаи жизни. Универсальный слой, поддерживающий любого поставщика, обычно оказывается сложнее, чем сама интеграция, и всё равно не покрывает первый же нестандартный случай.
Достаточно тонкой обёртки: функция принимает задачу и возвращает результат. Всё остальное решается конфигурацией.
Не держите два поставщика одновременно «для независимости», если у вас нет на это нагрузки. Вы получите два набора промптов, два тестовых прогона и вдвое больше поводов для ошибок.
Переносимость — не про то, чтобы быть готовым уйти завтра. Она про то, чтобы решение остаться принималось из-за качества сервиса, а не из-за стоимости переезда.
Проверка учением
Самый честный способ узнать, насколько вы готовы, — попробовать. Выделите день, переключите тестовый контур на другого поставщика и прогоните набор примеров.
Вы почти наверняка обнаружите пару неприятных мелочей: название модели в трёх местах, промпт, который никто не может объяснить, тест, который проходит только на старой версии. Это и есть ваш реальный список задач.
Повторять такое учение имеет смысл раз в полгода. Занимает день, а результат — понимание, а не предположение.
Чем платить за независимость
У переносимости есть цена, и о ней честнее сказать прямо.
Тонкий слой вызова нужно писать и поддерживать. Конфигурация усложняется. Часть удобных возможностей конкретного поставщика останется неиспользованной, потому что они не переносятся.
Обычно это оправдано, но не всегда. Для внутреннего инструмента на десять человек городить абстракции незачем. Для продукта, на котором держится выручка, — наоборот, странно этого не делать.
Разумный ориентир: чем дороже обойдётся простой, тем больше смысла в подготовке.
Что проверить в договоре
Техническая переносимость бесполезна, если юридически вы связаны.
Посмотрите на срок уведомления при расторжении, судьбу остатка на балансе и условия выгрузки ваших данных. Отдельно — есть ли ограничения на использование одновременно нескольких поставщиков: обычно их нет, но проверить стоит.
И обратите внимание на то, как меняются условия. Возможность поставщика изменить тарификацию в одностороннем порядке — обычная практика, но вы должны знать, за какой срок вас предупредят. Именно этот пункт определяет, успеете ли вы спокойно переехать, если условия перестанут устраивать.
Коротко
Держите адрес, ключ, модель и параметры в конфигурации. Храните промпты, тестовый набор и данные у себя. Спрячьте вызовы за одной функцией. И раз в полгода проверяйте готовность на практике — это единственный способ узнать настоящую цифру вместо оптимистичной оценки.
Полезно записать результат последнего учения в двух строках: что заняло больше всего времени и что в итоге исправили. Через полгода этот короткий журнал заменяет спор о том, готовы вы к переезду или нет: вместо ощущений появляется список задач с понятной трудоёмкостью, а решение остаться или уйти принимается по фактическим цифрам.