AWS собрала наблюдаемый поиск для агентов на Amazon Bedrock

AWS представила референсную архитектуру enterprise agentic retrieval, в которой агент не ограничивается одним поиском по одной базе. Он анализирует вопрос, выбирает подходящую Amazon Bedrock Managed Knowledge Base, запускает многошаговый поиск через `AgenticRetrieveStream`, при необходимости повторяет retrieval и возвращает ответ с цитатами. Вся цепочка разворачивается четырьмя связанными AWS CloudFormation stacks, включая данные, AgentCore Gateway, runtime агента и dashboards.

Сценарий построен на двух раздельных корпусах — финансовом отчёте и документе о торнадо. Каждая knowledge base становится отдельным MCP tool через нативный коннектор AgentCore Gateway. Поэтому модель выполняет реальную маршрутизацию между доменами, а метрики по каждому корпусу не смешиваются. Внутри выбранной базы `AgenticRetrieveStream` самостоятельно разбивает сложный вопрос на подзапросы, выполняет итеративный retrieval и синтезирует grounded response.

Управляемая база вместо собственного vector store

В архитектуре используется Managed Knowledge Base типа `MANAGED`. Amazon Bedrock берёт на себя ingestion, хранение, indexing, embedding, reranking и retrieval, поэтому команде не нужно разворачивать, масштабировать и обновлять отдельную vector database. AWS отдельно указывает, что `AgenticRetrieveStream` и интеграция с AgentCore Gateway доступны для managed-варианта, но не для customer-managed knowledge base.

Решение разделено на четыре слоя инфраструктуры. Stack `01-knowledge-bases` создаёт S3 bucket, две базы, data sources, IAM и начальную загрузку документов. `02-agentic-gateway` публикует инструменты поиска через MCP без Lambda и дополнительного контейнера. `03-agent-runtime` собирает инструментированный Strands agent image через CodeBuild, запускает его в AgentCore runtime и включает online evaluation. Последний stack создаёт два CloudWatch dashboards.

Семь уровней вместо одного графика latency

AWS распределяет наблюдаемость по семи уровням. Первый показывает вызовы, ошибки и throttling отдельных knowledge bases; второй — результат ingestion. Третий оценивает использование найденного контекста, grounded coverage и долю дубликатов. Четвёртый измеряет объём и задержку Gateway/MCP calls, пятый хранит OpenTelemetry span tree всего reason-and-act цикла, шестой считает token usage по сессиям и моделям, седьмой собирает оценки корректности, faithfulness, выбора инструмента и релевантности ответа.

Часть сигналов появляется автоматически: AgentCore runtime инструментирует шаги и отправляет traces и metrics в CloudWatch и AWS X-Ray. Другие custom metrics публикует сопровождающий notebook. Один dashboard показывает agentic workflow целиком, включая вызовы агента, retrieval, LLM и Gateway; второй собирает стоимость и нагрузку по каждой knowledge base — размер индекса, число запросов, tool calls и использование токенов.

Качество проверяется до релиза и на живом трафике

Для on-demand evaluation notebook передаёт spans в AgentCore Evaluate и запускает LLM-as-judge по критериям Correctness, Faithfulness и Tool-Selection Accuracy. Этот режим предназначен для разработки и проверки выбранного набора сессий. В production CloudFormation создаёт `AWS::BedrockAgentCore::OnlineEvaluationConfig`: конфигурация автоматически выбирает часть живых сессий и оценивает их, добавляя Response Relevance к остальным показателям.

В демонстрации AWS установила `SamplingPercentage: 100`, чтобы быстро заполнить графики, но прямо предупреждает, что это не production-рекомендация. Каждый отобранный сеанс вызывает LLM-as-judge, поэтому расходы растут вместе с трафиком и долей выборки. Практический шаблон — чаще использовать on-demand checks во время разработки, а после запуска включить непрерывную оценку с умеренным sampling rate, согласованным с бюджетом и внутренними правилами.

Развёртывание остаётся воспроизводимым

Пример разворачивается скриптом `./scripts/deploy.sh us-west-2 bmkb-ml21427`. Наиболее долгий этап — сборка контейнера агента через CodeBuild, на которую AWS предлагает закладывать примерно 8–10 минут. После завершения все четыре stacks должны перейти в `CREATE_COMPLETE`. Для traces уровней 5–7 требуется заранее включить CloudWatch Transaction Search; локальный Docker не нужен, поскольку image собирается в облаке.

AWS показывает архитектуру на небольших учебных данных, а не публикует benchmark для произвольной корпоративной нагрузки. Её ценность в другом: data plane, routing, tracing, quality evaluation и cost signals описаны как одна воспроизводимая система. При переносе в production команде всё равно придётся подключить свои corpora, настроить IAM и VPC, определить тестовые вопросы, пороги качества и приемлемую стоимость наблюдения.

Почему это важно

Agentic RAG усложняет эксплуатацию именно там, где классический dashboard обычно заканчивается. Итоговый ответ может выглядеть убедительно, хотя агент выбрал не ту базу, повторил дорогой retrieval, потерял часть контекста или использовал неподходящий инструмент. Семислойная схема связывает пользовательский результат с маршрутом, traces, токенами и оценкой качества, поэтому ошибку можно искать по этапам, а не угадывать по финальному тексту.

Практический вывод — проектировать наблюдаемость одновременно с агентом. Для каждой knowledge base стоит разделять ingestion health и query health, сохранять полный trace выбора инструментов, считать стоимость на сессию и иметь фиксированный набор on-demand tests. Continuous evaluation полезна как датчик регрессий, но не должна бездумно охватывать 100% трафика. А CloudFormation или другой IaC должен поднимать не только runtime, но и dashboards, alarms и evaluation configuration — иначе production останется формально работающим, но фактически непрозрачным.