От выбора модели к выбору стратегии
GitHub выпустил Project HydraFusion в статусе исследовательского превью (Research Preview) для всех подписчиков GitHub Copilot. Ключевое отличие от стандартного режима — система больше не ограничивается выбором одной модели для всего диалога. Вместо этого HydraFusion анализирует запрос и строит исполнительный план (workflow) специально под эту задачу, используя модели от разных провайдеров.
Система работает внутри GitHub Copilot CLI. Разработчикам нужно активировать экспериментальную функцию командой /experimental on, а затем выбрать модель HydraFusion (Research Preview) через команду /model. Оплата производится по стандартным тарифам за токены, потребленные каждой моделью в рамках построенного плана.
Три паттерна выполнения
HydraFusion оптимизирует затраты, выбирая один из трех сценариев обработки запроса, балансируя между скоростью, стоимостью и качеством:
- Single (Одиночный): Одна модель решает задачу напрямую. Максимальная скорость, базовая стоимость.
- Cascade (Каскад): Эффективная модель создает черновик. Если система качества (quality gate) его отклоняет, задача передается более мощной модели. Это позволяет не тратить дорогие ресурсы на простые задачи.
- Critique (Критика): Одна модель пишет код, а независимый «критик» из другой семейной группы моделей проверяет его. Затем авторская модель вносит правки. Этот паттерн добавляет внешнюю перспективу, где проверка эффективнее, чем повторная генерация.
Результаты бенчмарков: экономия против качества
GitHub протестировал фиксированные политики HydraFusion на трех агентных бенчмарках, сравнив результаты с базовыми моделями Claude Opus 5 и GPT-5.6 Sol (на уровне рассуждения medium). Ниже приведены относительные показатели стоимости и качества по сравнению с Opus 5:
| Бенчмарк | Экономия стоимости vs Opus 5 | Качество задачи vs Opus 5 |
|---|---|---|
| TerminalBench 2.1 | На 67% ниже | +4.9 балла |
| DeepSWE | На 36% ниже | −1.5 балла |
| CheckpointBench | На 65% ниже | −0.1 балла |
Наиболее впечатляющий результат показан в TerminalBench 2.1: при значительном снижении затрат качество кода даже выросло. На других наборах данных (DeepSWE и CheckpointBench) наблюдается незначительное снижение качества (менее 2 баллов), что компенсируется существенной экономией ресурсов.
Инженерные гарантии безопасности
Система построена на пяти принципах, критичных для работы с репозиториями:
- Полный учет: Логирование роли, результата, стоимости и задержки для каждого этапа (черновик, критика, исправление).
- Ограниченное выполнение: Явные таймауты и возможность отмены для каждого этапа.
- Изолированная проверка: Критики работают в средах без доступа к инструментам и не могут изменять репозиторий.
- Безопасное применение: Патч не применяется, если рабочий процесс отменен или не прошел валидацию.
- Валидированная маршрутизация: Проверка доступности моделей и fallback-поведения до начала выполнения.
Разработчик видит единый ответ и набор изменений, aware к правам доступа, в то время как внутри системы происходит сложная координация между разными моделями.
Источник: MarkTechPost ↗