Запуск продукта на топовой LLM вроде Claude 3.5 Sonnet всегда проходит по одному предсказуемому сценарию. Сначала команда разработки восхищается качеством генерации и глубиной понимания контекста. Пользователи оставляют восторженные отзывы. А затем приходит первый полноценный счет за использование API, и эйфория мгновенно улетучивается. Финансовый директор смотрит на пятизначную сумму и задает резонный вопрос: на что конкретно мы сжигаем эти деньги?
Вы открываете логи запросов и видите картину, от которой становится физически больно. Флагманская модель, стоимость которой измеряется долларами за миллион токенов, методично обрабатывает запросы уровня «исправь опечатки в этом абзаце», «переведи текст на испанский» или генерирует дежурные ответы на пользовательское «привет, как дела». Мы используем микроскоп для забивания гвоздей. Огромная доля трафика состоит из тривиальных задач, с которыми безупречно справилась бы открытая Llama 3 8B, стоящая в десятки раз дешевле.
Очевидный порыв — захардкодить выбор модели на уровне пользовательского интерфейса или бизнес-логики. Если пользователь нажимает кнопку «Суммаризация» — шлем запрос в дешевую модель. Если открывает продвинутый чат — в дорогую. Эта статичная архитектура рушится при первом же столкновении с реальностью. Пользователи не следуют правилам интерфейса. Они легко могут вставить простыню сложного кода на Rust в обычное диалоговое окно с просьбой провести глубокий рефакторинг. Дешевая модель послушно берется за работу, выдает галлюцинацию или синтаксически неверный код, и мы стремительно теряем доверие клиента. Хардкод мертв, потому что намерения пользователя предельно динамичны.
Системе необходим интеллектуальный фильтр на пути трафика. Механизм, который оценивает сложность промпта до того, как начнется дорогая генерация, и принимает решение о маршрутизации. В индустрии этот подход закрепился под термином Semantic Routing (семантическая маршрутизация).
Архитектурно инженеры реализуют оценку сложности тремя путями.
Первый — эвристический. Разработчики пишут набор правил на базе регулярных выражений и длины текста. Система видит блоки кода? Запрос летит в Claude. Находит слова «архитектура», «асинхронность», «паттерны»? Тоже в Claude. Запрос короче пятидесяти символов без спецсимволов? Отдаем Llama 3. Подход работает с нулевой задержкой, но быстро достигает потолка развития. Эвристика слепа к контексту. Запрос «напиши скрипт на питоне» поймается правилом, а запрос «сделай парсер для этого сайта» может проскользнуть в дешевую модель, которая выдаст нерабочий мусор.
Второй путь — использование LLM в роли судьи (LLM-as-a-Judge). Архитектура внедряет сверхбыструю и предельно дешевую модель, например Claude 3 Haiku или Llama 3 8B. Система прогоняет через нее промпт с единственной целью — классифицировать его. Системный промпт звучит примерно так: «Оцени сложность задачи от 1 до 10. Верни только число. 1 - базовый перевод, 10 - сложная логика и программирование». Точность такого роутера поражает. Классификатор понимает нюансы и скрытый смысл. Но мы платим за это безжалостным временем. К задержке основного ответа добавляются 300–600 миллисекунд на этап классификации. Для риалтайм-продуктов, где каждая сотня миллисекунд убивает конверсию, этот путь закрыт.
Третий, наиболее сбалансированный путь — векторная маршрутизация. Дата-инженеры берут историю продуктовых логов — скажем, 10 000 прошлых запросов — и размечают их на «сложные» и «простые». Затем они превращают эти запросы в эмбеддинги (числовые векторы) и помещают в векторную базу данных или легковесный in-memory индекс. Когда приходит новый запрос от пользователя, система мгновенно вычисляет его эмбеддинг и ищет ближайших соседей в созданном векторном пространстве. Если запрос семантически близок к кластеру тривиальных задач — бэкенд отправляет его в Llama 3. Вычисление эмбеддинга и поиск занимают порядка 50 миллисекунд. Продукт получает скорость эвристики и контекстное понимание, близкое к LLM-судье.
Пытаться реализовать логику маршрутизации внутри каждого продуктового микросервиса или в ядре монолита — верный способ превратить кодовую базу в неуправляемое спагетти. Разработчикам придется в каждом вызове учитывать фоллбеки, считать токены и поддерживать актуальные версии моделей. Каждое обновление логики роутинга потребует пересборки всех клиентов.
Истинная мощь семантического роутинга раскрывается при внедрении паттерна единого шлюза (API Gateway). В экосистеме платформы эту роль играет RouterAPI (шлюз).
Команда выносит всю сложность маршрутизации за пределы бизнес-логики. Для клиентского кода, будь то бэкенд на Laravel или микросервис на Go, не меняется абсолютно ничего. Приложение продолжает использовать стандартный OpenAI-совместимый SDK. Разработчик просто отправляет запрос client.chat.completions.create, указывая абстрактную модель smart-router или дефолтный claude-3-5-sonnet.
Логика срабатывает на слое RouterAPI. Шлюз перехватывает запрос до отправки провайдеру. Встроенный middleware анализирует входящий массив сообщений. Он вычисляет эмбеддинг последнего промпта, проверяет эвристики и принимает решение. Если шлюз уверен в простоте задачи, он на лету подменяет параметр model на meta-llama/llama-3-8b-instruct и проксирует запрос к резервный провайдер или локальному инстансу vLLM.
RouterAPI закрывает и более жесткие краевые сценарии. Защита формата — один из них. Дешевая модель должна была вернуть строгий JSON, но сорвалась в генерацию обычного текста. Шлюз перехватывает ошибку парсинга и прозрачно для клиента выполняет повторный запрос к дорогой, надежной модели. Клиент получает корректный ответ, даже не подозревая о драме, развернувшейся под капотом бэкенда.
Шлюз берет на себя проблему контекстного окна. В длинных диалогах первый вопрос мог содержать сложный код, а следующий звучать предельно просто: «сделай фон синим». Отправлять весь огромный контекст в дешевую модель бессмысленно — она потеряет нить рассуждений и забудет изначальный код. RouterAPI применяет жесткое правило: если контекст диалога превышает 4000 токенов, трафик принудительно остается на флагманской модели. Это сохраняет непрерывность пользовательского опыта.
Внедрение маршрутизатора не означает окончательную победу над хаосом LLM-разработки. Семантический роутинг приносит собственные архитектурные болезни. Главный враг продакшена здесь — false positives (ложноположительные срабатывания). Это ситуации, когда векторный алгоритм ошибочно классифицирует сложную многоуровневую задачу как простую. Запрос улетает в Llama 3. Пользователь мгновенно видит падение интеллекта системы, получает поверхностный или галлюцинирующий ответ. Он раздражается, переписывает промпт жестче и отправляет его снова. В итоге система классифицирует новый запрос как сложный, отправляет в Claude, и компания всё равно платит за вызов тяжелой модели. Но теперь бизнес заплатил дважды, получив в довесок разочарованного пользователя.
Ключ к жизнеспособному роутингу лежит в асимметричной настройке порогов уверенности. Маршрутизатор должен переводить трафик на дешевую модель только при абсолютной, 98-процентной уверенности в тривиальности задачи. При малейших сомнениях или пограничных значениях семантической близости трафик обязан идти по дефолтному дорогому пути.
Экономия десятков тысяч долларов на AI-инфраструктуре строится не на слепой жадности, а на холодном управлении вероятностями. Бизнес не перестает платить за передовые языковые модели. Он просто прекращает бессмысленно сжигать вычислительные мощности там, где задача решается инструментами базового уровня. Умная архитектура позволяет платить только за реальный интеллект, жестко делегируя рутину рабочим лошадкам.