TL;DR
MARS — техника, где вместо стандартных ролей «планировщик → кодер → дебаггер» LLM по очереди играет роли узких тематических экспертов (специалист по графам, специалист по динамическому программированию и так далее). Каждый специалист сам оценивает, подходит ли задача под его профиль, а затем они передают решение друг другу как эстафету — проверяют черновик и решают: оставить, исправить или передать дальше вместе с кратким отчётом.
Главная проблема обычных мультиагентных систем: когда LLM даёшь общие роли типа «программист» или «тестировщик», она сама выбирает алгоритмический подход к задаче — и часто выбирает неправильный, если задача требует специфической теории (геометрия, строки, графы). Проблема не в том, что модель не умеет писать код, а в том, что она не знает, какую теорию применить, когда роль слишком общая и размытая.
Метод решает это через эстафету: сначала пул специалистов сам решает, кто подходит под задачу (self-assessment по каждой теме), затем формируется команда из 2-3 участников. Первый пишет черновик, проверяет его на примерах, и на каждом шаге текущий специалист решает — доработать самому или передать следующему с чётким описанием, что сделано и что осталось.
Схема метода
ШАГ 1: Пул специалистов (по теме) оценивает задачу → флаг "подходит/не подходит" + уверенность
ШАГ 2: Формируется команда 2-3 специалиста, выбирается стартующий → список ролей
ШАГ 3: Стартующий специалист пишет черновик решения → код/текст
ШАГ 4: Черновик проверяется на конкретном примере → отчёт "работает / не работает"
ШАГ 5: Специалист решает: оставить / исправить / передать дальше → структурированный пакет (что сделано, что осталось, в чём сомнение)
ШАГ 6: Повтор шагов 3-5 для следующего специалиста (до 3 участников, до 8 раундов)
ШАГ 7: Финальная зачистка — единый стиль, устранение технических шероховатостей
В оригинале шаги 1-2 — отдельный запрос (routing), шаги 3-6 — отдельные запросы с реальным запуском кода в песочнице. В чате это можно свернуть в один длинный диалог, но проверку на примере придётся имитировать вручную или через встроенный интерпретатор кода.
Пример применения
Задача: Разбор бизнес-плана стартапа перед питчем инвесторам — документ требует разной экспертизы: юнит-экономика, маркетинговая стратегия, юридические риски. Универсальный «бизнес-консультант» в одном промпте часто путает эти слои и даёт поверхностные комментарии по всем сразу.
Промпт:
Ты будешь работать как эстафета из нескольких экспертов, разбирающих бизнес-план по очереди.
Список возможных специализаций: юнит-экономика, маркетинг и позиционирование, юридические риски, финансовое моделирование.
ШАГ 1 — Отбор команды:
Вот бизнес-план: [вставить текст].
Для каждой специализации оцени: подходит ли она для разбора этого плана (да/нет) и насколько уверен (0-100%).
Выбери 2-3 специалиста с наивысшей уверенностью, определи кто начинает.
ШАГ 2 — Первый специалист разбирает план в своей области, отмечает риски и слабые места.
ШАГ 3 — Проверь свои замечания на конкретном примере из плана (например, на разделе про расчёт LTV).
ШАГ 4 — Реши: оставить свой разбор как есть, доработать самостоятельно, или передать следующему специалисту с кратким отчётом (что проверено, что осталось, в чём сомнение).
ШАГ 5 — Повтори для следующего специалиста, максимум 3 раунда.
ШАГ 6 — Собери финальный разбор в едином формате: сильные стороны, риски, рекомендации.
Результат: Модель сначала покажет таблицу самооценки специализаций с процентами уверенности. Затем — 2-3 раунда разбора, где каждый «эксперт» комментирует свою область и передаёт документ следующему с пометками. В финале — сводный отчёт с рисками и рекомендациями, структурированный по темам, а не размазанный общими фразами.
Почему это работает
Когда роль в промпте общая («ты бизнес-консультант», «ты программист»), модель сама выбирает, на что обратить внимание — и часто распыляется, потому что пытается охватить всё сразу поверхностно. Узкая роль работает как фокус: если сказать модели «ты специалист по юнит-экономике», она подтягивает более конкретные критерии и меньше уходит в общие рассуждения.
Сильная сторона LLM — она хорошо удерживает узкую роль, если её чётко назвать и дать конкретный участок работы. Слабость — без внешней структуры модель не умеет сама решать, когда её экспертизы недостаточно и нужно передать задачу «другому специалисту».
Метод обходит это через self-assessment на входе (кто из специалистов вообще подходит) и relay с явной передачей (что сделано, что осталось) — вместо того чтобы просить одну универсальную роль сделать всё и сразу.
Рычаги управления: - Число специалистов в команде (в оригинале до 3) → уменьши до 2 для простых задач, экономия времени - Критерий передачи (self-assessment confidence) → замени на явный чек-лист «что должно быть проверено» - Структурированный пакет передачи → упрости до трёх пунктов: сделано / осталось / сомнения - Финальный fixer-проход → полезен всегда, приводит разные куски работы к единому стилю
Шаблон промпта
Ты будешь работать как эстафета из нескольких тематических экспертов, решающих задачу по очереди.
Список возможных специализаций: {список_тем}.
ШАГ 1 — Отбор команды:
Для каждой специализации оцени задачу «{задача}»:
- Подходит ли эта тема под задачу? (да/нет)
- Насколько уверен (0-100%)
Выбери 2-3 специалиста с наивысшей уверенностью, определи, кто начинает эстафету.
ШАГ 2 — Черновик:
{специалист_1} пишет первую версию решения, используя знания своей области.
ШАГ 3 — Проверка:
Проверь черновик на примере: {контрольный_пример}. Отметь, что работает, а что нет.
ШАГ 4 — Решение специалиста:
{специалист_1} решает: оставить черновик, исправить самостоятельно, или передать {специалист_2} с кратким отчётом (что сделано, что осталось, в чём сомнение).
ШАГ 5 — Повтори шаги 3-4 для следующего специалиста, максимум {число_раундов} раз или до готовности решения.
ШАГ 6 — Финальная сборка:
Собери итоговую версию, приведи к единому стилю и формату.
Подставь: {список_тем} — 4-6 конкретных областей экспертизы под твою задачу, {задача} — сама задача, {контрольный_пример} — конкретный кейс или фрагмент для проверки, {число_раундов} — сколько передач эстафеты допустимо (обычно 2-3).
🚀 Быстрый старт — вставь в чат:
Вот шаблон эстафеты тематических специалистов (MARS). Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие специализации нужны для твоей задачи и по какому примеру проверять черновик — потому что без этого эстафета не соберётся правильно. Она возьмёт паттерн из шаблона и подставит твои темы вместо программистских специализаций.
Ограничения
⚠️ Теряется ключевая часть без реального запуска кода: в оригинале черновик проверяется в реальной песочнице на тестах — это даёт объективный сигнал. В обычном чате без встроенного интерпретатора модель «проверяет» код или текст сама на словах, а не фактически — это менее надёжно и может создавать иллюзию проверки.
⚠️ Не даёт выигрыша на простых однородных задачах: метод рассчитан на задачи, где нужна разная теоретическая экспертиза по темам. Если задача не распадается на разные области знаний — эстафета просто увеличивает время и объём текста без пользы.
⚠️ Медленнее и дороже прямого запроса: авторы показывают, что более «тяжёлые» системы с ещё бо́льшим числом итераций точнее MARS. Метод выигрывает по балансу скорость/качество, но не является максимально точным решением.
Ресурсы
Multi-Specialist LLM Relay System for Competitive Programming — Andrei Mikhailov (MIRAI), Mikhail Burtsev (London Institute for Mathematical Sciences), Alsu Sagirova. Код: github.com/fckand/mars. Тестировали на CodeContests test split с моделями Gemma 4, Qwen3.5-27B, GPT-5.4-mini.