AWS 详解如何在 LangChain 中实现 Amazon Bedrock 托管知识库的代理式检索

AWS 发布教程演示如何在 LangChain 应用中集成 Amazon Bedrock Managed Knowledge Bases 的 AgenticRetrieveStream API，以解决标准 RAG 在处理多意图、多跳查询时因单一向量无法覆盖所有子问题而导致的召回缺失。文章指出，当用户提问包含多个比较维度（如“对比服务 A 和 B 在三个指标上的差异”）时，标准 Retrieve API 仅执行一次混合搜索，返回的 chunks 往往只能覆盖部分意图，而 Agentic 模式则通过内置模型将查询拆解为子查询，迭代检索并评估证据充分性。

技术实现上，Agentic 检索并非标准的 LangChain Retriever，而是作为独立函数 agentic_retrieve 暴露，需配合 RunnableLambda 嵌入 LCEL 链中。关键细节在于权限配置：调用者身份必须显式授予 bedrock:AgenticRetrieveStream 和 bedrock:GetDocumentContent 权限，后者常被忽略，因为当规划器判定片段上下文不足时会触发整文档扩展。此外，结果事件中的相关性评分字段从 Retrieve API 的 typed score 变为无结构化 content，且去重仅在最终结果事件中生效，导致 trace 流中同一 chunk 可能重复出现多次。

商业与工程推论方面，该功能默认 maxAgentIteration 为 5，低于 4 时退化为单次检索但保留代理成本。AWS 在 MuSiQue 基准测试显示，单跳问题收益小于 5 点，而在多跳问题上召回率显著提升。这意味着对于生产环境，不应对所有流量启用代理检索，而应基于查询复杂度进行路由分流——简单查询走低成本 Retrieve 路径，复杂探索性问题才调用高延迟、高成本的 Agentic 路径。事实层面，该功能目前仅限托管知识库；推断层面，未来若支持跨库路由，将增强其在企业级多源数据场景的价值；猜测层面，Guardrails 仅支持 BLOCK 模式可能限制其在需要内容过滤场景的替代能力。