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

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

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

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

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

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

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

Предел 2: нет multi-hop. «Клиенты, использующие фичу X и пожаловавшиеся на Y» требует комбинации информации из двух разных источников с set-логикой. Chunk-based retrieval этого не делает.

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

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

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

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

Graph RAG

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

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

Домены, насыщенные связями. Структуры customer-account-deal-interaction. Org-иерархии. Таксономии продуктов. Сети цитирования. Всё, где связи между сущностями значат не меньше самих сущностей.

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

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

Цитирование и объяснения. Связи в графе явные и аудируемые. LLM может процитировать «John is the manager of Team Acme [edge: manages]» вместо «I think John manages Team Acme based on context».

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

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

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

• Структурированные источники (БД, структурированные API): импортируем напрямую. Клиенты, продукты, транзакции уже в таблицах.
• Неструктурированные источники (документы, транскрипты, письма): используем LLM, чтобы извлечь сущности и связи. «From this transcript, extract people, organizations, and the relationships between them.»

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

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

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

4. Запрос на retrieval. Три распространённых паттерна:

• Graph-only query. LLM (или роутинг-логика) генерирует graph-запрос (Cypher, SQL). Исполняем. Возвращаем результаты в LLM.
• Embedding-first, graph-expand. Находим релевантные сущности эмбеддингом. Затем расширяемся до их соседей и связанных сущностей.
• Гибрид. Комбинируем векторный поиск + обход графа в одном пайплайне.

5. Форматирование для LLM. Graph-результаты форматируются как структурированный текст, который 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-tier имели более 3 тикетов поддержки в Q1 и идут на продление в Q2?»

Это естественно graph-запрос:

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, когда связи — first-class-граждане в вашем домене. Не выбирайте, потому что звучит продвинуто; для многих document-heavy доменов классический RAG проще и не хуже.

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

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

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

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

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

Agentic RAG

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

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

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

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

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

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

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

Пайплайн:

User query
    ↓
Agent reasons about what it needs
    ↓
Agent calls retrieval tools (one or many)
    ↓
Agent reads results
    ↓
Agent decides: enough info? Or another retrieval?
    ↓
Loop until done
    ↓
Generate final answer

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

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

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

Принятие решений. Агент явно рассуждает, достаточно ли у него информации. «Do I know the answer to the user's question? If not, what else do I need to retrieve?»

Завершение. Агент должен знать, когда остановиться. Бюджет max-step. Порог уверенности. Условие «I've answered».

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

Запрос: «Каковы топ-3 заботы клиентов в Q1, с примерами?»

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

Подход agentic RAG:

Agent: I need to find Q1 customer concerns. Let me start by searching for customer complaints in that period.
> Tool: search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})

Agent: I got 25 results. Let me see what topics they cover.
> [reads results]

Agent: I see three main themes: pricing, slow support, and missing integrations. Let me get specific examples for each.
> 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: Now I have 3-5 specific examples per theme. Let me compile the answer.

Несколько retrieval-ов, итеративно уточнённых. Агент решает структуру на основе того, что находит.

Компромиссы

Плюсы:

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

Минусы:

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

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

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

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

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

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

Паттерн 2: Plan-and-execute. Агент сначала создаёт многошаговый план (что доставать в каком порядке), потом исполняет план, возможно — корректирует.

Паттерн 3: Self-critique. После retrieval агент оценивает, достаточно ли извлечённой информации. Если нет — уточняет запрос и достаёт снова.

Паттерн 4: Tool-rich агент. У агента много retrieval-инструментов (full-text search, SQL-запрос, graph-запрос, API-вызовы), и он выбирает между ними.

Разные паттерны подходят разным use case-ам. Tool-rich работает для гетерогенных источников; ReAct — для исследовательских запросов; plan-and-execute — когда структура сложного запроса может быть спланирована заранее.

Long-context RAG

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

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

Маленькие корпусы. Корпус в 100K токенов легко влезает в окно 1M токенов. Не нужна retrieval-инфраструктура.

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

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

Прототипирование. Long-context — простейший путь к работающей системе. Стройте прототип на long-context; оптимизируйте retrieval-ом потом, если понадобится.

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

Пайплайн тривиальный:

[corpus, possibly 100K-1M tokens]
    ↓
+ [user query]
    ↓
LLM call
    ↓
[answer]

Никакого vector store. Никакого chunking. Никакого reranking.

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

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

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

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

• Качество выше всего при 5–50K токенов контекста.
• Качество заметно падает при 100K+ токенов.
• При 500K+ важная информация часто упускается или применяется неверно.

Модели технически могут обрабатывать длинные контексты, но бенчмарки «needle in a haystack» переоценивают их производительность. Реальное использование long-context страдает.

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

Компромиссы

Плюсы:

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

Минусы:

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

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

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

Гибрид: retrieval + long-context

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

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

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

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

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

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

Decision-фреймворк:

Используйте классический chunk-based RAG, когда:

• Документы — основные данные.
• Запросы в основном retrieval-стилевые.
• Объём и стоимость важны (самый дешёвый на запрос).
• Нужен предсказуемый latency.

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

• У данных богатая entity-relationship структура.
• Запросы включают multi-hop рассуждения, set-операции, агрегацию.
• Готовы вкладываться в построение и поддержку графа.

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

• Сложность запросов сильно варьируется.
• Некоторые запросы требуют итеративного исследования.
• Готовы платить более высоким latency/стоимостью за сложные запросы.
• Есть observability для дебага agent-run-ов.

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

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

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

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

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

Production-реалии

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

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

Eval сложнее. С несколькими retrieval-путями оценка должна покрывать их все. Тест-сет должен включать запросы, упражняющие каждый путь.

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

Latency варьируется аналогично. 30-секундный ответ от agentic RAG нормален для одних use case-ов, не для других. Подбирайте варианты под UX-контекст.

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

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

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

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

Query
  ↓
Router (classify the query)
  ├→ "Lookup" → Classic RAG (cheap, fast)
  ├→ "Relational" → Graph RAG
  ├→ "Complex / open-ended" → Agentic RAG
  └→ "Whole-corpus / small corpus" → Long-context

Each variant produces an answer.
Observability tracks which path was used.
Eval suites cover all paths.

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

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

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

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

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

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

Этот порядок обычно соответствует ROI. Long-context: низкая стоимость, реальная польза. Agentic: умеренная стоимость, закрывает реальные пробелы. Graph: высокая стоимость, специфические сценарии.

Главный вывод

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

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

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

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

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