16 архітектур RAG у порівнянні: яка схема підходить до якої проблеми

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

Три проблеми, що лежать в основі RAG

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

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

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

Without RAG:
  User: "What's our refund policy?"
  LLM:  "I believe you offer a 14-day return..." (guessing)

І разом з ним:

With RAG:
  User: "What's our refund policy?"
  → Step 1: Search internal docs → Finds: "Refunds within 30 days..."
  → Step 2: LLM reads the doc and answers accurately
  LLM:  "Your refund policy allows returns within 30 days..."

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

Шістнадцять шаблонів у чотирьох рівнях

Розташування шаблонів за їхнім впливом у реальному світі дозволяє виділити чотири рівні. Перший охоплює те, що потрібно приблизно 80% систем у промисловому використанні, а наступні — спеціалізовані проблеми.

Рівень 1: обов’язково до вивчення

1. Стандартний RAG — основа

Рівень складності: початківець. Найкраще підходить для тих, хто тільки починає. Кожний проект RAG починається з цього етапу, і процес складається з чотирьох стадій:

1. Індексування: розділення документів на частини, їх перетворення на ембеддинги та зберігання у векторній базі даних.
2. Пошук: ембеддингування запиту користувача та пошук схожих частин документів.
3. Доповнення: включення знайдених частин до запиту.
4. Генерація: ШІ-модель відповідає на основі цього реального контексту.

Основний цикл складається приблизно з десяти рядків:

# The core loop in ~10 lines
query_embedding = embed(user_query)
relevant_docs = vector_store.search(query_embedding, top_k=5)
context = "\n".join(relevant_docs)
prompt = f"Answer using this context:\n{context}\n\nQuestion: {user_query}"
answer = llm.generate(prompt)

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

2. Гібридний RAG – найбільше покращення якості

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

User: "React useState hook"
→ Semantic search finds: "state management in React components"
→ BM25 finds: docs with exact string "useState"
→ Hybrid (RRF fusion): gets the best of both

Функція взаємного злиття рангів (RRF) об’єднує два списки з рангуванням без необхідності нормалізації їхніх оцінок, що робить її елегантною та ефективною. Багато команд повідомляють про підвищення точності на 10–20 відсотків лише завдяки цій заміні. Вона підходить для будь-якої системи виробництва, особливо для документації до коду, технічних посібників та юридичних документів, де важливі як точні терміни, так і їхнє значення.

3. Контекстуальне пошукове забезпечення RAG, створене для діалогу

Рівень складності: середній. Використовуйте його, коли з’являються додаткові запитання. Поширена проблема полягає у наступному: хтось запитує про план Premium, а потім — скільки він коштує. Стандартний RAG шукає щось на кшталт „it cost“ та не знаходить нічого корисного. Ця версія перед пошуком переписує запит, використовуючи історію розмови.

User turn 1: "Tell me about the Premium plan"
User turn 2: "How much does it cost?"

Before search, rewrite → "How much does the Premium plan cost?"
Now retrieve → finds the pricing document ✓

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

Рівень 2: конкурентна перевага

4. Agentic RAG – популярна тенденція 2025 та 2026 років

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

User: "What was NVDA's stock return last quarter vs its historical average?"

Agentic RAG decides:
  → Use web_search tool for current stock data
  → Use calculator tool for return calculation
  → Use document_retrieval tool for historical reports
  → Synthesize all three into one answer

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

5. Self-RAG – для ситуацій, коли помилки є неприйнятними

Рівень складності: просунутий. Ідеально підходить там, де точність має критичне значення. Контроль якості вбудований у сам процес обробки, і система не надає відповідь сліпо після пошуку. Інформація проходить через чотири контрольні точки. Перша перевіряє, чи взагалі потрібен пошук для цього запиту. Друга — чи є отриманий документ справді релевантним. Третя — чи відповідь ґрунтується на отриманих фактах. Четверта — чи допомагає ця відповідь. Якщо система не пройшла будь-яку з цих перевірок, вона здійснює новий пошук, коригує результат або відмовляється відповідати. Медичні системи, юридичні ШІ та фінансові консультанти є природними сферами застосування, де хибна відповідь може завдати реальної шкоди.

6. HyDE RAG – місток між словниковими запасами

Рівень складності: просунутий. Найкраще підходить, коли мова користувачів відрізняється від мови документів. HyDE — це скорочення від Hypothetical Document Embeddings. Уявіть ситуацію, коли користувач запитує, чому речі падають, тоді як у документах йдеться про прискорення вільного падіння 9,81 м/с². У цих двох випадках майже немає спільного словникового запасу, тому пошук за вбудованими даними, ймовірно, не дасть результатів. Хитрість HyDE полягає у тому, що спочатку генерується фальшива відповідь, а потім проводиться пошук за нею.

User: "Why do things fall down?"
→ LLM generates hypothesis: "Objects fall due to gravitational force..."
→ Search with the hypothesis (technical vocabulary)
→ Find the actual document about gravitational acceleration
→ Answer using the real document

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

Рівень 3: спеціалісти високого рівня впливу

7. Graph RAG – для реляційного міркування

Рівень складності: середній. Найкраще підходить, коли потрібно відповісти на запитання про зв’язок між X та Y. Векторний пошук знаходить схожі документи, але не може відповісти на запитання на кшталт «Які компанії пов’язані з певною особою через принаймні двох членів правління», що вимагає обробки графа. Graph RAG створює граф знань на основі документів, де елементи є вузлами, а зв’язки – ребрами, а запити проходять по цьому графу.

Text: "Dr. Chen collaborated with Dr. Patel on a 2022 study funded by NIH."

Graph nodes: Dr. Chen, Dr. Patel, 2022 study, NIH
Graph edges: COLLABORATED_WITH, FUNDED_BYQuery: "Who funded Dr. Chen's work?" → traverse: Chen → study → NIH

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

8. RAG із підсиленням пам’яті – бот, який пам’ятає вас

Рівень складності: середній. Ідеально підходить, коли чат-бот має пам’ятати своїх користувачів між сеансами. У звичайному боті кожна розмова починається з нуля. Ця версія додає три види пам’яті: пам’ять розмови для поточного чату, семантичну пам’ять для фактів про користувача, таких як уподобання до технічних пояснень, та епізодичну пам’ять для минулих сеансів, наприклад запитання щодо певної теми, поставлене два тижні тому.

user_profile = memory.get_user_facts(user_id)
recent_context = memory.get_recent_conversations(user_id, k=3)
answer = rag_with_context(query, user_profile, recent_context)
memory.update(user_id, query, answer)

Додатки для репетиторства, боти для підтримки клієнтів та особисті асистенти з підвищення продуктивності отримують найбільшу користь.

9. Модульний RAG – можливість заміни будь-якої частини без переписування коду

Рівень складності: середній. Ідеально підходить, коли потрібно швидко вносити зміни. Це архітектурна філософія, згідно з якою кожен компонент конвеєра може бути замінений окремо. Перехід від FAISS до ChromaDB здійснюється за один рядок, а тестування BM25 порівняно з іншими алгоритмами пошуку не вимагає рефакторингу.

Standard RAG:   [fixed retriever] → [fixed reranker] → [fixed LLM]

Modular RAG:    [pluggable retriever] → [pluggable reranker] → [pluggable LLM]
                     ↑ swap anytime         ↑ swap anytime        ↑ swap anytime

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

10. RAG, спеціалізований для певної галузі, створений для конкретної індустрії

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

11. Покращена система RAG: три джерела та одна відповідь

Рівень складності: просунутий. Найкраще підходить, коли потрібні одночасно структуровані та неструктуровані дані. Одне запитання поєднує SQL або інші структуровані бази даних для отримання точних чисел, графи знань для визначення взаємозв’язків та ембеддинги документів для контексту оповіді.

Query: "Tell me about the Mars Exploration Program"

→ SQL: "Mars: 1.52 AU from sun, 687-day orbit"
→ Graph: Mars → explored_by → Curiosity Rover, Perseverance
→ Text: "Mars is the fourth planet... known as the Red Planet..."→ Fused Answer: Combines all three for comprehensive, expert-level response

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

12. Рекурсивний або багатоетапний RAG для складних запитань

Рівень складності: просунутий. Вибирайте його, коли одного пошуку недостатньо для відповіді на запитання. Деякі запитання вимагають послідовності знань. Щоб зрозуміти, як винахід транзистора призвів до сучасних ШІ, потрібно пройти щонайменше п’ять етапів: транзистор, інтегральна схема, CPU, GPU, глибоке навчання, LLMs. Рекурсивний RAG здійснює пошук, навчається та знову здійснює пошук.

Round 1: Retrieve about transistors → learn about miniaturization
Round 2: Retrieve about integrated circuits → learn about computing power
Round 3: Retrieve about GPUs → learn about parallel processing
Round 4: Retrieve about deep learning → learn about compute requirements
Round 5: Synthesize the full chain into a coherent answer

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

Рівень 4: спеціалізовані сценарії використання

13. ODQA RAG – відповідь на будь-яке запитання

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

14. Multi-Modal RAG – текст, зображення та аудіо разом

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

User (text): "Show me the anatomy of the heart"
→ Retrieves both: text descriptions AND anatomical diagrams
→ Response includes both text explanation and relevant image

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

15. Streaming RAG, знання в реальному часі

Рівень складності: середній. Найкраще підходить, коли інформація змінюється кожні кілька хвилин. Запитання, поставлене о 9 ранку та знову о 11 ранку, потребує різних відповідей, якщо дані, на яких воно ґрунтується, змінилися. Streaming RAG підтримує постійно оновлювану базу знань, індексуючи нові документи щойно вони надходять.

Time 9:00 AM: "What's happening with NVDA?"
→ Retrieves this morning's earnings report

Time 11:30 AM (after news breaks): "What's happening with NVDA?"
→ Retrieves the breaking news from 11:15 AM

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

16. Федерований RAG, приватність на першому місці та багатоджерельність

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

Central Query: "What's the survival rate for treatment X?"

→ Hospital A retriever: returns relevant anonymized snippets
→ Hospital B retriever: returns relevant anonymized snippets
→ Hospital C retriever: returns relevant anonymized snippets
→ Central LLM synthesizes — never saw raw patient recordsResult: HIPAA/GDPR compliant, collaborative AI

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

Порядок реалізації місяць за місяцем

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

Month 1:  Standard RAG           ← Get something working
Month 2:  + Hybrid RAG            ← Biggest retrieval quality win
Month 3:  + Contextual Retrieval  ← Multi-turn conversations work now
Month 4:  + Self-RAG              ← Stop hallucinations
Month 5:  + Agentic capabilities  ← Tools beyond just search

This covers 80-90% of production RAG needs.

Поєднання шаблонів

Системи виробництва майже завжди поєднують кілька шаблонів. Ось кілька прикладів:

• Корпоративний чат-бот поєднує стандартні, гібридні, контекстуальні та моделі на основі пам’яті для багатокрокових розмов, ефективного пошуку та персоналізації.
• Медичний асистент використовує спеціалізовані, самостійні та покращені моделі, оскільки важлива точність та задіяні структуровані дані.
• Інструмент для досліджень поєднує агентні, гібридні та рекурсивні моделі для складних запитань, багатьох кроків та різних інструментів.
• Служба підтримки клієнтів використовує стандартні, контекстуальні та потокові моделі для подальших дій та миттєвих оновлень.
• Юридичні дослідження ґрунтуються на спеціалізованих, графових та гібридних моделях для визначення взаємозв’язків між елементами та точних цитувань.
• Аналізатор новин поєднує потокові, ODQA та багатомодальні моделі для роботи з миттєвими даними, широким спектром тем та зображеннями.

Швидкий вибір

Для першого бота з відповідями на запитання щодо документів почніть з Standard RAG. Для кращого пошуку в промислових умовах додайте Hybrid. Бот для багатокрокових розмов потребує Contextual Retrieval, а бот, який використовує інструменти чи API, — агентської версії. Висока точність у медицині чи праві вимагає Self-RAG, а звичайні користувачі, які працюють із технічною документацією, — HyDE. Для відносних запитань потрібен Graph RAG, для персоналізованого асистента — Memory-Augmented, для експериментів із різними комплектаціями — Modular, а для регульованих галузей — Domain-Specific. Змішані структуровані та неструктуровані дані підходять для Enhanced RAG, запитання з кількома кроками — для Recursive RAG, а універсальні Q&A-системи — для ODQA. Зображення та аудіо вимагають Multi-Modal, потокові дані — Streaming, а багатоорганізаційні системи в рамках HIPAA чи GDPR — Federated.

Запуск прикладів

Кожна реалізація призначена для безпосередньої роботи: скопіюйте репозиторій, встановіть необхідні залежності, налаштуйте ключ API OpenAI та почніть з першого шаблону.

# Clone the repo
git clone https://github.com/Manjunadh86/RAG-Materials.git
cd RAG-Materials

# Install dependencies
pip install -r requirements.txt# Set your OpenAI API key
export OPENAI_API_KEY="sk-your-key-here"# Run your first RAG system
cd 01-Standard-RAG
python hands_on.py

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

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