qvib.pro
EN

От RAG к агентному поиску (agentic RAG)

Для чего: понять сдвиг от «один запрос → один ответ» к агенту, который сам планирует, уточняет и многократно ищет.

Survey on Agentic RAG, arXiv 2501.09136 (январь 2025) — оформление подхода как отдельного направления проверено 2026-06-01

Что это

Agentic RAG — эволюция классического Retrieval-Augmented Generation. Вместо «один поисковый проход → подставили в промт → ответ» агент планирует шаги, переписывает запросы, вызывает инструменты, обращается к памяти и итеративно уточняет результат, оценивая собственный вывод. Поиск становится многошаговым и самокорректирующимся.

Откуда пошло

  • 2023–24 — классический RAG стал стандартом «привязать LLM к своим данным».
  • Январь 2025 — выходит обзорная статья «Agentic RAG: A Survey» (arXiv 2501.09136), которая оформляет подход в отдельное направление.
  • 2025 — вендоры (Redis, RAGFlow, фреймворки агентов) переносят логику с «пайплайнов» на «агентов».

Почему взлетело

  • Статичный RAG плохо тянет сложные многошаговые вопросы — нужна адаптивность.
  • Самооценка и повторный поиск снижают галлюцинации: по ряду замеров ошибки падают с ~20%+ до <10%.
  • Совпало с общим разворотом индустрии к агентам: «поиск» естественно стал одной из способностей агента.

Как применить сейчас

  1. Если у тебя уже есть RAG — добавь шаг «агент переформулирует запрос, если результат слабый».
  2. Дай агенту несколько источников/инструментов и право выбирать, куда идти за ответом.
  3. Встрой проверку: агент оценивает свой ответ и при сомнении ищет ещё раз.

На что обратить внимание

  • Многошаговость дороже и медленнее одношагового RAG — не везде оправдана.
  • Больше шагов = больше мест для ошибки; нужны лимиты на итерации.
  • Качество всё равно упирается в качество источников: мусор на входе — мусор на выходе.