Роутинг LLM для продакшена: как выбрать стратегию

В чем проблема с роутингом в продакшене

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

Частая ошибка выглядит просто: команда берет самую дешевую модель и надеется, что она "потянет" все. На легких задачах это и правда работает. Но как только запрос становится запутанным, требует точного формата или длинного контекста, дешевая модель начинает срезать углы. Она путает шаги, пропускает ограничения и додумывает детали.

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

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

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

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

Что считать хорошим ответом

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

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

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

Поэтому формат ответа лучше задавать сразу и коротко. Например: JSON по схеме, один класс из списка, ответ до 5 строк, SQL без комментариев. Простое правило обычно полезнее, чем расплывчатая инструкция вроде "ответь качественно и аккуратно".

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

После этого задайте пороги по цене и времени ответа. Хороший ответ за 12 секунд может быть плохим для онлайн-чата. Очень точная модель тоже не подходит, если она делает задачу в 8 раз дороже без заметной пользы. Удобно задать простой коридор: например, до 2 секунд для чата, до 10 секунд для фоновой обработки и понятный потолок цены на 1000 запросов. Тогда модели можно сравнивать спокойно, а не по впечатлению после пары удачных ответов.

Как собрать один набор задач для сравнения

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

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

Сначала почистите выборку. Уберите дубликаты, очень похожие формулировки и все, что содержит персональные данные: имена, телефоны, почту, номера договоров и адреса. Если данных немного, это не проблема. Набор из 150-300 живых задач обычно полезнее, чем тысяча однотипных.

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

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

Ориентир по составу выборки можно держать таким: 60-70% обычных запросов из реального потока, 20-30% пограничных случаев и 10-15% редких, но дорогих ошибок. При этом в каждой группе стоит оставить немного коротких, средних и длинных примеров.

Когда набор собран, его нужно заморозить до конца сравнения. Не добавляйте новые примеры в середине теста, даже если одна модель вдруг выглядит слабее, чем вы ожидали. Иначе результаты уже нельзя честно сопоставить.

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

Какие метрики смотреть

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

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

Качество удобно мерить простой рубрикой. Например, для ответов поддержки можно ставить 0, 1 или 2 балла: не ответил по сути, ответил частично, ответил правильно и полно. Если такую шкалу трудно формализовать, берите парные сравнения: два ответа на один запрос, а ревьюер выбирает лучший. Часто это честнее длинной шкалы на 10 баллов.

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

Удобно свести все в одну таблицу:

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

Где простые правила работают лучше

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

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

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

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

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

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

Когда сложная схема только мешает

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

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

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

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

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

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

Как провести сравнение на своей выборке

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

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

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

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

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

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

Победивший вариант оставьте на короткий пилот на реальном трафике. Обычно 1-2 недель хватает, чтобы увидеть сбои, редкие сценарии и реальные расходы, которых не видно в лабораторном тесте.

Пример на запросах службы поддержки

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

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

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

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

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

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

Ошибки, которые встречаются чаще всего

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

Вторая проблема связана с задержкой. Многие смотрят только на среднее время ответа и успокаиваются. Пользователь же замечает не среднее, а длинный хвост - те самые 2-5% запросов, которые отвечают слишком долго. Если одна схема дает 1,8 секунды в среднем, а другая 2,0, это еще ничего не значит. Нужно видеть p95 и p99.

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

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

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

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

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

Перед запуском стоит проверить несколько вещей:

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

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

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

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

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

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

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

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

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

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