Мапування RAG: етапи пайплайну, основні компоненти та ландшафт варіантів
Зрозумійте, як працює генерація з підтримкою пошуку з кінця до кінця, які компоненти потрібні системі RAG та як багато різних варіантів RAG вписуються в єдину структуру.
Джерела: The Complete Guide to RAG — Part 1: What It Is, Why It Exists & How It Works
Модель мови може демонструвати вражаючі здібності до міркувань, проте водночас не мати жодних знань про вашу внутрішню документацію, зміни політики минулого тижня чи заявку, подану годину тому. Технологія RAG (Retrieval-augmented generation) усуває цю прогалину, дозволяючи моделі шукати потрібну інформацію у зовнішньому джерелі знань перед тим, як дати відповідь. У цьому посібнику розглядаються проблеми, які вирішує RAG, та ті, що залишаються нерозв’язаними, три етапи роботи системи RAG, компоненти, необхідні для її створення, а також огляд численних варіантів RAG.
RAG у одному реченні
RAG поєднує два процеси:
- Отримання інформації: пошук відповідних даних у зовнішньому джерелі знань.
- Генерація відповідей: створення відповіді моделлю мови на основі знайденої інформації.
Простіше кажучи, RAG надає моделі бібліотеку довідок для ознайомлення перед тим, як вона дасть відповідь. Дослідження, яке запропонувало цей підхід, описало його як поєднання параметричної пам’яті моделі — знань, збережених у її вагах під час навчання, — з непараметричною пам’яттю, тобто зовнішнім індексом, який можна шукати та оновлювати незалежно.
Корисним порівнянням є екзамен з відкритою книгою:
- LLM — це учень.
- База знань — це підручник.
- Система пошуку — це учень, який перегортає потрібні сторінки.
- Кінцева відповідь — це відповідь учня, написана з цими сторінками відкритими.
Модель забезпечує логічні міркування та плавну мову; система пошуку надає факти, які є релевантними для конкретного запитання.
Проблеми, які має вирішувати RAG
Опора лише на вбудовані знання моделі стикається з кількома практичними обмеженнями. Для кожного з них RAG пропонує часткове рішення.
Знання, які закінчуються на момент навчання
Модель не може знати про те, що було додано або змінено після збору її навчальних даних. За допомогою RAG актуальна інформація зберігається у зовнішньому сховищі, яке можна оновлювати у будь-який час без впливу на саму модель.
Непідтримані або вигадані відповіді
Іноді моделі генерують твердження, які є неправильними або не мають підстав. Отримані докази дають моделі конкретну основу для роботи, що зменшує кількість непідтриманих вихідних даних. Однак це не усуває їх повністю: процес пошуку може повертати неправильні уривки, самі джерела можуть бути неточними, а модель все одно може робити твердження, які не підтримуються доказами.
Приватні дані, яких модель ніколи не бачила
Універсальна модель не має доступу до внутрішніх документів вашої організації, пропріетарного коду чи приватних знань. RAG дозволяє додатку користуватися авторизованими приватними джерелами під час запиту, без необхідності повторного навчання на цих даних. Контроль доступу все одно має велике значення: система повинна повертати лише те, що поточному користувачеві дозволено читати.
Інформація, яка часто змінюється
Політики, технічна документація продуктів та внутрішні записи постійно змінюються. Додавання чи оновлення записів у індексі пошуку значно дешевше та швидше, ніж щоразу перенавчати мовну модель після кожної зміни.
Документи, які занадто великі для повного надсилання
Вставка цілих документів у кожен запит марнує ресурси та гроші. RAG надсилає лише відповідні частини бази знань, що дозволяє запитам залишатися конкретними та короткими.
Шум від нерелевантного контексту
Занадто багато матеріалів з слабким зв’язком ускладнює моделі пошук важливих доказів. Фільтрація, переранжування та стиснення контексту існують для підвищення якості того, що врешті-решт потрапляє до моделі.
RAG покращує зв’язок із реальністю та знижує частоту галюцинацій, але не гарантує точних чи безгалюцинаційних відповідей. Використовуйте його як інструмент надійності, а не доказ правильності.
Три етапи системи RAG
На найпростішому рівні кожна система RAG виконує три завдання: підготовка знань, їх пошук та створення відповідей на основі цих знань.
Етап 1: індексування
Індексування відбувається до того, як користувач поставить запитання. Джерельний матеріал, такий як PDF-файли, веб-сторінки, документація чи рядки баз даних, піддається:
- завантаженню в систему,
- розділенню на менші частини,
Результатом є пошукова репрезентація ваших знань. Концептуально ви створюєте індекс пошуку для власних даних.
Етап 2: пошук
Коли надходить запит:
- запит перетворюється на ембеддинг за допомогою тієї ж моделі, що використовувалася під час індексації,
- у базі знань шукаються сусідні вектори,
- вибираються найбільш релевантні фрагменти,
- необов’язкове фільтрування або переранжування удосконалює вибір.
Потік від запиту до кандидатських фрагментів виглядає так:
User Query
│
▼
[Embedding Model]
│
▼
[Query Vector]
│
▼
[Vector Database]
│
▼
[Relevant Chunks]
Важлива властивість полягає у тому, що запити та документи знаходяться в одному векторному просторі. Саме тому модель ембеддингу, яка використовується під час обробки запиту, має збігатися з тією, яка використовувалась для створення індексу; поєднання різних моделей створює вектори, які неможливо змістовно порівнювати.
Етап 3: генерація
Вибрані фрагменти поєднуються з запитом користувача у форматі запрошення до дії, і модель генерує відповідь:
User Query
+
Retrieved Context
│
▼
[Prompt / Context]
│
▼
[LLM]
│
▼
Final Answer
Отримана відповідь ґрунтується як на загальних здібностях моделі, так і на конкретних даних, отриманих з вашого джерела знань. Те, як у запрошенні до дії представлені ці дані, наприклад за допомогою позначок джерел, які модель може посилатися, сильно впливає на те, наскільки точно відповідь буде ґрунтуватися на них.
У механізмі створення індексу
Саме під час створення індексу визначається більша частина якості системи RAG. Її основна структура:
Raw Data
│
▼
Document Loader
│
▼
Text Chunking
│
▼
Embedding Model
│
▼
Vector Database
Сирі дані
Знання можуть надходити майже з будь-якого джерела:
- PDF-файли
- Веб-сайти
- Документація
- Текстові документи
- Бази даних
- API
- Внутрішні корпоративні файли
Завантажувачі документів
Завантажувач документів читає вхідний матеріал та перетворює його на уніфіковану структуру, яку може обробити решта системи. Наприклад, у LangChain завантажувачі мають спільний інтерфейс, який створює об’єкти Document, і вони можуть підтримувати як метод load(), так і lazy_load(). Варіант з використанням lazy_load() генерує документи по одному замість того, щоб завантажувати все в пам’ять, що має значення для великих колекцій. LangChain та LlamaIndex — це два екосистеми, з яких зазвичай починають більшість користувачів.
Розділення на частини
Великі документи розділяються на менші частини, які називаються чанками, оскільки отримання відповідної частини документа зазвичай є кориснішим, ніж передавати моделі весь документ. Гарною аналогією є перетворення книги на стос карток з індексом, кожна з яких охоплює одну ідею.
Розмір чанків та ступінь їхнього перекриття не мають універсально правильних значень. Вони залежать від того, як структуровані ваші документи, які запитання ви очікуєте, від моделі ембеддингу, яку ви використовуєте, та від кількості контексту, яку можна забезпечити далі. Чанки, які занадто малі, втрачають навколишній зміст; чанки, які занадто великі, послаблюють сигнал тієї однієї речення, яка мала значення. Щоб детальніше дізнатися про цей компроміс, перегляньте метод розділення на чанки, який зберігає докази.
Моделі ембеддингу
Кожен фрагмент перетворюється на ембеддинг — список чисел, який представляє його значення:
"RAG retrieves relevant information"
↓
[0.24, 0.87, 0.11, 0.62, ...]
Ембеддинги дозволяють системі вимірювати ступінь спорідненості двох фрагментів контенту, що є основою для семантичного пошуку та відтворення інформації: тексти з схожим значенням опиняються близько один до одного у векторному просторі, навіть якщо вони мають мало спільних слів.
У родині моделей text-embedding-3 від OpenAI невелика модель за замовчуванням генерує 1536-вимірні вектори, а велика — 3072.
Обидві моделі підтримують параметр dimensions для отримання коротших векторів, жертвуючи трохи точністю заради меншого обсягу зберігання та швидшого пошуку. Список моделей може змінюватися, тому перевірте поточні опції в документації постачальника.
Векторні бази даних
Ембеддинги зберігаються у векторній базі даних або векторному індексі, створеному для швидкого пошуку за схожістю. Серед поширених варіантів:
- Qdrant
- Pinecone
- Chroma
- Weaviate
- FAISS
Збережений запис зазвичай містить не лише вектор, а й оригінальний текст фрагмента та метадані, такі як джерело, номер сторінки, ідентифікатор документа чи часовий позначник. Саме ці метадані дозволяють згодом фільтрувати інформацію за датою чи типом документа, а також вказувати, звідки походить відповідь.
Основні елементи додатку RAG
Якщо об’єднати все це, типовий додаток RAG складається з шести видів компонентів:
- Джерело знань: надає інформацію, наприклад PDF-файли, веб-сайти, SQL-бази даних чи API.
- Розділювач тексту: розбиває документи на керовані фрагменти за допомогою інструментів розділювання тексту від LangChain чи власної логіки.
Карта родини RAG
Як тільки основна схема стане зрозумілою, екосистема різних варіантів може здатися перевантаженою. Не існує єдиного канонічного списку типів RAG; наукові статті та інженерні блоги використовують перекриваючіся назви для архітектур, стратегій пошуку, технік контексту, джерел знань та спеціалізованих систем. Групування їх за тим, що вони змінюють, допомагає краще орієнтуватися в цій сфері.
Основні архітектури
- Naive RAG: проста послідовність кроків — імбеддинг, пошук та генерація.
- Advanced RAG: додає кроки до та після отримання інформації, такі як переписування запиту та його повторне ранжування.
- Modular RAG: розглядає кожну стадію як модуль, який можна замінити чи перекомбінувати.
Стратегії отримання інформації
- Single-pass RAG: одне отримання даних на кожне запитання.
- Multi-Query RAG: генерує кілька варіантів формулювання запиту та отримує інформацію для кожного з них.
- Iterative RAG: отримує інформацію, аналізує її та знову отримує дані.
- Multi-Hop RAG: поєднує кілька етапів отримання інформації, коли відповідь вимагає поєднання кількох фактів.
- Hybrid RAG: поєднує семантичний векторний пошук із пошуком за ключовими словами.
Підходи до контексту та чанкінгу
- Parent-Child RAG: знаходить відповідності у малих чанках, але повертає їхню більшу батьківську секцію.
- Sentence Window RAG: отримує речення разом із сусідніми реченнями.
- Hierarchical RAG: проводить пошук на різних рівнях, від документів до уривків.
- Contextual RAG: доповнює чанки контекстом на рівні документа перед їх вбудовуванням.
- RAPTOR: створює дерево рекурсивних узагальнень та здійснює пошук на його рівнях.
Самокоригуючі та адаптивні підходи
- Self-RAG: модель оцінює, чи потрібне отримання інформації та чи підтверджуються її результати.
- Corrective RAG (CRAG): аналізує отримані результати та ініціює їх корекцію, якщо вони є недостатньо якісними.
- Adaptive RAG: спрямовує кожне запитання до стратегії, яка відповідає його складності.
- Feedback-based RAG: використовує зворотний зв’язок від користувача чи експерта для поступового покращення процесу отримання інформації.
Агентські підходи
- Agentic RAG
- Multi-Hop Agentic RAG
- Multi-Agent RAG
У цих підходах агент вирішує, коли та де отримувати інформацію, можливо, за допомогою кількох інструментів чи співпрацюючих агентів, замість того щоб дотримуватися фіксованої схеми.
Варіанти, визначені джерелом знань
Кілька назв просто описують джерело даних. Vector RAG шукає в індексі ембеддингів, тоді як SQL RAG та Table RAG запитують реляційні чи таблицеві дані, часто з метою того, щоб модель написала відповідний запит. GraphRAG отримує інформацію з графа ентитетів та взаємозв’язків, Web або Search RAG отримує актуальні результати з пошукової системи, а Knowledge-Base RAG використовує спеціально підготовлений корпус даних, такий як центр допомоги чи вікі.
Багатомодальні варіанти
Інші позначення стосуються типу контенту, який отримується. Text RAG є стандартним варіантом; Image, Video та Audio RAG отримують інформацію з відповідних медіа, зазвичай через ембеддинги чи транскрипції, а Multimodal RAG — це загальна назва для систем, які поєднують кілька з цих підходів.
Спеціалізовані варіанти
Остання група — це системи найменувань груп, налаштовані під певні вимоги: одне поле, наприклад право чи медицина (специфічні для певної галузі), запитання, що враховують час, де важлива свіжість інформації (темпоральні), відповіді, адаптовані під окремого користувача (персоналізовані), запити та джерела більш ніж однією мовою (багатомовні), конфіденційні дані, які мають залишатися захищеними (збереження приватності), а також індекси, розташовані на кількох сайтах чи в організаціях (розподілені чи федеративні).
Ці групи можуть взаємно перетинатися. Реальна система для продакшну може бути одночасно гібридною, агентською та специфічною для певної галузі; ці позначки описують вибір конструкції, а не взаємовиключні продукти.
Найпростіший потік обробки — це пряма лінія:
Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
LLM
↓
Answer
Саме це мають на увазі люди, коли говорять про наївний або базовий підхід RAG: вставляють запит, беруть k найближчих фрагментів та передають їх моделі. Це розумна початкова версія, яка часто є достатньою для невеликих, організованих корпусів даних.
Більш розвинені системи додають додаткові етапи під час отримання інформації:
User Query
↓
Query Rewriting
↓
Query Routing
↓
Hybrid Retrieval
↓
Metadata Filtering
↓
Reranking
↓
Context Compression
↓
LLM
↓
Answer
Кожен етап спрямований на усунення певної слабкості. Переписування запитів допомагає виправити нечіткі чи розмовні запити, маршрутизація направляє запит до правильного індексу чи інструменту, гібридний пошук знаходить точні терміни, які пропускає чистий векторний пошук, фільтрація метаданих видаляє документи, що не належать до сфери пошуку, переурочування ранжування переставляє кандидатів за допомогою більш точної моделі, а стиснення скорочує обсяг даних для дотримання обмежень. Додавайте їх лише тоді, коли можете виміряти проблему, яку вони вирішують; складність сама по собі не є метою.
Чому RAG — це більше, ніж векторна база даних плюс LLM
Поширеною помилкою серед початківців є думка, що RAG означає „зберігати ембеддинги, здійснювати запити до них та викликати модель“. Насправді процес у продакшні виглядає більше так:
Document Processing
↓
Chunking
↓
Metadata
↓
Embedding
↓
Vector / Keyword Retrieval
↓
Filtering
↓
Reranking
↓
Context Compression
↓
Prompt Construction
↓
LLM
↓
Validation
↓
Final Answer
Кожен крок у цьому ланцюжку може погіршити кінцеву відповідь: погана обробка даних, недбале розділення на частини, відсутність метаданих, несумісна модель ембеддингів, слабке фільтрування чи погано сформульований запит. Саме тому підключення векторного сховища до моделі — це лише початок. Якою б не була здатність моделі, вона не може повністю компенсувати надання їй неправильної інформації.
Як оцінити систему RAG
Отримання відповіді — це не критерій якості. Хороша система RAG знаходить справді корисну інформацію та генерує відповідь, яку підтверджують знайдені докази. Важливими показниками є:
- Якість пошуку: чи справді повертаються відповідні документи чи їх фрагменти?
Окреме вимірювання кожної стадії дозволяє діагностувати проблеми; підхід оцінки RAG за стадіями збоїв показує, як це організувати.
Що робити далі
Наступним рівнем глибини є сам шлях індексації: як PDF перетворюється на текст, відмінності між завантаженням, парсингом та очищенням даних, компроміси між частковим розбиттям на символи, токени, рекурсивним, семантичним та структурно-орієнтованим підходами, що насправді означає перекриття частин тексту, як слід проектувати метадані, як текст перетворюється на вектор, у чому різниця між косинусовою схожістю, дотичним добутком та евклідовою відстанню, а також як база даних векторів здійснює пошук за схожістю у великих масивах даних.
Ключові висновки
- RAG поєднує навчені знання моделі з зовнішнім сховищем даних, яке можна шукати, щоб відповіді могли відображати приватну та актуальну інформацію без необхідності повторного навчання.
- Цей підхід зменшує кількість некоректних відповідей, але не гарантує їх правильності; процеси пошуку, отримання даних та генерація відповідей все ще можуть зазнати невдач.