超越RAG：为什么AI需要语义层

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

考虑：

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

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

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

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

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

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

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

典型的RAG管道如下：

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

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

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的文档。它无法可靠地推断这些提及形成了特定的多跳关系。

图可以显式遍历：

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

语义相似性与关系不同。

1.3 实体歧义

"Acme"可能指：

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

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

1.4 无精确数值过滤

问：

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

这本质上是SQL：

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

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

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

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

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

向量 → 含义和非结构化文本
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
成分
管理资产
研究报告

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

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

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

这改变了本体的作用。它不再是静态文档，而是可以成为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
• apache/ossie on GitHub

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

一个简化的示例如下：

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亿美元，并且在最新研究报告中获得积极评价？"

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

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

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

9、更大的转变

企业AI大致这样演变：

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

RAG回答：

哪些文档是相关的？

图回答：

这些实体如何连接？

SQL回答：

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

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

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

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

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

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

原文链接：Beyond RAG: Why AI Systems Need a Semantic Layer

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