Palantir与本体论 · 番外五：两种建模——斯坦福七步法vs Palantir式建模

在讨论建模方法之前，需要先说清楚一个前提：学术界说的"本体"和Palantir说的"本体"，严格来讲不是同一个东西。

学术界的定义来自Tom Gruber 1993年的经典论述：本体是"对概念化的一个显式规约"——对某个领域中被认为存在的对象、概念及其关系的形式化描述（Gruber, Knowledge Acquisition, 1993）。这个定义下的本体是一种“知识表示工具”——它的目标是准确描述一个领域的概念结构，让不同系统能够基于共同的语义进行互操作。语义网时代的OWL、RDF、SPARQL都是在这个定义下发展出来的技术标准。

Palantir说的本体是另一个东西。Palantir官方架构文档的表述是：ontology的设计目标是"表示企业的复杂、互相关联的决策，而不仅仅是数据"，它需要实现"数据、逻辑、行动和安全的四重整合"（Palantir, "The Ontology system"）。这不是一个知识表示工具，而是一个“可执行的业务操作系统”。

两者的关系可以这样理解：Gruber定义的本体是"描述世界的模型"，Palantir的本体是"在世界中行动的系统"。前者回答"这个领域里有什么"，后者回答"基于对这个领域的理解，系统应该做什么"。有研究者将这一演变概括为四个阶段：从AI研究中的知识表示工具，到语义网标准，再到暴露出"静态知识无法支撑动态运营"的局限，最终由Palantir引入了"可执行的本体"这一新范式（参见Pebblous, "Shifting the Enterprise Ontology Paradigm", 2025）。

斯坦福七步法是在Gruber定义下发展出来的建模方法论。Palantir在实践中走出了另一条路。把两者放在一起对比，不是为了说谁对谁错，而是要说清楚它们解决的是不同层次的问题。

斯坦福七步法：学术界的经典指南

先简单介绍一下斯坦福七步法。它由斯坦福大学医学院的Noy和McGuinness在2001年提出（"Ontology Development 101"），是目前学术界最被广泛引用的本体建模入门方法论。七个步骤依次是：确定领域与范围、复用现有本体、列举核心术语、定义类与层级、定义属性、定义属性约束、创建实例。

整个流程的逻辑很清晰：先想清楚你要建模的领域有多大，再把这个领域里的概念全部收集起来，然后按分类学的方式组织成树状结构，最后给每个类定义属性和约束。它的产出物是一套形式化的概念模型——用OWL或RDF写成的本体文件，可以被推理机处理。

这套方法在学术研究、生物医学、语义网等领域被验证过无数次，是成熟的、有效的。但当我们拿它跟Palantir的实践放在一起看，会发现两者在几乎每一个维度上都走了不同的路。

起点不同：从术语开始，还是从决策开始

斯坦福七步法的起点是"确定领域与范围"，然后"列举核心术语"——把脑子里关于这个领域的所有名词、动词都写下来，再整理成分类体系。红酒、葡萄、酿酒厂、产地、颜色、价格、口感、单宁……全都列出来。这是一个发散过程，从"这个领域有什么"开始。

Palantir式建模的起点是"你要做什么决策、你现在看不见什么"。番外四讲过，第一步不是列举术语，而是找到业务决策者问三个问题：你做的最关键的决策是什么？做这些决策时需要看到什么？你现在看不到什么？这是一个收敛过程，从"你要解决什么问题"开始。

斯坦福的第三步在做加法——尽量多地收集原材料。Palantir的第三步在做减法——用奥卡姆剃刀砍掉一切跟决策无关的东西。方向完全相反。前者在办公室里推演"世界应该是怎样的"，后者在现场追问"现在的瓶颈在哪里"。

建模方向不同：分类树，还是因果链

斯坦福七步法第四步是"定义类与层级"——建一棵分类树。先定义最通用的概念（食品），再细分（酒→红酒→赤霞珠）。它提供了三种策略：自顶向下、自底向上、混合法。但不管哪种，核心动作都是在做分类——把事物归入正确的类别。

Palantir式建模不建分类树。它从一个具体的决策问题出发——"这条产线良率为什么下降"——倒推出支撑这个决策需要的实体和关系：工序、设备、物料批次、维保记录、传感器读数。这些实体之间的关系不是"谁是谁的子类"，而是"谁影响了谁""谁触发了谁"。

分类学关心的是"这个东西属于哪个类别"。Palantir关心的是"这个东西跟我的决策之间有没有因果关系"。一个在画族谱，一个在画作战地图。

对"完整性"的态度不同：穷尽，还是够用

斯坦福七步法隐含一个倾向：本体应该尽可能完整地覆盖领域。它的第二步甚至鼓励你去复用已有的标准本体——FOAF、Dublin Core、Schema.org——把通用概念都纳入进来。它还特别提到"不要重复造轮子"是本体工程的第一条铁律。

Palantir式建模的态度相反：够用就行，多了反而有害。第五篇讲过，全量建模是对数据缺乏判断的表现。车间温度、操作员工龄、当天星期几——这些数据不是不存在，但对"蚀刻工序良率下降"这个决策来说不构成因果变量。留着它们不是信息量变大了，是信噪比变低了。

牛顿没有试图把苹果的所有属性都塞进方程，他只保留了质量。好的ontology同理。圣埃克苏佩里说过，完美不是无可增添，而是无可删减。这句话用来描述Palantir的本体建模哲学再合适不过——好的ontology不是实体越多越好，而是留下来的每一个都不可或缺。

而且这不只是设计美学的问题，还有实际的维护成本。每多一个实体、多一条关系，就多了一份需要持续治理的负担——确保数据源在更新、确保定义没有漂移、确保跟其他实体的关系仍然成立。那些利用率极低的实体和关系，就是系统里的"模型负债"，日积月累会拖慢整个ontology的迭代速度。

对"执行"的态度不同：停在定义，还是必须能跑

斯坦福七步法的七个步骤全部集中在"定义"层面——定义类、定义属性、定义约束、创建实例。它教你怎么把本体"建好"，但不涉及建好之后数据怎么流进来、怎么触发业务动作、怎么写回源系统。

用第七篇的框架来说，斯坦福七步法只覆盖了语义层（Semantic Layer）。动力层（Kinetic Layer）和动态层（Dynamic Layer）完全不在它的讨论范围内。按第七篇的三个检验问题——语义定义是否连接了实际数据源？系统能否触发业务动作？动作结果能否写回源系统？——斯坦福七步法建出来的本体，三条都不满足。

而且"写回"（Write-back）不仅是执行层面的能力要求，它还会反向约束建模本身。在Palantir的逻辑里，如果一个属性不能支撑某个动作的判定，或者不接受业务操作的反馈修改，这个属性在建模时就应该被砍掉。建模不仅是为了"看"，更是为了"改"——不能被操作的属性，连被定义的资格都没有。

这不是说它没有价值。作为学术研究和知识组织的工具，它是成熟的、有效的。但如果你的目标是建一个能驱动业务决策和执行的ontology，只学斯坦福七步法是不够的——你建出来的东西很可能是第七篇说的"数字盆景"。

谁来建：专家在办公室，还是工程师在现场

斯坦福七步法假设建模者是领域专家——一个对该领域有深入了解的人，坐在电脑前，用Protege这样的工具画类、画属性、画关系。建模过程是离线的、个人的、一次性的。

Palantir式建模假设建模者是FDE——一个同时懂技术和懂业务的人，驻扎在客户现场，通过苏格拉底式追问从业务专家那里提取内隐知识，然后当场变成可运行的系统。建模过程是在线的、协作的、持续迭代的。第六篇讲过，这两种人的交付物完全不同：一个交付文档和模型文件，一个交付可运行的业务操作系统。

两种认识论

两种方法论的差异不是技术层面的，是认识论层面的。

斯坦福七步法背后的假设是：领域有一个相对客观的知识结构，我们的任务是尽可能准确地把它描述出来。本体是现实的映射——建得越完整、越精确越好。

Palantir式建模背后的假设是：现实是混沌的，没有一个预设的"正确结构"等着你去发现。你必须根据当前的决策需求，主动构建一种看待现实的方式。本体是认知的工具——能支撑决策、能驱动行动就够了。

这跟第三篇给出的判断完全一致：Palantir的ontology不是数字孪生，是认知眼镜。

斯坦福七步法在造镜子——尽量忠实地反映现实。Palantir在配眼镜——帮你看清楚你需要看清楚的东西。两者都有价值，但解决的是不同的问题。搞清楚你要的是镜子还是眼镜，比选择哪种建模方法论重要得多。

---

参考资料：

1. Tom Gruber, "A Translation Approach to Portable Ontology Specifications", Knowledge Acquisition, 5(2):199-220, 1993

2. Palantir, "The Ontology system", palantir.com/docs/foundry/architecture-center/ontology-system

3. Pebblous, "What Is Palantir Ontology? — 5 Key Differences from Classic Ontology", 2025

4. Noy, N. F. & McGuinness, D. L., "Ontology Development 101: A Guide to Creating Your First Ontology", Stanford University, 2001