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, а тим, що різні запитання потребують різних стратегій пошуку. Спершу розберіться в запитанні та структурі знань, а технологію обирайте потім.