最近读到一篇文章——《Palantir 的“本体论”骗局》。

文章写得很痛快。它把 Palantir 近年来反复强调的 Ontology 拆开来看：

Object Type、Property、Link、Action。

然后给出一个数据库工程师几乎无法拒绝的翻译：

于是，一个颇有杀伤力的问题出现了：

如果所谓 Ontology 最后不过是表、字段、外键和存储过程，那么 Palantir 究竟发明了什么？

这个问题值得问。

但如果因此得出结论——Ontology 不过是数据库 Schema 换了一套昂贵的名字——事情可能又走向了另一个极端。

真正值得讨论的，不是 Palantir 是否发明了 Ontology。答案显然是否定的。

真正有意思的问题是：

为什么一个几十年前就存在的概念，会在 AI 时代重新变得重要？

Ontology 的确被过度包装了

Palantir 并没有发明“实体—属性—关系”。

Object、Property、Link 这些概念，在计算机科学里都有非常悠久的历史。

关系数据库有 Table、Column、Foreign Key；

面向对象有 Class、Property、Association；

ER Model 有 Entity、Attribute、Relationship；

知识图谱有 Node、Edge、Property。

因此，当我们看到：

Equipment

Property: Name

Property: Model

Link: InstalledIn

Link: MaintainedBy

很容易把它翻译成：

CREATE TABLE Equipment (
    id BIGINT PRIMARY KEY,
    name VARCHAR(200),
    model VARCHAR(200),
    plant_id BIGINT
);

从这个角度说，对 Ontology 保持警惕是必要的。

如果一家厂商只是把原来的数据模型重新画成几个漂亮的圆圈和箭头，再把 Entity 改名为 Object、Relationship 改名为 Link，然后告诉客户这是一次“本体驱动的数字化转型”，那么这确实更接近营销创新，而不是技术创新。

问题在于：

相似，不意味着相同。

Schema 描述数据，Ontology 试图描述世界

数据库 Schema 主要回答一个问题：

数据应该怎样存？

例如：

然后通过外键告诉数据库：

Equipment.PlantID → Plant.ID

这是一个非常好的数据结构。

但 Ontology 想回答的问题稍有不同：

这些东西究竟是什么？它们之间存在什么意义上的关系？

例如：

CentrifugalPump IS-A Pump
Pump IS-A Equipment

SafetyValve IS-A Valve
Valve IS-A Equipment

Pump INSTALLED-IN System
Pump HAS-PART Impeller

Equipment HAS-FAILURE-MODE FailureMode
FailureMode MITIGATED-BY MaintenanceStrategy

如果我们进一步定义：

P101 IS-A CentrifugalPump

那么一个具有形式语义和推理能力的 Ontology 可以得到：

P101 IS-A Pump
P101 IS-A Equipment

数据库当然也可以实现这些事情。

可以增加表，可以增加字段，可以写 SQL，可以写存储过程。

但这恰好说明了二者之间真正的区别：

数据库首先是一种数据组织机制，而 Ontology 首先是一种语义表达机制。

W3C 的 OWL 体系之所以不仅包含 Class 和 Property，还包含 Individual、Axiom 和 Reasoning，就是因为传统 Ontology 关心的不只是“有什么字段”，而是：

这个领域中的事物是什么，以及我们能够从已有事实推导出什么新的事实。

因此，把 Ontology 与 Schema 说成“严格同构”，并不准确。

它们大量重叠，却并不是同一个东西。

企业真正困难的，从来不是 CREATE TABLE

想象一家大型工业企业。

SAP 里面有：

Functional Location
Equipment
Work Order
Material

设备管理系统里面有：

Asset
Device
Maintenance Task
Spare Part

工程设计系统里面有：

Tag
Component
System
Document

IoT 平台里面又有：

Device
Sensor
Point
TimeSeries

知识管理平台里面可能还有：

Equipment
Document
Procedure
FailureMode
Requirement

任何一个有经验的数据库工程师，都可以在几小时内设计出一张 Equipment 表。

真正困难的问题却是：

SAP 的 Equipment、EAM 的 Asset、工程系统里的 Tag、IoT 的 Device，以及知识库里的 Equipment，到底是不是“同一个东西”？

这已经不是 CREATE TABLE 能回答的问题了。

因为企业里的数据从来不是为了一个统一世界设计出来的。

每个系统都有自己的历史。

自己的组织边界。

自己的业务语言。

自己的数据模型。

自己的权限体系。

甚至有自己对“设备”两个字的理解。

于是我们逐渐发现，大型企业缺少的往往并不是数据库，而是一个共同的世界模型。可以把它理解成：

Ontology 真正试图建立的，是这样一层稳定的企业语义。

Palantir 真正卖的，也不是“本体论”

因此，我并不认为 Palantir 最值得研究的地方是 Object、Property 和 Link。

这些东西没有什么神秘之处。

真正值得研究的是，它试图把很多过去彼此分离的东西连接起来：

这已经超过了传统意义上的 Ontology。

一个 Aircraft 不只是：

Aircraft
- TailNumber
- Location
- FuelLevel

它还可以：

assignedTo → Flight

甚至拥有：

Assign Aircraft
Ground Aircraft
Schedule Maintenance

这样的 Action。

到了这里，我们面对的其实已经不是一个纯粹的知识本体。它更接近：

Domain Model + Semantic Layer + Business Logic + Authorization + Workflow + API

这可能也是理解 Palantir Ontology 最好的方式。

Palantir 并没有发明“对象”。

它真正试图产品化的是： 一个企业的 Operational Semantic Layer——可运行的企业语义层。

概念并不新，工程却非常难

这是讨论 Palantir 时很容易陷入的误区。

一种技术思想不是新的，并不意味着把它做成产品很容易。

Linux 没有发明进程。

Kubernetes 没有发明容器。

Snowflake 没有发明 SQL。

Databricks 没有发明数据分析。

Palantir 同样没有发明 Entity、Relationship 或 Ontology。

但真正的工程价值，经常并不来自发明一个新的名词，而来自：把几十个已经存在的概念组合成一个真正能够运行的系统。

几十行 SQL 确实可以建立一个 Schema。

但几十行 SQL 无法自动解决：

数据从哪里来？

谁拥有这些数据？

两个系统中的 Equipment 如何映射？

字段含义发生变化怎么办？

历史数据如何追踪？

权限如何继承？

业务动作如何审计？

一个 Action 修改 SAP 的同时是否需要修改 EAM？

AI Agent 能看到哪些对象？

它可以读取哪些属性？

又允许执行哪些操作？

当问题来到这个层次，“这不就是几张表吗”开始变得没有那么重要。因为真正昂贵的从来不是表。真正昂贵的是组织复杂性。

LLM的出现

如果故事停留在 BI 时代，我对 Ontology 的兴趣可能不会这么大。

传统 BI 的世界大致是：

User
 ↓
Dashboard
 ↓
SQL
 ↓
Database

人类最终面对的是一个 Dashboard。Dashboard 已经替用户消化了数据库背后的复杂性。

但 AI Agent 改变了这个结构。我们开始希望 AI 能理解这样的指令：

找出最近一个月故障超过三次的泵，检查这些设备是否存在尚未关闭的维修工单，如果存在高风险设备，通知相应设备负责人。

这句话对于人来说很自然。但对于机器来说，它背后隐藏着一个世界：

Pump
Failure
WorkOrder
Employee
Department

以及：

hasFailure
targets
responsibleFor
belongsTo

最后还有：

Action:
Notify
CreateWorkOrder
AssignOwner

如果没有统一语义层，Agent 面对的真实世界可能是：

然后我们期待 LLM 自己搞明白所有东西。这是一种危险的乐观主义。

Ontology 正在从“给人理解数据”变成“给机器理解企业”

这可能是 AI 时代 Ontology 最值得重新审视的地方。过去建立企业数据模型，主要是为了：

Human → Data

今天，我们越来越需要解决：

AI → Enterprise

AI 必须知道：

什么是设备？

什么是合同？

什么是供应商？

什么是员工？

什么是工作票？

什么是缺陷？

谁负责什么？

谁有权访问什么？

哪些动作可以执行？

哪些动作必须经过审批？

这实际上需要一个机器能够理解的企业世界模型。于是 Ontology 的位置开始发生变化：

数据库仍然存在。API 仍然存在。ERP 仍然存在。数据仓库仍然存在。但在它们和 AI 之间，多了一层东西：

企业语义。

这也是为什么我认为 Ontology 并没有因为 LLM 出现而过时。恰恰相反。LLM 可能第一次让企业 Ontology 从一个略显学院派的数据治理概念，变成真正具有业务价值的基础设施。

RAG 解决“哪段文字相关”，Ontology 解决“这些东西是什么关系”

这个区别在企业知识系统中尤其明显。过去几年，我们已经非常习惯 RAG：

它非常有效。但它主要解决的是：哪段文字与我的问题比较相关？

Ontology 解决的是另一个问题：这些知识在业务世界里是什么关系？

例如一个工业知识体系可能是：

这时，当用户问：P101 泵最近出现振动异常，应该参考哪些规程？

系统不只是去寻找“P101”“振动”“规程”几个词在向量空间里的邻居。它可以沿着业务世界本身去寻找：

RAG 找的是相似性。Ontology 描述的是关系性。二者并不互相替代。在复杂企业 AI 中，它们反而很可能最终汇合。

真正应该警惕的不是 Ontology，而是“Ontology PPT”

所以，我赞成对 Ontology 的营销保持警惕。但判断一个企业 Ontology 项目是不是骗局，我会使用另一套标准。

不要问：有没有 Object、Property、Link？

而应该问：能不能真正解决跨系统的语义映射？

继续问：

SAP Equipment 与 IoT Device 是如何映射的？

同一个业务对象存在多个 Source of Truth 怎么办？

Ontology 如何版本化？

Schema 演化以后如何处理？

数据血缘在哪里？

Object-level Permission 如何实现？

行级和属性级权限怎么办？

Action 如何授权？

AI Agent 能执行哪些 Action？

每一次执行能不能审计？

Ontology 是否绑定特定厂商？

能不能导出？

能不能使用开放标准表达？

如果这些问题都没有答案，而 PPT 上只有：

Customer
   ↓
Order
   ↓
Product

那么，无论它叫：**Ontology、Knowledge Graph、Semantic Layer、Digital Twin，还是 Enterprise Brain，**都值得保持警惕。

Ontology 的下一站，也许不是知识图谱，而是 Agent

过去谈 Ontology，我们想到的通常是 Semantic Web、OWL、RDF、Knowledge Graph。

今天，这个概念正在获得一个新的出口：

Agent。

因为 Agent 与传统软件最大的不同，是它需要自己理解环境。

传统程序里：

get_equipment(id)

函数已经告诉程序：这是 Equipment。

而 Agent 收到的是：“看看三号机组最近有没有值得注意的设备问题。”

它必须自己理解：

什么叫机组？

什么叫设备？

什么叫问题？

“最近”是多少天？

“值得注意”由什么规则定义？

去哪里查？

需要哪些权限？

查到以后能做什么？

从这个角度看，Ontology 很可能成为未来 Enterprise Agent 的一部分“世界模型”。

可以把未来企业 AI 的基础架构简单写成：

这样再回头看 Palantir，事情就变得有意思了。

它真正的野心可能从来不是重新发明数据库。

而是希望成为：

AI 与真实企业之间的那一层。

Ontology 到底是不是骗局？

我的答案是：不是。

但围绕 Ontology 的营销，当然可能是。

说 Palantir 发明了 Ontology，是夸大。把 Object、Property、Link 描述成一种革命性的计算机科学突破，也是夸大。

但反过来说：Ontology 就是 Table + Column + Foreign Key。同样过度简化了问题。

更准确的说法应该是：Database Schema 描述数据如何组织；Ontology 描述业务世界如何被机器理解；Operational Ontology 则进一步描述这个世界可以发生什么。

三者大量重叠，却处在不同的抽象层次。

数据库回答：

What data do we have?

Ontology 回答：

What does it mean?

Operational Ontology 进一步回答：

What can we do with it?

而 Agent 最终要回答：

What should I do next?

这四个问题连接起来，可能正是下一代企业 AI 平台真正的技术骨架。

机器需要一张关于企业世界的地图

计算机发展的很长一段时间里，我们一直要求人适应机器。

我们设计数据库。

定义字段。

编写 API。

建立数据仓库。

制作 Dashboard。

然后培训员工理解这些系统。

LLM 改变了一件很微妙的事情：

我们第一次开始认真要求—— 机器来理解我们的世界。

但机器要理解一家拥有几十年历史、几百套系统、数万个业务概念的大型企业，仅靠语言模型的参数记忆是不够的。

它需要知道什么是设备。什么是组织。什么是合同。什么是标准。什么是责任。以及它们彼此之间如何连接。

它还需要知道：什么可以看，什么不能看；什么可以做，什么必须审批；什么只是知识，什么会真正改变现实世界。

我们当然可以把这些东西存在 PostgreSQL 里。也可以存在 Neo4j、OpenSearch、Milvus、对象存储或者任何未来出现的数据库里。但那已经不是最重要的问题。

地图用什么纸印刷，与地图描绘了怎样的世界，是两件不同的事情。

数据库是纸。Ontology 是地图。而 AI Agent，终于成为那个需要读懂这张地图的人。