AWS扩展Bedrock知识库检索，单次RAG与零模型调用统一接入

摘要：Amazon Bedrock Managed Knowledge Base 扩展 AgenticRetrieveStream，以 maxAgentIteration 在一次接口中统一三种检索模式：取值为0时只返回去重语段且不调用模型，1时执行单次检索加一次答案生成，2至5时允许多轮查询改写、证据评估与补充搜索。简化了单次RAG、纯检索和智能体检索的接入路径，同时让开发者按问题复杂度权衡延迟、模型成本与答案完整性。现有内容为AWS官方说明且银行案例仅为示例，实际收益仍需基于企业知识集独立评测。

---

一次接口覆盖三种企业知识检索模式

AWS 为 Amazon Bedrock Managed Knowledge Base 的 AgenticRetrieveStream 增加单次 RAG 与纯检索能力，并通过 maxAgentIteration 在同一 API 中统一三种执行路径：

• maxAgentIteration=0：执行一次检索并返回去重语段，不调用基础模型；
• maxAgentIteration=1：执行一次检索，再调用一次基础模型生成答案；
• maxAgentIteration=2..5：允许多轮规划、查询改写、证据评估与补充检索，最后生成答案。

这意味着简单查表、多文档比较和原文审阅不必分别维护多套客户端协议。真正的路由决策仍由应用完成，参数本身不会自动判断问题难度。

迭代次数的计算机制

AWS 将一次基础模型调用计作一次迭代。一个值为 n 的配置最多允许 n-1 轮智能体规划，剩余一次用于生成最终答案。每轮规划包含查询改写和一次检索。

因此，maxAgentIteration=1 并没有规划回合：系统先检索一次，再生成一次答案。maxAgentIteration=4 则最多执行三轮规划与检索，最后生成答案。这里的“迭代”是模型执行预算，而不是单纯的向量检索次数。

初始 speculative retrieval 不计入该上限。它在第一次规划前预取候选内容，主要用于缩短首包等待时间；但预取结果是否命中正确证据，仍取决于后续排序与改写。

三种模式的工程含义

纯检索：隔离生成环节

maxAgentIteration=0 配合 generateResponse=false 只返回检索语段，不产生任何基础模型调用。这适合需要审阅政策原文、审计证据链或把结果交给确定性程序处理的应用。

在该模式下设置 generateResponse=true 会返回 4xx 错误，因为生成答案必然需要模型调用。其行为类似直接调用 Retrieve API，但语段通过 AgenticRetrieveStream 的 result 事件返回，且不包含直接 Retrieve API 中的 score 与 location 字段，迁移时不能假设两种响应完全同构。

单次 RAG：减少规划开销

maxAgentIteration=1 对应“检索一次、生成一次”的经典 RAG 路径，不做查询改写或智能体规划。它适合答案位于单份清单、字段定义明确且检索范围高度收敛的问题。

相较多轮智能体检索，这种模式减少规划模型调用和额外检索，延迟与费用更容易预测；代价是无法主动补齐跨文档证据。官方银行示例中的“开通企业账户需要哪些文件”适合此模式，但不代表真实业务已经获得特定准确率或成本数据。

智能体检索：处理多部分问题

当值为 2 至 5 时，基础模型会拆分问题、构造针对性查询，并评估现有证据是否足够。若发现信息缺口，它会继续改写查询并检索其他知识库，最后基于收集到的证据生成带引用答案。

这一机制的优势是能覆盖比较型、条件型和跨知识库问题；代价是每轮都会增加模型推理、向量检索及重排开销，而且更高上限并不保证答案更好。错误规划可能把检索引向无关文档，迭代过多还会扩大延迟、成本和错误累积风险。

延迟、成本与答案质量如何权衡

三种模式形成了一条可调的执行路径：

| 模式 | 模型调用 | 适用场景 | 主要风险 | |---|---:|---|---| | 纯检索 | 0 | 原文审阅、程序消费 | 不生成归纳答案，排序错误仍会直接暴露 | | 单次 RAG | 1 次生成 | 明确、范围收敛的查询 | 一次召回遗漏跨文档证据 | | 智能体检索 | 多次规划与最终生成 | 比较、探索、跨库问题 | 成本和尾延迟上升，错误规划可能放大偏差 |

新增参数的主要价值不是提高某一个固定模式的平均精度，而是把预算控制权交给调用方。生产系统应按请求类型选择模式，而不是为全部流量统一设置最高迭代值。

官方示例中的应用设计

AWS 使用虚构的银行运营助手演示三种工作流：

• 查询个体经营者开户所需文件时，采用 maxAgentIteration=1 与 generateResponse=true；
• 比较个体经营者、有限责任公司及非居民所有者的要求时，采用 maxAgentIteration=4，预留三轮补充检索；
• 仅展示开户政策原文时，采用 maxAgentIteration=0 与 generateResponse=false。

该示例清楚展示了应用层路由，但 AWS 明确说明它不是客户部署或实测结果，助手也只负责查询和解释政策，不执行开户审批或替代人工授权。

落地建议：先建立分桶评测

迁移现有应用时，不应直接把复杂请求全部切到高迭代值。较稳妥的做法是：

1. 从真实业务中抽取单文档直查、跨文档比较、证据不足和权限边界样本；
2. 在同一知识库和同一基础模型配置下，对单次 RAG 与现有智能体检索做对照；
3. 分别记录召回率、答案正确性、引用支持度、P50/P95 延迟、模型调用次数与单请求成本；
4. 为不同请求类别确定最低满足质量要求的迭代值；
5. 保留“知识库无法回答”的测试集，避免快速回答掩盖证据缺口；
6. 对引用、访问权限和生成答案执行分层审计，尤其不能把检索语段的普通展示等同于完整的生产级证据链。

maxAgentIteration 扩展到 0 至 5 后，原有 2 至 5 的行为保持不变，企业可以先以新增的 0 和 1 覆盖简单流量，再逐步调整复杂请求。

兼容性边界

三种模式都支持多个知识库；“单次检索”并不表示只能检索一个知识库。新增能力改变的是规划与生成预算，而不是知识源数量。

应用仍需自行选择模式，并通过 generateResponse 控制是否生成答案。对于需要直接消费检索结果的系统，纯检索模式可以消除生成模型的延迟和费用，但会失去自然语言归纳层，调用方必须自行处理排序、来源定位和结构化输出。

---

消息来源：AWS Machine Learning Blog (2026-11-09)

—— 完 ——

主题标签： #Amazon Bedrock 关注 #Agentic RAG 关注 #知识库检索 关注 #AgenticRetrieveStream 关注