> ## 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.

# 本体论 vs. 语义层
- URL: https://www.hubwiz.com/blog/ontology-vs-semantic-layer/
- Published: 2026-08-26T15:37:30.000Z
- Updated: 2026-08-26T15:37:30.000Z
- Description: 语义层回答"我们的收入是多少？"本体论回答"什么是客户？"
- Author: admin
- Tags: APPLICATION, #Import 2026-10-14 14:41

自我们推出OceanBase DataPilot以来，一个模式几乎在每个客户中都出现：同一个指标根据提问者的不同返回不同的数字。财务说收入是1020万。营销说1040万。Slack中的AI助手说是980万美元。三个数字，没有共识。

过去这是人的问题，人们可以在十分钟的会议中解决它。代理不会发消息给同事询问指标是如何定义的。当它遇到名为`rev_ttm_adj_v2`的列时，要么编造答案，要么采用它碰巧找到的第一个定义。

将建模的领域知识注入检索路径已被证明可以将幻觉率降低约40%——但前提是这些知识确实被建模在某处，而不是存在于构建表的三个人的头脑中。这就是为什么我们将上下文层视为OceanBase AI数据库架构的一等公民。您可以存储多少数据以及代理的能力如何都不重要：如果它们之间的一切都是原始表和SQL，业务将永远不信任输出。

## 1、上下文层

上下文层不是产品名称。它是将语义定义、领域知识、血缘、治理策略、质量信号和认证状态包装在一个接口后面的层，人类和代理都可以查询。

本体论和语义层是它的两个承重组件。供应商喜欢将它们合并为一个流行词，但它们解决不同的问题——以错误顺序构建它们的团队最终会得到演示精美但永远无法投入生产的AI项目。

## 2、一句话分工

**语义层回答"我们的收入是多少？"本体论回答"什么是客户？"**

语义层拥有指标：收入、MAU和LTV如何计算，要连接哪些表，应用哪些过滤器。它的工作是确保每个团队和每个工具以相同的方式计算它们。

本体论拥有含义：客户是什么，客户如何与订单相关，哪些规则使客户成为白金客户，以及机器是否可以从已有的事实中推导出新的结论。

## 3、本体论：概念、关系和推理

教科书定义——"共享概念化的显式形式规范"——归结为三个部分：

- **类**——领域中的事物类型（客户、产品、订单、地区）
- **属性和关系**——它们如何连接（客户*下*订单；产品*属于*类别）
- **公理和规则**——逻辑约束（每个订单包含至少一个产品；客户在任何给定时间恰好属于一个地区）

因为本体论是用W3C标准（如RDF和OWL）编写的，机器不仅仅可以阅读它们——它们可以对其进行推理。如果本体论说白金客户是年收入超过100万的客户，而事实说Acme的年收入是200万，引擎会自行得出结论Acme是白金客户。没有人编写if-else。这是语义层和BI工具无法做到的部分：它们执行您预先定义的计算，但它们从不推导您没有的事实。

本体论还协调跨系统的词汇。CRM称之为客户，ERP称之为客户，财务称之为账户——本体论将所有三个指向同一个业务对象。基于本体论的代理遍历连接的图，而不是在一堆不相关的表中猜测。医疗保健中的SNOMED CT和金融服务中的FIBO是规范的例子；在受监管的领域，形式本体论实际上是基本要求。

成本同样明确。Palantir将企业本体论变成了一个类别，但交付模式很重：前线工程师、手动建模、六到十八个月的完整构建，以及真正难以招聘的形式逻辑技能。

## 4、语义层：指标、逻辑和一致的数字

语义层来自更实用的工程传统。Business Objects在1990年代发布了"Universe"，将复杂模式隐藏在业务语言后面，它解决的问题至今没有改变：团队计算收入的方式不同，数字不一致，信任受到侵蚀。新的是影响范围。不一致的定义过去会产生尴尬的幻灯片；现在它们会在决策报告中产生幻觉数字。

现代语义层有四个部分：将`mrr_calc_v3`映射到"月度经常性收入"的**元数据存储库**；在一个地方保存指标公式、定义一次并在各处重用的**业务逻辑引擎**；生成连接和过滤器的**查询翻译**；以及一致地应用行级和列级权限的**访问控制**。

工具已经迅速成熟。dbt Semantic Layer with MetricFlow将指标作为YAML进行版本控制，并将其编译为多种SQL方言。Snowflake、Salesforce、dbt Labs和BlackRock于2025年9月推出了OSI（开放语义交换），v1.0于2026年1月发布，作为交换语义元数据的供应商中立标准。LookML、DAX、Cube、AtScale、Snowflake Semantic Views和Databricks Metric Views都在汇聚于同一个想法：语义层正在成为AI就绪数据堆栈中的标准基础设施。

它仍然有天花板。它可以准确告诉你收入是如何计算的。它不能告诉你客户如何与市场和监管框架相关，或者根据一组领域规则是否应该将账户标记为高风险。

正如Jessica Talisman在Metadata Weekly中所说：**语义层用于查找；本体论用于上下文和推理。**

### 5、只构建一个时会出什么问题

**仅语义层：准确但肤浅。**询问哪个渠道上个月推动了最高的GMV，您会得到一个精确的答案。询问为什么该渠道下降，或者是否应该增加其支出，您将一无所获。该层没有渠道、支出策略和客户档案如何相关的模型。

**仅本体论：精通概念，对数字无用。**询问Acme是否是白金客户，推理是完美的。询问Acme上个月的收入是多少，您又回到了三个答案，因为没有东西告诉系统查询哪个事实表或如何聚合它。

行业数据指向同一个方向。Gartner预计到2027年底，超过40%的代理AI项目将被取消，理由是成本、价值不明确和控制不足。在对248位数据管理领导者的调查中，63%表示他们缺乏支持AI所需的数据管理实践。这些失败大多不是关于选择错误的模型；而是关于没有语义基础的数据。

趋势的另一面同样明显。Gartner的2026年峰会预测，到2030年，通用语义层将与数据平台和网络安全一起成为关键基础设施，Futurum预计采用率将从2026年的16%增长到2031年的30%。Microsoft Fabric IQ正在预览本体论原生支持，Timbr.ai正在营销"具有推理能力的语义层"。两条路径正在合并。

## 6、知识图谱和分类法在哪里

**知识图谱**保存实例——实际的客户和实际的订单作为节点。本体论是模式；知识图谱是数据。当代理在运行时遍历关系时，它正在遍历图。

**分类法**是删除了困难部分的本体论：父子层次结构，没有推理，没有横向关系。产品目录、数据域分类和PII标记都从这里开始，这是一个合理的起点。只有当代理必须跨类别推理时，您才需要转向完整的本体论——"如果类别A降级，类别B的库存会受到影响吗？"

## 7、整合起来

我们将上下文层分为两部分：

- **数据上下文**——本体论、语义层、知识图谱、血缘、质量分数、访问策略。这告诉AI它正在什么样的业务中运营。
- **应用程序上下文**——用户偏好、对话历史、领域文档、检索的事实（记忆加上RAG）。这告诉AI它在与谁交谈。

在实践中，一个问题流经所有四个：

1. 本体论将"收入确认"定义为一个概念，以及附加到它的规则
2. 语义层将其转化为计算——要连接哪些表，如何聚合
3. 知识图谱将概念与其指标、血缘和下游消费者连接起来
4. MCP在推理时将该上下文传递给代理

过去两年上下文工程讨论产生的所有内容都得出相同的结论：可靠的输出需要结构化上下文，而本体论和语义层是最难正确获取的两个部分。MCP解决了传递问题。它对您传递的内容无能为力——将未治理的表和SQL交给代理，协议将忠实地传输幻觉。

## 8、我们构建了什么：OceanBase OSI

我们不是发布另一个BI语义层，而是将指标、定义、原始数据、上下文图和本体论统一到一个开放的语义栈中：**OceanBase OSI（开放语义交换）**。它有三个层。

- \*\*语义层（底部）。\*\*指标定义、计算规则和维度到数据映射。它建立在Ant-OSI标准之上，兼容行业OSI，并已在蚂蚁集团投入生产。
- \*\*上下文图（中间）。\*\*指标、对象、事件、血缘和消费者连接为一个网络。在这个图上推理的LLM确实比单独阅读表模式或YAML的LLM表现更好。
- \*\*本体论层（顶部）。\*\*与数据库语义对齐的业务语义。工作区本地术语和企业范围概念保持链接，同时按照自己的时间表演进。

所有三个层下面的原则是**语义即代码**：定义一次语义，然后让BI渲染仪表板、代理生成SQL、治理工具跟踪血缘——全部针对相同的定义。没有单独的BI、AI和治理语义。

在多个行业的客户POC中，DataPilot的自然语言到数据准确性远高于测量的替代方案。模型不是差异化因素——每个人都在调用相同的前沿LLM。差异化因素是语义上下文的质量。给代理准确的业务定义而不是原始表，NL到SQL的准确性会提高，这是任何提示调整都无法匹配的。

## 9、从哪里开始

**从语义层开始，如果：**

- 团队对"收入"或"活跃用户"的含义存在分歧
- 您正在构建对话分析或与数据聊天
- 您的数据堆栈已经集中，您希望在两到六个月内获得回报

**从本体论开始，如果：**

- 您处于金融、医疗保健或政府领域，合规要求严格
- 您的AI必须跨领域推理——客户×产品×法规
- 同一个概念在半打系统中名称不同
- 您需要自动分类或基于规则的异常检测

**对于大多数企业，务实的顺序是：**

1. 首先构建语义层。集中核心指标，以便BI和AI读取相同的定义。
2. 开始时保持本体论轻量——业务术语表，而不是完整的OWL建模工作。
3. 分层添加治理信号：血缘、质量分数、所有权、认证。
4. 通过MCP将其全部暴露给代理，这将把上下文层从图表变为基础设施。

dbt不会给你本体论。Palantir风格的本体论不适合每个团队。从术语表发展为形式本体论比试图一次性完成整个过程要现实得多。

## 10、下一步

**短期，**我们正在将OSI语义层推广到每个DataPilot工作区，指标以Ant-OSI格式集中管理，术语、指标和维度都可发现和搜索。

**中期，**我们正在强化OSI本体论层。业务术语表、类别层次结构和实体关系首先作为产品化的分类法发布，然后获得跨系统对齐和基本推理。这种增长是逐领域发生的，而不是自上而下。

**长期，**困难的问题是当独立建模其语义的领域需要合并时会发生什么。协调这些冲突——并保持本地和全局定义之间的关系可演进——是OSI上下文图要解决的问题。

---

原文链接：[Ontology vs. Semantic Layer: Why Your AI Agent Needs Both](https://medium.com/oceanbase-database/ontology-vs-semantic-layer-why-your-ai-agent-needs-both-a2e24c8060a1?ref=hubwiz.com)

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