GraphRAG: как графы знаний улучшают ответы LLM

Что такое GraphRAG

GraphRAG — вариант retrieval-augmented generation, где база знаний — это не только набор текстовых фрагментов с эмбеддингами, но и граф знаний: узлы — сущности (люди, компании, продукты, договоры, системы), рёбра — связи между ними («поставляет», «владеет», «зависит от»).

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

Как строится граф

1. Разбиение на фрагменты: документы режутся на чанки, как в обычном RAG.
2. Извлечение сущностей и связей: LLM (или классическая NER-модель с правилами) читает каждый чанк и выдаёт тройки вида (Поставщик A) -[поставляет]-> (Завод B) с кратким описанием и ссылкой на исходный фрагмент.
3. Разрешение сущностей: «ООО Acme», «Acme» и «ACME Ltd.» должны стать одним узлом. Этот шаг определяет качество всего графа.
4. Хранение: граф кладут в графовую БД или в реляционную с таблицами рёбер; чанки и эмбеддинги обычно хранятся рядом.
5. Сводки (опционально): некоторые реализации, например open-source GraphRAG от Microsoft, группируют граф в сообщества тесно связанных сущностей и заранее генерируют сводку по каждому.

Результат извлечения может выглядеть так:

{
  "entities": [
    {"name": "Acme", "type": "company"},
    {"name": "Plant B", "type": "facility"}
  ],
  "relations": [
    {"source": "Acme", "target": "Plant B", "type": "supplies", "chunk_id": "doc12#4"}
  ]
}

Как работает поиск

Есть два основных режима:

• Локальный поиск: найти сущности из вопроса, взять соседей на один-два шага, добавить связанные чанки и отправить всё в LLM. Подходит для вопросов «Какие поставщики завода B работают и с заводом C?»
• Глобальный поиск: использовать сводки сообществ для вопросов обо всём корпусе, например «Какие основные риски упоминаются во всех аудиторских отчётах?» Векторный RAG здесь слаб, потому что ответа нет ни в одном отдельном чанке.

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

Когда поиск по графу лучше векторного RAG

Если вопросы в основном вида «найди абзац, где сказано X», лучше выбрать векторный RAG с хорошим разбиением и реранкингом.

Дополнительные затраты и сложность

• Стоимость индексации: каждый чанк проходит через LLM для извлечения троек, сводки добавляют ещё вызовы. Это многократно дороже расчёта эмбеддингов.
• Обновления: новые документы — это повторное извлечение, повторное разрешение сущностей и иногда пересборка сообществ. Инкрементальные обновления требуют продуманной архитектуры.
• Ошибки извлечения: LLM может придумать связь или пропустить её. Ошибки в графе превращаются в уверенные неверные ответы.
• Разрешение сущностей: дубликаты и ошибочные слияния — самая частая причина плохих результатов.
• Задержка: обход графа и больший контекст могут замедлять ответы.
• Больше компонентов: онтологию нужно поддерживать, графовое хранилище — обслуживать, тестов становится больше.

С чего начать

1. Сделайте сильный базовый векторный RAG и набор реальных тестовых вопросов.
2. Найдите вопросы, на которых он ошибается, и причину. Если дело в связывании фактов или обобщении корпуса, граф может помочь.
3. Задайте небольшую онтологию: ограниченный список типов сущностей и связей, важных для вашей области.
4. Постройте граф на части документов и сравните ответы на том же тестовом наборе.
5. Для критичных областей добавьте ручную проверку извлечённых сущностей.