可以把 LLM + RAG 的演化理解为一条很清晰的路线：

LLM 内部参数知识 → 外挂知识 → 提升检索质量 → 检索可决策 → 多步检索与推理 → 图结构知识 → Agent 主导检索 → RAG / Long Context / Tool / Memory 融合

真正变化的并不只是“向量数据库越来越高级”，而是 LLM 与外部知识之间的控制权在发生变化：最早是程序固定检索，后来模型开始判断“要不要查、查什么、结果是否可信、是否需要继续查”，最终 RAG 逐渐成为 Agent 的一个底层能力。

一、为什么会出现 RAG

LLM 本身可以看成一种 Parametric Memory（参数化记忆）：

训练数据
   ↓
Model Training
   ↓
模型参数
   ↓
LLM

知识被编码到了模型参数中。

这带来几个天然问题：

               LLM
                │
     ┌──────────┼──────────┐
     ↓          ↓          ↓
  知识滞后     私域未知     难以追溯
     │          │          │
训练截止日期   企业数据    不知道答案来源

例如问：

公司 2026 年最新差旅制度中，住宿标准是多少？

即使模型推理能力很强，也不应该指望它“记住”企业内部刚更新的制度。

2020 年 Lewis 等人提出 RAG 时，核心思想就是把：

1 2	Parametric Memory 模型参数中的知识

与：

1 2	Non-parametric Memory 外部知识库

结合起来。原论文使用稠密向量索引作为外部记忆，让生成模型基于检索到的知识回答。(arXiv)

从工程视角，可以把它抽象成：

Answer = LLM(
    Question,
    Retrieve(Question, KnowledgeBase)
)

这就是后面所有 RAG 架构的起点。

二、阶段 0：纯 LLM —— Parametric Knowledge

RAG 出现以前，最简单的是：

User
 ↓
Prompt
 ↓
LLM
 ↓
Answer

如果知识不足，有两个主要办法：

1 2	Prompt Engineering Fine-tuning

Fine-tuning 的问题是：

它适合改变模型行为，不适合频繁更新事实知识。

例如：

1 2	让模型学会： "按照企业数据分析师的风格回答"

很适合 Fine-tuning。

但：

1
2
3

2026年8月最新销售政策是什么？
今天库存是多少？
最新产品价格是多少？

显然不应该靠重新训练模型解决。

因此早期形成了一个重要分工：

     LLM
      │
Reasoning / Language
      │
      ↓
模型负责推理
      
     RAG
      │
   Knowledge
      │
      ↓
外部系统负责事实

这是理解 RAG 的第一原则。

三、第一代：Naive RAG

大约 2022～2023 年企业最常见的 RAG，就是今天大家最熟悉的：

                 Offline
                   │
Document
   ↓
Parsing
   ↓
Chunking
   ↓
Embedding
   ↓
Vector DB


                 Online
                   │
User Question
      ↓
Embedding
      ↓
Vector Search
      ↓
Top K Chunks
      ↓
Prompt
      ↓
LLM
      ↓
Answer

例如企业知识库：

PDF
Word
Wiki
规章制度
产品文档
       ↓
    Chunk
       ↓
 Embedding
       ↓
  Vector DB
       ↑
       │
   用户问题

这其实就是典型的：

Retrieve → Read → Generate

需要注意一点：工程界后来所谓的“Naive RAG”，并不完全等同于 2020 RAG 原论文中的端到端训练架构，而更多指这种 Vector DB + TopK + Prompt 的工程实现。

优点

最大的优点是简单。

知识更新：

1
2
3

旧文档删除
新文档 Embedding
Vector DB 更新

不需要重新训练 LLM。

同时非常适合：

企业知识库；
产品手册；
FAQ；
制度查询；
技术文档；
客服知识库。

最大问题

问题逐渐从：

LLM 不知道答案。

变成：

Retriever 没找到正确答案。

例如：

Question
   ↓
Vector Search
   ↓
Top5
   ↓
只有 Top3 真正相关
   ↓
LLM

如果真正答案根本没进入 Context：

1
2
3

LLM 再聪明
     ≠
能够生成正确事实

因此 RAG 领域慢慢出现一句非常重要的工程判断：

RAG 的上限，很大程度取决于 Context Quality，而不仅仅取决于 LLM。

这促成了第二阶段。

四、第二代：Advanced RAG

Advanced RAG 的核心，不是换一个更强 LLM，而是优化：

1	Retrieval Pipeline

整体结构开始变成：

Question
   ↓
Query Processing
   ↓
Hybrid Retrieval
   ↓
Candidate Documents
   ↓
Reranking
   ↓
Context Filtering
   ↓
LLM

也就是：

 Pre-Retrieval
      │
      ↓
   Retrieval
      │
      ↓
Post-Retrieval

1. Pre-Retrieval

首先优化问题。

例如用户问：

去年华东地区耗材产品利润为什么下降？

直接 embedding 整句话效果可能并不好。

系统可以先：

Query Rewrite

去年
 ↓
2025

华东地区
 ↓
上海、江苏、浙江……

利润下降
 ↓
收入、成本、销量、单价、毛利

甚至把一个问题拆成：

Query 1：2025 华东销售收入
Query 2：2025 华东销售成本
Query 3：2024 华东毛利率
Query 4：2025 华东毛利率

这开始出现 Multi-query / Query Decomposition。

五、Embedding 单路检索 → Hybrid Search

纯 Vector Search 有一个明显问题：

它擅长：

1 2	semantic similarity 语义相似

但未必擅长：

精确产品编码
合同编号
客户名称
特殊缩写
表名
字段名

例如：

1	ZWFSYS_DF_JE

这种字段，用 embedding 检索可能不如关键词搜索。

于是企业 RAG 常见架构变为：

           Query
             │
    ┌────────┴────────┐
    ↓                 ↓
BM25 Search       Vector Search
Keyword             Semantic
    │                 │
    └────────┬────────┘
             ↓
           Fusion
             ↓
         Candidates

也就是：

Sparse Retrieval + Dense Retrieval

这也是现代企业 RAG 中非常常见的一层。

六、Retriever 后面增加 Reranker

原来：

1
2
3

Vector Search
    ↓
Top 5

后来：

Retriever
    ↓
Top 50
    ↓
Reranker
    ↓
Top 5

Retriever 的目标：

Recall

尽量别漏。

Reranker 的目标：

Precision

把真正相关的内容排到前面。

所以：

   Retriever
       │
high recall
       ↓
   50 docs
       │
   Reranker
       │
high precision
       ↓
    5 docs

这实际上是一个非常重要的架构演进。

七、第三代：Modular RAG

再往后，人们发现：

RAG 不应该是一个 Pipeline，而应该是很多可组合模块。

于是变成：

           Query
             │
      Query Router
      /      |      \
     /       |       \
Vector      SQL      Web
Search      Query    Search
   │          │        │
   └──────────┼────────┘
              ↓
          Reranker
              ↓
       Context Builder
              ↓
            LLM

RAG 从：

固定流水线

演变成：

1	Composable Architecture

典型模块包括：

Query Rewriter
Query Router
Retriever
Hybrid Search
Reranker
Graph Search
SQL Retriever
Web Search
Context Compressor
Citation Generator
Evaluator

这一步非常关键。

因为企业知识绝不只是：

1	PDF → Vector DB

而是：

                 Enterprise Knowledge

     ┌─────────────┼──────────────┐
     ↓             ↓              ↓
Documents      Data Warehouse    API
     ↓             ↓              ↓
Vector DB         SQL           Tools

        ↓
Knowledge Graph

        ↓
Search Engine

所以真正成熟的 RAG，本质上已经变成了：

Enterprise Knowledge Access Layer

而不只是 Vector DB。

八、第四代：Adaptive RAG

接下来出现了一个非常重要的问题：

是不是每个问题都需要 RAG？

比如：

Python list 和 tuple 有什么区别？

LLM 本身完全可以回答。

却仍然执行：

Embedding
Vector Search
Reranking
LLM

不仅增加：

延迟；
Token；
计算成本；

还可能因为检索到错误资料反而降低答案质量。

Adaptive-RAG 的思想是让系统先判断问题复杂度，然后选择：

          Query
            │
        Classifier
   ┌────────┼────────┐
   ↓        ↓        ↓
No RAG   Single RAG Multi-step RAG
   │        │        │
   └────────┴────────┘
            ↓
           LLM

相关研究展示了按照问题复杂度，在“不检索、单次检索、多步检索”之间动态选择策略的思路。(arXiv)

这意味着：

Retrieval 从一个默认动作，开始变成一个决策。

这是 RAG 架构真正走向智能化的标志。

九、第五代：Self-RAG / Corrective RAG

Adaptive RAG 解决：

要不要检索？

下一个问题是：

检索到的内容可信吗？

传统 RAG：

Retrieve
   ↓
Documents
   ↓
LLM

隐含假设：

Retriever 给我的东西是对的。

但现实不是如此。

于是出现 Self-RAG、CRAG 之类的方法。

Self-RAG 的核心思想是让模型能够按需检索，并对检索内容和生成结果进行自我评估，而不是机械地始终塞入固定数量文档。(arXiv)

可以理解为：

Question
   ↓
Need Retrieval?
   ↓
Retrieve
   ↓
Relevant?
   ↓
Generate
   ↓
Supported?
   ↓
Answer

而 Corrective RAG 更进一步：

Retrieve
   ↓
Evaluate Retrieval
   │
 ┌─┴────────────┐
 ↓              ↓
Good           Bad
 ↓              ↓
Use         Correct
               │
          Query Rewrite
               │
          New Retrieval
               │
             Web

CRAG 原始工作就是针对“Retriever 检索错了怎么办”这个问题，引入 Retrieval Evaluator，根据检索质量决定后续修正动作。(arXiv)

于是 RAG 出现一个非常重要的闭环：

Retrieve
   ↓
Evaluate
   ↓
Correct
   ↓
Retrieve

从：

Retrieval Pipeline

开始变成：

Retrieval Loop

十、第六代：GraphRAG

传统 Vector RAG 还有一个严重问题：

Chunk 把知识结构切碎了。

例如文档描述：

华东事业部
   │
   ├── 上海区域
   │      └── A经销商
   │             └── 产品P
   │
   └── 江苏区域
          └── B经销商

Chunk 后可能变成：

Chunk 001
上海区域销售情况……

Chunk 035
A经销商……

Chunk 107
产品P……

Chunk 246
华东事业部……

Vector Search 很容易找到：

局部相似内容

却不擅长回答：

华东事业部各区域经销商之间的结构是什么？

或者：

这些事件背后的主要参与者及相互关系是什么？

于是 GraphRAG 出现。

Microsoft 的 GraphRAG 工作将私有文本构造成知识图谱、社区和摘要，用来解决普通 chunk-based RAG 不擅长的“跨文档全局问题”。(微软)

大致结构：

Documents
    ↓
Entity Extraction
    ↓
Relationship Extraction
    ↓
Knowledge Graph
    ↓
Community Detection
    ↓
Community Summary

查询时：

           Question
              │
     ┌────────┴────────┐
     ↓                 ↓
Local Search       Global Search
     ↓                 ↓
Entity/Relation   Community Summary
     └────────┬────────┘
              ↓
             LLM

GraphRAG 优势

特别适合：

跨文档关系；
组织网络；
风险关系；
上下游关系；
因果链；
实体关系；
全局总结。

缺点

代价也明显：

文档
 ↓
实体抽取
 ↓
关系抽取
 ↓
图构建
 ↓
Community
 ↓
Summary

Indexing 成本远高于普通 Vector RAG。

所以：

GraphRAG 不是 Vector RAG 的替代品。

更合理的是：

1
2
3

Vector RAG
    +
Graph RAG

十一、第七代：Agentic RAG

这一步我认为是整个演化里最关键的一次变化。

传统 RAG 是：

1	程序控制 Retrieval

Agentic RAG 是：

1	LLM / Agent 控制 Retrieval

传统：

User
 ↓
Retriever
 ↓
LLM

Agentic：

              User
                ↓
              Agent
                │
          Understand
                │
              Plan
                │
   ┌────────────┼─────────────┐
   ↓            ↓             ↓
Search        SQL          API Tool
   ↓            ↓             ↓
   └────────────┼─────────────┘
                ↓
             Reason
                ↓
        Need more data?
           ↓          ↓
          Yes         No
           │           │
           └── loop ───┘
                       ↓
                    Answer

Agentic RAG 相关研究通常把它概括为把 planning、reflection、tool use、多 Agent 协作 引入 RAG，使检索策略从固定流程变成动态过程。(arXiv)

例如用户问：

为什么 7 月份华东区域毛利下降？

普通 RAG：

1	Search "华东毛利下降"

Agentic RAG：

Agent
 │
 ├─ 查询 6月、7月销售额
 │
 ├─ 查询销量
 │
 ├─ 查询售价
 │
 ├─ 查询单位材料成本
 │
 ├─ 查询客户结构变化
 │
 ├─ 查询产品结构变化
 │
 └─ 对比分析

发现：

材料成本 ↑ 3%

再继续：

Agent
 ↓
查询材料采购价格
 ↓
发现某原材料上涨 12%
 ↓
查询该材料对应产品
 ↓
计算影响

最后才回答。

这其实已经不太像传统意义上的：

Retrieval Augmented Generation

而更像：

Retrieval Augmented Reasoning

十二、2024～2026：Long Context 开始挑战传统 RAG

随着 Context Window 越来越长，又出现一个新的问题：

我为什么一定要 Chunk + Retrieve？

假设一份文档只有：

1	80K tokens

模型 Context 支持：

1	200K / 1M tokens

理论上可以：

Document
    ↓
Entire Context
    ↓
LLM

避免：

1
2
3

Chunking
Embedding
Retrieval

因此开始出现：

1
2
3

RAG
VS
Long Context

相关实验显示了一个很有意思的结果：在资源充足的一些 benchmark 中，直接使用 Long Context 可以优于传统 RAG，而 RAG 的明显优势仍然在成本；因此产生了根据问题自动选择 RAG 或 Long Context 的混合方案。(arXiv)

但这并不意味着：

Long Context 会消灭 RAG。

另一些实验也表明，Context 变长并不意味着性能会持续线性提高，过长上下文可能带来注意力稀释和性能下降。(arXiv)

所以现在更合理的方向是：

            Query
              ↓
           Router
 ┌────────────┼────────────┐
 ↓            ↓            ↓
LLM        Long Context    RAG
 │                         │
 │                    Hybrid Retrieval
 │                         │
 │                     Graph RAG
 └────────────┬────────────┘
              ↓
            Agent

十三、把整个演化压缩成一张图

可以把整个历史看成：

Stage 0
Pure LLM
│
│ 模型知识过时 / 私域未知
↓
Stage 1
Naive RAG
Vector DB + TopK
│
│ 检索质量不好
↓
Stage 2
Advanced RAG
Hybrid + Reranker + Query Rewrite
│
│ Pipeline 固定
↓
Stage 3
Modular RAG
Router + Multiple Retriever
│
│ 所有问题都检索成本太高
↓
Stage 4
Adaptive RAG
决定是否检索 / 如何检索
│
│ Retriever 可能出错
↓
Stage 5
Self-RAG / CRAG
Retrieve → Evaluate → Correct
│
│ Chunk 缺乏关系和全局视角
↓
Stage 6
GraphRAG
Entity + Relation + Community
│
│ 流程仍需要智能规划
↓
Stage 7
Agentic RAG
Plan → Retrieve → Reason → Retrieve
│
↓
Stage 8
RAG + Long Context + Tools + Memory

从架构思想看，本质变化是：

Search
 ↓
Retrieval
 ↓
Knowledge Access
 ↓
Reasoning
 ↓
Decision Making

十四、各代架构优劣势对比

架构	优势	缺点	适合
Pure LLM	简单、低延迟	知识过期、私域未知	通用问答
Naive RAG	简单、便宜、易落地	检索质量一般	FAQ、文档 QA
Advanced RAG	准确率明显改善	Pipeline复杂	企业知识库
Hybrid RAG	语义+关键词兼顾	调参复杂	技术/业务文档
Modular RAG	多数据源	架构复杂	企业平台
Adaptive RAG	成本/效果平衡	Router可能误判	大规模系统
Self/Corrective RAG	鲁棒性高	多次LLM调用	高可靠问答
GraphRAG	关系/全局分析强	构建成本高	复杂知识网络
Agentic RAG	多步推理能力强	延迟、成本、可控性	Data Agent
Long Context + RAG	灵活、信息完整	Token成本较高	长文档分析

十五、RAG 最大的优势其实不是“降低幻觉”

经常看到这样的表述：

RAG = 解决幻觉。

这个理解过于简单。

我更倾向于认为 RAG 真正重要的价值有五个：

LLM
 │
 ├── Parametric Knowledge
 │
 └── External Knowledge
          │
          ├── Freshness
          ├── Private
          ├── Traceable
          ├── Controllable
          └── Replaceable

特别是企业场景中，后三个非常重要。

1. Knowledge Freshness

知识可以独立更新。

2. Private Knowledge

可以接：

ERP
MES
CRM
SRM
DW
Wiki
SharePoint
PDF

3. Traceability

可以回答：

1
2
3

答案是什么？
       +
依据是什么？

4. Knowledge Governance

可以控制：

哪些数据
谁可以访问
什么版本
什么时候生效

5. Model / Knowledge 解耦

这是企业架构尤其重要的一点：

        AI Application
              │
    Knowledge Layer
              │
       Model Router
   ┌──────────┼─────────┐
   ↓          ↓         ↓
GPT          Claude    Local LLM

换模型：

1	Knowledge Layer 不变

换知识：

1	LLM 不需要重新训练

十六、RAG 最大的弱点：它把问题从 Generation 转移到了 Retrieval

这是做企业 RAG 最容易忽略的问题。

很多项目：

换 Embedding Model
换 Vector DB
换 LLM
调 Prompt

最后准确率还是只有 70%。

原因往往不是模型，而是：

Data Quality
     ↓
Parsing
     ↓
Chunking
     ↓
Metadata
     ↓
Retrieval
     ↓
Ranking
     ↓
Context
     ↓
    LLM

任何一层错了都会传递。

所以实际可以写成：

RAG Quality
≈
Data Quality
× Retrieval Quality
× Context Quality
× LLM Reasoning Quality

这是乘法关系，不是加法关系。

例如：

1	Retriever Recall = 80%

意味着：

20% 的问题，LLM 根本拿不到正确资料。

后面再怎么 Prompt Engineering 都解决不了。

十七、一个容易误判的趋势：未来不是“RAG 会不会消失”

Long Context 越来越长以后，经常有人问：

RAG 是否会被 Long Context 淘汰？

我的判断是不会，但 Naive RAG 的重要性会降低。

未来更可能是：

                    Agent
                      │
                   Router
                      │
      ┌───────────────┼────────────────┐
      ↓               ↓                ↓
Parametric        Long Context      Retrieval
Knowledge                              │
                               ┌───────┼───────┐
                               ↓       ↓       ↓
                             Vector   Graph    SQL
                               │       │       │
                               └───────┼───────┘
                                       ↓
                                     Tools

模型自己决定：

这个问题我知道
        ↓
直接回答

需要读完整合同
        ↓
Long Context

需要找几个相关文档
        ↓
Vector RAG

需要理解关系
        ↓
GraphRAG

需要最新经营数据
        ↓
SQL

需要最新实时信息
        ↓
API / Search

需要多步分析
        ↓
Agent Loop

这才是比较完整的下一代架构。

十八、放到企业 Data Agent 场景

企业 Data Agent：

                    Data Agent
                        │
              ┌─────────┼─────────┐
              ↓         ↓         ↓
           Planner    Memory    Policy
              │
              ↓
        Knowledge Router
              │
    ┌─────────┼─────────┬──────────┐
    ↓         ↓         ↓          ↓
Vector RAG GraphRAG  Semantic    API
                      Layer
                       ↓
                  Metric / SQL
                       ↓
                     Hive

这时：

RAG 不再等于知识库。

它应该被理解为：

Agent 获取外部上下文的一种机制。

而：

Semantic Layer
SQL Engine
Knowledge Graph
Vector DB
Search Engine
API
MCP / Tools

本质上都属于：

External Knowledge / External Context

这也是我认为理解现代 RAG 最重要的一点。

总结

LLM + RAG 的演化，本质上经历了：

“给 LLM 找几段资料” → “给 LLM 建立可靠的知识访问层” → “让 LLM 自己决定如何获取知识” → “让 Agent 在推理过程中持续获取、验证和利用外部世界的信息”。

因此站在 2026 年看，企业真正值得建设的已经不是一个孤立的 RAG 知识库，而是：

             Enterprise AI Knowledge Layer
                        │
      ┌─────────────────┼─────────────────┐
      ↓                 ↓                 ↓
Document Knowledge   Semantic Data    Operational
      │                 │               Tools
Vector / Graph       Metric / SQL      API / MCP
      └─────────────────┼─────────────────┘
                        ↓
                   Agent Runtime
                        ↓
                       LLM

这条路线与我们前面讨论的 “Hive 数据仓库 → 指标语义层 → Agent 统一语义接口”实际上正好可以接起来：RAG 负责非结构化知识，Semantic Layer 负责结构化事实，Agent 负责决定什么时候用哪一种。 这比简单建设一个“企业向量知识库”更接近最终形态。

陶玉印的博客

LLM + RAG 架构的演进过程