SIRAG: двухагентная RAG-система с процессным контролем качества

INPUT: вопрос пользователя

ЦИКЛ (макс 5 раундов):
 ШАГ 1 [Decision Maker]: Решить действие
 → Retrieve(новый_запрос) — сделать поиск
 → Stop & Generate — хватит, генерируй ответ
 
 ЕСЛИ Retrieve:
 ШАГ 2 [Retriever]: Найти документы по запросу
 
 ШАГ 3 [Knowledge Selector]: Отфильтровать документы
 → Вход: вопрос + найденные документы + текущий контекст
 → Выход: подмножество релевантных документов
 
 ШАГ 4 [LLM-Judge]: Оценить качество шага (0-1)
 → Хороший ли запрос?
 → Полезны ли отобранные документы?
 
 Добавить отобранные документы в копилку
 
 ЕСЛИ Stop & Generate:
 ВЫХОД из цикла

ФИНАЛ: Генератор создаёт ответ из накопленных документов

Обучение: Агенты тренируются через PPO (reinforcement learning) с наградами от LLM-Judge + правильность финального ответа.

Задача: Нужно найти информацию о том, какие новые законы по маркетплейсам приняли в России в 2024 году. Обычный RAG выдаст кашу из старых и новых законов, новостей, комментариев — и будет пытаться из всего этого собрать ответ.

С двухагентной схемой (вручную в чате):

Промпт 1 — Decision Maker:

Вопрос: Какие новые законы по маркетплейсам приняли в России в 2024 году?

Текущий контекст: [пусто]

Выбери действие:
1. RETRIEVE: сформулируй новый поисковый запрос
2. STOP: если достаточно информации для ответа

Ответ в формате:
Действие: [RETRIEVE/STOP]
Обоснование: [почему]
Запрос: [если RETRIEVE]

Промпт 2 — Knowledge Selector (после получения результатов поиска):

Вопрос: Какие новые законы по маркетплейсам приняли в России в 2024 году?

Найденные документы:
1. [Закон о защите прав потребителей на маркетплейсах, июль 2024]
2. [Статья РБК про проблемы Wildberries]
3. [Изменения в налогообложении для продавцов, январь 2024]
4. [Обсуждение законопроекта в Госдуме, декабрь 2023]
5. [Новые требования к маркетплейсам от Роскомнадзора, август 2024]

Какие документы ДЕЙСТВИТЕЛЬНО релевантны для ответа?
Отбери только те, что содержат конкретные законы принятые в 2024.

Формат ответа:
Релевантные документы: [номера]
Обоснование для каждого: [почему взяли/отбросили]

Промпт 3 — LLM-as-Judge (оценка качества шага):

Оцени качество действий:

Запрос: "законы маркетплейсы 2024 Россия"
Отобранные документы: #1, #3, #5

Критерии:
- Запрос точный и найдёт нужное?
- Отобранные документы релевантны вопросу?
- Есть ли среди отброшенных что-то важное?

Оценка: [0-1]
Что можно улучшить:

Результат: Через 2-3 итерации (поиск → фильтрация → оценка) модель соберёт именно релевантные документы о конкретных законах 2024 года, отбросив новости, обсуждения и старые законы. В финале генератор получит чистый набор документов и выдаст точный структурированный ответ.

Слабость обычного RAG: Модель видит все найденные документы скопом и пытается из них что-то слепить. Если среди 10 документов 3 релевантных, 4 частично релевантных и 3 мусорных — модель размазывает внимание по всем. Плюс нет механизма "стоп, нужно больше информации" или "эти документы не годятся, поищем иначе".

Сильная сторона LLM: Модели отлично умеют рассуждать пошагово и оценивать качество. Если спросить "эти документы полезны для ответа на вопрос?" — модель даст точную оценку. Если дать роль судьи — будет судить объективно.

Как SIRAG использует это:

1. Разделяет большую задачу на микрозадачи — вместо "найди и ответь" делает "решить нужен ли поиск → отфильтровать документы → оценить качество → решить повторить или ответить". LLM отлично работает с такими атомарными задачами.
2. Добавляет петлю обратной связи — LLM-Judge оценивает каждый шаг и даёт сигнал "это действие было полезным". Так система учится не повторять ошибки (если Judge поставил 0.2 — значит запрос был плохой).
3. Использует специализацию — один агент думает про стратегию поиска (продолжать/остановиться), другой про качество документов (что взять/что выбросить). Как два эксперта с разной экспертизой, а не один универсал.

Рычаги управления:

• Максимальное число раундов (в статье 5) → уменьши до 2-3 для простых вопросов, экономия запросов
• Критерии для LLM-Judge → добавь свои (например, "документ не старше года")
• Условие Stop → вместо "достаточно документов" можно "достигнута уверенность 0.8"
• Роли агентов → вместо безликих DM/KS дай конкретные роли: "придирчивый редактор" и "опытный исследователь"

Ты — координатор исследования. Твоя задача: решить, нужен ли ещё поиск или достаточно информации для ответа.

Вопрос: {вопрос_пользователя}

Текущий контекст:
{список_собранных_документов}

Раундов поиска выполнено: {число_раундов} / 5

Выбери действие:
1. RETRIEVE — сформулируй новый поисковый запрос (если информации недостаточно)
2. STOP — если накоплено достаточно для полного ответа

Формат ответа:
Действие: [RETRIEVE/STOP]
Обоснование: [почему принял это решение]
Запрос: [если выбрал RETRIEVE — сформулируй точный запрос]

Подставь:

• {вопрос_пользователя} — исходный вопрос
• {список_собранных_документов} — что уже найдено (или "пусто" в начале)
• {число_раундов} — счётчик итераций

Ты — эксперт по отбору релевантных документов.

Вопрос: {вопрос_пользователя}

Найденные документы:
{список_документов_с_номерами}

Текущий контекст (что уже собрано):
{список_ранее_отобранных}

Задача: отбери ТОЛЬКО те документы, которые:
- Напрямую отвечают на вопрос
- Не дублируют уже собранные
- Содержат конкретные факты/данные

Формат ответа:
Отобранные документы: [номера через запятую]
Для каждого — краткое обоснование (1 строка):
Отброшенные документы: [номера]
Почему отбросил: [причины]

Подставь:

• {вопрос_пользователя} — исходный вопрос
• {список_документов_с_номерами} — результаты поиска с нумерацией
• {список_ранее_отобранных} — что уже в копилке

Ты — независимый эксперт, оцениваешь качество шагов исследования.

Вопрос: {вопрос_пользователя}

Выполненное действие:
- Поисковый запрос: "{запрос}"
- Отобранные документы: {номера_документов}

Оцени по шкале 0-1:
1. Насколько точен запрос? (найдёт ли нужное)
2. Правильно ли отобраны документы? (релевантны ли вопросу)
3. Не упущено ли что-то важное?

Формат ответа:
Оценка: [0.0 - 1.0]
Сильные стороны:
Что можно улучшить:
Рекомендация: [продолжить поиск / достаточно]

Подставь:

• {вопрос_пользователя} — исходный вопрос
• {запрос} — что искали
• {номера_документов} — какие документы взяли

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

Помоги настроить двухагентную RAG-систему для моей задачи: {твоя_задача}.

Адаптируй эти три промпта под мой вопрос. Задавай вопросы если нужны детали:
- какой тип информации ищем?
- какие критерии качества документов?
- сколько раундов поиска максимум?

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

LLM спросит про специфику твоей задачи (область, требования к источникам, критерии релевантности) — потому что каждый тип исследования требует свои фильтры (для медицинских данных — проверенные источники, для новостей — свежесть, для технических вопросов — официальная документация). Модель возьмёт паттерн из шаблонов и адаптирует критерии отбора и оценки под твой домен.

⚠️ Токены: Три отдельных промпта на каждую итерацию → в сложных задачах (5 раундов) будет 15+ запросов. Дорого в API, медленно в чате.

⚠️ Субъективные критерии: LLM-Judge хорош для оценки релевантности и полноты, но не для оценки стиля, креатива или этических аспектов. Если задача "найди самую красивую архитектуру" — судья не поможет.

⚠️ Простые вопросы: Для фактических вопросов ("столица Франции") двухагентная схема — overkill. Используй только для сложных исследовательских задач где нужно собирать информацию по кусочкам.

⚠️ Зависимость от поисковика: Если поисковик плохой — никакие агенты не спасут. Метод улучшает координацию между поиском и генерацией, но не качество самого поиска.

Исследователи взяли 4 датасета вопросов — два простых (NQ, PopQA), два сложных multi-hop (2Wiki, HotpotQA). На каждом взяли всего 100 случайных вопросов (вместо полного набора) — небольшая выборка, но для proof-of-concept достаточно.

Что сравнивали: SIRAG против пяти методов:

• Стандартный RAG (найти → ответить без фильтров)
• Reranker (переранжировать документы по релевантности)
• Query-Writer (переписать запрос для лучшего поиска)
• SelfRAG (самопроверка: модель сама решает когда искать)

Результаты удивили в multi-hop задачах: На простых вопросах SIRAG выиграл скромно (+1.8% на PopQA). Но на сложных, где нужно собирать информацию по частям — рванул вперёд: +9.3% на 2Wiki, +9.2% на HotpotQA. Это логично: чем больше шагов рассуждения, тем важнее координация между поиском и генерацией. Одношаговые вопросы не раскрывают силу метода.

Ключевой инсайт из ablation study: Когда убрали LLM-Judge (оставили только финальный reward "правильно/неправильно"), качество стало нестабильным — иногда проваливалось ниже базовой модели. Почему? Потому что система не понимала какое КОНКРЕТНОЕ действие было плохим — если финальный ответ неправильный, это может быть из-за плохого запроса ИЛИ плохой фильтрации ИЛИ преждевременной остановки. Без процессного контроля — слепое обучение методом тыка.

Практический вывод: Если делаешь multi-step workflow — оценивай каждый шаг, не только результат. Это как в бизнесе: если продажи упали, не просто "плохо" — нужно понять на каком этапе воронки потери (реклама? конверсия? повторные покупки?).

SIRAG исследовали на общих вопросах, но метод особенно силён для информации с датами — законы, новости, релизы продуктов.

Промпт для Knowledge Selector с временным фильтром:

Ты — фильтр документов с фокусом на актуальность.

Вопрос: {вопрос} (требуется информация за {период})

Найденные документы:
{документы_с_датами}

КРИТЕРИИ ОТБОРА:
1. Дата документа в пределах {период}
2. Документ содержит конкретные данные/факты
3. Не дублирует уже собранное

Если документ релевантен НО устарел — укажи это явно.

Формат ответа:
Релевантные и актуальные: [номера]
Релевантные но устаревшие: [номера] — [указать что именно устарело]
Нерелевантные: [номера]

Когда применять: Юридические изменения, финансовая отчётность компаний, технические спецификации продуктов, медицинские рекомендации — всё где дата критична.

Стандартный Decision Maker выдаёт бинарное решение: RETRIEVE или STOP. Но полезно видеть степень уверенности.

Изменённый промпт:

Действие: [RETRIEVE/STOP]
Обоснование: [почему]
Уверенность: [0-100%]
 - если <50% — поясни что смущает
 - если 80%+ — укажи почему уверен
Запрос: [если RETRIEVE]

Зачем: Если Decision Maker говорит "STOP" с уверенностью 55% — это слабый сигнал, может стоит сделать ещё один раунд поиска. Если "RETRIEVE" с уверенностью 95% — точно есть пробел в знаниях. Уверенность = метрика качества решения.

Замени абстрактные "Decision Maker" и "Knowledge Selector" на конкретные роли с характером.

Пример:

Ты — Владимир Познер на пенсии. Ведёшь глубокое расследование.

[...]

Ты сомневаешься в поверхностной информации. Ты знаешь когда нужно копнуть глубже,
а когда достаточно фактов для выводов. Ты не терпишь домыслов — только проверенные источники.

Вместо "Knowledge Selector":

Ты — главред "Медузы". Отбираешь факты для статьи.

[...]

Ты берёшь только проверенные источники. Ты знаешь разницу между фактом и мнением.
Ты отбрасываешь дубли и околотематический мусор безжалостно.

Эффект: Персонажи дают более острые оценки и специфичные критерии. Познер не остановит исследование на первых 3 документах. Главред Медузы не возьмёт сомнительный источник.

SIRAG: Towards Stable and Interpretable RAG with A Process-Supervised Multi-Agent Framework — Junlin Wang, Zehao Wu, Shaowei Lu, Yanlan Li, Xinghao Huang (Heyuan Tobacco Monopoly Administration, South China University of Technology)

Упоминания методов: Self-RAG (Asai et al., 2024), Query-Writer, Reranker, REPLUG

Техники: Proximal Policy Optimization (PPO), Generalized Advantage Estimation (GAE), Tree-structured rollout, LLM-as-a-Judge

Retriever: Contriever-msmarco на Wikipedia dump 2018

Модели: Qwen2.5-7B-Instruct (основная), Qwen2-0.5B (агенты)