LangChain + Amazon Bedrock：Agentic检索如何破解多段式问题

检索增强生成（RAG）已成为企业构建知识型AI应用的标准方案，但传统的单次检索（single-shot retrieval）在面对复杂的多段式问题时往往力不从心。本文基于 LangChain 与 Amazon Bedrock 托管知识库（Managed Knowledge Base）的实践，探讨 Agentic 检索（agentic retrieval）如何弥补这一短板。

单次检索的局限

传统 RAG 的工作流相对直接：接收用户查询，将其转化为向量，一次性从知识库中召回最相关的文档片段，再交由大语言模型生成答案。对于单一意图的简单问题，这套流程表现稳定、延迟低、成本可控。

问题出在复杂查询上。当用户提出包含多个子问题或需要跨文档综合推理的请求时，单次检索只能完成一轮召回，很容易遗漏关键信息。比如一个同时涉及「产品A的定价」和「产品B的兼容性」的问题，单次向量检索难以同时覆盖两个语义方向，最终导致答案不完整或偏差。

从技术机制上看，单次检索的瓶颈根源于向量相似度搜索的本质：它将用户查询压缩为单一的高维向量，在向量空间中寻找最近邻文档片段。当一个问题包含多个语义方向时，这个单一向量往往是多个语义的"平均"，导致任何一个子意图都无法被充分表达。此外，传统 RAG 的召回数量（top-k）是静态配置的，无法根据问题复杂度动态调整，进一步限制了对复杂查询的覆盖能力。

Agentic 检索的思路

Agentic 检索的核心区别在于引入了「智能体」式的决策逻辑。它不再把检索当作一次性动作，而是让模型自主判断：是否需要拆解问题、是否需要多轮检索、每一轮应该查询什么。

在 LangChain 与 Amazon Bedrock 知识库的组合中，这意味着智能体可以把一个多段式问题拆分为若干子查询，针对每个子查询分别调用知识库检索，再将多轮结果汇总后生成最终答案。这种方式天然适配需要多步推理的场景。

构建流程概览

基于 Amazon Bedrock Managed Knowledge Base 搭建 RAG 应用，典型步骤包括：

• 在 Bedrock 中创建并配置托管知识库，完成文档的向量化与索引
• 使用 LangChain 封装检索器（retriever），对接 Bedrock 知识库 API
• 分别构建单次检索链路与 Agentic 检索链路，便于对照
• 通过同一组查询在两条路径上运行，观察差异

Agentic 检索在架构上借鉴了 ReAct（Reasoning + Acting）范式：模型在每一步先进行推理（Thought），再决定执行什么动作（Action），观察结果后继续下一轮推理。应用到检索场景中，模型扮演"检索规划者"的角色，可以将原始问题分解为子问题、决定每个子问题最合适的查询词、判断已召回的信息是否足够，直到认为信息充分才进入生成阶段。这种自主决策循环使其能够处理需要多跳推理（multi-hop reasoning）的问题，例如"A公司的CEO在哪所大学取得学位，该大学的排名如何"这类需要串联多条信息链的查询。

对照实验：两条路径跑同一个问题

本文方法论上最有价值的部分，是让同一个查询分别走单次检索与 Agentic 检索两条路径，然后读取追踪事件（trace events），对比各自的行为与开销。

追踪事件记录了检索过程中的每一步调用：智能体做了哪些决策、触发了几轮检索、每轮召回了什么。通过阅读这些事件，开发者可以直观看到 Agentic 检索在处理多段式问题时的额外推理步骤，以及它为什么能给出更完整的答案。

成本与收益的权衡

更强的检索能力并非没有代价。Agentic 检索由于涉及多轮模型调用和多次知识库查询，其 token 消耗与延迟都会高于单次检索。文章特别强调了比较两条路径各自的成本这一点——这对生产环境落地至关重要。

实践中的决策逻辑应当是：对于简单、单一意图的查询，单次检索足以应对且更经济；只有当问题确实复杂、需要跨多个信息源综合时，才有必要启用 Agentic 检索。将两者结合、按需路由，往往是性价比最优的工程方案。

量化两条路径的开销差异时，通常需要关注三个维度：token 用量（包括每轮检索触发的模型调用所产生的 prompt 和 completion tokens）、知识库查询次数（直接影响 API 调用费用），以及端到端延迟（多轮串行调用会线性叠加延迟）。一种常见的工程优化策略是在请求入口处增加"意图复杂度分类器"——用一个轻量模型或规则判断查询是否属于多段式问题，从而将请求路由到合适的检索链路，避免对所有查询都启用开销较高的 Agentic 模式。

对企业落地的启示

对于正在构建知识型 AI 应用的团队，这套实践提供了几个可操作的方向。Amazon Bedrock 的托管知识库降低了向量库运维负担，LangChain 则提供了灵活的编排能力，两者结合让 Agentic 检索的实现门槛显著下降。

更重要的是「可观测性」的价值。通过 trace events 理解检索过程，不仅帮助调试，也为成本优化和效果评估提供了数据依据。在 RAG 应用从原型走向生产的过程中，这种可量化的对照能力是区分「能跑」与「跑得好」的关键。

小结

Agentic 检索不是要取代传统 RAG，而是为其补齐处理复杂查询的能力。理解单次检索与 Agentic 检索各自的适用边界、读懂追踪事件、权衡成本与效果，才能在真实业务中做出合理的架构选择。