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

一位银行运营员工在早晨开始时询问内部 AI 助手，开立企业账户需要哪些文件。答案就在一份清单里。几个小时后，同一位员工又问，这些要求对于独资企业、有限责任公司（LLC）和有多名合伙人的合伙企业有何不同。这个答案分散在几份政策指南中。一个助手必须同时处理这两个问题：对第一个问题要快速且低成本，对第二个问题要全面彻底。应用需要一种方式，让检索投入与每个请求相匹配，而不必为简单和复杂问题分别构建系统。

Amazon Bedrock Managed Knowledge Base 现在通过 AgenticRetrieveStream 支持单次检索增强生成（RAG）和仅检索请求。使用单次 RAG 时，服务会搜索一次您的知识库，并使用基础模型（FM）根据找到的段落生成答案。使用仅检索请求时，服务会返回匹配的段落而不生成答案，因此您的应用或用户可以直接处理源文本。这些模式加入了现有的代理式检索，即服务在回答前会规划并运行多次搜索。现在，您可以使用同一个 API 来处理该员工的两个问题：用单次 RAG 进行清单查询，用代理式检索进行跨政策比较。

在本文中，我们解释这些新设置如何工作，以及何时使用每种模式。我们使用一个示例性的内部银行政策助手来展示单次 RAG 如何处理直接问题，以及代理式检索如何支持跨政策文档的比较。我们还展示当员工需要查看源段落而不是生成的答案时，如何配置仅检索请求。

主要优势

代理式检索帮助助手回答需要多次搜索的问题。基础模型将问题分解为子查询，搜索相关知识库，并评估结果是否提供足够信息来回答原始问题。如果发现缺口，它可以在配置的迭代限制内优化搜索并检索更多证据。

对于应用构建者来说，这带来了多项好处：

更好地支持多部分问题 – 有针对性的搜索可以为问题的每个部分找到证据，而不是依赖一次搜索覆盖所有内容。在银行示例中，助手可以分别查找独资企业和 LLC 的要求，然后再进行比较。
信息缺失时进行后续搜索 – 规划器可以利用找到的内容来决定下一步搜索什么。当某个段落没有提供足够上下文时，它还可以检索完整文档，帮助解决单次检索可能遗留的缺口。
带支持证据的答案 – 启用响应生成后，服务会将检索到的信息合并为带引用的答案。跟踪事件会显示规划和检索步骤，帮助开发者检查答案是如何产生的。
减少自定义编排 – 服务通过一个 API 管理规划、检索、评估和响应生成工作流。应用无需实现自己的循环来协调这些步骤。

这些代理式能力对于复杂问题仍然很有价值。对于简单的查询，应用也需要一种无需额外规划即可检索并回答的方式。扩展后的 maxAgentIteration 范围填补了这一空白。通过一个参数，你可以为每个请求在三种模式中选择一种：

仅检索返回段落而不生成答案。
单次 RAG检索一次并生成答案，不进行规划轮次。
代理式检索针对复杂问题规划并执行多次搜索。

单次 RAG 使用一次基础模型调用来生成答案，与代理式检索相比，这可以减少延迟和模型使用量。仅检索请求不进行任何基础模型调用。你可以为每个请求平衡速度和答案质量，而无需集成第二个 API，也无需为简单和复杂查询维护单独的代码路径。

检索迭代如何计数

在介绍新取值之前，先明确迭代如何计数会有所帮助，因为这正是行为可预测的原因。

一次迭代等于一次基础模型调用。循环始终以一次答案生成调用结束。取值 n 最多可进行 n 减 1 轮代理式规划，最后一次迭代保留用于生成响应。每个规划轮次是一次查询重写加一次检索。迭代次数越多，意味着规划轮次越多，在难题上的结果越好。迭代次数越少，意味着延迟越低。

有一点不计入：推测性检索。在第一个规划步骤之前运行的初始检索属于检索，而不是迭代。它永远不会计入你的 maxAgentIteration 值，并且只会让请求更快。在阅读以下取值时，请记住这一区别。

新增内容

范围现在为 0–5。

三种模式均支持多个知识库，包括 maxAgentIteration=0 和 1。单次检索并不意味着单个知识库。代理模式增加了查询分解、证据评估和迭代搜索，而不是对多个知识库的独占访问。

maxAgentIteration = 1：基础 RAG（主要用例）

这就是单次 RAG：一次检索，然后一个答案。没有代理式规划，没有查询重写。API 针对你的查询检索一次，并基于这些段落生成响应。这就是检索一次，然后生成响应的模式，此前无法通过此 API 表达。

将其与 generateResponse=true 配合使用，可获得基于检索到的段落生成的答案。如果你只需要段落，请改用 maxAgentIteration=0，如下一节所述。

如果你的大部分流量都是范围明确、直接的问题，这很可能就是你想要作为默认设置的选项。

maxAgentIteration = 0：仅段落，零 LLM 调用

这会执行一次有保证的检索，不生成任何内容。不调用任何基础模型。它等同于直接调用 Retrieve API。这使得它对已经统一使用 AgenticRetrieveStream、宁愿更改参数也不愿切换 API 的调用者最为有用。

由于不调用任何大语言模型（LLM），因此没有可生成的答案。将 generateResponse=true 设置为此值无效，并会返回 4xx 错误，因为生成答案需要 LLM 调用。

maxAgentIteration = 2 到 5：代理模式，保持不变

在agentic 模式下，基础模型会将复杂问题拆解为聚焦的子查询，并在多个步骤中检索证据，包括跨多个知识库进行检索。它会评估检索到的信息，并在证据缺失时优化搜索。对于单次搜索可能无法完全解决的多部分问题和比较性问题，这种方法可以提高检索准确率。

启用响应生成后，值 n 允许在基于检索到的证据生成答案之前最多进行 n 减 1 轮规划。使用 2–5 之间值的现有请求保持其当前行为。

选择值

一种理解方式：

`maxAgentIteration`	你将获得	最适合
0	一次检索，不生成，零 LLM 调用	段落检索。已标准化使用此 API、希望获得 Retrieve 风格行为的调用方
1	一次检索加一个答案	用于直接、范围明确问题的单次 RAG
2 到 5	最多 n 减 1 轮规划，然后给出答案	多部分、比较性、探索性以及跨知识库问题

值越低，调用越快且越可预测。值越高，规划器在真正困难的问题上就能进行更多分解和优化。对于简单流量，从低值开始；当复杂查询的准确率比延迟更重要时，再提高该值。

实践示例：一个内部银行政策助手

设想一家虚构的银行，其运营团队使用一个内部助手，该助手由开户流程、文档清单和政策指南的知识库提供支持。员工使用该助手来查找并理解银行记录在案的要求。以下示例说明了应用程序如何为每个工作流选择检索模式。它们并不描述客户部署或实测结果。

下图展示了银行助手如何为每个请求选择检索模式。

图 1：银行助手如何为每个请求选择检索模式

一名员工向助手提问。应用程序选择一种检索模式，并将请求发送到 AgenticRetrieveStream。使用单次 RAG 时，服务会搜索知识库一次并生成答案。使用 agentic 检索时，服务会将问题拆分为多个部分，多次搜索，然后生成带引用的答案。使用仅检索时，服务会返回源段落而不生成答案。以下各节将解释每种模式。

回答一个直接的文档问题

一名员工问道：“为独资经营者开立企业支票账户需要哪些文件？”在此示例中，银行维护了一份包含答案的专用清单。应用程序设置 maxAgentIteration=1 和 generateResponse=true 来检索相关段落并生成响应，而不进行查询重写或 agentic 规划。

这就是单次 RAG 模式：一次检索，随后一次答案生成调用。当问题和支持内容已经范围明确时，它可以避免规划步骤。

比较不同政策文档中的要求

另一名员工问道：“独资经营者和 LLC 的开户要求有何不同，根据我们的政策，非居民所有者是否适用任何额外检查？”回答这个问题可能需要来自不同流程和所有权验证指南的信息。

在此工作流中，应用程序可以设置 maxAgentIteration=4 和 generateResponse=true，允许在生成答案前最多进行三轮规划。规划器可以将问题拆分为子查询、检索相关证据，并在信息缺失时优化搜索。应针对有代表性的问题评估合适的迭代上限，而不是假设更高的值总能产生更好的答案。

显示源段落而不生成答案

审查开户流程的员工可能希望看到相关政策原文，而不是生成的摘要。应用程序设置 maxAgentIteration=0 和 generateResponse=false，在不调用语言模型的情况下返回段落。随后它可以显示这些段落及其来源引用，供员工查阅。

这三种工作流都使用 AgenticRetrieveStream。应用程序决定迭代上限以及是否返回生成的答案。选择模式属于应用程序逻辑，而不是此参数提供的自动路由。该助手支持政策查询和比较。它不负责审批账户，也不替代银行的审查和授权流程。

解决方案概述

以下示例展示了一个完整的智能体请求。其后的各节将其调整为单次 RAG 和仅检索模式。

为银行助手选择检索模式

示例代码使用虚构的政策文档演示这三种工作流。



{
    "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
    }
}

示例：单次 RAG

从智能体调用改为基本 RAG 只需一行改动。将 maxAgentIteration 设为 1，并保持响应生成开启。



{
    "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
    }
}

你仍以一贯的方式消费流。区别在于流中的内容：一次检索和一个有依据的答案，中间没有规划跟踪事件。

示例：仅段落

对于不生成内容的检索，将 maxAgentIteration 设为 0。在此值下响应生成必须关闭。



{
    "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
    }
}

这会返回去重后的源段落，不生成答案。检索行为与直接调用 Retrieve 一致，但响应格式不同：段落出现在流的 result 事件中，且不含 score 或 location 字段。

结论

借助 Amazon Bedrock Managed Knowledge Base，你现在可以通过 AgenticRetrieveStream 在一个助手中组合单次 RAG、智能体检索和仅检索请求。在银行示例中，你可以用 maxAgentIteration=1 并启用响应生成来回答开户清单问题，这样无需规划调用即可生成答案。对于跨业务结构的比较，你可以设置 maxAgentIteration=4，在生成响应前允许进行额外搜索。当员工需要阅读政策原文时，你可以设置 maxAgentIteration=0 并禁用响应生成，从而在不调用语言模型的情况下返回段落。你的应用程序选择模式，员工则继续使用同一个助手。

要在现有应用程序中采用新模式，请先从你自己的文档中选取一组有代表性的问题和预期答案。使用同一知识库，将单次 RAG 与你当前的智能体配置进行比较。测量响应延迟和请求成本，并检查答案是否正确且有检索到的段落支持。要包含答案跨多个文档的问题，以及文档无法回答的问题，这样更快的响应就不会掩盖证据缺失或不支持的结论。

使用这些结果来选择满足每个工作流质量要求的最低迭代上限。在额外搜索能改善答案的地方保留代理式检索，在单次检索足够时使用单次 RAG，在任务是来源审查时禁用生成。现有值为 2–5 的请求保持不变，因此你可以选择性地引入新模式，而不必重新设计整个应用。

要开始使用，请参考 AgenticRetrieveStream API 参考文档，在请求中配置 maxAgentIteration 和 generateResponse，然后根据应用的问题和响应时间目标评估这些设置。要了解有关该服务的更多信息，请访问 Amazon Bedrock Managed Knowledge Base 服务页面。

关于作者

Siddhant Sahu

Siddhant 是 AWS 的高级产品经理，负责领导 Amazon Bedrock Managed Knowledge Base 的产品开发。他专注于构建和推出基础设施软件服务，通过完全托管的摄取、解析和代理式搜索管道，以经济高效、准确且安全的方式处理多模态、多语言企业数据，并采用混合搜索、多次检索、工具使用和嵌入技术等先进能力。他的工作使数千家企业客户和 ISV 能够大规模构建代理。

Chinmayee Rane

Chinmayee 是 AWS 的全球生成式 AI 专家解决方案架构师，专注于帮助组织通过 Amazon Bedrock AgentCore 和 Amazon Quick 将代理式 AI 付诸实践。她与客户和合作伙伴合作，连接企业知识、自动化业务工作流，并将数据转化为可操作的洞察。她的工作涵盖解决方案架构和动手技术赋能，帮助团队从实验走向实际采用。她拥有应用数学和机器学习背景，将技术深度与对业务成果的明确关注相结合。工作之余，她喜欢萨尔萨舞和巴恰塔舞。

Josh DeMuth

Josh 是 AWS 的生成式 AI 解决方案架构师。他在科技行业拥有超过 20 年的经验，其中包括数年的系统集成经验，一直专注于让不同的系统协同工作。他现在帮助客户构建生成式 AI 应用，使其能够与他们已有的系统和数据配合工作。

Rohan Karhadkar

Rohan 是 Amazon Web Services 的软件开发工程师。他为 Amazon Bedrock Managed Knowledge Base 和 Amazon Quick 构建代理式检索系统。他的工作让 AI 代理能够规划多步搜索、检索权限感知的企业数据，并生成带有准确引用的有据可依的答案。

Qihao Shao

Qihao 是 Amazon Web Services 的高级软件工程师，负责为 Amazon Bedrock Managed Knowledge Base 和 Amazon Quick 开发代理式检索系统。