Amazon Bedrock Managed Knowledge Base 支持单次与智能体检索

A banking operations employee starts the morning by asking an internal AI assistant which documents are needed to open a business account. The answer is in a single checklist. A few hours later, the same employee asks how those requirements differ across sole proprietorships, LLCs, and partnerships with multiple owners. That answer is spread across several policy guides. One assistant has to handle both questions, quickly and cheaply for the first and thoroughly for the second. Applications need a way to match retrieval effort to each request without building separate systems for simple and complex questions.

Amazon Bedrock Managed Knowledge Base now supports single-shot Retrieval Augmented Generation (RAG) and retrieval-only requests through AgenticRetrieveStream. With single-shot RAG, the service searches your knowledge bases once and uses a foundation model (FM) to generate an answer from the passages it finds. With retrieval-only requests, the service returns the matching passages without generating an answer, so your application or the user can work with the source text directly. These modes join the existing agentic retrieval, where the service plans and runs multiple searches before answering. You can now use the same API for both of the employee’s questions: single-shot RAG for the checklist lookup and agentic retrieval for the cross-policy comparison.

In this post, we explain how the new settings work and when to use each mode. We use an illustrative internal banking policy assistant to show how single-shot RAG handles direct questions and how agentic retrieval supports comparisons across policy documents. We also show how to configure retrieval-only requests when an employee needs to review source passages rather than a generated answer.

Key benefits

Agentic retrieval helps an assistant answer questions that require more than one search. A foundation model breaks the question into sub-queries, searches the relevant knowledge bases, and evaluates whether the results provide enough information to answer the original question. If it identifies gaps, it can refine the search and retrieve additional evidence, within the configured iteration limit.

For application builders, this provides several benefits:

• Better support for multi-part questions – Targeted searches can find evidence for each part of a question instead of relying on one search to cover everything. In the banking example, the assistant can look up requirements for sole proprietors and LLCs separately before comparing them.
• Follow-up searches when information is missing – The planner can use what it finds to decide what to search for next. It can also retrieve a full document when a passage doesn’t provide enough context, helping address gaps that a single retrieval might leave unresolved.
• Answers with supporting evidence – When response generation is enabled, the service combines retrieved information into an answer with citations. Trace events show the planning and retrieval steps, helping developers inspect how the answer was produced.
• Less custom orchestration – The service manages the planning, retrieval, evaluation, and response-generation workflow through one API. Applications don’t need to implement their own loop to coordinate these steps.

These agentic capabilities remain valuable for complex questions. For straightforward lookups, applications also need a way to retrieve and answer without additional planning. The expanded maxAgentIteration range closes that gap. With one parameter, you can choose one of three modes for each request:

• Retrieval-only returns passages without generating an answer.
• Single-shot RAG retrieves once and generates an answer, with no planning rounds.
• Agentic retrieval plans and runs multiple searches for complex questions.

Single-shot RAG uses one foundation model call to generate the answer, which can reduce latency and model usage compared with agentic retrieval. Retrieval-only requests make no foundation model calls. You can balance speed and answer quality for each request, without integrating a second API or maintaining separate code paths for simple and complex queries.

How retrieval iterations are counted

Before walking through the new values, it helps to anchor on how iterations are counted, because that is what makes the behavior predictable.

One iteration equals one foundation model call. The loop always ends with a single answer-generation call. A value of n buys up to n minus 1 agentic planning rounds, with the last iteration reserved for generating the response. Each planning round is one query rewrite plus a retrieval. More iterations means more planning rounds and better results on hard questions. Fewer iterations means lower latency.

One thing that doesn’t count: speculative retrieval. The initial retrieval that runs ahead of the first planning step is retrieval, not an iteration. It never counts against your maxAgentIteration value, and it only ever makes a request faster. Keep that distinction in mind as you read the following values.

What’s new

The range is now 0–5.

All three modes support multiple knowledge bases, including maxAgentIteration=0 and 1. Single-shot retrieval doesn’t mean a single knowledge base. Agentic mode adds query decomposition, evidence evaluation, and iterative searches, rather than exclusive access to multiple knowledge bases.

maxAgentIteration = 1: Basic RAG (the headline use case)

This is single-shot RAG: one retrieval, then one answer. No agentic planning, no query rewriting. The API retrieves once against your query and generates a response grounded in those passages. This is the retrieve once, then generate a response pattern that previously wasn’t expressible through this API.

Pair it with generateResponse=true to get a generated answer grounded in the retrieved passages. If you only need the passages, use maxAgentIteration=0 instead, as described in the next section.

If most of your traffic is well-scoped, direct questions, this is likely the setting you want as a default.

maxAgentIteration = 0: Passages only, zero LLM calls

This runs one guaranteed retrieval and generates nothing. No foundation model is invoked. It is equivalent to calling the Retrieve API directly. This makes it most useful for callers who are already standardized on AgenticRetrieveStream and would rather change a parameter than switch APIs.

Because no large language model (LLM) is called, there is no answer to generate. Setting generateResponse=true at this value is invalid and returns a 4xx error, because generating an answer requires an LLM call.

maxAgentIteration = 2 to 5: Agentic mode, unchanged

In agentic mode, a foundation model breaks complex questions into focused sub-queries and retrieves evidence in multiple steps, including across multiple knowledge bases. It evaluates the retrieved information and can refine its searches when evidence is missing. This approach can improve retrieval accuracy for multi-part and comparative questions that a single search might not fully address.

With response generation enabled, a value of n allows up to n minus 1 planning rounds before generating an answer grounded in the retrieved evidence. Existing requests using values from 2–5 retain their current behavior.

Choosing a value

One way to reason about it:

The lower the value, the faster and more predictable the call. The higher the value, the more the planner can decompose and refine on genuinely hard questions. Start low for simple traffic, raise it when accuracy on complex queries matters more than latency.

In practice: An internal banking policy assistant

Consider a fictional bank whose operations team uses an internal assistant backed by a knowledge base of account-opening procedures, documentation checklists, and policy guides. Employees use the assistant to locate and understand the bank’s documented requirements. The following examples illustrate how the application can select a retrieval mode for each workflow. They don’t describe a customer deployment or measured results.

The following diagram shows how the banking assistant selects a retrieval mode for each request.

Figure 1: How the banking assistant selects a retrieval mode for each request

An employee asks the assistant a question. The application chooses a retrieval mode and sends the request to AgenticRetrieveStream. With single-shot RAG, the service searches the knowledge base once and generates an answer. With agentic retrieval, the service splits the question into parts, searches several times, and then generates an answer with citations. With retrieval-only, the service returns source passages without generating an answer. The following sections explain each mode.

Answer a direct documentation question

An employee asks, “What documents are required to open a business checking account for a sole proprietor?” In this example, the bank maintains a dedicated checklist that contains the answer. The application sets maxAgentIteration=1 and generateResponse=true to retrieve relevant passages and generate a response, without query rewriting or agentic planning.

This is the single-shot RAG pattern: one retrieval, followed by one answer-generation call. It avoids a planning step when the question and supporting content are already well scoped.

Compare requirements across policy documents

Another employee asks, “How do account-opening requirements differ for sole proprietors and LLCs, and what additional checks, if any, apply to nonresident owners under our policy?” Answering this question might require information from separate procedures and ownership-verification guides.

For this workflow, the application can set maxAgentIteration=4 and generateResponse=true, allowing up to three planning rounds before generating an answer. The planner can break the question into sub-queries, retrieve relevant evidence, and refine its search if information is missing. The appropriate iteration limit should be evaluated against representative questions rather than assuming that a higher value always produces a better answer.

Show source passages without generating an answer

An employee reviewing an account-opening procedure might want the relevant policy text instead of a generated summary. The application sets maxAgentIteration=0 and generateResponse=false to return passages with no language model calls. It can then display those passages and their source references for the employee to review.

All three workflows use AgenticRetrieveStream. The application chooses the iteration limit and whether to return a generated answer. Selecting the mode is application logic, not automatic routing provided by this parameter. The assistant supports policy lookup and comparison. It doesn’t approve accounts or replace the bank’s review and authorization processes.

Solution overview

The following example shows a complete agentic request. The sections after it adapt it for single-shot RAG and retrieval-only modes.

Select a retrieval mode for the banking assistant

The sample code demonstrates the three workflows using fictional policy documents.

{
    "messages": [
        { 
            "content": { 
                "text": "How do account-opening requirements differ for sole proprietors and LLCs, and what additional checks, if any, apply to nonresident owners under our policy?" 
            }, 
            "role": "user" 
        }
    ],
    "retrievers": [
        {
            "description": "Knowledge base of account-opening procedures, documentation checklists, and policy guides",
            "configuration": { 
                "knowledgeBase": { 
                    "knowledgeBaseId": "KB12345678" 
                } 
            }
        }
    ],
    "generateResponse": true,
    "agenticRetrieveConfiguration": {
        "foundationModelType": "MANAGED",
        "rerankingModelType": "MANAGED",
        "maxAgentIteration": 4
    }
}

Example: Single-shot RAG

Setting up basic RAG is a one-line change from an agentic call. Set maxAgentIteration to 1 and keep response generation on.

{
    "messages": [
        { 
            "content": { 
                "text": "What documents are required to open a business checking account for a sole proprietor?" 
            }, 
            "role": "user" 
        }
    ],
    "retrievers": [
        {
            "description": "Knowledge base of account-opening procedures, documentation checklists, and policy guides",
            "configuration": { 
                "knowledgeBase": { 
                    "knowledgeBaseId": "KB12345678" 
                } 
            }
        }
    ],
    "generateResponse": true,
    "agenticRetrieveConfiguration": {
        "foundationModelType": "MANAGED",
        "rerankingModelType": "MANAGED",
        "maxAgentIteration": 1
    }
}

You consume the stream the same way you always have. The difference is what’s in it: a single retrieval and one grounded answer, with no planning trace events in between.

Example: Passages only

For retrieval with no generation, set maxAgentIteration to 0. Response generation must be off at this value.

{
    "messages": [
        { 
            "content": { 
                "text": "Show the policy text for the business account-opening procedure." 
            }, 
            "role": "user" 
        }
    ],
    "retrievers": [
        {
            "description": "Knowledge base of account-opening procedures, documentation checklists, and policy guides",
            "configuration": { 
                "knowledgeBase": { 
                    "knowledgeBaseId": "KB12345678" 
                } 
            }
        }
    ],
    "generateResponse": false,
    "agenticRetrieveConfiguration": {
        "foundationModelType": "MANAGED",
        "rerankingModelType": "MANAGED",
        "maxAgentIteration": 0
    }
}

This returns the deduplicated source passages with no generated answer. The retrieval behavior matches a direct Retrieve call, but the response format differs: passages arrive in the stream’s result event without score or location fields.

Conclusion

With Amazon Bedrock Managed Knowledge Base, you can now combine single-shot RAG, agentic retrieval, and retrieval-only requests in one assistant through AgenticRetrieveStream. In the banking example, you can answer the account-opening checklist question with maxAgentIteration=1 and response generation enabled, which produces an answer without planning calls. For the comparison across business structures, you can set maxAgentIteration=4 to allow additional searches before the response is generated. When an employee needs to read the policy text, you can set maxAgentIteration=0 with response generation disabled to return passages without calling a language model. Your application selects the mode, and employees keep using the same assistant.

To adopt the new modes in an existing application, start with a representative set of questions and expected answers from your own documents. Compare single-shot RAG with your current agentic configuration using the same knowledge base. Measure response latency and request cost, and check whether answers are correct and supported by the retrieved passages. Include questions whose answers span several documents, and questions the documents can’t answer, so a faster response doesn’t hide missing evidence or unsupported conclusions.

Use those results to choose the lowest iteration limit that meets each workflow’s quality requirements. Keep agentic retrieval where additional searches improve the answer, use single-shot RAG where one retrieval is sufficient, and disable generation when the task is source review. Existing requests with values from 2–5 remain unchanged, so you can introduce the new modes selectively rather than redesigning the entire application.

To get started, configure maxAgentIteration and generateResponse in your requests using the AgenticRetrieveStream API reference, then evaluate the settings against your application’s questions and response-time targets. To learn more about the service, visit the Amazon Bedrock Managed Knowledge Base service page.

About the authors

Siddhant Sahu

Siddhant is a Senior Product Manager at AWS, where he leads product development for Amazon Bedrock Managed Knowledge Base. He focuses on building and rolling out infrastructure software services that handle multi-modal, multi-lingual enterprise data through fully managed ingestion, parsing, and agentic search pipelines, in a cost-efficient, accurate, and secure way, using state-of-the-art capabilities such as hybrid search, multi-shot retrieval, tool use, and embedding techniques. His work enables thousands of enterprise customers and ISVs to build agents at scale.

Chinmayee Rane

Chinmayee is a Worldwide Generative AI Specialist Solutions Architect at AWS, focused on helping organizations put agentic AI into practice with Amazon Bedrock AgentCore and Amazon Quick. She works with customers and partners to connect enterprise knowledge, automate business workflows, and turn data into actionable insights. Her work spans solution architecture and hands-on technical enablement, helping teams move from experimentation to practical adoption. With a background in applied mathematics and machine learning, she bridges technical depth with a clear focus on business outcomes. Outside of work, she enjoys salsa and bachata dancing.

Josh DeMuth

Josh is a Generative AI Solutions Architect at AWS. Over 20 years in the tech industry, including several years in systems integration, he has focused on making disparate systems work together. He now helps customers build generative AI applications that work with the systems and data they already have.

Rohan Karhadkar

Rohan is a Software Development Engineer at Amazon Web Services. He builds agentic retrieval systems for Amazon Bedrock Managed Knowledge Base and Amazon Quick. His work lets AI agents plan multi-step searches, retrieve permission-aware enterprise data, and generate grounded answers with accurate citations.

Qihao Shao

Qihao is a Senior Software Engineer at Amazon Web Services, where he works on agentic retrieval systems for Amazon Bedrock Managed Knowledge Base and Amazon Quick.