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

一位银行业务运营员工早上开始工作时，询问内部 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：智能体模式，保持不变

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

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

选择值

一种理解方式是：

`maxAgentIteration`	你得到的结果	最适用于
0	一次检索，无生成，零次 LLM 调用	段落检索。已统一采用此 API 且想要 Retrieve 风格行为的调用方
1	一次检索加一个答案	针对直接、范围明确的问题的单轮 RAG
2 到 5	最多进行 n 减 1 轮规划，然后生成答案	多部分问题、比较性问题、探索性问题以及跨知识库问题

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

实际案例：一个内部银行政策助手

设想一家虚构的银行，其运营团队使用一个内部助手，该助手背后是一个包含开户流程、文件清单和政策指南的知识库。员工使用该助手来查找和理解银行的规定要求。以下示例展示了应用程序如何为每个工作流选择检索模式。它们并不描述实际的客户部署或测量结果。

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

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

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

回答直接的文档问题

一位员工提问：“为个人独资企业开立企业支票账户需要哪些文件？”在此示例中，银行维护着一份包含答案的专用清单。应用程序设置 maxAgentIteration=1 和 generateResponse=true 来检索相关段落并生成响应，无需查询重写或智能体规划。

这就是单轮 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 托管知识库，您现在可以通过 AgenticRetrieveStream 在同一个助手中组合使用单次 RAG、智能体检索和仅检索请求。在银行示例中，您可以使用 maxAgentIteration=1 并开启响应生成来回答开户清单问题，从而在不调用规划的情况下生成答案。对于跨业务结构的比较，您可以设置 maxAgentIteration=4 以允许在生成响应之前进行额外的搜索。当员工需要阅读政策文本时，您可以设置 maxAgentIteration=0 并关闭响应生成，在不调用语言模型的情况下返回段落。由您的应用程序选择模式，而员工继续使用同一个助手。

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

利用这些测试结果，为每个工作流选择能满足其质量要求的最低迭代上限。在额外搜索能改善答案的场景保留智能体检索，在单次检索即可满足需求的场景使用单次 RAG，在任务是审阅源资料时禁用生成。取值为 2–5 的现有请求保持不变，因此你可以选择性地引入新模式，而无需重新设计整个应用程序。

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