RAG в эпоху агентного ИИ: существует ли Agentic RAG? Существует ли вообще ещё RAG?

Источник первой публикации

Это моя четвёртая большая статья про RAG. Если вы читали предыдущие, вы помните, что мы обсуждали базовое устройство технологии и попытки преодоления её недостатков в юридическом домене путём усложнения архитектур (раз, два). До относительно недавнего времени RAG оставался самостоятельной технологией — системой, которую проектируют, настраивают и оценивают как целое. Но с массовым распространением агентного ИИ RAG теперь — часть более широкого скилл-сета управления контекстом (с нашей, пользовательской, точки зрения) и одна из компетенций автономных агентов с точки зрения технологий.

В разных публикациях и новостях можно увидеть термин «agentic RAG», которым описывают этот сдвиг. Термин удобный и модный, но по сути не очень точный. Сам RAG не стал агентным, но он стал компетенцией агента. И в этой статье я предлагаю обсудить, что это значит в теории и уже в недалёкой практике. 

Что было и что стало: от глупенького конвейера к «сначала думаем, потом ретривим»

Прямолинейность как свойство архитектуры

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

В предыдущих статьях я подробно разбирала, как этот пайплайн можно усложнять: иерархический RAG добавил многоуровневую индексацию, GraphRAG связал сущности, SAT-Graph научился учитывать исторический контекст. Но что важно — какую бы сложную RAG-архитектуру мы ни придумали, она будет снова гнать велосипед каждый раз, когда пользователь напишет запрос. Можно бесконечно усложнять базу знаний, индексацию, навешивать реранкинг — но сам процесс «вопрос → поиск → ответ» в этой парадигме остаётся однонаправленным. У такой системы нет возможности сказать «мне не нужен поиск по этому вопросу» и очень мало возможностей оценить релевантность найденных чанков. Не зря мы используем термин «RAG-пайплайн» — это буквально конвейер, линейный и однонаправленный.

Что меняется: RAG как инструмент агента-исследователя

Что собой представляет юридический ресерч? Профессиональный юрист вряд ли вбивает один запрос в поисковую систему и пишет меморандум на основе первых десяти результатов. Он думает: нужно ли мне вообще искать, или я уже знаю ответ, сейчас рас-рас и набросаю клиенту емейл? Если всё же искать — где именно? Достаточно освежить пару статей в кодексе, или нужно садиться рыть судебную практику, задумчиво листать Глоссу? Собрав какой-то пул материалов, юрист оценивает их релевантность своей фактуре, возможно, отправляется на поиски дальше, но уже с переформулированной задачей. В какой-то момент понятно, что можно уже писать мемо или ответ клиенту.

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

Что конкретно делает агент?

• Решает, нужен ли поиск вообще. Не каждый вопрос требует обращения к внешней базе. Если ответ уже содержится в контексте диалога или в «знаниях» самой модели, поиск — лишний шаг, который увеличивает стоимость и время ответа, а иногда добавляет и ненужный шум. Это первая точка принятия решений в «стеке решений» (Decision Stack) агента. В классическом RAG этого вопроса просто не существовало — поиск происходил всегда.
• Составляет оптимальный поисковый запрос. Вместо того чтобы отправить пользовательский вопрос «как есть» на векторизацию, агент может переформулировать его, разбить на подзапросы, уточнить терминологию. Может выбрать между поиском по ключевым словам (когда нужно найти конкретный термин и конкретную статью закона) и семантическим (когда важен смысл, а не точное совпадение слов).
• Выбирает правильную базу знаний. Если доступно несколько источников (база договоров, нормативных актов, мечта цивилиста — векторизованная Глосса, судебная практика, открытый Интернет), то агент маршрутизирует запрос (или часть оптимизированного запроса) к наиболее подходящему. Это может делать один агент-«маршрутизатор» или целая команда специализированных агентов, каждый со своим источником.
• Оценивает найденное на релевантность. Извлечённые чанки — не финальная точка, а материал для критической оценки. Достаточно ли информации? Отвечает ли она на вопрос? Нет ли противоречий? Авторы этого исследования (пока назовём его SoK, а дальше упомянем подробнее) описывают это как паттерн Retrieve-Reflect-Refine: поиск → рефлексия → уточнение. Классический RAG, даже с реранкером, этого этапа лишён — модель обязана работать с тем, что нашлось.
• Повторяет поиск, если нужно. Если первая итерация не дала результата — переформулирует запрос, пробует другой инструмент, обращается к другому источнику. Вместо одноразовой операции получаем итеративный процесс.
• Решает, когда пора остановиться. Нужно определить, что собрано достаточно информации для качественного ответа, и не уходить в бесконечный цикл уточнений. Но это нетривиальная задача, и с этим пока не всё гладко — но об этом в части про риски.

Важно здесь зафиксировать кое-что терминологическое. Всё, что описано выше — это базовые свойства и навыки агента, а не RAG-технологии. Сам RAG остаётся тем же самым поиском по базе знаний с передачей результатов модели. Меняется не RAG, а то, кто и как его использует. Поэтому термин «агентный RAG», хоть и мелькает в публикациях, концептуально неточен. RAG стал компетенцией — исследовательским инструментом внутри агентской системы, наряду с генерацией кода, вычислениями, вызовами API и обращением к человеку. Субъект здесь — агент, который активно исследует, а не пассивно потребляет пре-индексированные результаты.

Очень круто, а есть ли уже что-то подобное на практике?

Описанная выше рамка уже не просто теория, появились первые наработки. A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces — одна из первых работ, опубликованных в начале февраля 2026 года, которая предложила конкретную архитектуру и замерила результаты.

Архитектура: что было сделано

Идея A-RAG проста и элегантна. Исследователи дали языковой модели три инструмента:

• keyword_search — поиск по ключевым словам
• semantic_search — поиск по смыслу на естественном языке
• chunk_read — полное чтение выбранного фрагмента. Когда предварительный поиск показал перспективный документ, но нужно прочитать его целиком для понимания контекста.

Цикл работы построен по фреймворку ReAct (Reasoning + Acting): модель смотрит на всё, что уже знает, решает вызвать один из инструментов, видит результаты, решает, что дальше — вызвать другой инструмент, прочитать найденный чанк целиком или дать финальный ответ. Система запоминает, что уже прочитала, и не перечитывает одно и то же. При этом «правильный» (и какой-либо вообще) порядок действий не программировался: модель может сама выбирать стратегию в зависимости от вопроса.

Результаты

Исследователи протестировали A-RAG на пяти бенчмарках по разным темам и сравнили с существующими подходами — включая и знакомый нам GraphRAG.

На модели GPT-5-mini полный A-RAG (с тремя инструментами) показал 74,1% точности на бенчмарке MuSiQue, проверяющем способность к многошаговому рассуждению. Для сравнения: наивный RAG — 52,8%, GraphRAG — 48,3%, лучший из конкурентов LinearRAG — 62,4%. На других бенчмарках разрывы ещё заметнее вплоть до 89,7% у A-RAG против 50,2% у наивного RAG.

Особенно интересны следующие наблюдения:

• Даже упрощённая версия A-RAG (один инструмент — только семантический поиск, но с правом агента решать, когда его вызывать) показала 66,2% на MuSiQue — лучше, чем все существующие сложные методы, включая Graph RAG и LinearRAG. Иными словами, сам факт того, что модель имеет выбор — искать или нет, когда остановиться, — важнее, чем сложность поискового пайплайна.
• A-RAG использует меньше контекста. Полная версия A-RAG тратила ~2700–7600 токенов на вопрос в зависимости от датасета. Наивный RAG — ~5000–5500 токенов. Агентная система точнее выбирает, что читать, и не заваливает модель нерелевантным шумом. Это контринтуитивно (я вот была убеждена, что агенты априори дороже): кажется, что итеративный процесс должен быть «тяжелее» — но на практике целенаправленный поиск экономичнее.
• Исследователи по очереди убирали каждый инструмент, и увидели, что все три необходимы, но вносят разный вклад. Удаление семантического поиска принесло наибольший урон качеству, снизив точность на 4–5 процентных пунктов. Удаление поиска по ключевым словам — на 1,5–2 п.п. Полного чтения чанков — на 0,5–2 п.п. Каждый инструмент закрывает свой тип задач, и агент учится выбирать правильный.

Всё ли так радужно?

Исследователи проанализировали по 100 ошибок наивного RAG и A-RAG и увидели самое интересное!

У наивного RAG основная проблема — это поиск: 36% ошибок на MuSiQue связаны с тем, что система не смогла найти нужную информацию, ещё 15% — с тем, что нужный документ не попал в топ результатов, которыми аугментируется запрос в LLM. То есть больше половины ошибок — это проблема в поиске.

У A-RAG картина перевёрнута. 82% ошибок на MuSiQue — это ошибки рассуждений (reasoning chain errors). Система нашла нужные документы, но неправильно с ними работала. Только 3% ошибок — «не получилось найти информацию».

В этих 82% ошибок рассуждений структура такая:

• 40% — путаница сущностей (entity confusion: модель путает похожие имена, даты, номера)
• 28% — неправильная стратегия поиска (модель искала не то или не там)
• 22% — неправильное понимание вопроса
• 10% — превышение бюджета шагов (модель не успела дойти до ответа).

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

Риски и ограничения агентского подхода

То, что написано в этом разделе, поможет нам перестать закапывать классический RAG (и избавит меня от необходимости придумывать новое название моему каналу). Но, кроме шуток, это важно, особенно в юридическом домене.

Галлюцинации, усиленные агентным циклом

Я уже упоминала исследование SoK, SoK: Agentic Retrieval-Augmented Generation (RAG): Taxonomy, Architectures, Evaluation, and Research Directions. Вообще SoK (Systematization of Knowledge) — это формат академических публикаций, в котором авторы не предлагают новое решение, а систематизируют и структурируют уже существующие знания по теме, выстраивая из разрозненных исследований единую картину с таксономией, классификацией и выявлением пробелов. Соответственно, эта команда собрала всё, что на текущий момент можно собрать об «агентном» RAG.

Авторы ссылаются на публикацию, в которой утверждается, что юридические RAG-системы галлюцинируют в 33% случаев. Сам факт того, что модель имеет доступ к базе знаний, не защищает от галлюцинаций (что в целом не новость, но всегда интересно, если кто-то эмпирически посчитал). Причины смутно могут напомнить вам все те недостатки и слабые стороны наивных RAGов, описанные в моих других статьях.

В агентных системах проблема галлюцинаций может усугубляться. Возникает то, что авторы SoK называют Compounded Hallucination Loops (самоусиляющиеся петли галлюцинаций).

Вот пример в юридическом контексте, который мне придумал Claude:

Представьте: на шаге 1 модель генерирует утверждение «В 2020 году закон X был существенно изменён» — и это галлюцинация. На шаге 2 она использует это утверждение как основу для поиска: «изменения закона X в 2020 году». Поиск находит документы, которые упоминают и «закон X», и «2020» — но совсем в другом контексте. На шаге 3 модель интерпретирует найденное как подтверждение: «я нашла доказательство того, что закон был изменён». Галлюцинация не просто сохранилась — она усилилась, обросла «доказательствами» и стала выглядеть убедительнее.

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

Для нас, юристов, это довольно-таки критично, так как в наших текстах все детали имеют значение, особенно такие мелкие и имманентно подверженные галлюцинациям, как номера статей, тонко различающиеся термины и семантически близкие формулировки с нюансами. Эти детали будто созданы для того самого entity confusion, на который приходится значительная доля ошибок рассуждений в A-RAG.

Дрейф поиска и каскадирование ошибок

Ещё один специфический риск итеративных агентских систем — дрейф поиска (retrieval drift), возникающий при переформулировании запроса. То, что в целом кажется благом — ведь векторизуется не ерунда от пользователя, а что-то более осмысленное — в результате самоуправства агента может привести к значительному отклонению от исходного вопроса.

Смежная проблема — каскадирование ошибок: ошибка на шаге 1 порождает неправильные данные на шаге 2, которые становятся основой для ошибочного анализа на шаге 3. В отличие от однопроходного RAG, где ошибка локализована, в итеративной системе ошибки нарастают экспоненциально.

Больше возможностей для промпт-инъекций

Авторы упоминают об этом риске, хотя он мне кажется не самым существенным для российского legaltech-ландшафта сегодня и в обозримом будущем. Но всё же коротко, авторы пишут о том, что в классическом RAG злоумышленник может атаковать систему один раз — через документы, попавшие в ретрив. В агентном RAG каждый поиск — это новая возможность для атаки. Система проводит пять поисков — пять возможностей для промпт-инъекции.

Для кастомных и DIY баз с запретом агенту ходить в Интернет такого риска нет. А некастомных у нас пока и нет, в общем-то. Но всё же полезно держать в голове, что нужно соблюдать гигиену, формируя пул документов для векторизации.

Экономика

Каждый шаг агентного цикла — это дополнительные API-вызовы, а значит — деньги. В классическом RAG векторизация базы + одна векторизация запроса + одна генерация = предсказуемый по стоимости и времени результат. Агент, который будет делать несколько раундов рассуждения и поисков, заходить в возможные тупики и пытаться выходить из них, копит непредсказуемую задержку (latency stacking), причем задержка образуется на каждом шагу. Кроме того, агент может впасть в состояние битья головой об стену или retrieval thrash: агент ищет снова и снова, не может остановиться, и при этом каждая новая итерация не улучшает результат.

Получается, иногда достаточно и классического RAG?

Конечно же, да! Как раньше мы говорили о том, что не каждая задача требует LLM, так теперь мы будем часто говорить о том, что не каждая задача требует агентной архитектуры (и это не только про RAG...).

Классический RAG достаточен, когда задача предполагает один «заход» в одну базу с предсказуемым типом ответа: поиск по конкретному пулу однородных НПА или практики, FAQ-бот по внутренним регламентам компании. Здесь прямолинейность становится преимуществом: предсказуемая стоимость и время ответа, меньше узлов, на которых что-то может пойти не так (ведь базовые технологические ограничения LLM никуда не делись с агентской архитектурой).

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

Критерий, в общем, интуитивно понятен:

Выдыхаем и делаем RAG. Но ещё и управляем контекстом

Хоронить ретрив рано

Хотя то и дело его хоронят, подтягивая самые разные аргументы. Например, контекстные окна моделей растут (на днях и Claude заявил об одном миллионе токенов, у Google AI Studio уже давно столько). Зачем тогда вообще нужен поиск, если всё можно залить в контекст? А агенты, агентный поиск-то каков?

Но для юридической работы всё же критичен RAG с точки зрения гарантии того, что у вас будет верифицируемый источник. Пока что RAG — единственная технология, которая обеспечивает связь между ответом и источником. Авторы SoK называют это свойство RAG-систем Retrieval-Grounded Self-Verification, то есть система привязывает каждое утверждение к конкретному фрагменту из базы знаний, а не достаёт из параметрической памяти или дальних закоулков Интернета.

В том, что касается роста контекстного окна, здесь предлагают хорошую аналогию. Для какой-то консультации вы можете спросить одного эксперта-фрилансера — это стоит, условно, $75. А можете пойти в консалтинг, где вам соберут команду, час работы которой будет стоить $750. Большой контекст — это «пригласить миллион токенов», когда ответ содержится в нескольких тысячах. К тому же вы замучаетесь каждый раз всё лить в контекст. А кроме этого, для реально полезной юристу базы знаний, требуемой регулярно, миллиона токенов будет мало. В том числе потому, что пока никуда не деваются фундаментальные свойства архитектуры внимания (attention dilution at scale): модель может проигнорировать критически важную информацию, если она не в начале и не в конце контекста.

И в связи с этим ещё пара слов об управлении контекстом

Отрицать, что агенты меняют правила игры, уже нет смысла. Мои личные торги на эту тему уже кончились, кончились хихоньки-хахоньки! И в связи с этим, а также всем вышеперечисленным, ещё раз приподниму мысль о том, что у RAG-технологии значительным образом меняется роль. Просто делать RAG уже совсем скоро будет делать маловато, делать нужно будет богатый контекст (и учиться им управлять на каждом повороте на пути ваших агентов).

Напомню, что под управлением контекстом (context engineering, хотя мне больше нравится нетехнический context management) — это зонтичный термин для всего, что связано с подготовкой и управлением информацией, которую получает LLM. Из 2026 года под этим понимается и промпт-инжиниринг, и написание и администрирование скиллов, подбор MCP-инструментов, управление памятью агентов. И RAG — тоже часть этой, в общем-то, дисциплины.

В отношениях с агентами нужно проектировать системы с учётом ошибок, которые агенты потенциально могут совершать (о части из которых мы говорили выше). Нужно будет:

• придумывать, как защищаться от дрейфа поиска, например, ограничивая число итераций и правила переформулирования запросов;
• подбирать под каждый процесс стоп-условия: когда останавливаться, чтобы не уходить в бесконечный цикл;
• управлять памятью агента, что ощущается как очень горячая тема, в которую лично мне хочется попытаться погрузиться;
• настраивать алгоритмы эскалации к человеку при неуверенности агента.

А ещё (такого я пока не видела в публикациях, но вижу перспективу) можно придумывать процессы, в которых агент настраивался бы на отслеживание обновлений нормативного материала в базах знаний. Это боль для всех сервисов, заявляющих наличие юридического RAG: базы очень быстро устаревают, в базах гниют правоприменительные акты, содержащие старое законодательство, загрязняющие ретрив. Агент, который не просто ищет, но и проверяет свежесть источников, мог бы закрыть эту проблему — хотя до промышленных реализаций пока далеко.

Итого!

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