LangChain + Bedrock Knowledge Bases 实现 Agentic Retrieval

LangChain + Bedrock Knowledge Bases 实现 Agentic Retrieval

本文解析如何利用 LangChain 框架与 Amazon Bedrock 托管知识库（Knowledge Bases）构建 Agentic Retrieval（代理式检索）应用。该方案专为处理复杂、多步骤查询场景设计，通过引入“规划器（Planner）”与“执行器（Executor）”分离架构，解决传统 RAG 在处理多部分问题时的上下文丢失与检索精度不足问题。对于需要高准确率、低幻觉率的企业级 AI 应用，此架构是优于简单向量检索的进阶选择。

核心架构：从线性检索到代理式决策

传统 RAG 流程通常是线性的：用户提问 -> 嵌入向量 -> 相似度搜索 -> 生成回答。这种模式在面对“比较两个不同文档中的数据”或“需要多步推理”的问题时，往往因单次检索无法覆盖所有必要信息而失败。

Agentic Retrieval 的核心在于引入一个 LLM 作为“代理（Agent）”，它不再直接生成答案，而是先规划检索策略。代理会根据用户意图，决定是否需要多次检索、是否需要过滤特定文档类型，甚至是否需要调用外部工具。这种机制显著提升了复杂查询的召回率。

在 GrokCode 的本地部署实验室中，我们观察到类似的分层处理逻辑也适用于 API 中转场景。当请求涉及多模型路由时，简单的负载均衡往往失效，而基于意图识别的动态路由（类似 Agentic 逻辑）能更精准地分配算力。参考 API 中转 中的动态路由策略，理解这种“先规划后执行”的思维模式，有助于更好地掌握 Bedrock 知识库的高级用法。

技术实现步骤

#### 1. 环境准备与依赖安装

首先，确保 Python 环境已配置，并安装必要的库。你需要 langchain-aws、langchain-community 以及 Amazon Bedrock 的 SDK。

``bash pip install langchain langchain-aws langchain-community boto3 ``

#### 2. 构建 Bedrock Knowledge Base

在 AWS 控制台创建 Knowledge Base 时，关键在于配置索引策略。对于 Agentic Retrieval，建议使用混合索引（Hybrid Search），结合向量搜索和关键词搜索，以提高对专有名词或精确匹配的召回能力。

• 数据源：支持 S3 存储桶中的 PDF、TXT、Markdown 等文件。
• 向量模型：推荐使用 Amazon Titan Embeddings 或 Cohere Embeddings，根据数据维度选择。
• 检索器配置：启用 Metadata Filtering，允许代理在检索前根据文档元数据（如来源、日期）进行过滤。

#### 3. 实现 Agentic 检索链

在 LangChain 中，我们使用 BedrockKnowledgeBaseRetriever 作为基础检索器，并将其包装在 AgentExecutor 中。关键组件包括：

• Planner (规划器)：通常是一个较小的 LLM，负责分解用户问题。
• Executor (执行器)：负责执行具体的检索操作。

```python from langchain_aws import BedrockKnowledgeBaseRetriever from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_core.tools import tool

1. 初始化知识库检索器

kb_retriever = BedrockKnowledgeBaseRetriever( knowledge_base_id="your-knowledge-base-id", region_name="us-east-1" )

2. 定义检索工具

@tool def search_knowledge_base(query: str): """Search the knowledge base for relevant information.""" return kb_retriever.invoke(query)

3. 创建 Agent

tools = [search_knowledge_base] prompt = ChatPromptTemplate.from_messages([ ("system", "You are a helpful assistant. Use the search tool to find answers."), ("human", "{input}"), MessagesPlaceholder("agent_scratchpad") ])

llm = BedrockChat(model_id="anthropic.claude-3-sonnet-20240229-v1:0") agent = create_tool_calling_agent(llm, tools, prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

4. 执行查询

response = agent_executor.invoke({"input": "Compare the pricing models of Grok and Claude based on the docs."}) print(response["output"]) ```

#### 4. 优化检索策略

为了提升效果，建议在检索前加入“查询重写（Query Rewriting）”步骤。代理可以将用户的自然语言问题转化为更适合向量搜索的关键词组合。例如，将“Grok 的价格是多少？”重写为“Grok API pricing per token”。这种预处理能显著减少噪声。

在 Grok API 的定价查询场景中，这种重写机制同样有效。通过解析用户意图，系统可以自动匹配最相关的价格文档片段，避免检索到过时的或非官方的价格信息。

性能对比与决策指南

对于大多数初创项目，建议先从传统 RAG 开始，验证基本可行性。当发现检索准确率瓶颈时，再引入 Agentic 架构。参考 模型天梯 中的模型选型指南，选择成本效益最高的 LLM 作为代理核心，可以平衡性能与支出。

风险与边界

1. 延迟增加：Agentic 流程涉及多次 LLM 调用和检索，响应时间可能从秒级增加到十秒级。不适合对实时性要求极高的交互场景。
2. 成本失控：每次检索都消耗 Token。如果代理陷入无限循环或过度检索，成本可能迅速上升。务必设置最大迭代次数和 Token 预算限制。
3. 幻觉风险转移：虽然检索精度提高，但代理的规划逻辑本身可能出错。如果代理错误地分解了问题，后续检索将毫无意义。需要严格的测试用例覆盖。
4. 数据隐私：确保上传到 Bedrock 的知识库数据符合 GDPR 或本地数据合规要求。参考 API 中转 中的安全检测机制，对输入输出进行敏感信息过滤。

*免责声明：本文内容仅供参考，不构成法律或专业建议。AWS 服务条款及定价可能随时变动，请以官方文档为准。*

延伸阅读

• API 中转：了解如何高效管理多模型请求，降低 API 调用成本。
• 模型天梯：对比不同模型在复杂推理任务中的表现，选择合适的代理核心。
• 本地部署：探索在本地环境中运行开源模型，实现数据完全私有化。
• API 实验室：获取更多关于 API 集成与优化的实战技巧。

English summary

This guide explores building an Agentic Retrieval application using LangChain and Amazon Bedrock Knowledge Bases. Unlike traditional RAG, which performs single-step retrieval, Agentic Retrieval employs a planner-executor architecture to handle complex, multi-part queries. The agent decomposes user questions, dynamically decides on retrieval strategies, and synthesizes answers from multiple sources. This approach reduces hallucinations and improves accuracy for tasks like cross-document comparison. However, it comes with higher latency and token costs. Developers should carefully weigh these trade-offs and implement safeguards like iteration limits and query rewriting to optimize performance. For more on API management and model selection, refer to GrokCode's resources on API Transit and Model Ladder.