Google показала agentic RAG: поиск, который сам дособирает недостающие данные

Что нового

Google добавила в Gemini Enterprise Agent Platform новую архитектуру поиска — agentic RAG с кросс-корпусным поиском (Cross-Corpus Retrieval).

Главные факты:

• Многоагентная RAG‑схема с отдельными агентами: оркестратор, планировщик, переписчик запросов, агент фан-аут поиска, RAG‑агент, Sufficient Context Agent и агент синтеза.
• Новый Sufficient Context Agent проверяет, хватает ли фактов для ответа, и запускает дополнительные поиски, если данные неполные.
• По сравнению со стандартным RAG Google заявляет рост точности на фактологических датасетах до 34%.
• На датасете FramesQA (824 сложных мультихоп‑запроса, 2 676 PDF‑документов) agentic RAG:
  • в кросс-корпусном режиме (4 набора документов, один целевой + 3 «шумовых») даёт 90,1% правильных ответов;
  • при этом точность почти не падает относительно режима с одним корпусом.
• Задержка (latency) в однокорпусном и кросс-корпусном режимах отличается менее чем на 3%.
• Функция доступна как public preview в Gemini Enterprise Agent Platform.

Цены, лимиты контекста и точные SLA Google не раскрывает. Это часть корпоративной платформы Gemini, а не отдельный публичный API вроде PaLM 2.

Как это работает

Классический RAG vs agentic RAG

Обычный «ванильный» RAG работает просто:

1. LLM получает вопрос.
2. Ретривер ищет релевантные документы по этому вопросу.
3. LLM пишет ответ по найденному контексту.

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

Agentic RAG превращает поиск в последовательность шагов с несколькими агентами, которые умеют планировать, переписывать запросы и повторно искать недостающие фрагменты.

Роли агентов

Google описывает архитектуру как «исследовательский отдел», а не один поисковик. Внутри работают несколько специализированных агентов.

1. Orchestrator (Root Agent)

   • Принимает исходный запрос.
   • Понимает, что задача сложная и многосоставная.
   • Делит её на подзадачи и раздаёт другим агентам.

2. Planner Agent

   • Строит план, по каким источникам и в каком порядке искать.
   • Пример: «сначала финансовая БД, потом логи проектного менеджмента».
   • В кросс-корпусном режиме решает, из какого корпуса документов вообще стоит читать.

3. Query Rewriter

   • Разбивает длинный, размытый запрос на несколько конкретных поисковых подзапросов.
   • Пример: из «Что с проектом X?» делает:
     • «Отчёт о статусе Project X за Q3»
     • «Основные блокеры команды Project X».

4. Search Fanout Agent

   • Берёт набор переписанных запросов.
   • Рассылает их по разным источникам: базы, индексы, внешние корпуса.
   • Собирает фрагменты текста (snippets) для дальнейшей работы.

5. RAG Agent

   • Классический RAG‑компонент: по каждому подзапросу ищет в индексе и возвращает релевантные куски документов.

6. Sufficient Context Agent — ключевая новинка

   • Стоит на «выходе» перед генерацией ответа.
   • Делает три типа проверки:

   1. Проверка извлечённых фрагментов

   • Читает текстовые сниппеты, которые вернул RAG Agent.
   • Смотрит, есть ли в них ответы на все части исходного вопроса.

   2. Проверка черновика ответа

   • Система формирует промежуточный черновик.
   • Sufficient Context Agent смотрит на:
     • исходный запрос,
     • черновой ответ,
     • извлечённые фрагменты.
   • Если в запросе три пункта (например, лекарства, диета, аллергии), а в сниппетах только два, агент помечает контекст как «недостаточный».

   3. Анализ пропусков (missing pieces)

   • Агент явно формулирует, чего не хватает.
   • Генерирует лог с «Reason» и «Feedback»:
     • «Нашли список лекарств и диету».
     • «Не нашли данные об аллергических реакциях или побочных эффектах».
   • Даёт конкретный совет другим агентам: что именно и где искать дальше, например: «перепроверь документы по ключевым словам “rash”, “adverse events”».

7. Iteration loop

   • На основе фидбэка Sufficient Context Agent переписчик запросов формирует новые, более точные подзапросы.
   • RAG Agent повторно ищет, иногда в других документах или корпусах.
   • Цикл повторяется, пока агент не решит, что данных достаточно.

8. Synthesis Agent

   • Когда Sufficient Context Agent подтверждает полноту контекста, агент синтеза собирает финальный ответ.
   • Делает связное резюме с опорой на найденные документы.

Пример из медицины

Google разбирает запрос врача:

«Какие препараты для выписки и диетические ограничения у пациента после операции на колене, были ли аллергические реакции во время госпитализации? Не включай препараты, которые давали только в стационаре или при обращении в приёмный покой, кроме гепарина IV и Tenecteplase».

Ход работы:

1. Root Agent понимает, что нужно три блока: лекарства, питание, аллергии.
2. Planner Agent выбирает три источника: аптека (pharmacy), нутриция (nutrition), клинические записи (clinical notes).
3. Query Rewriter превращает длинный текст в несколько точных запросов по каждому блоку.
4. RAG Agent ищет сразу по всем фан-аут запросам.
5. Находит лекарства и диету, но не находит аллергии.
6. В обычном RAG на этом всё: ответ будет частичным.
7. Sufficient Context Agent видит, что часть про аллергии не покрыта сниппетами.
8. Агент формулирует, чего не хватает, и просит переписать запрос, чтобы целиться в «rashes», «adverse events» и т.п.
9. Query Rewriter создаёт новый запрос, RAG Agent лезет глубже в клинические записи.
10. После повторного поиска система находит нужные данные, Sufficient Context Agent подтверждает полноту, Synthesis Agent формирует итоговый отчёт.

Пример из FramesQA (мультимодальный фактологический датасет)

Задача:

«Из двух самых просматриваемых финалов телесезонов (на июнь 2024 года) какой шёл дольше и на сколько?»

Шаги, которые должна выполнить система:

1. Найти, что два самых просматриваемых финала — это MASH и Cheers.
2. Найти длительность каждого финала.
3. Посчитать разницу.

Vanilla RAG часто отвечает в духе:

«Не нашёл явных длительностей, есть только данные по просмотрам».

Agentic RAG:

1. Сначала ищет сами шоу.
2. Потом через Query Rewriter и Sufficient Context Agent запускает целевые запросы на длительность финалов.
3. После этого Gemini может спокойно ответить:

«Финал MASH шёл 150 минут, это на 52 минуты дольше финала Cheers (примерно 98 минут)».

На этом датасете Google и оценивает выигрыш по точности.

Что это значит для вас

Для кого это реально полезно

Agentic RAG заточен под сложные, многошаговые запросы, где данные лежат в разных системах.

Стоит смотреть на эту технологию, если вы:

• Enterprise / крупный бизнес

  • У вас несколько БД и хранилищ: CRM, ERP, тикеты, документы, вики.
  • Сотрудники задают вопросы, которые требуют 2–5 «прыжков» по данным.
  • Важна прослеживаемость и обоснованность ответа (аудит, регуляторы).

• Финансовые сервисы и аналитика

  • Нужно собирать данные из разных отчётов, логов, систем учёта.
  • Частые запросы вида: «покажи бюджет по проектам с учётом последних корректировок и рисков».

• Медицина и здравоохранение

  • Истории болезни, назначения, лабораторные отчёты живут в разных подсистемах.
  • Важно не пропустить критичную деталь (аллергию, побочный эффект).

• Внутренние ассистенты для корпораций

  • Нужен «внутренний Copilot», который не просто отвечает по одному документу, а умеет переходить между системами и проверять, что ничего не упущено.

Где agentic RAG помогает особенно сильно

1. Мультихоп‑запросы

   • Всё, что требует нескольких логических шагов: найти сущности, потом их свойства, потом посчитать разницу или собрать сводку.

2. Кросс-корпусный поиск

   • Когда данные лежат в нескольких независимых хранилищах.
   • Planner Agent умеет выбирать нужный корпус, а не стрелять по всем подряд.

3. Сценарии, где опасны «догадки» модели

   • Sufficient Context Agent снижает риск, что LLM просто придумает недостающие факты.
   • Если данных нет, система может честно сказать, что не хватает контекста.

4. Аудит и соответствие требованиям

   • Ответ опирается на явно извлечённые сниппеты.
   • Легче показать, откуда взялась каждая часть вывода.

Где технология пока спорна

1. Простые Q&A по одному документу

   • Для FAQ, базовых чат-ботов и поиска по одной базе классический RAG часто дешевле и проще.
   • Многоагентная схема может быть избыточной.

2. Сверхжёсткие требования по задержке

   • Google заявляет, что разница в latency между одним и четырьмя корпусами < 3%.
   • Но многоагентный цикл с итерациями всё равно сложнее, чем один запрос к ретриверу.
   • Для real-time сценариев с миллисекундными SLA может потребоваться тюнинг и кэширование.

3. Ограниченный доступ к Google Cloud / Gemini

   • Agentic RAG доступен через Gemini Enterprise Agent Platform.
   • Для России доступ к сервисам Google Cloud и Gemini нестабилен и часто требует VPN и корпоративной инфраструктуры за пределами РФ.

Практический совет

Если вы уже используете RAG в корпоративном ассистенте и регулярно видите:

• неполные ответы,
• «не нашёл», хотя люди потом находят руками,
• галлюцинации, когда модель заполняет пробелы выдумками,

agentic RAG — логичный следующий шаг. Его стоит тестировать на ваших реальных сценариях, особенно там, где запросы мультишаговые и данные раскиданы по разным системам.

Если же вы только начинаете и у вас один индекс документов, проще стартовать с классического RAG, а к agentic‑схеме вернуться, когда структура данных усложнится.

Место на рынке

Google напрямую не сравнивает agentic RAG с продуктами OpenAI или Anthropic по скорости и цене. Зато даёт несколько опорных точек по сравнению с собственным «ванильным» RAG.

Что есть в цифрах:

• До 34% прироста точности на фактологических датасетах по сравнению со стандартным RAG Google.
• На FramesQA в кросс-корпусном режиме (4 корпуса документов) — 90,1% правильных ответов.
• Разница в задержке между однокорпусным и кросс-корпусным режимами — в среднем менее 3%.

Что это говорит о позиции продукта:

• Google делает ставку не только на качество самой модели (Gemini), но и на архитектуру вокруг неё: планирование, маршрутизация запросов, контроль полноты контекста.
• Agentic RAG встроен в корпоративную платформу, а не идёт как отдельный open source‑фреймворк. Это ближе к «платформенным ассистентам» в духе Microsoft Copilot Studio, чем к библиотекам уровня LangChain.
• Сценарий «cross-corpus» явно нацелен на большие компании с разрозненными хранилищами данных, а не на стартапы с одним векторным индексом.

По сравнению с классическими RAG‑решениями в экосистеме open source (Haystack, LangChain, LlamaIndex), главное отличие — наличие встроенного Sufficient Context Agent, который формализует понятие «достаточного контекста» и запускает дополнительные итерации поиска автоматически.

Конкретных сравнений по цене запросов, лимитам токенов или скорости с GPT‑4o, Claude 3/4 или другими проприетарными системами Google не приводит. Поэтому оценивать экономику придётся на собственных пилотах в Gemini Enterprise Agent Platform.

Итог

Agentic RAG от Google — это шаг от «поиска по одному индексу» к многошаговому исследованию по нескольким источникам с встроенным контролем полноты данных. Для сложных корпоративных сценариев это реальный способ снизить число неполных ответов и галлюцинаций без ручного написания многоходовых пайплайнов.

Если вы строите внутреннего ассистента на данных компании и уже упёрлись в ограничения классического RAG, стоит внимательно посмотреть на новый режим в Gemini Enterprise Agent Platform — особенно на кросс-корпусный поиск и Sufficient Context Agent.

---

Читайте также

• Amazon Bedrock AgentCore: как перестать держать ноутбук открытым ради ИИ‑агентов для кода
• vibeOS: операционная система, где всем управляет Claude Code
• 90210: локальная фабрика короткометражек на базе Veo 3.1 и Gemini 2.5 Pro