1. 从关键词看本质：Agent 时代到底在解决什么问题
Agent 这个词这两年几乎被说烂了。但如果你真正动手搭过几个能跑起来的 Agent 项目，就会发现一个很尴尬的事实：大部分 Agent 的瓶颈根本不在模型本身，而在“它到底知不知道自己在干什么”。模型再强，如果检索回来的上下文是错的、过时的、或者压根不相关，那它输出的东西就是一本正经地胡说八道。
这就是 RAG（Retrieval-Augmented Generation，检索增强生成）在 Agent 时代反而变得更重要的原因。早期 RAG 的定位很简单：给大模型外挂一个知识库，用户问什么，先去向量库里捞几段相关文本，拼到 prompt 里让模型回答。这套逻辑在“单轮问答”场景下够用，但一旦进入 Agent 场景——多轮对话、工具调用、任务规划、记忆管理——传统 RAG 就开始露怯了。
我自己的体会是，Agent 对 RAG 的要求和普通问答对 RAG 的要求，完全不是一个量级。普通问答只需要“检索到相关段落”，Agent 需要的是“检索到正确的、结构化的、可推理的、有时序关系的上下文”。这就催生了一堆新的 RAG 变体：GraphRAG、LightRAG、Agentic RAG、Ontology RAG……名字越来越多，但很多人其实分不清它们到底有什么区别，什么时候该用哪个。
这篇内容就是想把这件事讲清楚。我会从 Agent 场景的实际需求出发，把目前主流的 8 种 RAG 方案逐一拆解，说清楚每种方案的核心思路、适用场景、实操要点，以及我在实际项目中踩过的坑。不管你是刚接触 RAG 的新手，还是已经在搭 Agent 项目的开发者，应该都能从中找到可以直接参考的东西。
先给一个全局的认知框架：RAG 的演进本质上是在解决三个层面的问题——检索精度（能不能找到对的）、上下文组织（找到之后怎么用）、与 Agent 的协作方式（什么时候检索、检索几次、检索结果怎么影响决策）。下面这 8 种方案，基本都可以放到这个框架里理解。
2. 八种 RAG 方案逐一拆解
2.1 Naive RAG：最基础的检索增强，也是最多人踩坑的起点
Naive RAG 就是最经典的“向量检索 + 拼接 prompt”模式。流程很简单：文档切块（chunking）→ 用 embedding 模型把每个 chunk 转成向量 → 存进向量数据库 → 用户提问时，把问题也转成向量 → 做相似度检索 → 取 Top-K 个 chunk 拼到 prompt 里 → 交给大模型生成回答。
这套东西看起来简单，但实际做起来坑非常多。我见过太多项目卡在第一步就出问题了。
切块策略是第一个大坑。很多人直接用固定长度切，比如 512 个 token 一刀切。这种做法在技术文档上勉强能用，但遇到法律合同、学术论文、产品手册这类有强结构的内容，一刀切会把完整的语义单元切碎。比如一个条款被切成两半，检索到前半段但后半段丢了，模型给出的答案就是残缺的。
我的做法是：优先按语义边界切，其次按结构切，最后才按长度切。具体来说，Markdown 文档按标题层级切，代码按函数或类切，PDF 按段落切。如果实在没有结构，用递归切分（RecursiveCharacterTextSplitter）比固定长度好得多，它会优先在段落、句子、逗号这些自然边界处断开。
from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=800, chunk_overlap=150, separators=["\n\n", "\n", "。", "！", "？", ".", " ", ""] ) chunks = splitter.split_text(document)注意chunk_overlap这个参数。它的作用是让相邻 chunk 之间有重叠内容，防止关键信息刚好落在切割边界上被丢掉。一般设成 chunk_size 的 15% 到 20% 比较稳妥。太小了起不到保护作用，太大了会导致检索结果冗余、浪费 token。
第二个坑是 embedding 模型的选择。很多人默认用 OpenAI 的 text-embedding-ada-002，但这个模型对中文的支持其实一般。如果你的知识库主要是中文内容，建议用 BGE 系列（BAAI/bge-large-zh-v1.5）或者 M3E 这类中文优化过的模型。实测下来，中文场景下 BGE 的检索命中率比 ada-002 高出不少。
第三个坑是 Top-K 的设置。K 太小，可能漏掉关键信息；K 太大，噪声太多，模型反而容易被干扰。我的经验是：先用 5 到 10 做召回，然后用 rerank 模型（比如 bge-reranker）做精排，取前 3 到 5 个最相关的塞进 prompt。这样既保证了召回率，又控制了噪声。
注意：Naive RAG 最大的问题不是“检索不到”，而是“检索到了但模型不用”。很多时候检索结果明明包含正确答案，但模型还是按自己的知识回答。解决办法是在 prompt 里明确要求“只根据以下上下文回答，如果上下文中没有相关信息，就说不知道”。
2.2 Advanced RAG：在检索前后做文章，把精度拉上来
Advanced RAG 不是某一种具体技术，而是一类优化思路的统称。核心思想是：在 Naive RAG 的基础上，在检索前、检索中、检索后三个阶段分别做优化。
检索前优化主要包括查询改写（Query Rewriting）和查询扩展（Query Expansion）。用户的问题往往很短、很模糊，直接拿去检索效果不好。比如用户问“这个怎么配置”，你根本不知道“这个”指什么。查询改写就是用大模型把用户问题改写成更适合检索的形式，比如结合对话历史补全指代、扩展同义词、生成多个查询变体。
# 查询改写的简单实现 rewrite_prompt = """ 根据以下对话历史，将用户的最新问题改写成一个独立的、完整的检索查询。 对话历史：{history} 用户问题：{question} 改写后的查询： """ rewritten_query = llm.invoke(rewrite_prompt.format( history=history, question=question ))检索中优化最典型的是混合检索（Hybrid Search）。纯向量检索擅长语义匹配，但对精确关键词的匹配能力弱。比如用户搜一个特定的错误码“ERR_4032”，向量检索可能返回一堆语义相似但错误码不同的内容。混合检索就是把向量检索和关键词检索（BM25）结合起来，两路召回后做融合排序。实测下来，混合检索在技术文档场景下的召回率比纯向量检索高 20% 以上。
检索后优化主要是 rerank。向量检索用的是双塔模型，query 和 document 分别编码后算余弦相似度，速度快但精度有限。Rerank 用的是交叉编码器（Cross-Encoder），把 query 和 document 拼在一起过模型，精度高但速度慢。所以典型做法是：向量检索召回 Top-50，rerank 精排取 Top-5。
| 优化阶段 | 技术手段 | 解决的问题 | 代价 |
|---|---|---|---|
| 检索前 | 查询改写 | 用户问题模糊、指代不清 | 增加一次 LLM 调用 |
| 检索前 | 查询扩展 | 单一查询覆盖不全 | 增加检索次数 |
| 检索中 | 混合检索 | 纯向量对关键词不敏感 | 需要维护两套索引 |
| 检索后 | Rerank | 向量相似度精度不够 | 增加推理延迟 |
实操心得：Advanced RAG 的优化手段不需要全上。先做 rerank，性价比最高；如果用户 query 普遍很短很模糊，再加查询改写；如果知识库里有大量专有名词和代码，加混合检索。
2.3 GraphRAG：用知识图谱解决“全局性问题”
GraphRAG 是微软提出来的方案，核心思路是用知识图谱来组织知识，而不是简单的文本块。它解决的是传统 RAG 的一个根本性缺陷：无法回答需要跨文档、跨段落综合推理的问题。
举个例子。假设你有一个包含几百份项目文档的知识库，用户问“这个项目的主要风险有哪些”。传统 RAG 的做法是检索最相关的几个 chunk，但“主要风险”这个信息可能分散在几十份文档里，没有任何一个 chunk 包含完整答案。GraphRAG 的做法是：先从所有文档中抽取实体和关系，构建知识图谱；然后对图谱做社区检测（Community Detection），把紧密相关的实体聚成社区；最后为每个社区生成摘要。回答全局性问题时，直接使用社区摘要，而不是原始文本块。
GraphRAG 的索引过程比较重，大致分几步：
- 实体和关系抽取：用 LLM 从每个文本块中抽取实体（人、组织、事件、概念）和它们之间的关系。
- 图谱构建：把所有实体和关系合并成一张全局图。
- 社区检测：用 Leiden 算法对图做聚类，形成层次化的社区结构。
- 社区摘要生成：为每个社区生成自然语言摘要。
# GraphRAG 索引配置示例（简化） config = { "entity_extraction": { "model": "gpt-4", "prompt": "从以下文本中抽取实体和关系..." }, "community_detection": { "algorithm": "leiden", "max_cluster_size": 10 }, "community_summary": { "model": "gpt-4", "max_tokens": 500 } }GraphRAG 的代价也很明显：索引成本高（需要大量 LLM 调用）、构建时间长、更新麻烦。所以它适合的场景是：知识库相对稳定、需要回答全局性/总结性问题、对成本不敏感。如果你的知识库每天更新，或者只需要回答具体的细节问题，GraphRAG 可能不是最优选择。
2.4 LightRAG：GraphRAG 的轻量替代，成本和效果的平衡
LightRAG 可以理解为“GraphRAG 的实用版”。它保留了图结构的思想，但在实现上做了大量简化，把索引成本和查询延迟降了下来。
LightRAG 的核心创新在于它的双层检索机制：低层检索关注具体实体和细节，高层检索关注抽象概念和主题。查询时同时进行两层检索，然后把结果合并。这样既保留了图结构对全局性问题的优势，又避免了 GraphRAG 那种动辄几小时的索引时间。
另一个关键设计是增量更新。GraphRAG 每次新增文档都要重新构建整个图谱，LightRAG 支持增量插入，新文档的实体和关系可以直接合并到现有图中。这对需要频繁更新知识库的场景非常友好。
from lightrag import LightRAG, QueryParam rag = LightRAG( working_dir="./lightrag_data", llm_model_func=llm_complete, embedding_func=embedding_func ) # 插入文档 rag.insert(document_text) # 查询（支持多种模式） result = rag.query( "这个项目的主要风险是什么", param=QueryParam(mode="hybrid") # 可选 local/global/hybrid )LightRAG 的mode参数值得说一下。local模式只检索低层实体，适合具体问题；global模式只检索高层概念，适合总结性问题；hybrid模式两者都用，适合大多数场景。我实测下来，hybrid 模式在综合表现上最好，但延迟也最高。如果对延迟敏感，可以根据问题类型动态选择模式。
踩坑记录：LightRAG 的实体抽取质量高度依赖 LLM 的能力。我用小模型（7B 级别）跑的时候，抽取出来的实体关系质量很差，图谱基本没法用。换成 GPT-4 级别后效果明显提升。所以如果预算有限，建议至少在实体抽取这一步用好一点的模型。
2.5 Agentic RAG：让 Agent 自己决定怎么检索
前面几种 RAG 本质上都是“被动检索”——系统按照固定流程去检索，然后把结果给模型。Agentic RAG 的思路完全不同：把检索能力作为工具交给 Agent，让 Agent 自己决定什么时候检索、检索什么、检索几次。
这个转变很关键。传统 RAG 是“先检索再生成”，Agentic RAG 是“边推理边检索”。Agent 可以根据当前任务的需要，自主规划检索策略。比如：
- 简单事实性问题：直接回答，不检索。
- 需要外部知识：调用检索工具，取 Top-K。
- 检索结果不完整：改写查询，再检索一次。
- 需要多步推理：先检索 A，根据 A 的结果决定下一步检索 B。
# Agentic RAG 的工具定义示例 tools = [ { "name": "search_knowledge_base", "description": "在知识库中检索相关信息。当需要查找事实、数据、文档内容时使用。", "parameters": { "query": {"type": "string", "description": "检索查询"}, "top_k": {"type": "integer", "default": 5} } }, { "name": "search_by_entity", "description": "按实体名称精确查找。当已知具体实体名称时使用。", "parameters": { "entity_name": {"type": "string"} } } ]Agentic RAG 的优势在于灵活性和适应性，但代价是延迟和成本不可控。Agent 可能检索一次就够，也可能检索五六次还在绕圈子。我的做法是设置一个最大检索次数（通常 3 到 5 次），超过就强制生成回答，避免无限循环。
另一个实操要点是检索结果的压缩。Agent 多轮检索后，上下文里会积累大量检索结果，很容易超出模型窗口。需要在每轮检索后做一次压缩，只保留与当前子任务最相关的信息。
2.6 Ontology RAG：用本体论约束知识结构
Ontology RAG 的核心思想是：在构建知识库之前，先定义一个领域本体（Ontology），也就是这个领域里有哪些概念、属性、关系。然后用这个本体来指导知识的抽取、组织和检索。
举个例子。假设你在做一个医疗领域的 Agent，本体可能包括：疾病、症状、药物、检查项目、治疗方案等概念，以及“疾病-症状”关系、“药物-治疗疾病”关系、“检查-诊断疾病”关系等。当用户问“头痛可能是什么病”时，系统不是做简单的向量相似度匹配，而是沿着本体中的关系路径去检索：头痛 → 症状 → 关联疾病 → 返回结果。
Ontology RAG 的优势在于检索精度高、可解释性强。因为检索路径是沿着预定义的关系走的，不会出现“语义相似但逻辑无关”的结果。但它的局限性也很明显：本体需要领域专家来定义，构建成本高；而且本体一旦确定，灵活性就差，难以处理本体之外的问题。
| 对比维度 | Ontology RAG | GraphRAG | 传统 RAG |
|---|---|---|---|
| 知识组织 | 预定义本体 | 自动抽取图谱 | 文本块 |
| 构建成本 | 高（需专家） | 中高（需 LLM） | 低 |
| 检索精度 | 高 | 中高 | 中 |
| 灵活性 | 低 | 中 | 高 |
| 适用场景 | 垂直领域、规则明确 | 通用领域、全局问题 | 通用问答 |
我的建议：Ontology RAG 适合医疗、法律、金融这类对精度要求极高、且有成熟领域知识体系的场景。普通场景用 GraphRAG 或 LightRAG 就够了，没必要上本体。
2.7 Hybrid RAG：多路召回 + 融合排序的工程实践
Hybrid RAG 严格来说不算一种独立的 RAG 架构，而是一种工程实践模式。它的核心思路是：不依赖单一检索源，而是同时使用多种检索方式，然后做融合排序。
常见的组合包括：
- 向量检索 + BM25 关键词检索
- 稠密检索 + 稀疏检索
- 文本检索 + 图检索
- 不同 embedding 模型的检索结果融合
融合排序的常用方法有 RRF（Reciprocal Rank Fusion）和加权分数融合。RRF 的公式很简单：对每个文档，把它在各路检索中的排名取倒数后求和。排名越靠前，得分越高。
def reciprocal_rank_fusion(results_list, k=60): """ results_list: 多个检索结果列表，每个列表是文档ID的有序列表 k: 平滑参数，通常取60 """ scores = {} for results in results_list: for rank, doc_id in enumerate(results): if doc_id not in scores: scores[doc_id] = 0 scores[doc_id] += 1 / (k + rank + 1) return sorted(scores.items(), key=lambda x: x[1], reverse=True)RRF 的好处是不需要归一化不同检索源的分数，直接基于排名融合，简单且鲁棒。我在多个项目里用下来，RRF 的效果比加权分数融合更稳定，因为不同检索源的分数分布差异很大，归一化很容易出问题。
2.8 Modular RAG：把 RAG 拆成可插拔的模块
Modular RAG 是一种架构思想：把 RAG 系统拆成多个独立模块，每个模块负责一个特定功能，模块之间通过标准接口通信。典型的模块划分包括：
- 索引模块：负责文档解析、切块、向量化、存储。
- 检索模块：负责查询处理、多路召回、融合排序。
- 后处理模块：负责 rerank、压缩、格式化。
- 生成模块：负责 prompt 组装、LLM 调用、结果解析。
- 评估模块：负责检索质量评估、生成质量评估。
这种架构的好处是灵活性和可维护性。你可以根据场景需要替换任意模块，而不影响其他部分。比如今天用 OpenAI 的 embedding，明天想换成 BGE，只需要改索引模块的配置。或者今天用向量检索，明天想加一路图检索，只需要在检索模块里加一个子模块。
# Modular RAG 的模块接口示例 class RetrievalModule: def retrieve(self, query: str, top_k: int) -> list[Document]: raise NotImplementedError class VectorRetrieval(RetrievalModule): def retrieve(self, query, top_k): # 向量检索实现 pass class GraphRetrieval(RetrievalModule): def retrieve(self, query, top_k): # 图检索实现 pass class HybridRetrieval(RetrievalModule): def __init__(self, modules: list[RetrievalModule]): self.modules = modules def retrieve(self, query, top_k): all_results = [] for module in self.modules: all_results.append(module.retrieve(query, top_k)) return rrf_fusion(all_results)[:top_k]Modular RAG 的代价是系统复杂度上升。模块多了，调试和排查问题的难度也大了。我的经验是：小项目别过度设计，先用 Naive RAG 跑通，遇到瓶颈再逐步模块化。大项目从一开始就按模块化设计，后期维护会轻松很多。
3. 八种方案怎么选：一张决策表和一个真实案例
3.1 选型决策表
说了这么多方案，实际做项目的时候到底怎么选？我整理了一张决策表，按场景特征来推荐。
| 场景特征 | 推荐方案 | 理由 |
|---|---|---|
| 知识库小、问题简单、预算有限 | Naive RAG | 够用，别过度设计 |
| 检索精度不够、用户 query 模糊 | Advanced RAG | rerank + 查询改写性价比最高 |
| 需要回答全局性、总结性问题 | GraphRAG / LightRAG | 图结构擅长跨文档综合 |
| 知识库频繁更新 | LightRAG | 支持增量更新 |
| 任务复杂、需要多步推理 | Agentic RAG | Agent 自主规划检索策略 |
| 垂直领域、精度要求极高 | Ontology RAG | 本体约束保证检索逻辑正确 |
| 多源异构数据、需要高召回 | Hybrid RAG | 多路召回 + 融合排序 |
| 大型项目、长期维护 | Modular RAG | 模块化架构便于迭代 |
3.2 一个真实项目的选型过程
去年我参与了一个企业知识管理 Agent 的项目。需求是：员工可以用自然语言查询公司内部的制度文档、技术文档、项目文档，Agent 要能回答具体问题，也能做跨文档总结。
一开始我们用的是 Naive RAG，效果很差。具体问题表现在：员工问“年假怎么算”，检索到的 chunk 是年假制度的某一段，但那段只讲了天数，没讲计算方式，计算方式在另一个文档里。模型只根据检索到的片段回答，结果不完整。
后来我们升级到 Advanced RAG，加了 rerank 和查询改写，具体问题的回答质量明显提升。但跨文档总结类问题还是不行，比如“今年公司发布了哪些技术规范”，传统 RAG 根本没法回答。
最终我们采用了混合架构：底层用 LightRAG 做图索引，支持全局性问题；同时保留向量检索通道，处理具体细节问题；上层用 Agentic RAG 做调度，Agent 根据问题类型选择走图检索还是向量检索。这个架构跑下来，具体问题的准确率从 62% 提升到 89%，总结类问题的可用率从几乎为零提升到 75% 左右。
这个案例给我的最大启发是：没有一种 RAG 方案能通吃所有场景。实际项目里往往是多种方案组合使用，关键是搞清楚每种方案的边界，然后在边界处做好路由。
4. 实操中的常见问题与排查技巧
4.1 检索到了但模型不用，怎么办
这是最高频的问题。检索结果明明包含答案，但模型就是不用，按自己的知识回答。排查思路：
- 检查 prompt 模板。有没有明确要求“只根据上下文回答”？如果没有，模型倾向于用自己的知识。
- 检查上下文位置。检索结果放在 prompt 的开头还是结尾？研究表明，模型对 prompt 开头和结尾的信息更敏感，中间部分容易被忽略。把最相关的检索结果放在开头或结尾。
- 检查上下文长度。检索结果太多太长，模型可能“看不过来”。做压缩，只保留最相关的部分。
- 检查模型能力。小模型对上下文的利用能力弱，换大模型试试。
4.2 检索结果重复度太高
Top-K 检索经常返回内容高度相似的 chunk，浪费上下文窗口。解决办法：
- 用 MMR（Maximal Marginal Relevance）做多样性采样，在相关性和多样性之间做平衡。
- 检索后做去重，按内容相似度过滤。
- 调整 chunk 切分策略，减少重叠。
# MMR 检索示例 from langchain.vectorstores import Chroma results = vectorstore.max_marginal_relevance_search( query, k=5, # 返回数量 fetch_k=20, # 候选数量 lambda_mult=0.5 # 0=最大多样性，1=最大相关性 )4.3 知识库更新后检索结果没变化
这是索引更新问题。常见原因：
- 向量数据库没有重新索引。新增文档后需要重新 embedding 并插入。
- 缓存没有失效。如果用了查询缓存，需要清缓存。
- 图索引没有增量更新。GraphRAG 需要重建，LightRAG 支持增量但需要正确调用插入接口。
实操建议：在知识库更新流程里加一个“索引状态检查”步骤，确保新文档已经完成 embedding 和索引。我见过太多因为索引没更新导致检索不到新内容的案例。
4.4 Agentic RAG 陷入检索循环
Agent 反复检索但找不到满意结果，一直循环。解决办法：
- 设置最大检索次数（通常 3 到 5 次）。
- 在 prompt 里明确告诉 Agent“如果检索 3 次仍找不到相关信息，就基于已有信息回答或说明无法回答”。
- 加一个“检索结果质量评估”步骤，如果连续两次检索结果相似度高，就停止检索。
4.5 中文检索效果差
中文场景下，embedding 模型的选择很关键。我实测过的组合：
| Embedding 模型 | 中文检索效果 | 备注 |
|---|---|---|
| text-embedding-ada-002 | 一般 | 英文为主，中文一般 |
| BAAI/bge-large-zh-v1.5 | 好 | 中文优化，推荐 |
| BAAI/bge-m3 | 很好 | 多语言，支持稠密+稀疏 |
| M3E-base | 较好 | 轻量，适合资源有限场景 |
另外，中文切块要注意标点符号。英文按句号切，中文要按“。！？”切，而且中文的段落边界往往比英文更明确，优先按段落切效果更好。
5. 几个容易被忽略的工程细节
5.1 向量数据库的选择
小项目用 Chroma 或 FAISS 就够了，本地跑、零配置。中等规模用 Milvus 或 Qdrant，支持分布式和过滤。大规模用 Pinecone 或 Weaviate 的托管服务。我的建议是：别一上来就上重型数据库，先用 Chroma 跑通流程，遇到性能瓶颈再换。
5.2 检索结果的格式化
检索回来的原始文本块直接拼到 prompt 里，模型理解起来其实有困难。更好的做法是给每个检索结果加上元数据：来源文档、章节标题、更新时间。这样模型能更好地判断信息的可信度和时效性。
context_template = """ [来源：{source} | 章节：{section} | 更新时间：{date}] {content} """5.3 评估体系的建立
没有评估，优化就是盲人摸象。至少需要两个指标：检索命中率（正确答案在检索结果中的比例）和生成准确率（模型回答正确的比例）。构建一个包含 50 到 100 个问答对的测试集，每次改动后跑一遍，用数据说话。
我在实际项目里踩过最大的坑就是：凭感觉优化，改了一个参数觉得“好像好了一点”，但没有量化评估，结果改来改去反而把之前好的 case 改坏了。后来老老实实建了测试集，每次改动都跑评估，才把效果稳定下来。
5.4 成本控制
RAG 系统的成本主要来自三块：embedding 调用、LLM 调用（查询改写、实体抽取、生成）、向量数据库。其中 LLM 调用是大头。控制成本的手段包括：缓存常用查询的检索结果、用小模型做查询改写、实体抽取只在索引阶段做一次而不是每次查询都做。
最后再分享一个小技巧：如果你的知识库里有大量结构化内容（表格、列表、代码），在切块时保留结构信息，检索时按结构过滤，效果会比纯文本检索好很多。比如代码块单独索引，查询时如果检测到问题是代码相关，就只在代码块里检索。这个改动不大，但实测对技术文档场景的提升很明显。
