本体论与AI大模型：本体建模和传统OO建模的差异

各位好，我是人月聊IT。今天继续探讨本体论、本体建模和AI相关的话题，由于部分观点和想法较为零散，我打算专门开设一个本体与AI的系列来记录这些重要的见解。

本体论是否为AI所必需？

尽管我也撰写过大量文章，讨论如何借助本体建模来打造企业AI知识中台，沉淀并显性化企业核心知识经验，精确表达企业业务运作的核心语义。那么本体论是否AI的必需条件？

对于这个疑问必须分开来看，即企业在AI赋能过程中，为了让企业已有的私有知识经验更好地被AI所运用，必须攻克业务语义的精确化表达和抽象建模这两个核心难题，恰好本体建模能够很好地解决这两个关键问题罢了。

如果熟悉OOA和OOD面向对象分析和设计，包括传统的数据架构和数据建模，你会发现本体建模在很多方面与面向对象分析设计极为相似。那为何还要进行本体建模？在此我们必须形成完整的认知，即传统OO建模解决的是从无到有的问题，而本体建模除了从无到有（从0到1构建系统），还需解决举一反三的问题（基于规则进行分析和推理的能力）。

传统OO建模是为设计和实现服务的，因此你会发现到了构建阶段实际业务语义和数据语义发生了分离，数据库和数据模型仅沉淀了最终的数据语义，但数据的形成过程，数据经过何种流程和规则形成的过程语义并未保存在数据库和数据模型中，而是分散在应用的业务逻辑层和规则代码里。

比如我们常提及的底层数据库模型能够呈现供应商、采购订单、入库单之间的数据关联，却无法体现采购订单是经过怎样的业务流程、遵循何种规则生成的，包括采购订单又如何经过流程和规则转化为入库单。

因此我再次强调并非传统OO建模不关注行为和规则，而是为了系统构建的便利和解耦，行为规则和数据进行了分离，分别在系统数据库和系统的应用逻辑层代码中实现。

当行为规则和数据分离后，虽然便于构建，却引发了新的问题——不便于分析和推理。所以你看到一个关键点，到了本体建模阶段，又将对象行为规则进行了融合建模。当我们在对象、行为中引入规则后发现了一个关键点，通过规则将对象、对象关系、对象行为构建成了一个网状回路。这导致我们最终本体建模后得到的并非单个行为模型图，而是一个基于规则形成的、具备相互依赖约束和网络回路的知识图谱。抽离规则，研究基于规则形成的完整知识网络，这在传统OO建模中是不存在的，而这个内容恰恰是经典本体论或知识图谱最大的价值所在，这才是本体建模带来的最大变革。

这也是我常说的本体建模虽然与OO建模高度相似，但更加强调规则连接、闭环和回路，以及完整的知识图谱构建。

为何引入这种知识图谱？

简单来说就是复杂问题的分析和解决不是线性的单任务工作流，而是复杂的任务网络，类似我前面提及的Graph Engineering图工程。这种复杂任务、非精确算法求解的问题，往往才是AI大模型最擅长的领域。本体建模能够更好地解决传统OO建模的问题，通过构建这种复杂的知识网络并借助AI大模型能力进行更有效的分析和推理。如果你没有这种场景和需求，那么你构建本体做什么？引入大模型做什么？如果你构建的方法能够解决抽象建模、业务语义精确化表达和知识网络闭环回路构建，那么这个模型是否叫本体模型也无关紧要。

经典本体论和Palantir本体论

对于经典本体论，核心仍然是分析和推理能力。传统知识图谱往往已经是抽象实例化图谱构建。而本体论更加强调了抽象建模。如果简单总结可以归纳为：OWL/OWL2本体论的核心，是通过严谨的TBox（概念层）建模，为ABox（实例层）的知识图谱赋予形式化的语义。在此基础上，推理机能够执行一致性检测、分类、实例化等多种逻辑推理，从而自动发现隐含知识。而多跳推理，正是这种基于TBox引导的、严谨的逻辑推理在知识图谱问答等任务中的一个关键且强大的应用。但是可以看到OWL2没有办法承载跨对象、跨对象行为的复杂规则，因此进一步引入了SWRL和SHACL等规则建模语义标准来进行补充和完善。所以大家看斯坦福的本体建模工具，实际对SWRL和SHACL支持的并不好。

所以到了Palantir的本体论，实际整个本体建模包括了静态建模和动态建模两个部分的内容。静态建模即对象(Object)、属性(Property)和关系(Link)，动态建模包括了行为（Action）、规则（Function），当然还包括了类似事件、接口方面的扩展。实际即使静态建模部分我的理解Palantir参考OO建模的更多，而非OWL2建模的思路。同时在动态建模部分完全不是经典本体论建模的推理模式，而是更多地采用AI大模型辅助推理。

Palantir的本体建模的目的不是简单的数据集成，而是基于数据的分析和推理。这个推理的方式才是和经典本体论最大的区别点。即传统本体论核心是演绎推理，而Palantir的推理更多是溯因（归因）推理，这个我在前面文章也专门强调过多次。我再举例说明下。

还是拿供应链相关的业务场景来说明。经典本体论的推理是当前某个供应商供货中断是否影响客户订单交期？或者是原材料A是否可以作为原材料B的替代物料？而归因推理要解决的问题是当前客户订单交期提前了，我需要你给出最可行的改进计划和建议。从结论或我们假设的结论去反推原因或改进建议，这个实际是经典本体论无法做的事情。如果再准确点描述的话就是如下：

“Palantir 的本体建模绝非仅为集成，而是为‘可计算的分析’提供骨架。它与经典本体论（OWL2）的本质分水岭在于：经典本体践行基于TBox的演绎推理（Deduction），回答‘已知A，必然推出什么B’；而 Palantir 践行基于本体图结构的规划/优化推理，回答‘为了达成目标B，反推需要调整哪些A’。后者不是逻辑学上的溯因，而是运筹学上的逆向寻优，这是传统描述逻辑推理器永远无法胜任的。”。

上面这个才是Palantir的本体建模和分析推理最大的价值。这也是为何我经常拿APS系统里面的ATP承诺假设来举例的一个关键原因，和基于本体建模的分析推理相当类似。那么好了，问题又来了，既然传统的APS分析推理已经可以做，为何还要进入本体建模和AI大模型来做同样的事情？

本体和AI的结合

最后一个点，还是要谈下本体论、本体建模和AI大模型结合的事情。因为我看到太多本体+AI的例子。更多的方法都是通过AI辅助来构建本体，而这个本体模型本质还是用传统的OWL2模型+SWRL等规则语义，那么你后续推理自然也是演绎推理，这个虽然有价值但是并不是最核心价值的地方。你通过AI去做，更多是通过AI编程去实现了传统基于知识图谱的推理引擎、推理机类似的事情，这个本身也不是AI最大化价值的地方。还有就是基于AI自动去完成本体建模，这个更加不应该，本体建模的核心是业务建模，业务建模必须由熟悉行业和业务域的领域专家才能够完成，AI帮你构建的通用本体模型实际没有什么价值。

所以你如果看我本体建模的文章，核心分解为两个步骤，其一是业务建模输出完整的业务文档或需求文档，这个仍然由业务专家完成；其二将业务文档转化为本体模型文件，这个才是可以发挥AI辅助的关键地方。

那么本体和AI如何结合？

又回到这个关键的问题上面。我一再强调的观点就是，本体模型提供给AI完整的精确的业务语义上下文，而基于场景的分析推理完全交给AI大模型。也就是我实际并不关心AI大模型是如何进行分析推理的，不关心AI大模型内部的推理机制。但是在这种实践的过程中我们看到关键点在于这个上下文不仅仅是抽象的本体模型，还包括基于场景问题解决的时候动态拉取的实例数据，如果我们不分阶段把这些东西全部投喂给AI大模型，AI大模型实际是无法解决的，超过了AI本身的上下文容量，即使没有超过实际AI大模型处理到后面也严重出现幻觉和偷懒。

也正是这个原因，我才一直强调了一个关键点，把基于场景的问题分析解决拆分为多个阶段，每个阶段只投喂给AI完整的本体抽象模型+该阶段需要的数据集，而不是一股脑投喂给AI所有数据。在本体+AI辅助的前期，我们可以提前定义这种场景规划和阶段约束，让AI严格按场景阶段来运行，这个拆分完成后的阶段实际有些并不需要AI大模型推理，可能完全是精确算法和代码的计算过程，这个我们也必须区分出来。

到了后期，我们希望做到的是对于出现的新场景，AI能够自动拆分场景为多任务，自动进行规则的组装或能力的编排。这个才是我们本体+AI的终极目标。包括在数字化过渡到AI原生的过程中，我一直强调AI原生的两个关键点，其一是AI的意图识别和能力编排；其二是问题解决后的自我反思和进化。如果在这两个关键点你没有应用AI的能力，那么只能叫AI辅助，而非AI原生。对于这点后续我会再写一篇文章来谈数字化和AI原生，在这里不再展开。

希望以上分享对你有所启发。