Article · AI translation
一名银行运营员工早上询问内部 AI 助手，开立企业账户需要哪些文件。答案就在一份清单中。几小时后，同一名员工又问，独资企业、有限责任公司（LLC）和拥有多名所有者的合伙企业在这些要求上有何不同。这个问题的答案分散在几份政策指南中。同一个助手必须处理这两种问题：回答第一个问题要快速且成本低廉，回答第二个问题则要全面。应用程序需要一种方法，根据每项请求调整检索投入，而无须为简单和复杂问题分别构建系统。Amazon Bedrock Managed Knowledge Base 现在通过 AgenticRetrieveStream 支持单次检索增强生成（RAG）和仅检索请求。使用单次 RAG 时，该服务会搜索知识库 1 次，并使用基础模型（FM）根据找到的段落生成答案。使用仅检索请求时，该服务返回匹配的段落，但不生成答案，以便应用程序或用户直接使用源文本。这些模式与现有的智能体检索模式共同提供服务；在智能体检索模式下，服务会在回答前规划并执行多次搜索。现在，员工提出的两种问题都可以使用同一个 API：用单次 RAG 查询清单，用智能体检索比较不同政策。在本文中，我们将解释新设置的工作方式以及每种模式的适用场景。我们以一个示例性的银行内部政策助手为例，展示单次 RAG 如何处理直接提问，以及智能体检索如何支持跨政策文件的比较。我们还将展示，当员工需要审阅来源段落而非生成的答案时，如何配置仅检索请求。主要优势 智能体检索有助于助手回答需要不止 1 次搜索的问题。基础模型将问题拆分为子查询，搜索相关知识库，并评估结果是否提供了足够的信息来回答原始问题。如果发现信息缺口，它可以在配置的迭代次数限制内调整搜索并检索更多证据。对于应用程序开发者，这带来以下几项好处：更好地支持多部分问题——有针对性的搜索可以分别找到问题各部分所需的证据，而不必依赖 1 次搜索涵盖全部内容。在银行示例中，助手可以分别查找独资经营者和 LLC 的要求，然后再进行比较。信息缺失时开展后续搜索——规划器可以根据已找到的信息决定接下来搜索什么。当某个段落提供的上下文不足时，它还可以检索完整文档，帮助填补单次检索可能留下的信息缺口。提供有证据支持的答案——启用响应生成后，服务会将检索到的信息整合成带有引文的答案。跟踪事件会显示规划和检索步骤，帮助开发者检查答案是如何生成的。减少自定义编排——该服务通过 1 个 API 管理规划、检索、评估和响应生成流程。应用程序无须自行实现循环来协调这些步骤。这些智能体能力对于复杂问题仍然很有价值。对于直接查询，应用程序也需要一种无需额外规划就能检索并回答的方法。扩展后的 maxAgentIteration 取值范围填补了这一空缺。只需设置 1 个参数，就可以为每项请求选择 3 种模式之一：仅检索返回段落，不生成答案。单次 RAG 检索 1 次并生成答案，不进行规划轮次。智能体检索针对复杂问题规划并执行多次搜索。单次 RAG 使用 1 次基础模型调用生成答案，与智能体检索相比，可以降低延迟和模型用量。仅检索请求不调用基础模型。无需集成第 2 个 API，也无需为简单和复杂查询维护不同的代码路径，就可以根据每项请求平衡速度和答案质量。如何计算检索迭代次数 在介绍新取值之前，先明确迭代次数的计算方式，有助于理解这些模式的可预测行为。1 次迭代等于 1 次基础模型调用。循环始终以 1 次答案生成调用结束。值为 n 时，最多可进行 n 减 1 轮智能体规划，最后 1 次迭代留给生成响应。每轮规划包括 1 次查询改写和 1 次检索。迭代次数越多，规划轮次就越多，处理难题的结果也可能越好。迭代次数越少，延迟就越低。有一项操作不计入迭代次数：推测性检索。在第 1 个规划步骤之前提前运行的初始检索属于检索，而不是迭代。它绝不会计入 maxAgentIteration 的取值，而且只会加快请求处理速度。阅读以下取值说明时，请记住这一点。新增内容 取值范围现在是 0–5。全部 3 种模式都支持多个知识库，包括 maxAgentIteration=0 和 1。单次检索并不意味着只能使用 1 个知识库。智能体模式增加的是查询分解、证据评估和迭代搜索，而不是独享访问多个知识库的能力。maxAgentIteration = 1：基本 RAG（主要使用场景） 这就是单次 RAG：检索 1 次，然后生成 1 个答案。不进行智能体规划，也不改写查询。API 根据查询检索 1 次，并基于检索到的段落生成响应。这种“检索 1 次，然后生成响应”的模式此前无法通过此 API 表达。将其与 generateResponse=true 配合使用，即可获得以检索到的段落为依据生成的答案。如果只需要段落，请改用 maxAgentIteration=0，如下一节所述。如果大部分请求都是范围明确的直接提问，这很可能是合适的默认设置。maxAgentIteration = 0：仅返回段落，LLM 调用次数为 0 此设置保证运行 1 次检索，不生成任何内容。不调用基础模型。其效果相当于直接调用 Retrieve API。因此，对于已经统一使用 AgenticRetrieveStream、希望通过修改参数而不是切换 API 来获得相同行为的调用方，它最为实用。由于不会调用大语言模型（LLM），也就不会生成答案。在此取值下设置 generateResponse=true 无效，并会返回 4xx 错误，因为生成答案需要调用 LLM。maxAgentIteration = 2 到 5：智能体模式，行为不变 在智能体模式下，基础模型将复杂问题拆分为聚焦的子查询，并分多步检索证据，包括跨多个知识库检索。它会评估检索到的信息，并在缺少证据时调整搜索。这种方法可以提高多部分问题和比较类问题的检索准确性，因为单次搜索可能无法充分解答这些问题。启用响应生成时，值为 n 可在生成以检索到的证据为依据的答案之前，最多进行 n 减 1 轮规划。使用 2–5 取值的现有请求将保持当前行为。如何选择取值 可以这样理解：maxAgentIteration 可获得的结果 适用场景 0 检索 1 次，不生成答案，LLM 调用次数为 0 检索段落；已统一使用此 API 且希望获得类似 Retrieve 行为的调用方 1 检索 1 次并生成 1 个答案 针对直接、范围明确的问题使用单次 RAG 2 到 5 最多进行 n 减 1 轮规划，然后生成答案 多部分、比较类、探索类以及跨知识库的问题 取值越低，调用越快，耗时也越可预测。取值越高，规划器就越能针对真正困难的问题进行分解和调整。对于简单请求，应从较低取值开始；当复杂查询的准确性比延迟更重要时，再提高取值。实际示例：银行内部政策助手 假设一家虚构银行的运营团队使用内部助手，该助手以包含开户流程、文件清单和政策指南的知识库为基础。员工使用它查找并理解银行记录在案的要求。以下示例说明应用程序如何为各项工作流程选择检索模式。它们并不描述实际客户部署或测量结果。下图展示银行助手如何为每项请求选择检索模式。图 1：银行助手如何为每项请求选择检索模式 员工向助手提问。应用程序选择检索模式，并将请求发送至 AgenticRetrieveStream。使用单次 RAG 时，服务搜索知识库 1 次并生成答案。使用智能体检索时，服务将问题拆分为几个部分，进行多次搜索，然后生成带有引文的答案。使用仅检索模式时，服务返回来源段落，不生成答案。以下各节介绍每种模式。回答直接的文件要求问题 一名员工问：“独资经营者开立企业支票账户需要哪些文件？”在本例中，银行维护了一份包含答案的专门清单。应用程序设置 maxAgentIteration=1 和 generateResponse=true，以检索相关段落并生成响应，而不进行查询改写或智能体规划。这就是单次 RAG 模式：先检索 1 次，再调用 1 次答案生成。当问题及其支持材料的范围已经很明确时，就可以省去规划步骤。比较不同政策文件中的要求 另一名员工问：“独资经营者和 LLC 的开户要求有何不同？根据我们的政策，如果所有者是非居民，还需要进行哪些额外核查？”回答此问题可能需要查阅不同流程文件和所有权核验指南中的信息。对于这项工作流程，应用程序可以设置 maxAgentIteration=4 和 generateResponse=true，从而允许在生成答案前最多进行 3 轮规划。规划器可以将问题拆分为子查询，检索相关证据，并在缺少信息时调整搜索。应根据有代表性的问题评估合适的迭代次数限制，而不能假定取值越高，答案就一定越好。显示来源段落而不生成答案 审阅开户流程的员工可能希望看到相关政策原文，而不是生成的摘要。应用程序设置 maxAgentIteration=0 和 generateResponse=false，以返回段落，且不调用语言模型。随后，它可以展示这些段落及其来源引用，供员工审阅。全部 3 种工作流程都使用 AgenticRetrieveStream。应用程序选择迭代次数限制，以及是否返回生成的答案。模式选择由应用程序逻辑负责；此参数不提供自动路由功能。该助手支持政策查询和比较。它不批准账户，也不取代银行的审核和授权流程。解决方案概览 以下示例展示一个完整的智能体请求。后续各节会将其调整为单次 RAG 和仅检索模式。为银行助手选择检索模式 示例代码使用虚构的政策文件展示 3 种工作流程。{ "messages": [ { "content": { "text": "根据我们的政策，独资经营者和 LLC 的开户要求有何不同？如果所有者是非居民，还需要进行哪些额外核查？" }, "role": "user" } ], "retrievers": [ { "description": "包含开户流程、文件清单和政策指南的知识库", "configuration": { "knowledgeBase": { "knowledgeBaseId": "KB12345678" } } } ], "generateResponse": true, "agenticRetrieveConfiguration": { "foundationModelType": "MANAGED", "rerankingModelType": "MANAGED", "maxAgentIteration": 4 } } 示例：单次 RAG 只需对智能体调用修改 1 行，即可设置基本 RAG。将 maxAgentIteration 设为 1，并保持响应生成功能开启。{ "messages": [ { "content": { "text": "独资经营者开立企业支票账户需要哪些文件？" }, "role": "user" } ], "retrievers": [ { "description": "包含开户流程、文件清单和政策指南的知识库", "configuration": { "knowledgeBase": { "knowledgeBaseId": "KB12345678" } } } ], "generateResponse": true, "agenticRetrieveConfiguration": { "foundationModelType": "MANAGED", "rerankingModelType": "MANAGED", "maxAgentIteration": 1 } } 消费数据流的方式与以往相同。不同的是流中的内容：1 次检索和 1 个以检索内容为依据的答案，两者之间没有规划跟踪事件。示例：仅返回段落 如需只检索而不生成答案，请将 maxAgentIteration 设为 0。此取值下必须关闭响应生成功能。{ "messages": [ { "content": { "text": "显示企业开户流程的政策原文。" }, "role": "user" } ], "retrievers": [ { "description": "包含开户流程、文件清单和政策指南的知识库", "configuration": { "knowledgeBase": { "knowledgeBaseId": "KB12345678" } } } ], "generateResponse": false, "agenticRetrieveConfiguration": { "foundationModelType": "MANAGED", "rerankingModelType": "MANAGED", "maxAgentIteration": 0 } } 此请求返回去重后的来源段落，不生成答案。检索行为与直接调用 Retrieve 相同，但响应格式不同：段落通过数据流的结果事件传送，不包含分数或位置字段。结论 借助 Amazon Bedrock Managed Knowledge Base，现在可以通过 AgenticRetrieveStream，在同一个助手中结合使用单次 RAG、智能体检索和仅检索请求。在银行示例中，可以设置 maxAgentIteration=1 并启用响应生成来回答开户清单问题，从而无需规划调用即可得到答案。对于不同企业组织形式的比较，可以设置 maxAgentIteration=4，以便在生成响应前进行额外搜索。当员工需要阅读政策原文时，可以设置 maxAgentIteration=0 并关闭响应生成，在不调用语言模型的情况下返回段落。模式由应用程序选择，员工继续使用同一个助手。要在现有应用程序中采用新模式，首先应从自己的文档中选取一组有代表性的问题和预期答案。使用同一个知识库，比较单次 RAG 与当前的智能体配置。测量响应延迟和请求成本，并检查答案是否正确、是否得到检索段落的支持。还应纳入答案分散在多份文档中的问题，以及文档无法回答的问题，以免更快的响应掩盖证据缺失或缺乏依据的结论。根据这些结果，为每项工作流程选择能够满足质量要求的最低迭代次数限制。在额外搜索能改善答案的场景中保留智能体检索；1 次检索就足够时使用单次 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 的智能体检索系统。