AWS опублікував референс-архітектуру для observable agentic RAG, яка збирає у зв'язку Managed Amazon Bedrock Knowledge Base, retrieval-агента та CloudFormation-шаблон для розгортання одним кліком. Ідея проста: замість того, щоб кожна команда сама прикручувала логування й трейсинг до свого retrieval-пайплайна, AWS дає готовий каркас, де observability вбудована з першого дня, а не додається постфактум.
Для команд, які вже мучилися з дебагом «чому агент витягнув не той документ» без жодних логів проміжних кроків, це закриває конкретну біль. Agentic retrieval — коли LLM сам вирішує, які запити ставити до бази знань, скільки разів ітерувати пошук і коли зупинитися — складно дебажити наосліп, а власноруч писати трейсинг для кожного кроку агента довго і легко забути.
За даними AWS ML, гайд націлений саме на enterprise-сценарії, де retrieval має бути не лише точним, а й аудитованим — тобто кожен крок пошуку і кожне рішення агента можна відтворити й перевірити пізніше.
Що саме описує архітектура AWS?
В основі — Managed Bedrock Knowledge Base, яка виконує саму роботу з індексації, чанкінгу й векторного пошуку, і агентний шар зверху, що звертається до неї ітеративно, а не одним запитом. Розгортання всієї конструкції — інфраструктура, права доступу, підключення сервісів — описане у CloudFormation-шаблоні, тож команда отримує відтворюваний деплой замість ручного налаштування консолі AWS.
- Managed Knowledge Base відповідає за зберігання й пошук по документах;
- агентний шар формує послідовні retrieval-запити і вирішує, коли зупинити пошук;
- CloudFormation фіксує всю інфраструктуру як код, придатний для повторного розгортання;
- шар observability логує кожен крок агента для подальшого аналізу.
Чим ця observability відрізняється від звичайного логування?
Ключова відмінність — трейсинг охоплює не лише фінальну відповідь, а весь ланцюжок рішень агента: які запити він формулював, які документи отримав на кожній ітерації, і чому вирішив, що інформації достатньо. Для звичайного RAG-пайплайна з одним retrieval-викликом такий рівень деталізації надлишковий, але для agentic retrieval, де кількість кроків заздалегідь невідома, саме він дозволяє відповісти на питання «чому агент дав саме таку відповідь», а не просто зафіксувати факт помилки. Для регульованих індустрій — фінансів, права, охорони здоров'я — саме такий детальний trace-лог перетворюється на аудиторський слід, який регулятор може вимагати при перевірці рішень AI-системи.
Кому знадобиться цей шаблон уже зараз?
Найбільше виграють команди, що вже працюють на стеку AWS і будують внутрішні retrieval-системи для великих масивів документів — юридичних баз, технічної документації, корпоративних вікі. Для них шаблон економить тижні на побудові інфраструктури спостережуваності з нуля. Компаніям поза екосистемою AWS Bedrock цінність архітектури буде радше концептуальною — як референс, які саме точки пайплайна варто трейсити, незалежно від того, який vendor використовується. Водночас це не заміна власної observability-стратегії: шаблон радше задає базову планку, яку потім треба адаптувати під конкретні compliance-вимоги команди.
Висновок AiiN
За нашою оцінкою, головна цінність цього релізу не в самому Bedrock, а в тому, що AWS фактично визнає: agentic retrieval без вбудованої спостережуваності — це production-ризик, а не просто незручність. Раніше observability для RAG додавали як опцію поверх готового пайплайна; тут вона частина референс-архітектури з самого початку, і це, ймовірно, стане стандартом очікувань для будь-якого enterprise RAG-рішення найближчим часом, незалежно від хмарного провайдера.
Що таке agentic retrieval?
Agentic retrieval — це підхід, коли LLM сама керує процесом пошуку в базі знань: формулює власні запити, оцінює релевантність результатів і вирішує, чи потрібна додаткова ітерація пошуку, замість одного статичного виклику retrieval, як у класичному RAG.
Чи потрібен CloudFormation, щоб скористатися цим гайдом?
Так, шаблон розгортання побудований саме на CloudFormation — це основний спосіб відтворити описану архітектуру. Без нього доведеться вручну відтворювати всі компоненти й зв'язки між Bedrock Knowledge Base, агентним шаром і сервісами логування, що зводить нанівець головну перевагу готового референсу.
Чи працює цей підхід поза Amazon Bedrock?
Сама архітектура прив'язана до сервісів AWS, але принципи — трейсинг кожного кроку агента, логування проміжних retrieval-запитів, аудитованість рішень — застосовні до будь-якого agentic RAG, незалежно від того, на якому стеку він побудований.