Что такое GraphRAG: поиск связей в документах — это подход к ответам по корпусу текстов, при котором система строит граф сущностей и связей и опирается на него при поиске. В рассматриваемой реализации Microsoft из текста извлекаются связи, строятся сообщества и их сводки. Это устройство конкретной реализации; всё семейство не обязано повторять её конвейер. Точечный вопрос про один факт решается обычным поиском по фрагментам.
Граф, узел, связь и источник
Граф — это набор узлов и соединяющих их связей. Узел обозначает сущность: компанию, сервис, команду, человека, место. Связь обозначает отношение между двумя узлами: «использует», «поддерживает», «обучает». Источник — документ, из которого извлечены узел или связь; без ссылки на источник связь невозможно проверить.
В нашем мини-графе единицей проверки служит DOC-A, DOC-B или DOC-C. Например, связь Сосна → использует → Портал проверяется по первому предложению DOC-A; соседнее предложение задаёт другую связь — о поддержке сервиса.
Практическое следствие для читателя: граф без источников превращается в набор догадок. Если связь «Север поддерживает Портал» не отсылает к документу, проверить её нельзя. Поэтому в рабочей схеме рядом с каждой связью хранят идентификатор документа, тип отношения и дату источника. Дата важна: корпус меняется, и связь, верная в прошлом месяце, может устареть.
Узел и связь — это ещё и способ увидеть структуру корпуса. Один документ описывает локальный факт. Множество документов, связанных общими сущностями, показывает, как устроена предметная область: какие сервисы обслуживает одна команда, какие компании зависят от одного поставщика. Такой обзор использует связи между несколькими фрагментами корпуса.
Семейство GraphRAG и реализация Microsoft
GraphRAG — семейство подходов, объединённых идеей графа сущностей и связей. Конкретные реализации различаются тем, как строится граф, как хранятся узлы и как формулируется поиск. Обобщать устройство одной реализации на всё семейство нельзя.
Ниже разбирается именно реализация Microsoft: её последовательность этапов и названия режимов поиска. Выбор этой реализации для объяснения не означает обязательного стека или способа хранения графа для других проектов.
Первичная работа на arXiv описывает двухэтапное построение графового индекса: сначала из исходных документов выводится граф знаний о сущностях, затем заранее готовятся сводки сообществ для групп тесно связанных сущностей. При вопросе каждая сводка даёт частичный ответ, а частичные ответы сводятся в итоговый. Здесь прочитана аннотация работы, а количественные выводы эксперимента не используются для обещания качества на другом корпусе.
Реализация Microsoft не задаёт обязательный стек для всего семейства. Документация проекта называет Leiden для кластеризации в своём процессе; другие реализации вправе использовать иные способы группировки и иные хранилища.
Индексация, извлечение, сообщества, поиск, ответ
Порядок работы удобно разложить на пять шагов.
- Индексация. Корпус нарезается на TextUnit — фрагменты, которые дальше служат опорой и дают точные ссылки в результатах.
- Извлечение. Из фрагментов достаются сущности, отношения и ключевые утверждения. Здесь появляются узлы и связи с привязкой к источникам.
- Сообщества. Граф кластеризуется иерархически; документация проекта называет метод Leiden. Для каждого сообщества и его состава генерируется сводка снизу вверх, что помогает целостному пониманию набора.
- Поиск. На этапе запроса структуры наполняют контекст модели. Документация проекта перечисляет режимы: Global Search, Local Search, DRIFT Search и Basic Search.
- Ответ. Модель формирует ответ, опираясь на подобранные материалы.
Режимы различаются по задаче. Global Search идёт по всем сводкам сообществ в схеме map-reduce; в документации проекта он назван ресурсоёмким и предназначен для вопросов о наборе целиком. Local Search соединяет данные графа с текстовыми фрагментами исходных документов и подходит для вопросов о конкретных сущностях. DRIFT Search добавляет к локальному поиску сведения о сообществах, расширяя стартовую точку запроса и разнообразие используемых фактов. Basic Search — простейшая векторная реализация для сравнения результатов по типу вопроса; число фрагментов top k задаётся.
Отдельная функция — генерация вопросов: список запросов превращается в следующие кандидаты, что полезно для продолжения беседы или для списка тем, которые стоит изучить в наборе.
Вопрос к одному факту, к связям и ко всему корпусу
Три типа вопросов требуют разной механики.
| Тип вопроса | Что нужно найти | Подходящий режим |
|---|---|---|
| Один факт | Фрагмент с прямым утверждением | Basic Search, обычный поиск по фрагментам |
| Связи между сущностями | Цепочку узлов и отношений | Local Search, DRIFT Search |
| Обобщение по корпусу | Тему, закономерность, сводку | Global Search |
Вопрос «Какой сервис использует Сосна?» упирается в один абзац. Ответ лежит в одном фрагменте, и граф здесь избыточен: достаточно найти нужный текст. Вопрос «Какие компании связаны с сервисами, которые поддерживает Север?» требует пройти по связям: от команды к сервисам, от сервисов к компаниям. Граф позволяет явно проследить этот путь. Ответ можно собрать и другими процедурами поиска по нескольким фрагментам; обязательность графа из примера не следует.
Вопрос «Какие темы преобладают в наборе?» требует обзора корпуса. Аннотация первичной работы рассматривает его как суммаризацию по запросу. Наши три учебных документа показывают связи, но не измеряют качество такого обобщения на большом наборе.
Выбор режима — это выбор того, что искать: фрагмент, цепочку или сводку.
Учебный мини-граф: документы и эталоны
Ниже — условный пример для тренировки. Все документы и связи заданы вручную; GraphRAG не запускался, рост качества не измерялся.
DOC-A: «Компания Сосна использует сервис Портал. За поддержку Портала отвечает команда Север».
DOC-B: «Компания Берег использует сервис Портал. За обучение сотрудников Берега отвечает команда Юг».
DOC-C: «Компания Роща использует сервис Каталог. Команда Север обслуживает сервис Каталог».
Узлы: Сосна, Берег, Роща, Портал, Каталог, Север, Юг. Связи с источниками: Сосна → использует → Портал [A]; Берег → использует → Портал [B]; Север → поддерживает → Портал [A]; Север → поддерживает → Каталог [C]; Роща → использует → Каталог [C]; Юг → обучает → Берег [B].
Ручные эталоны для проверки:
| Вопрос | Эталонный ответ | Опора |
|---|---|---|
| Какой сервис использует Сосна? | Портал | A |
| Какие компании связаны с сервисами, которые поддерживает Север? | Сосна и Берег через Портал; Роща через Каталог | A, B, C |
| Север обучает сотрудников Берега? | Неизвестно | B |
Третий эталон показывает границу метода. В корпусе сказано, что Юг обучает Берег. Связи «Север обучает Берег» в документах нет. Отсутствие связи означает, что сведений нет, и превращать это в доказательство отрицания нельзя. Граф отвечает на вопрос о том, что в нём есть.
Проверка ошибочной связи и отсутствующего факта
Проверка результата — отдельный шаг, который стоит делать до того, как ответ уйдёт читателю.
Возьмём ошибочное извлечение: «Юг поддерживает Портал». Такая связь не проходит сверку, поскольку исходный фрагмент B говорит об обучении сотрудников Берега. Тип отношения в источнике — «обучает», и подмена его на «поддерживает» меняет смысл. Проверка идёт по трём полям: идентификатор фрагмента, тип отношения, дата источника. У всех учебных документов дата 10.11.2026.
Порядок ручной сверки:
- Открыть фрагмент, на который ссылается связь.
- Сравнить тип отношения в графе с формулировкой в тексте.
- Убедиться, что оба конца связи упомянуты в этом фрагменте.
- Отдельно отметить вопросы, на которые в корпусе нет ответа, и не выдавать по ним утверждений.
Первая проверяемая ошибка — считать пустоту доказательством. Другая — склеивать две связи в одну: если Север поддерживает Портал, а Берег использует Портал, из этого не следует, что Север поддерживает Берег. Цепочку из двух рёбер помечайте как вывод о пути и сохраняйте источники обоих рёбер.
Третья ошибка — терять источник при обобщении. Сводка сообщества полезна для обзора, и проверять её следует по тем фрагментам, из которых она собрана.
Затраты, обновление и границы гарантий
Подготовка графа и сводок добавляет работу к обработке фрагментов. Руководство Query Engine называет Global Search ресурсоёмким. Для своего корпуса отдельно фиксируйте вызовы индексации и запросов; в нашем ручном наборе ни один такой вызов не выполнялся.
Обновление корпуса проверяйте на уровне источников и производных связей. Если DOC-A заменён, найдите все рёбра со ссылкой A и проверьте их заново. Затем проверьте ответы, которые использовали эти рёбра, и относящиеся к ним сводки. Перед изменением рабочего индекса сохраните версию корпуса и настройки; конкретные команды миграции сверяйте с установленной версией проекта.
Документация Microsoft рекомендует настраивать промпты под свои данные. Для учебного набора критерий остаётся конкретным: связи соответствуют A/B/C, а отсутствие факта об обучении Севером не превращается в отрицание. Качество на другом корпусе требует отдельной проверки.
Частые вопросы
Что такое GraphRAG простыми словами?
Это поиск с опорой на граф сущностей и связей. В нашем примере путь от Севера через Портал приводит к Сосне и Берегу; каждое ребро сохраняет источник.
Чем GraphRAG отличается от обычного RAG?
Базовый поиск опирается на векторное сходство и возвращает похожие фрагменты. Рассматриваемая реализация Microsoft дополнительно строит граф и сводки сообществ для вопросов о связях и корпусе в целом. Документация проекта описывает оба варианта и называет базовый поиск частью своей реализации.
GraphRAG от Microsoft — это единственная реализация?
Нет. Здесь разобрана конкретная реализация Microsoft. Для другого проекта проверяйте его собственные этапы индексации и поиска.
Когда хватает обычного поиска?
Когда ответ лежит в одном фрагменте: название сервиса, дата, имя ответственного. В учебном примере вопрос «Какой сервис использует Сосна?» закрывается одним документом. При вопросе к нескольким источникам граф — один из способов явно представить путь между общими сущностями.
Почему граф может ошибаться?
Связи извлекает модель, и она может подменить тип отношения: вместо «обучает» записать «поддерживает». Проверка по источнику, типу отношения и дате отсекает такие случаи. Отсутствие связи в графе означает нехватку сведений, и вывод об отрицании из него не следует.