本体论和本体建模-必须搞清两个关键场景

大家好，我是人月聊IT。今天接着聊聊本体论和本体模型。

首先看下OWL里面对本体的一个定义，即本体是“一个领域内术语的形式化词汇表，通常由某个用户社群共享，并通过描述术语之间的关系来明确其定义”。这里面其实强调了几个关键点，即面向特定知识领域，其次核心是术语和术语之间的关系。关键元素是类，属性，关系，数据值等。简单总结就是本体是一个形式化模型，通过抽象的模式来体现核心领域的知识。

但是要注意，OWL本书是W3C提出的Web本体语言，当时提出的时候更多的是面向结构化或半结构化数据的语义抽象，为领域知识提供严格的逻辑约束和推理基础。

如果回到工程学上面。又有一个经典的定义，即：“本体是共享概念模型的明确的形式化规范说明”。该定义由Studer等人在1998年提出，它精准地概括了本体的四个核心特征，即概念化，明确，形式化，共享。其中概念化代表了是对实例信息的抽象化表达，而形式化代表了表达的时候需要遵循相应的语义要求和表达结构。简单来说就是描述本体虽然也是文字，但是文字应该体现该有的结构化逻辑。

所以再回来看本体，如果还是仅仅是传统知识领域的建模和形式化表达，那么实际和原来没有大差异。但是现在我们谈本体，这个本体虽然仍然是知识工程的核心，但是知识本身已经不仅仅是非结构化的资料和文档，更加重要的是我们已有的结构化的数据，包括承载和产生这些数据的IT系统（包括OLTP系统和OLAP系统)。结合数字化和AI谈本体，那么就一定涉及到和IT系统的业务建模和数据沉淀的关系。也就是说传统的IT系统里面的业务模型+数据沉淀成为了构建本体的关键输入。

为何本体模型是更加适合AI读懂的模型？

接着我必须回答一个关键问题，就是为何本体模型是最适合AI读懂业务语义的模型。比如同样一份业务模型或软件需求定义，可以是Word文档提供，也可以是类似OWL本体模型文件方式提供。那么为何OWL方式提供更加方便AI读懂和理解？

这里面就必须要理解本体模型本身是一个形式化表达，也就是我们说的将完全无结构的文字进一步做了结构化处理。类似对象，关系，属性等的表达更加精确。其次就是通过形式化表达后，我们可以用更少的内容就表达清楚精确语义。同样内容传统Word表达可能5000字，那么形式化方式表达可能2000字就够了，更加更加精准。

我们原来准备任何资料文档核心目的都是方便人来阅读，但是我们现在希望准备一个包括同样语义内容的形式化语言文件，方便AI阅读。并不是说Word文档，纯文字化就不能表达本体，而是不够形式化，也不是最适合给AI阅读和理解的语义。

所以再回来，我们就更加容易思考。

对于当前的OWL和OWL2本体语言表达，是否就是最适合给AI的本体模型定义？实际我在前面解释过，OWL里面本身没有包括规则语义的定义，要定义完整规则还包括了类似SWRL，SHACL等规则语义文件。

那么大家再想下，OWL标准出来的时候还没有AI大模型，那么当初构建这个OWL语言标准目的不是为大模型服务，而是为了业务系统间定义一种标准的语言模型方便系统间集成和对接，或者定义一个标准OWL，方便后续代码程序进行自动化处理和解析。

所以这里我希望大家有一个关键的思考，既然OWL当初的标准定义就不是专门说了为了AI大模型使用，那么OWL这套是否就一定适合当前大模型使用？为何当前本体建模+AI的时候，就一定要把OWL作为一种或唯一的本体语言定义规范呢？这个问题我个人不想争论谁对谁错，但是我们在思考本体建模的时候必须要把这个事情想清楚，我们究竟需要一个什么样的本体模型。包括我在谈Palantir的本体模型定义的时候也说到，实际Palantir的本体定义更类似面向对象的建模，而非单纯的本体语义语义建模，包括其谈到的Action和Function实际就是参考了OOA和OOD的思路，通过这种动态模型来扩展了传统本体的静态模型。

本体建模必须要搞清楚两个关键场景

在我们进行本体建模的时候，一定要首先区分两个关键场景。第一种场景是本体建模是为了从0到1构建应用或Agent使用的本体，第二种场景是本体建模是为了衔接OLTP和OLAP，打通原来数据割裂，驱动数据分析的本体。虽然我一直在思考将两类融合统一，但是不容易。

场景一的核心是基于本体模型来驱动AI精确生成代码，哪怕是后续的自然语言对话，本质也是AI驱动对底层API能力的调用。该场景既产生数据，也使用数据。

场景二的核心是基于本体模型来提供AI大模型分析推理的完整上下文，基于本体来来是实现AI动态推理（精确规则算法+动态模糊推理）融合。核心是融合推理，该场景不产生原始数据，更多是使用数据，最终出分析结论或改进建议。

搞不清楚这两类研究和实践本体，很容易犯错。

对于场景一，你研究半天可能发现这不就是传统的面向对象分析建模吗？你如果回到传统面向对象建模，为何又硬生生的搞个本体建模的概念出来？这个问题需要思考清楚。

我最近看到不少的关于本体建模的文章，感觉作者都在谈面向对象的建模，确实本体建模和面向对象建模很类似，都涉及到类，属性，关系，行为，规则等的定义。但是大家一定要注意里面的关键差别。

首先要注意OO建模的出发点是封装（属性和方法紧耦合），而本体建模的出发点是断言（事实和规则解耦）。“面向对象问的是‘谁能做这件事（Who does What）’，而本体问的是‘这件事在客观世界中意味着什么逻辑后果（What does it imply）’。因此，本体模型天然不具有方法，只有关系和公理，而对于行为在本体中是作为事件或过程类来描述的。而非作为对象的私有函数。其次要注意本体的模型是概念模型，或者偏业务模型，在我构建本体模型的时候我不会去考虑具体的逻辑模型和物理模型，不会去考虑具体的功能实现，而是核心把模型本身搞清楚。而且本体模型它更加偏一个领域模型，我前期的重点是搞清楚核心的对象，行为，关系，而不是为了实现一个业务功能，我必须要暴露哪些业务能力或接口。所以标准的本体建模里面是没有场景模型的，只是我后面为了将本体模型和业务问题域映射才增加的一个模型，本体模型前期一定是高度内容对象行为规则，而不是马上去适配业务功能的实现。最后，本体模型是要为AI提供业务语义的模型，本体模型的构建也不仅仅是为了IT系统实现服务的，更加重要的是为了IT系统构建出来了，AI能够更好的理解该系统底层的业务场景和业务语义服务的。所以你如果不考虑上面内容，完全参考传统面向对象分析建模的思路构建本体本身是错误的。

其次，我们来看场景二，典型的就是数据集成，打通OLTP和OLAP。先是构建本体模型，然后基于问题场景分析，结合模型语义理解后，拉取特定的数据出来进行动态分析推理，最终形成结论或改进建议，对于涉及到业务系统后续行动的再执行回写操作。这个就是典型的Palantir本体的做法。这种做法最大的好处就是不会导致传统已有的OLTP系统或BI，数据中台系统造成大的改动，类似一个具备了动态分析推理的AI外挂。类似早期的APS，我完全可以在已有的采购系统，库存系统，ERP系统后来新构建一个APS系统，动态拉取数据出来，基于TOC规则计算，得出ATP承诺反馈给业务系统。而不对已有业务系统造成大的影响。

那么对于场景二实际的重点有如下。

其一是在传统的数据模型的基础上完善动态业务语义定义，包括数据产生的来龙去脉，数据变化对下游的影响，原来沉淀在IT系统业务代码中的业务规则的显性化梳理表达等。其二就是构建数据集成和映射，方便拉取数据和结论回写。其三就是这套东西如何更好的和AI大模型结合，能够充分的发挥AI大模型的动态分析推理能力。包括我前面讲到的，这个分析推理应该是精确算法+动态模型的融合推理。精确算法部分通过AI大模型生成代码来完成，动态推理部分则是由于场景不同每次从数据源拉取的数据都不同导致的推理链的动态构建。

大家要注意，即使我们看Palantir，它本身也有类似图数据库的存储引擎，但是本体模型层本身是在你的底层数据库基础设施之上的一个层次，传统的数据库，数据ODS层等仅仅是为本体提供数据源的一个数据基础设施，传统ODS里面的数据模型也不是本体，本体一定是构建在传统数据基础设施之上的一层。本体模型层既可以动态拉取你业务系统，数据中台的数据过来进行动态分析处理。也可以类似传统数据集成一样采集数据过来落地到自己的存储引擎里面。这两种模式实际都可以选择。我个人反而是建议本体模型层不要再去持久化一套数据，而是应该按需拉取数据过来，即使本体模型层的存储引擎也仅仅是中间态的数据暂存，方便后续的推理展开使用而已。

本体，知识图谱和图数据库

我在前面发过文章，谈到了本体论的火热，可能让图数据库厂家来了迎来了高速发展的第二春。所以在这里进一步解释下。

大家注意，抽象的本体模型也会形成类似知识图谱一样的知识网络结构。基于本体模型拉取数据出来后形成的实例，同样会形成知识图谱一样的网络结构。在面向IT系统和结构化数据的时候，我前面也谈到过，我们希望构建在Schema层的关系和规则，能够在对象实例化后自动的泛化到实例这个层级，而不是针对实例数据来手工构建关系和规则。

所以原来一直讲本体包括了TBOX抽象层和ABOX实例层，原来知识图谱往往更加关注实例层，其知识图谱里面的Shema定义相当粗或不完善。而本体研究必须对抽象和实例两层都关心。

对于抽象的本体模型，实际数据量并不大，个人理解并没有必要一定要存储到图数据库里面，采用类似OWL语义文件存储，Yaml文件存储没有任何问题。真正的动态推理也不会发生在抽象模型层。而对于实例层，往往就会涉及到大数据量了，数据量大的时候可能上万行，或者几十万行，那么拉取出来的数据是否需要临时存储？如果需要临时存储或中间态存储，图数据库就是最好的选择。一个是图数据库天生方便存储这种网络关系数据，一个是还可以用图数据库的规则引擎进行多跳推理。

但是我们要说的是本体和图数据库之间没有任何必然联系，图数据库是技术层面的基础设施，解决存储问题，解决推理问题等。没有图数据库还有其它技术同样能够解决存储问题和动态推理问题。类似我前面谈到的直接用大模型的动态推理能力，涉及到数据量大的可以分解任务，形成分层推理和多步骤推理。

今天分享就到这里，希望对大家有所启发。