Что такое GraphRAG и зачем он нужен
GraphRAG собирает контекст для модели из графа знаний. Данные лежат в виде узлов (сущностей), рёбер (связей) и свойств, а поиск идёт по связям между объектами, а не только по косинусной близости эмбеддингов.
Практическое руководство по шести архитектурным паттернам GraphRAG описывает смену парадигмы так: система переходит от извлечения плоских документов к извлечению структурированных знаний и объединяет нечёткое сопоставление смыслов силами LLM с детерминированным reasoning графа. Там же сказано прямо: термин «GraphRAG» используют вольно, а за ним стоит несколько принципиально разных архитектур.
Потребность в этом вырастает из ограничений обычного векторного RAG. Явные локальные вопросы он закрывает хорошо, но на запросах с глобальным контекстом, многошаговым reasoning и агрегацией чисел из разных документов начинает сдавать: детерминированные связи между сущностями остаются за кадром.
Чем GraphRAG отличается от векторного RAG
Разница видна на конкретном вопросе: «Как задержка поставки детали A от поставщика B повлияет на сборку продукта C?». Векторный поиск вернёт несколько чанков по семантическому пересечению: один про поставщика, другой про продукт. Цепочку B - деталь A - продукт C он не соберёт, потому что в индексе этой цепочки нет, есть только текст. GraphRAG вытащит узел поставщика, пройдёт по ребру SUPPLIES к детали и дальше по PART_OF к продукту, после чего отдаст модели связный подграф.
| Аспект | Векторный RAG | GraphRAG |
|---|---|---|
| Единица хранения | Чанк и его эмбеддинг | Узел, ребро, свойство |
| Способ поиска | Близость векторов | Обход связей плюс similarity по эмбеддингам узлов |
| Сильные запросы | Локальные, явные, поиск по формулировке | Многошаговые, кросс-документные, с агрегацией чисел |
| Что теряется | Связи между сущностями из разных чанков | Свободный текст, не попавший в граф при извлечении |
| Стоимость подготовки | Чанкинг и эмбеддинги | LLM-проход по корпусу, онтология, графовая БД |
Вывод простой: граф не отменяет векторный поиск. В большинстве описанных ниже паттернов векторы и граф работают в одной схеме, просто с разным порядком шагов.
Когда граф знаний даёт реальный выигрыш
Граф окупается там, где ответ строится на связях, а не на одном фрагменте текста:
- Цепочки поставок: где именно возникает узкое место и как задержка одного звена расходится по всей сборке.
- Финансовые расследования и compliance: связи компаний, владельцев и транзакций, где нельзя пропустить промежуточное звено.
- Научные и патентные исследования: кто на кого ссылается и какие работы развивают одну линию.
- Кросс-документная агрегация: тренд выручки по категории за пять лет, когда цифры разбросаны по годовым отчётам за 2021-2025 годы.
- Многошаговые вопросы, где следующий шаг зависит от результата предыдущего.
Векторного RAG достаточно для поиска по документации, FAQ, инструкциям и вопросов к одному документу. Часть многошаговых задач закрывается и без графа: в разборе AgenticRetrieveStream для Amazon Bedrock LLM-планировщик разбивает сложный запрос на подзадачи и итеративно уточняет поиск по неструктурированным данным, обходясь без графа как отдельной структуры. Граф нужен тогда, когда связи должны быть явными, проверяемыми и обходимыми по имени, а не выводимыми заново на каждом запросе.
Цена решения: извлечение графа дороже векторизации, инфраструктура сложнее, а качество ответа зависит от полноты графа. При локальных запросах эти расходы не окупятся.
Базовый пайплайн GraphRAG: извлечение, хранение, retrieval, генерация
Об этом же говорит разбор базовых компонентов GraphRAG: извлечение информации, хранение графа, retrieval и генерация остаются опорами при любой логике маршрутизации. Расходятся схемы только в третьем пункте.
Извлечение сущностей и связей через LLM
Необработанный текст прогоняют через LLM с инструкцией выполнить NER (распознавание именованных сущностей) и Relationship Extraction. Модель определяет узлы (например, Company, Person, Product) и рёбра (WORKS_FOR, SUPPLIES, PART_OF). Руководство отмечает два свойства этого шага: он вычислительно дорогой и требует хорошо определённой онтологии.
Качество извлечения определяет всё остальное. Ошибка в типе сущности или в направлении связи потом не лечится ни обходом графа, ни финальной генерацией: модель просто не увидит нужного пути. Отдельная головная боль - разрешение сущностей. «ООО Ромашка», «Romashka LLC» и «Ромашка» должны свестись к одному узлу, иначе граф распадётся на изолированные куски и обход не найдёт второго конца цепочки.
Хранение графа: Neo4j, NebulaGraph, Memgraph
Извлечённые узлы и рёбра загружают в графовую базу данных. Такие базы используют специализированные языки запросов, например Cypher, для обхода узлов и связей. Дополнительно узлы и связи можно векторизовать: тогда работает поиск по сходству, когда точное совпадение по имени не дало результата.
| БД | Профиль | Язык запросов | Когда уместна |
|---|---|---|---|
| Neo4j | Зрелая экосистема, много готовых инструментов | Cypher | Быстрый старт, средние и крупные графы, нужны визуализация и админские инструменты |
| NebulaGraph | Распределённая, рассчитана на горизонтальное масштабирование | nGQL | Очень большие графы, где один сервер не тянет хранение и запросы |
| Memgraph | In-memory, низкая задержка обхода | Cypher-совместимый | Потоковые обновления и жёсткие требования к времени ответа |
Neo4j часто берут на старте, потому что вокруг него больше всего примеров и обвязки. Показательный случай - пайплайн реверс-инжиниринга, где Ghidra, локальная LLM и Neo4j собраны в один контур анализа: граф связей между функциями строится для того, чтобы видеть вызовы и зависимости целиком, а не по одному фрагменту дизассемблера. Логика выбора та же, что и в документных задачах: если нужен обход связей, реляционная таблица или плоский индекс не помогут.
Retrieval и генерация
Retrieval - это механизм, которым запрос пользователя взаимодействует с графом. Именно здесь архитектурные паттерны расходятся сильнее всего: одни превращают вопрос в запрос на языке графа, другие идут по графу и векторам параллельно, третьи отдают решение LLM-агенту.
На этапе генерации собранные из графа данные подставляют в контекстное окно LLM, и модель синтезирует финальный ответ с опорой на них. Практическое требование: в промпте должно быть явно разрешено отвечать «в графе нет подходящего пути». Без этого LLM достроит связь, которой в данных не было.
6 архитектурных паттернов GraphRAG
Паттерны отличаются способом взаимодействия запроса с графом, и описание паттернов фиксирует именно этот водораздел. Ниже шесть схем с потоком данных, сильными сторонами и рисками. Выбор между ними зависит от того, насколько структурированы вопросы пользователей и насколько полон граф.
Text-to-Cypher: генерация запросов на естественном языке
Принцип. LLM переводит вопрос пользователя в запрос на языке графа, база исполняет его и возвращает таблицу результатов, которую модель превращает в ответ.
Поток данных: вопрос - LLM (генерация Cypher) - графовая БД - результат - LLM - ответ.
Плюсы: детерминированная выборка; агрегации, сортировки и лимиты считает сама база, а не модель; результат объясним, потому что запрос виден и его можно проверить.
Минусы: нужна стабильная схема и её описание в промпте; LLM путает синтаксис, имена свойств и направления связей; расплывчатые вопросы переводятся в мусорные запросы; без таймаутов и лимитов один запрос легко положит базу на большом графе.
Сценарии: аналитика по известной схеме, вопросы вида «сколько», «топ-N», «как связаны сущности X и Y».
Параллельный гибридный поиск (вектор + граф)
Принцип. Запрос уходит одновременно в векторный индекс и в граф, результаты объединяют и только потом отдают модели.
Поток данных: вопрос - векторный поиск и графовый поиск параллельно - слияние результатов - LLM - ответ.
Плюсы: закрывает и семантику, и структуру; графовая ветка компенсирует пропуски векторной, а векторная подстраховывает граф там, где он неполон.
Минусы: слияние нетривиально: оценки косинусной близости и релевантности узлов живут в разных шкалах; контекст легко переполнить дублями; растут latency и расход токенов.
Сценарии: смешанный поток вопросов, где пользователь пишет своими словами и при этом называет конкретные сущности.
Graph-First: сначала граф, потом векторы
Принцип. Сначала обход графа находит релевантные узлы, затем векторный поиск идёт по документам и чанкам, привязанным к этим узлам.
Поток данных: вопрос - граф - подграф - векторный поиск по связанным документам - LLM - ответ.
Плюсы: узкий и чистый контекст, меньше шума, высокая точность на вопросах вокруг известных сущностей.
Минусы: полностью зависит от качества и полноты графа; документы, не привязанные ни к одному узлу, не найдутся никогда; ошибка извлечения на входе превращается в систематический пропуск на выходе.
Сценарии: вопросы об окружении конкретной сущности, разбор инцидентов и расследований с заранее известным центром.
Vector-First: сначала векторы, потом граф
Принцип. Сначала векторный поиск достаёт релевантные чанки, из них на лету извлекают сущности и связи, а граф обогащает контекст соседями и связями.
Поток данных: вопрос - векторный поиск - чанки - извлечение сущностей - граф - LLM - ответ.
Плюсы: работает на неполном графе; можно запускать на существующем векторном стеке без полной пересборки знаний; быстрый старт.
Минусы: извлечение на лету добавляет задержку на каждом запросе; результат зависит от качества NER в моменте, а не от проверенного графа; обогащение легко приносит шум.
Сценарии: граф ещё строится, запросы слабо структурированы, нужен постепенный переход от классического RAG.
Адаптивный роутер: выбор стратегии на лету
Принцип. Классификатор или LLM определяет тип вопроса и направляет его в графовый пайплайн, в векторный или сразу в оба.
Поток данных: вопрос - роутер - (векторный | графовый | гибридный) - LLM - ответ.
Плюсы: ресурсы тратятся по потребности, простые вопросы не платят за обход графа, схема расширяется без переписывания пайплайна.
Минусы: роутер ошибается, и ошибка классификации тихо портит качество; нужна разметка типов вопросов и мониторинг распределения; отладка становится двухуровневой.
Сценарии: разнородный поток обращений, где рядом живут фактологические и аналитические вопросы. Похожую задачу решает динамическая маршрутизация фактологических и аналитических запросов в TAKC: там запросы разводятся по разным путям обработки, а база знаний сжимается в 8-64 раза для аналитических сценариев.
Агентный GraphRAG: LLM как агент, управляющий графом
Принцип. LLM-агент сам решает, какие узлы смотреть, по каким рёбрам идти дальше, когда уточнить запрос и когда остановиться.
Поток данных: вопрос - агент - шаг 1 (поиск узла) - шаг 2 (обход связей) - шаг N (уточнение) - LLM - ответ.
Плюсы: максимальная гибкость, тянет многошаговые исследовательские задачи, где маршрут поиска заранее неизвестен.
Минусы: стоимость токенов и latency растут кратно числу шагов; поведение плохо предсказуемо; отладка сложна, а без лимита шагов агент уходит в цикл.
Сценарии: исследовательский анализ, разбор сложных дел, задачи, где человек сам не знает точного пути к ответу. Контроль над агентами проще держать, когда их работа видна: в обзоре GraphArc для визуализации оркестрации AI-агентов показан подход, при котором шаги агента отображаются графом в реальном времени, а опасные действия можно заблокировать до выполнения.
| Паттерн | Как запрос попадает в граф | Сильная сторона | Основной риск |
|---|---|---|---|
| Text-to-Cypher | Через сгенерированный запрос на языке графа | Точные агрегаты и проверяемость | Ошибки в синтаксисе и схеме |
| Гибридный параллельный | Одновременно с векторным поиском | Покрытие семантики и структуры | Сложное слияние и дубли |
| Graph-First | Обход графа до векторного поиска | Чистый узкий контекст | Зависимость от полноты графа |
| Vector-First | После векторного поиска, по найденным чанкам | Работает на неполном графе | Шум и задержка от извлечения на лету |
| Адаптивный роутер | По решению маршрутизатора | Экономия ресурсов | Ошибки классификации |
| Агентный | Итеративно, по шагам агента | Гибкость на сложных задачах | Стоимость и непредсказуемость |
Сравнение с Microsoft GraphRAG: иерархическая суммаризация vs обход графа
Фреймворк Microsoft GraphRAG решает другую задачу. Он строит по корпусу граф сущностей и связей, выделяет сообщества и заранее готовит иерархические суммаризации, чтобы отвечать на глобальные вопросы вида «о чём этот корпус в целом». Обход графа в момент запроса здесь не основной механизм: основную работу делает предварительная суммаризация.
Отсюда практическая разница. Для вопросов о темах, трендах и общей картине корпуса такой подход даёт то, чего не вытянет ни векторный поиск, ни точечный обход: сжатое описание больших смысловых блоков. Для точечных запросов с конкретными сущностями и связями полезнее схемы из предыдущего раздела, где граф обходится в реальном времени и отдаёт точную цепочку.
Сравнение носит концептуальный характер: разобранное руководство по шести паттернам фреймворк Microsoft не рассматривает, поэтому числа по качеству и стоимости для конкретного корпуса придётся получать своими замерами на своих данных.
Выбор между подходами упирается в тип вопросов, а не в популярность инструмента. Если большая часть обращений - «расскажи, что у нас есть по теме», ставка на суммаризацию логична. Если это «как связаны объект A и объект B», нужен обход графа.
Практические проблемы внедрения GraphRAG
Руководство останавливается на перечислении паттернов и не разбирает эксплуатацию, поэтому ниже инженерные соображения, которые стоит проверять на своём корпусе, а не готовые рецепты.
Стоимость плотного извлечения графа. LLM-проход по всему корпусу съедает заметный бюджет токенов, и он же становится узким местом по времени. Что помогает: обрабатывать только новые и изменённые документы, кэшировать результаты извлечения по хешу текста, держать дешёвую модель для NER и дорогую только для разрешения спорных случаев, разбивать корпус на батчи с отдельными лимитами.
Дрейф онтологии. Со временем в документах появляются новые типы сущностей и связей, а схема остаётся прежней. Извлечение начинает сваливать новое в ближайший старый тип, и граф деградирует. Что помогает: версионировать онтологию, регулярно просматривать типы, которые модель присваивает чаще всего и которые вообще не встречаются, вводить правила нормализации имён и явное разрешение сущностей.
Синхронизация графа с документами. Обновился источник, и граф обязан это отразить: старые рёбра удалить, новые добавить, не задев остальное. Что помогает: хранить на узлах и рёбрах идентификаторы исходных документов, пересобирать только затронутые подграфы, держать фоновую очередь переиндексации вместо полной пересборки.
Оценка промежуточных шагов retrieval. Итоговый ответ может быть верным при кривом обходе, поэтому качество поиска проверяют отдельно от генерации. Что помогает: считать precision и recall по нужным узлам подграфа относительно эталонных цепочек, сравнивать выдачу паттернов между собой на одном наборе вопросов, трассировать каждый шаг обхода. Полезно помнить, что ошибки в RAG рождаются на нескольких этапах сразу: в разборе четырёх этапов пайплайна, где появляются галлюцинации, показано, как ломается парсинг, обработка запроса, поиск и генерация по отдельности. В GraphRAG к этим этапам добавляется ещё один, обход графа, и его тоже нужно измерять отдельно.
Когда GraphRAG даёт выигрыш, а когда достаточно векторного RAG
Решение удобно принимать по типу вопросов, а не по хайпу вокруг технологии.
| Признак | Векторный RAG | GraphRAG |
|---|---|---|
| Тип вопросов | Локальные, явные, поиск по формулировке | Многошаговые, с глобальным контекстом |
| Источники | Документация, FAQ, инструкции | Взаимосвязанные данные: поставки, финансы, исследования |
| Что требуется от ответа | Найти подходящий фрагмент | Показать цепочку связей и агрегат по документам |
| Бюджет на подготовку | Чанкинг и эмбеддинги | LLM-извлечение, онтология, графовая БД |
| Частота обновлений | Переиндексация чанков | Инкрементальные обновления графа |
Практический порядок действий выглядит так:
- Запустить векторный RAG и собрать реальные вопросы пользователей.
- Отметить, на какой доле запросов ответ неполный из-за отсутствия связей между сущностями, а не из-за плохого поиска.
- Если доля заметна и связи можно извлечь из имеющихся документов, добавить граф, выбрав паттерн по типу вопросов: Text-to-Cypher для аналитики по известной схеме, гибридный поиск для смешанного потока, Graph-First для вопросов вокруг известных сущностей, агентный для исследовательских задач.
- Начать с одного паттерна и измерять retrieval отдельно от генерации, иначе улучшения нечем будет доказать.
GraphRAG не универсальная замена векторному поиску. Граф стоит денег на извлечении, требует онтологии и дисциплины в обновлениях, а на локальных вопросах проигрывает простому индексу по времени ответа. Выигрыш появляется там, где вопрос без графа не имеет однозначного ответа: когда нужно пройти по цепочке связей и собрать числа из разных документов в один проверяемый результат.