AgenticRetrieveStream в Amazon Bedrock Managed Knowledge Bases: как агентный поиск решает сложные вопросы

Пользователи задают составные, сравнительные и исследовательские вопросы по PDF, слайдам, тикетам, расшифровкам и веб-контенту. Обычный однократный retrieval на таких запросах ломается: ответу не хватает контекста, тикеты эскалируются, а аналитики тратят часы на повторные поиски. Agentic retrieval для Amazon Bedrock Managed Knowledge Bases создан именно для таких сценариев.

Рассмотрим два вопроса, которые может задать аналитик: «Сравните нашу стратегию 2020 и 2023 года. Что изменилось?» и «Каковы три главных риска по продуктовым направлениям?». Это не запросы на один поиск. Многоинтентный вопрос не имеет одной точки в embedding space, которая хорошо его представляет, поэтому top-k фрагменты возвращаются как усреднение конкурирующих поднамерений.

Agentic retrieval планирует и итеративно выполняет retrieval, а также может сгенерировать ответ в том же вызове. В этой статье объясняется, почему классический retrieval плохо справляется с многочастными вопросами, как работает API AgenticRetrieveStream (включая построение запроса и разбор trace), и когда его выбирать вместо стандартного Retrieve API.

Почему однократный retrieval не справляется

Практический пример хорошо показывает разрыв. Допустим, вы загрузили в Managed Knowledge Base 25 лет писем акционерам Amazon. Ваш первый вопрос прямой:

«Каков самый важный посыл в документах?»

Стандартный Retrieve API возвращает пять фрагментов по hybrid score. В нашем тестовом корпусе лучший результат имеет высокий балл, но низкую ценность: он посвящен цветовому оформлению логотипа Amazon. Следующие фрагменты относятся к найму, builders и differentiation. Retriever выполнил свою работу и отсортировал фрагменты по сходству с embedding запроса. Но «самый важный посыл» — слишком расплывчатая формулировка, и скорер не получает сигнала, что именно важно.

Теперь перейдем к более реалистичному вопросу:

«Сравните, как Amazon говорил о найме, долгосрочных инвестициях и customer obsession в 2020 и 2023 годах. Где сместился акцент?»

Однократный retrieval теперь должен обслужить три намерения и два временных периода одним query vector. В результате вы получаете либо россыпь слабо связанных фрагментов, либо плотный кластер, в котором доминирует самый сильный сигнал. Ни один вариант не похож на то, как действовал бы человек-аналитик.

Что сделал бы аналитик-человек

Человек разобрал бы вопрос на части. Он бы искал про найм в 2020 году, затем про найм в 2023 году, затем про философию инвестиций в каждом году. Он бы прочитал результаты, заметил пробелы, уточнил поиск и повторил его. Имея достаточно фактов, он бы синтезировал ответ.

Agentic retrieval автоматизирует этот рабочий процесс как API.

Пробелы, которые оставляет однократный retrieval

• Многочастные вопросы: один embedding может плохо представлять многоинтентный запрос, поэтому top-k результаты склонны смешивать намерения.
• Сравнительное рассуждение: запросы вида «сравните A и B по измерению X» требуют целевого retrieval по каждому объекту, а не одного смешанного поиска.
• Вопросы по нескольким источникам: когда доказательства распределены по нескольким knowledge bases, статические правила маршрутизации хрупки и могут плохо адаптироваться к конкретному запросу.
• Достаточность: классический retrieval не оценивает, «достаточно ли» данных. Он возвращает k фрагментов в любом случае.
• Исследование: некоторые вопросы требуют дополнительных поисков в зависимости от того, что показали первые результаты. Однократный retrieval не умеет итерацию.

Команды закрывали этот разрыв с помощью собственных agent framework поверх Retrieve API. Они заставляли модель планировать и вызывать Retrieve API в цикле, управлять подзапросами, устранять дубликаты и решать, когда остановиться. Это работает, но превращается в кастомную инфраструктуру в каждом приложении, а каждая такая реализация несет собственные риски задержки, стоимости и надежности.

Что такое agentic retrieval

Agentic retrieval — это новый режим retrieval в Amazon Bedrock Managed Knowledge Bases, доступный через API AgenticRetrieveStream. Вместо одного similarity search он запускает цикл планирования, управляемый foundation model: модель разбивает ваш вопрос на части, выполняет retrieval по каждой части, оценивает, достаточно ли доказательств, и повторяет цикл при необходимости. По умолчанию он в том же вызове генерирует grounded response. Если задать generateResponse=False, можно вернуть результаты retrieval без генерации ответа.

Каждый шаг этого цикла виден как упорядоченный stream trace-событий. У каждого события есть step и status, поэтому можно понять, что именно сделал planner и почему:

• SpeculativeRetrieval: начальный retrieval, который запускается до первого шага планирования, чтобы снизить end-to-end latency. Для одной KB он использует исходный пользовательский запрос. Для нескольких KB это пробный поиск, который помогает маршрутизировать подзапросы. Он не входит в maxAgentIteration.
• Planning: foundation model (FM) анализирует запрос, просматривает предыдущие результаты и формирует подзапросы, соответствующие извлекаемым намерениям. Между итерациями здесь же модель оценивает достаточность и решает, остановиться или искать дальше.
• Retrieval или FullDocumentExpansion: по одному событию на выполнение каждого подзапроса, у каждого — собственный status. В agentic retrieval это действие/событие может получить весь документ, если агент решает, что контекста фрагмента недостаточно для ответа. Часто этим полезны запросы на суммаризацию, перечисление элементов или извлечение информации из разных частей документа. Цикл может выполнить несколько итераций, если нужно больше доказательств, но он ограничен maxAgentIteration.
• Result: финальное событие. Оно содержит дедуплицированные source chunks, собранные за все итерации. Для multi-KB запросов каждый фрагмент указывает свой sourceRetriever. Поскольку генерация ответа включена по умолчанию, событие result также содержит grounded answer и citations, если только вы не задали generateResponse=False.

Примечание о дедупликации и trace. Дедупликация применяется только к финальному событию result. Когда несколько подзапросов находят один и тот же фрагмент, он появляется в итоговых результатах один раз. Trace-события остаются доступными, чтобы можно было разобрать отдельные шаги планирования и retrieval.

Два параметра больше всего влияют на настройку. Первый — maxAgentIteration, верхний предел итераций планирования и retrieval. Используйте 3 для одной KB и 4–5 для multi-KB или сравнительных запросов, хотя planner может выйти раньше, если на этапе оценки обнаружит достаточность доказательств. См. Quotas and limits для значений по умолчанию и максимальных ограничений.

Второй — конфигурация foundation model. Поле foundationModelType определяет, использует ли agentic retrieval сервисную управляемую модель или пользовательскую модель. Если указать CUSTOM, модель нужно передать через foundationModelConfiguration.

Примечание о цене: Agentic retrieval тарифицируется за вызов, а ставку задает модель, выбранная для orchestration. С управляемой моделью вы платите $4 за 1 000 вызовов agentic retrieval плюс $1 за 1 000 базовых вызовов Retrieve API. Если вы выбираете модель, доступную в Amazon Bedrock, действует стандартное pass-through Bedrock pricing для этой модели плюс те же $1 за 1 000 базовых вызовов Retrieve. Подробнее — на странице цен.

Разбор API

Теперь, когда вы увидели, как работает цикл планирования, посмотрим на API AgenticRetrieveStream на практике.

Одна knowledge base

Самый прямой сценарий: одна KB, один запрос, planner сам разбирает вопрос. Вы отправляете запрос и затем читаете stream, который возвращает trace-события, chunks с generated response, если генерация ответа включена, и финальное событие result.

import boto3
bedrock_agent_runtime = boto3.client(
    "bedrock-agent-runtime",
    region_name=REGION,
)
MODEL_ARN = (
    "arn:aws:bedrock:us-west-2:"
"<account-id>:inference-profile/<planner-model-id>"
)
response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_ID,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            }
        }
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 3,
    },
)

# Consume trace events, generated-response chunks, and the final result
for event in response["stream"]:
    if "traceEvent" in event:
        attrs = event["traceEvent"]["attributes"]
        print(f"[TRACE] step={attrs.get('step')} status={attrs.get('status')}")

        if attrs.get("step") == "Retrieval":
            for chunk in attrs.get("retrievalResponse", []):
                preview = chunk.get("content", {}).get("text", "")[:60]
                print(f"    {preview}")

    elif "responseEvent" in event:
        print(event["responseEvent"]["text"], end="", flush=True)

    elif "result" in event:
        print()

        for chunk in event["result"].get("results", []):
            source_retriever = chunk.get(
                "sourceRetriever", {}
            ).get("identifier", "")
            preview = chunk.get("content", {}).get("text", "")[:80]
            print(f"[RESULT] {source_retriever} | {preview}")

Это весь цикл: один запрос, без кода orchestration, и stream, который читается сверху вниз. Trace-события показывают, что сделал planner. Событие result отдает дедуплицированные chunks. В production такие trace-события стоит логировать в Amazon CloudWatch для атрибуции затрат, планирования latency и отладки. Каждая итерация — это один вызов planner плюс его retrieval по подзапросам, поэтому именно число итераций определяет и стоимость, и время ответа.

Несколько knowledge bases

Маршрутизация по нескольким KB — это то, что agentic retrieval умеет, а другие API — нет. Можно зарегистрировать до пяти Managed KB retrievers в одном запросе и прикрепить к каждому описательное сообщение на естественном языке. Planner читает эти описания и направляет каждый подзапрос в наиболее подходящую KB.

response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_PRODUCT_DOCS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "Публичная продуктовая документация и API reference.",
        },
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_SUPPORT_TICKETS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "Закрытые обращения в поддержку клиентов и runbooks.",
        },
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 5,
    },
)

Stream читается так же. Решение о маршрутизации видно в результате: каждый фрагмент содержит идентификатор sourceRetriever, поэтому можно понять, какая KB ответила на какой подзапрос. Описания — это контракт, по которому planner маршрутизирует запросы, поэтому формулируйте их как одно предложение-презентацию каждой KB. Нечеткие описания приводят к нечеткой маршрутизации.

Как выбрать правильный API retrieval

Managed Knowledge Bases дают два интерфейса запросов: Retrieve и AgenticRetrieveStream. Выбор зависит от формы вопроса.

Используйте Retrieve для коротких, четко ограниченных вопросов, где достаточно одного similarity search. В нем нет planner, самая низкая стоимость за вызов и минимальная latency, а вы полностью контролируете, как генерировать ответ.

Используйте AgenticRetrieveStream, когда вопросы многочастные, сравнительные, исследовательские или охватывают несколько knowledge bases. Он разбивает вопрос на части, делает retrieval по намерениям, оценивает достаточность и может сгенерировать grounded response в том же вызове либо вернуть chunks, которые вы синтезируете моделью под своим контролем. Он дороже и медленнее, потому что делает несколько model calls, но находит доказательства, которые один поиск может пропустить.

Как agentic retrieval работает на benchmark

Мы оценили agentic retrieval на MuSiQue (Trivedi et al., 2022) — публичном benchmark для multi-hop вопросов. На этих вопросах он показал 20 процентных пунктов абсолютного улучшения recall по сравнению с однократным retrieval, причем наибольший прирост был на самых сложных вопросах. Для single-hop вопросов прирост меньше — менее пяти пунктов.

Каждый вопрос MuSiQue требует двух, трех или четырех шагов retrieval, а человек-разметчик определил точную цепочку документов, необходимую для ответа. Эта цепочка — oracle decomposition: идеальный план retrieval, с которым можно сравнивать.

Здесь видно две закономерности. Во-первых, чем сложнее вопрос, тем больше выигрыш. Чем больше шагов требует вопрос, тем больше один поиск упускает, и тем больше восстанавливает agentic retrieval. Вопросы, которым нужно несколько шагов, просто нельзя ответить за один проход.

Во-вторых, система делает примерно столько шагов, сколько вопросу действительно нужно. Benchmark показывает идеальное число шагов для каждого вопроса — ту цепочку, которую проследил эксперт. Собственное число шагов agentic retrieval остается примерно в пределах одного шага от идеала, так что он ищет достаточно, чтобы ответить, но не блуждает.

Пример

Покажем, как agentic retrieval решает 4-hop запрос в датасете MuSiQue.

Запрос: «Когда исследователь добрался до штаб-квартиры группы, частью лейбла которой является Study in Brown?»

Agentic Retrieve Trace:

Процесс retrieval показан на следующем t-SNE графике пространства представлений корпуса. Он демонстрирует, как результаты одноступенчатого Retrieve (пунктирная красная граница) сравниваются с многошаговым agentic retrieve. На каждом hop agentic retrieve разбивает запрос и приходит к документу с ответом.

Лучшие практики

Эти практики снижают стоимость, улучшают latency и делают agentic retrieval предсказуемым в production.

• Начинайте с небольшой и быстрой planner model. Agentic retrieval делает много коротких вызовов. Большая модель planner редко оправдывает задержку.
• Настраивайте maxAgentIteration в зависимости от масштаба. Используйте 3 для single-KB, 4–5 для multi-KB. Измеряйте и затем корректируйте.
• Пишите описания retriever как в product marketing. Они должны быть конкретными, наглядными и отличающимися друг от друга.
• Поток trace отправляйте в Amazon CloudWatch Logs с correlation ID на каждый запрос. Это помогает повторять сценарии и отлаживать их.
• Планируйте стоимость по итерациям, а не только по tokens. Итерации определяют и цену, и wall-clock latency.
• Комбинируйте с reranking. Agentic retrieval может использовать reranking model для повышения релевантности найденных результатов. Для AgenticRetrieveStream настройте reranking через agenticRetrieveConfiguration.rerankingModelType. Если используете пользовательскую reranking model, передайте ее конфигурацию через agenticRetrieveConfiguration.rerankingConfiguration.
• Считайте результаты доказательствами, а не ответом. Синтезируйте их моделью под своим контролем, чтобы задавать тон, citations и guardrails.

Безопасность, governance и observability

Agentic retrieval наследует модель доступа Managed Knowledge Bases. Вызывающему principal из AWS Identity and Access Management (IAM) нужны четыре действия: bedrock:AgenticRetrieveStream для запуска stream; bedrock:Retrieve и bedrock:GetDocumentContent, ограниченные конкретными ARNs knowledge base, чтобы извлекать фрагменты и полный контент документов; а также bedrock:InvokeModelWithResponseStream, чтобы вызывать planner model и стримить сгенерированный ответ. Политику и настройку см. в документации.

Есть два момента, специфичных для agentic retrieval. Guardrails настраиваются через policyConfiguration.bedrockGuardrailConfiguration, и поддерживается только действие BLOCK; действие MASK с agentic retrieval не поддерживается. Поскольку planner генерирует промежуточные подзапросы, их нужно аудировать так же внимательно, как и финальные результаты. Логируйте полный trace в Amazon CloudWatch, чтобы видеть, что именно искал planner, а не только то, что он вернул.

Для observability Managed Knowledge Bases публикуют метрики CloudWatch по invocations, client errors, server errors и throttles. AgenticRetrieveStream также публикует метрику TotalIterationCount. Телеметрия managed knowledge base интегрируется с Amazon Bedrock AgentCore Observability. Полный список метрик, namespaces и вариантов маршрутизации логов см. в документации.

Вывод

В этой статье объясняется, почему однократный retrieval не справляется с многочастными вопросами, представлен API AgenticRetrieveStream и показано, когда выбирать его вместо стандартного Retrieve. Agentic retrieval переносит планирование, итерации и оценку достаточности в сервис Managed Knowledge Bases, так что вы получаете единый, наблюдаемый API с предсказуемой безопасностью, логированием и стоимостью вместо собственной orchestration в каждом приложении.

Для прямых поисков начинайте с Retrieve, а для многочастных, сравнительных или исследовательских вопросов, а также когда доказательства распределены по нескольким knowledge bases, переходите к AgenticRetrieveStream. Чтобы собрать свою первую agentic knowledge base, используйте сопроводительный notebook на GitHub. Подробности API см. в справочнике AgenticRetrieveStream API reference, либо изучите функцию в консоли Amazon Bedrock.

Материал — перевод статьи с английского.

Оригинал: Agentic retrieval for Amazon Bedrock Managed Knowledge Base