RAG проти агентного RAG проти Graph RAG: як обрати правильну архітектуру пошуку
Дізнайтеся, чому наївний підхід RAG зазнає невдач при роботі з багатоетапними запитами та структурованими даними, а також як агентні цикли та пошук на основі графів окремо усувають різні слабкості.
Проблема, яку потрібно вирішити за допомогою RAG
Будь-яка модель великої мови має знання, накопичення яких припиняється після завершення навчання, і вона може міркувати лише щодо того, що вміщується у її вікні контексту. Технологія Retrieval-Augmented Generation вирішує цю проблему шляхом додавання зовнішньої пам’яті, до якої модель може звертатися під час відповідей на запитання. Замість того, щоб покладатися виключно на те, чого вона навчилась під час навчання, модель отримує відповідний текст з колекції документів та використовує цей матеріал для формування своєї відповіді.
Основні кроки, ймовірно, вже знайомі вам:
- Джерельні документи розділяються на менші частини та перетворюються на векторні ембеддинги.
- Ці ембеддинги зберігаються у векторній базі даних — поширеними варіантами є Pinecone, Weaviate, pgvector та подібні інструменти.
- Коли користувач надсилає запит, він також перетворюється на ембеддинг за допомогою того ж методу.
Увесь цей процес виконується один раз від початку до кінця: одне отримання даних, одна генерація. Це недорого, його поведінку легко зрозуміти, і для широкого спектру сценаріїв використання — пошук у внутрішніх документах, відповіді на запити підтримки на основі бази знань чи робота з питаннями та відповідями на основі статичного набору документів — він працює ідеально.
Де провалюється примітивний підхід RAG
Коли цей простий процес зазнає невдачі, причини зазвичай належать до кількох видимих категорій:
- Запитання, які вимагають поєднання кількох фактів. Щось на кшталт "які постачальники продовжили контракти після оновлення політики у 3-му кварталі?" потребує двох окремих джерел інформації, які майже напевно знаходяться у різних частинах даних. Метод векторної схожості знаходить частини даних, які семантично схожі на запит, а не конкретну комбінацію фактів, необхідну для його відповіді.
- Відсутність вбудованих умов зупинки. Система завжди повертає свої топ-k частини даних, незалежно від того, містять вони справді відповідь чи ні. Коли справжня відповідь знаходиться поза цим набором топ-k, модель або вигадує щось правдоподібне, або дає нечітку, некорисну відповідь.
- Відсутність зворотного зв’язку. Якщо початковий пошук не дає результату, ніщо в системі не фіксує цього та не намагається сформулювати запит краще. Вона просто продовжує роботу з тим, що отримала.
Жоден з цих ефектів насправді не є помилками; це природні наслідки основної передумови, закладеної в архітектуру — а саме того, що пошук за схожістю серед несполучених фрагментів тексту є достатньою заміною справжньої релевантності. Agentic RAG та Graph RAG спрямовані на різні слабкі місця цієї передумови.
Agentic RAG: Надання процесу пошуку можливості приймати рішення
Agentic RAG замінює жорстку послідовність «пошук – генерація» на цикл, у якому ШІ-модель виступає організатором — вирішуючи, що потрібно знайти, чи потрібен черговий пошук, та коли зібрано достатньо інформації для формування відповіді.
Замість одного кроку пошуку процес виглядає приблизно так:
- Модель читає запит та аналізує, яку саме інформацію їй насправді потрібна.
- Вона визначає, чи взагалі є необхідністю пошук, і якщо так, створює запит на пошук — можливо, розбиваючи складне запитання на менші підзапитання.
- Вона отримує результати, оцінює їхню адекватність, і якщо вони недостатні, переписує запит та знову шукає.
- За потреби вона може користуватися кількома різними джерелами — базою даних типу vector store, SQL-базою даних, API веб-пошуку чи внутрішньою службою — залежно від того, що вимагає запитання.
- Лише після того, як вона дійде висновку, що має достатньо доказів, вона формулює остаточну відповідь.
Фактично це вкладає RAG у механізм агентського циклу, використовуючи той самий патерн виклику інструментів, що й кодувальні асистенти: планування, дія, спостереження за результатом та подальше рішення про продовження роботи. Завантаження інформації більше не є обов’язковим першим кроком, а стає лише одним із кількох інструментів, які викликаються вибірково, а не автоматично з кожним запитом.
Перевагою є гнучкість. Просте запитання викликає одне пошукове завдання; запитання, що вимагає трьох послідовних пошуків у різних системах, отримує саме це. Така конфігурація також дозволяє самокорекцію — якщо отримані фрагменти інформації явно є некоректними, агент може це визначити та зробити інший запит замість того, щоб впевнено відповідати на основі ненадійного контексту.
Ця гнучкість має реальну ціну. Кожен крок планування та кожен етап оцінки є окремим викликом моделі, тож за кожен запит доводиться виконувати більше викликів LLM, що призводить до вищої затримки та складнішого для прогнозування профілю витрат заздалегідь. Агентний підхід RAG добре працює, коли складність запитів сильно варіюється від однієї заявки до іншої, адже фіксована однопроходна схема або марнуватиме зусилля на прості запити, або не впорається з складними. Це менш ефективний варіант, коли потрібна постійно низька затримка, або коли запити достатньо конкретні, щоб ретельно налаштований одноразовий механізм пошуку вже ефективно їх обробляв.
Graph RAG: Відновлення структури, знищеної чанкінгом
Graph RAG спрямований на зовсім іншу обмеженість: звичайний векторний пошук серед чанків не має вбудованого розуміння того, як елементи пов’язані між собою.
Замість того, щоб покладатися виключно на векторний індекс (хоча його все одно можна використовувати разом), Graph RAG створює граф знань безпосередньо з вихідного матеріалу. Це передбачає видобуток ентитетів — людей, продуктів, організацій, понять — разом із зв’язками між ними, такими як працює в, залежить від, спричинений чи є версією. Таким чином процес пошуку вже не є суто пошуком за схожістю, а стає частково проблемою перебору графа: починаючи з відповідного ентитета, система може переходити до пов’язаних ентитетів та отримувати інформацію, яка ніколи б не з’явилась лише за допомогою пошуку за ключовими словами чи векторними ембеддингами, просто тому, що вона знаходиться на кілька кроків у зв’язках у зовсім іншому документі.
Дослідження GraphRAG від Microsoft є найбільш поширеною реалізацією цього підходу, і воно включає додаткову функцію, яка є особливо корисною для певного типу запитів — виявлення спільнот. Система групує граф у кластери тісно пов’язаних ентитетів та заздалегідь обчислює короткий огляд для кожного кластера. Це надає Graph RAG перевагу у відповідях на широкі запити, що охоплюють великі обсяги інформації — наприклад, на запит типу «Які теми повторюються в усьому цьому наборі звітів?» — що саме є категорією, з якою мають труднощі прості системи RAG, адже жоден окремий фрагмент не містить повної відповіді; відповідь з’являється лише шляхом синтезу інформації з усього набору даних.
Тут витрати є структурними, а не випадковими. Створення графа є дорогим, оскільки воно вимагає обробки всього корпусу даних з метою вилучення елементів та їхніх зв’язків, яка зазвичай здійснюється за допомогою ШІ, плюс додатковий крок створення узагальнень для окремих груп документів. Цей підхід також не підходить для корпусів, які часто змінюються, адже граф доводиться перебудовувати або поступово оновлювати щоразу, коли змінюються документи — це значно складніша операція, ніж просте додавання нового вектора до індексу ембеддингів.
Порівняння трьох підходів
Варто зазначити, що ці підходи не є взаємовиключними. Поширеною практикою є використання агентського циклу, оснащеного як векторним, так і графовим пошуковиком як доступними інструментами, що дозволяє агенту обирати між ними або використовувати обидва залежно від вимог запиту. Агентський шар насправді є стратегією оркестрації, яка розташовується над будь-яким механізмом пошуку, тому він природно додається до Graph RAG, а не конкурує з ним.
Практична система прийняття рішень
Замість того, щоб обирати підхід через його поточну популярність, корисно пройтися конкретною процедурою прийняття рішень:
- Почніть з простого RAG. Це найдешевший варіант для створення та усунення проблем, і для більшості реальних застосувань він вже є достатньо хорошим. Уникайте додавання складності, поки у вас немає доказів того, що вона справді потрібна.
- Перейдіть на Agentic RAG, як тільки ви помітите певні моделі збоїв: запити, які вимагають отримання інформації з кількох джерел, відповіді, які є неправильними через необхідність моделлю шукати інформацію, оцінювати знайдене та шукати знову, або обсяг роботи, який поєднує прості та складні запити таким чином, що одна фіксована схема обробки стає або зайвою, або недостатньою.
Основний висновок відображає закономірність, яка повторюється у проектуванні систем: більш складна архітектура не є за своєю природою кращою, вона краща лише для певного типу проблем. Простий RAG не справляється з запитаннями, що вимагають багатокрокового міркування та аналізу взаємозв’язків. Agentic RAG усуває цю проблему шляхом введення ітерацій. Graph RAG усуває проблему взаємозв’язків шляхом створення структури. Правильна діагностика того, з якою саме проблемою ви стикаєтесь, — це ключ до успіху.
Пов’язана література
- Чому витрати на агентський ШІ стрімко зростають: модель витрат, заснована на архітектурі — пояснює, чому витрати на агентів ШІ потрібно вимірювати за кожне виконане завдання, а не за кожен запит, та описує архітектурні засоби, такі як маршрутизація моделей, бюджети контексту та кешування, для контролю витрат.
- Second Brain: перетворення стенограм зустрічей на знаннєву схему для пошуку — пояснює, як агентська система витягує елементи зі стенограм зустрічей та зберігає їх у Cosmos DB, щоб забезпечити пошук за допомогою природної мови та дослідження знаннєвої схеми.