AWS 为 Bedrock 新增单次 RAG 和仅检索模式

Amazon Web Services 于 2026 年 11 月 9 日宣布，Amazon Bedrock 托管式知识库现已支持单次检索增强生成（RAG）和仅返回段落的请求，通过 AgenticRetrieveStream。扩展后的 0–5 范围适用于 maxAgentIteration ，让应用能够选择仅检索来源、一次搜索后生成答案，或使用该服务现有的多步智能体检索。

此次更新将基本的 RAG 模式——检索一次后生成答案——引入用于复杂搜索的同一流式 API。单次 RAG 使用一次基础模型调用来生成内容，而仅检索请求不使用模型调用。AWS 表示，与智能体检索相比，单次操作可以降低延迟并减少模型用量，但公告没有提供经过测量的延迟或成本对比数据。

通过一个参数选择检索模式

值为 0 时返回匹配的段落，但不生成答案；值为 1 时检索一次，并使用 generateResponse=true生成答案；值为 2 到 5 时则保留现有的智能体行为。所有模式都支持多个知识库。因此，单次指的是只检索一次，而不是限制只能使用一个知识库。

一次迭代代表一次基础模型调用。启用生成后，限制为 n 时，会将最后一次调用留给答案生成，并允许最多进行 n 减 1 轮规划。每轮规划都包含一次查询改写和一次检索。初始的推测性检索会在规划开始前运行，且不会计入限制。

设为 0 时，必须关闭响应生成。若启用生成，则会产生 4xx 错误，因为答案生成需要模型调用。设为 1 时，流中会包含一次检索和一个有依据的答案，不包含规划跟踪事件。现有使用 2 到 5 的请求不会受到影响。

流式行为与运行限制

AgenticRetrieveStream API 参考文档指出 messages, retrievers，以及 agenticRetrieveConfiguration 是请求中必须提供的输入，而 generateResponse 为可选项。只有启用生成时，才会输出生成的答案片段。最终结果可以包含检索到的条目、综合生成的答案，以及将答案中的部分内容与支持性结果对应起来的引文。

仅检索操作等同于直接调用 Retrieve ，但响应格式不同：段落会出现在流的 result 事件中，不包含 score 或 location 字段。因此，已在使用 AgenticRetrieveStream 的应用只需更改一个参数，即可获得 Retrieve式的行为，而不必集成单独的 API。

对于复杂问题，Amazon Bedrock 用户指南介绍了一种工作流：将查询拆解为多个子查询，检查检索到的证据是否充分，进行额外搜索，并可扩展到检索完整文档。智能体检索仅支持完全托管的 Bedrock 知识库，并且每个请求最多允许使用五个检索器。降低迭代次数上限可以让智能体更早停止，但也可能降低其处理复杂问题时的准确性。

由应用团队选择并测试模式

AWS 用一家虚构银行的内部政策助手来说明这些设置，并非展示客户部署案例。针对个体经营者的文档问题使用 maxAgentIteration=1；比较个体经营者与有限责任公司（LLC）的要求，同时核查非居民所有者相关规则的请求则使用 4，最多可进行三轮规划。检查政策原文的请求使用 0，只返回来源段落，不提供摘要。

应用必须自行选择模式； maxAgentIteration 不会自动为请求选择路由。示例中的助手能够查询和比较政策，但既不会批准账户，也不会取代银行的审核和授权流程。

对于采用该功能，AWS 建议使用具有代表性的问题和预期答案，在同一知识库上比较单次 RAG 与现有的智能体配置。评估应测量延迟和请求成本，核实答案的正确性及检索段落是否提供支持，并纳入涉及多份文档的问题和无法回答的问题。这些结果有助于为每个工作流选出满足质量要求的最低迭代次数上限。

这项变更使检索深度成为每个请求都可明确设定的基础设施决策。直接查询可以省去规划调用，而复杂查询仍可通过迭代持续收集证据。对企业而言，关键在于减少模型用量后，能否仍根据自身文档提供完整且有依据的答案，而不是想当然地认为迭代次数上限越高越好。