Агентське отримання інформації та достатній контекст: коли RAG не знає достатньо
Стандартний RAG часто відповідає занадто рано. Агентні механізми пошуку аналізують джерела, оцінюють докази та продовжують пошук, поки контекст справді не стане достатнім.
Джерела: When RAG Doesn’t Know Enough: Why Agentic Retrieval Needs Sufficient Context
Векторний пошук — це не та причина, яка знищує більшість систем RAG. Справжньою проблемою під час роботи є ситуація, коли модель надає відповідь, проте у неї бракує достатньо доказів. Це не означає, що не знаходиться жодної інформації: система зазвичай знаходить щось, фрагменти виглядають релевантними, а відповідь є плавною та впевненою. Проте вона є неповною, оскільки необхідні факти розташовані у кількох документах, системах, таблицях, заявах, посібниках, журналах або графічних зв’язках.
Класичний підхід передбачає один прохід:
User question → embed query → retrieve top-k chunks → send to LLM → generate answer
Це підходить для простих запитань, але корпоративні запитання рідко бувають такими. Політика знаходиться в одному документі, а її винятки — в іншому. Запит описує інцидент, примітка до випуску пояснює змінену поведінку, рядок у базі даних містить поточний статус, ребро графа відображає залежність, таблиця у PDF містить фактичні цифри, а запис минулої розмови фіксує те, що користувач вже намагався зробити. Якщо отримувати лише кілька перших схожих фрагментів, модель відповідає занадто швидко. RAG не мертвий. Йому потрібно розпізнавати, коли у нього недостатньо інформації.
Передчасні відповіді
Багато систем RAG працюють без проблем. Вони ніколи не кажуть, що недостатньо доказів. Вони надають відповідь — витончену, структуровану та переважно правдоподібну, але хибну.
Уявіть собі співробітника внутрішньої підтримки, якого запитують, чому експорт у Acme зламався після міграції робочого простору. Примітивний інструмент пошуку знаходить одну сторінку з інструкціями щодо усунення проблем з експортом та стверджує, що бракує дозволів. Можливо, це частково правда. Повна відповідь ґрунтується на записах про міграцію в Acme, примітках про зміни у дозволах на експорт, заявці з минулого тижня, звіті про внутрішній інцидент, прапорцях функцій облікового запису та діаграмі залежностей, яка вказує на сервіс експорту. Один документ ніколи не зможе містити все це, тому процес пошуку має діяти більше як у співробітника підтримки.
Що означає достатній контекст
Достатній контекст означає, що наявні докази дозволяють дати впевнену відповідь. Не мають значення слабко пов’язані фрагменти, високий рівень схожості чи п’ять отриманих документів. Перед генерацією система повинна перевірити, чи має вона політику, винятки, поточний стан, авторитетні дані, зв’язки між ентитетами, достатню інформацію для пояснення причини, а не лише симптому, а також спосіб посилання на результат. Якщо чогось бракує, вона повинна повернутися та знову провести пошук. Саме це і є переходом від класичного RAG до агентного пошуку.
Від top-k до пошуку доказів
Стандартний RAG розглядає пошук як єдиний крок: знаходить інформацію один раз та відповідає. Агентний пошук розглядає його як робочий процес:
Retrieve once → answer
Plan → retrieve → inspect → judge evidence → retrieve again → answer
Ніщо не зобов’язує модель відповідати на основі того, що повернулося першим. Вона діє скоріше як аналітик, який шукає інформацію, відкриває документи, порівнює їх, визначає зв’язки, перевіряє дані та відповідає лише тоді, коли контекст є достатнім.
Чому агенти підвищують ризики
Чат-бот відповідає на запитання. Агент приймає рішення: обирає інструменти, викликає API, оновлює записи, створює заявки, рекомендує дії, просить схвалення чи продовжує виконання багатьох кроків. Неповний контекст тоді поширюється далі:
Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action
Агент з обробки даних не повинен просто надсилати схожий документ. Він має бути здатний зазначити, де знаходиться політика, виняток, стан активного облікового запису та відповідна подія, і стверджувати, що ці докази вирішують питання. Це інша архітектура.
Куди рухається технологія агентського пошуку
Нещодавні дослідження в галузі RAG та графів знань вказують на пошук, який контролюється агентом, враховує структуру графа, оцінюється за наявністю доказів та підтримується пам’яттю. Не кожній системі потрібен величезний граф знань, але шар пошуку потребує більшої інтелектуальності, ніж просте вставлення запиту та повернення топ-k результатів. Існує кілька важливих напрямків розвитку.
Пошук між корпусами
Корпоративні знання не знаходяться в одній організованій базі даних типу векторів. Вони розкидані по Google Drive, Confluence, Notion, Slack, Jira, GitHub, складах, заявах підтримки, панелях керування, внутрішніх API, документації до продуктів та PDF-інструкціях. Хороша система має вміти вирішувати, де шукати спочатку. Механізм пошуку може класифікувати запит як політику, поведінку продукту, проблему, специфічну для клієнта, інцидент, фінансовий показник чи технічну залежність, та направляти його відповідним чином. Пошук у всьому є дорогим, а пошук у неправильному місці — ще гіршим.
Пошук як інструменти
Один корисний підхід полягає у тому, щоб представляти пошук як контрольований набір інструментів замість фіксованого результату:
search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)
Це відображає процес людського дослідження: пошук, відкриття перспективних результатів, перегляд розділів, уточнення запиту та порівняння доказів. Модель міркувань керує цим процесом, але лише в межах обмеженого набору інструментів, що забезпечує гнучкість без необмеженого доступу.
Проходження по графу знань
Векторний пошук знаходить семантично схожий текст, тоді як багато практичних запитань ґрунтуються на взаємозв’язках. Які клієнти піддаються впливу цього сервісу? Які продукти залежать від цього API? Яка політика діє в цьому регіоні? Яка версія програми спричинила цей інцидент? Це запитання, пов’язані з контекстом, а не зі схожістю. Граф може безпосередньо поєднувати ентитети:
Customer → Workspace → Feature Flag → Service → Incident → Release Note
Агент може переходити за цими посиланнями замість того, щоб сподіватися, що потрібний матеріал з’явиться серед перших результатів. Це свідчить скоріше про навігацію, ніж про пошук інформації. Використовуйте цей підхід там, де важливі взаємозв’язки, а ігноруйте його, якщо це лише звучить складно.
Оцінка достатності доказів
Після пошуку система має визначити, чи достатні докази. Чи відповідає вона на запитання безпосередньо? Чи відсутні певні елементи, такі як ентитети, дати чи джерела? Чи суперечать одне одному джерела? Чи має походження інформації справжню автентичність? Чи можна посилатися на цю відповідь? Якщо докази слабкі, система продовжує пошук:
Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source
Цей цикл запобігає передчасним відповідям та полегшує дебаггінг, оскільки можна побачити, чому агент здійснив ще одну пошукову операцію.
Графи контексту та пам’ять агента
RAG зазвичай працює з зовнішніми знаннями, але агентам також потрібна пам’ять: що запитував користувач раніше, що було знайдено під час пошуку, які докази були прийняті, що було вирішено та які припущення залишаються відкритими. Простий буфер розмови тут не підійде. Кращий підхід — пов’язати пам’ять із елементами та рішеннями, щоб сам слід міркувань ставав частиною пам’яті:
User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch
Наступного разу, коли з’явиться схожа проблема, агент не починатиме роботу з нуля, що має велике значення для агентів, які працюють протягом тривалого часу.
Багатомодальний та обізнаний у документах RAG
Більша частина корпоративних знань має формат, відмінний від звичайного тексту. Вони зберігаються у PDF-файлах, таблицях, скріншотах, діаграмах, формулах, сканах, графіках, презентаціях та формах. Звичайне розділення на частини порушує структуру: таблиці перетворюються на хаотичний текст, формули втрачають свій контекст, діаграми стають результатом OCR-розпізнавання, а розділи відокремлюються від підписів, які їх пояснюють. Система, обізнана у документах, розуміє текст, таблиці, ілюстрації, макет, ієрархію заголовків, підписи, поля форм та спосіб взаємозв’язку візуальних елементів з прозовим текстом. Найбільше від неї залежать фінансова, медична, виробнича, юридична, страхова галузі та технічна документація.
Бюджети інструментів та контексту
Інструменти також споживають контекст. Якщо завантажити десятки інструментів для пошуку, аналізу графів, роботи з базами даних та пошуку, їхні схеми конкурують із доказами:
Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window
Тому агентний RAG потребує середовища виконання, яке враховує бюджет, щоб вирішувати, які інструменти показувати, скільки фрагментів включати, чи потрібно узагальнювати результати роботи інструментів, та, що найважливіше, коли зупинитися. Мета — отримати достатню кількість інформації, а не безкінечно.
Архітектура для продакшну
У сукупності система для агентного пошуку більше нагадує план керування, ніж конвеєрний ланцюг:
User Question
↓
Intent + Risk Classifier
↓
Retrieval Planner
↓
Source Router
├── Enterprise Search
├── Vector Search
├── Keyword Search
├── Knowledge Graph
├── Structured Data
├── Document Parser
└── Agent Memory
↓
Evidence Inspector
↓
Sufficiency Gate
├── If insufficient → refine query / follow graph / open document
└── If sufficient → generate answer
↓
Answer with Evidence Trace
Практичний порада простіша: не дозволяйте RAG відповідати, поки у нього немає достатньо доказів.
Справа Acme, від початку до кінця
Коли запитують, чому експорт зазнав невдачі після міграції робочого простору, стандартний RAG завантажує посібник з усунення проблем експорту та часто задавані запитання щодо міграції та відповідає, що експорт, ймовірно, зазнав невдачі через відсутність прав. Агентська система проводить розслідування:
- Шукає в документації підтримки інформацію про невдачі експорту.
- Шукає у примітках до випуску зміни, пов’язані з міграцією робочого простору.
- Відкриває конфігурацію облікового запису клієнта.
- Перевіряє стан флагів функцій.
- Шукає історію інцидентів.
- Простежує граф залежностей від сервісу експорту до сервісу прав.
- Вирішує, чи є тепер достатньо доказів.
- Пише відповідь із посиланнями на джерела.
Отримана відповідь: Acme було переміщено до нової моделі робочого простору, тоді як сервіс експорту продовжував перевіряти старий шлях дозволів. Прапорець робочого простору увімкнений, проте політика експорту так і не була оновлена, тому рішенням є оновлення цієї політики для моделі робочого простору. Саме по собі сильніша модель не змінила результату — це зробило краще збирання доказів.
Що створювати спочатку
Якщо у вас вже є система RAG, не потрібно все перебудовувати. Виконайте ці кроки у порядку:
- Додайте перевірку достатності. Перед генерацією запитайте, чи достатньо отриманих доказів для цього конкретного запитання, і якщо ні, або проведіть ще одне пошукове запитання, або поставте користувачеві уточнююче запитання.
- Додайте механізм маршрутизації джерел. Щоразове пошук у кожному джерелі є марним. Спочатку класифікуйте запит: питання щодо політик — до документів з політиками, проблеми клієнтів — до заявок разом із станом облікового запису, технічні несправи — до документів, журналів та графа послуг, а питання щодо метрик — до семантичного шару.
- Додайте інструменти пошуку, такі як
search,open,find,summarize,follow_entity_relationтаquery_structured_record, щоб процес пошуку став ітеративним. - Додайте алгоритми просування по графу, де відповіді залежать від власності, залежностей, лінійності, причинно-наслідкових зв’язків, ієрархії, багатоетапних посилань чи винятків у політиках.
- Зберігайте структуру документа. Для PDF, звітів, слайдів, таблиць та діаграм використовуйте парсинг, який бере до уваги структуру документа, та зберігайте її, а не просто розділяйте на фрагменти.
- Зберігайте запис доказів, який фіксує джерела, що були переглянуті, документи, відкриті, факти, які були прийняті, виявлені прогалини та причину, чому система вирішила, що інформації достатньо. Саме цей запис забезпечує довіру до агентних систем типу RAG.
Що не варто надмірно розробляти
Це може стати занадто складним, і не кожна технологія підходить для кожного випадку використання. Простий пошук у форматі FAQ, ймовірно, не потребує графа знань, документи у простому текстовому форматі не потребують багатомодального аналізу, одноразові запитання та відповіді не потребують довгострокової пам’яті у вигляді графа, а повністю внутрішні домени не потребують зовнішнього пошуку. Потрібно запитати себе, якого типу доказів потребує це запитання. Для одного чистого документа може вистачити звичайної системи RAG. Коли відповідь вимагає врахування джерел, взаємозв’язків, пам’яті та поточного стану, тоді агентний механізм пошуку стає необхідним через свою складність.
Зміна підходу
Текущий розвиток технологій RAG не спрямований на заміну векторного пошуку. Він додає можливості для керування процесом отримання інформації. Векторний пошук залишається важливим, як і пошук за ключовими словами. Графи знань мають значення там, де існують взаємозв’язки, аналіз документів — там, де є структура, а пам’ять — там, де агент працює протягом певного часу. Завданням у практичному застосуванні є їх поєднання. Наступне покоління цих технологій виглядатиме інакше:
Vector DB → top-k chunks → LLM
і ще щось подібне:
Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer
RAG не зазнає невдачі лише тоді, коли завантажує погані фрагменти. Він також зазнає невдачі, коли завантажує частково корисні фрагменти та надає відповідь раніше часу. Для простих запитань метод top-k все ще може бути ефективним. Однак для корпоративних, дослідницьких, сервісних, операційних систем та агентів, які працюють із великою кількістю документів, потрібен більш потужний механізм пошуку:
plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded
Це перехід від стандартного RAG до агентського пошуку інформації. Це не тому, що RAG вже не використовується. Продуктові агенти повинні розпізнавати моменти, коли у них недостатньо знань.
Пов’язана література
- RAG, Fine-Tuning чи Agents: який рівень та порядок використання для створення системи — практичне порівняння методів пошуку, налаштування параметрів та використання агентів з урахуванням витрат, часу відгуку, можливих проблем, загальноприйнятих правил та прикладу асистента з кадрів, який ілюструє порядок створення системи.