GraphRAG — проект Microsoft Research, который сначала представили в блоге 13 февраля 2024 года, затем оформили как препринт в апреле 2024-го, а 2 июля 2024 года выложили в open source на GitHub. Важный нюанс: исходная работа была не про «любой RAG, только с графом», а про более узкую и сложную задачу — ответы на глобальные вопросы по всему корпусу, где обычный векторный поиск часто дает фрагменты вместо картины.
Ниже — разбор именно этой исторической версии GraphRAG от Microsoft 2024 года. Позднейшая библиотека уже включает дополнительные режимы вроде local, DRIFT и basic search, но центральная идея исходной работы — графовый индекс плюс иерархические сводки, которые помогают LLM собирать ответ не из отдельных чанков, а из структуры корпуса.
Коротко
- GraphRAG нужен прежде всего для «глобальных» запросов: темы корпуса, повторяющиеся паттерны, противоречия, общие выводы.
- Ключевой ход — заранее построить граф сущностей и связей, разбить его на сообщества и сгенерировать для них иерархические summary-отчеты.
- В июльском разборе Microsoft результаты суммируются так: GraphRAG на средних и низких уровнях сообществ давал примерно 70–80% win rate против naive RAG по полноте и разнообразию ответов при примерно 20–70% token use на запрос относительно прямой map-reduce-суммаризации исходного текста.
- GraphRAG на корневом уровне сообщества был заметно дешевле: около 2–3% token use на запрос относительно source-text summarization, хотя и с более общими ответами.
- Работа не доказывает, что GraphRAG автоматически повышает фактическую точность. В раннем блоге Microsoft faithfulness описана как сопоставимая с baseline RAG, а в самом препринте авторы отдельно пишут, что сравнение fabrication rates еще нужно усиливать.
Контекст: какую проблему решает GraphRAG
Обычный RAG чаще всего устроен так: корпус режется на чанки, чанк переводится в embedding, а на запрос пользователя система достает top-k фрагментов по семантической близости. Это хорошо работает, когда ответ локализован: найти дату, факт, определение, цитату, конкретное упоминание сущности.
Проблема начинается, когда вопрос адресован не отдельному фрагменту, а всему набору документов. Примеры из самой документации и статьи — «какие главные темы в корпусе?», «какие противоречащие друг другу позиции встречаются в новостях?», «какие паттерны повторяются в эпизодах подкаста?». Для такого вопроса top-k похожих чанков — слабый прокси. Они могут быть тематически близки к формулировке вопроса, но не обязаны представлять весь корпус.
Авторы GraphRAG называют это задачей глобального осмысления корпуса, или global sensemaking. В терминах NLP это близко к query-focused summarization: системе нужно не просто извлечь релевантные куски, а собрать целостную сводку по большому массиву текста под конкретный запрос.
Именно здесь Microsoft предлагает поменять единицу работы. Вместо того чтобы каждый раз искать похожие текстовые чанки, GraphRAG заранее строит структурированное представление корпуса: сущности, отношения между ними, сообщества связанных сущностей и summary-отчеты по этим сообществам. Запрос потом идет уже не в «плоский» список кусочков текста, а в многоуровневую карту содержимого.
Исторически это тоже важно. В исходном paper фокус — на global search. В текущей библиотеке GraphRAG уже есть local search, global search, DRIFT search и basic search. То есть сам проект со временем пришел к более прагматичной позиции: графовый режим не отменяет обычный поиск, а дополняет его там, где вопрос действительно требует глобальной структуры.
Метод: как работает GraphRAG
В статье GraphRAG разбит на индексирование и ответ на запрос. Это разделение принципиально: метод платит высокую цену заранее, чтобы потом отвечать лучше на повторяющиеся глобальные вопросы.
1. Разбиение корпуса на TextUnits
Сначала документы режутся на небольшие текстовые единицы. Это еще не отличие от обычного RAG: без нарезки нельзя стабильно запускать извлечение сущностей и связей.
2. Извлечение сущностей, отношений и описаний
Далее LLM проходит по TextUnits и извлекает сущности, связи между ними и краткие описания. По сути, модель не просто читает текст, а переписывает его в семантический слой: кто здесь важен, с кем связан и как эти связи сформулировать в компактном виде.
Это уже первое сильное отличие от vector RAG. Векторный индекс хранит близость к запросу; GraphRAG пытается хранить структуру содержания.
3. Построение графа знаний
Из извлеченных сущностей и отношений собирается knowledge graph. В документации Microsoft подчеркивает, что такой граф позволяет видеть не только отдельные факты, но и общую организацию данных.
4. Разбиение графа на сообщества
Затем граф делится на иерархические сообщества методом Leiden. Практический смысл простой: тесно связанные узлы объединяются в тематические кластеры, а кластеры можно рассматривать на нескольких уровнях абстракции — от грубых тем до более детальных подтем.
Если нужна аналогия, это похоже не на список найденных абзацев, а на оглавление, у которого есть разделы, подразделы и подпункты. Аналогия неполная, но помогает понять главное: GraphRAG пытается заранее построить карту тем корпуса.
5. Bottom-up community summaries
Для каждого сообщества LLM генерирует summary. Сначала для нижнего уровня, затем сводки поднимаются наверх и используются при генерации summary более высокого уровня. Так формируется иерархическая «память» корпуса.
Именно этот шаг, на наш взгляд, часто недооценивают, когда пересказывают GraphRAG как «RAG с графом». Новизна не только в самом графе, а в том, что граф становится основой для предвычисленных тематических отчетов, пригодных для последующего ответа на запрос.
6. Ответ на запрос через map-reduce по community summaries
Когда пользователь задает глобальный вопрос, система выбирает summaries одного из уровней иерархии и запускает map-reduce. На шаге map вопрос применяется к отдельным группам community reports, и модель производит промежуточные ответы. Затем эти промежуточные ответы ранжируются и агрегируются, после чего reduce-стадия формирует финальный ответ.
В современной документации Microsoft global search описан почти так же: ответ строится поверх набора community reports, а не поверх top-k текстовых чанков. Чем ниже уровень иерархии, тем ответ обычно подробнее, но тем выше время и стоимость.
Результаты: что показала работа Microsoft 2024
Эксперименты исходной работы были поставлены на двух корпусах порядка миллиона токенов: транскриптах подкаста и наборе новостных статей. В июльском посте Microsoft этот setup описан так же: GPT-4 использовался для генерации activity-centered questions, а затем ответы сравнивались по head-to-head-схеме с помощью LLM-judge.
Авторы оценивали три основные метрики: comprehensiveness — насколько ответ покрывает все аспекты вопроса; diversity — насколько в ответе есть разные перспективы и инсайты; empowerment — помогает ли ответ читателю сформировать более осмысленное понимание темы. Позже в paper результаты по полноте и разнообразию дополнительно проверяли через claim-based анализ, то есть через количество и разнообразие извлеченных фактических утверждений.
| Режим | Что идет в контекст LLM | Что показала работа | Практический смысл |
|---|---|---|---|
| Naive vector RAG | top-k текстовых чанков по семантической близости | Проигрывает GraphRAG по полноте и разнообразию на глобальных вопросах | Хорош для локального факта, но слаб для вопроса про весь корпус |
| Source-text summarization | map-reduce по исходным чанкам без графа | Сильный baseline, но самый дорогой среди сравниваемых global-подходов | Может давать хорошие сводки, но стоимость быстро растет |
| GraphRAG на средних и низких уровнях сообществ | Более детальные community summaries | В июльском посте Microsoft это суммировано как примерно 70–80% win rate против naive RAG по comprehensiveness и diversity при примерно 20–70% token use на запрос относительно source-text summarization | Хороший компромисс между качеством и стоимостью для глобальных вопросов |
| GraphRAG на корневом уровне | Самые общие community summaries | Ответы более обзорные, но стоимость падает примерно до 2–3% token use на запрос относительно source-text summarization; преимущество над naive RAG по глобальным метрикам сохраняется | Подходит для быстрого обзорного прохода по корпусу |
Если упростить, результат paper такой: когда вопрос требует не найти пару релевантных отрывков, а собрать высокоуровневую картину, GraphRAG выигрывает потому, что отвечает по тематическим сводкам, уже построенным над всем корпусом.
Есть и важная деталь про trade-off. Чем выше вы поднимаетесь по иерархии сообществ, тем дешевле становится ответ, но тем сильнее сжимается содержание. Чем ниже опускаетесь, тем богаче и полнее ответ, но тем больше токенов и времени нужно на обработку.
Интерпретация
Главный вклад GraphRAG — не просто в том, что к RAG прикрутили knowledge graph. Настоящее изменение архитектуры здесь в другом: retrieval-единицей становится не фрагмент текста, а предварительно осмысленный фрагмент структуры корпуса.
Это меняет сам тип вопросов, на которые система может отвечать уверенно. Обычный vector RAG хорошо ищет «что сказано вот здесь». GraphRAG пытается отвечать на «что вообще происходит в этом массиве документов».
Наш комментарий
На наш взгляд, GraphRAG полезнее всего понимать как компрессию корпуса в несколько уровней смысловых отчетов. Граф здесь нужен не ради модного слова, а как механизм тематической группировки: он помогает перевести набор разрозненных чанков в структуру, по которой LLM потом легче делать summary под запрос.
Из этого следует и практический вывод для инженеров. Если ваш пользовательский сценарий — «найди конкретный факт», GraphRAG может быть избыточен. Если сценарий — «объясни общие темы, конфликты, повторяющиеся связи и тренды по большому закрытому корпусу», тогда предвычисленная структура может окупить себя.
Показательно, что в текущей документации Microsoft GraphRAG не позиционируется как универсальная замена: там рядом живут local search и даже basic vector search. Это хороший сигнал против переоценки метода.
Ограничения и критика
1. Работа проверяет узкий класс запросов. Авторы честно пишут, что оценивали global sensemaking на двух корпусах порядка миллиона токенов. Это важно: paper не доказывает, что GraphRAG так же стабильно выиграет в FAQ-поиске, точечном QA или retrieval over tables.
2. Основные метрики — относительные, а не абсолютные. В paper качество в первую очередь меряется через head-to-head LLM judgment и claim-based proxy-метрики. Это полезно, но не то же самое, что строгое измерение фактической точности. Более того, в февральском блоге Microsoft отдельно сказано, что по SelfCheckGPT faithfulness у GraphRAG была сопоставима с baseline RAG, а в самом paper авторы пишут, что сравнение fabrication rates еще нужно усиливать.
3. Высокая цена предобработки. GraphRAG требует извлечения сущностей, построения графа, community detection и генерации summaries еще до первого пользовательского запроса. В июльском посте Microsoft прямо отмечает, что пригодность метода зависит от того, перевешивают ли преимущества структурированного индекса и поддержки global queries upfront costs его построения.
4. Исходная статья и текущая библиотека — не одно и то же. Сегодня GraphRAG — это уже более широкий набор режимов и инженерных решений. Но исходная работа 2024 года была про конкретную постановку: graph index плюс global search по community reports. Подменять этот scope более поздними возможностями библиотеки было бы некорректно.
5. На наш взгляд, многоступенчатый конвейер повышает риск накопления ошибок. Если LLM неточно извлек сущность, затем эта ошибка попала в summary сообщества, а потом summary стало входом для reduce-стадии, неточность может закрепиться на нескольких слоях сразу. Это вывод из архитектуры метода, а не отдельный эмпирический тезис paper.
Вывод
GraphRAG в версии Microsoft 2024 года — это не «лучший RAG вообще», а специализированный способ отвечать на глобальные вопросы по большим корпусам текста. Его сильная сторона — превращение корпуса в иерархию смысловых сообществ и summary-отчетов, что помогает LLM собирать ответы уровня «каковы основные темы, связи и противоречия».
Если вам нужен retrieval по фактам, обычный vector RAG и локальные режимы поиска никуда не исчезают. Но если задача ближе к аналитической сводке по большому массиву документов, исходная идея GraphRAG выглядит инженерно осмысленной и, по данным самой Microsoft, лучше согласуется с таким типом вопросов, чем плоский top-k поиск по чанкам.
Источники
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization — arXiv abstract
- Project GraphRAG – Microsoft Research
- Project GraphRAG – Microsoft Research: Publications
- GraphRAG: Unlocking LLM discovery on narrative private data
- GraphRAG: New tool for complex data discovery now on GitHub
- Welcome – GraphRAG
- graphrag/docs/query/global_search.md at main · microsoft/graphrag · GitHub
FAQ
Когда GraphRAG полезнее обычного vector RAG?
Когда вопрос требует охватить весь корпус: темы, повторяющиеся мотивы, противоречия, общие связи между сущностями. Для локального факта выигрыш неочевиден.
Заменяет ли GraphRAG обычный RAG полностью?
Нет. Это видно и по исходной работе, и по текущей документации Microsoft: в проекте сохраняются local search и basic search, потому что разные типы вопросов требуют разных режимов.
Почему GraphRAG может быть дорогим?
Потому что до первого запроса нужно построить граф, выделить сообщества и сгенерировать их summaries. Метод переносит значительную часть стоимости с query-time на indexing-time.
Доказывает ли paper, что GraphRAG точнее по фактам?
Нет в строгом смысле. Работа убедительно показывает преимущество по полноте и разнообразию ответов на глобальных вопросах, но сама Microsoft отдельно отмечала, что faithfulness была сопоставима с baseline RAG, а paper указывает на необходимость более сильной проверки fabrication rates.