Graph RAG: чому звичайний пошук ламається на довгих ланцюжках питань
Звичайний пошук за документами ріже корпус на фрагменти, рахує близькість кожного до формулювання питання й віддає верхні кілька в контекст моделі. Схема працює, поки відповідь лежить у межах одного абзацу.
Щойно питання вимагає пройти три-чотири зв’язки між сутностями, близькість перестає бути мірою релевантності: у питанні сформульовано підсумок, а кожна ланка ланцюжка говорить про своє.
Звідси два класи провалів у відповідях. Перший — фрагмент із потрібною ланкою не потрапляє у верхню частину видачі: він не схожий на питання ні лексично, ні за змістом, бо описує проміжну подію або властивість.
Другий — питання збиральне («що спільного в цих випадків», «які напрями перетинаються»), і вибірка з кількох абзаців не покриває корпус. Модель відповідає частково або добудовує зв’язок сама — переконливо й повз факт.
Graph RAG змінює одиницю пошуку: індексуються не фрагменти, а сутності та відношення між ними. Під час підготовки будується граф знань — витягуються згадки, нормалізуються дублікати, задаються типи зв’язків.
Багатокроковий пошук іде за структурою: знаходяться точки входу, потім два-чотири кроки за ребрами, і в контекст потрапляє зв’язний підграф разом із початковими цитатами. Зв’язність фактів стає перевірюваною, а не вгаданою за текстовою близькістю.
Далі розбираємо, з яких рішень складається така система і де проходять її межі.
Що дає граф знань: точність і стійкість відповідей
Граф знань зберігає сутності та зв’язки окремо від текстових фрагментів. Пошук іде не за збігом формулювань, а за ребрами: система переходить від факту до факту й збирає відповідь на кілька кроків уперед. У Graph RAG цей маршрут стає частиною видачі — його видно й можна перевірити.
Частка правильних відповідей на складених питаннях
Векторний пошук відповідає впевнено, поки потрібний факт лежить в одному фрагменті. Щойно відповідь збирається з трьох-чотирьох джерел, частка правильних відповідей падає: частина зв’язків губиться між чанками.
Обхід графа тримає ці зв’язки, і на багатокрокових питаннях точність зростає кратно, а не на відсотки.
Перевірюваний ланцюжок міркування
Система повертає не лише відповідь, а й шлях із чотирьох-шести переходів. Інженер бачить, на якому ребрі міркування звернуло, і править не модель, а сам граф: додає зв’язок або уточнює сутність. Помилку вдається зловити до того, як її побачить користувач.
Обсяг контексту на один запит
Звичайний пошук підкладає в запит півтора десятка фрагментів «про всяк випадок» — модель розмивається на шумі. Граф віддає три-п’ять вузлів, пов’язаних саме з ланцюжком, і обсяг контексту скорочується в рази за вищої якості відповідей. Заодно дешевшає сам виклик моделі: менше вхідних даних — стабільніший час відповіді.
Стійкість видачі
Переформулювання питання не змінює набір вузлів: маршрут іде за зв’язками, а не за словами. Частка запитів, де відповідь «пливе» при зміні формулювання, знижується — результат перестає залежати від того, як користувач запитав.
Способи пов’язувати факти: граф, вектори чи гібрид
Три режими відрізняються тим, що саме вважається зв’язком між фактами. Векторний пошук спирається на близькість смислів: два фрагменти потрапляють в одну видачу, навіть якщо в них немає спільних слів.
Графова зв’язність — це явні ребра між сутностями, тому відповідь збирається обходом, а не підбором схожих шматків. Гібридний пошук бере кандидатів з обох джерел і зводить їх одним ранжуванням.
Як режими поводяться на реальних даних
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Векторний пошук | Запити формулюються вільно, відповідь лежить в одному фрагменті | Не зводить факти з різних місць, промахується на перефразуванні |
| Графова зв’язність | Відповідь виводиться з ланцюжка «сутність — відношення — сутність»: регламенти, договори, довідники | Потребує витягування й нормалізації сутностей, помилки в ребрах дорого виправляти |
| Гібридний пошук | Змішані запити, де потрібна і близькість формулювань, і жорсткі зв’язки | Два індекси синхронізуються під час кожного завантаження, потрібен етап об’єднання |
Що визначає вибір схеми
Дивимося на характер даних і тип питання. Якщо відповідь збирається з кількох документів і важливий порядок зв’язків, самої близькості мало — потрібен граф. Якщо запити живуть формулюваннями користувача, граф без вектора дає промахи на перефразуванні.
На практиці вибір схеми рідко буває строгим «або-або»: гібрид закриває обидва класи запитів, але платить за це синхронізацією індексів під час кожного оновлення даних.
Як ми будуємо граф знань: етапи інженерної роботи
Граф знань не збирається одним проходом по документах: помилка в схемі на старті обходиться дорожче, ніж місяць роботи, — перерозмічати доводиться всі зв’язки.
Тому етапи впровадження йдуть від інвентаризації джерел до замірів якості, і лише після цього граф виходить в експлуатацію.
- Аудит джерел. Зводимо регламенти, тікети, базу знань і таблиці в одну карту: обсяг, дублі, права доступу, частота змін. Тут же визначаємо поля, за якими сутності зшиваються між собою.
- Проєктування схеми. Фіксуємо типи вузлів і ребер, обов’язкові атрибути, напрямок зв’язків і правила злиття дублів. Схема затверджується до першого завантаження: інакше витягування сутностей дає несумісні типи.
- Витягування сутностей і зв’язків. Правила закривають передбачувані поля, мовна модель — формулювання в тексті. Після розв’язання сутностей один реальний об’єкт отримує один вузол, а не три схожі.
- Складання графа. Завантажуємо вузли й ребра у сховище, додаємо ієрархію розділів, ваги зв’язків і зворотні посилання на вихідний фрагмент — за ними перевіряється кожна цитата.
- Контрольний набір. Беремо реальні питання співробітників з еталонними ланцюжками відповідей. На них вимірюємо повноту витягування й точність багатокрокових запитів, окремо — на частині, невидимій під час налаштування.
- Передача команді. Віддаємо схему, регламент оновлення, переіндексацію під час зміни джерела й панель якості: частка коректних ланцюжків і час відповіді.
Критерій приймання — не факт складання графа, а стійкість метрик на контрольному наборі: якщо точність багатокрокових відповідей падає при додаванні нових документів, схему або витягування повертаємо на доопрацювання.
Схема графа, політики доступу й передача документації
Проєкт закінчується не вдалим демо-запитом, а станом, у якому ваша команда сама підключає нові джерела, править зв’язки й не ламає при цьому доступи.
Тому приймання йде за переліком артефактів: кожен лежить поруч із кодом, версіонується разом із ним і перевіряється на стенді до передачі.
- Схема графа — типи вузлів і ребер, обов’язкові атрибути, правила злиття дублів сутностей, а також що зв’язується автоматично, а що підтверджує людина.
- Правила збагачення — які джерела обходять і з якою періодичністю, як розв’язується конфлікт між ними й за якою ознакою запис вважається достовірнішим.
- Налаштування витягування й зв’язування — розмір фрагмента, що розбирається, модель представлення тексту, поріг упевненості для ребра, ваги типів зв’язків. З ними відповідь пошуку відтворюється, а не «виходить по-різному».
- Політики доступу — ролі, обмеження на читання окремих вузлів і цілих підграфів, маскування полів у відповіді, журнал запитів із суб’єктом і часом звернення.
- Регламент оновлення — що перезбирається частинами, що потребує повного перерахунку графа, хто запускає процес і як перевіряється відповідність версії зв’язків версії джерел.
- Набір оцінювальних питань — багатокрокові сценарії з очікуваними шляхами в графі; прогін за ними показує просідання точності відразу після правок, а не через скарги користувачів.
- Інструкція з експлуатації — відновлення зв’язків після збою завантаження, відкат на попередню версію графа, типові помилки й порядок ескалації.
- Документація рішення — архітектурна схема, опис контурів і журнал ухвалених рішень: чому структура зв’язків саме така й що змінювалося по ходу.
Такий комплект дає змогу передати супровід вашій команді або повернутися до розвитку через місяці без розбору по коду.
Кейс: як зросла точність відповідей на зв’язних питаннях
Проєкт вівся для постачальника промислового обладнання: близько 40 000 документів — регламенти, керівництва, протоколи випробувань.
Пілотні питання користувачів улаштовані так, що відповідь збирається з трьох-чотирьох джерел: спочатку знайти вузол виробу, потім вийти на модифікацію, потім на допуски й на регламент обслуговування.
На старті пошук працював за векторною близькістю фрагментів — на одиночних питаннях це давало прийнятний результат, на зв’язних розсипалося.
Що показали заміри до
На еталонному наборі з 300 зв’язних питань частка правильних відповідей становила 52%. У 41% випадків губився щонайменше один зв’язок, і відповідь виглядала правдоподібно, але не містила потрібного пункту — найдорожча категорія помилок, бо її помічав лише експерт-предметник. Складання видачі займало до 3,1 с, а ручна перевірка відповіді забирала в інженера кілька хвилин.
Що змінили
Сутності та зв’язки винесли в граф знань на Neo4j, текстові фрагменти залишили атрибутами вузлів. На запит будуємо шлях за зв’язками на два-три кроки й лише потім ранжуємо кандидатів, тому пропущена ланка ланцюга перестає бути невидимою для пошуку.
Кожній відповіді додали обов’язкові посилання на вузли й документи, з яких вона зібрана, — з’явилася простежуваність.
Що стало на тому самому наборі
Частка правильних відповідей зросла до 88%, втрати зв’язків скоротилися до 4%, час підготовки видачі — до 0,9 с. Суцільну ручну перевірку замінили вибірковою: інженер дивиться одну відповідь із десяти замість кожної.
На розширеному наборі питань метрики тримаються — граф поповнюється разом із документацією, а не деградує в міру зростання бази.
Чим Graph RAG відрізняється від звичайного векторного пошуку
Звичайний векторний пошук ранжує фрагменти за близькістю до запиту: система знаходить шматки тексту, чиї векторні представлення найближчі до питання, і віддає їх моделі.
Графовий шар відповідає на інше питання — не «що схоже», а «що з чим пов’язано»: сутності та відношення з документів виносяться в явні зв’язки, і пошук іде за ними.
Питання «хто відповідає за цей модуль і які обмеження він накладає на сусідні системи» розкладеться в ланцюжок: модуль → відповідальний → суміжні системи → обмеження. Векторний пошук витягне фрагменти, близькі до формулювання, і часто це різні документи без зв’язку між собою. Граф проходить ланцюжок за ребрами, і у відповіді видно шлях виведення — його можна перевірити.
Графовий шар надлишковий, коли питання локальні й закриваються одним документом, коли даних мало й близькість дає прийнятну точність, коли зв’язки між сутностями в предметній галузі нестабільні. Тоді підтримка зв’язків не окупається, а векторний пошук працює швидше й простіше в супроводі.
Обмеження в підходу теж є: якість графа не вища за якість витягування сутностей, схема потребує супроводу при зміні предметної галузі, а нові дані потрібно пропускати через збагачення зв’язками. Тому частіше беруть гібрид — векторний відбір кандидатів і обхід графа поверх них.
Вибір робимо за замірами на реальних запитах: набір типових питань, порівняння повноти відповідей, частка випадків, де ланцюжок фактів не збирається з окремих фрагментів. Neo4j і подібні сховища підключаємо лише тоді, коли заміри підтверджують, що зв’язність справді потрібна.
Технічні сумніви: дані, якість, супровід
Сумніви щодо Graph RAG зводяться до чотирьох речей: суперечливі джерела, оновлення графа, закритий контур і приймання результату. Нижче — як кожне з них вирішується в проєкті, а не відкладається на етап супроводу.
Що якщо джерела суперечать одне одному?
«Правильний» документ граф не вибирає — він зберігає провенанс: у кожного факту залишається джерело, дата й версія. Конфліктні твердження лягають окремими зв’язками, а пріоритет задає політика: свіжість, статус джерела, підрозділ-власник. У відповіді видно, чим він підтверджений і де розходження.
Як оновлюється граф при правках у документах?
Повна перезбірка на кожній правці не потрібна: працює інкрементальна переіндексація — змінений фрагмент розбирається заново, заторкнуті вузли й зв’язки перезаписуються, решта залишається на місці. Повна перезбірка йде за регламентом, наприклад після міграції сховища.
Чи можна розгорнути рішення в закритому контурі?
Так. Моделі, індекс і граф розміщуються на вашій інфраструктурі, зовнішні виклики закриває політика мережі, доступи роздаються за ролями. Логи запитів залишаються всередині контуру: для чутливих даних це умова, а не опція.
За якими критеріями приймається якість?
Приймання йде на наборі питань із ваших сценаріїв: окремо прості, окремо ті, що потребують обходу кількох зв’язків. Рахуємо частку правильних відповідей, точність посилань на джерело й повноту обходу, фіксуємо класи помилок.
Якщо метрики не досягнуті, доопрацьовуємо розбір документів і схему графа, а не підганяємо відповіді.
Обговоримо задачу й повернемося з планом робіт
Щоб повернутися з планом робіт, а не із загальними обіцянками, на старті потрібен мінімум контексту з вашого боку. Graph RAG будується навколо конкретного корпусу й конкретних питань — без них граф знань виходить охайним, але марним у роботі.
Що потрібно від вас на першому розборі задачі:
- 20–30 реальних питань користувачів, включно зі складеними, де відповідь збирається з кількох документів.
- Корпус джерел як є: регламенти, договори, каталоги, технічна документація, листування.
- Перелік сутностей і зв’язків, важливих у предметній галузі: клієнт, об’єкт, договір, версія документа.
- Опис того, як пошук помиляється зараз: де губиться зв’язок між документами й що вважається неправильною відповіддю.
- Обмеження щодо контуру: де розгортаємо рішення, які системи віддають дані й за якими доступами.
- Бажаний горизонт запуску й те, хто з вашого боку приймає результат.
За підсумками розбору надсилаємо план етапів з орієнтовними строками: підготовка корпусу й розмітка зв’язків, складання графа, зв’язка графа з пошуком, налаштування генерації відповіді, приймання на вашому наборі питань.
До кожного етапу зазначаємо, що вважається готовим результатом і які перевірки він проходить — частка правильних складених відповідей, наявність посилання на джерело, поведінка системи там, де даних у корпусі немає.
Опишіть задачу у вільній формі, навіть без готового набору питань — уточнимо решту в діалозі й повернемося з оцінкою строків і планом робіт.
