用 LangChain 与 Amazon Bedrock 构建智能体检索 RAG 应用

当用户向 RAG 支持助手提问「从三个维度比较两款产品」时，实际上同时抛出了六个独立问题。标准相似度检索将所有意图编码进单一查询向量，返回的是这些意图的「平均最优近似」。结果在表面上看起来合理——相关性分数正常、没有报错——但检索到的文本块只覆盖了问题的一部分。这种隐性的信息缺失很难被下游评估指标捕捉到，却直接影响最终答案的完整性。

Amazon Bedrock 托管知识库的智能体检索针对上述问题引入了规划循环机制。AgenticRetrieveStream API 不再执行单次搜索，而是让模型先制定检索计划，将原始问题拆解为若干子查询并依次执行，随后判断已获取的证据是否足以回答每个子问题，若不足则触发补充搜索。整个过程以流式追踪事件的形式返回，开发者可以实时观察规划步骤，包括何时触发了 FullDocumentExpansion 以获取完整文档上下文。

在 LangChain 集成层面，langchain-aws 包同时暴露了两条检索路径。标准检索对应 AmazonKnowledgeBasesRetriever，可直接嵌入现有 LangChain 链；智能体检索则通过独立函数调用 AgenticRetrieveStream API。两者均以文档块的形式返回结果，供后续语言模型生成有依据的回答。开发者无需重构整体架构，即可在同一应用中按需切换或并行运行两种检索模式。

权限配置是本方案中容易被忽视的细节。知识库服务角色与应用调用身份需要分开管理，前者负责读取 S3 文档并调用嵌入模型，后者负责查询知识库。值得注意的是，bedrock:GetDocumentContent 权限常被遗漏，而智能体检索在执行 FullDocumentExpansion 步骤时必须依赖它。缺少该权限的策略在规划器尝试获取完整文档时会中途失败，且错误信息并不直观，建议在初始配置阶段一并添加。

在成本维度，标准检索每次只执行一次混合搜索，调用开销固定且可预测；智能体检索因规划循环可能触发多次检索与模型推理，单次查询成本更高。对于结构简单、意图单一的问题，标准检索仍是更经济的选择。只有当问题本身包含多个独立子意图、且答案完整性优先于成本控制时，智能体检索的额外开销才能带来相称的价值回报。两者并非替代关系，而是互补的检索策略。

从工程落地角度看，本方案要求 Python 3.12 及以上版本，boto3 需升级至 1.43.32 或更高（agentic_retrieve_stream 接口在此版本之前不存在），langchain-aws 需 1.6.3 及以上。知识库的语料库应包含多篇覆盖重叠主题的文档，单一平铺文档无法有效展示查询规划的价值。实验完成后建议及时删除相关资源，以避免持续产生存储、摄取与推理费用。

要点

• 单次向量检索在多部分问题上存在结构性缺陷，检索结果看似合理但实际覆盖不完整，智能体检索通过规划循环系统性地解决了这一问题。
• AgenticRetrieveStream API 以流式追踪事件返回规划步骤，开发者可观察子查询拆解、证据判断与补充搜索的完整过程，便于调试与优化。
• bedrock:GetDocumentContent 权限在 IAM 策略中容易被遗漏，但智能体检索执行 FullDocumentExpansion 时必须依赖它，缺失会导致查询中途失败。
• 标准检索成本固定适合简单查询，智能体检索因多轮规划成本更高，应根据问题复杂度与答案完整性要求在两者之间做出权衡。
• langchain-aws 同时支持两种检索路径，开发者无需重构架构即可在同一 LangChain 应用中灵活切换或并行使用标准与智能体检索。