Mercury Router: карточка диффузионного маршрутизатора между ИИ-моделями
Mercury Router — предварительный маршрутизатор Inception, представленный вместе с Mercury 2.5. Он анализирует входной запрос быстрой диффузионной моделью и выбирает из доступных открытых и закрытых моделей вариант с подходящим сочетанием качества, скорости и цены. Идея практична: не каждую задачу нужно отправлять в самую дорогую модель, а ручной список правил быстро разрастается.
Маршрутизатор не является универсальным «ИИ поверх всех ИИ». Он принимает решение на ограниченной информации и способен ошибиться в сложности, языке или риске запроса. Экономия появляется только тогда, когда выбор измеряется по завершённой задаче, а критические сценарии не зависят от непрозрачного рейтинга.
Какую проблему он решает
У команды обычно есть быстрый дешёвый вариант для классификации, сильная модель для сложного анализа, кодовая — для репозитория и локальная — для закрытых данных. Без маршрутизатора приложение либо всегда использует дорогой профиль, либо поддерживает десятки условий. Router предлагает вынести выбор в отдельный интеллектуальный слой.
Это полезно при неоднородном потоке: короткие запросы в поддержку, длинные документы, код и задачи с изображениями. Если все обращения почти одинаковы, фиксированная модель проще, предсказуемее и легче аудируется.
Что должно входить в решение
Одного текста запроса мало. Маршрутизатору нужны допустимые поставщики, регион, тип данных, максимальная цена, требуемый формат и задержка. Политика безопасности должна отфильтровать запрещённые направления до интеллектуального выбора. Иначе система может отправить конфиденциальный документ дешёвой модели, которая не соответствует договору.
Хороший ответ Router — не только имя модели, но и причина, оценка уверенности и резервный путь. Приложение сохраняет эту запись вместе с фактическим model ID. Тогда ошибку можно расследовать и повторить на новой версии.
Где экономия реальна
Возьмём сто тысяч обращений. Большинство просит статус или краткую классификацию, меньшая часть содержит противоречивый документ, а несколько требуют сложного анализа. Если дешёвая модель уверенно закрывает первый слой, более дорогие вызовы остаются редкими. Экономия считается как полная стоимость всех попыток и проверок, а не разница прайс-листов.
Неверная маршрутизация создаёт скрытый расход: повтор, эскалацию, исправление оператором или пропущенную ошибку. Поэтому оптимизировать только цену вызова опасно. Нужен показатель стоимости принятого результата, о котором мы писали в обзоре Mercury 2.5.
Как построить контрольную выборку
Разделите реальные обезличенные задачи по типу и риску. Для каждой укажите минимальный допустимый класс модели и причины: мультимодальность, длинный контекст, строгая схема, локальная обработка. Добавьте пограничные запросы, которые выглядят простыми, но содержат вложение или опасное действие.
Сравните Router с двумя базами: всегда сильная модель и ручные правила. Измерьте точность выбора, итоговое качество, задержку, стоимость, долю повторов и нарушения политики. Если маршрутизатор экономит токены, но часто выбирает запрещённый регион, пилот не пройден.
Ошибка выбора и безопасный fallback
При низкой уверенности система может выбрать проверенную сильную модель или передать запрос человеку. Fallback должен учитывать причину сбоя. Если провайдер недоступен, подходит резерв. Если данные запрещено передавать наружу, резервным должен быть локальный контур, а не второй внешний API.
Не запускайте автоматический бесконечный перебор моделей. Ограничьте число попыток и бюджет запроса. Иначе сложное обращение способно пройти через весь список, увеличить задержку и разнести данные по нескольким поставщикам.
Наблюдаемость и версии
Панель должна показывать распределение маршрутов, качество по типам задач, стоимость и изменения после обновления. Следите не только за средней долей дешёвых вызовов, но и за тем, какие темы ушли в другой профиль. Внезапный сдвиг может означать изменение входного потока или поведения Router.
Закрепляйте версию маршрутизатора и таблицу доступных моделей. При добавлении новой модели сначала включайте теневой режим: решение записывается, но реальный вызов остаётся прежним. Сравнение покажет, насколько новый маршрут изменил бы качество и бюджет без риска для пользователя.
Кому Mercury Router не нужен
Если продукт использует одну модель, объём мал или требования требуют жёстко закреплённого поставщика, маршрутизатор добавит сложность без выгоды. Не нужен он и там, где задача определяется простым полем интерфейса: выбранный пользователем тип файла надёжнее вероятностной догадки.
Интеллектуальный выбор оправдан, когда поток разнообразен, данные разрешают несколько контуров и команда умеет оценить итог. До этого полезнее изучить практический выбор модели для работы и реализовать несколько прозрачных правил.
Редакционная оценка
Mercury Router — интересный служебный слой, а не модель для общения. Быстрая диффузионная классификация может снизить задержку и цену в большом неоднородном потоке. Но ценность зависит от наблюдаемости: владелец обязан знать, куда ушёл запрос и почему.
Для пилота достаточно трёх моделей, пяти категорий и теневого режима. Если Router стабильно повторяет экспертный выбор и сохраняет политику данных, можно отдать ему часть трафика. Если объяснение маршрута недоступно, автоматическая экономия слишком плохо проверяема.
FAQ
Router сам отвечает пользователю?
Его основная роль — выбрать модель. Финальный ответ формирует выбранный провайдер или отдельный этап конвейера.
Можно ли включить только разрешённых поставщиков?
Это обязательное условие безопасного внедрения. Точный механизм нужно подтвердить в документации и настройках доступа.
Чем он лучше обычных правил?
Он потенциально распознаёт сложность и формат гибче, но правила прозрачнее. Сравнивать нужно на реальном потоке.
Как начать без риска?
Запустите теневой режим: сохраняйте выбор Router, но пока вызывайте прежнюю модель. Затем сравните качество, политику и стоимость.