Palantir与本体论 · 番外四：从决策到本体——Palantir式建模的五步方法

这个系列写了九篇正文加三篇番外，从古希腊哲学讲到了AIP，从数字孪生讲到了FDE。但有一个问题一直被绕着走：拿到一个业务场景，具体怎么开始建ontology？

大家都在讲"本体论是什么""为什么重要"，没有人讲清楚"怎么做"。这篇试着把散落在前面各篇中的方法论碎片串起来，给出一个可操作的框架。

但在讲方法之前，有一个前提需要交代：Palantir这套建模方式不是在书斋里想出来的，是被现实逼出来的。2003年Palantir成立时，面对的是一个所有传统方法全部失效的场景——客户说不清自己想要什么，因为需求本身是机密的；市面上买不到现成的软件；传统咨询公司既不会写代码，也进不去最敏感的现场；标准的"销售—售前—交付"SaaS模式彻底走不通，因为你连客户的真问题都不知道。

这意味着Palantir从第一天起解决的就不是"已有工具能解决但解决得不够好"的问题，而是"所有已有方法都不适用"的问题。在这个前提下，才逼出了"从决策问题出发、驻扎现场、边做边建"这条路。下面讲的五步方法论，根基就在这里。

有意思的是，这个框架的前三步，分别对应三个经典的哲学方法论工具。不是强行贴标签——是真的对得上。

第一步：问题驱动——从决策开始，不从数据开始

亚里士多德说，哲学起源于"惊异"——对问题的困惑和追问。建模的起点也一样，不是"我有什么数据可以建模"，而是"我要做什么决策、我现在看不见什么"。

拿一个工厂产线场景来说。车间主任每天面对的关键决策可能是："这条产线的良率为什么突然从98%掉到了93%？""要不要停线检修？""如果不停线，风险有多大？"

不要从"我们有多少传感器数据"开始。从这几个决策问题开始。

第二步：苏格拉底式追问——把说不清楚的变成说得清楚的

苏格拉底有一套方法叫"助产术"——不直接给答案，通过不断追问，帮对方把已经隐含知道但说不清楚的东西"生"出来。

FDE在工厂车间做的就是这件事。工艺工程师知道良率为什么掉了，但你直接问他"你需要系统展示什么"，他说不清楚。FDE通过层层追问把它引出来：

"良率为什么掉了？"——"感觉是蚀刻工序出了问题。"

"你怎么判断是蚀刻？"——"颗粒读数最近偏高。"

"偏高多少算异常？"——"看工艺要求，亚纳米级的偏差就很敏感了。"

"颗粒数偏高可能是什么原因？"——"可能是冷却系统，也可能是上一批物料纯度不够，还有一种可能是上周那次维保之后参数没调回来。"

"你怎么排除这三种原因？"——"通常是一个一个查，先看维保记录，再看物料批次检验报告，最后看冷却系统的温度曲线。花半天到一天。"

每一轮追问都在做两件事：把模糊的直觉转化成精确的范畴定义，同时暴露出实体之间的关系链条。"蚀刻工序"是一个实体，"颗粒读数"是关键属性，"冷却系统"跟"工序"之间有关联关系，"维保记录"跟"设备参数"之间有因果关系，"物料批次"的"纯度"跟"良率"之间有因果关系。

这些东西工艺工程师全都知道——但它们藏在他二十年的经验和肌肉记忆里。苏格拉底追问的是"你以为你知道的东西你真的知道吗"，FDE追问的是"你脑子里的判断逻辑，系统里有没有"。

第三步：奥卡姆剃刀——如无必要，勿增实体

经过前两步，你手上会有一堆候选的实体、属性和关系。工厂场景尤其如此——现代产线上能采集的数据太多了：温度、湿度、振动频率、转速、压力、噪音、操作员工龄、当天星期几……全量建模的诱惑在这里最大。

奥卡姆剃刀的原话是"Entities should not be multiplied beyond necessity"——如无必要，勿增实体。

对每一个候选实体问一句：如果去掉它，我对良率下降的判断会受影响吗？

车间的湿度、操作员的工龄、当天是不是周一——这些数据不是不存在，但对"蚀刻工序良率下降"这个具体问题来说，它们大概率不构成因果变量。真正关键的可能就三个东西：蚀刻工序的颗粒读数、物料批次的纯度检验结果、上次维保后设备参数的变化。

砍掉其余几十个变量不是因为它们没用，而是在当前这个决策场景下它们不是必要的。牛顿把苹果砍到只剩质量——颜色、气味、品种全扔掉——但能预测一切运动。好的ontology同理：不是实体越多越好，而是留下来的每一个都跟决策有因果关系。

不过，奥卡姆剃刀不是一刀切。同一个变量在不同场景下的重要性不同——"车间湿度"对蚀刻工序可能不重要，但对光刻工序可能就是关键因素。范畴的取舍是场景驱动的，不是一劳永逸的。

还有一个容易踩的坑：不要把统计相关当成因果。"温度"和"良率"可能在数据上高度相关，但真正的因果链可能是"冷却剂压力下降→温度升高→颗粒沉积增加→良率下降"。你按温度建模，预测会非常脆弱——因为温度只是表象，冷却剂压力才是根因。所以砍变量的时候还要追问一层："我看到的这个东西，是原因还是原因的影响？"这跟第二步的苏格拉底追问是连续的——第二步问的是"你看什么"，第三步还要问"你看到的是本质还是表象"。

第四步：最小可用范畴——先跑起来再迭代

前三步做完，你的第一版ontology可能只有六七个实体类型——工序、设备、物料批次、维保记录、传感器读数、品质检测结果——加上十几条关系和几条核心规则（"颗粒读数超过阈值→触发异常预警""维保后需要校验参数复位"）。

不要觉得少。先让它跑起来——接入真实的产线数据、能在良率下降时自动关联可能的原因、能触发至少一个预警动作。然后让工艺工程师用起来。

他们在使用中会告诉你还缺什么——"我还想看到同一设备在不同班次的表现差异""能不能把上游供应商的来料检验数据也接进来"。这些反馈就是迭代的方向。

Palantir内部的说法是：FDE先铺一条土路让车能跑起来，然后产品团队再把它变成高速公路。先能用，再完美。

而且这里的"迭代"不只是调整ontology框架本身。Palantir内部有一种叫"Echo + Delta"的两人小组模式——FDE在现场发现已有产品功能不够用时，会绕开总部的产品路线图，直接给客户做新功能甚至新产品。也就是说，不只是ontology在现场生长，连产品本身都在现场被重新定义。这进一步说明了为什么"先跑起来"如此重要——你在办公室里永远想不到现场会遇到什么。

第五步：可推演性检验——能预测，才算建对了

好的ontology的标准不是"建了多少实体"，而是"能不能支撑有效的预测"。

你的产线ontology能不能在良率刚开始下滑的时候就预警，而不是等到废品堆成山了才发现？能不能预测"如果不停线检修，接下来两天良率还会继续掉"？能不能在维保完成后自动校验关键参数是否复位？

如果不能，先问：是范畴选错了（跟踪的变量跟良率之间没有因果关系），还是前提假设变了（换了新工艺、新物料供应商，原来的规则不适用了）？

当预测失败的时候，就是范畴框架需要演进的信号。

从哲学到工程

五步串下来：亚里士多德的追问（问题驱动）→ 苏格拉底的助产术（从内隐到显式）→ 奥卡姆的剃刀（砍掉非必要）→ Palantir的土路策略（先跑起来）→ 牛顿的标准（能预测才算对）。

前三步是哲学方法论，后两步是工程实践。这不是巧合——ontology这个概念本身就生长在哲学和工程的交叉地带。理解它，需要两边的语言都会说。