IterSynth: разделение ролей «Планировщик» и «Синтезатор» с перезапуском контекста для глубокого поиска

ЦИКЛ (пока Планировщик не выдаст answer):

ШАГ 1. ПЛАНИРОВЩИК
  Видит: вопрос + сводка (и больше ничего)
  Делает: думает, что известно и чего не хватает
  Выдаёт: search("запрос")  ИЛИ  answer("итог")

ШАГ 2. ПОИСК (инструмент или человек)
  Выполняет запрос → возвращает найденные тексты

ШАГ 3. СИНТЕЗАТОР
  Видит: вопрос + сводка + решение Планировщика + найденные тексты
  Делает: фильтрует шум, вытаскивает факты, разрешает противоречия
  Выдаёт: НОВУЮ сводку (старая заменяется)
  Не может: искать и отвечать

→ Контекст сбрасывается. Следующий круг начинается с (вопрос + новая сводка).

Роли — один и тот же LLM с разными ролевыми инструкциями. Отдельные модели не нужны.

Задача: Вы готовите для инвестора разбор рынка быстрой доставки продуктов в России. Нужны выручка и доля Самоката, Яндекс Лавки, ВкусВилл и «Магнит Экспресс», с датами и источниками. Данные разбросаны по отчётам, интервью и новостям и местами противоречат друг другу. В одном чате на 30 запросов модель запутается в цифрах за разные годы.

Промпт (Планировщик, круг 1):

Ты — Планировщик глубокого поиска. Ты не читаешь сырые результаты поиска. Ты работаешь только с вопросом и сводкой. Твоя задача — понять, чего в сводке не хватает, и сформулировать ОДИН следующий поисковый запрос. Либо, если данных достаточно, дать финальный ответ.



Сравни крупнейших игроков быстрой доставки продуктов в России: Самокат, Яндекс Лавка, ВкусВилл, Магнит Экспресс. Для каждого нужны выручка (GMV или оборот) за последний доступный год, доля рынка и источник с датой. Укажи, где источники расходятся.



Пока пусто.



- Один запрос за круг, конкретный и пригодный для поисковика.
- Не повторяй запросы, уже отражённые в сводке.
- Отвечай только если по каждому игроку есть цифры с источником, а расхождения отмечены.



Think: что известно, чего не хватает, почему выбираю этот запрос.
Action: search("...") ИЛИ answer("...")

Вы (или агент с поиском) выполняете запрос. Затем отдаёте Синтезатору его результат вместе со старой сводкой, и он пишет новую. Потом начинаете новый чат: вопрос + новая сводка + промпт Планировщика.

Результат: Планировщик выдаст короткое рассуждение («по Самокату цифр нет, по Лавке есть оценка, нужен оборот») и один конкретный запрос. После обработки Синтезатором сводка будет расти структурно: факты по игрокам, источники, список расхождений. Через несколько кругов Планировщик увидит, что пробелов нет, и вместо запроса выдаст итоговый ответ. Каждый круг начинается с чистого контекста, поэтому старые страницы не мешают.

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

Сильная сторона: модель хорошо справляется с узкой задачей по чёткой инструкции. «Вот сводка, скажи, чего не хватает» и «вот страницы, обнови сводку» — две простые работы. Каждая сама по себе ей по силам.

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

Рычаги управления: - Что требовать от сводки. Структура (факты / расхождения / пробелы) определяет, насколько Планировщик видит дыры. Чем конкретнее поля, тем точнее следующий запрос. - Условие остановки. «Отвечай, только если по каждому игроку есть цифра с источником» — защита от преждевременного ответа. Замените на свой критерий готовности. - Один запрос за круг или несколько. Для простых задач разрешите 2–3 запроса — быстрее. Для сложных оставьте один — точнее. - Жёсткий запрет для Синтезатора («не ищи, не отвечай»). Это ключ метода. Если убрать, роли снова склеятся.

Промпты самих авторов в доступной части статьи не приведены (они в приложении). Шаблон ниже — реконструкция по описанию ролей, входов и допустимых действий из статьи.

Промпт 1 — Планировщик:

Ты — Планировщик. Ты видишь только вопрос и текущую сводку. Определи, каких сведений не хватает, и выдай один следующий поисковый запрос. Если сведений достаточно — выдай финальный ответ.


{вопрос}

{сводка_или_"пока пусто"}


- Не повторяй запросы, уже отражённые в сводке.
- Запрос должен быть конкретным и пригодным для поисковика.
- Отвечай, только если выполнено: {критерий_готовности}.



Think: что известно, чего не хватает, почему именно этот запрос.
Action: search("...") ИЛИ answer("...")

Промпт 2 — Синтезатор:

Ты — Синтезатор. Твоя единственная задача — обновить сводку. Ты НЕ формулируешь новые запросы и НЕ даёшь финальный ответ.


{вопрос}
{текущая_сводка}
{последнее_решение_Планировщика}
{найденные_тексты}


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



Think: что нового, что отброшено, что противоречит.
Summary: {полная обновлённая сводка — она заменяет старую}

Что подставлять: - {вопрос} — исходная задача целиком, без изменений на каждом круге. - {критерий_готовности} — когда можно отвечать, например «по каждому игроку есть цифра, источник и дата». - {сводка_или_"пока пусто"} — на первом круге «пока пусто», дальше выход Синтезатора. - {найденные_тексты} — то, что вернул поиск или что вы нашли сами.

🚀 Быстрый старт — вставь в чат:

Вот шаблон IterSynth (два промпта: Планировщик и Синтезатор). Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, что именно вы ищете, по каким объектам нужны данные, что считать «достаточно» для финального ответа и какие поля вести в сводке. Для метода это критично: критерий готовности и структура сводки задают, когда Планировщик остановится и что Синтезатор будет хранить.

⚠️ Основной результат — про обученную модель: главные цифры статьи получены на маленькой модели, которую авторы дообучали (SFT + RL). Читателю это недоступно. Из статьи применим только режим «без обучения», где выигрыш скромнее.

⚠️ Нужен цикл с пересборкой контекста: в обычном чате контекст растёт сам. Чтобы метод работал, нужно переносить «вопрос + сводку» в новый чат вручную или настроить агента, который делает это сам. В экспериментах это делал оркестратор.

⚠️ Сводка может потерять нужное: если Синтезатор отбросит важный факт, Планировщик его уже не увидит. Это главный риск схемы. Проверяйте сводку глазами на ключевых шагах.

⚠️ Избыточно для простых вопросов: если ответ находится за 2–3 запроса, два роля и сброс контекста только добавят работы.

⚠️ Проверено на задачах с одним проверяемым ответом: бенчмарки — это поиск конкретного факта. Для открытых аналитических отчётов, где «правильного ответа» нет, выигрыш статья не измеряла.

⚠️ Прирост умеренный: на сильных моделях это единицы пунктов в среднем, лучший случай — около десяти на одном бенчмарке. Не прорыв, а аккуратное улучшение.

Авторы сделали две вещи. Во-первых, взяли небольшую модель (8 млрд параметров), дообучили её работать по схеме «Планировщик ↔ Синтезатор» и сравнили с другими небольшими и более крупными агентами на пяти сложных поисковых бенчмарках. Маленькая модель обошла прежний лучший результат среди себе подобных и приблизилась к некоторым моделям втрое крупнее.

Во-вторых, проверили саму схему как чистый промптинг. Взяли Claude-4.5-Opus и DeepSeek-V3.1, без всякого обучения, и прогнали через четыре бенчмарка в трёх режимах: обычный ReAct, IterResearch (ближайший конкурент: тоже пересобирает контекст из отчёта) и IterSynth. IterSynth дал прирост к ReAct в среднем около +5,5 пункта на Claude и около +4,5 на DeepSeek. Лучший случай — до +10 на китайском BrowseComp. IterResearch он тоже обошёл на большинстве бенчмарков.

Любопытная деталь: в одном из приложений авторы замерили, что ReAct на сложном бенчмарке при 64К контексте в большинстве случаев (больше 59%) вообще не доходил до ответа — контекст кончался. Это показывает, что проблема не в уме модели, а в раздувающейся истории.

Вывод для практики: раздельные роли и сводка вместо истории — это структурный приём. Он работает на разных моделях, а не подгонка под одну.

💡 Адаптация для Claude Code / агента с файлами (моя достройка, в статье такого нет):

В CLAUDE.md задайте два режима и файл-память:

Copy

## Режим исследования
Состояние поиска хранится ТОЛЬКО в файле research/summary.md.
Каждый круг:
1. ПЛАНИРОВЩИК: прочитай вопрос и summary.md. Ничего больше. Определи, чего не хватает. Запиши ОДИН запрос в research/next_query.txt либо выдай финальный ответ.
2. Выполни поиск. Сырые результаты сохрани в research/raw_N.md.
3. СИНТЕЗАТОР: прочитай summary.md и raw_N.md. Перепиши summary.md целиком: факты с источником и датой, расхождения, пробелы. Не ищи и не отвечай.
4. Перед следующим кругом не опирайся на память о прошлых шагах — только на summary.md.

🔧 Техника: добавить в сводку раздел «пробелы» → острее следующий запрос

В промпте Синтезатора требуйте поля Подтверждено, Противоречия, Не найдено. Планировщик получает готовый список дыр и точнее формулирует запросы (идея-достройка, статья этого не проверяла).

• Работа: IterSynth: Rethinking Deep Search Agents via Role-Decoupled Iterative Synthesis
• Код: https://github.com/Tencent/IterSynth
• Авторы: Xingyu Wu, Yuchen Yan, Zhengxi Lu, Siqi Chen, Xin Zhang, Aiting Liu, Chao Deng, Jie Liu, Jin Ma, Jian Shao, Jun Xiao, Yongliang Shen — Zhejiang University, Tencent
• Упомянутые подходы: ReAct (Yao et al., 2023), IterResearch, ReSum, AgentFold, InfoFlow
• Бенчмарки: BrowseComp, BrowseComp-ZH, GAIA, Xbench-DeepSearch