RAG за пределами чанков: graph RAG, agentic RAG, long-context RAG

Если вы построили классический RAG, вы знаете его сильные стороны: он извлекает релевантные чанки, LLM генерирует обоснованные ответы, производительность разумная, стоимость предсказуема. Для большинства запросов к базе знаний этого достаточно.

Но некоторые запросы ломают классический RAG. Многошаговые вопросы («Кто из наших клиентов пользуется функцией X и ушёл за последние 6 месяцев?»). Вопросы с обилием связей («Как наше ценообразование выглядит на фоне конкурентов A, B и C?»). Вопросы на синтез («Резюмируй всё, что мы знаем о пути этого клиента»). Классическое извлечение по чанкам плохо соединяет чанки между собой; в итоге LLM упускает контекст, разбросанный по многим местам.

Подходы «за пределами чанков» — graph RAG, agentic RAG, long-context RAG — атакуют эти пределы каждый по-своему. Эта статья — о том, что представляет собой каждый из них, когда каждый оказывается правильным инструментом, как они реально работают в продакшене и какие компромиссы имеют значение.

Пределы чанкового RAG

Чтобы понять, что именно мы чиним, — вот эти пределы:

Предел 1: нет структуры связей. Чанки — независимые единицы. Тот факт, что чанк A относится к аккаунту клиента X, а чанк B — к жалобе того же клиента X, теряется: это просто два чанка в векторном пространстве, извлекаемые (или нет) независимо друг от друга.

Предел 2: нет многопереходности. «Клиенты, которые используют функцию X и пожаловались на Y» требует объединить информацию из двух разных источников с помощью логики множеств. Извлечение по чанкам этого не делает.

Предел 3: ограниченный синтез. «Резюмируй отношения с этим аккаунтом за всё время» требует собрать множество чанков в связное повествование. Чанки подаются как фрагменты; LLM каждый раз выполняет синтез с нуля.

Предел 4: жёсткость фиксированного пайплайна. Классический RAG всегда делает одно и то же: строит эмбеддинг запроса → извлекает K → генерирует. Сложные запросы, которым нужно итеративное извлечение или многошаговое рассуждение, в этот пайплайн не вписываются.

Предел 5: разбавление контекста. В топ-5 чанков могут попасть такие, что формально совпадают с запросом, но не по теме. LLM вынуждена продираться сквозь них; качество страдает.

Варианты, которые мы обсудим, закрывают разные подмножества этих пределов.

Graph RAG

Идея: представить ваши данные как граф знаний. Сущности (люди, продукты, документы, события) — это узлы; связи — рёбра. Запросы обходят граф, а не (или в дополнение к этому) выполняют векторный поиск.

Когда graph RAG помогает

Домены, насыщенные связями. Структуры вида «клиент — аккаунт — сделка — взаимодействие». Организационные иерархии. Таксономии продуктов. Сети цитирования. Всё, где связи между сущностями значат не меньше самих сущностей.

Многошаговые рассуждения. «Кто менеджер команды, купившей продукт X в Q3?» требует переходов: продукт → сделка → команда → менеджер. Graph RAG обрабатывает это естественно.

Агрегация. «Сколько клиентов в сегменте Y интегрировались с системой Z?» требует операций над множествами сущностей. SQL по графу знаний обыгрывает текстовое извлечение.

Цитирование и объяснения. Связи в графе явные и поддаются проверке. LLM может сослаться: «John — менеджер команды Acme [ребро: manages]» — вместо «Кажется, John управляет командой Acme, судя по контексту».

Как graph RAG реально работает

Типичный пайплайн:

1. Извлечение. Строим граф из данных. Два распространённых подхода:

• Структурированные источники (БД, структурированные API): импортируем напрямую. Клиенты, продукты, транзакции уже лежат в таблицах.
• Неструктурированные источники (документы, расшифровки, письма): используем LLM, чтобы извлечь сущности и связи. «Из этой расшифровки извлеки людей, организации и связи между ними».

На выходе — узлы (с типами и свойствами) и рёбра (с типами и свойствами).

2. Хранение. Графовая БД — Neo4j, Memgraph, собственный Postgres с таблицами рёбер. Выбор зависит от паттернов запросов и масштаба.

3. Дополнение эмбеддингами. Каждый узел получает также текстовое представление и эмбеддинг. Это даёт гибрид: обходим граф И выполняем семантический поиск.

4. Запрос на этапе извлечения. Три распространённых паттерна:

• Только графовый запрос. LLM (или логика маршрутизации) генерирует графовый запрос (Cypher, SQL). Исполняем. Возвращаем результаты в LLM.
• Сначала эмбеддинг, потом расширение по графу. Находим релевантные сущности по эмбеддингу. Затем расширяемся до их соседей и связанных сущностей.
• Гибрид. Комбинируем векторный поиск и обход графа в одном пайплайне.

5. Форматирование для LLM. Результаты графа оформляются как структурированный текст, который LLM может использовать. Сущности со своими свойствами; связи заданы явно.

Конкретный пример

SaaS-компания с данными о клиентах. Сущности: клиенты, контракты, продукты, тикеты поддержки, взаимодействия, сотрудники.

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

Подход graph RAG:

• Узлы: customer, contract, product, ticket, interaction, employee.
• Рёбра: customer→has→contract, customer→subscribed_to→product, customer→submitted→ticket, ticket→assigned_to→employee, contract→sold_by→employee.

Запрос: «У каких клиентов на тарифе SaaS было более 3 тикетов поддержки в Q1 и предстоит продление в Q2?»

Это естественным образом графовый запрос:

MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
  AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count

LLM генерирует этот запрос (или выбирает из шаблонных запросов). Исполняем. Форматируем результаты. Генерируем ответ.

Классический RAG не может ответить на это легко. Graph RAG делает это чисто.

Компромиссы

Плюсы:

• Естественно справляется с реляционными запросами.
• Явная, проверяемая структура.
• Сочетается с эмбеддингами.

Минусы:

• Построение графа — это реальная инженерная работа. Особенно для неструктурированных источников извлечение получается неидеальным.
• Схема важна; плохая схема связывает вам руки.
• Поддержка: данные меняются — граф меняется вместе с ними.
• Инструменты менее зрелые, чем у векторного поиска.

Когда выбирать:

Выбирайте graph RAG, когда связи первичны в вашем домене. Не выбирайте его только потому, что это звучит солидно; для многих документо-ориентированных доменов классический RAG проще и не хуже.

Microsoft Graph RAG и смежные работы

Проект Microsoft с открытым исходным кодом GraphRAG (2024) популяризировал конкретный подход:

1. Извлечь сущности и связи из документов (на базе LLM).
2. Кластеризовать сущности в сообщества.
3. Сгенерировать резюме по каждому сообществу на нескольких иерархических уровнях.
4. На запрос: извлечь релевантные резюме сообществ; использовать их как контекст.

Хорошо работает для «глобальных» вопросов, охватывающих весь корпус (например, «каковы основные темы в истории жалоб этого клиента?»), а не для точечных поисков.

Среди вариантов — LightRAG, Graphiti и другие; у каждого свои архитектурные решения.

Agentic RAG

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

Когда agentic RAG помогает

Сложные запросы, требующие итераций. «Помоги разобраться, почему в Q1 у нас вырос отток» требует посмотреть под разными углами (какой сегмент, какой период, какие функции, какие конкуренты). Агент может исследовать итеративно.

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

Запросы с условной логикой. «Если по первому извлечению X истинно — ищи Y, иначе ищи Z». Агенты обрабатывают ветвления; фиксированные пайплайны — нет.

Неоднозначные запросы. Агент может запросить уточнение у пользователя (или у данных).

Как agentic RAG работает

Пайплайн:

User query
    ↓
Агент рассуждает о том, что ему нужно
    ↓
Агент вызывает инструменты извлечения (один или несколько)
    ↓
Агент читает результаты
    ↓
Агент решает: достаточно информации? Или нужно ещё одно извлечение?
    ↓
Цикл до завершения
    ↓
Сгенерировать финальный ответ

Реализация включает:

Извлечение как инструменты. Открываем агенту функции извлечения: search_documents(query), lookup_by_id(id), aggregate(field, filter). Агент вызывает их по мере необходимости.

Память. Агент помнит между вызовами, что уже извлёк. Не запрашивает повторно тот же контент.

Принятие решений. Агент явно рассуждает, достаточно ли у него информации. «Знаю ли я ответ на вопрос пользователя? Если нет — что ещё нужно извлечь?»

Завершение. Агент должен понимать, когда остановиться. Лимит на число шагов. Порог уверенности. Условие «я ответил».

Конкретный пример

Запрос: «Каковы три главных беспокойства клиентов в Q1, с примерами?»

Классический подход RAG: извлечь несколько чанков клиентских отзывов и надеяться, что они покрывают тему.

Подход agentic RAG:

Agent: Мне нужно найти беспокойства клиентов за Q1. Начну с поиска жалоб клиентов за этот период.
> Tool: search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})

Agent: Получил 25 результатов. Посмотрю, какие темы они покрывают.
> [reads results]

Agent: Вижу три главные темы: цены, медленная поддержка и отсутствующие интеграции. Соберу конкретные примеры по каждой.
> Tool: search_documents(query="customer pricing complaints", filter={...})
> Tool: search_documents(query="customer support speed complaints", filter={...})
> Tool: search_documents(query="customer integration missing complaints", filter={...})

Agent: Теперь у меня 3–5 конкретных примеров на тему. Соберу ответ.

Несколько извлечений, итеративно уточняемых. Агент выстраивает структуру на основе того, что находит.

Компромиссы

Плюсы:

• Справляется со сложными многошаговыми запросами.
• Подстраивается под сложность запроса (простые запросы не запускают долгие прогоны агента).
• Может уточнить неоднозначность, задав вопрос.

Минусы:

• Выше задержка (несколько извлечений).
• Выше стоимость (несколько вызовов LLM).
• Важна надёжность агента; плохие агенты зацикливаются или сдаются.
• Сложнее оценивать (более разнообразные пути исполнения).
• Сложнее контролировать (агент может повести себя неожиданно).

Когда выбирать:

Выбирайте agentic RAG, когда сложность запросов сильно разнится. Простые запросы могут идти по быстрому пути; сложные получают агентную обработку. Для равномерно простых запросов накладные расходы не оправданы.

Паттерны внутри agentic RAG

Несколько распространённых паттернов:

Паттерн 1: ReAct (Reason + Act). Агент явно рассуждает, затем действует (извлекает), затем наблюдает, затем снова рассуждает. Цикл — до готовности.

Паттерн 2: планирование и исполнение. Агент сначала строит многошаговый план (что и в каком порядке извлекать), затем исполняет его, при необходимости корректируя.

Паттерн 3: самокритика. После извлечения агент оценивает, достаточно ли добытой информации. Если нет — уточняет запрос и извлекает снова.

Паттерн 4: агент с множеством инструментов. У агента много инструментов извлечения (полнотекстовый поиск, SQL-запрос, графовый запрос, вызовы API), и он выбирает между ними.

Разные паттерны подходят под разные сценарии. Вариант с множеством инструментов хорош для разнородных источников; ReAct — для исследовательских запросов; планирование и исполнение — когда структуру сложного запроса можно спланировать заранее.

Long-context RAG

Идея: при контекстных окнах в 1M+ токенов (Gemini, GPT-5) — зачем вообще извлекать чанки? Просто положить весь корпус в контекст.

Когда long-context RAG помогает

Небольшие корпусы. Корпус в 100K токенов легко помещается в окно на 1M токенов. Инфраструктура извлечения не нужна.

Понимание документа целиком. «Резюмируй весь этот 500-страничный документ». Модель с длинным контекстом делает это напрямую.

Междокументные запросы по небольшим наборам. «Сравни эти 10 контрактов». Проще положить их все в контекст, чем аккуратно извлекать.

Прототипирование. Длинный контекст — простейший путь к работающей системе. Соберите прототип на длинном контексте; при необходимости оптимизируете извлечением позже.

Как long-context RAG работает

Пайплайн тривиален:

[corpus, возможно 100K–1M токенов]
    ↓
+ [запрос пользователя]
    ↓
Вызов LLM
    ↓
[ответ]

Никакого векторного хранилища. Никакой нарезки на чанки. Никакого переранжирования.

На практике вы всё же можете выполнять лёгкое извлечение, чтобы уместить корпус в контекст (например, для корпуса в 5M токенов извлечь подмножество в 500K токенов). Но извлечение здесь грубое — тонкую работу «найти релевантные части» делает LLM.

Проблема «context rot»

Реальность 2025–2026 годов: модели с длинным контекстом на самом деле плохо используют длинные контексты.

Эмпирически:

• Качество максимально примерно при 5–50K токенов контекста (стоящий за этим паттерн позиционного внимания задокументирован в работе Liu et al. «Lost in the Middle» и последующих оценках длинного контекста).
• При 100K+ токенов качество заметно падает.
• При 500K+ токенов важная информация часто теряется или применяется неправильно.

Технически модели могут обрабатывать длинные контексты, но бенчмарки «иголка в стоге сена» переоценивают их возможности. На реальных задачах длинный контекст проседает.

Это значит, что long-context RAG надёжно работает для корпусов примерно до 50K токенов. Дальше — деградация по сравнению с хорошим извлечением.

Компромиссы

Плюсы:

• Простейшая из возможных архитектур.
• Нет пайплайна извлечения, который нужно поддерживать.
• Лучший вариант для задач понимания корпуса целиком.

Минусы:

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

Когда выбирать:

Небольшие корпусы (до 50K токенов). Разовые анализы. Прототипы. НЕ универсальное извлечение для больших баз знаний.

Гибрид: извлечение + длинный контекст

Распространённый паттерн: извлечь контекст побольше (50–200K токенов релевантного содержимого), чем взял бы классический RAG, но меньше полного корпуса. LLM получает достаточно контекста, чтобы хорошо обработать запрос, без «context rot».

Реализация: извлекаем топ-50 чанков (вместо топ-5), включаем их все и даём LLM разобраться.

Хорошо работает, когда:

• Запросы требуют широкого контекста.
• Модели хорошо справляются со средними контекстами (50–200K).
• Стоимость приемлема.

Золотая середина 2026 года: извлекать агрессивно (50–100 чанков), включать всё и давать LLM использовать релевантные части. Меняем стоимость на простоту и качество.

Выбор подходящего варианта

Схема выбора:

Используйте классический чанковый RAG, когда:

• Документы — основной источник данных.
• Запросы в основном поискового характера.
• Важны объём и стоимость (самый дешёвый на запрос).
• Нужна предсказуемая задержка.

Используйте graph RAG, когда:

• У данных богатая структура «сущности и связи».
• Запросы включают многошаговые рассуждения, операции над множествами, агрегацию.
• Вы готовы вкладываться в построение и поддержку графа.

Используйте agentic RAG, когда:

• Сложность запросов сильно разнится.
• Некоторым запросам нужно итеративное исследование.
• Вы готовы платить более высокой задержкой и стоимостью за сложные запросы.
• У вас есть наблюдаемость, чтобы отлаживать прогоны агента.

Используйте long-context RAG, когда:

• Корпус небольшой (до 50K токенов).
• Нужна простейшая архитектура.
• Разовые анализы или прототипы.

Комбинируйте, когда:

• Так делают большинство реальных систем.
• Классика + graph — для реляционных запросов.
• Классика + agentic — для сложных запросов.
• Классика с более широким извлечением (средний контекст) — для пограничных случаев.

Зрелый ответ на 2026 год: «всё вышеперечисленное, по запросу». Маршрутизатор определяет, какой вариант использовать, исходя из характеристик запроса.

Реалии продакшена

Несколько наблюдений из реальных внедрений:

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

Оценивать труднее. При нескольких путях извлечения оценка должна покрывать их все. Тестовый набор должен включать запросы, которые задействуют каждый путь.

Стоимость сильно разнится. Graph RAG может быть дешёвым (запрос к БД). Long-context RAG дорогой. Agentic RAG — как повезёт (простое — дёшево, сложное — дорого). Отслеживайте стоимость на запрос.

Задержка разнится так же. 30-секундный ответ agentic RAG нормален для одних сценариев и неприемлем для других. Подбирайте вариант под UX-контекст.

Бремя поддержки. Графовые схемы дрейфуют, промпты агентов требуют настройки, модели эмбеддингов обновляются. У каждого варианта своё бремя. Планируйте заранее.

Принцип 80/20. Классический RAG адекватно обрабатывает 80% запросов. Варианты «за пределами чанков» берут те сложные 20%, с которыми классика справляется плохо. Не заменяйте — дополняйте.

Комбинированная архитектура

Практическая архитектура с использованием нескольких вариантов:

Query
  ↓
Router (классификация запроса)
  ├→ «Lookup» → Classic RAG (дёшево, быстро)
  ├→ «Relational» → Graph RAG
  ├→ «Complex / open-ended» → Agentic RAG
  └→ «Whole-corpus / small corpus» → Long-context

Каждый вариант выдаёт ответ.
Observability отслеживает, какой путь использован.
Eval suites покрывают все пути.

Это сложнее любого отдельного варианта, но хорошо покрывает весь спектр запросов. Для зрелых систем с разнообразными типами запросов это и есть итоговая архитектура.

Практическая сборка

Если вы стартуете с работающего классического RAG и хотите расшириться:

Сначала добавьте длинный контекст. Наименьшая инженерная стоимость. Полезен для конкретных типов запросов. Часто даёт выигрыш сразу.

Затем добавьте agentic для сложных запросов. Определите запросы, с которыми классика не справляется. Постройте агента, который берёт их на себя. Маршрутизируйте к нему по условию.

Graph RAG добавляйте последним. Наибольшая инженерная стоимость. Оправдан, только если у вас есть явные паттерны реляционных запросов.

Такой порядок обычно соответствует отдаче (ROI). Длинный контекст: низкая стоимость, реальная польза. Agentic: умеренная стоимость, закрывает реальные пробелы. Graph: высокая стоимость, специфические сценарии.

Дополняйте, а не заменяйте

Классический чанковый RAG — рабочая лошадка, но у него есть пределы. Варианты «за пределами чанков» — graph RAG, agentic RAG, long-context RAG — каждый открывает свои возможности.

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

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

Составьте карту своих запросов. Найдите те, которые классический RAG обрабатывает плохо. Подберите подходящий вариант. Постройте дополнение. Итерируйте.

Так RAG-системы вырастают из «полезны для части запросов» в «по-настоящему способны на всё разнообразие реальных вопросов».