TL;DR
Исследователи сравнили пять способов получить ответ от LLM — простой запрос, запрос с инструкцией «думай по шагам» (CoT), Self-Refine (сгенерировать → раскритиковать → переделать), Best-of-N (сгенерировать 3 варианта → выбрать лучший) и Debate (два агента спорят, судья выбирает финал) — на задачах по программированию, шахматным этюдам и математике. Причём каждую технику одинаково тщательно оптимизировали заранее, чтобы сравнение было честным.
Оказалось, что многошаговые техники (Self-Refine, BoN, Debate) дают прирост точности всего 2–5 процентных пунктов, но тратят в 2–4 раза больше токенов — то есть в разы дороже и медленнее. И что важнее: какая техника выиграет — зависит не от сложности задачи (как многие интуитивно думают), а от того, какая именно модель стоит за ней. Метод, который отлично работает на одной модели, может провалиться на другой — предсказать это заранее почти невозможно.
Но самая практичная находка — в другом месте. Один детально расписанный промпт с явными инструкциями (что делать сначала, что потом, в каком формате выдать ответ) поднял точность модели на задаче по программированию с 20% до 82% — это сильнее, чем любая многошаговая оркестрация. Иначе говоря: прежде чем городить сложную схему из нескольких запросов, попробуйте один раз нормально прописать промпт.
Схема сравнения (не метод, а тест пяти подходов)
БАЗОВЫЙ ВАРИАНТ 1: Просто задача → ответ
БАЗОВЫЙ ВАРИАНТ 2: Задача + "думай по шагам" (CoT) → ответ
ОРКЕСТРАЦИЯ 1 (Self-Refine):
Генерация ответа → Критика ответа → Переделка (до 2 раундов) → финальный ответ
ОРКЕСТРАЦИЯ 2 (Best-of-N):
3 независимые попытки → выбор лучшей по критерию → финальный ответ
ОРКЕСТРАЦИЯ 3 (Debate):
2 "агента" отвечают отдельно → видят ответы друг друга → каждый пересматривает →
судья изучает обе версии → финальный ответ
Все варианты тестировали на одних и тех же задачах, с одинаковыми моделями, при равном бюджете на "докручивание" промпта — чтобы разница была в самой схеме, а не в том, что один промпт вылизали лучше другого.
Пример применения
Задача: Вы просите Claude/ChatGPT написать код для парсинга Excel-файла с расходами компании и вывода отчёта.
Плохой (дорогой) подход — сразу лезть в многошаговую схему:
Шаг 1: Напиши код для парсинга файла
Шаг 2: Раскритикуй свой код
Шаг 3: Перепиши с учётом критики
Это работает, но требует 3+ отдельных обменов и не гарантирует ощутимого прироста качества.
Хороший подход — один детальный промпт:
Напиши Python-код, который парсит Excel-файл с расходами и строит отчёт по категориям.
Сначала опиши план: какие библиотеки используешь, как обрабатываешь пустые ячейки и
несовпадение форматов дат.
Затем напиши сам код.
Требования к выводу:
- Код в одном блоке, без пояснений внутри
- Обработка ошибок для случаев, когда файл повреждён
- В конце — краткий список того, что код НЕ умеет (ограничения)
Результат: модель сначала явно проговорит план (разделение "что делать" от "как делать" — как в примере из исследования), потом выдаст код с чёткой структурой. Это даст более надёжный результат за один запрос, чем цикл "сгенерируй-раскритикуй-переделай".
Если всё же нужна многошаговая проверка (например, для сложной задачи, где важна перепроверка) — берите Best-of-N, а не «дебаты»: попросите модель сгенерировать 3 разных решения и затем сама выбрать лучшее по чётким критериям. Это стабильно работало лучше «дебатов между агентами» во всех проверенных доменах.
Почему это работает
Модели плохо угадывают, что именно от них хотят, если инструкция общая («думай по шагам»). Слабость не в рассуждениях самих по себе, а в неопределённости задачи — модель не знает, на что обращать внимание.
Сильная сторона LLM — она отлично выполняет явно прописанную процедуру. Когда промпт разделяет этапы («сначала план, потом код»), задаёт жёсткие рамки вывода и указывает на конкретные ограничения задачи — модель следует этой структуре почти как чек-листу. Это и объясняет скачок с 20% до 82% точности в исследовании: не «больше вызовов», а более точная инструкция.
Многошаговые техники (Self-Refine, Debate) пытаются добавить качество через повторные проходы — но каждый проход тоже подчиняется тому же слабому промпту, если сам промпт не улучшен. Отсюда и разброс: без хорошей базовой инструкции лишние шаги просто умножают токены, а не качество.
Рычаги, которые можно крутить самому: - Число кандидатов в Best-of-N — 3 в исследовании, можно сделать 2 для экономии или 5 для более сложных задач - Критерий выбора лучшего варианта — замените на свой (например, "выбери вариант с наименьшим количеством строк кода") - Число раундов в Self-Refine — 2 в исследовании; для простых задач достаточно 1 - Явный "выходной контракт" — формат вывода, ограничения, что не должно быть в ответе — этот рычаг дал больше эффекта, чем любая многошаговая схема
Шаблон промпта (детальная инструкция вместо оркестрации)
Задача: {описание задачи}
Прежде чем решать, распиши план:
- Какой подход используешь
- Как обработаешь {специфичные для задачи сложности — например, крайние случаи, ограничения}
Затем реализуй план.
Формат ответа:
- {требование к структуре, например: только код без комментариев / только текст без списков}
- {явное ограничение: длина, стиль, что нельзя включать}
В конце добавь короткий список: что решение не учитывает или где могут быть слабые места.
🚀 Быстрый старт — вставь в чат:
Вот шаблон детального промпта. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про специфику вашей задачи (какие крайние случаи важны, какой формат вывода нужен) — потому что именно эта конкретика даёт основной прирост качества, а не количество шагов в диалоге.
Шаблон для Best-of-N (если нужна доп. надёжность):
{задача}
Сгенерируй 3 независимых варианта решения.
Затем сам оцени все три по критерию: {критерий, например "точность расчётов и читаемость кода"}.
Выбери лучший вариант и объясни почему.
Выведи только финальный выбранный вариант.
Ограничения
⚠️ Эффект зависит от модели: то, что дало прирост на одной модели, может не сработать на другой — универсального правила "эта техника всегда лучше" нет. Нужно проверять на своей связке модель+задача.
⚠️ Сложность задачи не предсказывает выгоду от оркестрации: интуиция "чем сложнее задача, тем больше пользы от многошаговых техник" не подтвердилась. Не стоит автоматически включать Self-Refine или Debate только потому, что задача кажется трудной.
⚠️ Debate почти никогда не оправдывает себя: во всех трёх доменах "дебаты" между агентами не показали значимого превосходства над простым CoT-промптом, при этом расходуя больше всего токенов.
⚠️ Прирост скромный в абсолютных числах: лучшие результаты — это 2–5 процентных пунктов точности. Если для вашей задачи такая точность некритична, оркестрация того не стоит.
Ресурсы
Leins, Pelleriti, Gonnermann-Müller, Pokutta — "When Does LLM Orchestration Pay Off?", Zuse Institute Berlin & TU Berlin. Методология оптимизации промптов — GEPA (Agrawal et al., 2026). Бенчмарки: Codeforces, Lichess, AMC из набора Easy2Hard-Bench (Ding et al., 2024).