ACRouter выбирает наиболее эффективную модель ИИ для каждой задачи, превосходя по стоимости системы, использующие только Opus.

Бен Диксон

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

Новая платформа с открытым исходным кодом под названием Agent-as-a-Router решает эту проблему, рассматривая маршрутизатор как динамический агент, накапливающий память. Она использует цикл «Контекст-Действие-Обратная связь» (CAF) для отслеживания успехов и неудач модели и обновления поведения маршрутизатора.

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

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

Экономика маршрутизации и информационный дефицит

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

В настоящее время разработчики используют для решения этой задачи два основных механизма. Первый — это маршрутизация на основе эвристических алгоритмов, которая опирается на жестко закодированные правила, заданные вручную. Например, разработчик может написать правило, согласно которому, если приглашение содержит определенные ключевые слова, оно направляется в GPT-5.5. В противном случае оно отправляется в самодостаточную модель с открытым исходным кодом, такую как Kimi K2.7.

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

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

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

Агент как маршрутизатор: саморазвивающаяся система

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

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

Рассмотрим автоматизированный конвейер анализа корпоративных данных. Маршрутизатор получает задачу генерации SQL-запроса и отправляет её в модель с открытым исходным кодом, например, Kimi. Модель генерирует имя столбца и не может скомпилировать SQL-запрос. Цикл CAF отслеживает ошибку компиляции, регистрирует её как обратную связь и записывает в лог. В следующий раз, когда поступит аналогичный малопонятный SQL-запрос, маршрутизатор проверяет его контекст и перенаправляет задачу в более продвинутую модель, например, Claude Opus 4.8.

ACRouter

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

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

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

Сам Orchestrator отличается легкостью. Вместо массивной, ресурсоемкой языковой модели исследователи обучили адаптер с менее чем миллиардом параметров на основе Qwen 3.5 (0,8 млрд параметров), что означает возможность его самостоятельного размещения на любом устройстве по вашему выбору.

ACRouter в действии: превосходит базовые показатели.

Для стресс-тестирования фреймворка исследователи представили CodeRouterBench — среду оценки, включающую примерно 10 000 задач с проверенными результатами по восьми передовым моделям, в том числе Claude Opus 4.6, GPT-5.4, Qwen3-Max и GLM-5. Оценка была разделена на тесты в рамках дистрибутива (ID-тесты, охватывающие девять аспектов одноэтапного кодирования, таких как проектирование алгоритмов и генерация тестов) и тестовую среду для агентного программирования вне дистрибутива (OOD-тесты). Задачи OOD качественно отличались, требуя многоэтапного планирования, навигации по файлам и итеративной отладки, чтобы проверить, может ли маршрутизатор адаптироваться к принципиально новым областям.

Базовые результаты показали, почему стратегия, основанная на одной модели, является ошибочной: ни одна модель не доминирует во всех категориях. Например, хотя Claude Opus 4.6 показал наивысшую среднюю производительность, его превзошла GLM-5 в разработке алгоритма (относительное улучшение на 86%) и Qwen3-Max в генерации тестов (улучшение на 111%), несмотря на то, что Opus стоит примерно в 12 раз дороже, чем более мелкие модели, такие как Kimi-K2.5.

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

Согласно результатам сравнительного анализа исследователей, ACRouter прочно занимает позицию на границе Парето по соотношению стоимости и производительности. Как в потоках задач идентификации, так и в сложных агентных тестах объектно-ориентированного проектирования, ACRouter показал наименьшее совокупное сожаление — показатель, измеряющий неоптимальные решения по маршрутизации с течением времени. В тестовом наборе данных в распределенной среде затраты на ACRouter составили 13,21 доллара за весь период выполнения задачи, по сравнению с 34,02 долларами при постоянном использовании Opus по умолчанию — экономия в 2,6 раза.

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

Ограничения, предостережения и как начать работу

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

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

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

Исследователи опубликовали исходный код на GitHub и выпустили веса модели оркестратора на Hugging Face под лицензией Apache 2.0. Маршрутизатор совместим с Claude Code, Codex и OpenCode.

Источник: venturebeat.com