Palantir与本体论（五）：拒绝全量建模的虚荣——选对范畴比建全模型重要

本系列的上一篇我们用牛顿力学做了一个类比：人类最成功的"数字孪生"不是靠1:1复刻，而是靠极其精准的抽象——苹果只剩下质量，却能预测一切运动。

道理讲完了，但落到企业场景里，很多人的第一反应还是"先把所有数据都建进来，以后总会有用的"。这个思路听起来稳妥，其实是一个代价极高的陷阱。

全量建模：对企业数据缺乏判断的表现

全量建模的诱惑在于它回避了一个最难的判断：什么是重要的，什么不是。把什么都建进来，本质上是把这个判断推迟了——"我先不判断，先存着再说"。

但推迟不等于消除。

一个供应链的ontology如果试图把所有能采集到的数据都建模为实体和属性——集装箱的容积、仓库的建筑面积、叉车的品牌型号——这些数据不是没有用，但对"三周后会不会断货"这个决策来说，它们不构成因果变量。真正决定断货风险的可能就三个东西：供应商交付周期、安全库存水位、需求波动规律。

把前者和后者不加区分地堆在一起，不是信息量变大了，是信噪比变低了。做决策的人面对一团密密麻麻的实体关系网络，反而看不出什么是重要的。

牛顿如果把苹果的颜色、甜度、产地全塞进方程，不是模型更精确了，而是根本推不出任何规律。这些属性跟力学现象之间没有因果关系，它们的存在只会制造噪音。

Palantir的建模路径：从决策倒推范畴

Palantir的做法不是从数据出发问"我有什么数据可以建模"，而是从决策出发问"要做这个决策，我需要看见什么"。

它进入一个客户，第一步不是接数据源。是跟业务决策者坐下来搞清楚几件事：你日常做的最关键的决策是什么？做这些决策时你需要看到什么？你现在看不到什么？

然后从这些决策倒推：要支撑这些决策，需要跟踪哪些实体？这些实体之间什么关系？哪些属性跟决策有因果关系，哪些只是噪音？

这在行业里太常见了。一个供应链数字化项目花半年建出一个"全量数据模型"，实体类型超过两百个。但一线调度员打开系统的时候说了一句话："我还是看不到我最想知道的东西——这批货到底能不能在客户要求的时间到。"两百个实体类型，没有一个直接回答这个问题。

用牛顿的类比来说：牛顿不是先把苹果的所有属性记录下来再从中"发现"质量是重要的。他是先有了一个问题——"为什么东西会落地"——然后判断出回答这个问题只需要质量和力。问题在先，范畴在后。

最小可用范畴：先跑起来，再迭代

Palantir的建模策略可以概括为"最小可用范畴"——不追求一步到位的完美框架，先用一套最精简的实体和关系把系统跑起来，让业务人员在实际使用中发现"还缺什么"，然后逐步补充。

这背后有一个认知上的诚实：你不可能在开始建模的时候就想清楚所有的实体和关系。很多重要的范畴是在系统跑起来之后、在实际决策过程中才被发现的。

上一篇讲的那个供应链例子：平时只需要"供应商—物料—订单"三个实体就能支撑日常决策。但地缘政治局势一变，"冲突区域""制裁名单"必须被纳入。这些新范畴不是一开始就能想到的——它们是在前提假设崩塌后、在新场景的压力下才浮现出来的。

好的ontology不是一开始就"全"的，而是一开始就"对"的——核心范畴选准了，系统能跑起来、能支撑决策，然后在使用中持续演进。

怎么判断范畴选没选对

标准回到上一篇的判断：这套范畴框架能不能支撑有效的预测和推演。

你的供应链ontology能不能预测三周后的库存水位？你的航空ontology能不能预测明天的航班延误风险？如果能，范畴选对了。如果不能，不要急着加更多数据——先问一个问题：是范畴本身选错了，还是前提假设变了？

这两个原因的应对方式完全不同。范畴选错了，要调整实体和关系的定义——可能你跟踪的那些东西跟决策之间没有因果关系。前提假设变了，要重构范畴框架本身——可能需要纳入全新的实体类型。

不要在错误的范畴上追求更高的精度，那是在错误的方向上做正确的事。

三个问题

所以当你准备建ontology的时候，不要先问"我有多少数据"。先问自己三个问题：

我要做什么决策？做这个决策我需要看见什么？我现在看不见什么？

从这三个问题出发，你的第一版ontology可能只有五六个实体类型。但如果选对了，它能比一个有五百个实体的"全量模型"更快地跑起来、更准确地支撑决策。

牛顿用三个概念孪生了力学世界，不是因为力学世界简单，而是因为他的抽象准确。