Даже если ИИ отвечает связно и приводит ссылку на источник, его работу бывает трудно проверить. Команде нужно понимать, какой документ выбрал агент, обращался ли он к поиску повторно, сколько стоил запрос и почему убедительный на вид ответ оказался неподтверждённым.
26 октября 2026 года AWS опубликовала воспроизводимый пример агентного поиска на Amazon Bedrock Managed Knowledge Bases, AgentCore и AWS CDK. Это техническая инструкция, а не описание клиентского внедрения. В ней показано, как сделать ход поиска доступным для проверки. [1]
Когда одного поиска недостаточно
Обычный RAG — генерация ответа с поиском по внешним источникам — находит подходящие отрывки документов и передаёт их модели. Одного поиска может хватить, если вопрос простой и источник известен. Но ответ может требовать сведений из разных коллекций, а первый поиск — пропустить важную информацию. [1]
Один поиск и ответ
Система один раз получает сведения из базы. Достаточно ли этого, зависит от вопроса и документов.
Выбор источника и повторный поиск
Агент выбирает инструмент поиска и может обратиться к нему снова, если найденных сведений недостаточно.
Это сравнение подходов по описанию AWS. Один проход — особенность простой схемы, а не измеренный показатель клиентской системы.
Агентный поиск нужен не для каждого вопроса или поиска документа. Дополнительные шаги усложняют систему. Перед внедрением стоит проверить, помогает ли такой подход отвечать на сложные вопросы и разбирать, как был получен ответ.
Как агент выбирает базы знаний и ищет в них сведения
В примере AWS созданы две отдельные базы знаний: финансовая и метеорологическая. Первая содержит искусственно составленный отчёт вымышленной компании, вторая — открытый доклад Исследовательской службы Конгресса США о торнадо. Отдельные базы позволяют увидеть, какой источник выбрал агент. [1]
AgentCore Runtime
Планирование и выбор источника
AgentCore Gateway / MCP
Авторизованный доступ к инструментам поиска
Финансовая и метеорологическая базы
Агент может повторить поиск, прежде чем составить ответ со ссылками на источники.
CloudWatch + X-Ray
Трассировки, расход токенов, качество поиска и оценки
Схема основана на архитектуре AWS. Это не проект, внедрённый Maak.Digital, и не клиентская система.
AgenticRetrieveStream ищет сведения внутри базы знаний и формирует ответ со ссылками. AgentCore Gateway предоставляет агенту каждую базу как инструмент; агент сам решает, нужно ли обратиться к нему снова. В примере доступ к шлюзу разрешается через IAM, но это само по себе не решает все вопросы прав доступа к корпоративным документам. [1]
Четыре части инфраструктуры
Базы знаний
Исходные файлы в S3, два управляемых индекса и загрузка документов.
Шлюз
Доступ к инструментам поиска через MCP и авторизация.
Среда выполнения агента
Размещение агента, журналы работы и настройка непрерывной оценки.
Панели мониторинга
Показатели работы агента и каждой базы знаний.
Вся инфраструктура описана в одном приложении AWS CDK на Python. Зависимости четырёх частей определяются через ссылки на ресурсы, поэтому порядок их развёртывания не нужно задавать вручную. Это упрощает воспроизведение примера, но не доказывает ускорение бизнес-решений. [1]
Что можно увидеть и измерить
Если агент может искать несколько раз, одного факта получения ответа недостаточно для контроля системы. В примере AWS две панели CloudWatch показывают семь уровней наблюдения: работу поиска и агента, затраты и качество ответов. [1]
Работа базы знаний
Поисковые запросы и показатели сервиса.
Загрузка документов
Индексация и состояние загрузки документов.
Качество поиска
Использование найденных сведений, связь ответа с источниками и дубли.
Работа шлюза
Вызовы инструментов MCP, задержки, ошибки и ограничения частоты запросов.
Действия агента
Трассировки OpenTelemetry показывают последовательность действий.
Расход токенов
Использование модели по каждой модели и сеансу.
Оценки ответов
В частности, правильность, соответствие источникам и выбор инструмента.
Не все показатели появляются автоматически. AWS отмечает, что некоторые данные о качестве поиска, расходе и оценке рассчитывает или публикует прилагаемый блокнот с кодом. Сами панели создаются при развёртывании.
Работа агента целиком
Общий обзор работы шлюза и поиска, расхода токенов, трассировок и оценок.
Показатели баз знаний
Объём источников, количество поисковых запросов и активность сеансов отдельно по каждой базе.
При подсчёте токенов важна техническая деталь: один вызов модели создаёт несколько вложенных записей, в которых повторяются данные о расходе. AWS выбирает конечную запись CLIENT, чтобы не посчитать один вызов трижды. [1]
Что показывают результаты демонстрации
AWS показывает оценку по запросу и непрерывную оценку. В одном демонстрационном запуске четыре показателя получили оценку 1,00, при этом каждый оценивался всего по пяти трассировкам. Проверку проводили ИИ-оценщики. Это небольшая демонстрация, а не независимое доказательство безошибочной работы на реальных корпоративных документах. [1]
В демонстрации оценивается 100% сеансов, чтобы результаты было проще увидеть на панели. AWS не рекомендует этот уровень выборки для рабочей системы: вызовы ИИ-оценщика потребляют ресурсы и стоят денег. Размер выборки, пороги и правила проверки человеком нужно выбирать с учётом нагрузки и рисков.
В публикации нет измеренной окупаемости для клиента, данных об экономии времени сотрудников или масштабного сравнения точности в рабочей системе. Она показывает, как наблюдать за поиском и оценивать его, но не позволяет рассчитать экономию конкретной компании.
Вывод Maak.Digital: источники показывают, откуда взят ответ; трассировки — какие действия выполнила система; оценка помогает определить, что нужно проверить повторно.
Пять вопросов перед внедрением
Эти вопросы составлены по архитектуре AWS. Они помогают оценить внутренний поисковый помощник, систему технической документации или общую базу знаний компании. Демонстрация AWS не измеряла результаты такого внедрения.
Находит ли система нужный источник?
Документы можно разделить по владельцам, темам и правам доступа. Стоит проверить вопросы, которые затрагивают несколько тем или допускают разные трактовки.
Можно ли проверить ответ по документам?
Ссылки должны вести к конкретным отрывкам, а не только к названию документа. Нужно также определить, как помощник отвечает, если подтверждения не нашлось.
Видны ли действия агента?
Система может записывать поисковые запросы, выбор источников, ошибки и идентификаторы трассировок, не раскрывая закрытые данные.
Кто регулярно проверяет качество?
Для проверки нужны типичные вопросы пользователей и контроль ухудшений. Ответы, от которых зависят важные решения, должен проверять человек.
Что будет с затратами и доступом при росте нагрузки?
Перед запуском стоит проверить стоимость модели и оценки, права доступа, доступность сервисов в нужном регионе и сроки хранения данных.
Ответы ИИ должны поддаваться проверке
Агентный поиск может помочь, когда одного обращения к базе недостаточно. Но каждый дополнительный шаг тоже нужно проверять. В примере AWS выбор источников, трассировка и оценка предусмотрены в архитектуре с самого начала.
Это независимый разбор эталонной архитектуры AWS, а не описание клиентского внедрения или проекта Maak.Digital. В примере нет независимо подтверждённых данных об окупаемости или точности системы на реальных корпоративных документах.