LangChain 联手 Amazon Bedrock：Agentic 检索如何破解多意图 RAG 难题
当用户向客服助手提出"对比两款产品在三个维度上的表现"时，这实际上是一句包含六个子问题的复合查询。传统 RAG 的相似度搜索只用单个查询向量来承载所有意图，最终检索到的内容虽然主题相关，却往往只覆盖问题的一小部分。
AWS 近期展示了在 Amazon Bedrock Managed Knowledge Base 上结合 LangChain 构建 RAG 应用的方案，并对比了标准检索与 Agentic 检索在同一多部分问题下的表现。
两条检索路径的本质差异
Amazon Bedrock Managed Knowledge Base 提供两个核心 API：
- Retrieve API：执行一次混合搜索，返回带评分的文本块。在 langchain-aws 包中，它是一个标准的 LangChain retriever，可直接嵌入链式调用。
- AgenticRetrieveStream API：运行一个规划循环，将步骤以 trace 事件的形式流式返回。它对应 langchain-aws 中的函数检索能力。
标准检索走的是"单次搜索"逻辑——用一个查询向量近似所有意图的平均值。这种方式执行无错、评分合理，但检索结果只是"平均意图"的近似，无法完整覆盖复合问题的全部信息需求。
Agentic 检索则不同：它先把问题拆解为多个子查询，逐一执行，再判断已有证据是否充分，不够就继续搜索。整个过程通过 trace 事件暴露出来，开发者可以读取模型生成的检索计划。
架构与成本权衡
该方案从架构上移除了自管理向量存储、嵌入模型和重排序模型——用户只需配置数据源，Bedrock 托管知识库负责分块、嵌入、存储和检索。示例中使用 Amazon S3 作为数据源。
成本方面，两条路径的差异值得关注：标准检索只执行一次搜索，调用开销低；Agentic 检索涉及规划、多轮搜索和证据判断，调用次数和 token 消耗都更高。因此文章也讨论了"何时该选更便宜的那条路"——对于意图单一、结构简单的问题，标准检索仍然是更经济的选择。
对 RAG 架构的启示
这项对比揭示了一个常被忽视的问题：RAG 应用的质量瓶颈往往不在生成端，而在检索端。当查询本身包含多个意图时，单次向量搜索的"平均化"效应会系统性地遗漏信息。Agentic 检索通过规划循环把"一次搜索"变成"按需多搜"，在复杂查询场景下显著提升召回完整性，代价是延迟和成本上升。
对于构建客服助手、产品对比、多条件分析类应用的团队而言，这意味着检索策略需要根据查询复杂度做分层设计，而非一刀切。
