Що таке архітектура RAG? Повне визначення з докладними практичними прикладами

RAG (retrieval augmented generation, генерація, доповнена пошуком) — це процес, у якому LLM використовують зовнішню інформацію, щоб розширити й покращити свої відповіді. Архітектура RAG — це сукупність компонентів і зв’язків, що уможливлюють RAG.

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

Що таке архітектура RAG?

Архітектура RAG — це конфігурація компонентів (і пов’язаних із ними можливостей), що лежить в основі певної системи RAG. Усі ці архітектури спираються на базовий шаблон, який часто називають «простим» або «наївним» RAG.

Ось загальний огляд базової архітектури RAG:

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

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

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

Типи архітектури RAG

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

1. Базовий RAG

Базовий RAG, який також називають «наївним» або «простим» RAG, — це архітектурний шаблон для інших типів RAG.

Базовий процес відносно простий: користувач вводить промпт, оркестратор визначає, чи потрібна зовнішня інформація (самостійно або разом із LLM), і відповідно формує та надсилає пошуковий запит.

Зовнішнім джерелом інформації зазвичай є векторна база даних, але це також може бути база даних SQL, веб-API, граф знань або навіть сховище «необроблених» документів. Потім ця додаткова інформація додається до вхідного контексту LLM.

Окрім SQL-запитів і API, існує два основні типи методів пошуку:

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

Використання пам’яті — також важлива частина архітектури RAG. Ідеться про те, як LLM використовує контекст попередніх чатів для побудови пошукового запиту, вписуючи його в ширший контекст обговорення (або кількох обговорень). Розмовний RAG — стандарт для більшості чат-ботів, хоча в деяких сценаріях, як-от відповіді на звернення до служби підтримки, може використовуватися RAG для окремих запитань.

2. Гібридний RAG

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

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

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

3. Адаптивний RAG

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

В оригінальному фреймворку (Adaptive-RAG) менша модель виконувала роль класифікатора й обирала один із варіантів: без пошуку, одноетапний пошук або багатоетапний пошук. Деякі архітектури тепер натомість використовують генеративні моделі або евристики на основі правил.

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

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

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

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

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

5. Self-RAG

У Self-RAG модель може ініціювати запити після отримання початкового вхідного контексту. Згенеровані відповіді звіряються з отриманими доказами за допомогою токенів рефлексії, а за потреби через оркестратор надсилаються додаткові запити. І навпаки, LLM може вирішити, що пошук узагалі не потрібен.

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

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

6. Агентний RAG

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

Пошук можна запускати кілька разів за потреби, а для складніших запитів модель може залучати агентів. Наприклад, LLM може надіслати запит до бази даних, щоб визначити постачальника, запустити пошук документів, щоб знайти відповідні контракти, і завершити вебпошуком, щоб перевірити контактні дані за публічними джерелами.

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

7. Мультимодальний RAG

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

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

8. GraphRAG

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

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

9. Розгалужений RAG

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

10. HyDE (Hypothetical Document Embeddings — ембединги гіпотетичних документів)

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

Приклад простої архітектури RAG: векторна база даних

Базовий RAG є основою для складніших типів архітектури. У простій системі RAG, що використовує векторну базу даних, вихідна документація розбивається на менші частини (фрагменти) і перетворюється на щільні ембединги. Коли користувач вводить промпт, оркестратор формує запит, кодує його та надсилає до бази даних, щоб знайти релевантні фрагменти.

Ось покроковий опис процесу:

1. Великі обсяги тексту перетворюються на вектори за допомогою автоматизованого конвеєра завантаження даних і моделі ембедингів, як-от BERT.
2. Застосунок бази даних упорядковує, індексує та зберігає вектори для швидкого пошуку.
3. Користувач вводить промпт у чат-бот (наприклад, Perplexity).
4. Оркестратор застосунку кодує промпт (за допомогою моделі ембедингів), щоб отримати релевантну інформацію з векторної бази даних.
5. Векторна база даних повертає релевантні фрагменти, а оркестратор додає їх до вхідного контексту («великого промпту») і передає його LLM.
6. LLM використовує додатковий контекст, щоб згенерувати відповідь на основі своїх внутрішніх знань (збережених у її параметричних вагах).

Розгорнути

Приклад розширеної архітектури RAG: агентний RAG

Агентний RAG — це базова архітектура систем RAG на агентній платформі. Агентні потоки RAG зазвичай складні, оскільки ШІ-агенти можуть викликати різні інструменти та конвеєри залежно від характеру промпту, за потреби залучаючи кількох агентів.

Ось практичний приклад процесу:

1. Користувач ставить складне запитання, яке потребує глибокого дослідження теми. Припустімо, у цьому прикладі промпт такий: «Зроби прогноз прибутків компанії на наступні шість місяців з огляду на важливі геополітичні події».
2. LLM доходить висновку, що знадобиться поєднання запитів RAG до різних типів контенту.
3. Розгортаються три різні агенти: для (а) векторного пошуку, (б) обґрунтування відповідей даними з вебу та (в) пошуку зображень (мультимодального).
4. Агенти шукають релевантну інформацію, як-от новини та внутрішні фінансові дані, через оркестратор за допомогою доступних інструментів пошуку.
5. LLM порівнює отримані результати з дослідницьким запитанням кожного агента та ранжує їх за релевантністю.
6. LLM оцінює інформацію та запускає додаткові пошуки через окремих агентів там, де інформації бракує.
7. Коли отримано достатньо інформації, LLM генерує сценарні прогнози на основі наявних фінансових показників (отриманих із внутрішньої документації) і викликає інструмент-калькулятор, щоб спрогнозувати прибутки для кожного сценарію.
8. LLM генерує остаточну відповідь на основі отриманої інформації та розрахунків, за потреби посилаючись на джерела.

Розгорнути

Яке майбутнє чекає на RAG?

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

Ось три тенденції, які нині визначають напрям досліджень:

• Глибоке дослідження з використанням кількох джерел: це архітектура RAG, здатна планувати пошуки, запускати кілька гілок пошуку в різнорідних джерелах, оцінювати отримані докази та самостійно оптимізувати згенеровані відповіді. Агентний RAG, здатний виконувати всі ці завдання, стає дедалі швидшим і економічнішим.
• Мультимодальні застосування: конвеєри пошуку дедалі краще працюють із зображеннями та відео. Вони все точніше знаходять конкретні типи інформації в складних мультимодальних даних, як-от довгі відео та складні діаграми.
• Обґрунтування відповідей інформацією, що постійно змінюється: застосунки на основі LLM можуть використовувати джерела інформації в реальному часі (як-от відеопотоки та датчики) для формування вхідного контексту. Системи також можуть створювати багатогранні мережі інформації — наприклад, за допомогою GraphRAG, — щоб інтерпретувати ці дані.

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

Саме тому системи RAG та їхня базова архітектура — одна з найдинамічніших і найцікавіших галузей досліджень ШІ.