亚马逊云科技：一个参数在纯检索、单次生成与多轮规划之间切换知识检索深度
亚马逊云科技机器学习博客解释了Amazon Bedrock Managed Knowledge Base的AgenticRetrieveStream接口如何通过maxAgentIteration参数在三种检索模式间切换：0为纯检索零LLM调用，1为单次检索加一次生成，2到5为多轮规划。文章给出了迭代计数的核心模型——一个迭代等于一次基础模型调用，循环始终以生成回答结束——并说明该模型如何让行为可预测。
构建知识库问答应用时，开发者面临一个常见矛盾：简单查找需要快速廉价，复杂比较需要多轮搜索和证据整合。如果为两类请求分别搭建系统，维护成本翻倍；如果统一使用多轮规划，简单查询也要承担不必要的延迟和模型调用费用。亚马逊云科技机器学习博客在2026年11月9日发表的文章解释了Amazon Bedrock Managed Knowledge Base如何通过AgenticRetrieveStream接口的maxAgentIteration参数解决这一问题：同一个API，一个整数，三种行为。
理解这个参数的前提是搞清楚迭代如何计数。文章给出的模型是：一个迭代等于一次基础模型调用，循环始终以一次生成回答的调用结束。因此，值为n意味着最多n减1轮规划，最后一轮保留给回答生成。每一轮规划包含一次查询改写加一次检索。还有一个不占迭代额度的例外：推测性检索——在第一步规划之前预先发起的那次检索不计入maxAgentIteration，它只会让请求更快。这个计数模型是整篇文章最具操作价值的部分，因为它让开发者能够预判每次请求最多会触发几次模型调用。
三个档位各有适用场景。maxAgentIteration设为0时，执行一次检索，不生成回答，不调用任何基础模型，等价于直接调用Retrieve API，适合已经统一使用AgenticRetrieveStream但只需要返回原文段落的调用方。设为1时，执行一次检索加一次回答生成，即经典单次RAG，没有查询改写也没有规划轮次，适合答案集中在单一文档或检查表中的直接问题。设为2到5时进入agentic模式，基础模型将复杂问题分解为子查询，跨多个知识库检索，评估证据是否充分，不足时精炼搜索继续检索。文章建议，如果大部分流量是范围明确的直接问题，1是合适的默认值。
需要指出的是，文章本身是厂商对自身API行为的说明，未提供实测延迟、成本对比或独立基准测试。文中的银行示例明确标注为虚构说明，不代表客户部署或测量结果。模式选择被文章描述为应用逻辑而非API自动路由——开发者仍需自行判断每个请求应使用哪个档位。文章建议的采用路径是：用代表性问题集对比单次RAG与当前agentic配置，测量延迟和成本，验证答案是否正确且有检索段落支撑，然后为每个工作流选择满足质量要求的最低迭代上限。