RAG чи граф знань? 2 160 оцінених відповідей та вплив моделі

Чому взагалі потрібно вимірювати

Дискусії щодо корпоративного технічного асистента зазвичай застрягають на одному й тому ж рівні. Одна сторона виступає за використання RAG, інша — за граф знань; обидві сторони мають переконливі аргументи, але жодна не наводить цифр. Контрольоване експериментування може надати такі дані: два підходи, три родини моделей, три повторення та 120 запитань із правильними відповідями, що дає 2 160 оцінених відповідей. Кожну відповідь оцінювали за допомогою детерміністичного показника та групою з трьох експертів.

Результати є менш задовільними, ніж хотілося б. Абсолютного переможця немає, напрямок ефекту змінюється залежно від моделі, а змінна з найбільшим ефектом — це не жодна з стратегій. Це модель, яка лежить в основі системи.

Для швидкого ознайомлення:

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

Спочатку йдуть обмеження, адже саме вони визначають, чи варто читати решту.

Що охоплює та що не охоплює дослідження

Воно вимірює, яка стратегія пошуку дає більше правильних, повніших та більш простежуваних відповідей щодо екосистеми мікросервісів, при цьому модель генерації залишається незмінною під час кожного порівняння.

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

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

Проблема

Компанія перейшла на мікросервіси. Там, де раніше вся кодова база поміщалася в одному проекті, тепер існує десятки сервісів, контрактів, подій та баз даних. Знання розкидані по документах типу README, внутрішньому каталозі, панелі керування операціями та у трьох осіб, які знають їх напам’ять. Щоденні запитання є буденними та дорогими у вирішенні: який додаток зберігає персональні дані, від чого залежить сервіс X, чи вже існує щось подібне та чи можна це використати знову? Сьогодні відповідь полягає у тому, щоб запитати когось або прочитати документацію, яка може бути застарілою, а справжня витрата — це не час пошуку, а технічне рішення, прийняте на основі старої інформації.

Бесідний асистент міг би вирішити проблеми з доступом, за умови, що він спеціалізується на цій галузі, а література пропонує два підходи.

Неструктуроване пошукове забезпечення (RAG) розділяє документацію, індексує її у векторному сховищі, отримує уривки, найбільш схожі на запит, та вставляє їх у запрошення до обробки інформації. Цей термін був запропонований Льюїсом та його колегами у 2020 році, а Гао та його колеги оглядають останні досягнення в цій галузі. Його легко підтримувати, і він адаптується до змін без необхідності повторної підготовки моделі, проте є неефективним, коли для відповіді потрібні міркування на основі чітких взаємозв’язків.

Структуроване пошукове забезпечення (граф знань) моделює екосистему у вигляді вузлів та ребер з певними типами: сервіс, команда, подія, база даних, залежність. Запити є детермінованими та простими для відстеження, хоча моделювання та керування графом є складними та дорогими. Огляд графів знань, підготовлений Хоганом та його колегами, є стандартним джерелом інформації.

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

Дизайн

Найважливіше рішення приймається ще до написання будь-якого коду: лише шар знань може відрізнятися. Без цього правила порівнюються дві реалізації, а не дві стратегії. Будь-яка різниця у форматі запиту чи результату псує результат у спосіб, який пізніше неможливо відокремити, тому багато неформальних тестів RAG у кінцевому підсумку вимірюють навички того, хто написав запит.

Обидва підходи повертають абсолютно однаковий контракт відповіді: запитання, підхід, відповідь, джерела, отриманий контекст, час відгуку та орієнтовна вартість. Це забезпечує те, що код оцінки, API та інтерфейс залишаються незалежними від обраного підходу.

Для тестування була потрібна реалістична, публікувана та відтворювана екосистема, і використання реальної екосистеми роботодавця було неможливим. Тож для цілей тестування було створено CreditXPTO — фінтех-компанію з послугами особистого кредитування, якої насправді не існує:

Синтетичний підхід забезпечує три переваги. Контент контролюється, відома правильна відповідь на кожне запитання, і будь-хто може повторно виконати роботу без доступу до внутрішніх систем. Ціною є зовнішня достовірність – основна обмеженість, про яку йдеться наприкінці.

У обох форматах представлення існує однакові знання, а еквівалентність забезпечується правилами верифікації, які працюють у рамках безперервної інтеграції: пошкоджена посилання робить набір даних недійсним. Інакше одна зі сторін могла б таємно знати більше, ніж інша. 120 запитань позначені за категорією (фактичні, пояснювальні, щодо впливу, взаємозв’язків, для відкриття нового, неоднозначні), за рівнем складності та типом знань; кожне з них має очікувану відповідь та джерела.

У частині RAG використовуються фрагменти довжиною 512 токенів із перекриттям 50 токенів та параметром top-k рівним 5. Ембеддинги отримуються з моделі BAAI/bge-small-en-v1.5, яка працює локально, а як сховище векторів використовується Qdrant. Процес щільного пошуку відповідає схемі, запропонованій Карпухіним та його колегами (DPR), ембеддинги речень походять від Sentence-BERT, а родина моделей BGE описана в C-Pack.

У частині графа в пам’яті використовується бібліотека NetworkX, створена безпосередньо з вихідних файлів, тому вона завжди узгоджується з даними. Порівняння ентитетів здійснюється фаззі-методом із порогом 70/100, а пошук відбувається у межах одного сусідства.

Оцінювання

Оцінка відбувається на двох рівнях. Перший рівень є евристичним: лексична схожість, наявність ключових ентитетів та охоплення джерела. Він є дешевим, детермінованим та відтворюваним, але водночас поверхневим, оскільки карає парафразування. Це відома слабкість метрик перекриття n-грамів, і саме тому існують семантичні альтернативи, такі як BERTScore.

Другий рівень передбачає групу з трьох суддів-LLM, по одному від кожної родини моделей, які оцінюють правильність, повноту, обґрунтованість та зрозумілість у межах від 0 до 3. Парадигму використання LLM як судді була узагальнена Чженгом та його колегами за допомогою MT-Bench.

Є одна важлива деталь: основна метрика є міжсімейною. Для кожної відповіді суддя з власної сім’ї генератора не береться до уваги під час розрахунку. Моделі розпізнають власний текст та оцінюють його вище, а Panickssery та співавтори (2024) пов’язують цю самопреференцію з таким саморозпізнаванням. Єдиний спосіб нейтралізувати це — структурними заходами, а не шляхом прохання про неупередженість у запиті.

Значущість визначається за допомогою парного тесту Макнемара, оскільки обидві стратегії відповідають на одні й ті самі запитання. Інтервали обчислюються за допомогою методу bootstrap із 5 000 повторних вибірок, а згоду суддів оцінюється за допомогою коефіцієнта Каппи Коена.

Результати

У першій таблиці наведена строга точність, де враховуються лише повністю правильні відповіді; у кожній клітинці n = 360:

Важливими є два показники.

По-перше, результати змінюються залежно від моделі. RAG має перевагу з двома генераторами, а графовий підхід — з третім, і лише ця остання різниця є значущою. Якби експеримент було проведено з однією моделлю, як це робиться у більшості тестів, це призвело б до впевненого, але хибного висновку разом із інтервалом впевненості. У результатах не було б жодних ознак цього.

По-друге, різниця між моделями перевищує різницю між підходами. Перехід від claude-sonnet-4-6 до gpt-5.5 допомагає більше, ніж зміна стратегії всередині однієї моделі. Це зводить питання „RAG чи граф?“ до рішення другого порядку, і це є ключовим висновком дослідження.

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

Результати журі будуть опубліковані далі:

Комітет віддає перевагу RAG у всіх трьох моделях, включаючи ту, де гіпертеза надала графу значну перевагу. Це ефект інструменту, а не суперечність. У одному конкретному випадку запит отримав показник лексичної схожості 0,25 та був класифікований як неправильний за допомогою гіпертези, проте комітет поставив йому оцінку 2,88 з 3. Відповідь була правильною, просто сформульованою іншими словами. Метрики N-gram вимірюють словниковий запас, а оцінки LLM — сприйнятту правильність із упередженнями. Жоден з цих підходів окремо не дає відповіді на запитання, і коли вони суперечать один одному, ця суперечність вказує, куди слід звернутися.

Комітет заслуговує на чесне застереження: узгодженість між суддями була лише помірною, з показником Каппи Коена від 0,09 до 0,56. Комітет суддів LLM — це не інструмент для вимірювання точності. Це структурована друга думка, і саме тому існують такі фреймворки, як RAGAS, адже оцінка генерації з підсиленням через пошук залишається відкритою проблемою.

Щодо затримки, RAG був на 12–20% швидшим у всіх трьох моделях. Контекст графа є компактнішим, але запит вимагає додаткового кроку. Витрати змінюються залежно від моделі: граф є дешевшим у двох генераторах та дорожчим у одному. Співвідношення вхідних та вихідних токенів суттєво відрізняється між постачальниками, що може змінювати їхній знак. Це спостереження, а не висновок, оскільки склад токенів не перевірявся формально.

Як кожен підхід зазнає невдачі

Це найкорисніша частина, яка не відображається в жодній таблиці.

Граф має структурні недоліки. Коли запитували, яку базу даних використовує сервіс, система повернула ідентифікатор вузла, а не двигун, оскільки цей атрибут не був моделюваний. Коли запитували, скільки команд використовують певну технологію, сусідство одного кроку знайшло два сервіси, і система впевнено відповіла, що їх дві. А якщо алгоритм нечіткого зіставлення обирає неправильну entитет, весь контекст стає неправильним, причому немає жодних сигналів про це.

RAG неефективний через неповноту. Він правильно визначає, що сервіс використовує Redis, але обмежує відповідь лише знайденим сервісом, коли запит стосується загальної картини.

Обидва підходи є неправильними, але по-різному. Ці недоліки є взаємодоповнюючими, саме тому очевидним рішенням є гібридний підхід із маршрутизацією за типом запиту.

Рекомендації

• Спочатку оберіть модель. Це змінна з найбільшим впливом. Якщо розглядати її як деталь реалізації та витрачати тижні на налаштування розміру фрагментів, ви оптимізуєте параметр другого порядку.
• Почніть з RAG. У нього кращі базові характеристики та дешевше утримання, а спосіб його збою є прийнятним.
• Додавайте структуру поетапно, для визначення залежностей, власності та споживання подій. Не намагайтеся моделювати весь екосистему до того, як щось представите.
• Не покладайтеся на один метрик. Використовуйте детерміністичну евристику та набір з різних груп. Коли вони суперечать один одному, це означає наявність цікавого випадку, а не багу.
• Використовуйте парні тести. Обидві стратегії відповідають на одні й ті самі запитання, а порівняння середніх значень без методу Макнемара дає впевненість, яку дані не підтримують.

Обмеження

• Набір даних є синтетичним, а ключ відповідей створений самим експериментатором. Його не перевіряли реальні користувачі. Це забезпечує контроль та відтворюваність, але пожертвує зовнішньою валідністю.
• Реалізація графа є навмисно простою, тому деякі її слабкості у агрегації можуть походити від самої реалізації, а не від парадигми.
• Практична корисність та здатність до підтримки не вимірювалися. Вони були серед цілей та залишилися кількісними показниками.
• Гіпотеза не перевірялася порівняно з людським судженням. Група експертів пом’якшує цю проблему, але не вирішує її.
• Одинадцять із 2 160 відповідей (0,51%) були пов’язані з помилками мережі постачальника, а не з помилками системи.

Висновок

Сподівання полягало у тому, що відповідь буде на кшталт „використати граф“ або „використати RAG“. Однак виявилося, що жодна з цих відповідей не існує, поки не буде вирішено питання щодо моделі, а змінна, яку розглядали як фонову, мала найбільший вплив. Це менш задовільно, але більш корисно. Це також може бути застосовано до інших випадків: бенчмарк із прихованою змінною не дає явних помилок, а лише інтервали довіри. Перш ніж обрати архітектуру, запитайте, що саме залишалося незмінним у експерименті, та чи справді це мало бути незмінним.

Пов’язана література

• Розширені технології RAG у продакшені: архітектура, інструменти та компроміси — Огляд використання RAG у продакшені: отримання даних, їх обробка, розділення на частини, створення ембеддингів, використання векторних сховищ, гібридні методи пошуку, переранжування результатів, оцінка ефективності та забезпечення безпеки, а також компроміси, пов’язані з кожним з цих аспектів.
• GraphRAG проти Vector RAG: чому векторний пошук не ефективний у великих масштабах та як це вирішити за допомогою GraphRAG — Vector RAG має проблеми з ізоляцією частин документів, міждокументним міркуванням та масштабуванням. Дізнайтеся, як GraphRAG створює структури та анотації для вирішення цих проблем, та коли варто обирати той чи інший підхід.

ROE проти TechRAG: GraphRAG на Docker та Qdrant або на SQLite та LanceDB — Два підходи до однієї тези GraphRAG: Qdrant, MongoDB та модель обсягом 120 млрд параметрів проти LanceDB, SQLite та qwen2.5 обсягом 7 млрд параметрів, із порівнянням логіки пошуку та висновками.