Bedrock 新增检索模式：给每类客户问题一份投入预算

AWS 在 11 月 9 日公布的更新，把知识助手的一项产品选择说得更清楚了：可以只返回来源段落，可以检索一次后生成回答，也可以投入更多精力继续查找。按官方说明，这些路径现在可以通过同一个接口表达，不必让所有问题都经过同样的 Agent 检索流程。具体变化见 AWS 原文。

对正在做客户门户、客服工具或内部知识产品的创始人来说，机会在于给不同问题分配不同预算。客户只是问“导出指南在哪里”，未必需要与“比较两套迁移流程”相同的处理方式。多查几轮是否值得，要看它能否改善客户最终完成的事情。

采用之前，仍有一项实际检查。我们 11 月 10 日直接读取的参数文档已将最小值写为 0，与公告一致；研究过程中遇到的搜索阅读器旧副本却仍写着 2。做决策应以当前官方文档为准，并在目标环境中确认新模式可用，再向客户承诺。

本文给出一张问题投入预算表、一个虚构产品案例和一套可控的试点方法。核心建议是：只有当追加检索能在某类任务允许的等待与费用范围内，带来有证据、可使用的答案，才为这类任务开放更多投入。我们没有调用新模式、测量性能或查看客户账单；下文是产品验收方案，不是实验结果。

1. 把发布消息读成一项客户体验选择

按 AWS 的说明，maxAgentIteration=0 搭配 generateResponse=false 会返回段落，不调用大语言模型；取值为 1 并启用生成时，检索后直接作答，不经过规划；2 到 5 保留 Agent 检索行为。启用回答生成时，最后一轮用于作答，因此设为 4，最多允许前三轮做规划。这个数不代表四次搜索、四份文档，也不代表四个独立核验过的答案。官方还说明，三种模式都支持多个知识库。这些是厂商对功能的描述，不是我们的运行观察。

创始人要先回答更上层的问题：客户想完成什么？找到准确段落、理解已记录的操作流程、比较几份流程，是三类不同任务。一个统一聊天框容易把差异藏起来，让团队默认每次都购买最复杂的回答过程。

也要计算客户付出的成本。客户只想找一份能转发给同事的原文时，长篇解释可能妨碍办事；客户需要判断哪套说明适合自己时，一个很快返回的片段又可能不够。第二次检索如果能补上明确缺口，等待就有理由；如果只是展示一串看起来很忙的过程，价值就难以成立。

把取舍写进产品需求。先写“帮助工作区管理员找到并理解适用的导出流程”，再讨论“增加 Agentic RAG”。前一句明确了受众、任务完成条件和边界，也保留了一种可能：整理好的帮助页面，比对话功能更适合解决这个问题。

2. 分清找证据、解释证据和执行决定

检索是在可搜索的资料集合中选择材料；段落是返回的一部分材料；生成是模型重新组织语言、写出内容。RAG 即检索增强生成，将检索得到的信息与生成过程结合。早期 RAG 论文讨论了模型内部知识与外部检索机制的结合。这是概念背景，不能用来证明本周 AWS 功能的实际表现。 Agent 检索增加了规划过程：系统可能把问题拆成较小的查询，再判断已有信息是否足够。分流则是应用选择走哪条路径。这几件事由不同环节负责。检索模式本身并没有决定哪些客户可以得到答案、他们能看哪些文档，或最终建议是否适合采用。

分清这些责任，有助于避免采购误判。构建者展示了跨两份文档的比较，称助手“具备自主能力”，创始人还需要继续问：客户因此更容易完成什么？比较有没有保留相关例外？证据能否打开？助手获得的权限是解释已有规则，还是可以直接判定资格？

产品中的执行权应与解释能力分别设计。一个负责说明导出流程的助手，不能悄悄变成批准导出或修改保留设置的系统。那些操作需要单独的授权与确认机制。追加检索可以提供更完整的决策依据，但不会自动赋予执行权限。

3. 先确认可用，再购买迁移服务

我们 11 月 10 日直接读取的 参数参考文档写的是最小值 0。搜索阅读器的旧副本显示为 2，实时页面已经澄清了这项差异。但这仍不能证明你安装的 SDK、使用的账户和已部署的应用成功运行过新模式。采购记录应保留所依据文档的日期与副本。

批准迁移前，请构建者交一份简短的可用性记录：目标 Region、账户、知识库类型、SDK 版本、请求设置、返回结果或校验错误，以及测试时间。用不含敏感信息的测试文档即可。别人账户里的控制台演示成功，不足以证明你的生产应用能接受同样的请求。

同时检查前提条件。AWS 的 Agent 检索指南要求使用托管知识库。团队如果正在使用自行管理的向量存储，不能想当然地认为改个参数就能把新能力搬过去。估算迁移工作之前，先弄清现有架构。

客户体验也应与厂商功能上线节奏分开。如果新设置尚不能使用，就保留原先验证过的路径，或者单独验收后的原文搜索体验。不要暗中换成更长的 Agent 运行过程，却继续对客户称它是快速路径。如果没有合格的替代方案，功能就应留在范围明确的试点里。

这项检查并不要求创始人自己实现接口。它要求保留足够的证据，区分三个里程碑：厂商已经宣布、我们的环境已经接受请求、我们的用户使用起来合格。三者不能互相替代。

4. 根据缺少什么信息分流，而非看问题长短

一句很短的问题，也可能需要查几份资料。“这适用于我的老工作区吗？”可能取决于启用日期、账户类型和例外规则。一段很长的问题，也可能只是要找到某一份明确的文档。字数不能代替对任务的理解。

条件允许时，先让产品意图变得明确。“查看指南”可以请求原文；“解释这一节”可以要求基于该节作答；“比较这两套流程”则可以成为扩大检索的候选，但仍受证据与权限边界约束。这是我们提出的界面设计方式，不是 AWS 内置的自动分流器。

对于自由输入的问题，要说清继续检索可能补上哪个缺口。“已经找到新流程，但还缺旧工作区的例外条款”，是合理的升级理由；“回答太短”则不是。模型自信地表示应该多想一会儿，也不能作为可靠的质量指标。

每条路径都要有停止条件：允许使用的资料已经支持必要结论、等待预算耗尽、获准投入的工作量用完，或者出现需要人工判断的冲突。资料里根本没有答案时，不必为了让拒答显得更认真而不停升级。

问题含糊时，应采用另一种处理方式。如果用户没有说明工作区类型，针对性地问一句，可能比把两套政策都查出来再猜更有用。追问要简短，并解释这个信息为什么影响答案。应用已经能够从账户中适当获取的信息，就不应再让客户重复提供。

5. 用一个产品场景拆出三种不同承诺

设想一个虚构的小型协作产品助手，叫工作区指南。它获准使用的帮助资料包括当前导出指南、旧工作区例外说明，以及数据保留设置的解释。以下情况仅用于设计讨论，不是 AWS 演示、客户故事或实测结果。

管理员问：“导出指南在哪里？”期望结果是一份能够打开、标题清楚、附带相关摘录的来源。只返回原文的路径值得考虑。验收任务是：管理员不必读一篇生成文章，也能找到正确的现行指南。如果返回的是过时说明，取消生成并没有让产品变正确。

同一位管理员问：“申请导出前要准备什么？”如果获准使用的指南完整包含答案，简洁解释可能合适。审查者应检查所有必要准备步骤、限制条件，以及返回原文小节的链接。检索结果相关，不等于生成的清单已经保留段落中的全部条件。

第三个问题是：“新旧工作区的导出准备有什么不同？”这时值得测试追加检索，因为答案可能需要把当前指南与旧版例外一起考虑。产品应把未解决的冲突展示出来，不能混成一个似乎自洽的规则。如果其中一份指南缺少修订日期，助手不能凭空编出时间顺序，进而宣称冲突已解决。

再看“现在能替我把工作区导出吗？”这超出了知识功能的权限。助手可以说明如何进入获准的申请流程，却不能把比较成功当作搬运客户数据的批准。这个问题也应进入测试集，尽管三种检索模式都不应该执行导出。

因此，产品承诺应拆开：帮助找到证据、帮助理解证据、帮助比较证据。执行操作是另一项能力。验收记录中要保留这个区别，界面对客户的表达也应一致。

6. 给构建者一张可复用的问题预算表

为每一类任务填写下表。这是一份建议采用的创始人工作表，不是 AWS 配置格式。最好在观看最精致的演示前就填好判断标准，再根据保存的运行记录补上实际结果。不要看完结果后，再倒过来调整门槛，让喜欢的方案恰好通过。

一条填写中的计划可以这样写：WG-01；比较新旧工作区的导出准备；管理员；当前指南加旧版例外；候选方案为追加检索；必须说明准备步骤中的例外；文档适用性冲突时停止，交付两份来源并请求审查。 等待与费用上限仍需在运行前确定。这是一条计划记录，并不是已通过的测试。

把相应的来源摘录放在有访问控制的审查空间里，与完成的工作表一起保存。只有一张好答案截图，无法看出来源是否改过、是否走了回退路径，也无法证明用户有权查看那个段落。

审查者需要了解实际流程。创始人可以判断表达是否清楚、输出是否帮助客户完成任务；流程负责人则应判断例外与适用范围。如果双方都无法核实某个结论，就标为未解决，不能因为带了引用而接受。

7. 比较路径时，不要把客户真正经历的过程删掉

第一次比较应固定一组有代表性的问题，以及同一份来源快照。问题应覆盖直接查找、解释、跨文档比较、缺少资料、含糊请求、资料冲突和越权访问。条件允许时，从真实任务模式中挑选，并妥善移除敏感细节。不要只从演示已经擅长的问题里拼测试集。

用相关路径处理同一个问题、同一批证据，保存设置与失败记录。如果构建者在比较过程中改了提示词、文档或分流规则，应标记为另一个变体，否则就无法知道改善是否来自检索投入。

可行时，审查者先不看路径标签，只评估结果。检查任务是否完成、必要信息是否齐全、来源是否支持回答、未解决部分是否如实呈现，以及证据能否打开。ALCE 研究把流畅度、正确性与引用质量分开评价。这种区分值得借鉴，但论文的历史结果不能变成今天 Bedrock 的准确率。

等待时间应从客户最初发出请求开始，一直量到得到可用结果。如果快速路径失败后又升级，两个阶段和交接时间都要算进去。第一个字出现得快，不代表客户更早拿到了正确信息。超时和中途离开要与成功完成分别记录。

对结果有随机性的案例要重复运行；调换路径顺序，观察缓存预热或流量条件是否影响比较，并把重复尝试关联回同一个问题。无法控制的条件应写进局限。某条路径恰好赶上更轻松的测试时段，不能因此获得更优评价。

对于有明确起点与终点的任务，分母要保留所有真实尝试，包括失败。这借鉴了 GOV.UK 完成率指南的计量原则，不意味着所有一般性知识问答都符合政府事务中的交易定义。你仍需写明自己的完成标准，并将人工协助后的完成单独报告。

小试点可以揭露一条坏路径，却不能证明某个方案普遍更好，也不能证明罕见错误不会发生。内部发布说明应写出测试集的规模与构成，并把困难案例保留给下一轮复查。

8. 预算要覆盖整次尝试，包括升级与人工检查

较低的迭代上限，只是约束某一类工作量，不能直接作为完整账单估算。Bedrock 价格页分别列出索引存储、检索、Agent 规划及模型选择，也可能涉及其他服务费用。不能凭迭代数推导新模式的精确总价，更不能承诺只返回原文就是免费。

请构建者提供实际用量，并解释试点中这条具体路径涉及哪些计费项目。如果新设置的收费方式还不清楚，就把它留作采购待确认项。在没有澄清之前，不应以假设节省的金额为依据制定客户价格。

内部决策至少看两个角度。每次尝试的成本，反映无论成功与否消耗了多少工作；每个合格完成任务的成本，则用全部被评估尝试的总成本，除以达到书面验收标准的完成数。两种口径应使用一致的周期、人群和成本范围。如果没有一次合格完成，就应报告这一事实，而不是给出一个具有误导性的平均值。

重试或升级的两个阶段都要计入，还要考虑相关持续存储费用，以及纠正答案、维护来源适用性所需的人工。一次性设置和持续运营分开看。试点账单不一定代表繁忙月份的开销；服务账单下降，也可能伴随着客服工作增加。

GOV.UK 的服务绩效指南把成本、完成率和满意度放在一起观察，不把任何单项指标视为充分依据。这里也可以采用同样的判断方式：任务改善足以抵偿额外等待与支出时，才批准更多投入。一个靠让更多人卡住来省钱的路径，是需要认真评估的产品取舍，不能自动称为优化。

9. 回答形式变了，权限与信任边界仍要保留

只返回原文仍会暴露信息。去掉回答生成器，不等于不必确认用户能检索什么。类似地，第二个知识库可能包含有用例外，也不能成为追加检索扩大用户访问范围的理由。

AgenticRetrieveStream 接口文档介绍了用于访问控制过滤的 userContext，以及包含检索结果与生成回答字段的流式响应。构建者应演示应用如何传入正确身份、解析实际响应，而不是假设旧版结果展示器原样就能兼容。

AWS 的 知识库概览还区分了托管与客户自行管理的知识库能力，其中包括文档级权限支持的差异。产品说明并不能保证你导入的资料、连接器与身份映射已经正确配置。

测试时至少包括：有权访问的用户、没有权限的用户，以及访问权限已经发生变化的用户。除了聊天气泡，还要检查摘录、引用、缓存回答和审查导出内容。OWASP 授权指南强调最小权限、默认拒绝和每次请求的权限检查。落到产品上，就是每条路径及其回退都需要验证访问范围。

最后，状态文案要与产品真正知道的事情一致。“找到了相关来源”与“你的答案已经核实”不是同一种承诺。比较尚不完整，就显示缺失要点。来源预览应清楚表明自己只是摘录，不能让人以为它是一条刚刚获批的新指令。生成文字多一点或少一点，不应悄悄改变客户赋予输出的权威性。

10. 只为已通过验收的任务类型开放新路径

先对范围有限的人群开放，确保分流变化可以撤回。保留原先验证过的体验，记录每次尝试实际走了哪条路径，并明确谁能关闭新行为。看过失败情况、确认客户理解产品后再扩大范围，不能只凭上线当天演示成功就全面开放。

某类任务一旦泄露越权内容、把没有证据的例外说成定论、丢失来源交接，或反复耗尽约定的等待与费用预算，就应停止开放。发布前先确定这些规则。还要核实取消操作如何影响已在运行的工作，不能假设关掉聊天框就停止计费处理。如果费用上限无法精确执行，应把它称为告警阈值，并保守地确定开放范围。总体平均表现可能掩盖某一小类用户持续拿到更差答案的问题。

这种方法适合资料有人维护、问题有边界、也有人能判断答案的团队。如果只是堆了一批无人负责的文档，无法建立访问边界，或者问题需要资料之外的专业判断，就不适合从增加检索轮数开始。先修复资料集合，或收紧服务承诺。

已经使用 Bedrock 的团队，现在有一项值得调查的具体新能力，但仍要通过环境检查。使用其他服务商的团队，可以直接借用这张问题预算表，无须为了它迁移。帮助中心规模很小、组织清楚的团队，也应在增加对话层前，把普通搜索与直接链接纳入比较。

今天的产品讨论可以从一类任务开始：说清什么结果对客户有用，填好预算表，请构建者带回可用性记录和可比较的运行样本。看完证据，再决定这类任务值得采用哪条路径。这样既能把发布消息转成具体产品决定，也能始终分清厂商主张、你的测试计划和真正得到的结果。

参考资料

资料核验日期：2026 年 11 月 10 日。AWS 页面说明服务行为，不构成独立性能验证；论文提供历史概念与评价方法。文中的产品场景和工作表均为 YBuild 提出的设计示例。

• AWS：单次与 Agent 检索发布说明。
• AWS：AgenticRetrieveConfiguration，已直接读取当前最小值。
• AWS：AgenticRetrieveStream 请求与响应参考。
• AWS：Agent 检索的前提与用法。
• AWS：托管与客户自行管理的知识库概览。
• AWS：Bedrock 价格说明。
• Lewis 等：面向知识密集型 NLP 任务的检索增强生成。
• Gao 等：让大语言模型生成带引用的文本。
• OWASP：授权设计指南。
• GOV.UK：如何衡量完成率。
• GOV.UK：用绩效数据改善服务。