Что такое Agentic RAG: агент управляет поиском — это архитектура, в которой LLM-агент планирует короткие подзапросы, выполняет каждый против поисковика, взвешивает частичные ответы, переформулирует запрос при тонких результатах и синтезирует итог. Документация NVIDIA RAG Blueprint описывает такой конвейер как plan-and-execute на LangGraph рядом со стандартной цепочкой RAG.
Роль агента в выборе источника и повторном поиске
Для сравнения возьмём простую фиксированную схему: один поиск фрагментов и генерация по найденному. Это удобная исходная точка, но не определение всех возможных систем RAG. Агентный вариант добавляет решения во время выполнения: какие подвопросы выделить, куда направить поиск и достаточно ли свидетельств для ответа.
Документация NVIDIA RAG Blueprint описывает планировщик, выполнение задач, уточняющие запросы, синтез и проверку покрытия. Подзадача может искать повторно при частичном ответе. План может оказаться пустым, если начального контекста достаточно; дополнительная проверка включается отдельно. Это устройство конкретного конвейера.
AWS объясняет пользу разложения на вопросе с несколькими намерениями: один поиск по сходству может покрыть их неравномерно. LlamaIndex показывает другую организацию: агенты документов с поиском и суммаризацией, над которыми работает маршрутизирующий агент. Из этих примеров следует возможность разных реализаций, но не обязательное число агентов для каждого корпуса.
Для читателя практический вопрос — какие решения разрешено принять системе. Если источники заранее известны и вопрос прямой, дополнительный планировщик может оказаться лишним. Если ответ требует двух разных оснований, в журнале нужно сохранить оба. Само наличие агента ещё не подтверждает полноту найденного.
Цикл plan/search/check/answer на полном условном входе
Разберём цикл на ручном условном примере. Все решения заданы для ручного разбора; модель не запускалась, качество агента не измерялось. Входные данные:
Запрос: Можно ли заменить аккумулятор устройства А-10 и какой бланк нужен?
CATALOG: А-10: аккумулятор заменяемый; Б-20: аккумулятор незаменяемый
SERVICE: Для плановой замены аккумулятора А-10 нужен бланк S-4.
Для гарантийного случая нужна проверка мастера
STOCK: Остатки запасных аккумуляторов в базе не публикуются
Инструменты только для чтения:
search_catalog(query) -> CATALOG
search_service(query) -> SERVICE
search_stock(query) -> STOCK
Условный план:
1. проверить заменяемость в CATALOG
2. найти бланк в SERVICE
3. собрать ответ с ID источников
Лимит учебного контроллера: 3 вызова поиска.
Шаг plan. Агент читает запрос и видит два намерения: заменяемость и бланк. Он строит план из двух задач, каждая привязана к своему источнику. Третий инструмент в план не попадает, поскольку вопрос про остатки не задан.
Шаг search. Первая задача вызывает search_catalog и получает запись про А-10. Вторая вызывает search_service и получает правило про бланк S-4 для плановой замены.
Шаг check. Агент сверяет частичные ответы с исходным вопросом. Основание «А-10 заменяемый» подтверждено CATALOG, основание «для плановой замены нужен S-4» подтверждено SERVICE. Оба самостоятельных основания на месте, значит добор не нужен.
Шаг answer. Синтез собирает ответ: А-10 заменяемый [CATALOG], для плановой замены нужен бланк S-4 [SERVICE]; наличие запчасти и срок неизвестны. Проверка трассы требует, чтобы ответ содержал оба самостоятельных основания, не содержал ни одной записи во внешнюю систему и уложился в три условных вызова.
Теперь альтернативная ветка. Читатель спрашивает: «Когда привезут аккумулятор?» Агент вызывает search_stock, читает STOCK и получает сообщение о том, что остатки не публикуются. Данных для ответа нет. Цикл останавливается: повторять тот же запрос бесконечно бессмысленно, поэтому агент возвращает «неизвестно» и передаёт вопрос человеку. Эта ветка показывает, что check — самостоятельный шаг с правом остановить цикл.
Явный лимит и исход при нехватке данных
Лимит учебного контроллера — три вызова поиска на запрос. Он не описывает тариф или значение по умолчанию какого-либо сервиса. На основной ветке используются два вызова, значит запас на добор остаётся. Не нужно расходовать его только потому, что он разрешён.
Условие достаточности в основной ветке: CATALOG подтверждает заменяемость А-10, SERVICE задаёт бланк для плановой замены. Если найден только один документ, ответ ещё не закрывает обе части вопроса. Можно вернуть подтверждённую часть с пометкой пробела или потратить оставшийся вызов на целевой поиск недостающего основания.
Для вопроса о сроке поставки STOCK не содержит нужного факта. Его сообщение об отсутствии публикуемых остатков также не задаёт дату доставки. Повтор того же поиска без нового источника не создаст свидетельство. В этой ветке учебный контроллер завершает цикл и передаёт вопрос человеку.
Порядок настройки своего цикла: задать число вызовов, обязательные основания, допустимые источники и исход при исчерпании лимита. Ограничение числа поисков не заменяет таймаут и бюджет модели. Если запрос к инструменту завис, контроллер должен обработать технический сбой отдельно от содержательного ответа «неизвестно».
Для проверки остановки сохраните трассу даже неуспешной ветки. В ней должны быть исходный вопрос, сделанные вызовы, полученные документы и причина завершения. Отсутствующий факт, исчерпанный лимит и недоступный сервис — разные причины; смешивать их в один уверенный ответ нельзя.
Один агент и многоагентная архитектура
Планирование, поиск и проверка могут быть ролями одного конвейера. Несколько агентов — отдельный способ организации. В примере LlamaIndex каждый агент документа имеет поиск и суммаризацию, а верхний агент выбирает, к кому обратиться. В NVIDIA роли имеют отдельные настройки модели; по умолчанию может использоваться общая конфигурация.
Выбирать схему нужно по ответственности и доступным данным. В нашем примере достаточно описать три инструмента только для чтения. Разделение на агента каталога, сервиса и склада само по себе не добавит отсутствующий срок поставки. Оно добавит маршруты и места, где потребуется проверять переданный контекст.
| Вопрос проектирования | Что записать до реализации |
|---|---|
| Кто выбирает источник | Планировщик или фиксированный маршрут |
| Кто проверяет достаточность | Контроллер по заранее заданным основаниям |
| Кто имеет право менять внешние данные | В примере таких прав нет |
| Где действует лимит | На всём запросе, включая подзадачи |
| Кто объясняет остановку | Итоговый ответ с причиной и источниками |
Если добавляете второй уровень агентов, проверьте общий счёт вызовов. Локальное ограничение каждой подзадачи не обязательно ограничит весь запрос. Сохраняйте единый журнал и не теряйте ID источников при передаче подответов наверх.
Точность: что архитектура даёт и чего не гарантирует
Agentic RAG меняет процедуру поиска. NVIDIA описывает обмен дополнительных вызовов и задержки на возможность более полного поиска. AWS рекомендует измерять собственную смесь запросов и направлять планировщику те случаи, которым требуется разложение. Чужие benchmark здесь не используются как доказательство качества на нашем корпусе.
Проверим ошибочный ответ по условному входу:
Для А-10 нужен S-4, аккумулятор есть на складе и приедет завтра.
Бланк подтверждён только для плановой замены, наличие и срок не подтверждены вообще. Правильная первая часть не оправдывает две следующие догадки. В трассе нужно найти источник каждого утверждения, включая ограничения применимости.
Другая ошибка: «Аккумулятор незаменяемый». Это свойство Б-20 ошибочно перенесено на А-10. Здесь не поможет дополнительный поиск по складу: сначала нужно проверить идентификатор устройства в CATALOG. Разные режимы отказа требуют разных исправлений, поэтому полезно хранить фактический ответ и место обнаруженного расхождения.
Для приёмки используйте тот же полный вход. Проверьте заменяемость, бланк, оговорку о плановой процедуре и отсутствие выдуманного срока. Затем дайте новый вопрос, не использованный для настройки. Успех на ручном примере не доказывает обобщение на другие устройства.
Задержка, вызовы и бюджет
В основной ветке учебного плана два поиска: CATALOG и SERVICE. Это не означает два вызова LLM. Планировщик, генератор уточнений и синтез могут обращаться к модели отдельно. Число обращений зависит от реализации; в статье они не выполнялись и не измерялись.
Перед запуском составьте карту расходов: какие этапы вызывают модель, какие обращаются к поиску, какие допускают повтор и какие передают данные внешнему провайдеру. Для каждого этапа задайте предел и сохраните фактический результат. Ограничение числа шагов и денежный потолок — разные механизмы.
Простые вопросы можно направлять по фиксированному маршруту после проверки на своём наборе. Это решение контроллера; агент не должен самостоятельно получать дополнительные права ради поиска. В нашем примере все инструменты только читают. Запись заявки на ремонт, заказ детали и изменение карточки находятся за пределами разрешённого.
Практическая проверка бюджета: просуммируйте все вызовы в трассе, включая неуспешные и повторные. Отметьте, где использован кэш. Если добор не дал нового источника, сохраните это как результат шага; не скрывайте его из отчёта. Такой журнал помогает понять, приносит ли дополнительный цикл полезные свидетельства.
Архитектура и интерфейс конкретного продукта
Архитектура задаёт роли, переходы и условия остановки. API задаёт конкретные имена полей и методов. В NVIDIA агентный режим описан как конвейер LangGraph и включается настройками проекта. В AWS рассматривается отдельный путь agentic retrieval для Bedrock Knowledge Bases. Эти интерфейсы нельзя взаимозаменять по одному сходству назначения.
Для переноса нашего примера сначала реализуйте контракт инструментов: запрос на входе, документ с ID на выходе, отсутствие записей во внешнюю систему. Затем добавьте учёт общего лимита и проверку оснований. Только после этого выбирайте библиотеку и её конкретные вызовы по текущей документации.
Заполненная карта итогового ответа: «А-10 имеет заменяемый аккумулятор» опирается на CATALOG; «для плановой замены нужен S-4» — на SERVICE; «наличие и срок неизвестны» обозначает пробел данных. Это готовый ручной эталон. Он не утверждает, что проверка мастера уже состоялась или что гарантийная процедура совпадает с плановой.
Перед выпуском проверьте и объяснение остановки. Пользователь должен понимать, какая часть ответа подтверждена, какой факт отсутствует и какое уточнение нужно человеку. Формулировка «агент не справился» не заменяет эту карту и не помогает решить следующий шаг.
Частые вопросы
Чем Agentic RAG отличается от обычного RAG?
В сравнении с фиксированным маршрутом агентный вариант выбирает подвопросы, источники и повторный поиск по ходу выполнения. Это не означает, что все остальные реализации RAG ограничены единственным поиском.
Сколько поисковых шагов делает агент?
В нашем условном контроллере разрешены три поиска на запрос. Реальные параметры и значения по умолчанию зависят от выбранного продукта; их нужно сверять отдельно.
Что происходит, если данных не хватает?
В учебной ветке о поставке нужного факта нет. Контроллер останавливает поиск, возвращает подтверждённую часть и обозначает неизвестность; при необходимости вопрос передаётся человеку.
Нужно ли несколько агентов?
Не обязательно. Разные инструменты могут вызываться одним контроллером. Многоагентная схема LlamaIndex — один из документированных вариантов; её необходимость для конкретного корпуса нужно обосновать.
Повышает ли агентный режим точность автоматически?
Автоматического прироста не обещают. На своём наборе проверьте полноту оснований, неподдержанные утверждения, остановку и расход. В примере ручной эталон задан заранее; прогона модели не было.