Роутинг моделей: почему первая схема не окупается

Почему первая схема не дает отдачи

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

Проблема не в самой идее роутинга моделей, а в масштабе первой версии. Когда у команды есть доступ к десяткам или сотням моделей через один API, возникает простая мысль: раз выбор большой, надо использовать его по максимуму. В итоге вместо 2-3 понятных веток появляются 10-15 правил, пороги по длине запроса, исключения и ручные переопределения.

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

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

Хуже всего работают редкие сценарии. Допустим, отдельная ветка ловит 2% запросов и в лучшем случае экономит несколько процентов бюджета на этих запросах. Если из-за нее команда тратит даже 4-5 часов в месяц на отладку, смысл быстро исчезает. Формально схема умнее. По деньгам и по скорости работы она слабее.

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

Когда роутинг правда нужен

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

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

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

Третий сигнал - одна модель плохо держит нужный формат ответа. Команды часто смотрят только на "умность" текста и пропускают более приземленную проблему: JSON ломается, поля пропадают, tool call не проходит, категории путаются. В таком случае маршрутизация запросов LLM дает эффект даже без сложной логики: одна модель отвечает за строгую структуру, другая - за длинные объяснения.

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

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

Роутинг обычно стоит вводить, когда совпадают хотя бы три условия:

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

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

Какие сигналы взять в первой версии

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

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

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

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

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

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

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

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

Как собрать первую версию

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

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

Каркас первой версии обычно выглядит так:

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

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

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

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

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

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

Как считать эффект без сложной таблицы

Эффект от роутинга редко виден по общему счету за месяц. Смотрите на цену полезного ответа. Если модель дешевле, но чаще просит уточнение, ломает формат или уводит задачу на человека, экономия быстро тает.

Проще считать не весь поток, а один и тот же тип задач. Например, возьмите 500 похожих обращений в поддержку: короткие вопросы по статусу заказа, возврату или смене тарифа. Тогда видно, помогает схема или просто смешивает в одной куче легкие и трудные запросы.

Для первой оценки хватит четырех чисел:

• сколько стоит один полезный ответ;
• сколько секунд ждет пользователь;
• как часто ответ ломает нужный формат;
• сколько ручной работы добавляет сама схема.

"Полезный ответ" лучше определить заранее. Для поддержки это может быть ответ, который не ушел на повторный запрос и не потребовал правки оператором. Если из 100 ответов полезными оказались 82, делите расход не на 100, а на 82. Такое сравнение быстро отрезвляет.

Задержку и ошибки формата считайте отдельно от цены. Дешевая модель может отвечать на 2 секунды дольше. Для внутреннего инструмента это терпимо, а для чата на сайте уже нет. То же с форматом: если JSON ломается в 7% случаев, команда потом платит не токенами, а временем разработчика и оператора.

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

Даже если вы меняете модели через один эндпоинт, эффект нужно считать на одинаковых задачах, а не по среднему чеку по всей системе. Иначе получится красивая цифра, которая ничего не говорит о реальной пользе.

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

Пример: помощник для службы поддержки

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

Представим интернет-магазин. Половина обращений короткие: "Где заказ?", "Как отменить доставку?", "Когда вернут деньги?" Такие запросы можно сразу отдавать в дешевую модель. Она читает мало контекста, отвечает по базе знаний и не тратит лишние токены.

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

Отдельный случай - задачи со строгой формой ответа. Например, бот должен вернуть JSON для CRM с полями "intent", "priority", "order_id" и "next_action". В таком потоке обычно лучше работает не самая умная модель, а та, что стабильно держит формат. Если JSON ломается даже в 8% случаев, вся экономия исчезает на ретраях и ручной разборке.

Первая версия правил может быть короткой:

• до 25 слов и без вложений - дешевая модель;
• длинное обращение или больше одного вопроса - сильная модель;
• нужен строгий JSON - модель с самым ровным форматом;
• тайм-аут, пустой ответ или битый JSON - повтор через базовую модель.

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

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

Где команды сами ломают схему

Проблема редко в самом роутинге. Чаще команда ломает его своими руками: спешит с правилами, меряет не то и потом уже не понимает, что дало эффект, а что просто добавило шум.

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

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

Иногда команда радуется тому, что средняя задержка упала с 2,4 до 1,6 секунды. Звучит хорошо. Но если оператор все равно правит каждый второй ответ вручную, пользы мало.

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

Редкие случаи тоже часто ломают схему. Команды тратят дни на ветку для 2% запросов, потому что она красиво выглядит на диаграмме. А основной поток все еще идет без ясного правила. Для первой версии часто хватает двух маршрутов: простые FAQ - в дешевую модель, длинные обращения с документами - в более сильную.

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

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

Проверка перед запуском

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

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

Потом оставьте контрольную группу без роутинга. Хотя бы 10-20% трафика пусть идет по старому пути, где всегда вызывается одна и та же модель. Иначе вы увидите только красивые графики внутри новой схемы, но не поймете, стала ли система дешевле или быстрее на самом деле.

Хорошее правило можно объяснить одной фразой. Если фраза не помещается в одно предложение, правило обычно сырое. Например: "Короткие простые запросы отправляем в дешевую модель", "Длинные обращения с файлами отправляем в модель с большим контекстом", "Если первая модель не уверена, даем второй шанс более сильной".

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

Еще до старта настройте логи так, чтобы по каждому запросу были видны три вещи: цена, задержка и ошибка, если она случилась. Без этого вы не найдете причину провала. Если команда тестирует много провайдеров через один шлюз, единый формат логов и единый эндпоинт сильно упрощают сравнение. У AI Router в этом месте есть вполне практичный плюс: можно менять base_url на api.airouter.kz и продолжать использовать те же SDK, код и промпты.

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

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

Что делать после первого месяца

Через месяц у вас уже будут цифры, и они быстро покажут, что работает, а что было лишним. В этот момент не стоит расширять схему. Наоборот, лучше упростить ее до правил, которые реально дали эффект по цене, качеству ответа или скорости.

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

Хороший темп после первого месяца простой: добавляйте только один новый сигнал за раз. Например, сначала проверьте длину запроса. Потом, в отдельном цикле, добавьте тип задачи вроде "классификация" или "свободный ответ". Если менять все сразу, вы не поймете, что именно дало эффект.

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

Через месяц полезно ответить на четыре вопроса:

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

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

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

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