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

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

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

一、为什么会出现 RAG

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

1
2
3
4
5
6
7

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

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

这带来几个天然问题：

1
2
3
4
5
6
7

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

例如问：

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

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

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

1
2

Parametric Memory
模型参数中的知识

与：

1
2

Non-parametric Memory
外部知识库

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

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

1
2
3
4

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

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

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

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

1
2
3
4
5
6
7

User
 ↓
Prompt
 ↓
LLM
 ↓
Answer

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

1
2

Prompt Engineering
Fine-tuning

Fine-tuning 的问题是：

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

例如：

1
2

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

很适合 Fine-tuning。

但：

1
2
3

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13

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

这是理解 RAG 的第一原则。

三、第一代：Naive RAG

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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


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

例如企业知识库：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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 没找到正确答案。

例如：

1
2
3
4
5
6
7
8
9

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

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

1
2
3

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

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

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

这促成了第二阶段。

四、第二代：Advanced RAG

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

1

Retrieval Pipeline

整体结构开始变成：

1
2
3
4
5
6
7
8
9
10
11
12
13

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

也就是：

1
2
3
4
5
6
7

 Pre-Retrieval
      │
      ↓
   Retrieval
      │
      ↓
Post-Retrieval

1. Pre-Retrieval

首先优化问题。

例如用户问：

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

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

系统可以先：

1
2
3
4
5
6
7
8
9
10
11
12
13

Query Rewrite

去年
 ↓
2025

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

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

甚至把一个问题拆成：

1
2
3
4

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
2
3
4
5
6

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

例如：

1

ZWFSYS_DF_JE

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

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

1
2
3
4
5
6
7
8
9
10
11
12

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

也就是：

Sparse Retrieval + Dense Retrieval

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

六、Retriever 后面增加 Reranker

原来：

1
2
3

Vector Search
    ↓
Top 5

后来：

1
2
3
4
5
6
7

Retriever
    ↓
Top 50
    ↓
Reranker
    ↓
Top 5

Retriever 的目标：

Recall

尽量别漏。

Reranker 的目标：

Precision

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

所以：

1
2
3
4
5
6
7
8
9
10
11

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

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

七、第三代：Modular RAG

再往后，人们发现：

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

于是变成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

RAG 从：

1

固定流水线

演变成：

1

Composable Architecture

典型模块包括：

1
2
3
4
5
6
7
8
9
10
11

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

这一步非常关键。

因为企业知识绝不只是：

1

PDF → Vector DB

而是：

1
2
3
4
5
6
7
8
9
10
11
12
13

                 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 本身完全可以回答。

却仍然执行：

1
2
3
4

Embedding
Vector Search
Reranking
LLM

不仅增加：

• 延迟；
• Token；
• 计算成本；

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

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

1
2
3
4
5
6
7
8
9
10

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

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

这意味着：

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

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

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

Adaptive RAG 解决：

要不要检索？

下一个问题是：

检索到的内容可信吗？

传统 RAG：

1
2
3
4
5

Retrieve
   ↓
Documents
   ↓
LLM

隐含假设：

Retriever 给我的东西是对的。

但现实不是如此。

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

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

可以理解为：

1
2
3
4
5
6
7
8
9
10
11
12
13

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

而 Corrective RAG 更进一步：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

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

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

1
2
3
4
5
6
7

Retrieve
   ↓
Evaluate
   ↓
Correct
   ↓
Retrieve

从：

Retrieval Pipeline

开始变成：

Retrieval Loop

十、第六代：GraphRAG

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

Chunk 把知识结构切碎了。

例如文档描述：

1
2
3
4
5
6
7
8

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

Chunk 后可能变成：

1
2
3
4
5
6
7
8
9
10
11

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

Chunk 035
A经销商……

Chunk 107
产品P……

Chunk 246
华东事业部……

Vector Search 很容易找到：

1

局部相似内容

却不擅长回答：

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

或者：

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

于是 GraphRAG 出现。

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

大致结构：

1
2
3
4
5
6
7
8
9
10
11

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

查询时：

1
2
3
4
5
6
7
8
9
10

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

GraphRAG 优势

特别适合：

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

缺点

代价也明显：

1
2
3
4
5
6
7
8
9
10
11

文档
 ↓
实体抽取
 ↓
关系抽取
 ↓
图构建
 ↓
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

传统：

1
2
3
4
5

User
 ↓
Retriever
 ↓
LLM

Agentic：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

              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：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

发现：

1

材料成本 ↑ 3%

再继续：

1
2
3
4
5
6
7
8
9

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

理论上可以：

1
2
3
4
5

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)

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

1
2
3
4
5
6
7
8
9
10
11
12
13

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

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

可以把整个历史看成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

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

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

1
2
3
4
5
6
7
8
9

Search
 ↓
Retrieval
 ↓
Knowledge Access
 ↓
Reasoning
 ↓
Decision Making

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

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

经常看到这样的表述：

RAG = 解决幻觉。

这个理解过于简单。

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

1
2
3
4
5
6
7
8
9
10
11

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

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

1. Knowledge Freshness

知识可以独立更新。

2. Private Knowledge

可以接：

1
2
3
4
5
6
7
8

ERP
MES
CRM
SRM
DW
Wiki
SharePoint
PDF

3. Traceability

可以回答：

1
2
3

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

4. Knowledge Governance

可以控制：

1
2
3
4

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

5. Model / Knowledge 解耦

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

1
2
3
4
5
6
7
8

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

换模型：

1

Knowledge Layer 不变

换知识：

1

LLM 不需要重新训练

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

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

很多项目：

1
2
3
4

换 Embedding Model
换 Vector DB
换 LLM
调 Prompt

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

任何一层错了都会传递。

所以实际可以写成：

1
2
3
4
5
6

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 的重要性会降低。

未来更可能是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

模型自己决定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

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

需要读完整合同
        ↓
Long Context

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

需要理解关系
        ↓
GraphRAG

需要最新经营数据
        ↓
SQL

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

需要多步分析
        ↓
Agent Loop

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

十八、放到企业 Data Agent 场景

企业 Data Agent：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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

这时：

RAG 不再等于知识库。

它应该被理解为：

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

而：

1
2
3
4
5
6
7

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 知识库，而是：

1
2
3
4
5
6
7
8
9
10
11
12

             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 负责决定什么时候用哪一种。 这比简单建设一个“企业向量知识库”更接近最终形态。

“AI-Native 数据处理（AI-Native Data Processing）”，它还不像 ETL、ELT、Lakehouse 那样已经形成严格统一的行业定义，但主流数据平台正在明显向同一个方向收敛：Databricks 已把自然语言生成数据转换、Agent 访问结构化/非结构化数据纳入数据工程体系；Snowflake 把 LLM 能力直接变成可在数据处理流程中调用的 AI Functions；Microsoft Fabric 则开始让 Data Agent 根据问题判断相关数据源和执行方式。(Databricks Documentation)

因此，更倾向于把它定义成一种新的数据计算与执行范式。

一、先给出一个定义

建议把 AI-Native 数据处理定义为：

以业务意图和数据语义作为任务入口，以模型推理作为动态决策机制，将确定性数据计算、概率性模型计算和外部工具调用组合成可规划、可执行、可观察、可评价、可反馈的数据处理过程。

如果把这个定义再压缩，可以写成：

AI-Native Data Processing = Intent + Semantics + Reasoning + Data Compute + Tool Use + Evaluation Loop

这里最关键的不是“用了 AI”，而是：

数据处理逻辑不再完全由开发人员事先编码确定，而允许系统在约束范围内，根据数据、语义、上下文和执行结果动态决定“怎么处理”。

这是范式发生变化的地方。

二、传统数据处理的核心是：预先定义 How

传统 ETL 本质上是：

1
2
3
4
5
6
7
8
9
10
11

Requirement
    ↓
Developer
    ↓
SQL / Python / Spark
    ↓
DAG
    ↓
Execute
    ↓
Data

例如业务提出：

计算每个经销商最近 12 个月销售额、回款额和应收余额。

数据工程师需要提前知道：

1
2
3
4
5
6
7
8

销售额在哪张表
回款在哪张表
客户主数据在哪
日期字段是什么
客户ID是什么
如何Join
如何过滤
如何聚合

然后写成：

1
2
3
4
5
6

SELECT ...
FROM sales s
LEFT JOIN customer c ...
LEFT JOIN payment p ...
WHERE ...
GROUP BY ...

所以传统数据处理的核心关系是：

1

Requirement → Code → Execution → Data

真正控制数据处理过程的是 Code。

三、AI-Native 的核心变化：从 How 转向 What

AI-Native 更像：

1
2
3
4
5
6
7
8
9
10
11
12
13

Intent
  ↓
Semantic Understanding
  ↓
Planning
  ↓
Tool / Model / Data Operator Selection
  ↓
Execution
  ↓
Evaluation
  ↓
Re-plan / Fix / Continue

用户给出的可能只是：

分析最近半年华东地区销售下降的原因。

系统首先要理解：

1
2
3
4
5

“最近半年”是什么时间范围？
“华东”对应哪个组织维度？
“销售”使用收入、开票还是出库口径？
“下降”与同比还是环比比较？
“原因”可能涉及哪些维度？

然后根据 Semantic Layer / Metadata 找到：

1
2
3
4
5
6
7
8
9

sales_amount
customer
product
sales_region
channel
price
quantity
promotion
inventory

再规划：

1
2
3
4
5
6
7

Step 1 计算销售趋势
Step 2 判断下降时间点
Step 3 分解 Price / Volume
Step 4 按产品分析
Step 5 按客户分析
Step 6 按地区分析
Step 7 检查库存、停售、新品等异常

然后才生成 SQL、调用 Spark、执行查询、分析结果。

如果发现：

1

销售额下降主要来自A产品

系统还可以继续：

1
2
3
4
5

检查A产品销量
检查A产品价格
检查库存
检查客户覆盖率
检查停售记录

因此：

ETL

1
2
3

Human defines What
Human defines How
Computer executes

AI-Native

1
2
3
4
5

Human defines What + Constraints

AI determines How

Computer + Model execute

这是第一层本质变化。

四、但这里有一个非常重要的边界：AI-Native ≠ AI-assisted

现在很多产品容易把这几个概念混起来。

从理解上至少分成四层。

例如：

1

“帮我写一段 Hive SQL”

这是：

AI-Assisted

并不是 AI-Native。

下面这种：

1
2

SELECT ai_classify(customer_comment)
FROM customer_feedback;

已经进一步了。

这属于：

AI-Enhanced Data Processing

Snowflake Cortex AI Functions 已经体现这种趋势，允许直接在数据处理流程中对文本、图像等非结构化数据执行模型推理。(Snowflake Documentation)

但真正的 AI-Native 应该是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

目标：
识别导致客户流失的主要因素

Agent:
    ↓
读取指标定义
    ↓
寻找相关数据
    ↓
检查数据质量
    ↓
决定分析方法
    ↓
生成 SQL
    ↓
执行
    ↓
判断结果
    ↓
发现需要客服文本
    ↓
调用 LLM 提取投诉原因
    ↓
关联结构化数据
    ↓
重新分析
    ↓
评价结果是否足够解释问题

此时 AI 已经进入数据处理的 Control Plane。

这才是关键。

五、因此 AI-Native 真正改变的是“控制平面”

这是理解这个范式最重要的一点。

传统数据平台可以抽象为：

1
2
3
4
5
6
7
8
9
10
11
12

       Control Plane
            │
   DAG / Scheduler / Code
            │
            ▼
       Data Plane
 ┌──────────┼──────────┐
SQL       Spark       Python
 │          │           │
 └──────────┼───────────┘
            ▼
           Data

Airflow、Oozie、DataWorks、Dagster、Fabric Pipeline，本质上都主要属于控制层。

DAG 是预先确定的：

1

A → B → C → D

而 AI-Native：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

            Intent
               │
               ▼
      Semantic / Context
               │
               ▼
      ┌─────────────────┐
      │ AI Control Plane│
      │                 │
      │ Reasoning       │
      │ Planning        │
      │ Tool Selection  │
      │ Evaluation      │
      │ Re-planning     │
      └────────┬────────┘
               │
   ┌───────────┼───────────┐
   ▼           ▼           ▼
  SQL        Spark        LLM
   │           │           │
   ├───────────┼───────────┤
   ▼           ▼           ▼
Vector DB     API       Python
   │           │           │
   └───────────┼───────────┘
               ▼
              Data

所以从架构上讲：

AI-Native 最大的变化并不是多了一个 LLM Compute Engine，而是 Data Control Plane 从静态编排转向了“受约束的智能编排”。

最近关于 Agentic Cloud Data Engineering 的研究也开始把 Agent 放到这个位置：让 Agent 基于 pipeline telemetry、metadata 和 governance policy 做受约束的控制决策，而不是单纯生成代码。(arXiv)

六、第二个本质变化：Deterministic + Probabilistic Computing

传统数据处理的基本假设是：

1

Input + Program → Deterministic Output

比如：

1

SUM(amount)

同样的数据：

1
2

执行100次
结果100次相同

但 AI 计算不同：

1
2
3

Text + Model + Prompt + Context
             ↓
          Result

它天然带有概率性质。

例如：

1
2

客户投诉：
“产品还可以，就是最近送货越来越慢。”

传统 SQL 很难处理。

LLM 可以：

1
2
3
4
5

{
  "product_quality": "positive",
  "logistics": "negative",
  "complaint_type": "delivery_delay"
}

于是未来的数据处理算子会变成两类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Data Operator

├── Deterministic Operator
│   ├── Filter
│   ├── Join
│   ├── Aggregate
│   ├── Window
│   └── Sort
│
└── AI Operator
    ├── Extract
    ├── Classify
    ├── Summarize
    ├── Embed
    ├── Entity Resolution
    ├── Semantic Match
    └── Reason

Snowflake 把 AI Function 放进 SQL、Databricks 提供数据 enrichment 与结构化/非结构化 Agent 工具，本质上都是在让 Model Compute 成为 Data Compute 的一等公民。(Snowflake Documentation)

这是第二个非常重要的范式变化。

七、第三个变化：Structured Data → Multimodal Data

过去数据工程天然偏爱：

1
2
3
4

Table
Row
Column
Schema

所以传统数据仓库解决得最好的是：

1
2
3
4
5

ERP
CRM
MES
WMS
SRM

这类结构化数据。

但企业大量知识实际上存在于：

1
2
3
4
5
6
7
8
9
10
11
12
13

PDF
Word
Excel
邮件
合同
图片
客服记录
会议纪要
产品说明书
SOP
日志
音频
视频

过去的处理通常是：

1
2
3
4
5
6
7

Unstructured
      ↓
特殊ETL
      ↓
Structure
      ↓
Database

而 AI-Native 更接近：

1
2
3
4
5
6
7
8
9
10
11

                Enterprise Data

      ┌────────────┼────────────┐
      ▼            ▼            ▼
Structured    Semi-structured  Unstructured
    │              │             │
    SQL           JSON          LLM/VLM
    │              │             │
    └──────────────┼─────────────┘
                   ▼
             Semantic Layer

Databricks 当前已经明确区分 Agent 对 structured data 和 unstructured data 的访问机制，Snowflake Cortex 同样把文档、文本和图像处理纳入数据平台。(Databricks Documentation)

所以未来“数据”的边界本身都会扩大。

八、第四个变化：Schema First → Semantic First

这是企业落地 AI-Native 时比 LLM 更重要的一层。

传统数据系统主要告诉计算机：

1
2
3

table: dwd_sales_order
column: amt
type: decimal(18,2)

但 Agent 真正需要知道：

1

amt 是什么？

例如：

1
2
3
4
5
6
7

销售额
含税还是不含税？
开票还是发货？
人民币还是原币？
订单取消是否计入？
退货怎么计算？
集团内部交易是否剔除？

所以未来 Metadata 必须从：

1

Technical Metadata

升级到：

1

Business Semantics

整个体系会变成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Physical Data

Table
Column
Partition
File
    │
    ▼
Metadata
    │
    ▼
Semantic Layer
    │
    ├── Entity
    ├── Metric
    ├── Dimension
    ├── Relationship
    ├── Business Rule
    ├── Data Quality
    └── Permission
    │
    ▼
Agent

没有 Semantic Layer：

1

Agent → 猜 SQL

有 Semantic Layer：

1

Agent → 理解业务 → 规划 → SQL

这也是为什么 AI-Native 数据架构和之前讲的 指标语义层 / Agent Semantic Interface 最终实际上会汇合。

九、第五个变化：Pipeline → Goal-driven Workflow

传统 Pipeline：

1
2
3
4
5
6
7
8
9
10
11

Source
 ↓
ODS
 ↓
DWD
 ↓
DWS
 ↓
ADS
 ↓
BI

最重要的是：

路径固定。

AI-Native：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Goal
 │
 ▼
Planner
 │
 ├─ Task A
 ├─ Task B
 └─ Task C
     │
     ▼
Observe
 │
 ▼
Evaluate
 │
 ├─ sufficient → Finish
 │
 └─ insufficient
         │
         ▼
      Re-plan

也就是：

1
2
3
4
5
6
7
8
9

Plan
 ↓
Execute
 ↓
Observe
 ↓
Evaluate
 ↓
Re-plan

因此真正的最小执行单位可能从：

1
2
3

Job
Task
DAG

逐渐变成：

1
2
3
4

Goal
Plan
Action
Observation

这和 Agent 系统的 Reasoning–Acting Loop 是一致的。

十、还有一个经常被忽略的变化：Test → Evaluation

传统数据工程：

1
2
3
4
5

SELECT COUNT(*)
NULL检查
唯一性检查
金额平衡
Schema检查

判断通常是：

1

PASS / FAIL

AI-Native 不够。

例如：

1

从合同中提取付款条件

你不能简单测试：

1

result IS NOT NULL

还必须评价：

1
2
3
4
5
6

正确率？
完整率？
置信度？
Groundedness？
格式是否合法？
业务规则是否满足？

于是：

1
2
3

Traditional Data Quality

Rule → Result → Pass / Fail

变成：

1
2
3
4
5
6
7
8
9
10
11

AI-Native Quality

Rule
 +
Statistical Evaluation
 +
LLM Evaluation
 +
Business Validation
 +
Human Feedback

所以未来：

Evaluation 很可能会成为 AI 数据工程里的一级基础设施。

而不是测试阶段附加的一套工具。

十一、因此 AI-Native 可以定义 7 个判定特征

一个数据系统是否真正称得上 AI-Native Data Processing，至少应该满足其中大部分：

注意最后一个非常重要。

AI-Native 绝不是：

1
2
3
4
5
6
7

用户
 ↓
LLM
 ↓
随便生成SQL
 ↓
生产数据库

企业级应该是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

             Intent
                │
                ▼
            AI Agent
                │
      ┌─────────┴─────────┐
      ▼                   ▼
 Semantic Layer      Governance
      │                   │
      │             Permission
      │             Policy
      │             Cost
      │             Quality
      │
      ▼
    Planner
      │
      ▼
  Execution Plan
      │
 ┌────┼────┬────┐
 ▼    ▼    ▼    ▼
SQL Spark LLM  API
 │    │    │    │
 └────┴────┴────┘
      │
      ▼
  Observation
      │
      ▼
  Evaluation
      │
      ├── Finish
      │
      └── Re-plan

十二、用一句话区分 ETL、ELT、AI-Native

这是比较容易传播的一组定义：

ETL

人在数据进入平台之前定义怎么处理。

1

Extract → Transform → Load

ELT

先把数据放进平台，再由计算引擎处理。

1

Extract → Load → Transform

AI-Native

人定义目标、语义和约束，由智能执行系统动态决定如何处理数据。

可以抽象成：

1
2
3
4
5
6
7
8
9
10
11

Intent
   ↓
Understand
   ↓
Plan
   ↓
Execute
   ↓
Evaluate
   ↓
Adapt

甚至可以给它一个比较有意思的缩写：

IUPEA

1
2
3
4
5

Intent
Understand
Plan
Execute
Adapt

当然不用急着把它包装成行业术语，但这个过程模型本身是成立的。

十三、应该明确：AI-Native Data Processing 有两个方向

这个区别非常重要。

方向 A：Data for AI

目标是：

把数据加工成 AI 能消费的数据。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13

Document
 ↓
Parse
 ↓
Chunk
 ↓
Metadata
 ↓
Embedding
 ↓
Vector Index
 ↓
RAG

这是现在很多所谓：

1

AI Data Pipeline

真正做的事情。

Databricks 的 RAG 数据管道文档就是典型例子：将非结构化文档转成适合 GenAI 检索的数据资产。(Databricks Documentation)

方向 B：AI for Data

目标是：

让 AI 本身参与数据处理。

1
2
3
4
5
6
7
8
9
10
11

Intent
 ↓
Agent
 ↓
Understand Data
 ↓
Plan
 ↓
SQL / Spark / LLM
 ↓
Evaluation

我认为：

只有 B，或者 A+B 的结合，才更接近严格意义上的 AI-Native Data Processing。

否则只是：

AI-ready Data Engineering。

十四、再进一步，未来的数据处理栈可能变成五层

传统架构通常是：

1
2
3
4
5

Storage
Compute
SQL
Orchestration
BI

AI-Native 后可能逐渐形成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

┌──────────────────────────────┐
│ 5. Agent / Application Layer │
│ ChatBI / Data Agent / Apps   │
├──────────────────────────────┤
│ 4. Semantic Layer            │
│ Metric / Entity / Knowledge  │
├──────────────────────────────┤
│ 3. Intelligent Control Plane │
│ Planner / Agent / Evaluator  │
├──────────────────────────────┤
│ 2. Hybrid Compute Layer      │
│ SQL / Spark / ML / LLM / VLM│
├──────────────────────────────┤
│ 1. Unified Data Layer        │
│ DW / Lake / Vector / Docs    │
└──────────────────────────────┘

真正的新东西其实集中在：

第 3 层 Intelligent Control Plane。

很多企业目前正在建设第 2 层：

1

数据库 + LLM

但真正进入 AI-Native，还需要：

1
2
3
4
5
6
7

Semantic Layer
+
Agent Runtime
+
Evaluation
+
Governance

十五、最后给一个比较认可的“范式公式”

如果要把我们这次讨论沉淀成一个后续可以持续使用的架构定义，可以为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

              Semantic
                 │
                 ▼
Intent → Agentic Control → Plan
                 │
      ┌──────────┼──────────┐
      ▼          ▼          ▼
     SQL        Spark       AI
      │          │          │
      └──────────┼──────────┘
                 ▼
              Result
                 │
                 ▼
             Evaluation
                 │
                 ▼
              Feedback

最核心的一句话

传统数据工程是在“编写数据处理程序”，AI-Native 数据工程则开始变成“构建能够理解目标并完成数据处理的数据智能系统”。

而这意味着数据工程的核心产物也会逐渐发生变化：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

过去：

SQL
ETL
DAG
Data Mart

              ↓

未来：

Semantic Model
Tool
Policy
Evaluation
Agent Workflow
Data Product

这也是为什么 AI-Native 数据处理不是 ETL 的一次升级，而很可能是 ETL → ELT 之后更深的一次数据工程范式迁移。

如果沿着这个概念继续往下推，其实可以得到一个非常完整的体系：

ETL → ELT → Analytics Engineering → AI-Assisted Data Engineering → Agentic Data Engineering → AI-Native Data Processing

这条演进链，非常适合进一步拆成“AI 时代数据开发范式”的核心理论框架。

企业需要怎样的数据底座，才能真正支撑Data Agent？

前面的文章中，我们讨论了一个越来越明确的趋势：随着ChatBI和Data Agent的发展，企业数据应用正在从“提前开发答案”转向“根据问题生成答案”，而数据仓库的角色，也正在从传统BI的后台逐渐演变为AI应用的可信数据底座。

但是，当企业真正准备建设Data Agent时，一个更加现实的问题随之而来：

现有的数据仓库，真的可以直接支撑Data Agent吗？

我的答案是：大多数情况下还不够。

很多企业已经建设了多年的数据仓库，拥有ODS、DWD、DWS、ADS等完整的数据分层，也建立了大量面向财务、营销、供应链和生产管理的报表。在传统BI体系下，这套架构已经能够很好地工作，但如果直接在它上面接入大模型，让Agent面对数千张数据表自动生成SQL并回答业务问题，很快就会发现很多以前并不明显的问题。

AI不知道哪张表是可信的，不知道同名指标应该选择哪个口径，不知道表与表之间应该怎样关联，也不知道某个用户是否有权查看某些数据；即使它成功生成了一段语法完全正确的SQL，也无法证明最终返回的结果就是企业希望得到的那个答案。

因此，Data Agent时代真正需要建设的，并不是一个“可以被大模型访问的数据仓库”，而是一套可以被机器准确理解、可靠查询、受控访问并能够追溯结果的数据体系。

这两者之间，有着本质区别。

一、传统数据仓库解决了数据问题，但没有完全解决“机器理解”问题

先看一套比较典型的企业数据架构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

ERP / CRM / MES / SRM / WMS
              │
              ▼
        数据集成 / CDC
              │
              ▼
             ODS
              │
              ▼
             DWD
              │
              ▼
             DWS
              │
              ▼
             ADS
              │
              ▼
        OLAP / BI / 报表

这套架构的核心目标，是将不同业务系统的数据汇集起来，经过清洗、转换、建模和汇总之后，为下游数据分析提供统一的数据来源。

在过去二十年里，它已经被证明是一种非常成功的架构。

问题在于，这套体系主要是为人和预定义程序设计的。

数据开发工程师知道dwd_sales_order_detail是什么，BI工程师知道应该使用哪张DWS表，财务分析人员知道“含税销售收入”和“不含税销售收入”有什么区别，这些知识大量存在于人的经验、需求文档、SQL代码以及部门内部约定中。

Data Agent却没有这些经验。

假设一家企业的数据仓库拥有1200张表，Agent面对的可能是这样的对象：

1
2
3
4
5
6
7
8

dwd_sales_order_detail
dwd_sales_invoice_detail
dwd_sales_return_detail
dws_customer_sales_month
dws_customer_profit_month
ads_sales_analysis
ads_finance_revenue
...

业务人员只问了一句话：

“今年华东地区的销售收入同比增长多少？”

对于人类数据工程师来说，这可能是一个非常简单的问题，因为他知道公司默认使用财务确认收入，知道应该使用哪个日期字段，也知道华东区域按照客户所属销售区域而不是发货地址划分。

但是对于Agent来说，这句话至少包含四个需要解释的概念：

什么叫“销售收入”？

什么叫“今年”？

什么叫“华东地区”？

同比应该和哪个期间比较？

如果这些规则没有被显式表达出来，大模型只能根据字段名称、表结构和上下文进行猜测。

而企业数据分析最不能依赖的，恰恰就是猜测。

二、Data Agent需要的不是数据库访问权，而是企业数据的“说明书”

早期ChatBI产品有一种很常见的技术路线：把数据库Schema提供给大模型，让模型根据用户问题生成SQL，然后执行SQL并返回结果。

对于十几张结构清晰的表，这种Text-to-SQL模式可能工作得很好。

但是进入企业级数据仓库之后，问题会迅速复杂化。

例如：

1
2
3
4
5
6

SELECT
    region_name,
    SUM(sales_amount) AS sales_amount
FROM dws_sales_month
WHERE year_id = 2026
GROUP BY region_name;

从SQL语法来看没有任何问题。

但真正需要确认的是：

sales_amount是含税还是不含税？

是否扣除了退货？

区域按照客户归属还是订单归属？

2026年的数据是否已经完成月结？

这意味着，企业不能只把Schema交给Agent，还必须告诉它Schema背后的业务含义。

因此，在数据仓库与Agent之间，我认为必须增加一个非常重要的能力层：

Semantic Layer，也就是语义层。

它负责把数据库中的物理结构转换成业务可以理解、Agent也可以理解的语义模型。

例如，不应该让Agent自己推断“销售收入”应该如何计算，而应该明确告诉它：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

metric:
  name: sales_revenue
  label: 销售收入
  description: 财务确认的销售收入，不含税并扣除销售退回

  source: dws_finance_sales_month

  measure:
    type: sum
    field: revenue_excluding_tax

  time_dimension: accounting_date

  dimensions:
    - sales_region
    - customer
    - product

  owner: finance_center
  certified: true

这样，当业务人员询问销售收入时，Agent需要做的就不再是“猜测应该使用哪个字段”，而是选择一个已经经过企业认证的指标。

这正是语义层在AI时代重新受到重视的重要原因：它将过去存在于数据工程师头脑里的隐性知识，转换成机器可以理解和调用的显性知识。

三、一个真正面向Data Agent的数据架构应该是什么样？

如果重新设计一套面向Data Agent的数据体系，我更倾向于采用下面这样的逻辑架构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

┌───────────────────────────────────────────────┐
│                AI Application Layer           │
│                                               │
│   ChatBI   Data Agent   AI Copilot   Workflow │
└───────────────────────┬───────────────────────┘
                        │
                 MCP / API / SQL
                        │
┌───────────────────────▼───────────────────────┐
│              Semantic & Knowledge Layer       │
│                                               │
│  Metrics │ Dimensions │ Entities │ Glossary   │
│  Joins   │ Business Rules │ Knowledge │ ACL   │
└───────────────────────┬───────────────────────┘
                        │
┌───────────────────────▼───────────────────────┐
│              Trusted Data Foundation          │
│                                               │
│ Data Warehouse │ Lakehouse │ MDM │ Metadata   │
│ Data Quality   │ Lineage   │ Catalog │ Security│
└───────────────────────┬───────────────────────┘
                        │
┌───────────────────────▼───────────────────────┐
│                 Source Systems                │
│                                               │
│ ERP │ MES │ CRM │ SRM │ WMS │ OA │ Files     │
└───────────────────────────────────────────────┘

与传统数据仓库相比，底层的数据采集、清洗、建模和存储并没有消失，真正增加的是中间的Semantic & Knowledge Layer。

这也是我认为AI时代企业数据架构最值得关注的变化之一。

过去的架构重点解决：

数据如何从源系统流向BI？

未来还必须解决：

AI如何理解这些数据代表什么？

四、第一项基础能力：可信的数据仓库或Lakehouse

无论上层采用什么样的Agent框架，最底层仍然需要一个稳定的数据基础设施。

它可能是传统Hive数据仓库，也可能是Snowflake、Databricks等云数据平台，还可能采用Iceberg、Hudi、Paimon等开放表格式建设Lakehouse。

技术选择本身并不是最重要的。

真正重要的是这一层能够提供几个基本能力：

稳定的数据模型、完整的历史数据、可追溯的数据加工过程、可靠的数据更新机制，以及能够满足Agent查询需求的性能。

尤其需要注意最后一点。

传统BI的查询模式相对稳定，一张Dashboard可能每天执行几十次固定SQL，而Agent的查询模式完全不同。一个复杂问题可能被拆解成十几个子问题，Agent不断执行查询、验证假设并继续追问，这会使数据平台面临完全不同的并发和计算压力。

因此，未来的数据底座不仅要“存得下”，还要能够支撑大量动态、不可预测的分析请求。

对于传统Hive体系，可以继续承担离线数据加工和历史数据沉淀；对于需要秒级交互的数据，可以通过ClickHouse、Doris、StarRocks等OLAP引擎提供服务；如果企业正在建设新的湖仓体系，则可以考虑Iceberg、Paimon等表格式解决数据湖上的事务、Schema演进以及批流数据管理问题。

关键不是追求某一种“AI原生数据库”，而是根据数据规模、时效要求和查询模式建立合理的数据服务层。

五、第二项基础能力：统一语义层

如果只能从整个架构中选择一个我认为最值得企业AI团队重点建设的能力，我会选择Semantic Layer。

原因并不复杂。

Data Agent最危险的情况并不是“不会回答”，而是：

它非常自信地回答了一个口径错误的答案。

假设企业存在三个销售额指标：

1
2
3

sales_order_amount       订单金额
sales_invoice_amount     开票金额
sales_revenue            财务确认收入

业务人员问：

“今年销售额是多少？”

传统BI不存在太大问题，因为报表开发时已经选择了指标。

而Agent必须实时做出选择。

如果没有Semantic Layer，它只能根据名称猜测；如果存在统一语义层，则可以根据业务定义、用户角色和分析场景选择经过认证的指标。

截至2026年，Semantic Layer已经形成了比较明确的产品方向，例如dbt Semantic Layer、Cube以及部分云数据平台和BI产品自身的语义模型。它们实现方式不同，但核心思想非常接近：将Metric、Dimension、Entity、Join和Access Policy从具体报表中抽离出来，形成可以被多个数据应用复用的统一业务语义。

在AI时代，这一能力的意义已经不仅仅是让“不同BI看到同一个数字”，而是让人和Agent使用同一种企业语言。

六、第三项基础能力：元数据必须从“给人看”变成“给机器用”

过去企业建设元数据平台，更多是为了数据资产目录、血缘查询和数据治理。

数据人员打开数据目录，搜索一张表，查看字段说明和上下游血缘。

Agent时代，元数据的消费者发生了变化。

Agent同样需要知道：

customer_id是什么意思？

这张表由谁负责？

数据多久更新一次？

上一次质量检查是否通过？

这个指标来自哪些源系统？

哪些字段属于敏感数据？

因此，未来元数据平台必须具备机器可访问能力，而不能只是一个Web管理页面。

DataHub、OpenMetadata、Apache Atlas等元数据平台所沉淀的Schema、Ownership、Lineage、Glossary、Tag等信息，都有可能成为Agent Context的一部分。

例如，当Agent准备查询某个指标时，可以先获取：

1
2
3
4
5
6
7
8

{
  "metric": "gross_profit",
  "owner": "finance_center",
  "certified": true,
  "freshness": "T+1",
  "last_quality_check": "PASS",
  "source": "dws_finance_profit_month"
}

然后再决定是否使用这份数据。

这实际上意味着：

Metadata正在从数据治理系统的辅助信息，转变为Agent的上下文基础设施。

七、第四项基础能力：数据质量必须成为Agent调用数据之前的门禁

上一篇文章重点讨论了AI时代的数据质量。

如果把这个观点真正落到架构上，我认为应该遵循一个非常重要的原则：

质量检查应该发生在Agent消费数据之前，而不是回答错误之后。

传统的数据质量规则通常运行在ETL过程中，例如：

1
2
3

SELECT COUNT(*)
FROM dwd_sales_order
WHERE customer_id IS NULL;

未来可以进一步把质量状态暴露给语义层和Agent。

例如：

1
2
3
4
5
6
7
8
9
10
11
12

sales_revenue
    │
    ├── Accuracy      PASS
    ├── Completeness  PASS
    ├── Freshness     PASS
    ├── Reconciliation PASS
    │
    ▼
Certified Metric
    │
    ▼
Data Agent

如果当天财务数据尚未完成同步，指标状态就不应该是“Certified”，Agent可以直接告诉用户：

当前财务收入数据更新至8月9日，8月10日数据尚未完成同步，本次分析基于8月9日数据。

这比生成一个看起来准确、实际上数据并不完整的答案更加专业。

未来成熟的Data Agent，不应该只返回一个数字，还应该返回这个数字的可信状态。

八、第五项基础能力：主数据决定Agent能否正确理解企业实体

主数据管理在BI时代已经非常重要，而到了Agent时代，它的重要性会进一步提高。

假设同一个经销商在三个系统中的编码分别是：

1
2
3

ERP        C000238
CRM        CRM_10086
SRM        SUP-238

对于业务人员来说，这三个编码可能都代表同一家企业。

对于Agent来说，如果没有统一Customer ID，它们就是三个不同的实体。

于是，当业务人员问：

“分析这个经销商过去三年的销售、回款和售后情况。”

Agent需要同时关联CRM、ERP、财务以及售后数据。

如果企业没有做好主数据管理，这个问题甚至无法可靠计算。

因此，MDM在AI时代承担了一个新的角色：

为Agent建立企业实体的统一身份体系。

Customer、Product、Supplier、Employee、Organization等核心实体，都需要形成稳定的Entity ID。

只有这样，Agent才能真正完成跨系统推理。

九、第六项基础能力：权限必须跟着用户，而不是跟着Agent

这是很多Data Agent Demo最容易忽略的问题。

假设销售经理问：

“所有区域销售人员的奖金分别是多少？”

Agent有能力查询。

数据库也有这些数据。

但问题是：

他有权限查看吗？

传统BI通常通过报表权限、行级权限和字段权限控制访问。

Agent时代，这些权限不能消失，更不能简单地给Agent一个拥有全部数据库权限的Service Account。

正确的架构应该是：

1
2
3
4
5
6
7
8
9
10
11
12

User
 │
 │ Identity / Role
 ▼
Agent
 │
 ▼
Semantic Layer
 │
 │ Row / Column / Metric Policy
 ▼
Data Platform

也就是说，Agent只是代表用户执行任务，最终能够看到什么数据，仍然应该由用户身份和数据权限决定。

这也是为什么我不建议企业直接让大模型连接生产数据仓库并自由生成SQL。

真正的企业级Data Agent，必须运行在受治理的数据访问层之上。

十、企业案例：制造业Data Agent应该怎样查询“利润下降原因”？

假设一家制造企业拥有ERP、MES、CRM、SRM和财务系统。

总经理提出一个问题：

“为什么这个季度某产品线毛利率下降了？”

如果只是Text-to-SQL，Agent可能找到一张利润表，然后计算毛利率变化。

但真正的Data Agent应该完成更加完整的分析链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

问题：毛利率为什么下降？
            │
            ▼
识别指标：Gross Margin
            │
            ▼
Semantic Layer确认指标口径
            │
            ▼
获取销售收入、销售成本
            │
            ▼
发现成本同比上升
            │
            ▼
进一步拆解
      ┌─────┼─────┐
      ▼     ▼     ▼
   材料成本 人工成本 制造费用
      │
      ▼
发现某材料采购价格上涨
      │
      ▼
关联SRM采购数据
      │
      ▼
识别主要供应商及价格变化
      │
      ▼
生成原因分析

这个场景真正考验的，已经不是大模型能不能写SQL，而是企业是否已经建立：

统一的产品主数据。

统一的毛利率指标。

销售与成本模型。

ERP与SRM之间的数据映射。

可信的数据质量体系。

完整的数据血缘。

只有这些能力存在，Agent才可能完成真正有业务价值的多步分析。

否则所谓的Data Agent，最终仍然只是一个高级Text-to-SQL工具。

十一、工具怎么选？不要为了Agent重建整个数据平台

企业很容易犯另一个错误：看到AI之后，认为现有的数据平台已经过时，于是准备重新建设一套“AI数据平台”。

我认为大多数企业没有这个必要。

更合理的方法，是在现有数据体系之上逐层补齐能力。

这里没有所谓的标准答案。

如果企业已经拥有成熟的Hive数仓，没有必要为了AI把所有数据迁移到Lakehouse；如果已经拥有成熟的指标平台，也没有必要重新购买Semantic Layer产品。

真正需要判断的是：

现有的数据能力是否能够以标准化、机器可理解的方式提供给Agent。

这才是架构演进的核心。

十二、架构师视角：不要让Agent直接面对数据仓库

如果让我给正在建设Data Agent的企业一个最重要的架构建议，我会选择这一条：

不要让Agent直接面对整个数据仓库。

因为一个成熟企业的数据仓库中往往存在数百甚至数千张表，其中包含大量中间表、临时表、历史表以及不同版本的指标模型。

把这些Schema全部提供给LLM，不仅增加Context，还会增加模型选择错误数据源的概率。

更加合理的架构应该是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

           Data Agent
               │
               ▼
        Agent Data API
               │
               ▼
        Semantic Layer
               │
   ┌───────────┼───────────┐
   ▼           ▼           ▼
Metrics     Entities    Dimensions
   │           │           │
   └───────────┼───────────┘
               ▼
        Certified Data
               │
               ▼
       Data Warehouse

也就是说，Agent原则上应该优先访问经过认证的数据产品和业务语义，只有在需要深度探索时，才逐步开放更底层的数据能力。

这实际上与软件工程中的API设计非常相似。

我们不会让前端系统直接修改数据库。

同样，也不应该让Agent任意访问企业数据仓库。

Semantic Layer，本质上就是AI时代的数据API。

写在最后

如果说过去二十年企业数据平台建设的重点，是把分散的数据汇集起来，那么未来几年企业数据建设的重点，很可能会逐渐转向另一个问题：

如何让机器正确理解这些数据。

这也是Data Agent对企业数据体系提出的最大挑战。

它需要的不只是一个数据仓库，而是一套由可信数据、统一语义、元数据、主数据、数据质量、权限治理以及标准化访问接口共同组成的数据基础设施。

从这个角度看，AI并没有让过去的数据建设失去价值。

恰恰相反。

企业过去多年建设的数据仓库、数据治理、数据质量、主数据和元数据体系，正在第一次被连接起来，并共同成为AI应用的基础。

数据仓库解决的是“数据在哪里”。

Semantic Layer解决的是“数据是什么意思”。

数据质量解决的是“数据能不能相信”。

元数据解决的是“数据从哪里来”。

主数据解决的是“它到底是谁”。

权限体系解决的是“谁可以使用”。

而Data Agent最终解决的，才是：

如何利用这些数据和知识完成任务。

因此，真正成熟的企业Data Agent，并不是在大模型上增加一个数据库连接器，而是在企业已经形成的数据能力之上，再建立一层能够理解、推理和行动的智能系统。

这也是我认为AI时代企业数据架构真正的演进方向。

AI时代，数据质量为什么比模型更重要？

——重新理解企业数据质量体系

如果让我预测未来五年企业AI建设过程中最容易被低估的一项能力，我会毫不犹豫地选择：

数据质量（Data Quality）。

过去两年，大模型的发展几乎吸引了所有人的关注。

企业讨论最多的是模型参数、上下文长度、推理能力、Agent、RAG以及MCP，很少有人愿意花时间讨论数据质量。

原因并不难理解。

模型能够直接展示能力。

而数据质量是一项长期投入、短期难以看到效果的基础工程。

然而，在越来越多企业AI项目落地之后，一个现象开始变得十分明显：

决定AI项目最终效果的，往往不是模型，而是数据。

过去，企业更多关注模型是否足够聪明。

今天，越来越多企业开始意识到：

如果输入的数据本身存在问题，那么再优秀的大模型，也只能得到一个更加”聪明”的错误答案。

为什么BI时代的数据质量没有今天重要？

很多人会问：

企业过去二十年一直在建设数据仓库，也一直在强调数据质量，为什么今天突然变得更加重要？

原因在于：

数据消费方式发生了变化。

在BI时代，数据主要服务于报表和经营分析。

一张报表如果存在错误，通常会经历这样的过程：

1
2
3
4
5
6
7

业务发现异常。
    ↓
数据团队排查。
    ↓
修正ETL。
    ↓
重新发布报表。

虽然影响业务，但由于报表具有固定使用对象、固定展示方式以及固定更新周期，错误通常能够较快暴露。

换句话说。

BI时代的数据质量问题，大多数属于”局部影响”。

而AI时代完全不同。

ChatBI、企业知识库、Data Agent以及智能运营平台都开始直接消费企业数据。

错误的数据一旦进入AI系统，就可能通过推理、总结、自动分析等方式快速传播到多个业务场景。

因此。

AI时代的数据质量已经不仅仅影响报表。

它开始直接影响企业决策。

AI为什么会放大数据质量问题？

很多人认为，大模型最大的风险是”幻觉（Hallucination）”。

事实上，对于企业来说，真正值得担心的往往不是模型幻觉，而是可信事实的缺失。

例如，一家企业拥有两个利润指标。

ERP采用订单利润。

财务采用开票利润。

BI平台采用财务口径。

而Agent在生成SQL时，却引用了ERP事实表。

整个分析过程没有任何语法错误。

SQL能够正常执行。

模型推理过程也完全正确。

最终得到的答案却依然错误。

为什么？

因为：

AI能够保证推理逻辑正确，却无法保证事实基础正确。

这也是AI项目与互联网聊天机器人最大的区别。

企业AI真正回答的是经营问题。

经营问题没有”大概正确”。

只有”正确”与”错误”。

一个真实案例：为什么Agent总是回答错利润？

下面分享一个典型案例。

某制造企业建设了智能经营分析平台，希望管理层能够直接向Agent提问。

例如：

“分析最近半年利润下降最快的产品。”

Agent能够自动完成以下流程：

1
2
3
4
5
6
7
8
9
10
11

理解问题
    ↓
定位利润指标
    ↓
查询元数据
    ↓
生成SQL
    ↓
执行分析
    ↓
生成报告

整个流程运行正常。

但业务部门始终认为结果不可信。

最终定位问题发现：

数据仓库同时维护了两个利润口径：

• 毛利（Gross Profit）
• 财务利润（Net Profit）

而元数据没有明确标注默认口径。

Agent自动选择了第一个指标。

SQL完全正确。

模型也没有幻觉。

真正的问题来自：

指标语义缺失。

这个案例说明：

未来影响AI项目的，不一定是算法。

而是企业知识表达是否完整。

数据质量已经不仅仅是”准确”

很多企业一提到数据质量，首先想到的是：

• 空值
• 重复值
• 错误值
• 格式错误

这些当然属于数据质量。

但如果站在AI时代重新理解数据质量，会发现它已经远远超出了传统定义。

作为《数据质量管理实践手册》中文版联合译者，在翻译这本书的过程中，有一句定义让我印象非常深刻：

数据质量并不是数据本身的属性，而是数据满足使用目的的程度。

AI时代，这句话值得重新理解。

过去，一份数据能够生成报表，我们认为质量合格。

今天，一份数据不仅需要生成报表，还需要支撑：

• ChatBI
• Agent
• 自动决策
• 企业知识库
• 智能运营

数据的”使用目的”已经发生了变化。

因此，数据质量的评价标准也必须随之升级。

AI时代的数据质量体系应该关注什么？

我建议企业至少关注六类能力。

前三项是传统数据质量管理长期关注的问题。

后三项，则越来越成为AI时代的新要求。

例如：

Agent为什么选择这个指标？

SQL为什么这样生成？

为什么推荐这个客户？

未来，每一个AI回答，都需要能够追溯。

工程实践：把数据质量规则前移

很多企业的数据质量检查仍然发生在报表阶段。

AI时代，这种方式已经不够了。

建议将质量校验前移到数据进入语义层之前。

例如：

Hive数据进入DWS层之前完成完整性检查。

1
2
3
4

SELECT
    COUNT(*) AS null_customer_cnt
FROM dwd_order_detail
WHERE customer_id IS NULL;

对于关键业务指标，可以建立自动质量规则。

例如：

1
2
3
4
5
6
7
8
9
10
11

rule_name: sales_amount_check

metric: sales_amount

check:
  - not_null
  - >=0
  - compare_last_7_days
  - compare_last_year_same_day

severity: HIGH

只有通过质量校验的数据，才能进入Semantic Layer，最终被Agent消费。

这比让Agent去”猜测”数据是否正确更加可靠。

工具参考

不同企业可以根据自身规模选择不同的数据质量体系。

工具不是目的。

真正重要的是建立一套能够持续运行的数据质量体系。

架构师视角：未来的数据质量属于AI基础设施

过去，我们通常认为：

数据质量属于数据治理。

今天，我越来越倾向于另一种理解：

数据质量已经成为AI基础设施的一部分。

未来企业AI平台真正依赖的，并不是GPU数量，也不是模型参数，而是：

可信数据。

统一语义。

高质量知识。

模型可以持续升级。

Agent可以不断演进。

但是，如果企业没有建立可信的数据体系，那么所有AI能力最终都会受到限制。

写在最后

过去二十年，数据质量更多是一项数据治理工作。

今天，它正在成为企业AI建设过程中最重要的基础能力之一。

AI不会自动提高数据质量。

它只会更加快速地消费数据，更加广泛地传播数据，也更加依赖数据。

因此，未来企业真正需要建设的，并不是一个”更聪明的大模型”，而是一套能够持续产生可信事实的数据体系。

因为只有可信的数据，才能支撑可信的AI。

从RAG、ChatBI到Data Agent，看AI项目成败的真正原因

Chapter 1 软件为什么需要 AI Agent？

Part I Foundations

核心问题：为什么 AI Agent 会出现？

本章结论：AI Agent 的出现，并不是因为大模型足够强，而是因为传统软件越来越难以应对开放性任务。

Learning Objectives

完成本章后，应能够理解：

• 软件为什么需要新的执行范式
• AI Agent 解决的核心问题是什么
• 为什么 LLM 是 Agent 的基础，但 LLM 不等于 Agent
• Agent 在软件工程中的定位

本章只讨论 Agent 出现的原因，不讨论 Agent 的定义、组成和实现。这些内容将在后续章节展开。

1.1 软件的发展，本质是在降低复杂度

软件工程的发展历史，本质上是一部持续控制复杂度的历史。

每一次重要的技术演进，都源于上一代开发模式无法继续支撑软件规模的增长。

例如：

这些技术的发展方向并不相同，但目标一致：

降低软件系统的复杂度，提高软件的可维护性。

1.2 传统软件擅长解决确定性问题

过去几十年的软件开发，建立在一个共同假设之上：

开发者能够提前定义系统的执行过程。

例如，一个订单系统可以抽象为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21