GraphRAG или векторный RAG: как выбрать стратегию поиска под вопрос
Векторный поиск находит похожий текст, а многошаговым вопросам нужны связи. Разбираемся, когда подходит GraphRAG, гибридный или ключевой поиск и во что обходится граф.
Первая версия RAG-приложения обычно выглядит приятно простой. Обрабатываем документ, режем текст на чанки, считаем эмбеддинг для каждого и складываем векторы в базу. Когда приходит вопрос, достаём ближайшие чанки и отдаём их LLM. Весь процесс на одной схеме:
Documents
│
▼
Text Extraction
│
▼
Chunking
│
▼
Embeddings
│
▼
Vector Database
│
│
User Query ─────────┘
│
▼
Similarity Search
│
▼
Context
│
▼
LLM
│
▼
Answer
Для большой доли вопросов такая схема работает на удивление хорошо. Но корпоративная работа с документами быстро показывает второй тип вопросов, где найти семантически похожий текст недостаточно. Трудность уже не в том, «может ли система найти релевантный текст», а в том, «может ли она найти нужную информацию и понять, как её части связаны между собой». Именно об этом разрыве и пойдёт речь дальше.
Вопрос, который охватывает несколько документов
Возьмём упрощённую корпоративную базу знаний. В одном файле описан инженерный стандарт:
Document A
↓
Engineering Standard
↓
Requirement R1
В другом лежит спецификация проекта:
Document B
↓
Project Specification
↓
Component C1Document C
↓
Validation Rule
↓
Rule V1
Теперь кто-то спрашивает: какое требование относится к компоненту C1, какой стандарт его задаёт и какое правило проверки нужно применить. Ни в одном документе ответа целиком нет. Чтобы ответить правильно, нужно связать несколько фактов:
Component C1
│
│ governed by
▼
Requirement R1
│
│ defined by
▼
Engineering Standard
│
│ validated by
▼
Validation Rule V1
Векторная база не знает, что такая структура вообще существует. Её задача — находить контент, семантически близкий к запросу, и это очень ценная задача. Просто семантическая близость и рассуждение по связям — разные вещи.
Где векторный поиск — правильный инструмент
Прежде чем звать на помощь графы, стоит честно отдать должное векторному поиску. Это один из самых полезных кирпичиков RAG, и типичный поток выглядит так:
User Query
│
▼
Query Embedding
│
▼
Vector Similarity Search
│
▼
Top-K Chunks
│
▼
Context Construction
│
▼
LLM
Если спросить «Какие требования к толщине дорожного покрытия?», а в базе знаний есть раздел ровно об этом, семантический поиск, скорее всего, его и найдёт. Вопрос локальный, разбираться в широкой сети связей не нужно. Векторный поиск подходит лучше всего, когда:
- ответ находится в одном месте
- семантическая близость неплохо заменяет релевантность
- документы можно обрабатывать в основном по отдельности
- для ответа хватает нескольких фрагментов
- простота поиска в приоритете
Так что вопрос «векторный RAG — это хорошо или плохо?» поставлен неверно. Полезнее спросить, какая задача поиска на самом деле перед нами, потому что именно от ответа зависит, хватит ли обычного поиска по сходству или нужно что-то побогаче.
Знания обычно связаны
Корпоративные материалы редко существуют сами по себе. Стандарт задаёт требования, а каждое требование ссылается на что-то ещё:
Standard
│
├── defines → Requirement
│
├── references → Section
│
└── supersedes → Previous Standard
Requirement
│
├── applies_to → Component
├── depends_on → Condition
└── validated_by → RuleComponent
│
├── belongs_to → Project
└── uses → Material
Вопрос, который затрагивает несколько таких связей, требует многошагового поиска. Системе может понадобиться:
- найти компонент
- понять, какое требование к нему относится
- определить стандарт, который его регулирует
- собрать связанные условия
- найти правило проверки
- свести все доказательства вместе
Это совсем другая задача, чем достать ближайший абзац.
Что добавляет граф знаний
Граф знаний явно описывает сущности и связи между ними. Обычный пайплайн представляет знания так:
Document → Chunk → Embedding
Граф добавляет рядом второе представление:
Entity ──relationship──> Entity
Вот как это выглядит на практике:
Standard
│
defines
│
▼
Requirement
│ │
applies_to validated_by
│ │
▼ ▼
Component Rule
│
belongs_to
│
▼
Project
Граф не заменяет документы. Они остаются исходным материалом, а граф становится структурным слоем, который описывает сущности внутри них и их связи.
GraphRAG в одном абзаце
GraphRAG объединяет генерацию с дополненным поиском и представление знаний в виде графа с поиском по нему. Вместо того чтобы опираться только на семантическое сходство, система идёт по связям между сущностями и понятиями и так находит нужную информацию. Концептуально:
User Query
│
▼
Query Understanding
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence / Context
│
▼
LLM
│
▼
Answer
Реализации сильно отличаются. Неизменно одно: при поиске доступны связи, а не только сходство.
Два разных вопроса
Проще всего различить подходы по тому, о чём каждый спрашивает. Векторный поиск спрашивает, грубо говоря, какой контент больше всего похож на запрос. Поиск по графу может спросить, какие сущности связаны с понятиями из запроса и что можно узнать, если пройти по этим связям.
Они вполне могут работать в паре:
Query
│
┌────────┴────────┐
▼ ▼
Semantic Structural
similarity relationships
│ │
▼ ▼
Chunks Entities
│ │
└────────┬────────┘
▼
Evidence
Поэтому GraphRAG — не просто улучшенная векторная база. Это другая стратегия поиска для другого класса задач.
Когда связи окупаются
Явные связи обычно окупаются в нескольких ситуациях.
Многошаговые вопросы. На вопрос вроде «Какой регламент распространяется на эту деталь и какие дополнительные правила проверки к нему прилагаются?» можно ответить, только пройдя по нескольким связям подряд:
Component
↓
Requirement
↓
Regulation
↓
Validation Rule
Области, насыщенные связями. В некоторых сферах связей очень много: нормативные акты, инженерные стандарты, финансовые сущности, научные знания, каталоги товаров, знания об организации и сети зависимостей. Там сами связи несут смысл.
Доказательства разбросаны по файлам. Один документ задаёт требование, другой описывает исключение, третий объясняет проверку. Самое сложное — правильно сшить их вместе.
Вопросы о сущности целиком. Вопрос «Какие требования вообще связаны с этой сущностью?» естественно ложится на поиск, который учитывает связи.
Цена графа
Легко услышать про графы знаний и решить, что векторный RAG устарел, а GraphRAG лучше. Для инженера это неправильный вывод. Граф приносит дополнительную сложность: этапов, которые нужно построить и поддерживать, становится больше:
Document Processing
↓
Entity Extraction
↓
Relationship Extraction
↓
Entity Resolution
↓
Graph Construction
↓
Graph Storage
↓
Graph Retrieval
↓
Context Construction
Каждый этап — новое место для сбоя, а ошибки накапливаются по мере движения по пайплайну. Что, если сущности извлечены неверно? Что, если у двух разных сущностей одинаковое имя? Что, если связь выведена ошибочно, граф получился неполным или его поддержка дорожает по мере изменения документов? Это инженерные проблемы, а не только проблемы ИИ.
Граф нужно построить
Граф не появляется сам. Его построение — часть работы, и упрощённый пайплайн выглядит так:
Documents
│
▼
Document Processing
│
▼
Text / Structure
│
▼
Entity Extraction
│
▼
Relationship Extraction
│
▼
Entity Resolution
│
▼
Knowledge Graph
Допустим, в исходном файле есть фраза о том, что R-102 — правило для детали моста B-17 всякий раз, когда выполняется C-4. В виде структуры это может выглядеть так:
(R-102)
│
applies_to
↓
(B-17)
(R-102)
│
requires_condition
↓
(C-4)
Дальше поиск может использовать эти связи. Но если при извлечении по ошибке получится
R-102 → applies_to → B-71
граф понесёт неверную информацию дальше. Поэтому качество извлечения знаний становится частью качества поиска.
Векторы и граф вместе
В реальных системах часто не нужно выбирать что-то одно. Схема может сочетать векторы и граф:
Query
│
▼
Query Analysis
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence Fusion
│
▼
Context Building
│
▼
LLM
Векторный поиск находит семантически релевантные фрагменты, а поиск по графу добавляет контекст связей. Вместе они дают более полную доказательную базу, и больше всего это помогает, когда вопрос совмещает «найди нужную информацию» и «пойми, как она связана».
Ключевые слова, векторы, гибрид и граф
Переход от поиска по ключевым словам к векторному поиску, а затем к GraphRAG не означает, что каждый следующий шаг отменяет предыдущий. Каждый метод закрывает свою потребность:
Keyword Search
│
└── Exact terms / identifiers
Vector Search
│
└── Semantic similarityHybrid Search
│
└── Exact + semantic relevanceReranking
│
└── Improve ordering of candidatesGraph Retrieval
│
└── Relationship-aware retrieval
Продакшен-система может сочетать несколько из них. Инженерная задача — решить, какие сигналы важны для конкретной проблемы.
Начните с ответа
Вместо того чтобы начинать с вопроса «а не взять ли GraphRAG?», начните с того, что нужно найти для правильного ответа.
Если нужен один явно релевантный фрагмент, может хватить такого:
Query
↓
Vector Search
↓
Passage
Если важны точные идентификаторы, может помочь такое:
Query
↓
Keyword / Metadata Search
Если нужно семантическое понимание, пригодится такое:
Query
↓
Vector Search
Если требуется несколько сигналов поиска, лучше подойдёт такое:
Query
↓
Hybrid Search
↓
Reranking
Если нужно проходить по связям, становится интересен поиск по графу:
Query
↓
Entity Identification
↓
Graph Retrieval
↓
Related Evidence
А если сама стратегия поиска должна меняться от вопроса к вопросу, может быть оправдан агентный workflow:
Query
↓
Decision / Planning
↓
Choose retrieval strategy
↓
Retrieve
↓
Evaluate evidence
↓
Retrieve again if necessary
↓
Answer
С графом это уже системная инженерия
Без графа система выглядит так:
Application
↓
Vector Database
↓
LLM
С графом она превращается во что-то вроде этого:
Application
│
▼
Query Understanding
│
┌─────────┴─────────┐
▼ ▼
Vector Store Graph Store
│ │
└─────────┬─────────┘
▼
Retrieval Layer
│
▼
Context Builder
│
▼
LLM
На команду сваливается новый список забот: как строится граф, как держать его в синхроне с документами, как его индексировать, какая задержка у запросов, как обеспечить согласованность, насколько граф на самом деле хорош, как разрешать дубли сущностей, где его хранить, как мониторить и как оценивать. В этот момент GraphRAG перестаёт быть функцией фреймворка и становится задачей системной инженерии.
Переосмысляем, что такое RAG
Работа с документами меняет взгляд на RAG. Сначала кажется, что это просто найти правильные чанки и передать их LLM. Более широкий взгляд — спроектировать такое представление знаний, которое позволит системе достать доказательства, нужные для ответа. Иногда это чанки и эмбеддинги. Иногда помогают метаданные, гибридный поиск или связи, достаточно важные, чтобы оправдать граф. А иногда система должна сама на ходу решать, как искать. Архитектура должна следовать информационным потребностям задачи, а не популярности технологии.
Простая модель выбора
Если свести всё к ментальной модели, выбор выглядит так:
What does the question require?
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Exact terms Semantic meaning Relationships
│ │ │
▼ ▼ ▼
Keyword/ Vector Graph
Metadata Search Retrieval
│ │ │
└────────────────┼────────────────┘
▼
Hybrid System
│
▼
Reranking
│
▼
Context Building
│
▼
LLM
Цель — не самая изощрённая архитектура, а самая простая из тех, что надёжно решают задачу поиска.
Векторный поиск — мощный инструмент, но сходство не равно пониманию связей. Когда вопросы становятся многошаговыми, междокументными, сосредоточенными на сущностях или насыщенными связями, явное моделирование знаний добавляет ещё один сильный механизм поиска. GraphRAG интересен не тем, что побеждает RAG, а тем, что разные вопросы требуют разных стратегий поиска. Сначала разберитесь в вопросе и в структуре знаний, а технологию выбирайте потом.