2019 年，Meta 提出了 RAG（检索增强生成）这个词，那时候它很简单——先把问题变成向量，在知识库里捞相似文本，再塞给大模型生成答案。
七年后的今天，「RAG」已经不是一个技术名词，而是一个家族。五代技术堆在一起，每一代解决的都是上一代的盲区。你现在用的，可能已经是最低的那一层。
本期提纲：
· Naive RAG — 最原始的那一代
· Advanced RAG — 管道里加了哪些补丁
· Modular RAG — 模块自由组合
· Graph RAG — 用知识图谱重构检索逻辑
· Agentic RAG — 让 Agent 自己决定查什么
Naive RAG：简单，但天生残缺
这是最早期的架构，也是大多数团队跑通第一个 demo 的起点。流程很直接：向量化 → 相似度检索 → 拼接 prompt → 生成。
问题也出在这里。检索和生成是分开的两步，检索质量完全依赖向量相似度，而相似度不等于相关性——你搜"怎么提升编程水平"，最匹配的可能是一篇四年前的技术博客，而不是你真正需要的内部代码规范文档。
还有一个隐藏的问题：上下文窗口污染。你把检索到的所有文本都塞进 prompt，但模型的有效注意力是有限的，超出的部分直接被稀释。
图2：Naive RAG 流程——Query → 检索 → 生成，三步走
说真的，Naive RAG 适合的场景很明确：数据规模小、问题类型单一、延迟要求极高。它的实现成本也是最低的，如果你的场景还在这个范围内，先不要急着升级。
Advanced RAG：给管道打补丁
Advanced RAG 不是一种新技术，而是一套工程改进。它的核心思路是：在检索之前和之后，分别加一个预处理层和一个后处理层。
检索前的优化包括查询改写——把用户口语化的提问转换成更适合检索的表述，以及意图分类——判断这个问题到底需要查什么知识库。检索后的优化主要是重排（Re-ranking）：用更重的模型对初检结果做二次打分，把真正相关的文本顶到前面。
这类改进的效果立竿见影，但也有代价：每一次优化都会往管道里加一个调用延迟，越往深处调延迟越高。在实时性要求高的场景（比如客服），需要在效果和速度之间找平衡。
Modular & Graph RAG：从检索到理解
Modular RAG 把检索、生成、路由、记忆全部拆成独立模块，企业可以按需组合。这套思路在工程层面很优雅，但在语义层面有一个根本局限：纯向量检索本质上是「字面匹配」，它不知道「美国对华芯片出口限制」和「2022年10月BIS实体清单升级」说的是同一件事。
Graph RAG 尝试解决这个问题。它不是用向量表征孤立的文本块，而是构建实体和关系图谱——谁做了什么、与谁有关联、事件的先后顺序。当用户问到「芯片禁令的影响」，Graph RAG 检索的是一段因果链条，而不是关键词相似的碎片。
坦率地讲，Graph RAG 的部署成本不低。你需要额外的图数据库（比如 Neo4j），需要在入库前做命名实体识别和关系抽取，需要维护知识图谱的更新pipeline。如果你的数据更新频率极高，这个维护成本会变成瓶颈。
图3：Graph RAG 检索的不是文本块，而是实体关系链
Agentic RAG：让系统自己查资料
这是目前最复杂的一代，也是最接近「自主智能体」概念的一代。
在 Agentic RAG 里，大模型不再只是消费者——它同时扮演路由器、规划器和审核者的角色。面对一个复杂问题，它会自己判断：需要查哪些知识库？需要几次检索？第一次结果够不够？不够的话怎么调整查询策略？
典型的工作流程是：问题进来 → 模型规划需要什么信息 → 执行检索 → 评估结果是否足够 → 如果不够，改写查询再次检索 → 合成最终答案。这个循环可以迭代多轮，直到模型认为答案质量达标。
代价也是明显的：延迟会比 Naive RAG 高出 3 到 5 倍，成本大约是 2 到 4 倍。另外，迭代的终止条件是个工程难题——如何让模型知道「够了」，而不是永远觉得自己还能再查一轮？
图4：Agentic RAG 自主规划循环，可迭代多轮
小结
选 RAG 不是选最先进的那一个，而是选最匹配当前数据规模、问题复杂度和延迟要求的那一个。
数据小、问题简单、要求快 → Naive RAG。
数据规模上来了、答案质量开始波动 → Advanced RAG 加检索优化和重排。
需要跨实体理解、问题涉及多步关联 → 考虑 Graph RAG 的图谱建造成本。
问题复杂、延迟不敏感、愿意花工程成本 → Agentic RAG。
没有银弹，只有权衡。理解这五代的演进逻辑，比追最新技术更有价值。
粤ICP备14082021号
免费POC，
零成本试错
