AWS Bedrock 上线 Agentic 检索模式
AWS 在 Bedrock 知识库推出 Agentic 检索模式，针对多意图、跨源问答自动规划迭代检索并生成有据回答。
Amazon Web Services 在 Amazon Bedrock Managed Knowledge Bases 中推出 Agentic 检索模式（Agentic Retrieval），通过新增的 AgenticRetrieveStream API，把传统「一次相似度检索」升级为由基础模型驱动的规划—检索—判断循环。官方文档显示，该模式默认在同一调用内返回基于检索证据生成的回答，并允许通过 generateResponse=False 参数仅返回检索结果。
传统单轮检索为何不够
单轮检索（Single-shot Retrieval）依赖单一查询向量在向量空间中找到最相近的若干片段。对于事实型、单意图问题，这种方式足够高效；但面对多意图、跨时段或跨数据源的复杂问题时，存在明显短板：
- 多意图查询没有单一嵌入能完整表征，top-k 结果往往是各子意图的「平均」，相关但不聚焦；
- 比较类问题（如「比较 A 与 B 在 X 维度上的差异」）需要对每个对象做针对性检索，单次检索难以覆盖；
- 跨知识库场景下，静态路由规则脆弱，难以按问题动态分配；
- 经典检索不判断「证据是否充分」，无论够不够都返回 k 个片段；
- 部分问题需要依据首轮结果再做追问，单轮检索无法迭代。
官方用一个示例说明：把 25 年的亚马逊股东信装入知识库后，问「文档中最重要的信息是什么」，Retrieve API 返回的最高分片段实际只是关于 Amazon Logo 颜色的内容；再升级到「比较 2020 与 2023 年公司在招聘、长期投资和客户痴迷上的表述差异」，单次检索要么返回分散的弱相关片段，要么被最强信号主导，均不能像人类分析师那样先拆解、再分别检索、再综合判断。
Agentic 检索的工作方式
Agentic 检索把上述「分析师工作流」封装为一个 API：由基础模型分解问题、逐子意图执行检索、判断证据是否足够，必要时继续迭代，直到满足收敛条件或达到 maxAgentIteration 上限。整个过程以有序的 trace 事件流对外暴露，便于调试和审计。核心事件包括：
- SpeculativeRetrieval：在首次规划前进行的预检索，用于降低端到端延迟，单知识库场景使用原始查询，多知识库场景作为路由探针；该步不计入 maxAgentIteration；
- Planning：基础模型分析查询、回顾已得结果，输出对齐到可检索意图的子查询，并在每次迭代中判断「证据是否充分」以决定继续或停止；
- Retrieval / FullDocumentExpansion：每个子查询对应一个检索事件；当模型判定当前段落不足以回答时，可触发整文档扩展（FullDocumentExpansion），适用于摘要、列举、跨段落汇总类问题；
- Result：最终事件，输出经去重后的源片段集合，并默认附带基于证据生成的回答与引用；多知识库场景下每个片段标注其来源检索器。
需要注意的是，去重仅作用于最终 Result 事件；trace 中的中间事件仍保留完整的规划与检索步骤，便于复盘。
关键参数与取舍
文档披露了两个最主要的调参杠杆：maxAgentIteration 控制规划与检索迭代轮次的上限，单知识库场景下常用 3，多知识库或更复杂问题可上调至 4–5（原文此处被截断，完整建议以官方文档为准）；generateResponse 控制是否在同一次调用内返回生成式回答。除此之外，开发者仍可借助 trace 事件流对子查询质量、收敛时机和成本进行精细化分析。
对已经在 Bedrock 上自建 Agent 框架、围绕 Retrieve API 做循环调度的团队而言，Agentic 检索相当于把这套「每应用一套」的自研流程下沉为托管能力，统一了延迟、成本与可靠性口径；而对仍在使用单轮检索的产品，官方建议先把跨子意图、跨源、需追问的问题迁移到 Agentic 模式，事实型单点查询则继续保留在标准 Retrieve API 上以控制成本。