随着大模型进入企业数据分析场景，一个很常见的做法是：把数据库的表结构、字段名称、字段描述、样例数据等信息提供给模型，再通过自然语言生成 SQL。

从技术上看，这条链路已经越来越成熟。但真正进入企业生产环境后会发现一个问题：

> **数据库对机器可读，不代表对 AI 可理解；AI 能理解字段含义，也不代表它知道这个字段应该怎么用。**

例如数据库中存在：

```text
sales_order.total_amount
invoice.invoice_amount
finance_revenue.recognized_amount
payment.received_amount
```

当用户询问“上季度收入是多少”时，这四个字段与“收入”都有很强的语义相关性。无论使用向量检索还是大模型进行 Schema Linking，都可能把它们召回。

问题在于：**相关不等于正确。**

企业财务口径可能明确规定，“收入”只能使用 `finance_revenue.recognized_amount`。其他三个字段虽然与收入有关，却分别代表订单金额、开票金额和实际回款。

因此，企业智能问数真正需要解决的，不只是“找到相关数据”，而是：

> **找到当前业务问题允许使用的数据，并排除那些看起来合理、实际上不能使用的数据。**

---

## 一、Schema 只能告诉 AI“有什么”

传统元数据主要描述：

```text
表名
字段名
数据类型
主键
外键
字段描述
数据量
空值率
唯一率
```

例如：

```sql
CREATE TABLE sales_order (
    order_id BIGINT,
    customer_id BIGINT,
    total_amount DECIMAL(18,2),
    created_at TIMESTAMP,
    status VARCHAR(20)
);
```

大模型能够从中判断 `total_amount` 是金额字段，`created_at` 是时间字段，`customer_id` 可能用于关联客户。

但是它无法仅凭 Schema 判断：

```text
total_amount 是否包含税费？
取消订单是否已经排除？
它代表订单额还是确认收入？
created_at 能不能用于财务统计？
customer_id 在不同系统中的业务实体是否一致？
```

这些知识并不属于数据库物理结构，而属于企业长期运行形成的**业务知识和数据使用经验**。

---

## 二、Semantic Layer 解决“是什么”，但还缺少“不能是什么”

引入语义层以后，可以进一步定义：

```yaml
metric:
  name: 确认收入
  source:
    table: finance_revenue
    field: recognized_amount
  aggregation: SUM
  time_field: recognition_date
```

这已经比单纯 Schema 强很多。

AI 知道了：

> “确认收入应该使用 `recognized_amount`。”

但生产环境还需要另外一半知识：

```text
invoice_amount 不能作为确认收入
total_amount 不能作为确认收入
received_amount 不能作为确认收入
```

我把这类信息称为**负向数据知识（Negative Data Knowledge）**。

正向知识告诉 AI：

> 应该怎么做。

负向知识告诉 AI：

> **哪些看起来合理的做法其实是错的。**

而后者恰恰是很多企业资深分析师最有价值的经验。

---

## 三、负向知识不只是“禁用字段”

不能简单建立一个字段黑名单。

因为：

```text
invoice.invoice_amount
```

用于“开票金额分析”完全正确，只是在“确认收入分析”中错误。

因此，真正需要描述的是：

```text
数据对象 + 业务意图 + 使用场景 → 是否允许
```

例如：

```yaml
field:
  table: invoice
  name: invoice_amount

business_term:
  开票金额

valid_for:
  - 开票分析
  - 应收分析

invalid_for:
  - 确认收入
  - 实际回款

reason:
  开票并不代表已经满足收入确认条件
```

这样，AI 获取的就不只是字段含义，而是**字段的业务使用边界**。

---

## 四、表关系更需要负向知识

企业智能问数中另一个高风险环节是多表关联。

例如系统存在：

```text
客户 → 订单
客户 → 账户 → 订单
```

从字段名称和值域看，两条路径都可能成立。

但在集团客户场景中，直接：

```text
客户 → 订单
```

可能造成子账户订单重复计算，真正允许的路径是：

```text
客户 → 账户 → 订单
```

这时系统需要的不只是“发现了哪些关系”，还应该维护：

```yaml
relationship:
  source: 客户
  target: 订单

context:
  account_type: 集团客户

invalid_path:
  - 客户
  - 订单

required_path:
  - 客户
  - 账户
  - 订单

reason:
  直接关联会造成子账户订单重复计算
```

于是 AI 在生成 SQL 之前，就可以把错误路径排除。

这比 SQL 生成后再让另一个大模型判断“这条 Join 对不对”更加可靠。

---

## 五、检索逻辑也应该从“相关性”升级为“有效性”

现在很多 Text-to-SQL 系统使用 Embedding 检索相关字段。

传统逻辑近似于：

```text
最终排序 ≈ 语义相似度
```

但企业生产环境应该进一步变成：

```text
候选得分
=
语义相关性
+ 权威性
+ 可信度
- 使用约束
```

如果某字段明确：

```text
invalid_for = 确认收入
```

即使它的向量相似度达到 0.95，也应该被直接过滤或者大幅降权。

所以一个成熟的查询链路更应该是：

```text
用户问题
    ↓
识别业务意图
    ↓
召回候选数据
    ↓
匹配指标定义
    ↓
应用正向知识
    ↓
应用负向知识
    ↓
选择可信数据关系
    ↓
构造查询上下文
    ↓
大模型生成 SQL
    ↓
规则再次校验
    ↓
执行
```

这里最重要的变化是：

> **不要把所有“看起来相关”的数据全部交给大模型，然后期待模型自己判断。**

企业已经知道某条路径错误，就应该在模型推理之前排除。

---

## 六、企业真正需要沉淀的是“踩过的坑”

负向知识从哪里来？

最好的来源之一其实是历史问题。

例如某次报表收入虚高，最终发现：

```text
原因：
客户直接关联订单导致集团客户重复计算。

修复：
改为客户 → 账户 → 订单。
```

传统方式是修完 SQL，问题关闭。

但对于 AI 时代，更有价值的做法应该是继续沉淀：

```text
数据事故
   ↓
根因分析
   ↓
错误模式
   ↓
负向知识
   ↓
结构化约束
   ↓
未来查询自动规避
```

这样企业过去付出成本获得的经验，才真正变成 AI 可以复用的数据资产。

同样，向资深分析师调研时，与其问：

> “请把这 50 个字段都写一下描述。”

不如问：

> **“新人使用这组数据时，最容易犯的 5 个错误是什么？”**

往往得到的答案更有价值：

```text
这个字段不能当收入。
这两张表不能直接关联。
这个时间字段不能做财务统计。
这张旧表已经不能使用。
这里必须先去重再汇总。
```

这些才是 AI 很难仅靠 Schema 自己推理出来的企业知识。

---

## 七、AI 可读数据应该重新定义

因此，我认为未来所谓的 **AI-Readable Data（AI 可读数据）**，不能简单理解为“给字段增加 Description”。

更完整的定义应该是：

```text
AI 可读数据
=
业务含义
+
物理结构
+
数据关系
+
使用规则
+
负向知识
+
可信信息
```

也就是说，AI 不仅要知道：

> 这是什么？

还要知道：

> 怎么关联？  
> 什么场景可以使用？  
> 什么场景不能使用？  
> 哪些路径看起来合理但实际上错误？  
> 为什么这个定义和关系值得信任？

这才更接近一个资深数据分析师真正理解企业数据的方式。

---

## 总结

过去企业的数据模型主要是给开发人员、数据工程师和分析师使用的，人会自动补充大量没有写进数据库的经验。

AI 不具备这种组织记忆。

因此，企业数据要真正进入 AI 时代，不能只解决：

> **“让 AI 看见数据。”**

还要解决：

> **“让 AI 理解数据的使用边界。”**

很多时候，最有价值的企业数据知识并不是：

> “这个字段是什么意思。”

而是：

> **“这个字段千万不能这么用。”**

当这些隐藏在资深人员脑子里的经验能够被结构化、版本化，并在检索、关系选择、SQL 生成和校验过程中被持续复用时，企业数据才真正开始从“机器可读”走向“AI 可读”。