Agentic RAG：从检索增强生成到智能体驱动的问答系统

Agentic RAG：从检索增强生成到智能体驱动的问答系统

摘要

本文系统性地探讨了Agentic RAG（智能体增强检索生成）的技术架构、核心能力及实现方案。通过分析传统RAG的局限性、Agentic RAG的核心能力层次、以及具体的工程实现，为开发者提供了一套完整的智能体RAG系统设计指南。

---

1. 传统RAG的技术局限性

1.1 架构瓶颈

传统RAG（Retrieval-Augmented Generation）采用"检索 → 生成"的单程模式，存在以下技术瓶颈：

局限性	技术原因	影响
单次检索命中率不稳定	用户查询与文档表达不一致	召回率低，遗漏关键信息
无法处理多跳问题	缺乏跨知识源推理能力	复杂问答质量差
检索质量无法自我纠错	无反馈机制	错误检索导致错误生成
缺乏"自知之明"	无法评估检索结果相关性	不相关问题强行回答

1.2 典型场景分析

问题示例："过去三年公司营收增长了多少？"

传统RAG处理流程：

1. 向量检索"公司营收"相关文档片段
2. 将检索结果直接输入LLM
3. LLM基于片段提取数字回答

潜在问题：

• 可能只找到部分年度数据
• 无法判断数据完整性
• 缺少增长率计算能力

---

2. Agentic RAG的技术架构

2.1 核心设计理念

Agentic RAG将传统RAG的线性流程转换为循环决策过程：

用户查询 → 意图分析 → 检索策略规划 → 执行检索 → 
    ↓
结果评估 ← ┐
    ↓      │
    ├─ 足够 → 生成答案 → 返回
    │
    └─ 不足 → 调整策略 → 再次检索

2.2 四大核心能力

2.2.1 迭代检索（Iterative Retrieval）

不是只检索一次，而是持续检索直到满足信息需求。

class IterativeRetriever:
    def __init__(self, base_retriever, llm, max_iterations=3):
        self.base_retriever = base_retriever
        self.llm = llm
        self.max_iterations = max_iterations
    
    def retrieve_until_sufficient(self, query):
        """迭代检索直到结果充分"""
        results = []
        current_query = query
        
        for i in range(self.max_iterations):
            # 执行检索
            new_results = self.base_retriever.retrieve(current_query)
            results.extend(new_results)
            
            # 评估结果充分性
            if self.is_sufficient(results, query):
                break
                
            # 调整检索策略
            current_query = self.refine_query(current_query, results, query)
            
        return results
    
    def is_sufficient(self, results, original_query):
        """评估检索结果是否充分"""
        evaluation_prompt = f"""
        评估以下检索结果是否足以回答原始问题：
        
        原始问题：{original_query}
        
        检索结果：
        {self.format_results(results)}
        
        请判断：结果是否充分？(是/否)
        如果不充分，缺少什么信息？
        """
        
        response = self.llm.generate(evaluation_prompt)
        return "是" in response

2.2.2 查询转换（Query Transformation）

将用户模糊查询转换为更适合检索的形式。

class QueryTransformer:
    def __init__(self, llm):
        self.llm = llm
    
    def transform(self, user_query):
        """将用户查询转换为检索友好的格式"""
        transformation_prompt = f"""
        将以下用户查询转换为适合检索的查询语句：
        
        原始查询：{user_query}
        
        请提供：
        1. 主要检索查询
        2. 相关关键词列表
        3. 时间范围（如适用）
        4. 实体识别结果
        """
        
        response = self.llm.generate(transformation_prompt)
        return self.parse_transformation(response)

转换示例：

用户查询	转换后查询	附加信息
"那个去年发的产品叫什么来着"	"2025年产品发布记录"	时间范围：2025
"我们跟竞品比有什么优势"	"公司产品列表", "竞品A特性", "竞品B特性", "产品对比分析"	实体：公司产品、竞品A、竞品B
"这个报错是什么原因"	"错误日志分析" + 具体错误代码	需要上下文信息

2.2.3 路由判断（Routing）

根据问题类型决定处理策略。

class QueryRouter:
    def __init__(self, llm):
        self.llm = llm
    
    def route(self, query):
        """根据问题类型路由到不同的处理流程"""
        routing_prompt = f"""
        分析以下问题的类型，并选择处理策略：
        
        问题：{query}
        
        可选策略：
        1. direct_answer - 简单事实型问题，直接回答
        2. multi_retrieval - 需要深入分析的问题，多轮检索
        3. calculation - 需要计算的问题，先检索数据再计算
        4. reject - 完全超出知识库范围，拒绝回答
        
        请选择策略并说明理由：
        """
        
        response = self.llm.generate(routing_prompt)
        return self.parse_routing_decision(response)

2.2.4 多信源校验（Self-Verification）

通过多文档交叉验证提高答案可信度。

class MultiSourceVerifier:
    def __init__(self, llm):
        self.llm = llm
    
    def verify_answer(self, answer, sources):
        """通过多信源交叉验证答案"""
        verification_prompt = f"""
        基于以下文档验证答案的准确性：
        
        答案：{answer}
        
        参考文档：
        {self.format_sources(sources)}
        
        请评估：
        1. 答案是否与所有文档一致？
        2. 是否有文档之间存在矛盾？
        3. 答案的可信度评分（1-5分）
        """
        
        response = self.llm.generate(verification_prompt)
        return self.parse_verification_result(response)

---

3. 工程实现方案

3.1 基于Dify的可视化实现

3.1.1 环境配置

# Dify Agentic RAG 配置建议
agent_config:
  retrieval_settings:
    mode: "high_recall"        # 高召回率模式
    top_k: 5-10               # 返回文档数量
    similarity_threshold: 0.65 # 相似度阈值（适当降低）
  
  agent_prompt: |
    你是一个企业知识库助手。当用户提问时：
    1. 先判断问题是否涉及知识库内容
    2. 如果涉及，进入检索流程
    3. 检索后评估结果质量：
       - 如果结果明确、相关，直接回答
       - 如果结果模糊或不完整，进行第二轮检索
       - 如果多个文档有冲突，指出矛盾点
    4. 如果知识库没有覆盖这个问题，诚实告知用户

3.1.2 工作流设计

[用户输入] → [意图识别节点] → [知识库检索节点] → [结果评估节点]
    ↑                              ↓
    │                    [是否充分？]
    │                          ↓
    │               ┌───────┴───────┐
    │               ↓               ↓
    │         [充分 → 生成答案]  [不充分 → 查询转换]
    │                                      ↓
    └──────────────────────────── [再次检索]

3.2 基于LangChain的代码实现

3.2.1 完整实现示例

from langchain.agents import AgentType, initialize_agent
from langchain.tools import Tool
from langchain.retrievers import WikipediaRetriever
from langchain_ollama import OllamaLLM

class AgenticRAGSystem:
    def __init__(self, model_name="qwen3.5:9b"):
        # 初始化LLM
        self.llm = OllamaLLM(
            model=model_name, 
            base_url="http://localhost:11434"
        )
        
        # 初始化检索器
        self.retriever = self.setup_retriever()
        
        # 初始化Agent
        self.agent = self.setup_agent()
    
    def setup_retriever(self):
        """配置检索器"""
        return WikipediaRetriever(
            top_k_results=5,
            doc_content_chars_max=2000
        )
    
    def search_knowledge_base(self, query):
        """知识库检索工具函数"""
        docs = self.retriever.get_relevant_documents(query)
        return self.format_documents(docs)
    
    def setup_agent(self):
        """配置Agent"""
        tools = [
            Tool(
                name="知识库检索",
                func=self.search_knowledge_base,
                description="用于检索企业内部知识库"
            )
        ]
        
        return initialize_agent(
            tools, 
            self.llm, 
            agent=AgentType.ZERO_SHOT_REACT_DOCSTORE,
            verbose=True,
            max_iterations=3,  # 防止死循环
            early_stopping_method="generate"
        )
    
    def run(self, query):
        """执行查询"""
        return self.agent.run(query)

3.2.2 本地部署配置

# Ollama 本地服务启动
ollama serve

# Dify Docker 部署
cd dify/docker
docker-compose up -d

# 配置本地模型
# Model Name: qwen3.5:9b
# Base URL: http://localhost:11434

---

4. 实际应用场景分析

4.1 企业财报分析

查询："分析这家公司近三年毛利率变化趋势及原因"

Agentic RAG处理流程：

1. 检索近三年财报数据
2. 评估数据完整性（是否三年都有）
3. 如缺失，补充检索
4. 计算毛利率变化
5. 分析原因并生成报告

4.2 竞品对比分析

查询："我们的产品和竞品A、竞品B相比，优势在哪里？"

处理流程：

1. 分别检索自家产品和竞品资料
2. 多信源交叉验证
3. 生成对比分析矩阵
4. 明确指出优势点

4.3 技术支持问答

查询："这个报错是什么原因？之前有类似案例吗？"

处理流程：

1. 检索报错相关文档
2. 检索历史解决案例
3. 计算相似度
4. 如无完全匹配，扩大搜索范围
5. 综合给出解决方案

---

5. 性能优化与陷阱规避

5.1 常见问题与解决方案

问题	原因	解决方案
Agent死循环	检索结果一直"不够"	设置最大检索轮次（如3轮）
Token消耗过快	多轮检索+长上下文	控制最大返回文档数，使用小模型做初筛
检索质量参差	知识库文档质量差	建立文档质量标注，优先使用高可信度文档

5.2 性能优化建议

# 优化的Agent配置
optimized_agent_config = {
    "max_iterations": 3,          # 限制最大检索轮次
    "max_token_usage": 4000,      # 控制Token消耗
    "early_stopping": True,       # 提前终止机制
    "confidence_threshold": 0.8,  # 置信度阈值
    "fallback_strategy": "direct_answer"  # 降级策略
}

5.3 适用场景评估

推荐使用Agentic RAG的场景：

• 需要分析性问答的企业知识库
• 竞品研究、市场分析、财务报告等多源汇总场景
• 技术支持场景，需要交叉验证解决方案
• 已有一定技术基础，想提升知识库体验

不推荐使用Agentic RAG的场景：

• 简单文档检索（传统RAG更高效）
• 知识库规模很小（复杂能力无法施展）
• 对响应速度要求极高（多轮检索增加延迟）

---

6. 传统RAG vs Agentic RAG对比

维度	传统RAG	Agentic RAG	提升幅度
检索次数	一次	多次迭代	显著
查询处理	直接检索	可转换、可改写	显著
结果判断	无	能评估是否足够	从0到1
多信源校验	无	交叉验证	从0到1
复杂问题处理	弱	强	显著
实现难度	低	中	增加
资源消耗	低	略高	增加10-30%

---

7. 总结

7.1 技术演进路径

传统RAG → 增强检索RAG → Agentic RAG
   ↓           ↓            ↓
单次检索    查询重写     自主决策
直接生成    结果排序     迭代优化
            基础过滤     多信源校验

7.2 核心要点

• 架构演进：从"检索 → 生成"到"思考 → 检索 → 判断 → 再思考 → 生成"
• 核心能力：迭代检索、查询转换、路由判断、多信源校验
• 工程价值：解决复杂问题、多源分析、主动纠错

7.3 实施建议

1. 起步阶段：从传统RAG开始，验证场景需求
2. 升级路径：使用Dify等工具低成本升级到Agentic RAG
3. 性能优化：根据实际使用情况调整参数和策略
4. 持续迭代：根据反馈不断优化Agent行为

---

本文档基于当前Agentic RAG技术最佳实践编写，随着技术发展将持续更新。