В новостях последних недель виден один и тот же сюжет: один поставщик объявляет новую модель раньше, чем её вообще можно использовать; другой выпускает модель чуть слабее флагманской, но в разы дешевле; где-то суд решает, что модели одного производителя можно исключать из госзакупок. Если ваше AI-решение намертво привязано к конкретной модели, каждая такая новость — это риск. Если нет — это просто повод уменьшить счёт.
Модель — компонент, а не фундамент
Мы часто видим, что AI-проект начинается с вопроса «какую модель выбрать?», будто это решение на годы вперёд. На практике это ближе к выбору хостинга или платёжного провайдера: важно, но заменяемо. Ценность лежит не в модели. Она лежит в выстроенном процессе, понятных инструкциях, проверенных данных и в том месте, где вы измеряете результат. Модель — как раз та часть, которая через полгода с большой вероятностью станет дешевле или лучше.
Отсюда простое управленческое правило: не планируйте продукт вокруг модели, которая пока только анонсирована, и не позволяйте строить решение, внутренности которого везде завязаны на особенности одного поставщика. Решение о закупке принимается по тому, что реально работает в API сегодня.
Четыре вещи, которые держат вас готовыми к замене
Первое: модель выбирается ровно в одном месте. Если её название разбросано по десяти файлам или живёт только в личных чатах сотрудников, менять попросту нечего. Второе: инструкции и настройки хранятся в вашей системе, а не в веб-интерфейсе поставщика. Если вся логика поддержки собрана внутри чужого интерфейса, она фактически принадлежит этой платформе.
Третье — и это самый недооценённый шаг: соберите 20–30 реальных случаев вместе с тем, какой ответ вы считаете правильным. Настоящие письма клиентов, настоящие счета, настоящие документы. Это ваш тестовый набор и единственный трезвый способ понять, новая модель лучше или просто новее. Четвёртое: логируйте каждый запрос так, чтобы потом видеть вход, выход, название модели и дату. Без этого сравнение превращается в вопрос ощущений.
Как проводить замену на практике
Когда появляется новая модель, сначала прогоните её параллельно, не доводя результат до клиента. Сравните на своём тестовом наборе: сколько случаев решено верно, где стало хуже, сколько стоит один обработанный случай. И только потом переключайтесь — желательно по одному процессу, а не всё сразу. Оставьте старую конфигурацию на неделю, чтобы можно было откатиться.
Та же дисциплина даёт второй выигрыш. Большинству рутинных задач — классификация, краткие резюме, форматирование, извлечение полей из документов — топовая модель не нужна. Когда тестовый набор есть, вы можете спокойно попробовать модель подешевле и увидеть чёрным по белому, страдает ли качество. Чаще всего не страдает, а счёт заметно падает.
Где проходит граница
Будем честны: полной независимости не существует, а погоня за ней дорого обходится. Если вы используете фирменные возможности поставщика — встроенные инструменты, голос, поиск по документам, — замена перестаёт быть правкой в одну строку. В случае векторной базы тексты придётся переиндексировать новой моделью. А если инструментом пользуются пятьдесят раз в месяц, не стоит обкладывать его слоем абстракции, который требует больше обслуживания, чем экономит.
Цель не в том, чтобы замена была бесплатной. Цель в том, чтобы она была работой на пару дней, а не переписыванием проекта. Если про ваше текущее решение никто не может ответить на этот вопрос — это уже ответ, и хорошая точка старта на следующий квартал.