Публикация AiManual

Как собрать агентный поиск в Amazon Bedrock Managed Knowledge Base: маршрутизация между базами знаний и наблюдаемость

Практический разбор агентного поиска в Amazon Bedrock Managed Knowledge Base: как маршрутизировать запросы между несколькими базами знаний, связать AgentCore и

14 мин чтения 31.08.2026

Коротко

Что будет в материале

01
Коротко: когда агентный поиск Amazon Bedrock оправдан
02
Чем agentic retrieval Amazon Bedrock отличается от классического RAG
03
Архитектура: мультибазовый поиск знаний на Amazon Bedrock
04
Маршрутизация между базами знаний Amazon Bedrock: правила, а не магия

Коротко: когда агентный поиск Amazon Bedrock оправдан

Агентный поиск нужен, когда вопрос пользователя может относиться к нескольким изолированным корпусам знаний. Агент выбирает подходящую Amazon Bedrock Knowledge Base, при необходимости обращается к нескольким базам, проверяет полноту контекста и формирует ответ с цитатами. Такой подход подходит для корпоративных систем, где продуктовая документация, внутренние регламенты и база поддержки живут отдельно.

Для одной небольшой базы документов классический RAG обычно проще: он быстрее диагностируется, требует меньше вызовов модели и дает более предсказуемую стоимость. Agentic retrieval оправдан, когда выбор источника и последовательность поиска сами становятся частью задачи. Дополнительная логика увеличивает задержку, расходы и требования к наблюдаемости.

Что получит читатель после разбора

модель архитектуры с несколькими Knowledge Bases и маршрутизацией запросов;
контракт, по которому агент понимает назначение каждой базы;
последовательность подготовки данных, IAM, CloudFormation и runtime;
каркас модулей для инфраструктуры без привязки к неподтвержденным именам ресурсов AWS;
набор операционных и качественных сигналов для CloudWatch, X-Ray и OpenTelemetry;
тестовый набор вопросов, который выявляет ошибки маршрута, поиска, цитирования и доступа.

Конкретные типы CloudFormation-ресурсов, свойства AgentCore, Gateway, Knowledge Bases и имена метрик нужно сверять с актуальной документацией AWS для выбранного региона. Ниже описана архитектурная схема, которую можно адаптировать после такой проверки.

Чем agentic retrieval Amazon Bedrock отличается от классического RAG

Классический RAG: один корпус, один путь поиска

RAG, Retrieval-Augmented Generation, сначала извлекает релевантные фрагменты из заданного источника, затем передает их языковой модели для генерации ответа. Типовой поток выглядит так:

пользователь отправляет вопрос;
retriever ищет фрагменты в выбранном корпусе;
приложение передает найденный контекст модели;
модель формирует ответ, а приложение при необходимости показывает источники.

У такой схемы три практических преимущества: фиксированный маршрут, ограниченное число операций и понятная точка диагностики. Если ответ неверен, команда проверяет качество документов, параметры поиска, фильтры и инструкцию модели.

Слабое место появляется при смешанных доменах. Запрос о порядке доступа к функции продукта может требовать продуктовой инструкции и внутреннего регламента. Один заранее выбранный retriever не принимает решение, где искать дальше.

Агентный поиск: сначала выбрать действие, затем искать

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

Упрощенная цепочка выглядит так:

вопрос пользователя
  -> классификация домена
  -> выбор Knowledge Base
  -> поиск фрагментов
  -> проверка достаточности контекста
  -> дополнительный поиск или уточнение
  -> ответ с цитатами

Агентность не исправляет плохой корпус документов. На результат влияют структура файлов, качество разбиения на фрагменты, метаданные, фильтры доступа, описание инструментов, инструкция агента и выбранная модель. Ошибка на первом шаге способна привести к лишним вызовам или к уверенной работе с неподходящим источником.

Подробный разбор многошагового поиска и различий между одношаговым Retrieve API и агентным сценарием опубликован в статье про AgenticRetrieveStream в Amazon Bedrock.

Когда несколько баз знаний лучше одной большой

Разделять корпус стоит по устойчивым границам, а не по удобству раскладки файлов. Для enterprise-системы логичны три домена:

База знаний	Тип документов	Причина отдельного контура
Продуктовая	Руководства, API-описания, release notes	Свой жизненный цикл и версии продукта
Внутренние регламенты	Политики, инструкции доступа, процедуры	Ограниченный круг пользователей и отдельный владелец
Поддержка	История решений, FAQ, типовые инциденты	Частые обновления и другой профиль запросов

Разные владельцы данных, права доступа, требования к аудиту, языки документов и частота обновлений оправдывают разделение. Если документы описывают один домен, имеют одинаковые правила доступа и обновляются одним процессом, несколько баз могут лишь усложнить выбор источника.

Архитектура: мультибазовый поиск знаний на Amazon Bedrock

Какие компоненты должны быть в схеме

Удобно разделить систему на семь уровней:

Источники данных. Файловое хранилище, корпоративные системы или загрузки от владельцев документов.
Ingestion. Проверка файлов, нормализация, разбиение на фрагменты, добавление метаданных и запуск индексации.
Knowledge Bases. Отдельные управляемые контуры поиска по доменам.
Agent runtime. Среда, где выполняется логика агента, вызывается модель и сохраняется контекст запроса.
Router. Правила выбора базы, параллельного поиска и остановки.
Контур безопасности. IAM-роли, политики, фильтры по пользователю, подразделению, tenant и версии продукта.
Наблюдаемость. Логи, метрики, трассировки, оценки качества и дашборды.

Поток запроса можно представить так:

клиент
  -> API или Gateway
  -> AgentCore Runtime
  -> router
  -> Knowledge Base A / Knowledge Base B / Knowledge Base C
  -> модель генерации
  -> слой цитирования
  -> ответ и телеметрия

AgentCore Runtime и Gateway в этой схеме обозначают прикладные компоненты, а не универсальный готовый контракт для любого аккаунта. Их конкретные интеграции, поддерживаемые регионы и параметры нужно подтвердить перед развертыванием.

Amazon Bedrock Managed Knowledge Base снимает часть инфраструктурной работы вокруг поискового контура, но не принимает за команду решения о границах доменов, модели доступа и критериях хорошего ответа. CloudFormation помогает описать повторяемую конфигурацию, а IAM задает, какие роли могут загружать документы, запускать ingestion и выполнять retrieval.

Где проходит граница между управляемым сервисом и вашей ответственностью

Зона	Что дает managed-компонент	Что должна контролировать команда
Поиск	Предоставляет настроенный управляемый контур Knowledge Base	Проверяет релевантность, полноту и фильтры
Данные	Поддерживает выбранный процесс подключения источников	Удаляет дубликаты, следит за версиями и актуальностью
Доступ	Работает с заданными ролями и политиками	Проектирует least privilege и серверную проверку прав
Агент	Запускается в выбранном runtime	Ограничивает шаги, описывает инструменты и обрабатывает сбои
Качество	Может предоставлять технические сигналы и поддерживаемые механизмы оценки	Формирует тестовый набор и принимает решения по результатам

Развернутый обзор Managed Knowledge Base, прямого и агентного поиска можно использовать как соседний материал: практическое руководство по Amazon Bedrock Managed Knowledge Base.

Почему цитаты нужно проектировать до запуска

Цитата повышает проверяемость ответа только тогда, когда пользователь может понять, что именно послужило основанием для вывода. Для каждого документа желательно хранить понятное название, версию, дату актуальности, владельца и признак статуса.

Пример полезной ссылки на фрагмент содержит четыре элемента: название документа, раздел, версию и дату обновления. Ссылка на файл без названия раздела плохо помогает оператору, особенно если в базе лежат несколько редакций инструкции.

Проверьте четыре сценария:

ответ полностью подтверждается одним документом;
ответ требует фрагментов из двух доменов;
источники противоречат друг другу по версии или дате;
подтвержденного контекста нет.

В последнем случае агент должен сообщить об отсутствии достаточного основания или задать уточняющий вопрос. Генерация правдоподобного текста без цитаты не решает задачу поиска знаний.

Маршрутизация между базами знаний Amazon Bedrock: правила, а не магия

Опишите контракт каждой базы знаний

Роутер работает стабильнее, когда каждая база имеет короткое и конкретное описание. Для нее полезно зафиксировать карточку:

Поле	Пример содержания
Домен	Документация публичного API продукта
Допустимые вопросы	Синтаксис метода, параметры, ограничения версии
Исключения	Права сотрудников, внутренние процедуры, история инцидентов
Фильтры	Версия продукта, язык, статус публикации
Владелец	Команда, которая утверждает документы
Обновление	Событие публикации новой версии

Описание «отвечает на вопросы о продукте» слишком широкое. Формулировка «отвечает о параметрах API и ограничениях версии, но не о правах сотрудников» дает агенту более четкую границу.

Три стратегии: один маршрут, параллельный поиск и уточняющий вопрос

Один маршрут подходит для однодоменных вопросов. Запрос «какой параметр включает потоковую выдачу?» направляется в продуктовую базу. Второй домен в таком случае не нужен.

Параллельный поиск нужен для составного вопроса. Запрос «как получить доступ к функции и какие параметры передать в API?» может потребовать внутреннего регламента и продуктовой документации. Агент объединяет контекст, но сохраняет происхождение каждого утверждения.

Уточняющий вопрос снижает риск случайного выбора при неоднозначной формулировке. На запрос «как настроить доступ?» система может спросить, идет ли речь о доступе пользователя к продукту или о правах приложения на вызов API.

Стратегия	Полнота	Задержка и стоимость	Риск
Один маршрут	Достаточна для узкого вопроса	Ниже	Ошибочный выбор домена
Параллельный поиск	Выше для составных вопросов	Выше из-за нескольких обращений	Конфликт источников
Уточнение	Зависит от ответа пользователя	Добавляет один пользовательский шаг	Потеря темпа диалога

Метаданные и доступы не должны обходить роутер

Метаданные нужны для двух задач: улучшить выбор источника и ограничить выдачу. В запросе могут участвовать tenant, подразделение, версия продукта, язык, статус документа и уровень доступа.

Значение, пришедшее от клиента, нельзя считать доказательством его прав. Сервер должен получить идентичность из принятого механизма аутентификации, сопоставить ее с политиками и сам сформировать фильтр retrieval. IAM-политики, фильтры Knowledge Base и прикладные проверки должны дополнять друг друга.

Пример: пользователь выбирает `department=finance` в интерфейсе, но сервер не должен слепо передавать это значение в поиск. Сначала он определяет реальные подразделения пользователя, затем разрешает только допустимые фильтры.

Как обрабатывать конфликтующие источники и слабую выдачу

Агенту нужна явная политика отказа:

при конфликте показывать разные версии и даты документов;
не объединять несовместимые правила в единое утверждение;
при слабой выдаче выполнять ограниченный уточняющий поиск;
если подтвержденного контекста нет, сообщать об этом прямо;
для критичных операций передавать спорный случай оператору или отдельному процессу проверки.

Такие ситуации следует включать в набор тестов. Иначе демонстрация с удачным вопросом скроет реальные ошибки маршрутизации.

Сборка стека через CloudFormation: порядок ресурсов и зависимостей

Сначала данные, роли и политики доступа

Первый слой описывает не агента, а данные и границы доступа. Перед созданием Knowledge Bases зафиксируйте:

какие документы входят в каждый домен;
кто владеет публикацией и удалением файлов;
как помечаются версия, язык, статус и срок актуальности;
какие роли запускают ingestion и retrieval;
какое шифрование и хранение логов требует организация;
какой retention нужен для технических журналов и трассировок.

Секреты не должны попадать в параметры CloudFormation, исходный код или логи. Для окружений задайте отдельные значения, теги и политики. Роль агента должна получать минимально необходимый набор действий, а роль загрузчика документов не обязана иметь доступ к чтению всех пользовательских ответов.

Затем базы знаний и загрузка документов

Подготовьте корпус до запуска индексации. Проверьте кодировку, структуру заголовков, дубликаты, старые редакции и наличие метаданных. Успешное создание ресурса не доказывает, что retriever возвращает нужные фрагменты.

Процесс можно разделить на две операции:

создание инфраструктуры: хранилища, роли, политики, Knowledge Bases и источники данных;
подготовка корпуса: загрузка документов, запуск ingestion, проверка статуса и контрольные запросы.

Такое разделение облегчает повторный запуск. Шаблон не должен каждый раз создавать новый корпус, если меняется только набор документов.

Runtime агента, Gateway и интерфейс вызова

Прикладной контракт запроса лучше зафиксировать до настройки runtime. Минимальный набор полей:

request:
  user_identity: authenticated identity
  query: user question
  session_id: conversation identifier
  correlation_id: request identifier
  client_context: optional application context

`correlation_id` проходит через API, AgentCore Runtime, роутер, обращения к базам, модель и ответ. Если выбран Gateway, его контракт и разрешенные действия нужно сверить с поддерживаемой конфигурацией конкретного AWS-сервиса и региона.

Логика агента должна иметь ограниченный набор действий: выбрать источник, запросить поиск, уточнить вопрос, завершить ответ или вернуть отказ. Размытая инструкция вроде «ищи везде и отвечай уверенно» создает лишние вызовы и усложняет аудит.

Дашборды и алерты создаются вместе с runtime

Минимальный комплект для первого окружения включает журналы запросов, метрики ошибок, задержки по этапам, трассировки и алерты. Добавьте retention и теги одновременно с runtime, иначе диагностика начнется после первой проблемы.

Логическая цепочка CloudFormation может выглядеть так:

stack:
  parameters:
    environment
    data_retention
    model_configuration
  modules:
    storage_and_documents
    iam_roles_and_policies
    knowledge_base_product
    knowledge_base_policies
    agent_runtime
    gateway_or_api
    logging_and_tracing
    dashboards_and_alarms
  validation:
    ingestion_status
    retrieval_smoke_tests
    access_control_tests

Это каркас модулей, а не готовый deployable-шаблон. Реальные logical resource types, зависимости и свойства зависят от текущего набора возможностей AWS. Перед публикацией шаблона проверьте их по документации для конкретного региона.

Наблюдаемость agentic retrieval: что смотреть в CloudWatch, X-Ray и OpenTelemetry

CloudWatch: здоровье сервиса и операционные метрики

CloudWatch должен отвечать на первый операционный вопрос: система работает? Минимальный набор измерений:

Сигнал	Что выявляет
Количество запросов	Нагрузку, сезонность и резкие пики
Ошибки по этапам	Сбои API, runtime, retrieval или модели
Полная задержка	Влияние пользовательского ожидания
Задержка роутера и каждой базы	Медленный домен или лишнюю итерацию
Число обращений к Knowledge Bases	Сложность маршрута и повторные вызовы
Пустая или слабая выдача	Проблемы корпуса, фильтров или запроса
Уточняющие вопросы	Неоднозначность запросов и качество классификации

Не задавайте пороги вслепую. Сначала соберите baseline на тестовом и ограниченном рабочем трафике, затем задайте алерты на ошибки, задержку, рост пустой выдачи и необычное число шагов.

X-Ray и distributed tracing: путь одного ответа от запроса до цитаты

Трасса должна позволять восстановить путь конкретного ответа:

входящий запрос и идентичность пользователя;
решение роутера;
вызов первой Knowledge Base;
дополнительный вызов или уточнение;
вызов модели;
сбор цитат;
возврат ответа и ошибки.

Если ответ пришел через 12 секунд, одна общая метрика не объяснит причину. Трасса с отдельными spans покажет, потратил ли агент время на модель, несколько последовательных поисков, повторные попытки или внешний интерфейс.

Связывайте логи и spans через `correlation_id`. Не записывайте в трассу полный текст документов и персональные данные без отдельного основания: для диагностики часто хватает идентификатора документа, домена, версии и хэша запроса.

OpenTelemetry: единый формат телеметрии для приложения и AWS-сервисов

OpenTelemetry полезен как общий формат для приложения и подключенных компонентов. Для trace, span, metric и log attributes задайте согласованные поля:

`environment`;
`knowledge_base`;
`route`;
`model`;
`error_type`;
`prompt_version`;
`corpus_version`;
`correlation_id`.

Поле tenant добавляйте только при допустимой модели хранения телеметрии. В логах нельзя без необходимости сохранять email, токены, содержимое закрытых документов и полный пользовательский запрос. Наблюдаемость должна помогать искать проблему, а не создавать новый канал утечки.

Качественные сигналы: правильный маршрут, достаточный контекст, корректная цитата

Техническая доступность не означает полезный ответ. Разделите оценку на четыре вопроса:

выбран ли нужный домен;
релевантны ли найденные фрагменты;
подтверждает ли цитата конкретное утверждение;
правильно ли агент отказал или запросил уточнение при нехватке данных.

Встроенная оценка качества может быть доступна только для конкретного сервиса, версии и конфигурации. Не приписывайте ей универсальность без проверки документации. Автоматический оценщик подходит для массового фильтра, а спорные случаи требуют выборочной проверки человеком.

Как оценивать качество до продакшена и после релиза

Соберите набор вопросов вокруг реальных сценариев

Тестовый набор должен отражать работу пользователей, а не состоять из пяти удачных демонстрационных запросов. Включите минимум семь категорий:

однодоменные вопросы по каждому корпусу;
составные вопросы, требующие двух баз знаний;
неоднозначные формулировки;
запросы по устаревшей версии документа;
конфликтующие инструкции;
вопросы без ответа в корпусе;
запросы пользователя без доступа к части данных.

Для каждого вопроса сохраните ожидаемый маршрут, допустимые документы, требуемый фильтр доступа и правильное поведение при отсутствии ответа.

Оценивайте цепочку, а не только финальный текст

Этап	Проверка	Тип неудачи
Маршрутизация	Выбран правильный домен или задано уточнение	Поиск в неподходящей базе
Retrieval	Найдены релевантные фрагменты	Пустая или шумная выдача
Доступ	Применены серверные фильтры	Раскрытие закрытого документа
Цитирование	Каждое существенное утверждение связано с источником	Слабая или неверная ссылка
Генерация	Ответ не выходит за подтвержденный контекст	Необоснованный вывод
Эксплуатация	Задержка и число вызовов укладываются в лимиты	Дорогой или медленный маршрут

Разбирайте неудачи по первопричине. Ошибка «неверный ответ» слишком общая: проблема могла возникнуть в классификации, фильтре версии, retrieval, конфликте документов или финальной инструкции модели.

Версии данных и промптов должны быть наблюдаемыми

Каждый результат оценки связывайте с версией корпуса, датой ingestion, конфигурацией роутера, версией инструкций и параметрами runtime. После обновления документов это позволяет понять, изменилась ли выдача из-за данных или из-за логики агента.

Для регрессионного запуска сравнивайте одинаковый набор вопросов. Фиксируйте маршрут, найденные документы, количество шагов, задержку, решение по доступу и финальный текст. Автоматическая проверка ускоряет сравнение, но выборочная экспертная оценка остается нужна для конфликтов и неоднозначных ответов.

Ограничения и типовые провалы мультибазового поиска

Слишком похожие базы знаний создают ложный выбор

Если продуктовая документация и база поддержки содержат одинаковые инструкции, агент получает два почти равных маршрута. Итогом становятся разные цитаты, непоследовательные формулировки и дополнительные вызовы.

Проверьте границы корпусов. Иногда правильное решение состоит в объединении единого домена, иногда помогает более точная разметка версии и статуса, а иногда нужны явные правила приоритета источника.

Каждая лишняя итерация влияет на задержку и расходы

Последовательный поиск в трех базах почти всегда требует больше времени, чем один вызов retriever. Повторная генерация, уточнение и проверка контекста увеличивают число операций, которые нужно оплачивать и диагностировать.

Заранее задайте лимит шагов, условие остановки и поведение при слабой выдаче. Измеряйте долю маршрутов, где агент обращается к источнику, который не использован в финальном ответе. Кэширование подходит для стабильных публичных запросов, но требует проверки актуальности, прав доступа и версии документов.

Материал о динамической маршрутизации фактологических и аналитических запросов с помощью TAKC поможет сравнить агентный поиск с отдельным контуром сжатия знаний: разбор Task-Aware Knowledge Compression.

Managed не означает безоперационный

Управляемая инфраструктура сокращает объем работы с отдельными компонентами, но команда продолжает отвечать за:

актуальность и структуру документов;
контроль ingestion и удаления старых версий;
пересмотр IAM и фильтров доступа;
регрессионные тесты после изменения промпта или модели;
логи, трассы, retention и алерты;
контроль числа шагов и расходов;
аудит спорных ответов и разбор инцидентов.

Если команда не готова поддерживать эти процессы, для одного домена лучше выбрать простой RAG с фиксированным retriever. Агент добавляет полезную гибкость только там, где она компенсирует усложнение.

Чек-лист перед внедрением Amazon Bedrock Managed Knowledge Base

Определены домены и понятные границы каждой Knowledge Base.
У каждой базы есть владелец, примеры допустимых вопросов и список исключений.
Документы имеют метаданные версии, языка, статуса и даты актуальности.
Сервер формирует фильтры доступа на основе проверенной идентичности пользователя.
Описаны стратегии для однодоменных, междоменных и неоднозначных вопросов.
Задан лимит агентных шагов и правило остановки.
Подготовлены тесты на пустую выдачу, конфликтующие версии и отсутствие доступа.
В ответе сохраняется связь между утверждением и цитатой.
CloudFormation разделен на модули данных, IAM, Knowledge Bases, runtime и наблюдаемости.
Для каждого окружения заданы отдельные параметры, теги и retention.
В логах и трассировках нет лишних персональных данных и содержимого закрытых документов.
Есть `correlation_id`, связывающий запрос, маршрут, поиск, модель и ответ.
Настроены метрики ошибок, задержки, количества шагов, пустой выдачи и уточнений.
Проверена поддержка AgentCore, Gateway, Knowledge Bases, X-Ray и нужных механизмов оценки в выбранном регионе.

Практический порядок такой: сначала зафиксируйте домены и модель доступа, затем подготовьте документы и тестовые вопросы, после этого опишите инфраструктуру в CloudFormation и подключите runtime. Запускать агентный поиск без трассировки и набора негативных сценариев рискованно: красивый ответ еще не доказывает правильный источник, корректный фильтр или приемлемую стоимость.

Для технических шагов используйте актуальные официальные материалы AWS, проверяя регион, поддерживаемые ресурсы и текущие ограничения. Архитектурная схема из этой статьи помогает разложить задачу, но конкретный deployable-шаблон нужно собирать под выбранную конфигурацию аккаунта.

Подписаться на канал