Клієнт-юрист запитує асистента: «Які ризики у разі розірвання договору з субпідрядником з Німеччини, враховуючи наш рамковий контракт, чинну додаткову угоду та судову практику за останній рік?» Класичний RAG виконає одне пошукове запитання, поверне кілька фрагментів і згенерує відповідь. Може влучити, а може й ні. Agentic RAG підходить до цього інакше: розігрує запитання в кілька ходів, перевіряючи після кожного, чи вже достатньо інформації.
Що змінюється в архітектурі
У класичному підході RAG потік лінійний і незмінний: одне векторне запитання, k фрагментів у контекст, одна генерація. Це добре працює, коли запитання точне, а відповідь лежить в одному місці бази знань.
Agentic RAG замінює цей фіксований потік на цикл прийняття рішень. Агент отримує запитання, планує початковий запит, оцінює повернуті фрагменти, переформульовує запит, якщо контекст неповний або суперечливий, отримує наступну порцію даних і повторює до досягнення порогу впевненості. Лише тоді переходить до генерації.
Ключові структурні відмінності, що випливають з цієї зміни:
Багаторазові запити. Агент може надіслати 3-6 окремих запитів в одному циклі відповіді. Кожне може використовувати інше формулювання, іншу стратегію пошуку (векторний, гібридний BM25 плюс вектори, метадані) або звертатися до іншої колекції документів.
Оцінка достатності. Після кожної ітерації модель оцінює, чи зібрані фрагменти достатні для відповіді на запитання. Це не просте порогове правило: модель перевіряє узгодженість, покриття та чи бракує важливого аспекту.
Переформулювання запитів. Якщо перший запит повернув фрагменти з надто широким діапазоном, агент звужує його. Якщо контекст здається суперечливим, агент шукає вирішальний документ. Це reranking і селекція, що реалізуються активно, а не пасивно.
Межа впевненості. Якщо агент після ліміту ітерацій все ще не зібрав достатнього контексту, він не спекулює. Ескалує до людини з повідомленням: «Запитання поза покриттям бази знань або потребує верифікації експерта».
Класичний RAG проти agentic RAG
#| Параметр | Класичний RAG | Agentic RAG |
|---|---|---|
| Кількість запитів на відповідь | 1 | 2-6 (залежно від складності) |
| Затримка | 300-800 мс | 2-8 с |
| Вартість LLM | 1 виклик генерації | 2-6 викликів планування та генерації |
| Найкраще для | Прості, фактичні запитання | Складні, багатоаспектні, неоднозначні |
| Ризик галюцинацій | Середній (відсутність контексту = відсутність генерації) | Нижчий (ітерація зменшує прогалини в контексті) |
| Складність оцінки | Помірна | Висока (багато шляхів пошуку) |
| Human-gate | Опціональний | Обов’язковий при низькій довірі |
Цифри затримки та вартості — це діапазони з наших спостережень у проєктах з польськими юридичними та фінансовими документами, не гарантії. Реальні значення залежать від довжини документів, моделі та кількості ітерацій.
Де agentic RAG реально допомагає
#Агентний підхід має сенс, коли запитання має принаймні одну з цих характеристик.
Багатоаспектність. Запитання поєднує інформацію з різних джерел або різних моментів часу. Класичний RAG поверне фрагмент з одного місця; агент об’єднує кілька.
Неоднозначність. Запитання недостатньо визначене й потребує уточнення через контекст. Агент може запитати про передісторію справи, отримати загальний фрагмент, а потім зануритися в деталі.
Суперечлива інформація в базі. Коли документи в колекції містять дані з різних дат або неузгоджені процедури, класичний RAG може повернути застарілу версію. Агент ітерує й порівнює фрагменти, щоб вибрати актуальний.
Аудитованість шляху пошуку. У застосунках compliance (право, фінанси, медицина) цінністю є не лише відповідь, а й шлях до неї: які документи перевірено, в якій послідовності й чому їх виявилося достатньо. Agentic RAG природно генерує цей лог.
Для простих словникових запитань, одноетапних продуктових запитів чи навігації по FAQ класичний RAG дешевший і достатній. Немає сенсу впроваджувати агентну архітектуру там, де фіксований потік працює.
Вартість і складність оцінки
Agentic RAG не безкоштовний. Три основні витрати, на які варто звернути увагу перед впровадженням:
Більше викликів LLM. Кожна ітерація пошуку — це принаймні один додатковий виклик моделі для оцінки достатності та переформулювання запиту. Для хмарних моделей це пряма вартість токенів. Калькулятор inference на нашому сайті дозволяє оцінити, чи вигідний self-hosting для даного обсягу.
Вища затримка. Дві секунди — прийнятний час для внутрішнього асистента в середовищі B2B. Для чату підтримки клієнтів з очікуванням субсекундної відповіді agentic RAG потребує буферизації, семантичного кешування або гібридного режиму: агент для складних запитань, класичний RAG для простих.
Складніша оцінка. У класичному RAG є один набір фрагментів контексту й одна відповідь для оцінки. У agentic RAG шлях пошуку змінний. Golden set має покривати не лише кінцеву відповідь, а й якість переформулювання та рішення про достатність. Ми в Cashcrown будуємо для цього режиму окремі golden set з анотацією шляху, що повільніше, але необхідно для коректного виміру. Деталі методології описує стаття про оцінку системи RAG.
Guardrails і human-gate: де агент має зупинитися
#Цикл агента без обмежень — операційний ризик. Три guardrails, які вважаємо обов’язковими.
Жорсткий ліміт ітерацій. Агент не може шукати нескінченно. Встановлюємо верхню межу (зазвичай 5-7 ітерацій) і обробляємо перевищення як ескалацію, а не як збої. Лог містить запитання, всі ітерації та причину ескалації.
Guardrails проти галюцинацій. Перед генерацією відповіді перевіряємо, чи кожне твердження, яке модель планує включити, має підтвердження в зібраних фрагментах. Твердження без підтвердження видаляється або позначається. Те саме захищення, що описує стаття про багатокрокових агентів, тут застосовуємо до шару пошуку.
Human-gate при низькій довірі. Якщо оцінка достатності після всіх ітерацій нижча за поріг прийнятності, агент не генерує спекулятивну відповідь. Натомість повертає: «Не маю достатньо документів, щоб відповісти впевнено. Передаю експерту». Цей handoff має містити контекст: які запитання ставилися, що знайдено, чого бракує.
Observability циклу необхідна, щоб ці guardrails працювали. Логуємо кожну ітерацію: векторне запитання, повернуті фрагменти, оцінку достатності, рішення про продовження. Без цього логу немає як дебажити випадки ескалації чи калібрувати поріг впевненості.
Впровадження: від пілоту до продакшену
Типовий пілот agentic RAG для одного процесу у компанії B2B займає 4-6 тижнів. Перші два тижні — робота з даними та проектування циклу (стратегія chunking, threshold достатності, ліміт ітерацій, схема логу). Третій і четвертий тиждень — shadow mode: агент обробляє запитання паралельно з відповідями команди, розбіжності потрапляють на аналіз.
Перед запуском у продакшен будуємо golden set, специфічний для agentic RAG: для кожного запитання анотуємо очікуваний шлях пошуку та рішення про достатність, а не лише кінцеву відповідь. Це повільніше, ніж golden set для класичного RAG, але єдина методика, що дозволяє оцінювати якість планування, а не лише результат. Як будувати цей golden set у контексті багатоагентних систем описуємо окремо.
Вартість пілоту залежить від складності бази знань і вимог до анотації. Оцінку ROI впровадження агентного підходу дає калькулятор inference, який враховує вартість додаткових ітерацій LLM.
FAQ
#Чим відрізняється agentic RAG від класичного RAG?
#Класичний RAG виконує один фіксований цикл: одне векторне запитання, k фрагментів у контекст, одна генерація. Agentic RAG замінює цей потік циклом: агент планує запит, оцінює, чи достатньо результатів, переформульовує й ітерує до порогу впевненості або ліміту кроків. Різниця архітектурна, а не лише в кількості запитів: класичний RAG не може самостійно вирішувати, чи достатній контекст.
Коли agentic RAG не має сенсу?
#Для простих, одноетапних фактичних запитань, продуктових запитів, навігації по FAQ і скрізь, де користувач очікує субсекундної відповіді. Agentic RAG виправдовує себе для складних, багатоаспектних запитань, де брак контексту призводить до помилкової відповіді. Для більшості внутрішніх асистентів B2B розумний підхід — гібридний режим: класичний RAG для простих запитань, agentic для складних, з роутером, що вирішує шлях.
Як оцінювати достатність контексту в циклі агента?
Універсального методу немає. На практиці добре працюють два підходи: prompt оцінювальної моделі, що просить вказати, які аспекти запитання мають покриття в зібраних фрагментах, та пороговий показник узгодженості на основі cosinus similarity між запитанням і агрегованими фрагментами. Ми в Cashcrown калібруємо цей поріг на golden set для кожного проєкту, бо оптимальний рівень відрізняється між юридичними, технічними та комерційними базами знань.
Чи вирішує agentic RAG проблему галюцинацій?
#Частково. Ітеративний пошук зменшує ризик, що модель відповідатиме без контексту, бо агент збирає більше й краще підібраних фрагментів. Але не усуває галюцинації повністю: модель все ще може виходити за межі зібраного контексту при генерації відповіді. Guardrail, що перевіряє покриття кожного твердження в контексті, як і раніше необхідний, так само як і опція ескалації до людини при низькій довірі. Архітектуру цього шару описує стаття про корпоративний GPT на базі знань.
Як логувати шлях пошуку для аудиту?
Кожна ітерація генерує запис: оригінальне запитання, переформульоване векторне запитання, повернуті фрагменти (з ідентифікатором документа та позицією), оцінку достатності та рішення про продовження або завершення. Цей лог потрапляє до окремого сховища з ретенцією згідно з RODO. У застосунках, що підпадають під AI Act (фінанси, право, HR), лог є елементом обов’язкового аудиторського сліду, а не опціональним доповненням для дебагу.