Agentic RAG на Amazon Bedrock - это схема, в которой в цикл поиска ставится рассуждающий агент. Перед ответом он решает три вопроса: обращаться ли к базе знаний, какую из нескольких баз выбрать и стоит ли сходить за данными повторно.
Классический одношаговый RAG таких решений не принимает. Он эмбеддит вопрос, забирает ближайшие чанки из одного индекса, отдаёт их модели и возвращает ответ. Один retrieval, одна генерация. Для простых фактологических вопросов этого достаточно, и усложнять схему нет причин.
Проблема начинается там, где вопросу мало одного обращения к корпусу. С запуском Managed Knowledge Base retrieval перестал быть одним вызовом embed-and-fetch: в Bedrock он стал агентной возможностью с многошаговым планированием, поиском через инструменты и обоснованными ответами с цитатами (разбор от AWS). Штатный механизм для этого - AgenticRetrieveStream: он раскладывает вопрос на подзадачи, ищет итеративно, делает reranking внутри сервиса и возвращает синтезированный ответ с цитатами. Как устроена декомпозиция и во что обходится такой поиск, разобрано в материале про AgenticRetrieveStream, там же приведены замеры recall на MuSiQue: до +37% на вопросах из четырёх шагов.
Что такое Agentic RAG на Amazon Bedrock и чем он отличается от одношагового RAG
Разница в точке, где принимается решение. В одношаговой схеме маршрут фиксирован кодом: всегда один индекс, всегда один запрос, всегда одна генерация. В агентной маршрут выбирает модель на каждом вопросе, а retrieval становится инструментом, который можно вызвать, а можно и не вызывать.
Три сценария, где одношаговый RAG ломается
Ответ распределён по двум корпусам. Вопрос «какие условия SLA прописаны в договоре с подрядчиком и какие пункты этого SLA он нарушил по инцидент-репортам» требует двух источников: договорного корпуса и корпуса инцидентов. Единственный retrieval вернёт половину нужного. Ответ выйдет беглым и неполным, а это хуже пустого ответа: пользователь не видит, что данных не хватило, и принимает решение по обрезанной картине.
Правильная база зависит от вопроса. Если в системе лежат корпус внутренних регламентов и корпус клиентской документации, выбор индекса определяется темой вопроса. У одного индекса нет механизма выбора: он всегда смотрит в то, что в него загрузили, и на вопросе из чужой предметной области выдаёт ближайшие чанки по совпадению формулировок. Совпадение формулировок и релевантность ответа - разные вещи.
Нужен второй взгляд после первого результата. Первый поиск часто даёт зацепку, а не ответ: название системы, номер процесса, фамилию владельца. Чтобы добрать детали, нужен ещё один запрос, уже с уточнённым текстом. В одношаговом дизайне второму обращению просто негде произойти.
Что делает агент в цикле retrieval
Агентный цикл закрывает все три сценария тремя решениями. Первое: нужен ли retrieval вообще. На просьбу переформулировать абзац ходить в базу знаний незачем, и агент отвечает сразу. Второе: какую базу использовать, если их несколько. Третье: вернуться ли за дополнительными данными после первого результата.
В разобранной реализации агент маршрутизирует запросы между двумя базами знаний. Маршрутизация живёт в промпте и описаниях инструментов, а не в жёстких if-else: агент видит список доступных MCP-инструментов и выбирает по описанию. Из этого следует практическое требование к текстам описаний: они пишутся для модели, поэтому формулировка «база по договорам и правовым рискам поставщиков» работает лучше, чем «kb-prod-02».
Архитектура системы: Managed Knowledge Base, AgentCore Gateway и Runtime
Система делится на две половины. Managed-половина отвечает за данные: Amazon Bedrock Knowledge Base с типом MANAGED берёт на себя ingestion, хранение, индексацию и retrieval. Агентную половину обеспечивает Amazon Bedrock AgentCore: Gateway публикует каждую базу знаний как инструмент Model Context Protocol (MCP), Runtime хостит рассуждающего агента (первоисточник).
Managed Knowledge Base: что сервис берёт на себя
Практический смысл managed-типа в том, чего больше не нужно делать. Коллекция и индекс Amazon OpenSearch Serverless перестают быть вашей инфраструктурой: создавать их, масштабировать и оплачивать через OpenSearch Compute Units (OCUs) не требуется.
Для сравнения, реализация end-to-end RAG на Knowledge Bases for Amazon Bedrock и AWS CDK от августа 2024 года разворачивала одношаговый дизайн руками: корпус в Amazon S3, коллекция и индекс OpenSearch Serverless, база знаний и источник данных как отдельные CDK-стеки, порядок которых выстраивался вручную. Managed-вариант убирает большую часть этой обвязки. Вместе с обвязкой уходит и часть контроля.
Пошаговая настройка Managed Knowledge Base, включая коннекторы к источникам и сравнение прямого и агентного режимов, разобрана в отдельном руководстве.
AgentCore Gateway и MCP: как база знаний становится инструментом
Gateway превращает базу знаний в вызываемый инструмент по протоколу MCP. Агент видит не «индекс OpenSearch», а инструмент с именем и описанием, и вызывает его тогда, когда считает нужным. Для мультибазовой системы это ключевая деталь: каждая база получает собственный инструмент, а выбор между ними становится частью рассуждения.
Отсюда следует приятная эксплуатационная мелочь: добавление третьей базы - это регистрация ещё одного MCP-инструмента, а не переписывание логики агента. Пока описание инструмента отличает его от соседей, маршрутизация продолжит работать.
AgentCore Runtime: где живёт рассуждающий агент
Runtime хостит агента, который вызывает MCP-инструменты через Gateway и собирает финальный ответ. Внутри инструмента работает AgenticRetrieveStream: декомпозиция вопроса, итеративный поиск по выбранной базе, внутренний reranking и синтез ответа с цитатами. Агент оперирует готовым результатом, а не сырыми чанками, и ему не нужно самому склеивать контекст из десятка фрагментов.
Поток запроса выглядит так:
- Запрос приходит в AgentCore Runtime.
- Агент решает, нужен ли retrieval, и выбирает базу знаний.
- Вызывает соответствующий MCP-инструмент через Gateway.
- AgenticRetrieveStream выполняет декомпозицию, итеративный поиск и внутренний reranking.
- Агент возвращает ответ с цитатами на источники.
Развёртывание единым AWS CDK-приложением на Python: четыре стека
Вся система разворачивается как одно CDK-приложение на Python, а не как набор шагов в консоли. Стеков четыре, и порядок между ними задан зависимостями по данным.
| Стек | Что создаёт | От чего зависит |
|---|---|---|
| kb | Managed Knowledge Base и источники данных | ни от чего |
| gateway | AgentCore Gateway с MCP-инструментами по числу баз | от kb (идентификаторы баз) |
| agent | AgentCore Runtime и конфигурация агента | от gateway (эндпоинты инструментов) |
| dashboards | дашборды CloudWatch и настройка непрерывной оценки | от kb, gateway, agent |
Стек kb: базы знаний и источники данных
Первый стек создаёт Managed Knowledge Base с типом MANAGED и подключает источники данных. Здесь же фиксируются параметры ingestion: без них дальше нечего маршрутизировать. Коллекция и индекс OpenSearch Serverless в этом стеке не создаются и по OCUs не тарифицируются.
Стек gateway: публикация баз как MCP-инструментов
Второй стек поднимает AgentCore Gateway и регистрирует каждую базу знаний как MCP-инструмент, принимая идентификаторы из стека kb. Именно здесь фиксируется контракт «одна база - один инструмент»: имя, описание и связь с конкретной базой. Если позже понадобится развести базы по разным командам или окружениям, менять придётся эту привязку, а не код агента.
Стек agent: Runtime и конфигурация агента
Третий стек создаёт AgentCore Runtime и передаёт агенту эндпоинты Gateway. Агент получает список MCP-инструментов и сам решает, какой вызвать; жёсткая карта «тема вопроса - база» не нужна. Здесь же настраивается работа с AgenticRetrieveStream.
Стек dashboards: телеметрия и оценка
Последний стек собирает дашборды CloudWatch по слоям телеметрии и настраивает OnlineEvaluationConfig для непрерывной оценки. Отдельный стек здесь не для красоты: правки в наблюдаемости не должны тянуть за собой пересборку продовых kb, gateway и agent. Зависимость обратная - дашбордам нужны идентификаторы баз, эндпоинты инструментов и логи Runtime.
Схема зависимостей в условном виде, имена конструктов и параметров в реальном приложении отличаются:
app = cdk.App()
kb = KbStack(app, "kb")
gateway = GatewayStack(app, "gateway", knowledge_base_ids=kb.ids)
agent = AgentStack(app, "agent", gateway_endpoints=gateway.endpoints)
dashboards = DashboardsStack(app, "dashboards", stacks=[kb, gateway, agent])
Наблюдаемость: семь слоёв телеметрии в CloudWatch и X-Ray
Агент, который рассуждает и извлекает данные в цикле, идёт разным путём на каждом вопросе. По умолчанию не видно ни пройденного пути, ни качества ответа: остаётся факт вызова, но не логика выбора базы (источник). Наблюдаемость становится единственным способом узнать, что система работает так, как задумано.
В разобранной реализации семь слоёв телеметрии в CloudWatch и X-Ray. Точный состав слоёв и имена метрик в исходном материале не детализированы, поэтому ниже ориентир по категориям, которые нужно закрыть, а не готовая спецификация: метрики вызовов LLM (латентность, токены, ошибки), спаны retrieval, спаны инструментов Gateway, логи Runtime, трейсы X-Ray, метрики Knowledge Base и метрики оценки качества. Конкретные названия сверяйте с документацией сервиса до того, как строить алерты.
Как связать эти сигналы с маршрутизацией между базами и цитированием, подробно разобрано в материале про агентный поиск в Managed Knowledge Base с наблюдаемостью.
Подводный камень: тройное дублирование спанов на один вызов LLM
Телеметрия включается сразу на нескольких уровнях: Runtime, Gateway, SDK. В результате один вызов LLM порождает тройное дублирование спанов в X-Ray, и трейс выглядит так, будто агент сделал три вызова вместо одного.
Что с этим делать. Агрегировать по trace id и считать уникальные обращения к модели, а не сырое число спанов. Фильтровать по источнику спана, если нужен срез по конкретному уровню. И не брать количество спанов за метрику нагрузки: на дашборде она завышена кратно, а при деградации сервиса поведёт себя нелинейно.
Подводный камень: разный формат dimension для knowledge-base id
Формат dimension для идентификатора базы знаний различается между источниками метрик. Один источник отдаёт id в одном виде, другой в другом, и на общем дашборде метрики по одной и той же базе не склеиваются: вместо одной линии получается несколько неполных.
Лечится на уровне конфигурации. Нормализуйте id в CDK-описании дашбордов и приводите к одному виду до публикации. Для собственных метрик задавайте dimension явно, а не полагайтесь на значение по умолчанию. Проверять стоит заранее: соберите дашборд до подключения реального трафика, пока расхождение видно на пустых графиках и не мешает разбору инцидента.
Оценка качества: on-demand и непрерывная через OnlineEvaluationConfig
Наблюдаемость отвечает на вопрос «что произошло». Оценка отвечает на другой: «был ли ответ хорошим». В разобранной системе есть обе формы: разовый прогон on-demand и непрерывная оценка через OnlineEvaluationConfig.
Когда запускать on-demand оценку
Разовый прогон на подготовленном наборе вопросов имеет смысл перед изменениями, которые двигают качество:
- сменили модель генерации или модель планировщика;
- переписали системный промпт агента или описания MCP-инструментов;
- добавили новую базу знаний в Gateway;
- изменили chunking или параметры ingestion в Managed Knowledge Base.
Трактуйте прогон как регрессионный тест перед деплоем. Конкретные метрики и пороги в исходном материале не приведены, поэтому набор определяйте под задачу: попадание в нужный документ, полноту ответа, корректность цитаты. Главное, чтобы набор вопросов не менялся между прогонами, иначе сравнивать будет нечего.
Как работает непрерывная оценка
OnlineEvaluationConfig оценивает выборку реального трафика на постоянной основе, а результаты уходят в дашборды из стека dashboards и в алерты. Разница с разовым прогоном принципиальная: on-demand показывает, что вы не сломали систему своей правкой, непрерывная оценка ловит деградацию, которую никакая правка не объясняет. Поплыли формулировки в источниках, обновился корпус, изменилось распределение вопросов от пользователей.
Без непрерывной оценки такая деградация остаётся незамеченной до момента, когда пользователи начнут жаловаться. К этому времени в трейсах уже тысячи ответов, и понять, где именно просело качество, дорого.
Ограничения managed-подхода против DIY-векторной базы
Managed-схема снимает операционную нагрузку. Ingestion, индексацию и хранение делает сервис, OpenSearch Serverless и биллинг по OCUs уходят из вашей зоны ответственности. Взамен вы отдаёте вендору контроль над индексом, параметрами retrieval и версиями компонентов.
На практике это означает следующее. Вы не выбираете эмбеддинг-модель под свои данные произвольно, не настраиваете гибридный поиск по своему усмотрению и не управляете структурой индекса. AgenticRetrieveStream делает reranking внутри сервиса, поэтому точка вмешательства в этот reranking ограничена. Если бизнес-логика требует нестандартного скоринга или собственной нормализации чанков, остаётся либо жить с тем, что есть, либо строить поиск самостоятельно.
DIY-векторная база даёт выбор эмбеддингов, гибридного поиска и тонкой настройки параметров. Плата за это конкретная: эксплуатация, миграции схемы, мониторинг индекса, ручной контроль качества после каждой переиндексации.
Managed-подход подходит, если:
- в команде нет выделенного ML- или инфра-инженера;
- приоритет - быстрый выход в прод, а не вылизывание retrieval;
- корпуса типовые: регламенты, договоры, документация продукта, база поддержки;
- нужна прослеживаемость ответов через цитаты без собственной обвязки.
Стоит идти в DIY, если:
- нужны собственные эмбеддинги или доменная дообученная модель поиска;
- требуется специфический retrieval: поиск по графу сущностей, строгие фильтры по метаданным, собственный алгоритм ранжирования;
- полный контроль над индексом обязателен по требованиям аудита или локализации данных.
Отдельный случай - аналитические вопросы, которые плохо ложатся на чанковый поиск по своей природе. Для них существуют другие архитектуры, например сжатие базы знаний под аналитические запросы, где маршрутизация между фактологическим и аналитическим режимом решается на входе.
Кому подходит эта архитектура и с чего начать
Сведите решение к четырём вопросам. Есть ли у вас несколько корпусов, вопросы по которым пересекаются. Нужна ли прослеживаемость ответов: цитата на документ часто важнее красивого текста. Устраивают ли ограничения managed-подхода из предыдущего раздела. И действительно ли нужен агентный режим, ведь для большого класса вопросов одношагового дизайна достаточно.
Если ответы сложились в «да», первый шаг конкретный: разверните четыре стека CDK на тестовом корпусе, включите телеметрию и прогоните on-demand оценку до того, как подключать реальный трафик. Так вы получите базовую линию качества и увидите, где именно агент выбирает не ту базу, на живых вопросах, а не в презентации.
Похожий паттерн с MCP-инструментами в Gateway и изоляцией данных по токену разобран в кейсе AvioBook на AgentCore: полезно, если базы знаний разъезжаются по разным аккаунтам и командам.