Agentic RAG, Graph RAG и Advanced RAG: чем отличаются и как выбрать подход

Что такое RAG и почему одного подхода мало

Retrieval-Augmented Generation (RAG) — это архитектура, в которой языковая модель перед ответом обращается к внешней базе знаний. Вместо того чтобы полагаться только на обучающие данные, LLM получает актуальные фрагменты документов и формирует ответ на их основе. Это решает проблему устаревших знаний и галлюцинаций.

Но базовый RAG — не серебряная пуля. Простой векторный поиск справляется, когда вопрос чёткий, а ответ лежит в одном документе. Как только нужен синтез из нескольких источников, понимание связей между сущностями или логическая цепочка рассуждений, базовая схема начинает сбоить.

За последние два года сложились 14 различных типов RAG-архитектур, но на практике чаще всего используются четыре: Naive RAG, Advanced RAG, Graph RAG и Agentic RAG. Они отличаются по сложности, стоимости и кругу решаемых задач. Разберём каждый и определим, когда что выбирать.

Naive RAG: когда достаточно простого поиска

Naive RAG — самый простой вариант. Пользовательский запрос превращается в векторное встраивание, идёт поиск по векторной базе (Chroma, Qdrant, Milvus), находятся top-K похожих чанков, они подставляются в промпт LLM вместе с исходным вопросом. Модель генерирует ответ на основе найденных фрагментов.

Этот подход работает, когда вопросы однозначны, документы хорошо структурированы, а ответ находится в одном-двух чанках. Например: «Какой лимит по карте Gold в банке X?», «Какая температура плавления алюминия?», «Какие документы нужны для визы в Италию?» — всё это Naive RAG обрабатывает за доли секунды.

Ограничения проявляются сразу, как только задача усложняется:

Вопрос может быть сформулирован иначе, чем написано в документах — «сколько стоит обслуживание» вместо «тарифы на сопровождение счёта». Векторный поиск может не найти нужный чанк просто из-за разницы в лексике. Если вопрос требует информации из нескольких документов — «сравните условия ипотеки в банках А, Б и В» — Naive RAG найдёт фрагменты по каждому банку, но не сможет их сопоставить. Ответ будет компиляцией, а не анализом. Наконец, базовая схема не проверяет качество найденного — если в чанке нет ответа, модель может сгенерировать правдоподобную, но неверную информацию.

По данным репозитория RAG Techniques (28K+ звёзд на GitHub, 42+ техники), именно эти ограничения — неоднозначность запросов, разрозненные источники и отсутствие проверки — являются главными причинами перехода к более сложным архитектурам.

Advanced RAG: гибридный поиск и реранкинг

Advanced RAG — это не отдельный фреймворк, а надстройка над базовой схемой, которая добавляет дополнительные слои обработки на каждом этапе пайплайна.

Переформулировка запроса. Перед поиском LLM генерирует несколько вариантов одного и того же вопроса. Если пользователь спросил «сколько стоит аренда сервера», модель может сформулировать «цена dedicated-сервера в месяц», «тарифы на аренду оборудования» — и искать по всем вариантам параллельно. Это страхует от лексического несовпадения между запросом и документами.

Гибридный поиск. Векторный поиск находит семантически похожие чанки, но может пропустить точное совпадение термина. Keyword search (BM25, Elasticsearch) находит точные совпадения, но не понимает смысла. Гибрид комбинирует оба подхода: результаты ранжируются по взвешенной сумме семантической и лексической релевантности.

Реранкинг (reranking). После первичного поиска (top-20 или top-30 чанков) запускается более тяжёлая модель — cross-encoder вроде Cohere Rerank или BGE Reranker — которая заново оценивает релевантность каждого чанка к исходному запросу. Это существенно повышает точность: из top-20 отбираются 3–5 действительно релевантных. По данным Meilisearch, реранкинг может увеличивать точность ответов на 20–30% без изменения модели генерации.

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

Graph RAG: когда важны связи между сущностями

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

При индексации Graph RAG строит поверх документов граф знаний: люди, компании, продукты и события превращаются в узлы, а отношения между ними — в рёбра. Когда поступает запрос, система не перебирает похожие абзацы, а переходит от факта к факту, следуя логическим связям.

Пример. Вопрос «Как решение совета директоров в 2022 году повлияло на текущую продуктовую стратегию?» требует связать несколько документов цепочкой причинно-следственных связей. Векторный поиск найдёт фрагменты о совете директоров и о продуктовой стратегии, но не соединит их. Graph RAG при индексировании извлекает связи: «совет директоров → принял решение → сократить линейку продуктов → в 2022 году», «сокращение линейки → повлекло → пересмотр продуктовой стратегии → в 2023 году». Когда поступает запрос, система проходит по цепочке, собирая ответ из последовательных фактов.

Microsoft GraphRAG (открытый проект Microsoft) и Neo4j с векторными индексами — основные инструменты для этого подхода. Microsoft GraphRAG использует LLM для автономного извлечения сущностей и связей из документов, строит иерархический граф сообществ, а затем отвечает на вопросы, агрегируя информацию на разных уровнях графа. В тестах Microsoft, GraphRAG показал на 30–70% лучшие результаты на вопросах, требующих синтеза из нескольких источников, по сравнению с Naive RAG.

Когда выбирать Graph RAG: в данных много перекрёстных ссылок, вопросы требуют понимания иерархий и цепочек связей, а разрозненные факты нужно сводить в единую картину. Журналистские расследования, юридический анализ договоров, бизнес-аналитика — классические сценарии для Graph RAG.

Agentic RAG: агент с планом и инструментами

Agentic RAG — самый гибкий и самый сложный подход. Вместо того чтобы выполнять один предопределённый пайплайн поиск → генерация, система ведёт себя как опытный исследователь: планирует, выбирает инструменты, проверяет результаты и не останавливается, пока не найдёт удовлетворительный ответ.

По данным обзора Agentic RAG (arXiv, апрель 2026), авторы выделяют четыре ключевых паттерна, которые использует агент:

1. Reflection. Агент оценивает, достаточно ли найденной информации для ответа. Если нет — переформулирует запрос и ищет снова. Это решает проблему «пустых» ответов, когда Naive RAG нашёл чанк, но в нём не было нужных данных.

2. Planning. Агент разбивает сложный вопрос на подзадачи. Запрос «сравните SLA трёх облачных провайдеров и выберите лучший для нашей нагрузки» превращается в последовательность: собрать SLA каждого провайдера → найти требования к нагрузке → сопоставить → выдать рекомендацию.

3. Tool use. Агент решает, какой источник данных использовать для каждой подзадачи. Векторная база — для поиска по документации, веб-поиск — для актуальных новостей, SQL — для структурированных данных, граф — для связей между сущностями. Агент может обращаться к разным инструментам в рамках одного ответа.

4. Multi-agent collaboration. Несколько агентов работают параллельно: один ищет данные, другой проверяет факты, третий собирает финальный ответ. Это ускоряет обработку сложных запросов, но требует координации.

Благодаря этим паттернам Agentic RAG может повысить точность ответов на сложные вопросы в 3–7 раз по сравнению с Naive RAG (данные из обзора Agentic RAG Survey, основанные на тестах с LegalBench, MultiHopQA и HotPotQA).

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

Самые популярные инструменты для Agentic RAG: LangGraph (построение графа состояний агента), CrewAI (многоагентная оркестрация), AutoGen (multi-agent диалог), Phidata (агент с инструментами). На GitHub репозитории этих фреймворков набирают от 40K до 135K звёзд.

Сравнительная таблица: какой подход когда выбирать

Инструменты для каждого подхода

Для Naive RAG достаточно связки Chroma (28K+ звёзд, простой Python-клиент) или Qdrant (32K+ звёзд, Rust, высокая производительность) с LLamaIndex или LangChain. Это минимальный набор для прототипа, который закроет 70–80% простых вопросов.

Для Advanced RAG понадобятся те же векторные базы плюс инструменты реранкинга: Cohere Rerank API, BGE Reranker (HuggingFace), Cross-encoder от Sentence Transformers. Для гибридного поиска — Elasticsearch или Qdrant с поддержкой BM25 + векторный поиск.

Для Graph RAG основных варианта два: Microsoft GraphRAG (open-source, Python, автономное извлечение графа с помощью LLM) и Neo4j с плагином векторного поиска. Microsoft GraphRAG хорош для старта — он сам строит граф из документов, не требуя ручного моделирования схемы.

Для Agentic RAG фреймворки выбора: LangGraph (135K+ звёзд — гибкое построение графа состояний агента), CrewAI (60K+ звёзд — ролевая оркестрация агентов) и Phidata (30K+ звёзд — агент с инструментами на Python). Все три поддерживают Tool use и multi-agent collaboration. Репозиторий RAG Techniques (28K+ звёзд, 42+ ноутбука) содержит готовые реализации всех подходов на Python.

Как выбрать подход под свою задачу

Универсального ответа «какой RAG лучший» не существует — каждый подход решает свой круг задач. Вот алгоритм выбора:

Начните с Naive RAG всегда. Это быстрый прототип, который покажет, насколько ваша база знаний и типы вопросов вообще совместимы с RAG-архитектурой. Если 80% вопросов отвечаются корректно — вы можете остановиться на этом уровне.

Если точность не устраивает, подключайте гибридный поиск и реранкинг — получите Advanced RAG. Это самый дешёвый способ поднять качество без усложнения архитектуры. Для большинства корпоративных FAQ и базы знаний это оптимальный уровень.

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

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

Коротко

Naive RAG — быстрый прототип для простых вопросов. Advanced RAG — минимальный продакшен-уровень с гибридным поиском и реранкингом. Graph RAG — для задач, где важны связи между сущностями. Agentic RAG — многошаговый исследователь для сложных запросов. Все четыре подхода можно комбинировать в одной архитектуре: агент использует граф для поиска связей, гибрид для быстрого поиска, реранкинг для отбора лучших чанков.

Лучшая стратегия — начать с самого простого и добавлять сложность по мере роста требований к качеству. Инструменты выбора: Chroma или Qdrant для старта, LlamaIndex или LangChain для пайплайна, Microsoft GraphRAG для графов и LangGraph для агентов.

Что ещё важно знать