TL;DR
ExecutionRAG — техника для агента, который ищет ответ в несколько шагов. Агент ведёт реестр требований: список подвопросов, каждый со статусом (ждёт, ищем сейчас, закрыт, снят), короткой заметкой и источниками. Следующий поиск агент строит под открытый пункт из этого списка, а не под исходный вопрос целиком. Отвечает он только когда открытых пунктов не осталось.
Главная находка — дрейф поиска. Агент находит промежуточный факт, цепляется не за ту сущность и тратит остаток попыток на неё. Нужный документ при этом был доступен, но агент его не запросил. В логе это выглядит как «поиск ничего не нашёл», и вину обычно сваливают на поисковик. На самом деле в 66–69% неверных ответов сильного агента не хватало хотя бы одного нужного документа, а с ростом числа шагов доля растёт. Причина простая: у модели нет «счётчика» открытых вопросов, он размазан по свободным рассуждениям.
Реестр это чинит: нужные документы теряются заметно реже. Но тут же вскрывается следующая проблема. Агент чаще закрывает пункт раньше времени или сдаётся. Узкое место смещается с «найти» на «убедиться, что найденного достаточно». Ошибок становится меньше, но не пропорционально.
Схема метода
ШАГ 0: Один пробный поиск по вопросу → набор найденных фрагментов
ШАГ 1: По вопросу + найденному составить реестр подвопросов
(один "active", остальные "pending", заметки пустые)
ШАГ 2 (цикл): взять открытый пункт → искать под него
→ обновить только затронутые пункты:
статус / заметка / источники
ШАГ 3: Показывать агенту только изменения реестра (дельту)
ШАГ 4: Ответить, когда открытых пунктов нет.
Кончился бюджет поиска → частичный ответ с перечнем неподтверждённого
ПРАВИЛА: пункт уходит из списка только как "retired" с причиной.
Источники только добавляются, не стираются.
В статье это код-агент с несколькими вызовами модели. Правила «пункт не исчезает» и «источники не стираются» там выполняет код. В чате или в инструкции агенту их можно задать словами (см. шаблон).
Пример применения
Метод сильнее всего там, где ответ собирается цепочкой зависимых фактов, а каждый следующий поиск зависит от предыдущего ответа. Простые вопросы в одно действие ему не нужны.
Задача: Аналитик инвест-фонда готовит справку перед сделкой. Нужно выяснить, кто директор компании — крупнейшего поставщика категории на маркетплейсе, и в каких ещё компаниях он числится руководителем или учредителем. Цепочка: поставщик → директор → его другие компании → пересечения с конкурентами. Обычный агент легко «схватится» за соучредителя вместо директора и дальше копает не того человека.
Промпт:
Ты — исследовательский агент. Ты не отвечаешь, пока в реестре есть открытые пункты.
Выяснить: кто является генеральным директором компании — крупнейшего
поставщика категории «{категория}» на {маркетплейс}, и в каких ещё
компаниях он является директором или учредителем.
Источники: открытые реестры, сайты компаний, новости, отраслевые обзоры.
Шаг 0. Сделай один пробный поиск по задаче.
Шаг 1. По задаче и найденному составь реестр подвопросов.
Для каждого пункта веди:
- id и формулировка
- статус: pending / active / resolved / retired
- заметка (что известно и чего не хватает)
- источники (ссылки или названия документов)
Один пункт — active, остальные — pending.
Пока есть пункты pending или active:
1. Выбери открытый пункт.
2. Сформулируй поисковый запрос под ЭТОТ пункт. Учти исходную задачу
и заметку: что для него ещё не найдено.
3. Найди информацию.
4. Обнови только те пункты, которых коснулась находка.
5. Покажи мне только изменения: пункт, старый статус → новый статус, заметка.
- Пункт нельзя убрать из реестра молча. Только статус retired
с явной причиной (например, «позднее источник опроверг это допущение»).
- resolved ставь, только если источников достаточно для ответа на пункт.
- Источники только добавляй. Не стирай то, что уже записано.
- Не повторяй запрос, который уже делал.
Когда открытых пунктов нет — дай итоговый ответ и список пунктов с источниками.
Если ты сделал {число_поисков} поисков и пункты остались открытыми —
дай частичный ответ и прямо перечисли, что не подтверждено.
Результат: Сначала придёт реестр из 3–5 пунктов вроде «кто поставщик → кто его директор → какие ещё компании связаны с директором → пересечения». Дальше модель покажет по шагам только изменения: какой пункт закрыт, что записано в заметку, какой источник добавлен. В конце будет итоговая справка со ссылками на пункты. Если часть цепочки не подтвердилась, модель прямо перечислит открытое, а не «додумает».
Почему это работает
Слабость. Модель на длинной цепочке поиска держит план «в голове», то есть в потоке рассуждений. Одно неточное попадание (не тот человек, не та компания) подменяет цель, и неотвеченный подвопрос тихо теряется. Запросы дальше строятся вокруг ошибочной сущности. Кроме того, модель любит повторно искать то, что уже нашла.
Сильная сторона. Модель хорошо ведёт структурированную запись и следует явному списку: что открыто, что закрыто, чем подтверждено. Из заметки «чего не хватает» она точно строит следующий запрос. Явный список заставляет её каждый шаг адресовать конкретному пункту.
Как метод это использует. Реестр выносит состояние на поверхность: виден каждый момент «закрыл пункт». Правила «не удаляй пункт молча» и «источники только добавляются» не дают потерять цель и доказательства. Реестр составляется по пробному поиску, а не «из воздуха». Поэтому пункты получаются конкретными, а не размытыми и не такими, на которые в источниках нет ответа.
Рычаги управления: - Число пунктов и бюджет поиска — уменьши для простых задач (экономия токенов), увеличь для длинных цепочек. - Пробный поиск (Шаг 0) — убери, если тема вам хорошо знакома и цепочку вы можете написать сами. - Показ дельты — замени на «покажи весь реестр», если нужно полное наблюдение. Но контекст будет расти. - Условие закрытия пункта — ужесточи («resolved только с прямой цитатой»), если важна надёжность.
Шаблон промпта
Ты — исследовательский агент. Ты не отвечаешь, пока в реестре есть открытые пункты.
{задача: вопрос, на который нужно ответить цепочкой фактов}
Источники: {где искать}.
Шаг 0. Сделай один пробный поиск по задаче.
Шаг 1. По задаче и найденному составь реестр подвопросов.
Для каждого пункта веди:
- id и формулировка
- статус: pending / active / resolved / retired
- заметка (что известно, чего не хватает)
- источники
Один пункт — active, остальные — pending.
Пока есть пункты pending или active:
1. Выбери открытый пункт.
2. Сформулируй запрос под ЭТОТ пункт с учётом исходной задачи и заметки.
3. Найди информацию.
4. Обнови только затронутые пункты.
5. Покажи мне только изменения: пункт, статус до → после, заметка.
- Пункт нельзя убрать молча. Только retired с явной причиной.
- resolved — только если источников достаточно для ответа на пункт.
- Источники только добавляй, не стирай.
- Не повторяй уже сделанные запросы.
Нет открытых пунктов → итоговый ответ + пункты с источниками.
После {число_поисков} поисков остались открытые → частичный ответ
с перечнем неподтверждённого.
Что подставлять: {задача} — вопрос, где ответ собирается из 2–4 зависимых фактов. {где искать} — реальные источники, к которым у агента есть доступ. {число_поисков} — разумный предел, например 10–15.
🚀 Быстрый старт — вставь в чат:
Вот шаблон реестра требований для многошагового поиска. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой именно вопрос нужно разложить, где можно искать и сколько поисков допустимо. Это нужно, чтобы реестр строился под реальные источники и бюджет, а не абстрактно. Она возьмёт паттерн из шаблона и соберёт рабочий промпт под вашу цепочку фактов.
Ограничения
⚠️ Исходная реализация — код: в статье это агент с несколькими вызовами модели и правилами, которые выполняет программа, а не сама модель. Шаблон выше — перенос идеи в текстовую инструкцию. Готовых промптов в основном тексте статьи нет, и сам перенос авторы не проверяли. В чате модель может нарушать правила «не удаляй пункт».
⚠️ Простые вопросы: на двухшаговых вопросах, которые решаются сравнением из одного-двух источников, эффект почти нулевой. Метод помогает там, где подвопросы зависят друг от друга.
⚠️ Реестр не проверяет сам себя: модель сама решает, что пункт закрыт. После внедрения реестра выросло число преждевременных закрытий и отказов отвечать. Общая ошибка упала заметно меньше, чем число «потерянных» документов.
⚠️ Длинные цепочки остаются трудными: на четырёх шагах недостающих документов по-прежнему больше всего. Реестр не сделает недоступное доступным.
⚠️ Цена: метод тратит больше токенов и вызовов. На сложном наборе он читал около семи тысяч токенов поиска на вопрос.
⚠️ Старая модель в исследовании: все результаты получены на одной маленькой модели (GPT-4o-mini). Как это изменится на сильных современных моделях — неизвестно.
Как исследовали
Исследователи хотели отделить две причины, которые в логе выглядят одинаково: «поисковик не мог найти документ» и «агент не спросил». Они зафиксировали поисковик, базу документов и модель и меняли только одно — наличие реестра. Если с реестром нужный документ находился, значит, поисковик мог его вернуть и раньше. Так «провал поиска» превращается в измеряемую долю дрейфа.
Сравнивали с сильным агентом A-RAG на 1000 вопросах из трёх наборов (HotpotQA, 2WikiMultiHopQA, MuSiQue) и с кучей других методов. Каждому неверному ответу присваивали одну причину по строгому порядку: ошибка судьи, отказ, ошибка рассуждения, нехватка документа. На MuSiQue число ответов с недостающим документом упало с 382 до 234 (один поисковик) и с 383 до 274 (второй).
Неожиданность: общая точность выросла с 44,9 до 50,2 — гораздо скромнее. Ошибки рассуждения выросли с 9% до 26%, отказы — с 7% до 13%. Авторы честно оговаривают: часть роста — просто наблюдаемость, потому что у реестра каждое «закрыл пункт» записано, а у базового агента преждевременные ответы засчитывались как «не нашёл». Прирост сильнее всего на 2Wiki, где нужно держать цепочку зависимых подвопросов, а на HotpotQA почти нет. Это подтверждает механизм. Контроль на «просто читает больше текста» тоже есть: на 2Wiki реестр дал максимум прироста при том же или меньшем объёме найденного.
Практический вывод: после починки поиска главная проблема агента — поспешные «готово». Одной декомпозиции мало, нужна проверка достаточности.
Адаптации и экстраполяции
🔧 Техника: ужесточить условие закрытия пункта → меньше преждевременных «resolved»
Статья показывает, что узкое место теперь — достаточность доказательств. Добавьте в
- Перед статусом resolved процитируй фразу из источника, которая прямо
отвечает на пункт. Нет прямой цитаты — оставь пункт открытым и допиши в заметку,
чего не хватает.
Экстраполяция: реестр в файле инструкций агента. Для агента-исследователя в Claude Code или в кастомном GPT поместите блок CLAUDE.md. Дополнительно попросите агента вести реестр в отдельном файле register.md и обновлять его после каждого шага. Тогда состояние живёт вне потока рассуждений и не теряется на длинной сессии.
Ресурсы
- Работа: Beyond Retrieval Failure: Understanding Why LLMs Miss Evidence in Multi-Hop RAG, DAI '26 (Гонконг).
- Авторы: Jiaqi Wei (Zhejiang University, Shanghai AI Laboratory), Wenxuan Huang (Fudan University), Chengdong Xu (Sun Yat-sen University), Xiang Zhang (University of British Columbia), Wanli Ouyang (Chinese University of Hong Kong).
- Наборы данных: MuSiQue, HotpotQA, 2WikiMultiHopQA.
- Сравнивали с: A-RAG (основной базовый агент), IRCoT, HippoRAG / HippoRAG 2, LinearRAG, LAG, GFM-RAG и др.