Agentic RAG vs traditional RAG: коли потрібен агентний пошук

Traditional RAG доречний, коли запит можна стабільно перетворити на один або наперед визначений набір пошуків у відомому корпусі, а retrieved evidence одразу достатній для відповіді. Agentic RAG варто оцінювати для multi-hop питань, де наступний пошук залежить від попереднього результату, джерело треба обрати в runtime або система має перевірити достатність контексту й продовжити пошук. Це зміна control flow, а не просто інший retriever.

Починайте з найпростішого перевірюваного baseline. Query rewriting, hybrid search, metadata filters і reranking часто виправляють retrieval без planner loop. Додавайте агентність лише для сегмента, де fixed pipeline систематично не знаходить потрібні ланцюжки доказів і де виграш підтверджений на власному eval set. Назва agentic не доводить кращу якість, нижчу вартість або придатність до production.

• Один корпус і передбачуваний запит → traditional RAG baseline.
• Кілька залежних пошуків → bounded agentic retrieval candidate.
• Вибір між різними системами даних → явний source router із policy.
• Бракує доказів → пошук продовжується в межах бюджету або завершується abstain.

У fixed RAG оркестратор виконує відому послідовність: нормалізує запит, шукає кандидатів, rerank-ить, збирає evidence package і генерує відповідь. У agentic RAG модель або окремий planner обирає search tool, формує наступний query з observations, відкриває документ, переходить усередині нього та вирішує, чи потрібна ще одна ітерація. State machine, а не прихований prompt, має зберігати крок, budget, використані джерела й terminal reason.

Retrieval tool повертає структурований результат: source ID, version, access decision, snippet або location, score і provenance. Planner не отримує нових прав через те, що може викликати tool: кожен запит повторно застосовує tenant, ACL, purpose і data-class filters. Generator бачить лише дозволений evidence package, а citations будуються з фактично відкритих джерел, не з назв, які модель могла вигадати.

Multi-hop запит має залежність між фактами: спочатку знайти ідентифікатор проєкту, потім за ним відкрити бюджетну систему, далі зіставити період із планом. Запуск десятків перефразованих queries паралельно — search fanout, але не обов'язково агентність. Агентний loop виправданий, коли observation змінює наступний крок або коли до старту невідомо, який корпус містить потрібну передумову.

Задайте allowed source graph і maximum hops до виконання. Planner може перейти лише між явно дозволеними retrieval domains, не може сам додати web search або production database та не трактує знайдений документ як інструкцію. Якщо потрібний зв'язок відсутній, правильний outcome — insufficient evidence із журналом спроб, а не дедалі ширший пошук до появи правдоподібної відповіді.

Google Research формалізує sufficient context як питання, чи містить retrieved context досить інформації для правильної відповіді. У production цей verdict прив'язуйте до task contract: які claims треба підтримати, які поля обов'язкові, наскільки свіжим має бути джерело та які суперечності блокують synthesis. Самооцінка тієї самої моделі є сигналом, але не незалежним доказом повноти.

Для структурованої задачі перевіряйте coverage matrix claim-to-source, missing fields, source freshness і citation entailment. Для відкритого research додайте calibrated abstention і людський review вибірки. Iteration завершується, коли evidence contract виконаний, бюджет вичерпано, нові searches перестали додавати релевантні докази або policy заборонила наступний source. Кожна причина має окремий terminal state.

Створіть eval set із single-hop, multi-hop, cross-corpus, contradictory, stale, access-denied і unanswerable cases. Для traditional та agentic кандидатів використовуйте однаковий corpus snapshot, permissions, answer contract і model policy. Retrieval оцінюйте за evidence recall і precision; synthesis — за supported claims, citation correctness та abstention; trajectory — за правильністю routing, кількістю hops, повторними searches і policy violations.

Не переносіть цифри з vendor benchmark на власний workload. Microsoft AgenticRAG і Google Agentic RAG повідомляють результати для конкретних систем, benchmark, corpus і judge setup; вони підтверджують, що iterative tool use є перспективним design pattern, але не універсальну перевагу. Рішення про rollout приймайте за critical slices і full cost per accepted answer, а не за одним aggregate score або найкращим demo.

• Single-hop parity: агентний path не має погіршувати прості запити.
• Multi-hop completion: усі необхідні premises мають source trace.
• Access denial: planner не обходить ACL через інший retriever.
• Unanswerable: система зупиняється без fabricated bridge claim.
• Efficiency: вимірюйте tool calls, latency і cost на прийняту відповідь.

Agentic retrieval розширює attack surface: prompt injection у документі може спробувати змінити plan, malicious metadata — перенаправити routing, а непрямий ідентифікатор — витягнути дані іншого tenant. Весь retrieved content є недовіреними observations. Policy, tool schemas, source allowlist і authorization залишаються поза model-controlled context; response з tool проходить нормалізацію та маркування provenance до наступного кроку.

Обмежте total hops, fanout, opened bytes, tokens, wall time і витрати. Повтор однакового query без нового constraint блокуйте як loop. Timeout після read безпечніший за timeout після write, але може подвоїти витрати й навантаження; застосовуйте request identity та bounded retry. Agentic RAG, що лише шукає й готує відповідь, не повинен непомітно отримувати authority змінювати source systems.

Не переписуйте весь RAG. Додайте query classifier, який залишає прості cases на fixed pipeline, а складні направляє у shadow agentic path. Спочатку agentic candidate лише формує evidence package без показу користувачу. Порівняйте його з production baseline та adjudicated reference, розберіть зайві hops, пропущені permissions і unsupported claims, після чого відкрийте canary для вузького multi-hop сегмента.

Rollback — повернення routing rule на fixed pipeline, зупинка нових agentic runs і завершення або скасування активних state machines за версіонованим контрактом. Evidence packages лишаються сумісними, тому generator і citation renderer не роздвоюються. Переглядайте рішення при зміні corpus topology, retriever, model, ACL semantics або task mix; учорашня користь agentic loop не є постійною властивістю системи.

Зафіксуйте owner, query family, baseline, причину multi-hop, allowed sources, data classes, maximum hops, sufficient-context rule, eval threshold, cost ceiling, human escalation і rollback owner. Окремо збережіть версії corpus, indexes, prompts, tool schemas та model surface. Це дозволяє пояснити, чому конкретна відповідь пройшла agentic route і які докази були доступні на той момент.

Якщо команда не може назвати failure slice, де iterative retrieval вимірювано допомагає, agentic RAG ще не має production case. Якщо може, розширюйте його як контрольований retrieval режим, а не як універсальну заміну RAG. Найсильніша архітектура часто гібридна: deterministic pipeline обслуговує більшість, а bounded planner бере лише задачі, яким справді потрібне дослідження.