Вибір архітектури RAG: проста, розширена, CRAG, GraphRAG, агентська.

Чому саме RAG та чому однієї концепції недостатньо

Штучні інтелектуальні агенти є здатними до виконання завдань, проте вони створюють хибні дані та не можуть самостійно отримувати спеціалізовану чи реальну-часову інформацію. Технологія Retrieval-Augmented Generation (RAG) вирішує обидві проблеми, базуючи відповіді агента на перевіреній базі знань. Однак RAG — це не єдиний підхід. Звичайний векторний пошук достатній для простого бота з часто ставлених запитань, але погано справляється зі складними міркуваннями чи аналізом, які вимагають обробки багатьох документів. У наступному описано поширені архітектури RAG та критерії вибору серед них залежно від вимог завдання.

Що робить RAG

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

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

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

Фаза 1: збір даних

У першій фазі необроблені файли перетворюються на структуровані, пошукові записи в базі даних:

1. Завантажувати дані з таких джерел, як PDF, Notion, SQL та Slack, за допомогою інструментів на кшталт LlamaIndex чи LangChain.
2. Очищувати від зайвого контенту, такого як заголовки, футери та HTML-теги.
3. Розділяти довгі документи на змістовні частини, наприклад по 500 слів кожна. Занадто великі частини ускладнюють роботу моделі, а занадто малі втрачають контекст.
4. Вбудовувати кожну частину за допомогою моделі вбудовування (наприклад, text-embedding-3-small від OpenAI), щоб перетворити текст на вектори.
5. Створювати індекс векторів у базі даних векторів, такій як Pinecone чи Chroma, що дозволяє здійснювати семантичний пошук за змістом.

Етап 2: пошук та генерація

Коли користувач ставить запит, усе відбувається протягом кількох мілісекунд:

1. Трансформація запиту. Система перетворює запит, наприклад "Як скинути свій пароль?", на вектор за допомогою того ж моделі ембеддингів, що використовується на етапі 1.
2. Пошук. Вона шукає у базі даних векторів 3–5 фрагментів, які математично найближчі до запиту.
3. Переранжування. Модель переранжування ще раз перевіряє результати, щоб найкращий варіант опинився на першому місці.
4. Посилення інформації. Знайдені фрагменти включаються до запрошення для LLM. Типове запрошення повідомляє моделі, що це корисний асистент, передає їй фрагменти як контекст та потім ставить запит про скидання пароля.
5. Генерація. LLM читає запрошення та контекст та формулює відповідь, ґрунтуючись виключно на наданій інформації.

Етап 3: зворотний зв’язок

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

Інструменти за фазою

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

У таблиці технології RAG сортуються за етапами обробки даних.

Чи потрібна база даних векторів?

Не обов’язково. Для створення RAG не потрібен спеціалізований сховище векторів, існують два простіші підходи. За допомогою підходу без бази даних кілька документів розділяються на частини та зберігаються в оперативній пам’яті. Це швидко, безкоштовно та не вимагає налаштувань, але пам’ять очищується під час перезавантаження, а великі документи обробляються повільно. Традиційний підхід з базою даних передбачає зберігання фрагментів тексту у таких системах, як PostgreSQL, та використання пошуку за ключовими словами на основі правил. Він ефективний для унікальних фраз, таких як ім’я людини чи ідентифікатор, але не має семантичного розуміння: користувач, який шукає „ссавців“, не отримає результатів у документі, де написано лише „собаки“.

Порівняння шести архітектур

Жодна конфігурація не підходить у всіх випадках. Деякі завдання вимагають швидкості та простоти, інші — глибшого аналізу, кількох джерел чи нетекстових даних, таких як зображення чи графики. Шість основних підходів покривають більшість потреб: Naive RAG, Advanced RAG, Modular RAG, Corrective RAG (CRAG), GraphRAG та Agentic RAG.

Naive RAG

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

На діаграмі показано просте зіставлення векторної схожості типу top-K. Запит перетворюється на вектор, найбільш схожі фрагменти отримуються з бази даних векторів та надсилаються до LLM. Пошук є семантичним, а складність — низькою.

• Переваги: найшвидші відповіді та найнижчі витрати на обробку даних, легко налаштовується за допомогою бібліотек на кшталт LangChain чи LlamaIndex, підходить для базового отримання фактів з чистих документів.
• Слабкі сторони: нерелевантні фрагменти можуть створювати зайвий шум, який заплутує ШІ, він має труднощі з складними чи багатокомпонентними запитаннями, а також не може самостійно виправляти помилки, тому невдалий пошук перетворюється на хибну відповідь.
• Найкраще підходить для: простих запитань та відповідей у невеликих, чистих наборах даних, таких як запитання та відповіді щодо особистих документів, внутрішні FAQ компаній та прості додатки для спілкування з документами.

Розширений RAG

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

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

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

Модульний RAG

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

Серед виділених компонентів — модулі пошуку та пам’яті. Такий розподіл системи означає, що кожну її частину можна налаштувати окремо, не перебудовуючи решту: команда може встановити інший механізм пошуку, потужніший алгоритм ранжування чи інший генератор. Пошук може здійснюватися з кількох джерел, таких як API, бази даних та Інтернет, і складність є високою, оскільки потрібен складний шар оркестрації.

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

Найкраще підходить для: складних корпоративних систем, які потребують глибокої налаштуваності, наприклад асистента, який одночасно перевіряє Jira, Slack та Google Drive.

Коригувальний RAG (CRAG)

CRAG створений для подвійної перевірки своїх відповідей та їх виправлення у разі помилок.

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

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

GraphRAG

GraphRAG використовує граф знань для структурування зв’язків між фрагментами інформації та не покладається лише на схожість тексту.

На діаграмі показано просування по графу знань та створення підсумків для окремих груп даних. Після створення графу система аналізує його на наявність закономірностей у даних, а не лише збігів слів, тож може визначити зв’язок між Об’єктом А та Об’єктом Б навіть тоді, коли вони зустрічаються у різних документах. Складність дуже висока, оскільки необхідно створювати та підтримувати структуровану базу даних графів.

Друга ілюстрація, взята з матеріалів Microsoft Research, демонструє граф знань, створений за допомогою LLM на основі приватного набору даних з використанням GPT-4 Turbo.

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

Agentic RAG

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

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

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

Чотириетапний шлях прийняття рішень

Жодне правило не підходить до всього, але спільний підхід допомагає вирішити поставлену задачу.

Діаграма потоку допомагає архітекторам обирати між варіантами Simple, Graph, Corrective та Advanced RAG залежно від вимог завдання. Кроки:

Крок 1: тест на складність. Чи знаходиться відповідь у одному документі? Якщо так, найкращим варіантом є No-DB RAG для невеликих документів або Simple RAG — він швидкий, недорогий та майже не вимагає зусиль для створення.

Крок 2: тест на взаємозв’язки. Чи потрібно для отримання відповіді розуміти глибокі ієрархії чи приховані зв’язки між кількома джерелами даних? Якщо так, GraphRAG відображає ці ресурси та зв’язки, які залишаються непоміченими під час пошуку у простому тексті. Наприклад, для запиту „Які відділи піддаються впливу Політики А, і хто є їхніми керівниками?“ необхідно поєднати дані про відділи з даними про співробітників, а GraphRAG представляє їх як пов’язані елементи.

Крок 3: тест надійності та логічного міркування. Чи може система дозволити собі помилку? Там, де важлива максимальна точність, Corrective RAG або Self-RAG додають спеціальний крок, який перевіряє, чи отримані дані справді відповідають на запитання, перш ніж вони потраплять до користувача. Якщо таке завдання також вимагає багатокрокового міркування, Agentic RAG забезпечує планування та самокорекцію за допомогою своїх агентів.

Крок 4: баланс продуктивності та витрат. Коли пріоритетом є затримка, найкраще підходить простіша конфігурація, така як No-DB, Naive чи Simple RAG. Коли якість має більше значення, ніж витрати, але не на рівні максимальної точності з Кроку 3, Advanced RAG краще розуміє намір за запитом, ніж простіші рішення, але це коштує більше часу обробки.

Коли не варто використовувати RAG

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

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

Складні математичні чи логічні задачі, які вимагають багатоетапних обчислень. Для них краще підходить налаштування моделі або використання методу Chain-of-Thought (CoT).

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

Малі набори даних, які повністю поміщаються у запит. Краще просто вставити дані, ніж створювати спеціальну інфраструктуру.

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