> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 超越RAG：为什么AI需要语义层
- URL: https://www.hubwiz.com/blog/beyond-rag-why-ai-systems-need-a-semantic-layer/
- Published: 2026-08-26T15:58:35.000Z
- Updated: 2026-08-26T15:58:35.000Z
- Description: 为什么仅靠RAG还不够——以及语义层如何帮助AI理解企业数据中的关系、指标和含义。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

大语言模型使企业数据问题的自然语言查询变得容易。但回答问题与**理解该问题在不同数据系统中的含义**是不同的。

考虑：

> ***"哪些ETF持有NVIDIA的战略合作伙伴公司，管理资产超过10亿美元，并且在最新研究报告中获得积极评价？"***

这听起来像一个问题。技术上，它包含几个：

- **NVIDIA → 战略合作伙伴 → ETF持有** → 关系遍历
- **管理资产 > 10亿美元** → 精确数值过滤
- **积极的最新研究** → 对非结构化文本的语义理解

还有一个更深层次的问题：*管理资产*在底层数据模型中到底意味着什么，哪个来源是权威的？

在AI系统能够正确回答之前，它需要理解数据及其**含义**。

这就是语义工程试图解决的问题。

## 1、RAG很强大，但它只解决了问题的一部分

典型的RAG管道如下：

![基础RAG管道](https://www.hubwiz.com/blog/content/images/2026/08/1-b8292ZUTtfnA94lpEKQong.png)

当任务本质上是：**查找相关文本并从中回答**时，这种方法效果非常好。

但企业查询通常需要的不仅仅是语义相似性。

![为什么纯向量RAG不够](https://www.hubwiz.com/blog/content/images/2026/08/1-W5LQeta4EWzS8azY94aq5w.png)

### 1.1 碎片化检索

想象一个产品手册分成三个块：

```
块1：Atlas Enterprise — 供应商、类别
块2：定价 — 基础费用、使用费
块3：风险 — 锁定、迁移、数据驻留

```

问：*"Atlas Enterprise的定价和风险是什么？"*

产品名称可能只存在于块1中。块2和块3包含答案，但在分块后丢失了实体上下文。

元数据丰富、父子检索或重新排序可以帮助，但碎片化仍然是一个根本性的检索问题。

### 1.2 无关系遍历

现在问：

> ***"哪些ETF持有NVIDIA的战略合作伙伴公司？"***

推理路径不是单个关键词匹配：

```
NVIDIA
   ↓ HAS_STRATEGIC_PARTNER
公司
   ↓ HELD_BY
ETF

```

向量搜索可以找到提及NVIDIA、其合作伙伴或ETF的文档。**它无法可靠地推断这些提及形成了特定的多跳关系。**

图可以显式遍历：

```sparql
?nvidia corp:hasStrategicPartner ?company .
?etf etf:hasConstituent ?company .

```

**语义相似性与关系不同。**

### 1.3 实体歧义

"Acme"可能指：

```
NVIDIA     → 公司
NVIDIA International  → 子公司
NVIDIA AI Enterprise    → 产品

```

它们的嵌入可能接近，但它们是不同类型的实体。本体为系统提供**身份、类型和关系**，而不仅仅是文本相似性。

### 1.4 无精确数值过滤

问：

> ***"查找年收入超过100万美元且流失概率低于5%的客户。"***

这本质上是SQL：

```sql
SELECT customer_id
FROM customer_metrics
WHERE annual_revenue > 1000000
  AND churn_probability < 0.05;

```

嵌入理解相似性。它们无法可靠地实现 >、<、`BETWEEN`、聚合或排名。

## 2、一个问题需要多个引擎

我们最初的问题需要几种检索策略：

![一个问题，多个引擎](https://www.hubwiz.com/blog/content/images/2026/08/1-xr7g36b7TAQkpDK9hnfg5Q.png)

每个引擎擅长不同类型的推理：

```
向量 → 含义和非结构化文本
BM25   → 精确词汇匹配
图  → 关系和多跳遍历
SQL    → 过滤、数字和聚合

```

所以问题不再仅仅是**检索**。它变成了**联邦查询执行**。

而**联邦引入了三个更难的问题。**

## 3、真正的挑战：分解、路由和映射

### 3.1 分解

**系统必须将一个自然语言问题转化为可执行单元：**

```
1. 将NVIDIA解析为公司
2. 查找其战略合作伙伴
3. 查找持有这些公司的ETF
4. 过滤管理资产 > 10亿美元
5. 检索最新的研究报告
6. 识别积极观点

```

### 3.2 路由

每个单元必须发送到权威来源：

```
关系 → 图
管理资产           → SQL
研究观点 → 向量搜索

```

简单连接数据库是不够的。系统必须知道**哪个来源应该回答问题的哪个部分**。

### 3.3 映射

这通常是最难的部分。用户说*管理资产*。数据库可能包含以下字段：

```
NET_ASSET_AMT
AUM_USD
FUND_NET_ASSET

```

哪个字段代表受治理的概念？

同样，*ETF*可能映射到图中的`fund:ETF`、SQL中的`dim_fund.fund_id`和向量索引中的`metadata.product_id`。

系统需要**业务语言和物理模式之间的映射**。

这就是**模式锚定**。没有它，LLM可以使用甚至不存在的列生成完全合理的SQL。

## 4、语义层登场

语义层位于**人类意图**和**数据存储方式**之间。

我们不是将数百个原始表和属性直接暴露给LLM，而是暴露诸如：

```
公司
战略合作伙伴
ETF
成分
管理资产
研究报告

```

等概念，并为其附加含义：

```
管理资产
 ├─ 业务定义
 ├─ 货币/单位
 ├─ 生效日期
 ├─ 权威来源
 └─ 物理列

```

然后语义层可以直接参与查询生命周期：

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-tRr08qFcPdBFiVg38ScxDw.png)

这改变了本体的作用。它不再是静态文档，而是可以成为**AI系统的可执行上下文**。

## 5、实际上是什么样的？

对于结合关系数据库、知识图谱和向量搜索的系统，语义层可以这样组织：

```
semantic_layer/
├── ontology/
│   ├── tbox.ttl              # 类和关系
│   └── vocabulary.yaml       # 业务术语和同义词
├── schemas/
│   ├── rdb.yaml              # 表、列、类型
│   ├── graph.yaml            # 实体、谓词、图路径
│   └── vector.yaml           # 索引和文档元数据
├── semantics/
│   ├── metrics.yaml          # 受治理的指标，如管理资产
│   ├── mappings.yaml         # 概念 → 物理源映射
│   └── relationships.yaml    # 跨领域关系
├── query/
│   ├── routing.yaml          # 图 vs SQL vs 向量路由
│   └── examples.yaml         # 代表性查询计划
└── validation/
    └── rules.yaml            # 允许的字段和业务规则

```

例如：

- `tbox.ttl`定义诸如`Company`、`ETF`和`HAS_STRATEGIC_PARTNER`等概念
- `rdb.yaml`描述实际的表和列
- `mappings.yaml`将诸如`管理资产`等概念连接到`fund_metrics.net_asset_amt`
- `routing.yaml`告诉规划器操作属于图、SQL还是向量搜索

确切的文件是特定于实现的。关键思想是显式编码**含义、物理映射和有效执行路径**，而不是要求LLM为每个查询重新发现它们。

它有助于四项关键任务：

- **消歧：** NVIDIA公司和同名产品是不同的实体类别。
- **路由：** 合作伙伴/持有关系来自图；管理资产来自数据仓库。
- **模式锚定：** `管理资产 → fund_metrics.net_asset_amt`。
- **多跳推理：** NVIDIA → 战略合作伙伴 → ETF。

这就是为什么我认为语义工程比简单地"构建本体"更广泛。

它是关于通过词汇表、本体、指标、关系、模式映射、业务规则、源元数据和验证规则使业务含义**可操作**。

从这个意义上说，语义层开始看起来不像词汇表，而更像**企业数据的编译器层**。

## 6、从语义层到语义运行时

今天的许多代理架构大致如下：

```
用户 → LLM → 工具

```

LLM接收工具描述并弄清楚要调用什么。

语义架构可以更受约束：

```
用户
 ↓
语义解析
 ↓
逻辑查询计划
 ↓
已验证的执行
 ↓
证据
 ↓
LLM

```

LLM不再需要神奇地理解每个表、指标、图谓词和业务规则。它在受控的语义环境中进行推理。

目标不仅仅是更智能的模型。它是**模型和企业数据之间更智能的接口**。

## 7、为什么开放语义交换很重要

还有另一个问题：语义定义本身是碎片化的。

公司可能在其数据平台、BI工具、目录、分析应用程序和AI代理中分别定义**净收入**。随着时间的推移，这些定义会漂移。

\*\*开放语义交换（OSI）**就是为了解决这个互操作性问题而创建的。2026年6月，该计划进入Apache孵化器，现在作为**Apache Ossie（孵化中）\*\*进行开发。

- [Apache Ossie](https://ossie.apache.org/?ref=hubwiz.com)
- [apache/ossie on GitHub](https://github.com/apache/ossie?ref=hubwiz.com)

目标是提供一种供应商中立的方式来跨系统交换语义元数据。Ossie当前的核心规范基于YAML，描述**数据集、字段、关系、指标和AI上下文**。

一个简化的示例如下：

```yaml
version: "0.2.0.dev0"
semantic_model:
  - name: investment_products
    datasets:
      - name: etf
        source: analytics.dim_etf
        fields:
          - name: aum
            datatype: Decimal
            ai_context:
              synonyms: ["assets under management", "net assets"]
    metrics:
      - name: total_aum
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: SUM(etf.aum)

```

重要的部分不是YAML语法本身。`aum`的定义——包括其物理源、数据类型、指标逻辑和AI面向的同义词——变成了可移植的元数据，而不是在每个工具中独立重新定义。

概念上：

```
┌→ BI
                  ├→ 分析
语义模型 ───┼→ AI代理
                  ├→ 数据目录
                  └→ 数据应用程序

```

例如，数据目录可以暴露`AUM`的受治理定义和沿袭，而AI代理可以使用相同的语义元数据将短语"管理资产"映射到正确的字段，而不是从原始模式中猜测。

**Apache Ossie还支持针对JSON Schema的验证、多种表达式方言，以及用于在供应商格式之间转换的转换器模型**。其路线图扩展到高级指标、可组合性、目录集成、更丰富的关系语义和本体表示。

**本体表示**方向对AI特别有趣。仅靠指标和维度无法告诉代理：

```
客户是组织
公司 HAS_SUBSIDIARY 公司
公司 OWNS_PRODUCT 产品
文档 DESCRIBES 实体

```

如果语义模型和更丰富的本体表示融合，AI系统可以接收可移植的**业务含义**，而不仅仅是可移植的模式。

## 8、综合起来

回到我们的问题：

> ***"哪些ETF持有NVIDIA的战略合作伙伴公司，管理资产超过10亿美元，并且在最新研究报告中获得积极评价？"***

语义查询系统可以将其处理为：

![NVIDIA端到端示例](https://www.hubwiz.com/blog/content/images/2026/08/1-S2zJAvJrEUoWHtCwWOLRog.png)

没有语义层，LLM必须在每一步推断含义、来源、模式和关系。一个错误的假设可能会破坏整个链条。

有了语义层，这些决策可以锚定在显式元数据中。

## 9、更大的转变

企业AI大致这样演变：

```
LLM + 提示
     ↓
LLM + RAG
     ↓
LLM + 工具
     ↓
LLM + 联邦数据
     ↓
语义层 + 联邦执行 + LLM

```

RAG回答：

> ***哪些文档是相关的？***

图回答：

> ***这些实体如何连接？***

SQL回答：

> ***哪些记录满足这些精确条件？***

语义层回答在所有这些问题之前的问题：

> ***用户的问题用我们的数据语言意味着什么？***

这就是为什么语义工程很重要。

随着AI系统获得更多数据库、图谱、文档、API和工具的访问权限，仅仅连接更多数据是不够的。我们还需要连接其含义。

企业AI的未来可能不那么依赖于给予LLM访问**更多数据**，而更多依赖于给予它对**数据含义**的可靠理解。

---

原文链接：[Beyond RAG: Why AI Systems Need a Semantic Layer](https://medium.com/@kimdoil1211/beyond-rag-why-ai-systems-need-a-semantic-layer-9b6fa92e9bf6?ref=hubwiz.com)

汇智网翻译整理，请转载文章时标明出处