GraphRAG: коли знання як граф перемагає самі вектори

Компанія, що виробляє технічну документацію для десятка продуктових ліній, стикається з проблемою: асистент RAG чудово цитує фрагменти, але не може відповісти на запитання «які компоненти зі старої лінійки X сумісні з новою лінійкою Y і які сертифікати охоплює ця комбінація?». Це багатоетапне запитання, яке вимагає об'єднання інформації з трьох різних документів. Семантичний пошук повертає найкраще підібрані фрагменти окремо, але не будує між ними містків.

Саме це і є ніша GraphRAG.

Граф знань — це структура даних, що складається з вузлів (сутностей) і ребер (зв'язків). У корпоративному контексті: вузли — це продукти, процеси, підрозділи, регуляції, клієнти; ребра — це зв'язки типу «вимагає», «замінює», «підпорядковується», «виробляється».

Побудова графа з документів проходить у три етапи.

Екстракція сутностей і зв'язків. Мовна модель читає кожен фрагмент документа і витягує пари (сутність, зв'язок, сутність). Наприклад, з речення «Компонент A-7 вимагає сертифіката CE перед впровадженням в ЄС» модель витягує вузли A-7 і CE та ребро «вимагає». Це найдорожча частина: при 10 000 фрагментів і локальній моделі рахуйте від кількох десятків до кількох сотень хвилин обробки.

Дедедуплікація та нормалізація. Той самий продукт може з'являтися як «A-7», «компонент A7», «модуль A-7 rev.2». Без нормалізації граф фрагментується замість об'єднувати знання. Тут потрібне рішення: словник синонімів, написаний вручну доменними експертами, або додатковий крок LLM, що розпізнає аліаси. Обидва варіанти мають свої витрати.

Індекс + векторна база. У повному GraphRAG ви не позбавляєтеся ембедінгів: зберігаєте паралельно реляційний граф (наприклад, Neo4j, Memgraph або легший NetworkX для менших корпусів) та векторний індекс для пошуку точки входу. Запит спочатку потрапляє до вектора, щоб знайти близькі сутності, а потім до графа, щоб відстежити зв'язки.

Векторний пошук вимірює семантичну подібність. Граф вимірює зв'язки. Це різні запитання.

Багатоетапні запитання (multi-hop). «Які регуляції стосуються продукту X, який ми продаємо в сектор Y?» Вектор повертає документи, тематично близькі до запиту. Граф може пройти шлях: продукт X → сертифікат CE → директива машинобудівна → стаття 12 → обов'язок аудиту. Кожен крок — це ребро в графі, не обов'язково явно присутнє в одному фрагменті документа.

Запити, орієнтовані на сутності. «Перелічи всіх постачальників компонентів, що використовуються в продуктовій лінійці Z.» Вектор перегляне фрагменти і може пропустити постачальників, згаданих побічно. Граф з ребрами «постачальник-компонент-лінійка» відповість повно, за умови, що граф є повним.

Узгодженість знань між документами. Коли та сама сутність з'являється в документах з різних років і її атрибути змінилися, граф допомагає відстежувати історію та версії. Класичний RAG може повернути суперечливі фрагменти без жодного сигналу про суперечність.

Експланація та слід прийняття рішення. Відповідь, згенерована з графа, може показати буквальний шлях вузлів: «Ця відповідь випливає зі зв'язків A→B→C». Це важливо для систем, які AI Act класифікує як високий ризик і які повинні відповідати вимозі пояснюваності.

Для більшості корпоративних впроваджень RAG сам векторний індекс з гібридним пошуком достатній. Граф має сенс, коли:

• корпус має чітку структуру сутність-зв'язок-сутність, яку можна осмислено екстрагувати (документація продуктів, реєстри правові, бази доменних знань);
• запитання користувачів дійсно вимагають об'єднання інформації з багатьох джерел через спільні вузли;
• у вас є ресурси на супровід графа, бо кожне оновлення документа вимагає реекстракції або латання ребер.

Не впроваджуйте GraphRAG, коли:

• корпус — це розрізнені описові документи без чітких сутностей (стратегічні звіти, нотатки з зустрічей, кореспонденція);
• запитання переважно описові та концептуальні (тут семантичний пошук справляється добре);
• у вас менше кількох тисяч документів і класичний RAG дає recall вище 0,85 на golden set;
• бюджет токенів і час екстракції обмежені, а термін впровадження короткий.

Ми в Cashcrown за замовчуванням рекомендуємо починати з класичного RAG з гібридним пошуком і вимірювати recall. GraphRAG розглядається тоді, коли дані вимірювань вказують на конкретний клас запитів, які вектор не обробляє.

Екстракція графа з 50 000 фрагментів при локальній моделі (наприклад, llama3.1:70b на Ollama) реально займає 8-24 години і вимагає підтримки пам'яті GPU. При комерційному API це кілька десятків до кількох сотень доларів за одноразову екстракцію, плюс подібні витрати при кожному великому оновленні корпусу. Цифри сильно залежать від довжини фрагментів і складності екстракційного промпту: наводимо діапазони, а не гарантії.

Типовий стек GraphRAG у 2026 виглядає так:

Крок 1: чанкінг та екстракція. Документи проходять через чанкінг до екстракційної моделі. Промпт змушує модель повертати структурований JSON з парами (суб'єкт, предикат, об'єкт). Варто використовувати structured output з валідацією JSON Schema, бо сирий текст моделі при екстракції зв'язків буває неузгодженим.

Крок 2: побудова графа. Екстракти потрапляють до графової бази або простої структури в пам'яті. Для менших корпусів (до кількох тисяч вузлів) NetworkX у Python достатньо. Для більших і при потребі запитів Cypher варто розглянути Neo4j або Memgraph з self-hosting.

Крок 3: retrieval. Запит користувача потрапляє до векторного індексу (точка входу в графі). З top-k вузлів векторного пошуку система розширює сусідство в графі: отримує вузли на відстані 1-2 ребер. Цей набір потрапляє до контексту LLM.

Крок 4: генерація з цитуванням шляху. Модель генерує відповідь, наводячи шлях вузлів як джерело. Це не технічна вимога, але сильно підвищує довіру користувачів і відповідає вимогам пояснюваності для систем, що підпадають під AI Act.

Крок 5: observability. Вимірюйте окремо recall векторних запитів (скільки потраплянь у top-5) і recall графових шляхів (чи багатоетапні запитання дають повні відповіді). Без розділення цих метрик ви не знаєте, який компонент потребує оптимізації.

Подібний шаблон ми описуємо в контексті вибору векторної бази в статті як вибрати базу векторну та при обговоренні реранкінгу фрагментів у реранкінгу як шарі якості RAG.

Екстракція графа має три витратні пастки, про які рідко згадують технічні статті.

Пастка 1: якість екстракції падає при документах низької якості. Сканування OCR, документи з таблицями, пунктирні списки без контексту речення дають хаотичні зв'язки. Перед екстракцією графа варто подбати про якість чанкінгу, про що ми пишемо в статті про підготовку даних під RAG.

Пастка 2: граф застаріває після кожного оновлення документів. При класичному RAG ви оновлюєте ембедінг фрагмента, що займає секунди. При GraphRAG потрібно реекстрагувати зв'язки з цього фрагмента і оновити ребра в графі. Якщо документи змінюються часто, витрати на супровід швидко зростають. Інкрементальний підхід (оновлювати лише змінені документи) працює, але вимагає ведення версій.

Пастка 3: граф може увічнювати помилки. Якщо екстракційна модель неправильно інтерпретує зв'язок, цей зв'язок залишається в графі і впливає на відповіді до моменту ручної корекції. Класичний RAG може неправильно вибрати фрагмент, але помилка не є структурно увічненою. При GraphRAG варто періодично проводити аудит вибірки ребер. Це робота людини, а не автоматична.

Ні. Це доповнення, а не заміна. У більшості корпоративних впроваджень векторний RAG з гібридним пошуком покриває 80-90 відсотків випадків використання. GraphRAG додається як додатковий шар для конкретного класу багатоетапних запитів. Впровадження, які замінили вектор самим графом, зазвичай поверталися до гібридного підходу через кілька тижнів.

Microsoft випустив open-source бібліотеку GraphRAG (Python), яка автоматизує екстракцію сутностей і побудову графа з текстових файлів. LangChain і LlamaIndex мають інтеграції з графовими базами (Neo4j, Memgraph). Для самостійного впровадження без зовнішніх API достатньо Ollama з локальною моделлю для екстракції та NetworkX для зберігання графа при корпусах до кількох десятків тисяч вузлів. Для більших масивів спеціалізована графова база з інтерфейсом Cypher суттєво прискорює запити.

Діапазон широкий і залежить від моделі та довжини документів. При локальній моделі (llama3.1:70b на Ollama): 8-24 години екстракції, нульова вартість токенів. При комерційному API (GPT-4o або Claude Sonnet): 50-300 доларів одноразово за екстракцію, плюс подібні витрати при оновленнях. Додайте вартість нормалізації сутностей (зазвичай 1-2 дні роботи доменного експерта при першій екстракції) і заплануйте час на аудит вибірки ребер. Наводимо діапазони на основі типових проектів, а не конкретну оцінку без аналізу даних.

Шлях вузлів як слід прийняття рішення полегшує виконання вимоги пояснюваності (ст. 13 AI Act). Однак цього недостатньо: потрібна також документація системи, реєстр тестових випадків і human-gate при незворотних рішеннях. GraphRAG покращує пояснюваність механізму retrieval, але не звільняє від обов'язків compliance з боку впроваджувача.

Коли корпус має складну онтологію (багато типів сутностей і зв'язків), документи низької структурної якості (скани, legacy PDF), або термін впровадження короткий. Екстракція зв'язків вимагає кількох ітерацій prompt-engineering, пристосованого до домену, перевірки вибірки та корекції. Ми в Cashcrown оцінюємо технічну готовність і дані перед рекомендацією архітектури, бо корпоративний RAG, побудований на поганій екстракції графа, дає гірші результати, ніж простий вектор з семантичним пошуком.