Агентный RAG против модульного: что реально лучше на практике

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

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

Вторая — «агентный» (Agentic) RAG: вместо заранее заданных модулей мы даём LLM роль агента. Она сама решает, искать ли документы, стоит ли переписать запрос, нужно ли повторить поиск, достаточно ли контекста. Звучит красиво: меньше жёстких правил, больше гибкости «по ситуации». Но действительно ли это лучше, и главное — в каких условиях?

Авторы статьи как раз берутся за неприятный вопрос: «что реально работает» — и делают масштабное экспериментальное сравнение Enhanced и Agentic RAG. Причём на разных типах задач: финансовые вопросы (FIQA), фактчекинг (FEVER), поиск похожих обсуждений (CQADupStack-English) и открытые вопросы общего характера (NQ). Они раскладывают RAG на несколько «узких мест» и проверяют, кто и где выигрывает.

Где RAG должен уметь говорить «поиск не нужен»

Первый тест — умение отличать запросы, где внешние знания действительно нужны, от запросов «вне области знаний» или таких, где лучше отвечать без поиска. В Enhanced RAG это делает отдельный семантический роутер на эмбеддингах: сравнивает запрос с примерами «валидных» и «невалидных» запросов и решает, запускать ли retrieval. В Agentic RAG решение принимает сама LLM в процессе рассуждения.

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

Переписать запрос — но не всегда одинаково

Вторая проверка — query rewriting. Здесь документы в базе часто длинные и «канцелярские», а пользовательский запрос короткий и разговорный. Переписывание помогает ретриверу «свести форматы». В Enhanced RAG rewriting делается принудительно одним методом (HyDE-подход: LLM пишет абзац, как будто это ответ, и по нему идёт поиск). В Agentic RAG rewriting — опциональный шаг: агент может переписывать запрос по ситуации и под тип документов.

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

Третий момент — улучшение списка документов после первичного retrieval. Enhanced RAG добавляет классический cross-encoder переранкер и из большого пула кандидатов выбирает лучшее. Agentic RAG теоретически может добиться похожего, делая дополнительные итерации поиска с новыми формулировками. Но в эксперименте это не сработало: повторные заходы агента не приводят к качественно лучшим документам, а иногда даже ухудшают картину.

Итак, если проблема в том, что «в топе выдачи много мусора», то переранкер часто даёт более прямое и надёжное решение, чем попытка уговорить LLM переформулировать запрос ещё пятью способами.

Зависимость от базовой LLM и неприятная цена гибкости

Авторы отдельно проверяют, меняется ли баланс Enhanced vs Agentic при разных базовых моделях Qwen3 (0.6B, 4B, 8B, 32B). Тренд ожидаемый: чем лучше LLM, тем лучше итоговый ответ. Но важная деталь: кривые роста у Enhanced и Agentic похожи — агентный подход не получает «магического бонуса» от того, что модель стала сильнее.

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

Что из этого стоит вынести, если вы строите RAG в продукте

Эта работа не «хоронит» Agentic RAG и не объявляет Enhanced единственно правильным. Она делает более полезное: показывает, где агентность действительно помогает (гибкое переписывание, узкие домены), а где модульность выигрывает устойчивостью (роутинг в сложных запросах, надёжный reranking). И отдельно напоминает про цену: агентный контроль почти неизбежно означает больше токенов и времени, а значит — более дорогой ответ.

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