RAG 系统实战：架构设计的 5 个方案

0. 痛点：为什么你的 RAG 系统回答乱七八糟？

你有没有遇到过这种情况：

场景 1：检索到错误文档

[用户] 我们公司的退款政策是什么？

[Naive RAG]
1. 向量检索：找最相似的 3 个 chunk
2. 扔给 LLM：根据这些文档回答问题

[结果]
Agent：根据文档，退款政策是...（一本正经胡说八道）
[真相] 检索到的 chunk 根本不包含退款政策，而是产品介绍

场景 2：数据过时

[用户] 对比一下 A 产品和 B 产品的优缺点

[Naive RAG]
检索到：A 产品介绍（2020 年）
           B 产品介绍（2019 年）

[结果]
Agent：A 产品优点是... B 产品优点是...（数据过时 6 年）
[用户] 你们不知道 A 产品已经停产了吗？

这就是架构设计问题。

Naive RAG（最直接的 RAG 实现）在很多场景下不够用。本文将介绍 5 种 RAG 架构方案，从简单到复杂，帮你根据场景选择最合适的架构。

---

1. 问题根源：为什么 Naive RAG 不够用？

原因 1：检索精度低

Naive RAG 直接拿用户问题去做向量检索，找到最相似的 chunk 就扔给 LLM。但向量相似 ≠ 语义相关。

问题示例：

• 用户问：“退款政策是什么？”
• 检索到：“退款申请表.docx”（包含"退款"关键词，但不是政策）
• 结果：LLM 基于错误文档回答

根本原因：

• 向量检索只懂"相似"，不懂"相关"
• 没有 Rerank 步骤，无法重新排序
• 没有 Hybrid Search（向量 + 关键词），召回率低

原因 2：没有查询理解

用户问题可能复杂、模糊、有歧义，直接拿去检索效果差。

问题示例：

• 用户问：“那个东西怎么样？”（哪个东西？）
• 用户问：“跟之前那个比怎么样？”（之前哪个？上下文缺失）
• 用户问：“北京和上海哪个好？”（比什么？GDP？人口？房价？）

根本原因：

• 没有查询改写（简化复杂问题）
• 没有查询扩展（增加同义词，提高召回率）
• 没有查询分解（多跳问题分解为多个子问题）

原因 3：没有 Rerank

向量检索返回的 chunk 按向量相似度排序，但向量相似度高的 chunk 不一定最相关。

问题示例：

• 用户问：“如何申请退款？”
• 向量检索返回：
  1. “退款常见问题.pdf”（向量相似度高，但可能不是最直接相关的）
  2. “退款流程.docx”（向量相似度稍低，但最直接相关）
  3. “退款政策.pdf”（向量相似度更低，但可能包含政策细节）
• 如果直接拿 top-1 给 LLM，可能错过最相关的文档

根本原因：

• 向量相似度 ≠ 相关性
• 需要用 Rerank 模型重新排序

---

解决方案 1：Advanced RAG（高级 RAG）

什么是 Advanced RAG？

Advanced RAG 是在 Naive RAG 基础上，增加查询理解、Hybrid Search、Rerank、上下文压缩等优化手段，显著提高检索精度和回答质量。

核心优化点：

优化点	作用	效果
查询理解	改写、扩展、分解用户问题	提高召回率
Hybrid Search	向量检索 + 关键词检索	提高召回率和准确率
Rerank	对检索结果重新排序	提高 Top-k 准确率
上下文压缩	去掉无关内容	减少 Token 消耗，提高回答质量

适用场景

✅ 大多数 RAG 场景（推荐优先使用）
✅ 需要较高回答精度的场景
✅ 用户问题复杂、模糊的场景

❌ 不适合：

• 简单场景（FAQ 问答，Naive RAG 就够了）
• 对延迟极其敏感的场景（Advanced RAG 增加延迟）

实现原理（文字描述）

步骤 1：查询理解

• 查询改写：用 LLM 把复杂问题改写成更清晰的问题
  • 例如：“那个东西怎么样？” → “iPhone 15 怎么样？”
• 查询扩展：增加同义词，提高召回率
  • 例如：“退款” → “退款 退货 取消订单”
• 查询分解：把多跳问题分解为多个子问题
  • 例如：“对比 A 和 B 的优缺点” → [“A 的优点”, “A 的缺点”, “B 的优点”, “B 的缺点”]

步骤 2：Hybrid Search

• 向量检索：用 Embedding 模型把查询和文档转成向量，找最相似的 chunk
• 关键词检索（BM25）：用 BM25 算法做关键词匹配
• 合并：用 Reciprocal Rank Fusion（RRF）合并两个结果集

步骤 3：Rerank

• 用 Rerank 模型（如 BGE Reranker）对检索结果重新打分
• Rerank 模型比 Embedding 模型更精准（考虑查询和文档的交互）

步骤 4：上下文压缩

• 用 LLM 判断每个 chunk 是否相关
• 只保留相关 chunk，并压缩（只保留相关句子）

优点

✅ 检索精度高（Hybrid Search + Rerank）
✅ 回答准确（上下文压缩，减少噪声）
✅ 适用场景广（大多数场景都能用）

缺点

❌ 实现复杂（需要实现查询理解、Hybrid Search、Rerank、上下文压缩）
❌ 延迟较高（多个步骤增加延迟）
❌ 成本较高（多次调用 LLM 和 Rerank 模型）

核心代码示例（精简版）

class AdvancedRAG:
    """Advanced RAG"""
    def __init__(self, embedding_model, rerank_model, llm):
        self.embedding_model = embedding_model
        self.rerank_model = rerank_model
        self.llm = llm
    
    def process(self, query: str) -> str:
        """处理用户问题"""
        # 1. 查询理解
        processed_query = self._query_understanding(query)
        
        # 2. Hybrid Search
        retrieved_chunks = self._hybrid_search(processed_query)
        
        # 3. Rerank
        reranked_chunks = self._rerank(processed_query, retrieved_chunks)
        
        # 4. 上下文压缩
        compressed_chunks = self._context_compression(processed_query, reranked_chunks)
        
        # 5. 调用 LLM
        context = "\n".join([c["text"] for c in compressed_chunks])
        response = self.llm(f"根据以下文档回答问题：\n{context}\n\n问题：{query}")
        
        return response
    
    def _query_understanding(self, query: str) -> str:
        """查询理解（改写、扩展、分解）"""
        # 简化：用 LLM 改写
        prompt = f"改写问题：{query}\n改写后："
        return self.llm(prompt).strip()
    
    def _hybrid_search(self, query: str, top_k: int = 10) -> List[Dict]:
        """Hybrid Search（向量检索 + 关键词检索）"""
        # 向量检索
        query_embedding = self.embedding_model.encode(query)
        vector_results = vector_search(query_embedding, top_k=top_k)
        
        # 关键词检索（BM25）
        keyword_results = bm25_search(query, top_k=top_k)
        
        # 合并（Reciprocal Rank Fusion）
        merged = self._reciprocal_rank_fusion(vector_results, keyword_results)
        
        return merged[:top_k]
    
    def _rerank(self, query: str, chunks: List[Dict], top_k: int = 3) -> List[Dict]:
        """Rerank（重新排序）"""
        scores = self.rerank_model.compute_score(query, [c["text"] for c in chunks])
        
        for i, chunk in enumerate(chunks):
            chunk["rerank_score"] = scores[i]
        
        reranked = sorted(chunks, key=lambda x: x["rerank_score"], reverse=True)
        
        return reranked[:top_k]
    
    def _context_compression(self, query: str, chunks: List[Dict]) -> List[Dict]:
        """上下文压缩（去掉无关内容）"""
        compressed = []
        
        for chunk in chunks:
            # 用 LLM 判断 chunk 是否相关
            prompt = f"文档：{chunk['text']}\n\n问题：{query}\n\n这个文档是否包含回答问题的相关信息？\n只回答 \"是\" 或 \"否\"。"
            response = self.llm(prompt).strip()
            
            if response == "是":
                compressed.append(chunk)
        
        return compressed

---

解决方案 2：Modular RAG（模块化 RAG）

什么是 Modular RAG？

Modular RAG 是把 RAG 流程拆成独立的模块（如查询理解模块、检索模块、Rerank 模块、生成模块），每个模块可以独立替换、组合、扩展。

核心思想：像搭积木一样搭建 RAG 系统。

适用场景

✅ 需要灵活扩展的场景（例如：今天用这个 Embedding 模型，明天换另一个）
✅ 需要 A/B 测试的场景（例如：测试哪种查询理解策略更好）
✅ 复杂 RAG 系统（例如：多个检索源、多种 Rerank 策略）

❌ 不适合：

• 简单场景（Modular RAG 过度设计）
• 小团队（维护成本高）

实现原理（文字描述）

核心模块：

模块	作用	可替换性
查询理解模块	改写、扩展、分解用户问题	✅ 可替换（用 LLM 或用规则）
检索模块	向量检索、关键词检索、Hybrid Search	✅ 可替换（换 Embedding 模型、换向量数据库）
Rerank 模块	对检索结果重新排序	✅ 可替换（换 Rerank 模型）
生成模块	调用 LLM 生成回答	✅ 可替换（换 LLM、换 Prompt）

工作流程：

用户问题
    ↓
查询理解模块（改写、扩展、分解）
    ↓
检索模块（Hybrid Search）
    ↓
Rerank 模块（重新排序）
    ↓
生成模块（调用 LLM）
    ↓
返回回答

优点

✅ 灵活（模块可独立替换）
✅ 可扩展（新增模块不影响现有模块）
✅ 可测试（A/B 测试某个模块的效果）

缺点

❌ 实现复杂（需要设计模块接口）
❌ 模块间可能需要协调（例如：查询理解模块的输出格式要匹配检索模块的输入格式）
❌ 维护成本高（模块多了，维护成本高）

核心代码示例（精简版）

from abc import ABC, abstractmethod

class Module(ABC):
    """模块基类"""
    @abstractmethod
    def process(self, data: Dict) -> Dict:
        pass

class QueryUnderstandingModule(Module):
    """查询理解模块"""
    def __init__(self, llm):
        self.llm = llm
    
    def process(self, data: Dict) -> Dict:
        query = data["query"]
        
        # 查询改写
        rewritten = self.llm(f"改写问题：{query}\n改写后：").strip()
        
        data["processed_query"] = rewritten
        return data

class RetrievalModule(Module):
    """检索模块"""
    def __init__(self, embedding_model):
        self.embedding_model = embedding_model
    
    def process(self, data: Dict) -> Dict:
        query = data["processed_query"]
        
        # 向量检索
        query_embedding = self.embedding_model.encode(query)
        retrieved_chunks = vector_search(query_embedding, top_k=10)
        
        data["retrieved_chunks"] = retrieved_chunks
        return data

class ModularRAG:
    """Modular RAG"""
    def __init__(self):
        self.modules = []
    
    def add_module(self, module: Module):
        """添加模块"""
        self.modules.append(module)
    
    def process(self, query: str) -> str:
        """处理用户问题"""
        data = {"query": query}
        
        # 依次调用模块
        for module in self.modules:
            data = module.process(data)
        
        return data["response"]

# 使用示例
rag = ModularRAG()

# 添加模块（可灵活组合）
rag.add_module(QueryUnderstandingModule(llm=...))
rag.add_module(RetrievalModule(embedding_model=...))
rag.add_module(RerankModule(rerank_model=...))
rag.add_module(GenerationModule(llm=...))

response = rag.process("我们公司的退款政策是什么？")

---

解决方案 3：Graph RAG（知识图谱 RAG）

什么是 Graph RAG？

Graph RAG 是在传统 RAG 基础上，增加知识图谱（Knowledge Graph），利用实体和关系增强检索和回答。

核心思想：不仅检索 chunk，还检索知识图谱中的实体（Entity）和关系（Relation）。

适用场景

✅ 复杂关系查询（例如：“张三负责什么项目？”（需要查 张三 → 负责 → 项目））
✅ 多跳推理（例如：“A 公司的 CEO 是谁？”（需要查 A 公司 → CEO → 张三））
✅ 实体密集的文档（例如：人物传记、公司介绍、学术论文）

❌ 不适合：

• 简单事实查询（“退款政策是什么？” 不需要知识图谱）
• 构建知识图谱成本高的场景（需要大量标注数据）

实现原理（文字描述）

步骤 1：构建知识图谱

• 从文档中提取实体（人名、地名、组织名等）和关系（“负责”、“位于”、"成立于"等）
• 构建知识图谱（节点 = 实体，边 = 关系）

步骤 2：检索

• 向量检索：检索相关 chunk
• 知识图谱检索：提取查询中的实体，在知识图谱中查找相关实体和关系

步骤 3：生成回答

• 把 chunk 和知识图谱信息一起作为上下文
• 调用 LLM 生成回答

优点

✅ 回答更准确（利用知识图谱中的结构化信息）
✅ 能处理复杂关系查询（传统 RAG 做不到）
✅ 可解释性强（可以展示推理路径）

缺点

❌ 构建知识图谱成本高（需要 NLP 模型提取实体和关系）
❌ 知识图谱可能不完整（提取过程可能有遗漏）
❌ 实现复杂（需要维护知识图谱）

核心代码示例（精简版）

class GraphRAG:
    """Graph RAG"""
    def __init__(self, embedding_model, llm, kg_builder):
        self.embedding_model = embedding_model
        self.llm = llm
        self.kg_builder = kg_builder  # 知识图谱构建器
        self.knowledge_graph = None
    
    def build_knowledge_graph(self, documents: List[str]):
        """构建知识图谱"""
        self.knowledge_graph = self.kg_builder.build(documents)
        print(f"【知识图谱】构建完成，包含 {len(self.knowledge_graph.nodes)} 个节点")
    
    def retrieve_from_kg(self, query: str, top_k: int = 5) -> List[Dict]:
        """从知识图谱检索"""
        # 1. 提取查询中的实体
        entities = self._extract_entities(query)
        
        # 2. 在图谱中查找相关实体和关系
        relevant_subgraphs = []
        for entity in entities:
            if entity in self.knowledge_graph.nodes:
                neighbors = self.knowledge_graph.neighbors(entity)
                subgraph = {
                    "entity": entity,
                    "neighbors": neighbors,
                    "edges": self.knowledge_graph.edges(entity)
                }
                relevant_subgraphs.append(subgraph)
        
        return relevant_subgraphs[:top_k]
    
    def _extract_entities(self, query: str) -> List[str]:
        """提取实体（用 LLM 提取）"""
        prompt = f"从以下问题中提取实体（人名、地名、组织名等）：\n\n问题：{query}\n\n实体（每行一个）："
        response = self.llm(prompt)
        entities = [line.strip() for line in response.strip().split("\n") if line.strip()]
        return entities
    
    def process(self, query: str) -> str:
        """处理用户问题"""
        # 1. 向量检索（检索 chunk）
        query_embedding = self.embedding_model.encode(query)
        retrieved_chunks = vector_search(query_embedding, top_k=3)
        
        # 2. 知识图谱检索
        kg_subgraphs = self.retrieve_from_kg(query, top_k=3)
        
        # 3. 拼接上下文
        context = ""
        
        # chunk 上下文
        context += "文档片段：\n"
        for chunk in retrieved_chunks:
            context += f"- {chunk['text']}\n"
        
        # 知识图谱上下文
        context += "\n知识图谱：\n"
        for subgraph in kg_subgraphs:
            context += f"实体：{subgraph['entity']}\n"
            context += f"邻居：{subgraph['neighbors']}\n"
            context += f"关系：{subgraph['edges']}\n"
        
        # 4. 调用 LLM
        response = self.llm(f"根据以下信息回答问题：\n\n信息：\n{context}\n\n问题：{query}")
        
        return response

---

解决方案 4：Agentic RAG（Agent + RAG）

什么是 Agentic RAG？

Agentic RAG 是用 Agent 动态决定检索策略。Agent 可以：

• 理解用户意图
• 动态决定检索几次、检索什么
• 多次检索、反思、修正

核心思想：让 Agent 像人一样思考和行动，而不是固定的 RAG 流程。

适用场景

✅ 复杂多跳问题（例如：“对比 A 产品和 B 产品的优缺点，并分析市场前景”）
✅ 需要多次检索的问题（例如：第一次检索结果不好，Agent 可以优化查询重新检索）
✅ 需要推理的问题（例如：“张三负责什么项目？这个项目进展如何？”）

❌ 不适合：

• 简单问题（“退款政策是什么？” 不需要 Agentic RAG）
• 对延迟和成本敏感的场景（Agentic RAG 延迟高、成本高）

实现原理（文字描述）

工作流程：

用户问题
    ↓
Agent 理解意图
    ↓
Agent 决定下一步行动：
    - 检索（retrieve）
    - 回答（answer）
    - 优化查询（refine）
    ↓
[如果 action = "retrieve"]
    检索
    ↓
    把检索结果加入上下文
    ↓
    回到 Agent 决定下一步
    
[如果 action = "answer"]
    生成回答
    ↓
    返回回答
    
[如果 action = "refine"]
    优化查询
    ↓
    用优化后的查询重新检索
    ↓
    回到 Agent 决定下一步

Agent 决策过程（用 LLM 实现）：

• 输入：用户问题 + 已检索信息
• 输出：下一步行动（retrieve / answer / refine）

优点

✅ 动态、灵活（能处理复杂问题）
✅ 能多次检索和修正（提高回答质量）
✅ 能处理多跳问题（传统 RAG 做不到）

缺点

❌ 延迟高（多次迭代）
❌ 成本高（多次调用 LLM）
❌ 可能死循环（Agent 一直检索，不回答）

核心代码示例（精简版）

class AgenticRAG:
    """Agentic RAG"""
    def __init__(self, llm, retriever):
        self.llm = llm
        self.retriever = retriever
        self.max_iterations = 5  # 最大迭代次数
    
    def process(self, query: str) -> str:
        """处理用户问题"""
        # Agent 理解意图
        intent = self._understand_intent(query)
        
        # Agent 动态决定检索策略
        iterations = 0
        retrieved_info = []
        
        while iterations < self.max_iterations:
            # Agent 决定下一步行动
            action = self._decide_action(query, retrieved_info)
            
            if action["type"] == "retrieve":
                # 检索
                chunks = self.retriever.retrieve(action["query"], top_k=action["top_k"])
                retrieved_info.extend(chunks)
            
            elif action["type"] == "answer":
                # 回答
                response = self._generate_answer(query, retrieved_info)
                return response
            
            elif action["type"] == "refine":
                # 优化查询
                refined_query = self._refine_query(query, retrieved_info)
                query = refined_query
            
            iterations += 1
        
        # 达到最大迭代次数，强制回答
        response = self._generate_answer(query, retrieved_info)
        return response
    
    def _decide_action(self, query: str, retrieved_info: List[Dict]) -> Dict:
        """决定下一步行动（用 LLM 决定）"""
        prompt = f"""
用户问题：{query}

已检索信息：
{retrieved_info}

请决定下一步行动（retrieve / answer / refine）。

输出格式（JSON）：
{{"type": "retrieve", "query": "检索查询", "top_k": 3}}
或
{{"type": "answer"}}
或
{{"type": "refine", "refined_query": "优化后的查询"}}
"""
        
        response = self.llm(prompt)
        
        # 解析 JSON
        import json
        try:
            action = json.loads(response)
            return action
        except json.JSONDecodeError:
            # 解析失败，默认回答
            return {"type": "answer"}

---

解决方案 5：Self-RAG（自反思 RAG）

什么是 Self-RAG？

Self-RAG 是让 LLM 自我反思，决定是否需要检索。

核心思想：

1. LLM 先判断是否需要检索
2. 如果需要检索，检索后 LLM 再判断检索结果是否相关
3. 如果不相关，LLM 可以决定重新检索或使用自身知识回答

适用场景

✅ 需要减少不必要检索的场景（例如：用户问 “你好”，不需要检索）
✅ 检索结果可能不相关的场景（例如：用户问了一个文档中没有的问题）
✅ 需要降低成本的场景（减少不必要的检索和 LLM 调用）

❌ 不适合：

• 所有问题都需要检索的场景（Self-RAG 增加延迟）
• 对延迟极其敏感的场景（Self-RAG 需要多次调用 LLM 判断）

实现原理（文字描述）

工作流程：

用户问题
    ↓
LLM 判断是否需要检索
    ↓
[如果不需要检索]
    直接用 LLM 自身知识回答
    ↓
    返回回答
    
[如果需要检索]
    检索
    ↓
    LLM 判断检索结果是否相关
    ↓
    [如果相关]
        用检索结果生成回答
        ↓
        返回回答
    
    [如果不相关]
        优化查询，重新检索
        ↓
        用重新检索的结果生成回答
        ↓
        返回回答

优点

✅ 减少不必要的检索（降低成本）
✅ 提高回答质量（只使用相关检索结果）
✅ 能处理边界情况（例如：用户问了一个文档中没有的问题）

缺点

❌ 依赖 LLM 判断（可能误判）
❌ 延迟较高（多次调用 LLM 判断）
❌ 实现复杂（需要训练 LLM 学会判断）

核心代码示例（精简版）

class SelfRAG:
    """Self-RAG"""
    def __init__(self, llm, retriever):
        self.llm = llm
        self.retriever = retriever
    
    def process(self, query: str) -> str:
        """处理用户问题"""
        # 1. LLM 判断是否需要检索
        need_retrieval = self._judge_need_retrieval(query)
        
        if not need_retrieval:
            # 不需要检索，直接用 LLM 回答
            response = self.llm(query)
            return response
        
        # 2. 需要检索
        retrieved_chunks = self.retriever.retrieve(query, top_k=3)
        
        # 3. LLM 判断检索结果是否相关
        is_relevant = self._judge_relevance(query, retrieved_chunks)
        
        if not is_relevant:
            # 检索结果不相关，优化查询重新检索
            refined_query = self._refine_query(query)
            retrieved_chunks = self.retriever.retrieve(refined_query, top_k=3)
        
        # 4. 生成回答
        context = "\n".join([c["text"] for c in retrieved_chunks])
        response = self.llm(f"根据以下信息回答问题：\n\n信息：\n{context}\n\n问题：{query}")
        
        return response
    
    def _judge_need_retrieval(self, query: str) -> bool:
        """判断是否需要检索"""
        prompt = f"用户问题：{query}\n\n是否需要检索外部信息来回答这个问题？\n只回答 \"是\" 或 \"否\"。"
        response = self.llm(prompt).strip()
        return response == "是"
    
    def _judge_relevance(self, query: str, chunks: List[Dict]) -> bool:
        """判断检索结果是否相关"""
        context = "\n".join([c["text"] for c in chunks])
        prompt = f"检索到的信息：\n{context}\n\n用户问题：{query}\n\n这些信息是否包含回答问题的相关内容？\n只回答 \"是\" 或 \"否\"。"
        response = self.llm(prompt).strip()
        return response == "是"

---

效果对比

方案	检索精度	实现难度	延迟	成本	适用场景
Naive RAG	⭐⭐	⭐	低	低	简单场景
Advanced RAG	⭐⭐⭐⭐	⭐⭐⭐	中	中	大多数场景
Modular RAG	⭐⭐⭐⭐	⭐⭐⭐	中	中	需要灵活扩展
Graph RAG	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	高	高	复杂关系查询
Agentic RAG	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	高	高	复杂多跳问题
Self-RAG	⭐⭐⭐⭐	⭐⭐⭐	中	中	需要减少不必要检索

---

避坑指南

1. 不要一开始就上最复杂的架构

错误做法：

# 简单场景用 Agentic RAG（过度设计）
rag = AgenticRAG(...)
response = rag.process("今天天气怎么样？")

正确做法：

# 根据场景选择架构
if is_simple_query(query):
    rag = NaiveRAG(...)  # 简单场景用 Naive RAG
else:
    rag = AdvancedRAG(...)  # 复杂场景用 Advanced RAG

2. 不要忽略评估

错误做法：

# 没有评估（不知道效果好不好）
rag = AdvancedRAG(...)
response = rag.process(query)

正确做法：

# 建立评估指标
metrics = evaluate_rag(
    rag=rag,
    test_cases=...,
    metrics=["retrieval_precision", "answer_accuracy"]
)
print(f"评估指标：{metrics}")

3. 不要忽略延迟和成本

错误做法：

# 用 Agentic RAG 处理所有问题（延迟高、成本高）
rag = AgenticRAG(...)
for query in all_queries:
    response = rag.process(query)

正确做法：

# 根据场景选择架构
for query in all_queries:
    if is_complex_query(query):
        rag = AgenticRAG(...)
    else:
        rag = AdvancedRAG(...)
    response = rag.process(query)

---

总结

RAG 架构设计是系统成功的关键，需要根据场景选择：

简单场景（FAQ） → Naive RAG
大多数场景 → Advanced RAG
需要灵活扩展 → Modular RAG
复杂关系查询 → Graph RAG
复杂多跳问题 → Agentic RAG
需要减少不必要检索 → Self-RAG

关键原则：

1. 优先用 Advanced RAG，性价比最高
2. 复杂场景才用 Graph RAG 或 Agentic RAG
3. 建立评估指标，持续优化
4. 注意延迟和成本

---

下一篇预告：《RAG 系统实战：文档切分策略的 5 个方案》