Маршрутизатор LLM-запросов: как лёгкая модель на входе перестала сжигать бюджет на GigaChat Pro

Утро понедельника, финдиректор одного из наших заказчиков — оптовая компания, торгует стройматериалами — открывает счёт за месяц и коротко спрашивает: «Это что?». Счёт за LLM-вызовы за квартал вырос в разы. При этом всё работало: ИИ-агент для 1С разбирал входящие заявки, готовил коммерческие, дёргал остатки и цены, помогал менеджерам с ответами клиентам. Претензий к работе не было — были только к сумме.

Мы полезли в логи. Картина типовая для всех, кто когда-нибудь ставил готовые ИИ-агенты в реальный контур: львиная доля вызовов оказалась «лёгкой» — классификация интента, короткие переформулировки, извлечение даты или ИНН из строки, ответы вида «спасибо, получил». А улетали эти запросы туда же, куда и всё остальное — в GigaChat Pro. Это как ездить за хлебом на грузовике.

Меньшая часть вызовов действительно требовала тяжёлой модели: рассуждение по карточке клиента, многошаговое планирование, генерация коммерческого предложения с привязкой к прошлым договорённостям. Там Pro был оправдан. Везде остальное — нет.

Так родилась идея двухуровневой схемы: маршрутизатор на входе смотрит на запрос и решает, куда его отправить — на дешёвую модель или на тяжёлую. По сути — умный switch-case.

Первая попытка: keyword-router, который провалился

Самое очевидное решение — регулярки и ключевые слова. Если в запросе встречается «составь», «напиши», «проанализируй» — идёт на GigaChat Pro. Если «когда», «какой», «да/нет» — на лёгкую модель.

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

Хуже того, keyword-router не видел сложности. «Сколько стоит профлист С8?» — формально простой вопрос. Но если ответ требует свериться с прайсом из RAG, проверить наличие на складе через 1С и учесть индивидуальную скидку клиента — это работа уровня тяжёлой модели. Регулярки этого просто не понимали.

Ещё через несколько дней сдались: правила писать бесполезно. Нужна модель.

Вторая попытка: классификатор на T-Lite

Идея простая. Перед основным ИИ-агентом ставим маленькую модель, она получает запрос и возвращает один из трёх классов — simple, medium, complex. Дальше маршрутизатор по классу выбирает целевую модель и вызывает её через свой ИИ-агент API.

Взяли T-Lite от Т-Банка — она быстрая, хорошо понимает русский, стоит копейки. Промпт классификатора уместился в несколько сотен токенов: определение классов, по несколько примеров на каждый, инструкция вернуть строго JSON с полем class и полем reason.

ROUTING_PROMPT = """
Определи сложность запроса пользователя и верни JSON:
{"class": "simple|medium|complex", "reason": "..."}

simple — фактический вопрос, короткая реплика, классификация,
извлечение поля. Не требует контекста сверх запроса.

medium — нужно подтянуть 1-2 источника (карточка клиента, прайс),
ответ в 1-3 предложения, без многошагового рассуждения.

complex — генерация документа, рассуждение с учётом истории,
планирование действий, ответ с обоснованием.

Запрос: {query}
"""

Размечать датасет вручную не стали — тоскливо и долго. Взяли пачку реальных запросов из логов за пару недель, прогнали через тяжёлую модель с подробной разметкой, приняли это как ground truth. На валидации T-Lite попадала в большинство случаев, ошибалась в основном на границе medium/complex. Для нас это было не критично: переоценка сложности стоит дороже, но не ломает работу.

Куда что поехало

По распределению получилось так. Больше половины запросов оказались simple — их подхватывала T-Lite и отвечала за долю копейки от того, что стоил бы вызов Pro. Заметная часть уходила в medium — их обслуживал GigaChat Lite, тоже кратно дешевле. И меньшинство — тяжёлый complex, для которого мы, собственно, и держим GigaChat Pro.

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

Через месяц после раскатки счёт за LLM просел заметно — примерно вдвое, при том же объёме трафика. Простые запросы стали отвечать ощутимо быстрее: лёгкая модель проворнее по определению. На сложных задержка немного выросла из-за дополнительного вызова классификатора, но в пределах, которые никто не замечает — пользователи и так ждут несколько секунд.

Подводные камни, которые не лежали на поверхности

Первый — стоимость самого классификатора. Лёгкая модель это всё ещё деньги. Если экономия на маршрутизации меньше, чем суммарная стоимость T-Lite-вызовов, схема убыточна. У нас получилось так: как только доля простых и средних запросов у клиента становится существенной, классификатор себя окупает. Если у вас в потоке почти всё тяжёлое — проще оставить всё на Pro и не городить огород.

Второй — деградация на граничных случаях. Запросы, где T-Lite уверенно ставит medium, а реально надо complex, дают плохой ответ от GigaChat Lite — не дотягивает по рассуждению. Пришлось добавить механизм escalate: если ответ от средней модели содержит маркеры неуверенности («возможно», «не уверен», «уточните» и подобные), ИИ-агент перевызывает запрос уже на тяжёлой модели. Это съедает часть экономии, но снимает разговоры про «раньше отвечал нормально, а теперь как-то мимо».

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

Четвёртый — наблюдаемость. Без дашборда «доля запросов по классам в день» вы не увидите, как меняется распределение. У нас весной поток complex пополз вверх — оказалось, менеджеры стали скидывать в чат целые письма клиентов вместо коротких реплик, и модель честно классифицировала это как тяжёлое. Счёт немедленно откликнулся. Помог простой график в Grafana и алерт на сдвиг распределения — теперь такие вещи ловим сразу.

Когда схема не работает

Она бесполезна, если у вас мало запросов — на паре сотен вызовов в день экономия не окупит инфраструктуру маршрутизатора. Проще взять один из готовых ИИ-агентов и не мудрить.

Она проигрышна, если домен очень узкий: например, ИИ-агент только генерирует тексты договоров. Там почти всё complex, и маршрутизатор вырождается в overhead.

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

Что получилось в сумме

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

Если у вас в логах за месяц заметный поток LLM-вызовов и среди них есть что-то проще «напиши коммерческое» — просто посмотрите распределение. Скорее всего, большая часть запросов едет на грузовике за хлебом. А это и есть тот случай, когда стоит разрабатывать ИИ-агента чуть иначе — не одной большой моделью, а связкой из маршрутизатора и нескольких.