Мульти-модельная AI-стратегия для стабильного поведения продукта

Почему одна модель со временем начинает мешать

Сначала одна модель кажется самым простым вариантом. У вас один API, один стиль промптов и один счёт, за которым нужно следить. Потом продукт растёт. Эта же модель должна отвечать пользователям, сортировать запросы, вытаскивать факты из небрежного текста и писать краткие сводки.

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

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

Одно слабое место может распространиться на весь опыт. Если модель не справляется с одной задачей, начинают шататься все функции, построенные на ней. Хороший пример — ассистент поддержки. Если одна и та же модель обрабатывает живые ответы, определение намерения и сводки по кейсам, одно плохое поведение может ударить по всем трём сценариям сразу. Команда видит разрозненные сбои. Пользователь видит один ненадёжный продукт.

Обычно команды не называют проблему прямо, а пытаются латать её точечно. Они добавляют повторные попытки, удлинённые промпты, скрытые правила и быстрые скрипты для крайних случаев. Кто-то меняет модель в фоновой задаче. Кто-то добавляет другой промпт для крупных клиентов. Через несколько месяцев уже никто не может объяснить, почему продукт ведёт себя по-разному в понедельник и в четверг.

Вот тогда и начинает иметь смысл использовать больше одной модели. Не потому, что это звучит умнее, а потому, что одна модель стала общей точкой отказа.

Когда вторая модель действительно нужна

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

Прежде чем что-то тестировать, опишите проблему одним предложением. «Нам нужна классификация намерений за 500 мс». «Нам нужны более чистые поля в счетах». «Нам нужна меньшая стоимость для массовых сводок». Если вы не можете чётко назвать сбой, вторая модель принесёт шум, а не пользу.

Начните с одной узкой задачи и чёткой границы. Хорошие первые кандидаты — простые сценарии вроде классификации входящих запросов, извлечения полей из документов, коротких внутренних заметок или обработки тайм-аутов и лишнего трафика. Так риск остаётся низким, а результат легко измерить. Вы можете сравнить стоимость, скорость и частоту ошибок на одной задаче, а не гадать по всему продукту сразу.

Оставьте первую модель для той работы, с которой она уже справляется хорошо. Если основной чат-поток работает ровно и пользователи ему доверяют, не трогайте его. Поставьте новую модель рядом, а не перед всем продуктом.

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

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

Назначьте одного ответственного за маршрутизацию

Когда две модели работают внутри одного продукта, мелкие решения быстро накапливаются. Один инженер меняет запасную модель для тикетов поддержки. Другой подправляет промпт для возвратов. Третий повышает лимит стоимости для длинных ответов. Вскоре никто уже не может объяснить, почему ассистент ведёт себя так в понедельник и иначе в четверг.

За решения по маршрутизации должен отвечать один человек. Это не значит, что он пишет все правила в одиночку. Это значит, что он принимает финальное решение, держит логику прозрачной и не даёт случайным правкам попадать в продакшн.

В небольшой команде этим человеком часто бывает product manager, founder или Fractional CTO. Инженеры всё равно должны предлагать изменения, потому что именно они первыми замечают всплески задержки, лишние токены и повторяющиеся сбои. Но предложения — это ещё не решения. Если пять человек могут менять маршрутизацию самостоятельно, поведение продукта начнёт расползаться.

У владельца должно быть несколько коротких обязанностей: решать, какие задачи идут в какую модель, утверждать правила переключения на запасную модель и лимиты стоимости, определять, что считается хорошим результатом, и планировать изменения маршрутизации вместе с релиз-ревью. Храните все правила маршрутизации в одном общем месте. Достаточно одного документа, конфигурационного файла или внутренней панели. Формат не так важен, как привычка. Любой человек в команде должен быстро отвечать на простые вопросы: какая модель делает сводки, когда включается резервная модель и что изменилось на прошлой неделе.

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

Это скучная дисциплина. Зато она не даёт пользователям ощущать, что каждые несколько дней они разговаривают с другим продуктом.

Сначала задайте правила, потом что-то переключайте

Одна вторая модель сама по себе не создаёт стабильности. Без понятных правил она обычно порождает случайность. Если один и тот же запрос может прыгать между моделями без фиксированной логики, пользователи получают меняющийся тон, пропущенные поля и ответы, которые отличаются изо дня в день.

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

Запишите каждое правило так, чтобы product manager понял его с первого взгляда. Укажите название задачи, модель по умолчанию, допустимую запасную модель, ожидаемый формат и лимит ошибки. Правило ошибки так же важно, как и выбор модели. Решите, когда система повторяет запрос той же модели, когда переключается на другую и когда останавливается.

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

Версионируйте промпты. Версионируйте и форматы вывода. Если prompt v3 ожидает JSON schema v2, зафиксируйте эту пару и не меняйте её, пока не протестируете обновление. Команды часто меняют промпт, переключают модель и правят парсер в одну и ту же неделю. Потом никто не понимает, из-за чего всё сломалось.

Отслеживайте качество, задержку и стоимость в одном месте. Если смотреть только на один показатель, легко принять плохое решение. Более дешёвая модель может обойтись дороже, когда накапливаются повторные попытки. Более быстрая модель всё равно может вредить продукту, если она пропускает обязательные поля.

Вот часть, которую многие команды пропускают. Если для маршрута нет письменного правила задачи, правила повторной попытки и версионированного промпта, он ещё не готов к релизу.

Подключайте вторую модель маленькими шагами

Вторая модель должна войти в продукт через один узкий путь, а не через весь продукт сразу. Выберите один пользовательский сценарий с чёткими границами, например черновики ответов для агентов поддержки или сводки по загруженным заметкам. Если этот сценарий сломается, остальная часть продукта должна продолжать работать как обычно.

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

Затем сравните одно и то же по обе стороны: качество ответа, частоту отказов, задержку, стоимость и то, как часто нужно вмешательство человека. Если продукт ожидает структурированный вывод, сравните ещё и ошибки формата. Дешёвая модель не является выигрышем, если она в два раза чаще ломает логику ниже по цепочке.

Смотрите на реальные примеры, а не только на дашборды. Модель может выглядеть хорошо по показателю успешности и при этом звучать странно, терять тон или писать слишком длинные ответы. Такие проблемы быстро становятся заметны, когда вы смотрите фиксированную выборку реальных диалогов рядом.

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

Расширяйтесь по шагам. Перейдите с 5% на 15%, потом на 25% и остановитесь, если поведение меняется. Стабильное поведение продукта обычно рождается из терпения, а не из погони за самой новой моделью.

Как сохранить стабильное поведение продукта

Использовать больше одной модели плохо работает, когда пользователи замечают переключение. Если одна модель отвечает коротко и ясно, а другая пишет три расплывчатых абзаца, люди не видят полезного разнообразия. Они видят продукт, которому нельзя доверять.

Начните с одного шаблона промпта для каждого сценария. Промпт для статуса заказа должен иметь одну структуру, один тон и один набор правил для инструментов. То же самое сделайте для triage багов, сводок и ответов поиска. Под капотом модель можно менять, но само определение задачи должно оставаться тем же.

Затем стандартизируйте вывод. Каждая модель должна приводиться к одной общей схеме, прежде чем остальная часть продукта начнёт её использовать. Если приложению нужны поля вроде answer, confidence и next_action, каждая модель должна возвращать именно такую структуру. Небольшой слой нормализации может убирать лишний текст, одинаково форматировать даты и сводить разные стили отказа к одному сообщению продукта.

Большая часть нестабильности появляется из-за странностей, которые можно поймать до того, как их увидят пользователи: ответы, которые слишком растягиваются, отказы, которые звучат по-разному на один и тот же заблокированный запрос, вызовы инструментов с пропущенными полями и fallback-текст, не совпадающий с голосом вашего продукта.

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

Загруженные релизы — худшее время для смены моделей. Замораживайте версии моделей, правки промптов и правила маршрутизации во время релизов, рекламных кампаний или сезонных пиков. Если трафик растёт и поведение меняется одновременно, команда потеряет дни, пытаясь понять, что именно вызвало проблему.

Этот принцип повторяется снова и снова в lean AI operations. Сначала удерживайте пользовательский опыт стабильным. А уже потом настраивайте смесь моделей за кулисами.

Простой пример ассистента поддержки

Представьте почтовый ящик поддержки для программного продукта, куда каждый день приходит сотни чатов. Большинство людей задают обычные вопросы вроде «Где мой счёт?» или «Как изменить пароль?». Быстрая и недорогая модель может за секунды подготовить такие ответы, а агент проверит их одним взглядом.

Споры о возвратах требуют другого пути. Если клиент говорит, что с него списали дважды или он отменил подписку до продления, слабый ответ может привести к реальным потерям и раздражению. Отправляйте такие чаты в более сильную модель с лучшим reasoning, которая умеет сравнивать детали оплаты, читать правила политики и объяснять следующий шаг без догадок.

Пользователи не должны замечать, когда система переключает модели. Держите один и тот же тон, те же поля ответа и те же кнопки действий каждый раз. Если одна модель звучит дружелюбно и коротко, а другая — сухо и юридически, продукт кажется случайным, даже если оба ответа верны.

Хорошо помогает простой контракт ответа. Начинайте с прямого ответа в первом предложении. Показывайте одни и те же поля дела в одном и том же порядке. Предлагайте одни и те же следующие действия, например «проверка возврата» или «связаться с поддержкой». Заканчивайте одинаковым стилем подписи.

Нужна и запись на случай, когда маршрутизация меняет итоговый ответ. Если быстрая модель пишет «возврат одобрен», а более сильная меняет это на «возврат требует проверки», логируйте это различие. Такие случаи показывают, где правила маршрутизации слишком мягкие или где нужно доработать черновой промпт.

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

Это практичный способ использовать вторую модель. Дешёвая модель берёт на себя простую работу, более сильная закрывает рискованные крайние случаи, а пользователи по-прежнему получают предсказуемое поведение.

Ошибки, которые приводят к vendor chaos

Vendor chaos обычно начинается с расплывчатой жалобы. «Модель стала хуже» — это не причина добавлять ещё одного поставщика. Сначала команде нужна чётко названная проблема: стоимость на задачу, медленные ответы, плохая работа с инструментами, слабые сводки или неудачное поведение при отказе. Если этого никто не записал, вторая модель только добавит шума.

Ещё одна частая ошибка — позволить каждой команде функции самой придумывать правила маршрутизации. Поддержка выбирает самую дешёвую модель, поиск — самую быструю, а growth — ту, что лучше всех выглядела на прошлой неделе в демо. Вскоре у продукта появляется три характера, три стиля промптов и ни одного общего способа объяснить, почему один пользователь получил сильный ответ, а другой — слабый.

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

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

Команды слишком часто отвлекаются на небольшие улучшения по бенчмаркам. Пользователи редко замечают крошечный рост балла в публичной таблице. Зато они замечают, когда ответы становятся длиннее, вызовы инструментов ломаются чаще или ассистент забывает правило продукта, с которым вчера справлялся нормально.

Хорошая схема в продакшене ощущается почти скучной. Один человек или маленькая команда владеет правилами маршрутизации, тестами и решением о релизе. Если маршрут меняется, все должны видеть, почему он изменился и какую проблему это исправило. Так вы избегаете хаотичной формы vendor lock-in, когда только один инженер понимает систему.

Короткие проверки перед запуском

Запуск не готов, если команде нужна долгая встреча, чтобы его объяснить. У каждой модели должно быть простое описание роли, которое помещается в одно предложение. Если одна модель пишет первые ответы, а другая обрабатывает сложные случаи, так и скажите. Если никто не может объяснить, зачем нужна модель, система уже слишком запутана.

Не меньше важна и утверждающая сторона. Изменения маршрутизации влияют на поведение продукта, нагрузку на поддержку и расходы. Назначьте одно имя на решение до запуска. В маленькой команде это часто product owner или CTO. Важно, чтобы все понимали, кто может сказать «да», кто может сказать «нет» и кто должен быть на связи, если качество упадёт.

Вам нужен один взгляд на систему, а не четыре отдельных дашборда. Стоимость, скорость и качество ответов должны быть рядом, чтобы компромиссы были очевидны. Более дешёвая модель, которая добавляет три секунды и удваивает количество переписываний, на практике не дешевле.

Перед запуском проверьте четыре вещи. У каждой модели есть одна понятная задача. Один человек утверждает изменения маршрутизации. Один дашборд показывает расходы, задержку и качество вместе. Откат занимает минуты, а не долгий ремонт.

Именно на последнем пункте многие команды ломаются. Если качество падает, вы должны вернуть трафик обратно через feature flag или одно изменение конфига. Вам не нужен патч кода, охота за промптом и ночной созвон.

Для небольших команд здесь может помочь внешний обзор. Oleg Sotnikov через oleg.is работает со стартапами и бизнесом над AI-маршрутизацией, инфраструктурой и планированием Fractional CTO. Даже короткая проверка может показать слабое место до запуска, особенно когда правила владения или отката ещё размыты.

Что делать дальше

Большинству команд одна письменная страница помогает больше, чем десять встреч. Если вам нужно стабильное поведение продукта, начните с написания политики маршрутизации, которую любой человек в команде сможет прочитать за две минуты. Держите всё просто: какая модель отвечает за какую задачу, что считается fallback, кто может менять правило и как вы измеряете плохой результат.

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

Первая версия может быть простой. Назовите задачу и модель, которая ею владеет. Определите, когда запасная модель может подхватить работу. Выберите одну-две проверки, например точность ответа или время ответа. Назначьте одного человека, который утверждает изменения маршрутизации. Запишите, куда идут логи и отзывы пользователей.

Запустите тест на две недели. Один плохой день почти ничего не говорит. У моделей бывают шумные дни, промпты смещаются, а трафик меняется. Две недели обычно показывают закономерность: уменьшает ли вторая модель расходы, улучшает ли скорость или просто добавляет путаницу.

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

Хорошая multi-model AI-стратегия специально остаётся скучной. Меньше исключений, меньше владельцев и меньше неожиданных переключений обычно дают пользователям лучший продукт.