Превосходство над frontier-производительность с помощью Fusion

Оригинал: https://openrouter.ai/blog/announcements/fusion-beats-frontier/

Brian Thomas · 6/12/2026

Мы обнаружили, что синтез результатов нескольких моделей способен значительно превзойти то, на что способны модели по отдельности. Представляем Fusion: инструмент, позволяющий получать такие комбинированные результаты так же легко, как при вызове одной модели. Он позволяет вам выбрать панель (panel) моделей-участников вместе с моделью-судьей (judge model), отвечающей за объединение их индивидуальных результатов воедино.

Чтобы понять преимущества Fusion, мы использовали бенчмарк (benchmark) в области deep research, который тестирует комбинацию логики (reasoning), использования инструментов и знаний. Мы выяснили, что:

  1. Панели стабильно превосходят отдельные модели.
  2. Производительность выше уровня frontier-моделей может быть достигнута с помощью frontier-панелей.
  3. Панели из бюджетных моделей могут превзойти frontier-модели и приблизиться к производительности frontier-панелей.

Попробуйте Fusion прямо сейчас в Chatroom или изучите документацию API, чтобы интегрировать его в ваше приложение.

Панели моделей стабильно показывают лучшие результаты в Deep Research

Мы протестировали Fusion на 100 задачах deep research из бенчмарка DRACO. Вот некоторые ключевые выводы:

  • Объединенные вместе Fable 5 + GPT-5.5 набрали 69,0%**, превзойдя любую отдельную модель, включая саму Fable 5 с ее 65,3%**.
  • Бюджетная панель (Gemini 3 Flash, Kimi K2.6 и DeepSeek V4 Pro) обошла GPT-5.5 и Opus 4.8. Она приблизилась к результату Fable 5 с разрывом менее 1%, при этом оказавшись на 50% дешевле.

Image placeholder

** 7 из 100 задач DRACO не были завершены, поскольку контент-фильтры Fable 5 заблокировали их выполнение. Мы решили не использовать Opus 4.8 в качестве запасного варианта для этих задач, поэтому результаты Fable отражают 93 оцененные задачи вместо полных 100. Это дает наиболее точную картину собственной производительности Fable, но означает, что прямые сравнения результатов с моделями, выполнившими все 100 задач, немного неравнозначны.

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

Один вызов API, который объединяет лучшие результаты нескольких моделей

Когда вы отправляете промпт во Fusion, мы параллельно рассылаем его панели моделей, у каждой из которых включены web search и web fetch. Модель-судья читает каждый ответ панели и выдает структурированный анализ: точки консенсуса, противоречия, частичное покрытие, уникальные идеи, слепые зоны. Затем вызывающая модель (calling model) пишет финальный ответ, опираясь на этот анализ.

Весь пайплайн выполняется на стороне сервера (server-side), поэтому его можно вызвать так же, как вы вызывали бы отдельную модель.

Вызовите Fusion напрямую, используя единый model slug:

{ "model": "openrouter/fusion", "messages": [ { "role": "user", "content": "What are the strongest arguments for and against carbon taxes?" } ] }

Или настройте панель:

{ "model": "openrouter/fusion", "messages": [{ "role": "user", "content": "..." }], "plugins": [{ "id": "fusion", "model": "google/gemini-3-flash-preview", "analysis_models": [ "google/gemini-3-flash-preview", "moonshotai/kimi-k2.6", "deepseek/deepseek-v4-pro" ] }] }

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

DRACO (от Perplexity AI) разработан именно для этого. Он содержит 100 задач deep research, охватывающих 10 доменов: академические исследования, финансы, право, медицина, технологии, UX-дизайн, общие знания, поиск иголки в стоге сена, персонализированная помощь и сравнение продуктов.

Каждая задача сопровождается рубрикатором, включающим около 39 взвешенных критериев в четырех категориях:

  • Фактическая точность (Factual Accuracy) (~20 критериев): проверяемые утверждения, которые должны быть верными в ответе.
  • Широта и глубина (Breadth & Depth) (~9 критериев): качество синтеза, анализ компромиссов, практические рекомендации.
  • Качество подачи (Presentation Quality) (~6 критериев): терминология, форматирование, читабельность.
  • Качество цитирования (Citation Quality) (~5 критериев): цитирование первоисточников с рабочими ссылками.

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

Каждый ответ оценивается по каждому критерию моделью-судьей три независимых раза. Мы приводим среднюю нормализованную оценку (от 0 до 100) по всем задачам.

У DRACO есть ограничения, которые признают авторы: он оценивает только текстовые взаимодействия исключительно на английском языке, а его статический набор задач может не в полной мере обобщаться на будущие сценарии применения deep research. Абсолютные оценки также зависят от выбора модели-судьи (в статье сообщается о сдвигах в 10–25 баллов между разными судьями), хотя относительные рейтинги систем остаются стабильными.

Как мы не даем моделям жульничать

Когда мы предоставили моделям панели доступ к web search, мы обнаружили нечто тревожное: они находили рубрикатор оценок DRACO в интернете. Хотя это было случайностью, вызванной поисковыми запросами, а не намеренным жульничеством, это все равно выявило реальный риск загрязнения данных (contamination).

Мы решили эту проблему, исключив адреса размещения результатов из web search и web fetch, лишив тем самым модели доступа к страницам, связанным с рубрикатором бенчмарка. Серверные инструменты OpenRouter универсально поддерживают эти списки исключений для всех моделей благодаря использованию сторонних провайдеров, таких как Exa или Parallel, поэтому их применение потребовало лишь изменения конфигурации в одну строку вместо патчинга каждой отдельной модели. Все результаты в этом посте были получены уже после внедрения списков исключений.

Если вы запускаете собственные оценки, вам доступен тот же механизм: передайте excluded_domains в web_search или blocked_domains в web_fetch в ваших определениях инструментов (tool definitions), чтобы запретить панели доступ к конкретным источникам.

Значительный прирост от объединения модели с самой собой

Мы запустили Opus 4.8 в паре с ней же самой в виде панели из двух моделей, при этом Opus 4.8 также выступала в роли синтезатора (synthesizer). Результат: 65,5% — скачок на 6,7 балла по сравнению с одиночной Opus 4.8 (58,8%). Это говорит о том, что значительная часть прироста от Fusion происходит за счет самого этапа синтеза, а не только от комбинирования различных архитектур моделей. Двойной запуск одного и того же промпта порождает разные цепочки рассуждений, разные вызовы инструментов и разный выбор источников. Этого недостаточно, чтобы превзойти разнообразный набор моделей, но это помогает нам понять влияние самого процесса синтеза.

Примечания к нашей реализации DRACO

Мы тщательно воспроизвели методологию, описанную в статье DRACO, за исключением использования Gemini 3.1 Pro Preview в качестве модели-судьи вместо выбранной авторами статьи Gemini 3 Pro. Это означает, что наши оценки нельзя напрямую сравнивать с опубликованными результатами оригинальной статьи.

Мы хотели сохранить высокие свойства выравнивания между ответами человека и LLM, которые изначально обусловили выбор авторов, одновременно задействуя проницательность более новой модели. Мы провели проверку на адекватность (sanity-check) нашего судейства с помощью Claude Sonnet 4.6 после того, как Gemini 3.1 Pro Preview получила низкие оценки в самом бенчмарке, и обнаружили, что она сохранила те качества, благодаря которым авторы выбрали ее в качестве судьи. Нашей целью было показать относительную разницу между Fusion и отдельными моделями.

Попробуйте Fusion

API: Отправьте "model": "openrouter/fusion", чтобы напрямую вызвать Fusion, или добавьте {"type": "openrouter:fusion"} в ваш массив tools, чтобы позволить модели самой решать, когда его использовать. Документация Fusion

Chatroom: Откройте openrouter.ai/fusion и выберите пресет или соберите собственную панель.