一、RAG类别
RAG确实已经从简单的“检索+生成”演化成了一个庞大的技术谱系。为了方便你建立清晰的认知框架，可以从架构演进层级和技术实现范式两个维度来分类。
目前市面上所有的RAG方案，本质上都处于以下三代架构中某一代或混合态 ：
1. 第一类：Naive RAG（朴素/基础RAG）
这是最经典的“检索-增强”范式，也是目前80%以上生产环境的落地方案。
核心逻辑：用户问题 → 向量检索Top-K → 拼接Prompt → LLM生成。
典型方案：LangChain、LlamaIndex的Baseline版本，各云厂商（阿里云PAI、AWS Bedrock）的一键式RAG。
痛点：严重依赖切片质量和embedding效果，容易“检索不精确”或“信息淹没”。
2. 第二类：Advanced RAG（高级/优化型RAG）
为了解决Naive RAG的痛点，这一代在检索前后加入了大量优化模块。
核心逻辑：Naive RAG + 预处理优化 + 后处理优化。
典型技术方案：
预检索：HyDE（假设文档嵌入）、查询重写、查询路由（多路检索）、知识图谱增强。
检索优化：混合检索（稀疏+稠密，例如Elasticsearch+向量）、重排序（Rerank）。
后检索：上下文压缩（LLMLingua）、提示词压缩、元数据过滤。
代表产品：Dify、FastGPT、Cohere的Rerank-models。
3. 第三类：Modular RAG（模块化/自适应RAG）
这是目前学术界和大厂前沿团队探索的方向，RAG不再是一条固定流水线，而是动态可编排的智能体系统。
核心逻辑：根据问题动态决策，调用不同工具模块（检索、代码解释器、API），甚至自我反思。
典型技术方案：
Self-RAG：LLM边生成边判断检索内容是否相关，决定是否修正输出。
Agentic RAG：将检索权交给Agent，让它自行规划检索步骤（例如先搜论文，再搜代码库）。
GraphRAG：微软开源方案/KnowledgeGraph+RAG，先建知识图谱再检索，适合全局性问题（不再是找相似片段，而是总结社区主题）。
代表产品：LlamaIndex的Agentic RAG、LangGraph、微软GraphRAG。
二、类别混乱原因
市面各类RAG方案的“眼花缭乱”根源：
1、是因为RAG 已经从一个技术变成了一类技术。就像“数据库”这个词一样：
你问数据库分几类？答：关系型、键值型、图数据库、时序数据库……
RAG 现在也是这个状态。 它是一个架构风格，不是一个具体实现。
2、是上述三类架构与基础组件进行了交叉组合：即两个维度的交叉组合，如下所示
索引维度：纯向量（Milvus/Pinecone） vs. 关系型向量（PostgreSQL pgvector） vs. 图结构（Neo4j/GraphRAG）。
检索维度：单路 vs. 多路 vs. 混合。
优化维度：重排序 vs. 提示词压缩 vs. 微调。
三、如何抓住重点？
你的应对策略：
不用试图把所有 xxxRAG 都学一遍。
看它改的是哪一环：
改索引（如 GraphRAG）→ 适合特定场景，成本高。
改检索（如 HyDE、混合检索）→ 通用优化，必学。
改生成（如 Self-RAG）→ 前沿探索，需定制的可以跟进。
改流程（如 Corrective RAG、LinerRAG）→ 工程技巧，按需取用。
现阶段建议：
必学： 混合检索 + 重排序。
了解： GraphRAG（知其边界，别跟风乱用）。
忽略： 各种带专有名词的 RAG 变体（等你真遇到场景时再查，现学来得及）。
一句话总结：GraphRAG 是换引擎，LinerRAG 是加机油。 车跑不动通常先换机油，引擎别随便动。
四、快速入局建议：如何不被带节奏？
如果你是企业落地：
关注 Advanced RAG。目前Naive RAG不够用，Modular RAG（Agentic/Graph）过于复杂且存在不可控幻觉。建议技术栈锁定为：向量库（如pgvector）+ 混合检索 + 重排序。这三点足以解决95%的场景，工具如Dify、FastGPT已经将这些模块封装得非常成熟。如果你是前沿研究/大厂选型：
关注 GraphRAG + Self-RAG。这是当前RAG从“片段匹配”进化到“理解并生成”的关键路径，主要用于解决复杂主题归纳、多跳推理问题。
特别说明一点：目前像GraphRAG(不是微软的那套框架而是知识图谱+朴素RAG/高级RAG)以及Li ne r RAG只是其中一类方向
总结：
你不需要学所有方案。
掌握Naive的原理（理解切片、嵌入、向量检索），
选用Advanced的工具链（使用Dify等平台），
了解Modular的演进方向（GraphRAG、Self-RAG），就能清晰看懂目前的格局。
