Graph RAG: где он выигрывает у обычного RAG и где риск
Graph RAG — не очередной «прорыв» в генеративном ИИ, а инженерное решение давно известной проблемы: обычный Retrieval-Augmented Generation теряет связи между фактами, когда ответ требует сопоставления нескольких документов. Материал, на который указывает исходный сигнал, — разбор метода от практиков, — даёт повод разобрать его не как новость, а как рабочий инструмент. Ниже — без обёрток и хайпа: что такое Graph RAG на уровне компонентов, когда он действительно нужен, как встроить его в рабочий конвейер и что проверить до того, как показывать результат заказчику.
Что такое Graph RAG и чем он отличается от векторного RAG
Классический RAG работает по схеме «вопрос → поиск похожих чанков → генерация ответа на основе найденных кусков». Проблема возникает, когда ответ нужно собрать из разрозненных фактов, распределённых по разным документам, при этом модель должна отследить смысловые связи, а не просто соседство токенов. Там, где векторное сходство даёт список релевантных фрагментов, но не показывает, как именно они соотносятся друг с другом, Graph RAG вводит промежуточный слой — граф знаний.
Граф строится на этапе индексации: сущности (имена, даты, нормативные акты, коды продуктов) и отношения между ними извлекаются из исходного корпуса, формируя направленную структуру. При обработке запроса система сначала находит в графе релевантные подграфы, а затем подаёт их контекстом в языковую модель вместе с изначальным вопросом. Такой подход не заменяет векторный поиск, а дополняет его: векторные индексы по-прежнему отвечают за первичное извлечение, а графовый слой — за достраивание недостающих связей.
Ключевое отличие для практика: если обычный RAG отвечает «на основании трёх похожих абзацев», то Graph RAG отвечает «на основании трёх абзацев и того, что сущность А из первого абзаца является поставщиком для сущности B из второго». Это меняет класс решаемых задач.
Компоненты Graph RAG: как это собрано
Рабочий конвейер Graph RAG включает четыре последовательных блока, каждый из которых можно настраивать независимо. Понимание этих блоков важно, потому что ошибки индексации на первом шаге обесценивают все последующие.
1. Извлечение сущностей и отношений (Entity Extraction).
Над корпусом документов работает легковесная модель, обученная на задачи NER (Named Entity Recognition) и Relation Extraction. Результат — список троек: субъект, тип отношения, объект. Пример: «ООО "Пример" — поставляет — компонент К-47». Важно: модель должна работать на целевом языке корпуса и учитывать доменную специфику; общие модели вроде SpaCy en_core_web_lg не справляются с русскоязычными техническими текстами.
2. Построение графа и хранение (Graph Construction & Storage).
Тройки загружаются в графовую базу данных, обычно это Neo4j, Amazon Neptune или ArangoDB. Каждый узел — унифицированная сущность; связи — типизированные рёбра. На этом же этапе выполняется разрешение кореферентности и дедупликация, чтобы «ООО "Пример"» и «Пример, ООО» стали одним узлом.
3. Поиск по графу (Graph Retrieval).
При поступлении запроса система выполняет гибридный поиск: сначала векторный поиск находит документы-кандидаты, затем для ключевых сущностей из этих документов запускается графовый обход (обычно breadth-first search ограниченной глубины). Возвращается подграф, содержащий исходные сущности и всех соседей на расстоянии 1–2 рёбер.
4. Контекстная сборка и генерация (Context Assembly & LLM Call).
Графовый контекст линеаризуется в текстовое описание: «Сущность E1 связана с E2 отношением R1. Сущность E2 связана с E3 отношением R2…». Этот текст добавляется к основному промпту вместе с исходными чанками. Модель получает и факты, и структуру их связей.
Когда Graph RAG даёт реальное преимущество: таблица сравнения
Не все задачи требуют графового слоя. Выбор между векторным RAG и Graph RAG должен быть осознанным. Приведённая ниже таблица помогает принять первое архитектурное решение.
| Критерий | Векторный RAG | Graph RAG |
|---|---|---|
| Характер запросов | Фактоидные, «как», «что такое» | Аналитические, «кто кому что», «проследи цепочку» |
| Структура источников | Слабоструктурированный текст | Документы с явными связями: техзадания, контракты, реестры |
| Требование к полноте связей | Не критично | Критично; ответ зависит от того, знает ли граф про все звенья |
| Сложность внедрения | Низкая: достаточно векторной БД и чанков | Высокая: нужен графовый движок и стабильный extraction pipeline |
| Затраты на обновление индекса | Низкие (переиндексация чанков) | Высокие (перестроение графа при каждом изменении корпуса) |
| Типовые примеры | База знаний FAQ, поиск по документации | Due diligence, анализ цепочек поставок, комплаенс-проверки |
Практическое правило: если ответ требует соединить более двух документов через явную бизнес-сущность — начинайте с прототипа Graph RAG.
Пошаговый алгоритм внедрения Graph RAG в рабочий процесс
Ниже — проверенная последовательность шагов, которая позволяет не уйти в бесконечную настройку графовой модели, а получить измеримый результат за две-три недели.
Шаг 1. Выделите пилотный сценарий.
Не берите весь корпоративный документооборот. Выберите одну задачу, где ответ заранее известен, но обычный RAG стабильно ошибается. Пример: «найди всех контрагентов, поставляющих прекурсоры для продукта X» при условии, что записи о поставках распределены по разным договорам.
Шаг 2. Соберите эталонный датасет (ground truth).
Составьте 20–30 пар «вопрос — эталонный ответ» вместе с перечнем связей, которые обязательно должны быть в контексте. Этот набор понадобится на этапе оценки.
Шаг 3. Настройте extraction pipeline.
Для русского языка рассмотрите Natasha, DeepPavlov или адаптированную версию spaCy с RusVectōrēs. Обязательно добавьте правила для доменных сущностей (коды ТН ВЭД, ИНН, внутренние артикулы). Протестируйте на 50 случайных документах и вручную проверьте полноту извлечения троек.
Шаг 4. Поднимите графовую БД.
Если нет опыта, используйте Neo4j Community Edition в Docker-контейнере. Загрузите тройки. Включите разрешение сущностей: минимально — через fuzzy matching названий в пределах одного типа сущности.
Шаг 5. Реализуйте гибридный retrieval.
Напишите скрипт, который для запроса сначала получает чанки через векторный индекс, извлекает из них все сущности, строит запрос к графу для получения соседей на одно ребро, а затем формирует текстовый контекст. Не оптимизируйте глубину обхода без замеров — на старте достаточно depth=1.
Шаг 6. Оцените качество.
Прогоните эталонный датасет и замерьте две метрики: Coverage (доля эталонных связей, попавших в контекст) и Faithfulness (доля утверждений в ответе, которые можно проверить по графу и документам). Если Coverage ниже 80 %, вернитесь к настройке extraction pipeline и разрешения сущностей.
Шаг 7. Управляйте изменениями.
Graph RAG чувствителен к обновлению источников. Запланируйте процесс инкрементального обновления графа: при поступлении нового документа запускайте extraction только для него и мержите результаты с основным графом без полной перестройки.
Чек-лист верификации перед запуском в рабочую среду
Отметьте каждый пункт перед тем, как показывать результат бизнес-пользователю. Если хотя бы один ответ отрицательный — прототип ещё не готов.
- [ ] Extraction pipeline корректно извлекает доменные сущности, определённые заказчиком (проверено на выборке из целевого корпуса).
- [ ] Разрешение сущностей не склеивает разные объекты с похожими названиями (проверено минимум 10 примерами дубликатов и омонимов).
- [ ] Глубина графового обхода не превышает 2 рёбер и не вызывает комбинаторного взрыва контекста при максимальном размере запроса.
- [ ] Итоговый контекст, подаваемый в модель, укладывается в лимит окна конкретной LLM с учётом системного промпта и истории диалога.
- [ ] На эталонном датасете Coverage ≥ 80 %, Faithfulness ≥ 90 %.
- [ ] Реализован fallback: если граф не вернул ни одной связи, система продолжает работать как обычный векторный RAG без деградации.
- [ ] Процесс обновления графа автоматизирован и выполняется без ручного вмешательства при добавлении нового документа.
- [ ] Время отклика с учётом графового запроса не превышает установленный SLA (для синхронных ответов — обычно до 3–5 секунд).
Ограничения и когда Graph RAG не нужен
Graph RAG — не универсальный апгрейд, а дополнительный слой с предсказуемыми ограничениями. Первое и главное: качество ответов полностью зависит от полноты извлечённых троек. Если extraction pipeline допускает 20 % ошибок, графовый слой начинает не помогать, а вносить шум. Второе: поддержка графа требует серьёзной инженерной дисциплины — от версионирования схемы до мониторинга производительности графовой БД. Третье: стоимость эксплуатации выше, чем у чистого векторного RAG, за счёт дополнительной инфраструктуры и повторных вызовов LLM (часто сам extraction использует небольшую модель). Поэтому Graph RAG оправдан только когда задача без него принципиально не решается. Если пользователи задают вопросы, на которые можно ответить двумя-тремя релевантными абзацами из одного документа, — графовый слой принесёт дополнительные расходы без измеримого улучшения качества. Внедрение Graph RAG должно начинаться с бизнес-кейса, а не с желания попробовать новую технологию.
Детальный разбор метода, послуживший сигналом к подготовке этого материала, доступен по ссылке ниже. Рекомендуется смотреть его после изучения данной статьи — как иллюстрацию описанных блоков на конкретной реализации.