Bedrock知识库按请求调节检索深度
Amazon Bedrock Managed Knowledge Base 的 AgenticRetrieveStream 新增单次 RAG 和仅检索请求支持。文章通过银行政策助手示例，说明如何使用 maxAgentIteration 为不同请求配置检索迭代。
AI 深度解读
查一份开户清单，和比较不同企业类型的开户政策，虽然都叫「问知识库」，需要的检索工作却不同。AWS 这篇文章的核心主张是：让应用按问题选择检索力度，用同一个 AgenticRetrieveStream API，覆盖只取原文、检索一次后回答、多轮检索后回答三种需求。
对做企业知识助手的程序员来说，最值得看的是参数背后的调用规则，以及如何判断多轮检索是否划算。先说明一个前提：文中的银行助手是虚构示例，没有客户部署数据，也没有延迟、成本和准确率的实测对照。
同一个知识助手，为什么要有三种检索方式
Amazon Bedrock Managed Knowledge Base 将三种工作方式放进了同一个接口。
第一种是 retrieval-only，也就是只返回匹配的原文片段。用户想核对政策措辞时，直接看依据就够了，不必再让模型写一遍摘要。
第二种是 single-shot RAG。RAG 指检索增强生成：先从知识库取出相关内容，再交给模型组织答案。如果问题已经足够明确，而且答案集中在一份清单里，一次检索通常就是合理的起点。
第三种是 agentic retrieval。模型先把复杂问题拆成子问题，针对不同部分搜索，再判断证据是否足够。缺了某项要求，就继续查；片段上下文不够，也可以取完整文档。
原文用银行开户来解释这个区别。查询个体经营者需要提交哪些材料，可能命中一份专门清单；比较个体经营者、LLCs 的要求，并检查非居民所有者是否需要额外审核，则可能涉及多份流程和所有权核验指南。
多轮检索的价值，在于给不同子问题分别寻找依据，而不是指望一次搜索把所有材料都捞齐。启用答案生成后，服务还能提供带引用的回答，并通过 trace events 暴露规划和检索步骤。
但有一个容易误读的边界：三种模式都支持多个知识库，单次检索不等于只能查一个知识库。 Agentic 模式增加的是问题拆解、证据评估和迭代搜索。
maxAgentIteration 限制的不是检索次数
新配置将 maxAgentIteration 的范围扩展到了 0–5。理解它之前，要先区分「模型调用」和「检索」。
按原文的计数规则，一次 iteration 对应一次基础模型调用。启用回答生成时，最后一次调用留给生成答案，因此数值为 n 时，最多允许 n−1 轮规划。每轮规划包含一次查询改写和检索。
三种配置可以这样理解：
| 参数组合 | 执行方式 | 适合的任务 |
|---|---|---|
| maxAgentIteration=0，generateResponse=false | 保证执行一次检索，不调用基础模型，不生成答案 | 阅读和核对原文 |
| maxAgentIteration=1，generateResponse=true | 检索一次，再调用模型生成答案，不做规划或查询改写 | 明确的事实查询 |
| maxAgentIteration=2–5，启用回答生成 | 最多进行 n−1 轮规划，再生成答案 | 多部分问题和跨文档比较 |
例如 maxAgentIteration=4，允许最多三轮规划，然后生成回答。它不代表固定执行四次搜索，也不代表一定会用满预算。
另外还有 speculative retrieval，即首次规划前提前运行的检索。它不调用模型，因此不占 maxAgentIteration 的额度。原文称这种提前执行只会让请求更快，但没有给出独立的性能数据。
maxAgentIteration=0 是需要单独记住的例外：既然不允许模型调用，就不能生成回答。此时设置 generateResponse=true，会返回 4xx 错误。
原文将更多迭代与复杂问题上的更好结果联系起来，不过这仍需实测。它后面也明确提醒，应使用代表性问题选择上限，不能假设数值越高答案就越好。
接口可以统一，模式选择仍要应用负责
下面这份请求处理跨政策比较，给模型最多三轮规划机会。代码保留原文写法：
{
"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
}
}
重点看 maxAgentIteration: 4。若改为直接查询清单的问题，将它设为 1，并保留 generateResponse=true，就进入 single-shot RAG。流的消费方式不变，但中间不会再出现规划 trace events。
如果员工需要查看政策原文，则使用下面的请求：
{
"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
}
}
这里要一起看 generateResponse: false 和 maxAgentIteration: 0。服务返回去重后的来源片段，不生成答案。
它的检索行为等同于直接调用 Retrieve API，但返回格式不同：片段位于流的 result event 中，没有 score 或 location 字段。已有页面若依赖这些字段展示分数、定位原文，就需要检查适配逻辑，不能只替换接口名称。
另一个关键边界是路由责任。AgenticRetrieveStream 统一了执行入口，却不会因为这个参数自动判断问题该用哪种模式。 选择 0、1 还是 4，仍是应用逻辑。原文没有提供自动分类器，也没有说明如何识别复杂问题。
我的判断
我赞同它把「是否生成答案」和「需要多少规划」变成请求级选择。查清单、读原文、比较政策，确实不该默认支付同样的模型调用开销。对已经使用 AgenticRetrieveStream 的应用，这也提供了渐进调整的入口，原有 2–5 配置的行为保持不变。
但文章能直接证明的是调用路径发生了变化，不能据此推导出具体能省多少钱、快多少，或者准确率提升多少。银行案例只是说明用法，效果判断仍是机制解释和经验建议。
它还有内容组织上的前提。单次检索适合清单查询，前提是知识库里真有边界清晰、容易命中的清单。若材料过时、术语不一致，或者关键条件散落在多个片段里，问题看起来简单，也未必一次就查得全。
与自行搭建规划循环相比，托管服务减少了编排工作；但应用仍要负责模式选择和效果评估。与直接调用 Retrieve API 相比，0 模式对已经统一流式接口的系统更方便；如果系统原本只做文档搜索，文章没有提供必须迁移的理由。
最有用的取舍标准是：选择满足质量要求的最低迭代上限。这里的质量不只是回答读起来通顺，还包括结论正确、引用能支撑结论，以及资料不足时有没有越界作答。
能拿来做什么
-
在已有知识助手中，先区分「直接查询」「跨文档比较」「查看原文」三类任务，再配置对应模式。对已知的工作流，可以由页面入口或业务操作传入模式，先把路由规则做明确。
-
在 Node 服务端集中校验参数组合，拦住 maxAgentIteration=0 且 generateResponse=true 的请求；前端分别处理生成答案与来源片段，并检查是否依赖 score、location 字段。
-
用同一知识库整理一组问题和预期答案，对比 single-shot RAG 与现有 agentic 配置，记录响应延迟、请求成本、正确性和引用支持情况。测试集要包含跨文档问题，也要包含文档根本无法回答的问题。
-
对确实需要补查证据的任务，再逐步提高迭代上限，并借助 trace events 检查规划是否填补了缺口。把「搜索了更多次」和「回答得更完整」分开验证。