Вики
Блог nikolskiy.dev

GraphRAG

GraphRAG — вариант RAG, где вместо изолированных чанков строится граф знаний: сущности и связи между ними. Незаменим для multi-hop / global вопросов («какие основные темы во всём архиве?», «как связаны X и Y из разных документов?»), где обычный векторный поиск бессилен.

Суть

Обычный RAG ищет похожие фрагменты независимо — он не «видит» связи между фактами из разных документов. GraphRAG извлекает из документов сущности и отношения, строит граф, и отвечает, проходя по связям (multi-hop).

Зачем это нужно

Векторный поиск отвечает на локальные вопросы («что сказано про вклад X»), но проваливает глобальные и составные: чтобы связать факт из документа A с фактом из документа D, нужен явный граф связей, а не топ-K похожих чанков.

Как работает

  • Индексация: LLM извлекает сущности + связи → строится Knowledge Graph (отдельная структура поверх/вместо векторного индекса).
  • Запрос: обход графа по связям вместо поиска ближайших соседей; Comprehensiveness на global-вопросах +72-83%.
  • Кто строит граф — здесь решает всё. Сущности и связи извлекает модель, то есть индексация стоит вызовов LLM на каждый документ и остаётся вероятностной: сущность можно пропустить или выдумать. Это неизбежно для прозы, где связи не записаны, а подразумеваются. Для кода тот же граф даёт грамматика, и самый дорогой шаг исчезает — сравнение в Code Structural Search.
  • Цена: граф — это отдельная база поверх векторной, формируется дополнительно → стоимость памяти/индексации примерно ×2. Поэтому только для multi-hop / global, не для простых запросов.
  • Семейство графовых/иерархических техник:
    • NodeRAG (HF Papers 2025) — гетерогенный граф, превосходит GraphRAG и LightRAG по скорости индексации, времени запроса и качеству multi-hop QA.
    • RAPTOR — иерархическая кластеризация + суммаризация документов для вопросов верхнего уровня (долгая обработка, плохо масштабируется).
    • TreeRAG (ACL 2025, RAGFlow) — двухуровневый Search (точный recall) + Retrieve (сборка контекста через дерево).
  • Коробочно доступен в RAGFlow и Dify без ручной реализации.

Пример

Ключевой шаг индексации, отличающий GraphRAG от векторного RAG: LLM извлекает из текста сущности и связи, из которых строится граф знаний (здесь — упрощённо, для полного GraphRAG нужен Neo4j).

def extract_entities(text, title):
    prompt = f'''Извлеки сущности и их связи. Формат JSON:
[{{"entity": "название", "type": "тип", "relations": ["связанная_сущность"]}}]
Текст ({title}): {text[:400]}
JSON:'''
    raw = llm.invoke(prompt).content.strip()
    return json.loads(raw)                      # -> узлы и рёбра графа знаний

Когда граф окупается

Сверка 2026-08: перекос по стоимости больше, чем вдвое — построение графа обходится на порядок-полтора дороже обычной векторной индексации, потому что дорога не сама индексация, а извлечение сущностей и связей моделью. Более поздние варианты (LazyGraphRAG, LightRAG) сводят разрыв почти к стоимости эмбеддингов, откладывая построение до запроса.

Выигрыш при этом не универсальный, а строго по типу вопроса. Граф выигрывает там, где ответ собирается из нескольких документов: на multi-hop вопросах разрыв достигает кратного (в замерах — 86% против 32%), на агрегирующих запросах и вопросах «о корпусе в целом» векторный поиск проваливается почти полностью. На поиске конкретного факта в конкретном документе граф не даёт ничего — там векторный поиск не хуже, а иногда точнее.

Отсюда критерий окупаемости, не зависящий от размера корпуса: какая доля ваших реальных вопросов требует связывания нескольких источников. Если такие вопросы единичны, платить за граф не за что; если это основной класс запросов, обычный RAG будет отвечать уверенно и неверно, и вопрос стоимости отходит на второй план. Проверяется это на своём eval-наборе, где вопросы размечены по числу требуемых источников (RAG Metrics).

Варианты графового RAG: дорого — это про первую реализацию

Сверка 2026-08. Прямого сравнения с NodeRAG в открытых бенчмарках не нашлось, но более полезно другое: аргумент «граф дорого индексировать» относится к исходному GraphRAG и уже не относится к его вариантам.

  • LazyGraphRAG откладывает построение до запроса: стоимость индексации падает до 0.1% от полного GraphRAG — то есть до уровня обычного векторного RAG, — при сопоставимом качестве на локальных запросах и в 700 раз меньшей стоимости глобальных.
  • E²GraphRAG оптимизирует построение: индексация до 10 раз быстрее GraphRAG, поиск — более чем в 100 раз быстрее LightRAG и примерно в 10 раз быстрее локального режима GraphRAG.

Качество на том, ради чего граф и берут, подтверждается: на корпоративных наборах графовый подход даёт около 86% против 32% у обычного RAG, а LazyGraphRAG выигрывает у стандартного RAG в 96% сравнений на сложных классах запросов.

Практическое следствие для выбора: сначала решается, нужен ли граф вообще — по доле вопросов, требующих связывания нескольких источников (см. раздел выше), — и только потом выбирается вариант. Если нужен, начинать стоит с ленивого построения: оно снимает главный аргумент против. Для сравнения вариантов между собой появился профильный бенчмарк GraphRAG-Bench (ICLR'26), и он полезнее любого обзора.

Связано с

  • Code Structural Search — тот же графовый ход по коду, где граф даёт грамматика, а не модель
  • RAG — GraphRAG = архитектура retrieval для связанных данных
  • Chunking — альтернатива «нарезке на чанки» для глобальных вопросов
  • Agentic RAG — обе техники из «Enterprise»-фазы дорожной карты RAG