Несколько AI-моделей в одном продукте без лишнего хаоса

Почему одна модель для всего создаёт проблемы

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

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

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

Обратная ошибка тоже распространена. Команда выбирает одну недорогую модель и ставит её на все участки продукта. Для рутинных шагов это работает, а потом ломается, когда пользователь пишет что-то размытое вроде «мой отчёт выглядит неправильно, можешь это исправить?». Теперь модели нужно понять намерение, задать полезный уточняющий вопрос и не начать угадывать. Маленькие модели часто спотыкаются именно здесь, особенно при скудном контексте.

Разница хорошо видна на примере поддержки. Если пользователь пишет «сбросьте мой пароль», небольшая модель может классифицировать запрос и направить его дальше. Если же пользователь присылает три абзаца, где смешаны вопросы по биллингу, проблемы со входом и доступом к аккаунту бывшего сотрудника, сильная модель может спасти разговор за один ход. Сложность тут не в длине. Она в неоднозначности.

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

Что должны делать дешёвые модели

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

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

Такие модели хорошо работают и там, где нужно получить структуру из неаккуратного текста. Если человек пишет: «Привет, меня зовут Maya Chen. Заказ 48193 так и не пришёл. Должен был прийти 3 мая», дешёвая модель может вытащить имя, номер заказа и дату в чистые поля. Ваше приложение может сохранить эти данные или передать их более сильной модели только если случай выглядит необычным.

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

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

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

Где сильные модели действительно окупаются

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

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

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

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

Смешанные инструкции часто оказываются самой большой ловушкой. Реальные пользователи редко аккуратно разделяют цели, правила и исключения. Они пишут что-то вроде: «Суммируй этот баг-репорт для команды, убери имена клиентов, упомяни сбой только если он затронул платящих пользователей и держи тон спокойным, потому что это увидит юрист». Это сложно не из-за навыка письма. Это сложно потому, что модели нужно сначала расставить приоритеты, а уже потом писать.

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

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

Как пошагово разделить задачи

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

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

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

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

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

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

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

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

Держите правила маршрутизации простыми

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

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

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

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

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

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

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

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

Реалистичный пример продукта

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

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

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

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

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

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

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

Часто именно в этом и разница между полезным рабочим процессом поддержки и дорогим хаосом.

Ошибки, которые тратят деньги или портят качество

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

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

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

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

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

Не менее важны и запасные сценарии. Модели зависают. Провайдеры ограничивают запросы. Качество вывода может меняться после обновления. Если вы не предусмотрели fallback-правила, пользователи почувствуют сбой сразу.

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

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

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

Практический чек-лист запуска

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

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

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

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

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

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

Простой support assistant помогает легко представить это на практике. Используйте дешёвую модель для сортировки тикетов, получения данных аккаунта и черновиков стандартных ответов. Отправляйте только неясные, злые или высокорисковые сообщения сильной модели. Это быстро сокращает лишние траты и защищает качество там, где пользователи сильнее всего замечают ошибки.

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

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

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

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

Держите маршрутизацию гибкой

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

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

Получите ревью, пока масштаб не сделал ошибки дорогими

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

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