Agent时代RAG的8种形态：从Naive到Agentic的工程实践

1. 从"检索"到"行动"：RAG 在 Agent 时代到底变了什么

如果你这两年一直在做 AI 应用，大概率会有一种割裂感：一边是 RAG（Retrieval-Augmented Generation，检索增强生成）已经被讲烂了，好像谁都会搭一个"文档问答"；另一边是 Agent 突然成了主角，所有人都在聊工具调用、任务规划、多轮自主执行。于是问题来了——当模型开始自己决定"要不要查、查什么、查几次"的时候，传统那套"先检索再拼 prompt"的 RAG 还够用吗？

答案是不够，但也不是推倒重来。RAG 的底层逻辑——用外部知识补足模型参数里没有的东西——在 Agent 时代反而更重要了，因为 Agent 要做的决策越多，它对"准确、及时、结构化"的外部信息的依赖就越强。变的不是"要不要检索"，而是谁来发起检索、检索什么粒度、检索结果怎么进入推理循环。

这篇我想把 Agent 时代真正在工程里跑得起来的 8 种 RAG 形态一次讲清楚。不是罗列概念，而是按"它解决什么问题、核心机制是什么、什么场景该用它、落地时坑在哪"这个顺序来拆。关键词里出现的 GraphRAG、LightRAG、Agentic RAG、Ontology RAG 都会覆盖到，同时我会把 Naive RAG、Hybrid RAG、Self-RAG、Corrective RAG、Multimodal RAG 这些也串进来，因为它们不是互相替代的关系，而是同一套系统里不同层级的组件。

适合谁看？如果你已经搭过最基础的向量检索问答，想往 Agent 方向升级；或者你在做 Agent 项目，发现模型老是"幻觉式检索"、查了等于没查、多跳问题一塌糊涂，那这篇就是给你写的。我会尽量把每个环节的"为什么这么设计"讲透，而不是甩一堆名词让你自己拼。

先说一个我踩过的坑作为引子：早期我给一个 Agent 接了最朴素的向量 RAG，结果它遇到"对比 A 产品和 B 产品在 2023 年之后的政策差异"这种问题时，检索回来的永远是零散段落，模型要么漏掉一边，要么把两边信息张冠李戴。后来我才意识到，问题不在检索器，而在我把 RAG 当成了一个"一次性函数"，而 Agent 需要的是一个"可反复调用的工具"。这个认知转变，是理解后面 8 种形态的钥匙。

2. Naive RAG 与 Hybrid RAG：地基没打牢，上面全是空中楼阁

很多人一上来就想搞 GraphRAG、Agentic RAG，结果连最基础的检索质量都没解决。我见过太多项目，向量库塞了几十万条 chunk，召回率却惨不忍睹，然后归咎于"模型不行"。其实问题往往出在地基上。所以这一章先把两种"看起来最土但最不能省"的形态讲透。

2.1 Naive RAG 的真实瓶颈：不是检索，是切分和召回

Naive RAG 的流程大家都熟：文档切分成 chunk → 向量化 → 存向量库 → 查询时向量化问题 → 相似度召回 Top-K → 拼进 prompt。听起来没毛病，但实际跑起来，80% 的失败案例都死在 chunk 切分和召回策略上。

我做过一个对比实验，同一份 200 页的技术手册，用三种切分方式：

固定长度切分最省事，但也是最坑的。一个完整的操作步骤被切成两半，模型拿到前半段根本不知道后半段在讲什么。我的经验是：优先按语义边界切（标题、段落、列表项），再对超长块做二次切分，并且一定要加 10%-15% 的重叠。重叠部分看似冗余，但它能保证跨块的语义连续性，这点在 Agent 反复检索时尤其重要。

另一个常被忽略的点是元数据。光有文本向量是不够的，你得把来源、章节、时间、文档类型这些一起存进去。为什么？因为 Agent 在做多轮检索时，需要根据元数据做过滤——比如"只查 2024 年之后的文档""只查 API 参考手册"。没有元数据，Agent 就只能靠语义相似度硬碰，效果差一大截。

提示：如果你的 RAG 召回率低于 70%，先别急着换框架，回去检查 chunk 切分和元数据设计，十有八九问题在这。

2.2 Hybrid RAG：向量检索不是万能的，关键词得补位

向量检索擅长语义匹配，但对精确术语、编号、专有名词很无力。比如用户问"错误码 E5021 怎么解决"，向量检索可能召回一堆"错误处理"的泛泛内容，却漏掉真正包含 E5021 的那一段。这时候就需要 Hybrid RAG——向量检索 + 关键词检索（BM25）双路召回，再融合排序。

融合排序常用两种方法：RRF（Reciprocal Rank Fusion，倒数排名融合）和加权分数融合。RRF 更省心，不需要归一化分数，公式是score = Σ 1/(k + rank)，k 一般取 60。我实测下来，RRF 在大多数场景下比加权融合更稳，因为它对两路检索的分数尺度不敏感。

# RRF 融合的简化实现 def rrf_fusion(vector_results, bm25_results, k=60): scores = {} for rank, doc in enumerate(vector_results): scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1) for rank, doc in enumerate(bm25_results): scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1) return sorted(scores.items(), key=lambda x: x[1], reverse=True)

Hybrid RAG 的代价是延迟翻倍（两路检索并行还好，串行就难受了）和调参成本。我的建议是：如果业务里精确查询占比高（比如客服、技术支持），Hybrid 是必选项；如果是纯开放域问答，Naive RAG 调好切分也能凑合。

这里有个 Agent 场景的特殊考量：Agent 可以自己决定用哪路检索。比如它判断问题是"精确匹配"就走 BM25，是"语义理解"就走向量。这就自然过渡到了后面的 Agentic RAG。

3. GraphRAG 与 LightRAG：当问题需要"跨文档推理"时

传统 RAG 有个致命短板：它只能回答"某个片段里写了什么"，回答不了"这些片段之间是什么关系"。当用户问"公司 A 收购了 B，B 的创始人之前在哪家公司，那家公司现在和 A 有竞争吗"这种多跳问题时，向量检索召回的永远是零散段落，模型只能靠猜。GraphRAG 就是为解决这类问题生的。

3.1 GraphRAG 的核心：把文档变成知识图谱

GraphRAG 的思路是：先用 LLM 从文档里抽取实体和关系，构建知识图谱，然后查询时既走图遍历，也走社区摘要。微软那套 GraphRAG 的流程大致是：

1. 实体与关系抽取：LLM 逐块读文档，抽出"实体-关系-实体"三元组。
2. 社区检测：用 Leiden 算法把图划分成层次化社区。
3. 社区摘要生成：对每个社区用 LLM 生成摘要。
4. 查询时：局部问题走实体邻域，全局问题走社区摘要。

这套东西效果确实好，尤其在"全局性总结"类问题上（比如"这份报告的主要矛盾是什么"），GraphRAG 比向量 RAG 强太多。但它的代价也很明显：构建成本极高。一份 100 万字的文档，光实体抽取的 LLM 调用费用就可能上千块，而且抽取质量高度依赖 prompt 设计。

我踩过的坑：早期用 GraphRAG 时，实体抽取没有做归一化，结果"苹果公司""Apple""苹果"被当成三个实体，图谱直接乱掉。后来加了实体消歧（用 embedding 相似度 + 规则合并），才勉强能用。所以如果你要上 GraphRAG，实体归一化这一步绝对不能省。

3.2 LightRAG：GraphRAG 的"轻量化"妥协

GraphRAG 太重，于是有了 LightRAG。它的核心改进是双层检索：低层检索实体和关系，高层检索主题和概念，同时把图结构和向量索引结合，避免了 GraphRAG 那种全量社区摘要的开销。

LightRAG 的构建流程比 GraphRAG 简单：抽取实体关系 → 建图 → 同时为节点和边生成 embedding → 查询时图遍历 + 向量召回混合。它的优势是增量更新友好——新文档来了，抽完实体直接往图里加，不用重建整个社区结构。这点对 Agent 场景很关键，因为 Agent 面对的知识库往往是动态增长的。

我实测下来，LightRAG 在中等规模（几万到几十万 chunk）的知识库上，效果接近 GraphRAG 的 80%，但构建成本只有它的 30% 左右。如果你的场景是"多跳问答 + 动态知识库"，LightRAG 是性价比更高的选择。

注意：GraphRAG 和 LightRAG 都不是"开箱即用"的，实体抽取的 prompt 需要针对你的领域反复调。通用 prompt 在专业领域（医疗、法律、金融）上抽取质量会断崖式下跌。

4. Self-RAG 与 Corrective RAG：让检索学会"自我怀疑"

前面讲的都是"怎么检得更准"，但 Agent 时代有个更根本的问题：模型怎么知道自己检得对不对？传统 RAG 是无脑检索、无脑拼接，检索错了也照单全收，结果就是幻觉。Self-RAG 和 Corrective RAG 就是来解决"检索质量自省"的。

4.1 Self-RAG：用反思 token 控制检索行为

Self-RAG 的核心思想是训练模型生成特殊的"反思 token"，比如：

• [Retrieve]：要不要检索？
• [IsRel]：检索到的内容相关吗？
• [IsSup]：生成的内容有检索内容支持吗？
• [IsUse]：生成的内容有用吗？

模型在生成时自己决定要不要检索、检索后自己判断相关性、生成后自己验证支持度。这套机制的好处是按需检索——简单问题不检索，复杂问题多检索，避免了无脑检索带来的噪声和延迟。

但 Self-RAG 有个现实问题：它需要专门训练的模型。原论文是拿 Llama2 微调的，普通开发者很难复现。所以工程上更常见的是"用 prompt 模拟 Self-RAG 行为"——让 Agent 在检索前后插入自检步骤。这就引出了 Agentic RAG。

4.2 Corrective RAG：检索不好就重检

Corrective RAG（CRAG）更务实。它的流程是：检索 → 用轻量评估器判断检索质量 → 分三种情况处理：

• Correct：检索质量高，直接用。
• Incorrect：检索质量低，丢弃，改用网络搜索或重新检索。
• Ambiguous：模棱两可，两者结合。

评估器可以是一个小模型（比如 T5-large 微调），也可以直接用 LLM 打分。我实测下来，用 LLM 打分的成本比想象中低，因为只需要判断"相关/不相关"，prompt 很短，token 消耗可控。

CRAG 的价值在于它给了 Agent 一个"纠错回路"。传统 RAG 是一条直线，CRAG 是一个带反馈的环。这个环在 Agent 场景里特别重要，因为 Agent 本来就有多轮循环的能力，把 CRAG 嵌进去几乎零成本。

# CRAG 的简化决策逻辑 def corrective_retrieve(query, retriever, evaluator, llm): docs = retriever.search(query, top_k=5) quality = evaluator.score(query, docs) # 0-1 if quality > 0.7: return docs elif quality < 0.3: # 检索失败，尝试改写查询重检 new_query = llm.rewrite(query) return retriever.search(new_query, top_k=5) else: # 模糊，结合两路 return docs + retriever.search(llm.rewrite(query), top_k=3)

这里有个实操心得：查询改写（query rewriting）是 CRAG 里最值钱的一步。很多检索失败不是知识库没有，而是用户问法和文档写法对不上。让 LLM 把口语化问题改写成"文档风格"的查询，召回率能提升 20% 以上。

5. Agentic RAG：把检索变成 Agent 的一个工具

前面铺垫了这么多，终于到核心了。Agentic RAG 不是一个具体的算法，而是一种架构范式：把检索能力封装成 Agent 可调用的工具，由 Agent 根据任务需要自主决定何时检索、检索什么、检索几次、如何整合。

5.1 为什么 Agent 需要"自主检索"而不是"固定检索"

传统 RAG 是"一问一检一答"，Agentic RAG 是"边想边检边答"。区别在哪？举个例子，用户问"帮我分析这份财报的风险点"。传统 RAG 会检索一次，把 Top-K 段落拼进去，模型一次性生成。但这个问题其实需要：先检索财务数据 → 发现应收账款异常 → 再检索应收账款相关政策 → 发现某大客户占比过高 → 再检索该客户信息 → 综合判断。

这是一个多跳、动态的检索过程，固定的一次性检索根本做不到。Agentic RAG 让 Agent 自己规划检索路径，每一步的检索结果影响下一步的决策。这才是 Agent 时代 RAG 的真正形态。

5.2 Agentic RAG 的三种典型模式

我在项目里总结出三种模式，按复杂度递增：

模式一：工具调用式。把检索器注册成一个 tool，Agent 用 function calling 调用。最简单，适合大多数场景。关键是 tool 的描述要写清楚——"什么时候该用这个工具"比"这个工具能干什么"更重要。

模式二：规划-执行式。Agent 先拆解任务，生成检索计划（要查哪几个子问题），再逐个执行，最后综合。适合复杂分析类任务。这里可以用 ReAct 或 Plan-and-Execute 框架。

模式三：多 Agent 协作式。一个 Agent 负责规划，一个负责检索，一个负责验证，互相协作。适合超复杂场景，但工程复杂度也最高，容易失控。

我的建议是：从模式一开始，别一上来就搞多 Agent。我见过太多项目，三个 Agent 互相调用，最后调试到崩溃。单 Agent + 好的工具设计，能解决 80% 的问题。

5.3 Agentic RAG 的检索工具该怎么设计

这是最容易被低估的部分。很多人把检索工具设计成search(query) -> docs，太粗糙了。好的检索工具应该有这些参数：

• query：查询文本
• top_k：返回数量
• filters：元数据过滤（时间、来源、类型）
• mode：检索模式（向量/关键词/混合/图）
• rerank：是否重排

为什么？因为 Agent 需要精细控制。它可能知道"我只要 2024 年的数据"，或者"这次要精确匹配错误码"。工具参数越丰富，Agent 的决策空间越大，效果越好。

提示：检索工具的 docstring 要写得像给新人看的说明书，包含"什么时候用""什么时候不用""参数怎么填"。Agent 读 docstring 的能力比你想象中强。

6. Multimodal RAG 与 Ontology RAG：两个容易被忽视的进阶方向

前面六种偏"通用"，这一章讲两种特定场景下才需要、但一旦需要就绕不开的形态。

6.1 Multimodal RAG：当知识库里有图片和表格

热词里有人问"rag 知识库能存储图片嘛"，答案是能，但方式有讲究。Multimodal RAG 处理的是图文混排、表格、图表这类内容。常见做法有三种：

1. 图片转文本：用多模态模型（如 GPT-4V 类能力）把图片描述成文字，再走文本 RAG。简单，但丢失视觉细节。
2. 多向量索引：图片用 CLIP 类模型编码，文本用文本模型编码，查询时跨模态检索。适合"以图搜图"或"文搜图"。
3. 统一多模态 embedding：用统一模型把图文编码到同一空间。最优雅，但模型选择少。

我踩过的坑：表格千万别直接转文本。一个财务表格转成文字后，行列关系全乱，模型根本读不懂。正确做法是表格结构化提取（转成 Markdown 表格或 JSON），保留行列语义。图表则建议"图片 + 文字描述"双存，检索时用文字，展示时用图片。

6.2 Ontology RAG：用本体约束检索的语义边界

Ontology RAG（本体 RAG）是 GraphRAG 的进阶版。区别在于：GraphRAG 的图谱是"从文档里抽出来的"，而 Ontology RAG 的图谱是"预先定义好的本体结构"，文档只是往这个结构里填实例。

举个例子，医疗场景下，你可以先定义本体：疾病、症状、药物、检查项，以及它们之间的关系（"治疗""导致""检查"）。然后文档抽取时，只抽这些预定义类型的实体和关系。好处是图谱质量高、可控，坏处是本体设计成本高，且难以覆盖长尾。

Ontology RAG 适合领域边界清晰、术语体系稳定的场景，比如医疗、法律、工业设备。开放域场景下，本体根本定义不完，还是 GraphRAG 更实际。

7. 八种 RAG 怎么选：一张决策表和三条实战原则

讲了这么多，最后落到"我到底该用哪个"。先给一张决策表，再讲三条我踩坑总结的原则。

原则一：别追求"最先进"，追求"最匹配"。我见过一个内部文档问答项目，硬上 GraphRAG，结果构建花了两周，效果还不如调好切分的 Hybrid RAG。GraphRAG 的价值在多跳和全局总结，如果你的问题都是"某文档里某段说了什么"，它纯属浪费。

原则二：RAG 形态可以叠加，不是单选。真实系统里，往往是 Hybrid RAG 做召回，Corrective RAG 做纠错，Agentic RAG 做调度，GraphRAG 做特定子问题的补充。把它们看成积木，按需组合。

原则三：先解决数据质量，再谈架构。我见过太多项目，文档本身格式混乱、重复、过时，然后指望 RAG 架构来救。垃圾进，垃圾出，这话在 RAG 上尤其成立。花在数据清洗上的时间，回报率远高于换框架。

8. 我在 Agent 项目里踩过的 RAG 坑与调优心得

最后分享几个具体的、文档里不会写的坑，都是真金白银换来的。

坑一：Agent 会"过度检索"。给它一个检索工具，它会疯狂调用，一个问题查七八次，token 烧得飞快。解决办法是在工具描述里明确"同一信息不要重复检索"，或者加一个检索次数上限。我一般设 3-5 次，超过就强制它基于已有信息回答。

坑二：检索结果的排序比数量重要。早期我 Top-K 设 10，结果噪声太多，模型被带偏。后来改成 Top-5 + 重排（rerank），效果好很多。重排模型用轻量的 cross-encoder 就行，延迟增加不多，但精度提升明显。

坑三：多轮对话里的查询改写不能省。用户第二轮问"那它呢"，Agent 直接拿"那它呢"去检索，必然失败。必须结合对话历史改写查询。这一步在 Agentic RAG 里尤其关键，因为 Agent 的多轮检索依赖上下文连贯。

坑四：别忘了给检索结果加"来源标注"。Agent 生成答案时，如果能引用来源（"根据 XX 文档第 3 节"），可信度会高很多，也方便用户核查。这在企业场景里几乎是刚需。

坑五：评估体系要早建。别等到上线才发现效果不行。建一个 50-100 条的小评测集，覆盖典型问题，每次改动都跑一遍。召回率、准确率、延迟三个指标盯着，比拍脑袋调参靠谱得多。

关于并发，热词里有人问"ai agent 怎么扛并发"。RAG 侧的瓶颈通常在向量库和 LLM 调用。向量库选支持并发查询的（大多数都支持），LLM 调用要做限流和缓存。缓存是性价比最高的优化——相同查询直接返回缓存结果，能省掉一大半 LLM 调用。我一般用查询的 embedding 做缓存 key，相似度超过阈值就命中。

这套东西我陆陆续续调了大半年，从最朴素的 Naive RAG 一路演进到现在的 Agentic + Hybrid + Corrective 组合。回头看，最大的体会是：RAG 不是一个组件，而是一套需要持续调优的系统。没有银弹，只有针对你具体场景的反复打磨。Agent 时代给了 RAG 更大的舞台，但也对工程能力提出了更高要求。把基础打牢，再往上叠高级形态，这条路走得慢，但走得稳。