GraphRAG: как устроен поиск и когда нужен граф знаний

Документация проверена 26 октября 2026 года по документации Microsoft GraphRAG, репозиторию проекта и документации Neo4j и LlamaIndex. Сравнение ниже основано на описанных в документации механизмах, а не на тестировании производительности. Примеры с обратной связью о продукте приведены для пояснения.

Что такое GraphRAG?

Microsoft GraphRAG готовит обобщённое представление о коллекции ещё до того, как пользователь попросит её обобщить. Большая языковая модель, или LLM, извлекает из документов сущности и связи между ними. Связанные сущности объединяются в сообщества, для которых модель составляет сводки. Затем механизм обработки запросов использует эти структуры при подготовке ответов. Метод и основные режимы поиска описаны в обзоре Microsoft.

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

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

Так возникает знакомая проблема. RAG-приложение дополняет генерацию поиском: перед ответом оно передаёт модели найденные сведения. Оно верно находит правила экспорта, но поверхностно отвечает на вопрос «Что раздражает клиентов, если судить по всем этим интервью?». Для второго вопроса нужен охват всей коллекции. При этом фрагмента, в котором ответ сформулирован напрямую, может вообще не быть.

Термином «Graph RAG» также называют более широкое семейство поисковых систем, использующих графы. Здесь речь идёт о реализации Microsoft. Приложение на другом фреймворке, даже если оно работает с графом, не обязательно строит отчёты по сообществам Microsoft или использует её метод глобального поиска.

Как работает GraphRAG?

Главное отличие возникает на этапе индексации: GraphRAG создаёт на основе данных описания, которые затем можно использовать в разных запросах. В стандартном методе индексации Microsoft языковые модели отвечают за извлечение информации и подготовку сводок, а кластеризация графа формирует структуру сообществ.

На практике этапы зависят друг от друга:

1. Разбить документы на текстовые блоки. Это фрагменты исходного текста, или чанки. Ссылки на документы позволяют проследить происхождение извлечённой информации.
2. Извлечь сущности и связи. LLM читает каждый блок и описывает найденные объекты и отношения между ними.
3. Объединить данные графа. Описания совпадающих сущностей и связей объединяются и обобщаются. Согласно документации, правила объединения учитывают название и тип сущности, а для связи — её исходную и целевую сущности.
4. Выделить сообщества. Алгоритм кластеризации графов Hierarchical Leiden группирует связанные сущности на разных уровнях детализации.
5. Создать отчёты по сообществам и эмбеддинги. LLM составляет сводки по сообществам. Для объектов, по которым будет вестись поиск, также создаются эмбеддинги — числовые представления для поиска по сходству.

Эта последовательность соответствует схеме индексации Microsoft. Извлечение утверждений — отдельный необязательный процесс, по умолчанию отключённый. Для построения стандартного графа и отчётов он не требуется.

Допустим, в интервью о продукте упоминаются проект Atlas, ошибки экспорта и процедура согласования. В другом разговоре Atlas связывают с общим рабочим пространством. Если эти связи будут извлечены, отчёты по сообществам смогут собрать связанные проблемы воедино, даже когда в документах используются разные формулировки.

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

По умолчанию Microsoft сохраняет результаты индексации в таблицах Parquet — колоночном файловом формате, — а эмбеддинги записывает в настроенное векторное хранилище. Отдельная графовая база данных при такой организации не требуется. Обзор индексации.

Режимы поиска: Global, Local, DRIFT и Basic

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

Global: общие темы во всей коллекции

Глобальный поиск — главная причина проверить Microsoft GraphRAG на вопросах вроде «Какие основные темы встречаются во всех этих документах?». Материалом для ответа служат отчёты по сообществам на выбранном уровне иерархии.

В основе лежит map-reduce: сначала отдельная обработка пакетов данных, затем объединение результатов. На этапе map из пакетов отчётов получаются частичные ответы с оценками отдельных тезисов. На этапе reduce полезные тезисы отбираются и складываются в итоговый ответ. Более подробные отчёты по сообществам могут повысить как детализацию ответа, так и затраты ресурсов. Документация глобального поиска.

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

Есть существенное ограничение: глобальный поиск обобщает отчёты. Он не подсчитывает точно, сколько клиентов упомянули каждую проблему. Если для решения нужен рейтинг по частоте, используйте процедуру подсчёта с явно заданными единицами и устранением дублей, а модели поручите объяснить результат.

Local: сущность и её окружение

Локальный поиск подходит для вопроса «Как проект Atlas связан с проблемами экспорта?». Он находит семантически близкие сущности, собирает связанные с ними сведения из графа и фрагменты источников, а затем отбирает материал в пределах контекстного окна для ответа. Документация локального поиска.

Это полезно, когда ответ зависит от связей, разбросанных по разным документам. Граф даёт отправные точки и связи, а исходные фрагменты — подтверждающие детали. При этом локальный поиск по-прежнему опирается на сходство и ограниченный контекст, поэтому не гарантирует, что в ответ попадёт каждая значимая связь.

DRIFT: от общего контекста к уточняющим вопросам

DRIFT начинает с релевантных сведений о сообществах и формирует уточняющие вопросы, для которых использует локальный поиск. Режим подходит для исследования темы, когда первый общий ответ подсказывает более конкретные направления поиска. Документация DRIFT.

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

Basic: базовый поиск для сравнения

Basic находит похожие текстовые фрагменты с помощью векторного поиска. Microsoft включает этот режим, чтобы упростить сравнение разных типов запросов. Он полезен как контрольный вариант для узкого вопроса вроде «Что сказано в правилах экспорта?». Документация механизма обработки запросов.

GraphRAG vs RAG: сравниваем задачи и устройство индекса

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

Гибридный поиск решает другую проблему, чем обобщение всей коллекции. В документации Microsoft по гибридному поиску описано объединение результатов полнотекстового и векторного поиска. Если приложение не находит точный код продукта, начните с гибридного поиска. Глобальная сводка по сообществу — обходной путь для решения проблемы лексического поиска.

Агентный RAG меняет порядок работы с поиском. Модель может решить выполнить поиск, оценить релевантность, переформулировать вопрос и поискать снова — как показано в руководстве LangGraph по агентному поиску. Используйте агентный RAG, когда приложению нужно выбирать, какие сведения собирать дальше.

Эти подходы можно сочетать. Агент способен вызывать поиск по графу, а модуль поиска на основе графа — начинать с гибридного поиска. Важно понять, какой дополнительный механизм исправляет наблюдаемую проблему. Если добавить всё сразу, установить это будет сложнее.

Почему индексация GraphRAG требует больше работы

Стандартный GraphRAG добавляет генеративную обработку к построению эмбеддингов обычного векторного индекса. Универсального обоснованного коэффициента, который можно применить к числу документов, нет: объём работы зависит от текста, настроек извлечения, полученного графа и отчётов.

Для планирования полезна такая модель:

Работа при индексации = обработка чанков + проходы извлечения + сводные описания + отчёты по сообществам + эмбеддинги.

Это способ учёта работы в пилотном проекте, а не формула тарификации поставщика. Измеряйте каждый этап отдельно, чтобы видеть, что растёт при добавлении данных.

Чанки определяют объём повторной работы по извлечению. Чем больше чанков, тем больше текстовых блоков нужно проанализировать. Размер чанка и перекрытие влияют на то, сколько повторяющегося контекста обрабатывает механизм извлечения. В конфигурации Microsoft также есть max_gleanings, управляющий дополнительными циклами извлечения. Не следует считать, что каждый чанк всегда обходится ровно в один вызов LLM. Справочник конфигурации.

Размер графа определяет объём последующей обработки. Коллекция с множеством разных сущностей и связей может породить больше описаний для объединения, чем сопоставимая по объёму коллекция на узкую тему. Повторные упоминания создают описания, которые нужно объединить; разнообразие связей влияет на состав сообществ, для которых понадобятся отчёты. Это следует из устройства этапов извлечения и обобщения, а не только из числа документов.

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

Повторное использование кеша позволяет избежать части обращений к модели. Microsoft кеширует результаты вызовов LLM для последующих запусков индексации. Измеряйте построение с нуля и обновление отдельно: повторный запуск с кешем не покажет, сколько ресурсов потребует новая коллекция. Настройка кеша.

Обработка запросов требует отдельного бюджета. Глобальный map-reduce и исследование через DRIFT могут выполнять несколько операций с моделью уже после завершения индексации. Успешный пилот по индексации ещё не означает приемлемого времени ответа.

Свежие документы не гарантируют актуальности сводок

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

Microsoft предоставляет команду graphrag update; актуальное описание CLI указывает, что новый индекс по умолчанию записывается в update_output. В конфигурации также предусмотрено отдельное хранилище обновлений, позволяющее сохранить прежние результаты. Инкрементальное обновление существует, но одна команда обновления ещё не задаёт полноценную политику синхронизации. Справочник CLI, хранилище обновлений.

Представьте разговор со службой поддержки, который исправляет прежнее утверждение о проекте Atlas. Новый документ уже доступен, но используемый в приложении отчёт по сообществу всё ещё описывает старую ситуацию. Это сбой поддержки актуальности, даже если прямой поиск находит исправление.

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

Команде эксплуатации важно видеть версию индекса и знать, на каком срезе исходных данных он построен. Публикуйте согласованный набор результатов индексации, а затем направляйте запросы к этой версии. Если бизнесу нужны немедленные ответы по быстро меняющимся записям, сохраняйте возможность прямого поиска, пока оцениваете процесс обновления отчётов.

Два других подхода к RAG на графах

Neo4j и LlamaIndex предлагают компоненты для поиска по графам с другими решениями в области извлечения данных, хранения и обработки запросов. Оценивайте механизм, описанный в документации конкретного инструмента: «GraphRAG» не обозначает один продукт, реализации которого взаимозаменяемы.

GraphRAG на базе Neo4j

В Neo4j GraphRAG for Python есть VectorCypherRetriever: сначала он находит похожие узлы, затем выполняет поисковый запрос для сбора дополнительного контекста. Cypher — язык запросов к графам Neo4j. Пакет также предлагает гибридный поиск с векторными и полнотекстовыми индексами и Text2Cypher для преобразования вопроса в запрос к базе данных. Руководство по поисковым компонентам Neo4j.

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

Инструменты построения графа Neo4j также поддерживают извлечение сущностей и связей с помощью LLM, запись графа и устранение дублей сущностей. Согласно документации, при ошибках извлечения проблемные чанки могут игнорироваться, если не задать другое поведение. Проверяйте не только выполнение запроса, но и полноту загрузки данных. Руководство Knowledge Graph Builder.

Ограничение этого подхода: векторный поиск с последующим запросом к графу сам по себе не создаёт иерархию отчётов по сообществам Microsoft. Если нужны широкие тематические сводки, отдельно определите, как будет устроен этот слой.

Графы свойств в LlamaIndex

В LlamaIndex за построение графа и поиск отвечает PropertyGraphIndex. Граф свойств хранит сущности с метками, их атрибуты и связи. Компоненты извлечения обрабатывают чанки; SchemaLLMPathExtractor позволяет ограничить извлечение допустимыми схемами сущностей и связей. VectorContextRetriever находит узлы графа по эмбеддингам и извлекает связанные пути; параметры поиска позволяют также получить исходный текст. Руководство по графам свойств.

Этот подход подойдёт разработчику, которому нужны настраиваемые компоненты извлечения и поиска внутри фреймворка приложения. Описанные операции вставки, добавления с обновлением существующих записей и удаления дают средства для поддержки графа. Но политику обработки изменений в источниках и извлечённых из них фактах всё равно нужно определить на уровне приложения.

Ограничение: доступные операции зависят от хранилища графа. Используемое по умолчанию SimplePropertyGraphStore не является графовой базой данных и не поддерживает Cypher. Выбирайте хранилище и механизм поиска вместе. Наличие индекса графа свойств также не означает, что в нём есть процесс глобального обобщения Microsoft.

GraphRAG на практике: проверяйте на своей проблеме

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

После настройки рабочего каталога и учётных данных можно выполнить эти команды — они соответствуют синтаксису в актуальной документации CLI:

graphrag index --method standard
graphrag query "What are the main themes across these documents?" --method basic
graphrag query "What are the main themes across these documents?" --method global

В актуальном справочнике CLI текст запроса передаётся позиционным аргументом.

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

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

Если нужные сведения уже доступны, но модель регулярно ошибается с форматом или поведением, вернитесь к сравнению RAG и дообучения. Более сложный индекс решает задачу доступа к информации; он не обязательно устраняет любую проблему генерации.

Какие ожидания от GraphRAG завышены?

Обоснованное утверждение гораздо уже, чем «графы улучшают RAG»: определённый граф и способ поиска могут улучшить сбор сведений для определённого типа задач.

Связи не подтверждают истинность. Извлечённые отношения и отчёты по сообществам могут содержать ошибки. Относитесь к ним как к интерпретациям, по которым можно искать, и сохраняйте возможность проследить их до источника. Путь в графе облегчает проверку работы поиска, но не доказывает истинность лежащего в его основе утверждения.

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

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

Репозиторий — не управляемый сервис Microsoft. В пояснении к репозиторию Microsoft описывает код как демонстрацию методологии, а не как официально поддерживаемое предложение компании. Ответственность за развёртывание, мониторинг и обновление данных всё равно нужно на кого-то возложить.

Частые вопросы о GraphRAG

Что сделать на следующей неделе

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

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

Чтобы получать практические руководства по созданию систем ИИ, подпишитесь на рассылку.