本体论思想-抽象建模的本质是什么？

今天接着再跟大家聊一下本体论，因为最近在我好几个群里面，本体论聊得相当的火热，但是总感觉大家仍然还是在谈本体论一些基础的概念，或者是连概念都没有搞清楚。

我在一个群里面就一直在讲，如果你原来做过类似于抽象建模的工作，其实是方便你了解本体论的。不管是类似于软件建模、企业架构、BIM建模，各种建模，因为你通过这种建模，你就理解到了本体论的一个核心本质——它本身是现实世界的一种抽象。

好了，如果你原来还学习过相关的一些基础的西方哲学，你可能更容易了解本体论。因为本体论这个词本身就来源于西方哲学，我原来在讲哲学的时候就谈到里面两大分支：一个是本体论，一个是认识论。本体论更多的就是在找万事万物抽象以后的本质性的规则，它是一个形而上的事情。

但是我前几天又在群里面谈到一个重要的观点：本体论更多的是解释清楚本体是什么，但是更加重要的是认识论或者叫方法论——我们怎么样去构成这么一个抽象的本体。所以说现在很多群里面的讨论，更多的都在谈"本体是什么"，而没有真正的谈"我们怎么样去形成一个本体"，或者是"怎么样让这个本体真正的发挥它的业务价值"。

所以我今天在聊本体论，我准备聊三个方面的内容：

第一，我还是想从最初的软件系统开发、软件建模来谈起。

第二，接着来谈Palantir的本体论究竟解决了一个什么样的本质问题。

第三，再来谈当前我们怎么样更好地进行本体论的建模。

首先从软件建模来谈起。

谈软件建模大家都很清楚，最早的就是基于面向对象分析和设计的思路，类似于通过UML这种形式化的语言符号来进行建模。所以说这个建模里面既有静态的逻辑图，又有动态的逻辑图。类似于我们常见的用例图、活动图、状态图、序列图、部署图，这是一方面。

第二，建模完了以后，你会发现它既包括了静态的对象、对象之间关系的建模，同时也包括了相应的行为规则的建模。静态的对象关系的建模，类似于类关系图，它最终会转成数据模型，最终落到我们的数据库设计里面。

还有一个就是我们常说的一些行为规则关系的建模，类似于状态转换图、序列图，这么一些详细的建模设计，它最终其实是落地到了我们最终的源代码里面。

这个是我们的设计态和建模。好了，设计建模完了以后，整个软件经过开发最终就部署上线了。那大家发现一个关键的问题没有？部署上线以后，对于大部分人来讲，它实际上已经看不到代码了，因为这个时候代码已经编译构建成了一个部署包或者是一个镜像。但是稍微有点技术背景的人，他其实是能够看到数据库，能够查看到数据库表，包括表里面的字段属性关系，或者是表的一些解释信息。

所以任何一个软件建模，我们大家一定要理解到：从你的设计态变到最终的运行态以后，实际我们讲的数据模型和行为规则模型，它其实已经分离掉了。对于数据模型，往往落地到数据库表里面，相对来说容易理解、容易可见。但是行为和规则模型这个东西麻烦了——这个在代码里面大部分时候是看不到的。这个是我们软件建模常规走的一个流程。

接着来谈第二个问题：Palantir的本体论当初究竟解决了一个什么样的问题？

因为Palantir这家公司最初就是一个偏类做数据服务、数据中台类的公司。数据中台的产品大家都知道，它会出相应的一些数据服务，或者是相关的一些数据看板、数据指标。那当大家看到这个数据指标的时候，我们往往只能看到这个指标的结果，包括这个指标的计算公式，但是很难去看到形成指标这个数据蕴含的底层的业务语义，或者是业务流转规则。

类似于举一个简单的例子：我现在可以看到企业的库存周转率这个指标，我也能够知道库存周转率这个指标是以什么公式把它计算出来的。

好了，我理想化的库存周转率是一年要周转12次，但是现在整个的周转率只有8次。对于我管理人员来讲，我更希望能够去追溯：库存周转率下降究竟是什么样的一些行为导致了这么一个下降？究竟是你采购周期延长了，或者是交付周期延长了，还是说有客户大量的订单取消了，导致库存周转率提升了？在传统的BI或者是数据中台系统里面，实际上它是没办法回答这个问题的。

因为常规的数据中台系统里面，它底层只有数据模型。虽然说这个数据模型里面也有数据表和数据表之间的关系，但是它没有这么一个数据形成的语义模型，或者是说形成这个数据本身的行为和规则模型——这个东西没有。

那具体的行为规则模型究竟在哪里呢？是不是原来我们在构建IT系统的时候，大量的行为规则就丢失掉了呢？大家一定要注意，实际上不是的。我们在传统IT系统构建的时候，行为和规则实际上打包在了我们的源代码里面，行为和规则其实是落地到了我已经建设完的各个业务系统里面了。

所以再回到刚才说的：当我看到BI一个指标出现问题以后，我要追溯后面的业务隐含的业务规则逻辑的时候，往往我需要又回到我传统的类似于采购系统、库存系统，然后我去查我相关的业务活动、业务订单，最终找到实际导致这个指标下降的关键原因。

大家思考一下，我们是不是这样做的？

好了，由于正是这个原因，我们更加希望什么呢？就是当我再去查看分析一个指标的时候，我看到的不仅仅是这个指标的结果，我还能够分析追溯指标数据的来龙去脉。那怎么样才能够做到这个点呢？很简单——你只有数据模型那绝对就不够，我需要在传统的数据模型上面再增加相关的行为模型和规则模型。

当数据模型加行为加规则构成一个完整的大模型的时候，我才有了这么一件事情的一个完整语义。所以我在前面讲本体论的时候就一直在强调：我们去构建一个本体的时候，它不是单纯的对象模型，而是一种对象加行为加规则的一种整合的打包模型。

对象它可以产生行为，在我们去执行某个行为的时候，又需要调用或依赖某个规则或者是约束。所以说行为、对象、规则，它完完全全是一个完整的、相互制约、相互依赖的一个整体。我怎么样去构建这么一个本体？那就是需要在我传统的数据模型的基础上，增加行为建模，增加规则建模，这样就构建了一个完整的本体。

行为规则来源于哪里？来源于你的业务场景、业务活动，或者是来源于你对原始历史已有的IT系统的源代码的理解。我把这些东西抽象出来，变成一种类似于伪代码语义，或者是一种Markdown格式的定义都可以。这样我才能够构建一个完完整整的这么一个本体，这样才能够真正的解决"知其然又知其所以然"的问题。这个才是为什么要用本体论的一个关键。

接着来聊第三个问题：怎么样通过抽象建模去构建这么一个本体？

在AI大模型没有出现之前，为什么我们一直没有更好的去实施落地这件事情？在原来我讲的时候我就一直谈到：本体论它其实没有什么太多新鲜的东西，本体论的建模的思路本身就跟我们原来讲的面向对象分析设计建模的思路完全是一致的。那为什么现在回来又要谈到本体论的建模？中间究竟出现了哪一些变化？

所以说在这里大家一定要注意。

首先我谈第一个点：就是在UML建模完了以后，又出来一个东西叫MDA模型驱动建模。模型驱动建模里面它本身又分成了PIM和PSM，一个叫平台无关模型，一个叫平台相关模型。相对来说，平台无关模型本身是不是就更加简单了？这样的话让我们更加关注你核心的抽象的内核、模型的内核。

好了，在MDA完了以后，前几年又有一个东西很火，叫领域建模。领域建模很简单，就更加关心我们核心的领域对象、领域对象应该暴露的行为、事件和规则。领域建模又不关心一个什么东西呢？就是我构建的这个领域模型你究竟用什么样的开发语言？你究竟是采用3层框架还是5层框架？这些东西跟我都没有关系。这样的话我去做完领域建模，我就只做我核心的内容的抽象，或者叫业务的抽象。这样的话就是可以极大的控制我模型的规模，或者是模型的复杂度。

再来回来我们再讲一个关键的东西：就是传统的软件建模，大家发现有没有一个关键点？就是我们的软件建模实际是将业务建模和最终的IT实现建模完完整整打包在一起了。

但是随着整个AI大模型的发展，大家一定要意识到：对于最终的技术实现这个事情已经越来越不重要。我们对于任何一个业务场景的理解，它的核心仍然是业务建模。所以说我们在建模的时候又可以更进一步：我应该核心去关注业务的建模，而剥离掉技术实现的建模，这样重新形成一套抽象建模的方法论。

所以说在我们构建本体的时候，整个思路就相当明朗了。我们完全可以借鉴传统的面向对象分析设计的思路，借鉴MDA，借鉴领域建模，剥离掉语言相关的建模，剥离掉分层架构的建模，剥离掉技术实现的建模，最终围绕核心的业务去建模，围绕对象、行为、规则去建模。这样建出来的模就是一个核心的事情或者是事件，它最最本质的底层本体模型。

而且在前面我有一个视频，我专门在讲本体论建模的时候，我还讲了一个相当重要的东西：本体论的建模一定是围绕对象这个核心展开的。因为对象它本身可以产生各种行为，而行为本身又调用依赖各种规则，它的核心仍然是对象。整个建模的核心不是业务场景，不是流程，而是对象。

因为业务场景、业务流程千变万化，但是核心的对象它本身是可以穷举的，对象的行为也是可以穷举的。所有千变万化的业务或者是流程，往往都是对象行为的灵活的组装和编排。所以说你只要围绕核心的对象，把对象暴露的行为、规则全部搞清楚，你其实就得到了一个高度抽象化的本体。这个本体其实就是我们做任何一件事情，不管你是不是做IT系统，最最核心的抽象模型。