Блог
Смесь агентов (MoA): как коллективный интеллект повышает производительность LLM

Смесь агентов (MoA): как коллективный интеллект повышает производительность LLM

Nov 30, 202410 min read

Быстрое развитие больших языковых моделей (LLM) похоже на палку о двух концах. С одной стороны, наличие множества современных LLM дает нам много вариантов для решения наших практических задач. С другой стороны, такое изобилие выбора может ошеломлять.

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

В этой статье мы рассмотрим один метод решения этой проблемы: подход Mixture-of-Agents (MoA), который объединяет несколько LLM с разными специализациями в единую систему. Итак, без лишних слов, начнем с некоторых мотиваций, лежащих в основе MoA.

Мотивация, лежащая в основе Mixture-of-Agents (MoA)

Быстрое развитие LLM подарило нам множество вариантов при выборе лучшей модели для нашей практической задачи. Однако теорема «бесплатных обедов не бывает» по-прежнему применима к LLM — ни одна модель не показывает одинаково хорошие результаты во всех задачах. Разные LLM превосходят другие в разных задачах из-за различий в данных, на которых они обучались. Поэтому крайне важно выбрать LLM, которая лучше всего подходит для конкретной проблемы, которую мы пытаемся решить.

Сложность возникает, когда мы имеем дело с многодоменными практическими задачами, требующими экспертизы от нескольких LLM. Это поднимает важный вопрос: Можем ли мы коллективно использовать несколько LLM, чтобы задействовать их индивидуальные сильные стороны и создать более мощную, надежную систему? Метод Mixture-of-Agents (MoA) пытается ответить на этот вопрос.

Что такое MoA?

Вкратце, Mixture-of-Agents (MoA) — это фреймворк, в котором несколько специализированных LLM, или «агентов», совместно решают задачи, используя свои уникальные сильные стороны.

Концепция MoA проста: мы объединяем несколько LLM с разными сильными сторонами и возможностями в единую систему. Когда пользователь отправляет запрос, каждая LLM в системе генерирует ответ. Затем назначенная LLM в конце синтезирует все эти ответы в один связный ответ для пользователя, как показано на визуализации ниже:

Рисунок: концепция Mixture-of-Agents

Рисунок: концепция Mixture-of-Agents.

Хотя концепция MoA проста, она удивительно эффективна. Авторы статьи о MoA обнаружили, что LLM склонны генерировать более качественные результаты, когда им предоставляют ответы других LLM.

Этот феномен был продемонстрирован с помощью бенчмарк-тестирования на наборе данных AlpacaEval 2.0 с использованием шести разных LLM, включая Qwen, Wizard, Mixtral, Llama 3 и dbrx. Авторы сравнили качество ответов LLM в двух условиях: при использовании прямых входных промптов и при использовании ответов других моделей. Они измеряли качество с помощью метрики доли побед Length Controlled (LC), которая оценивает качество выходных данных независимо от таких факторов, как длина ответа, способных существенно повлиять на результаты оценки.

Рисунок: сравнение долей побед LC в AlpacaEval 2.0 для каждой LLM при двух разных входах: напрямую из пользовательского промпта и из выходных данных других моделей

Рисунок: сравнение долей побед LC в AlpacaEval 2.0 для каждой LLM при двух разных входах: напрямую из пользовательского промпта и из выходных данных других моделей. Источник.

Результаты были согласованными для всех шести LLM: они достигали более высоких показателей LC win rate при работе с выходными данными других LLM по сравнению с непосредственной обработкой входных промптов. На основе этих результатов авторы разработали концепцию MoA, которую мы подробно рассмотрим в следующем разделе.

Основы Mixture-of-Agents (MoA)

MoA объединяет несколько LLM в одну систему для итеративного повышения качества генерации ответов.

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

Рисунок: Иллюстрация структуры Mixture-of-Agents

Рисунок: Иллюстрация структуры Mixture-of-Agents. Источник.

На основе этой концепции LLM, используемые в MoA, можно разделить на две категории: proposers и aggregators.

Proposers генерируют ответы внутри каждого слоя системы MoA, внося вклад в качество финального ответа.
Aggregators собирают все ответы от LLM в последнем слое и синтезируют их в один высококачественный ответ для пользователя.

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

Поскольку MoA может включать множество слоев, один и тот же LLM можно повторно использовать в качестве proposer либо внутри одного и того же слоя, либо в разных слоях. Например, мы можем построить систему MoA с 5 слоями, каждый из которых содержит 5 LLM, и использовать модель Llama3 70B во всех них как single-proposer.

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

Вот пример такого промпта:

Рисунок: Пример промпта для синтеза и агрегирования ответов от нескольких LLM

Рисунок: Пример промпта для синтеза и агрегирования ответов от нескольких LLM. Источник.

Хотя эта концепция похожа на подход Mixture-of-Experts (MoE) , используемый в традиционных нейронных сетях, есть ключевое отличие. В традиционных нейронных сетях слои MoE реализуются как несколько подсетей внутри архитектуры одной модели. Поэтому, когда у нас появляются новые данные, которые сильно отклоняются от обучающих данных, нам необходимо тонко настроить веса каждого слоя MoE для оптимизации производительности.

В то же время MoA полностью полагается на промптинг. Поэтому нет необходимости тонко настраивать LLM, чтобы улучшить общую производительность системы. Это обеспечивает большую гибкость, поскольку мы можем свободно выбирать разные LLM в качестве proposers или aggregators, независимо от их размера и архитектуры. Это также означает, что если в будущем появится новая state-of-the-art модель, мы сможем напрямую внедрить эту модель в нашу систему MoA в качестве proposer или aggregator.

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

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

Результаты оценки на бенчмарк-датасетах

MoA была оценена на трех бенчмарк-датасетах: AlpacaEval 2.0, MT-Bench и FLASK.

Были протестированы три разных варианта MoA:

MoA: трехслойная система с шестью предлагающими моделями на слой (Qwen1.5-110B-Chat, Qwen1.5-72B-Chat, WizardLM-8x22B, LLaMA-3-70B-Instruct, Mixtral-8x22B-v0.1, dbrx-instruct) и Qwen1.5-110B-Chat в качестве агрегатора.
MoA with GPT-4o: та же конфигурация, что и выше, но с использованием GPT-4o в качестве агрегатора.
MoA-lite: двухслойная система, использующая те же шесть предлагающих моделей и агрегатор, что и стандартная MoA.

Figure: 2-layers MoA (left) vs 3-layers MoA (right)

Рисунок: 2-слойная MoA (слева) против 3-слойной MoA (справа). Источник.

На датасете AlpacaEval 2.0 все три варианта MoA превзошли передовую модель GPT-4 Omni вплоть до 8,2%. Конфигурация MoA с GPT-4o в качестве агрегатора достигла самого высокого показателя LC win rate среди вариантов.

Все три варианта MoA также продемонстрировали конкурентоспособную производительность на датасете MT-Bench. Хотя текущая передовая модель GPT-4 Turbo показала исключительно хорошие результаты, MoA с GPT-4o в качестве агрегатора превзошла ее. Сравнение производительности вариантов MoA и других передовых моделей показано ниже:

Figure: Results on AlpacaEval 2.0 (left) and MT-Bench (right)

Рисунок: результаты на AlpacaEval 2.0 (слева) и MT-Bench (справа). Источник.

Датасет FLASK обеспечивает более детальную оценку, чем AlpacaEval 2.0 и MT-Bench, оценивая 12 аспектов: устойчивость, корректность, эффективность, фактическая точность, здравый смысл, понимание, проницательность, полнота, метакогниция, читабельность, краткость и безвредность.

Конфигурация MoA с Qwen1.5-110B-Chat в качестве агрегатора превзошла GPT-4 Omni в пяти аспектах: корректность, фактическая точность, проницательность, полнота и метакогниция. Между тем показатели по другим метрикам вполне сопоставимы с GPT-4 Omni, за исключением краткости. Конфигурация MoA показала заметное снижение краткости, как показано ниже:

Figure: Results on FLASK

Рисунок: результаты на FLASK. Источник.

Теперь, когда мы знаем ее производительность по сравнению с передовыми моделями, такими как семейство GPT-4, также интересно посмотреть на ее производительность по сравнению с другими родственными методами mixture-of-agent.

Как упоминалось в предыдущем разделе, примером другого метода, похожего на mixture-of-agent, является LLM ranker, который использует несколько LLM (предлагающих моделей) для генерации независимых ответов на входной prompt. Вместо использования агрегатора LLM ranker выбирает лучший ответ среди предлагающих моделей.

Для оценки и MoA, и LLM ranker использовали одни и те же шесть предлагающих моделей: Qwen1.5-110B-Chat, Qwen1.5-72B-Chat, WizardLM-8x22B, LLaMA-3-70B-Instruct, Mixtral-8x22B-v0.1 и dbrx-instruct. Каждая предлагающая модель была протестирована в качестве агрегатора для MoA, тогда как LLM ranker использовал только Qwen1.5-110B-Chat для выбора лучшего ответа.

В оценках на наборе данных AlpacaEval 2.0 MoA стабильно превосходил LLM-ранжировщики независимо от используемого агрегатора. Это показывает потенциал метода MoA, при котором агрегатор в конце не просто выбирает один из ответов от предлагающих моделей, а генерирует агрегацию по всем ответам предлагающих моделей, чтобы создать более способный и надежный итоговый ответ.

Figure: LC win rate on AlpacaEval 2.0 with different aggregators in an MoA setup with 6 proposers

Рисунок: LC win rate на AlpacaEval 2.0 с разными агрегаторами в конфигурации MoA с 6 предлагающими моделями. Источник.

Рекомендации по настройке Mixture-of-Agents (MoA)

Теперь, когда мы увидели производительность MoA по сравнению с семейством GPT-4 с использованием трех вариантов, каждый из которых имеет шесть разных предлагающих моделей, возникают два ключевых вопроса: как количество предлагающих моделей влияет на общую производительность MoA? И что произойдет, если мы будем использовать несколько одинаковых LLM в качестве предлагающих моделей вместо разных?

Чтобы определить влияние количества предлагающих моделей, автор статьи о MoA оценил MoA на AlpacaEval 2.0 с разным количеством предлагающих моделей. Они измерили LC win rate 2-слойных конфигураций MoA с использованием 6, 3, 2 и 1 разных предлагающих моделей. Результаты показывают, что большее количество предлагающих моделей помогает агрегатору генерировать более надежные ответы.

Кроме того, конфигурации MoA с одной предлагающей моделью (идентичные LLM в качестве предлагающих моделей) показали худшие результаты, чем конфигурации с несколькими предлагающими моделями. Это говорит о том, что MoA выигрывает от наличия разнообразного набора LLM с разными специализациями, а не от использования одной идентичной LLM.

Figure: Effects of the number of proposers on AlpacaEval 2.0.

Рисунок: влияние количества предлагающих моделей на AlpacaEval 2.0. Источник.

Учитывая преимущества конфигураций с несколькими предлагающими моделями, также важно понять, какие LLM лучше всего работают в таких конфигурациях. Тестирование шести разных LLM на AlpacaEval 2.0 показало, что такие модели, как GPT-4o, Qwen и Llama 3, достаточно универсальны, чтобы выступать как в роли предлагающих моделей, так и агрегаторов. Однако такие модели, как WizardLM, заметно лучше работают в качестве предлагающих моделей, чем агрегаторов.

Impact of different LLMs used as proposers vs aggregators

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

Что касается затрат, зависимость MoA от нескольких LLM делает его соотношение стоимости и производительности особенно интересным по сравнению с современными моделями, такими как GPT-4o и GPT-4 Turbo. Эксперименты показывают, что MoA-Lite может превосходить GPT-4 Turbo примерно на 4% на AlpacaEval 2.0, при этом снижая затраты более чем наполовину. Стоимость MoA-Lite здесь рассчитана на основе информации о ценах, доступной от TogetherAI. Однако если у нас нет проблем с тем, чтобы тратить больше для максимизации производительности, то 3-слойный MoA будет лучшим выбором.

Figure: Performance trade-off vs cost (left) and performance trade-off vs TFLOPS (right).

Рисунок: компромисс производительности и стоимости (слева) и компромисс производительности и TFLOPS (справа). Источник.

Для оценки задержки авторы использовали TFLOPS в качестве метрики. TFLOPS означает способность системы выполнять триллион операций с плавающей запятой за одну секунду. Хотя TFLOPS не вполне сопоставим с задержкой, автор использовал TFLOP как приближенную меру задержки, поскольку задержка может варьироваться в зависимости от систем инференса. Результат эксперимента показал, что конфигурация MoA с 3 слоями оптимизирует свои TFLOPS, чтобы максимизировать показатель побед LC, как показано пунктирной линией Парето на визуализации выше.

Однако семейство GPT-4 демонстрирует более высокие TFLOPS по сравнению с конфигурациями MoA. Это ожидаемо, поскольку MoA должен обработать несколько ответов LLM, прежде чем сгенерировать свой итоговый результат. Это приводит к его основному ограничению: Time to First Token (TTFT), что может негативно сказаться на пользовательском опыте. Будущая работа направлена на решение этой проблемы путем реализации агрегации ответов по фрагментам вместо агрегации всего ответа, что потенциально может снизить TTFT при сохранении производительности.

Заключение

Метод Mixture-of-Agents (MoA) предлагает перспективное решение для использования разнообразия и специализации современных LLM. Используя несколько LLM с различными сильными сторонами через систему предлагающих агентов и агрегаторов, MoA создает более качественный и надежный итоговый ответ. Его гибкость и опора на prompt engineering, а не на fine-tuning, делают его экономически эффективным и адаптируемым подходом, особенно для сценариев использования в нескольких доменах.

Оценки в бенчмарках на наборах данных, таких как AlpacaEval 2.0 и MT-Bench, показывают превосходную производительность MoA по сравнению с современными моделями, такими как семейство GPT-4. Для дальнейшей оптимизации производительности рекомендуется использовать конфигурацию с несколькими предлагающими агентами вместо конфигурации с одним предлагающим агентом. Однако MoA не лишен ограничений. Опора на несколько LLM увеличивает задержку, влияя на пользовательский опыт из-за более высокого Time to First Token (TTFT). Поэтому для оптимизации его эффективности необходимы дальнейшие улучшения, такие как агрегация ответов по фрагментам.

Связанные ресурсы

Обновлено Jul 28, 2026

Ruben Winastwan

Читать далее

The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery

Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.

My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.

Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.

How to Build RAG with Milvus, QwQ-32B and Ollama

Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.