Если вы строили системы на базе RAG (Retrieval-Augmented Generation) последние два года, вы наверняка сталкивались с одной и той же проблемой: когда нужно узнать конкретную дату события, векторный поиск работает идеально, но когда нужно проанализировать общие темы в тысячах отзывов — он буксует. Причина в том, что ни один отдельный фрагмент текста не содержит полного ответа. Популярным решением стал GraphRAG, который вместо изолированных кусков данных использует графы знаний. Но стоит ли этот переход реальных затрат? Разберем факты, чтобы вы могли принять решение о выборе архитектуры.

Почему обычные текстовые чанки упираются в потолок

Стандартный векторный RAG ищет фрагменты, наиболее похожие на ваш запрос. Эта логика имеет три структурных ограничения:

• Отсутствие связей: если ответ требует объединения фактов из разных документов через общую сущность, изолированные фрагменты не покажут эту связь.
• Слепота к глобальным вопросам: вопрос «каковы основные темы?» требует анализа всего корпуса данных, а поиск по сходству возвращает лишь горсть поверхностно похожих кусков.
• Разрыв контекста: сложные рассуждения зависят от иерархии и отношений, которые процесс чанкинга просто отбрасывает.

Microsoft Research подчеркивает, что базовый RAG «с трудом связывает точки» и плохо справляется с комплексным пониманием семантических концептов в больших коллекциях данных.

Что меняет контекстный граф

GraphRAG решает проблему еще до того, как поступит вопрос. Во время индексации большая языковая модель (LLM) читает каждый фрагмент и извлекает сущности, отношения и утверждения, собирая их в взвешенный граф знаний. Затем алгоритм Leiden группирует граф в иерархию связанных тем и заранее создает краткие описания для каждой группы.

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

Доказательства: четыре исследования, один паттерн

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

1. Глобальное понимание корпуса

В прямом сравнении Microsoft противопоставила GraphRAG наивному RAG на наборах данных объемом в миллионы токенов. GraphRAG выиграл в 72–83% сравнений по полноте ответов и в 62–82% — по разнообразию. При этом высокоуровневые сводки использовали до 97% меньше токенов, чем прямая обработка исходного текста. Это критически важное преимущество для задач синтеза информации.

2. Многоходовый поиск (Multi-hop)

Граф находит то, что пропускают чанки. На стандартных бенчмарках (MuSiQue, HotpotQA) точность поиска (Recall@5) при использовании графа выросла с 73,4% до 87,8% (+19,6 пункта). Самые большие скачки — в сложных кросс-документных наборах: +31 пункт на MuSiQue и +28 на 2Wiki.

3. Честное сравнение: где графы проигрывают

Исследование 2025 года от Michigan State и Meta показало, что универсального победителя нет. Подходы дополняют друг друга:

• На простых фактологических запросах (одиночный переход) обычный RAG оказался эффективнее (F1 64,8 против 63,0 у лучшего метода на графах).
• В задачах сложных рассуждений (MultiHop-RAG) графовый поиск вырвался вперед (70,3 против 67,0).

4. Итоговый вердикт по типам задач

Бенчмарк GraphRAG-Bench (ICLR 2026) четко очертил границы эффективности:

1. Простой поиск фактов: чанки 60,9 против графа 60,1 — фактически ничья. Структура графа здесь — лишние расходы.
2. Сложные рассуждения: граф 53,4 против чанков 42,9 — преимущество графа на 10 пунктов.
3. Контекстная суммаризация: граф 64,4 против чанков 51,3 — преимущество графа на 13 пунктов.

Цена вопроса и нюансы реализации

Прежде чем внедрять GraphRAG, нужно учесть два критических фактора. Во-первых, построение графа дорогое. Извлечение сущностей из всего корпуса данных требует значительных ресурсов. Один анализ оценил создание индекса примерно в $48 при использовании GPT-4o для среднего корпуса, что значительно выше стоимости векторного индекса. Microsoft позже предложила метод LazyGraphRAG, который переносит извлечение на этап запроса, снижая стоимость до 0,1%, но это признание того, что исходный бюджет часто непрактичен.

Во-вторых, многие победы графов оцениваются другой LLM, которая может быть предвзятой. Аудит показал, что систематические ошибки оценки (позиционная и длина ответов) могут сильно искажать результаты. После корректировки некоторые методы показали результаты ниже 50%, что требует осторожности при интерпретации «прорывных» цифр.

Что вам делать: выбор архитектуры

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

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

Придерживайтесь обычных текстовых чанков, если:

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

Оптимальный путь — гибридная модель. Исследования сходятся в рекомендации: маршрутизируйте каждый запрос к нужному методу или объединяйте доказательства из обоих источников. Вам не нужно выбирать «религию» — вам нужно построить роутер. Подробнее: Anthropic выпустила Claude Opus 5. Вот когда вам стоит переключиться на новую модель.