Хотите более умное понимание в вашем почтовом ящике? Подпишитесь на наши еженедельные информационные бюллетени, чтобы получить только то, что имеет значение для искусственного интеллекта предприятия, данных и лидеров безопасности. Подписаться сейчас
Исследователи из Katanemo Labs представили Arch-Router, новую модель маршрутизации и структуру, предназначенную для разумного отображения пользовательских запросов с наиболее подходящей большой языковой моделью (LLM).
Для предприятий, создающих продукты, которые полагаются на несколько LLMS, Arch-Router стремится решить ключевую задачу: как направлять запросы на лучшую модель для работы, не полагаясь на жесткую логику или дорогостоящую переподготовку каждый раз, когда что-то меняется.
Проблемы маршрутизации LLM
По мере роста числа LLMS разработчики переходят от одномоделических настройки к многомодельным системам, которые используют уникальные силы каждой модели для конкретных задач (например, генерация кода, суммирование текста или редактирование изображений).
Маршрутизация LLM стала ключевой методикой для создания и развертывания этих систем, выступая в качестве контроллера трафика, который направляет каждый запрос пользователя в наиболее подходящую модель.
Существующие методы маршрутизации, как правило, подпадают под две категории: «маршрутизация на основе задач», где запросы направляются на основе предопределенных задач, и «маршрутизация на основе производительности», которые ищут оптимальный баланс между стоимостью и производительностью.
Тем не менее, на основе задач маршрутизация борется с неясными или изменяющими намерениями пользователей, особенно в разговорах с несколькими поворотами. Маршрутизация на основе производительности, с другой стороны, жестко расставляют приоритеты в эталонных оценках, часто пренебрегает реальными предпочтениями пользователей и плохо адаптируется к новым моделям, если она не подвергается дорогостоящей точной настройке.
Более принципиально, как отмечают исследователи Катанемо Лаборатории в своей статье, «существующие подходы маршрутизации имеют ограничения в реальном использовании. Они, как правило, оптимизируют для показателей эффективности, пренебрегая человеческими предпочтениями, обусловленными субъективными критериями оценки».
Исследователи подчеркивают необходимость в системах маршрутизации, которые «согласуются с субъективными человеческими предпочтениями, предлагают большую прозрачность и остаются легко адаптируемыми по мере развития моделей и вариантов использования».
Новая структура для маршрутизации, выравниваемой предпочтениями
Чтобы учесть эти ограничения, исследователи предлагают основу для маршрутизации, выравниваемой предпочтениями, которая соответствует запросам с политиками маршрутизации на основе определенных пользовательских предпочтений.
В этой структуре пользователи определяют свои политики маршрутизации на естественном языке, используя «таксономию домена». Это двухуровневая иерархия, которая отражает то, как люди естественным образом описывают задачи, начиная с общей темы (домен, такой как «законное» или «финансы») и сужение до определенной задачи (такое действие, такое как «суммирование» или «генерация кода»).
Каждая из этих политик затем связана с предпочтительной моделью, позволяющей разработчикам принимать решения о маршрутизации на основе реальных потребностей, а не только для оценки баллов. Как говорится в статье, «эта таксономия служит ментальной моделью, которая помогает пользователям определить четкую и структурированную политику маршрутизации».
Процесс маршрутизации происходит на два этапа. Во-первых, модель маршрутизатора, выровненная предпочтения, принимает пользовательский запрос и полный набор политик и выбирает наиболее подходящую политику. Во -вторых, функция отображения соединяется с выбранной политикой с назначенным LLM.
Поскольку логика выбора модели отделена от политики, модели могут быть добавлены, удалены или заменены просто путем редактирования политик маршрутизации, без какой -либо необходимости переподготовки или изменения самого маршрутизатора. Эта развязка обеспечивает гибкость, необходимую для практических развертываний, где модели и варианты использования постоянно развиваются.
Выбор политики питается Arch-Router, компактной моделью языка параметров 1,5B, точно настроенной для направленной на предпочтения маршрутизации. Arch-Router получает пользовательский запрос и полный набор описаний политики в рамках своей подсказки. Затем он генерирует идентификатор лучшей политики.
Поскольку политики являются частью ввода, система может адаптироваться к новым или модифицированным маршрутам во время вывода посредством встроенного обучения и без переподготовки. Этот генеративный подход позволяет Arch-Router использовать свои предварительно обученные знания, чтобы понять семантику как запроса, так и политики, а также обрабатывать всю историю разговоров одновременно.
Общей проблемой включения обширной политики в подсказку является потенциал для увеличения задержки. Тем не менее, исследователи разработали арх-маркировку, чтобы быть высокоэффективным. «В то время как длина политики маршрутизации может продолжиться, мы можем легко увеличить контекстное окно арх-маршрута с минимальным воздействием на задержку»,-объясняет Салман Парача, соавтор бумаги и основатель/генеральный директор Katanemo Labs. Он отмечает, что задержка в первую очередь обусловлена длиной вывода, и для арх-маршрута вывод-это просто короткое имя политики маршрутизации, например «Image_editing» или «document_creation».
Арк-маршрут в действии
Чтобы построить арх-маркировку, исследователи настраивали версию параметров 1,5B модели QWEN 2.5 на кураторском наборе данных из 43 000 примеров. Затем они проверили свою производительность против современных проприетарных моделей от OpenAI, Anpropic и Google на четырех открытых наборах данных, предназначенных для оценки разговорных систем ИИ.
Результаты показывают, что Arch-Router достигает самой высокой общей оценки маршрутизации 93,17%, превосходя все другие модели, включая лучшие запатентованные, в среднем на 7,71%. Преимущество модели росло с более длинными разговорами, демонстрируя его сильную способность отслеживать контекст на нескольких ходах.
На практике этот подход уже применяется в нескольких сценариях, согласно Paracha. Например, в инструментах кодирования с открытым исходным кодом разработчики используют Arch-маркировку для направления различных этапов своего рабочего процесса, таких как «дизайн кода», «Понимание кода» и «генерация кода», к LLMS, лучше всего подходит для каждой задачи. Аналогичным образом, предприятия могут направлять запросы на создание документов на такую модель, как Sonnet Claude 3.7 при отправке задач редактирования изображений Gemini 2.5 Pro.
Система также идеальна «для личных помощников в различных областях, где пользователи имеют разнообразие задач от суммирования текста до фактических запросов»,-сказал Парача, добавив, что «в этих случаях архитор может помочь разработчикам объединить и улучшить общий опыт пользователя».
Эта структура интегрирована с Arch, AI-C-Native Proxy Server для агентов Katanemo Labs, который позволяет разработчикам реализовать сложные правила формирования трафика. Например, при интеграции нового LLM команда может отправить небольшую часть трафика для конкретной политики маршрутизации в новую модель, проверить ее производительность с внутренними показателями, а затем с уверенностью полностью переходить трафик. Компания также работает над тем, чтобы интегрировать свои инструменты с платформами оценки для дальнейшей оптимизации этого процесса для разработчиков предприятий.
В конечном счете, цель состоит в том, чтобы выйти за рамки реализации ИИ с высоты. «Arch-Router-и более широко арки-разработчики и предприятия переходят от фрагментированных реализаций LLM в единую политику, управляемую системой»,-говорит Парача. «В сценариях, где пользовательские задачи разнообразны, наша структура помогает превратить эту задачу и фрагментацию LLM в единый опыт, что делает конечный продукт чувствовать себя бесшовным для конечного пользователя».
Источник
