Федерация моделей для реальных продуктов: рабочие правила маршрутизации

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

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

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

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

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

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

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

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

Что нужно каждой задаче

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

Инструмент поддержки, например, может выполнять несколько разных задач в одном потоке:

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

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

Для каждой задачи запишите размер входа, ожидаемый выход и стоимость плохого ответа. Модель, которая хорошо справляется с письмом на 200 слов, может провалиться на 40‑страничном контракте. Задача, возвращающая один ярлык, намного легче валидируется, чем задача, которая пишет ответ клиенту.

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

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

Обращайте клиентскую работу отдельно от внутренней. Черновик для аналитика — одно, письмо клиенту по выставлению счета — другое. Второе требует чистого тона, строгой проверки и безопасного плана на случай, если модель запутается.

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

Задайте лимиты до маршрутизации

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

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

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

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

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

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

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

Стройте политику шаг за шагом

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

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

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

Простая политика часто достаточна:

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

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

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

Пример для почтового ящика поддержки

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

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

Затем направляйте по правилам:

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

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

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

Неясные тикеты — место, где многие системы ломаются. Клиент может написать: «Мне сняли деньги дважды и теперь я не могу войти». Это и биллинг, и доступ к аккаунту. Первая модель может промахнуться. Отслеживайте, как часто последующие шаги меняют маршрут после первого прохода. Если перенаправлений много, ваши метки слишком расплывчаты или первая модель слишком слабая.

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

Планируйте медленные ответы и серьёзные ошибки

Пользователям всё равно, какая модель провалилась. Им важно, чтобы продукт ответил и не оставил их смотреть на крутящийся индикатор. Если ответ идёт слишком долго, отправьте короткое безопасное сообщение, чтобы пользователь не ушёл: «Нужно немного времени» или «Человек рассмотрит запрос». Такой шаг сохраняет доверие.

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

Простая лестница отказов

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

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

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

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

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

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

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

Измеряйте систему после запуска

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

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

Простая табличка должна включать:

• качество ответов по небольшой выборке проверок
• стоимость на запрос или на 100 запросов
• медианную латентность и p95
• частоту таймаутов, повтора и передач на ручную обработку
• частоту ошибок формата, например сломанный JSON или отсутствующие поля

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Быстрые проверки перед развёртыванием

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

Короткий чеклист ловит большинство дорогих ошибок:

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

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

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

Следующие шаги для вашей команды

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

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

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

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

Простой стартовый набор может выглядеть так:

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

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

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

Если хотите второе мнение перед масштабным развёртыванием, Oleg Sotnikov на oleg.is проверяет правила маршрутизации, инфраструктуру и планы релиза для стартапов и небольших компаний, которые переводят AI в продакшн.