Суть патерна
RAG Agent — це патерн, у якому агент спочатку знаходить релевантні джерела, а потім формує відповідь на їх основі, а не лише з параметричної пам'яті моделі.
Коли потрібен: коли відповідь має спиратися на актуальні документи й посилання, а не лише на пам'ять моделі.
Замість відповіді "з голови моделі", RAG додає окремий крок:
- знайти факти в базі знань
- відібрати найрелевантніші фрагменти
- дати відповідь із посиланнями
Проблема
Уяви, що користувач питає:
"Який SLA для enterprise-плану?"
Агент відповідає без кроку пошуку, лише з пам'яті моделі.
Текст може звучати впевнено, але бути слабко перевіреним:
- застаріле значення з попередньої версії політики
- змішані факти з різних документів
- відсутність джерела для перевірки
- "точне" формулювання без доказів
Без керованого пошуку навіть правдоподібна відповідь може бути непідтвердженою.
Особливо ризиковано це для support, compliance, внутрішніх політик і технічної документації.
У цьому й проблема: без прив'язки до джерел агент може дати переконливу, але неперевірену відповідь, яку важко аудіювати.
Рішення
RAG додає grounding-policy, яка керує пошуком перед генерацією.
Аналогія: це як відповідати з відкритою книжкою. Спочатку знаходиш потрібні сторінки, а вже потім формулюєш відповідь. Якщо джерел немає, краще уточнити запит, ніж вигадувати.
Ключовий принцип: Спочатку знайти й перевірити джерела, потім формувати відповідь.
Агент може запропонувати текст, але grounding-policy визначає:
- які джерела валідні
- що можна включити у відповідь
- коли потрібен резервний сценарій замість "додумування"
Керований процес:
- Пошук: знайти релевантні фрагменти
- Ранжування/фільтрація: прибрати шум і дублікати
- Прив'язка до джерел: зібрати дозволений контекст
- Генерація: відповідати лише в межах контексту
- Цитування: прикріпити посилання/metadata до тверджень
Це дає:
- менший ризик галюцинацій у factual-запитах
- прив'язку відповіді до документів
- перевірюваність та аудитованість
- актуальніші відповіді при змінах у документах
Працює добре, якщо:
- пошук має якісний індекс + metadata
- ranking стабільно відсікає шум
- модель не відповідає поза заземленим контекстом
- при відсутності джерел спрацьовує безпечний резервний сценарій
Модель може "хотіти" відповісти з пам'яті, але саме шар RAG визначає, чи є достатня доказова база.
Як працює
RAG не замінює агента. Він додає шар знань перед генерацією відповіді.
Ключова ідея: якщо релевантного контексту немає, система не повинна "вигадувати відповідь".
Опис повного флоу: Retrieve → Ground → Generate → Cite
Пошук
Система шукає кандидати у базі знань за запитом користувача.
Прив'язка до джерел
Відібрані фрагменти передаються як єдиний дозволений контекст для генерації відповіді.
Генерація
Агент формує відповідь лише на основі переданого контексту. Будь-яка інформація поза ним вважається недозволеною.
Цитування
У фінальний результат додаються джерела: посилання, назва документа, версія або timestamp.
У коді це виглядає так
chunks = retrieve(goal, top_k=8, filters={"tenant_id": tenant_id})
context = rerank_and_pack(goal, chunks, max_tokens=2500)
if not context:
return ask_clarifying_or_fallback(goal) # без релевантного контексту відповідь не генеруємо
answer = generate_grounded_answer(goal, context) # генерація тільки по знайдених джерелах
answer = attach_citations(answer, context)
return answer
Як це виглядає під час виконання
Goal: Який SLA для enterprise-плану?
Retrieve:
- знайдено 6 фрагментів у політиках підтримки
- після rerank залишено 2 релевантні
- якщо релевантних фрагментів 0 -> уточнювальне запитання / резервний сценарій замість вигаданої відповіді
Ground:
- сформовано контекст із двох уривків
- додано metadata: doc_id, section, updated_at
Generate:
- відповідь сформовано лише з цих джерел
Cite:
- додано посилання на "Support Policy v3.2"
Повний приклад RAG агента
Коли підходить — і коли ні
Підходить
| Ситуація | Чому RAG підходить | |
|---|---|---|
| ✅ | Важлива фактична точність і посилання на джерела | RAG прив'язує відповідь до конкретних документів і полегшує верифікацію. |
| ✅ | Знання часто оновлюються | Пошук підтягує актуальні дані без перевчання моделі. |
| ✅ | Відповідь має ґрунтуватися на внутрішніх матеріалах | RAG дозволяє використати корпоративні документи як основу відповіді. |
| ✅ | Потрібно зменшити галюцинації | Заземлений контекст зменшує частку відповідей без фактологічної опори. |
| ✅ | Результат має бути аудитований | Можна логувати знайдені джерела і пояснити, на чому базується відповідь. |
Не підходить
| Ситуація | Чому RAG не підходить | |
|---|---|---|
| ❌ | Задача не залежить від зовнішніх знань | Шар пошуку додає накладні витрати без помітного покращення результату. |
| ❌ | Немає якісної бази знань і metadata | Слабкий індекс і неякісні документи дають нерелевантний пошук. |
| ❌ | Потрібна лише коротка генерація без фактчекінгу | RAG у такому випадку ускладнює систему і збільшує затримку. |
Бо RAG додає додаткові кроки індексації, пошуку і ранжування.
Чим відрізняється від ReAct
| ReAct | RAG | |
|---|---|---|
| Головна роль | Крокове прийняття рішень | Подача релевантних знань у контекст |
| Ключове питання | Що зробити далі? | На яких джерелах базувати відповідь? |
| Фокус | Дії та інструменти | Факти та заземлена генерація |
| Ризик без guardrails | Надлишкові виклики інструментів або цикл | Галюцинації при слабкому пошуку |
ReAct керує циклом дій агента.
RAG керує якістю знань, на яких будується відповідь.
Коли використовувати RAG (vs інші патерни)
Використовуйте RAG, коли відповідь має спиратися на зовнішні документи або базу знань у поточному запиті.
Короткий тест:
- якщо потрібно "знайти релевантні джерела і відповісти на їх основі" -> RAG
- якщо потрібно "пам'ятати контекст користувача між кроками або сесіями" -> Memory-Augmented Agent
Порівняння з іншими патернами та приклади
Швидка шпаргалка:
| Якщо задача виглядає так... | Використовуйте |
|---|---|
| Потрібно знайти знання у зовнішніх джерелах і за ними сформувати відповідь | RAG Agent |
| Потрібно зберігати та використовувати контекст користувача між кроками або сесіями | Memory-Augmented Agent |
Приклади:
RAG: "Відповідай на питання клієнта лише за внутрішньою базою політик і покажи джерела".
Memory-Augmented: "Пам'ятай, що клієнт уже обрав тариф Pro, і враховуй це в наступних відповідях".
Як комбінувати з іншими патернами
- RAG + ReAct: спочатку агент дістає факти з джерел, а потім виконує кроки вже на перевіреному контексті.
- RAG + Supervisor: якщо немає валідних джерел, відповідь блокується або йде на погодження.
- RAG + Multi-Agent Collaboration: усі агенти отримують спільний knowledge context і працюють узгоджено.
Коротко
RAG Agent:
- Шукає релевантні фрагменти знань
- Формує відповідь на їх основі
- Додає посилання на джерела
- Зменшує ризик галюцинацій
Переваги та Недоліки
Переваги
відповідає на основі ваших документів
менше вигадок моделі
можна показати джерела у відповіді
знання оновлюються без донавчання моделі
Недоліки
якість залежить від індексу та chunking
базу знань треба підтримувати
без фільтрів може тягнути нерелевантні фрагменти
FAQ
Q: Чи гарантує RAG 100% правильну відповідь?
A: Ні. RAG знижує ризик помилок, але якість залежить від індексу, пошуку і ранжування.
Q: Що робити, якщо релевантних джерел не знайдено?
A: Потрібен безпечний резервний сценарій: уточнювальне питання, відмова з причиною або ескалація людині.
Q: Чи замінює RAG донавчання?
A: Ні. RAG вирішує доступ до актуальних знань. Донавчання змінює стиль або поведінку моделі. У продакшні їх часто комбінують.
Що далі
RAG дає агенту актуальні зовнішні знання для поточного запиту.
Але як зберігати корисний контекст взаємодії між сесіями користувача?