TL;DR
Исследователи обучили маленькую модель (7B параметров) координировать большие LLM через reinforcement learning. Conductor не решает задачи сам — он разбивает их на подзадачи, назначает каждую подходящей модели из пула (GPT-5, Claude 4, Gemini 2.5, и др.) и контролирует какой контекст видит каждый агент. Выводит результат на естественном языке: три списка (подзадачи, ID агентов, доступ к предыдущим ответам). Workflow выполняется последовательно, каждый агент получает свою инструкцию и видит только разрешённый контекст.
Главная находка: маленькая модель-дирижёр достигает state-of-the-art, превосходя каждую большую модель поодиночке и дорогие multi-agent системы. Секрет не в размере, а в обученной способности: (1) разбивать сложную задачу на специализированные части, (2) подбирать модель под сильные стороны (GPT для кода, Claude для анализа), (3) prompt-инжинирить таргетированные инструкции под каждого агента, (4) изолировать контекст — не передавать всё всем, а выборочно. Модель обучалась через RL на 960 задачах (математика, код, reasoning), награду получала только за правильный финальный ответ.
Суть метода: Conductor выводит agentic workflow — последовательность шагов координации. Каждый шаг = подзадача (естественный язык) + ID агента + список доступа (какие предыдущие ответы видит). Например: Шаг 1 — агент 2 (Gemini) создаёт алгоритм, Шаг 2 — агент 0 (GPT) пишет код, видя ответ агента 2. Модель обучена через 200 итераций GRPO (RL алгоритм), научилась prompt engineering и стратегиям координации (debate, verification, refinement) end-to-end через максимизацию награды.
Схема метода
КАК РАБОТАЕТ CONDUCTOR (для понимания механики):
[Вход: Сложная задача]
↓
CONDUCTOR (7B модель):
- Chain-of-thought рассуждение
- Вывод workflow: [подзадачи], [ID агентов], [списки доступа]
↓
ВЫПОЛНЕНИЕ WORKFLOW (последовательно):
ШАГ 1: Агент #2 получает подзадачу → генерирует ответ
ШАГ 2: Агент #0 получает подзадачу + ответ агента #2 → генерирует ответ
ШАГ 3: Агент #1 получает подзадачу + выбранные ответы → финальный результат
↓
[Выход: Финальный ответ пользователю]
Обучение: RL (GRPO), награда +1 за правильный ответ, -0.5 за неправильный, 0 за некорректный формат.
Пример применения
⚠️ Важно: Сам Conductor требует инфраструктуры для обучения/использования. Ниже — как применить ПРИНЦИПЫ координации вручную.
Задача: Ты запускаешь онлайн-школу по data science. Нужно: проанализировать конкурентов, создать структуру первого курса, написать скрипт для автоматической проверки домашек.
ПРИНЦИП: Используй разные модели для разных частей, контролируй видимость контекста
Чат 1 — Claude (анализ и структурирование):
Проанализируй российский рынок онлайн-школ по data science:
- Кто главные игроки (Яндекс Практикум, Skillfactory, Нетология)
- Какие пробелы в их программах
- Какую нишу можем занять
Дай структурированный анализ с конкретными инсайтами.
Чат 2 — GPT-4 (программирование курса):
На основе анализа конкурентов создай структуру первого курса на 2 месяца.
КОНТЕКСТ из анализа:
[копируешь ключевые инсайты из ответа Claude, НЕ весь текст]
Дай: темы по неделям, практические проекты, точки отличия от конкурентов.
Чат 3 — GPT-4o (код):
Напиши Python-скрипт для автоматической проверки домашек студентов.
ТРЕБОВАНИЯ из программы курса:
[копируешь типы заданий из ответа про структуру]
Скрипт должен: проверять код на корректность, давать фидбек, ставить оценку.
Результат: Ты получишь три специализированных ответа: глубокий анализ рынка от Claude (его сильная сторона), чёткую программу курса от GPT-4 на основе анализа, рабочий код от GPT-4o. Каждая модель видит только релевантный контекст, не перегружена лишним. Ты вручную координируешь workflow, как это делает Conductor автоматически.
Почему это работает
Слабость LLM: Одна модель не может быть лучшей во всём. GPT силён в коде, Claude — в анализе и рассуждениях, Gemini — в креативе. При решении сложной задачи "в лоб" модель применяет усреднённые способности ко всем частям, теряя эффективность на каждой.
Сильная сторона LLM: Модели хорошо выполняют узкоспециализированные инструкции с ограниченным контекстом. Когда промпт точно таргетирован под сильную зону модели и не перегружен лишней информацией — качество резко растёт. Prompt engineering работает: правильная формулировка задачи важнее размера модели.
Как Conductor использует это: Он научился через RL трём вещам: (1) разбивать задачу на части под сильные стороны разных моделей, (2) формулировать таргетированные промпты (не "реши задачу", а "создай алгоритм" для планировщика, потом "реализуй в Python" для кодера), (3) контролировать поток информации — каждый агент видит только релевантный контекст через списки доступа, не тонет в лишнем тексте. Вручную такую координацию сделать можно, но трудоёмко — Conductor автоматизирует, поэтому превосходит даже самые мощные модели поодиночке.
Дополнительные механики, которые исследование показало: - Debate стратегии: Conductor научился давать одну задачу двум агентам параллельно, потом третьему — выбрать лучший ответ или синтезировать - Verification loops: Один агент решает, другой проверяет, первый исправляет - Difficulty-adaptive compute: На простых задачах использует 2 агента, на сложных — 4-5 - Recursive scaling: Продвинутая версия может вызвать себя самого как агента, создавая вложенные уровни координации
Ключевые принципы для ручного применения
Принципы координации из исследования:
Специализация агентов: Не давай всю задачу одной модели. Разбей на части под сильные стороны (код → GPT, анализ → Claude, креатив → Gemini).
Контекст-изоляция: Не копируй весь предыдущий диалог в следующий чат. Передавай только релевантную часть — модель фокусируется лучше.
Prompt engineering под агента: Формулируй инструкции точно под возможности модели. Не "напиши", а "создай структуру" для планировщика, "напиши код по структуре" для кодера.
Параллельная генерация + консенсус: Для критичных решений дай задачу 2-3 разным моделям, потом синтезируй или выбери лучшее.
Verification через другую модель: Одна модель генерирует, другая проверяет. Снижает галлюцинации и ошибки.
Рычаги управления (если делаешь вручную):
- Число агентов: Простая задача — 1-2 модели, сложная — 3-5. Больше агентов = выше качество, но дороже.
- Порядок вызовов: Последовательно (шаг за шагом) vs параллельно (несколько моделей сразу на одну задачу).
- Уровень детализации контекста: Передавать весь ответ предыдущего агента vs только ключевые инсайты.
- Роли агентов: Назначить явные роли (планировщик, исполнитель, критик) vs просто задачи.
Ограничения
⚠️ Требует инфраструктуры для автоматизации: Сам Conductor — это обученная модель, не промпт-техника. Чтобы использовать автоматическую координацию, нужен доступ к модели (исследование не выпустило публичную версию) или инфраструктура для воспроизведения (Python, RL обучение, API множества моделей).
⚠️ Ручное применение принципов трудоёмко: Координировать 3-5 моделей вручную (копировать между чатами, формулировать промпты, синтезировать ответы) занимает значительное время. Эффективно только для действительно сложных задач где выигрыш в качестве окупает время.
⚠️ Высокие затраты на API: Система использует несколько вызовов premium-моделей (GPT-5, Claude 4, Gemini 2.5) на одну задачу. В исследовании Conductor в среднем делал 3 шага — это минимум 3 платных запроса, часто к разным провайдерам.
⚠️ Нужны подписки на несколько моделей: Эффект координации проявляется при доступе к разным моделям с разными сильными сторонами. Если есть доступ только к одной — принципы не работают.
⚠️ Не для простых задач: Накладные расходы на координацию окупаются только на сложных задачах (code generation, научный reasoning, многошаговый анализ). Для "столица Франции" одна модель лучше.
Ресурсы
Learning to Orchestrate Agents in Natural Language with the Conductor — Stefan Nielsen, Edoardo Cetin, Peter Schwendeman, Qi Sun, Jinglue Xu, Yujin Tang. Sakana AI (Japan), University of Michigan, Institute of Science Tokyo.
Исследование показывает возможности обучения моделей-координаторов через RL. Код обещан в submission, но публичного релиза Conductor на момент анализа нет.