本体论和AI大模型03-什么场景要用本体论，本体论究竟解决了什么业务问题？

大家好，我是人月聊IT。

今天继续聊本体论和AI大模型，今天核心的主题就是本体论究竟解决了什么问题，带来什么核心的业务价值。因此最近我和很多甲方客户，包括合作伙伴沟通的时候，谈到最多的就是本体论究竟带来了什么业务价值，具体什么场景下必须要用到本体论。

最近一个客户到我们公司喝茶聊天，实际该客户今年年初就专门成立了一个小团队，研究本体论在类似电商，零售行业的应用。但是客户仍然存在一个巨大的困惑，就是实际在没有应用本体论之前，客户已经结合AI大模型的能力，包括通过精确的程序代码，实现了电商某些场景下的自动化运营，包括类似自动化的商品推荐，自动化的商品补货等。所以即使已经在研究本体论思想，客户仍然困惑究竟什么场景必须要使用本体论。

在前面我专门写过一篇文章谈本体论的应用场景，那篇文章的核心观点就是本体论适合类似开创，创新，探索，动态分析和推理的场景。而且这些场景本身允许不确定性，允许一定的置信度。那么这些场景就是最佳的本体论应用场景。在前面我谈本体建模和传统面向对象建模差异和区别的时候又谈到了，虽然两者都是抽象建模，但是本体建模更加强调了最终的模型中的各个对象行为规则之间相互影响和制约，形成了一个闭环回路， 或者形成了一个完整的类似知识图谱的知识网络。在这种情况下很难通过固定算法精确求解，因为不是单目标最优，而是多目标下的平衡，类似系统思维和系统工程，那么这个场景是应用本体论的一个很好场景。

还是回到刚才谈到的类似自动化运营这个业务场景，看起来自动化运营已经变成了精确的代码程序来自动执行。那么本体论还有啥用？大家考虑下涉及到自动化运营是否涉及到诸多的业务场景，类似补货，调货，预警，客服，自动推荐，自动数据分析等。那么是否只要新出现一个新的业务场景，你为了自动化，是否都必须要新开发一个新的代码程序去运行。

而且究竟如何开发这个程序还涉及到有经验的业务人员将运作经验固化为业务需求，然后业务需求再转为代码程序。那么我们是否可以设想下，能否在给AI列举了5到10种已有场景下我如何做运营的方法后，AI能够基于我底层的对象模型，行为规则，自动来分析推理新场景的应对方法。如果能够做到这样，我们才真正具备举一反三的能力。因此固化当前的场景虽然也可以用本体，但是从来不是本体真正的重点，真正的重点是真正理解了完整的本体模型的业务语义，真正能够做到出现新场景下的举一反三。这样才能够充分发挥AI大模型+本体的价值。

前面我谈到过，经验在系统外。当前虽然有很多的IT系统，但是IT系统最终提供的仅仅是决策后的结果的表单化录入。我举一个最简单的供应链例子大家就容易理解。比如一个供应链系统有替代物料维护功能，调货补货功能，安全库存设置功能。但是如果当一个关键物料供货中断的时候，我究竟应该是引入替代物料，还是调货，还是调整安全库存设置？具体用到个问题来解决问题靠的是系统外的人员经验操作或者说系统外的操作指导书。大家可以简单理解为：

场景和问题=》思考和决策过程-》系统里面操作结果

真正衔接场景和系统功能间的，还有一个重要的问题分析，思考和决策过程。这个原来是靠有经验的人来完成的。那么后续是否可以靠AI来完成，或者进一步靠AI自动完成并自我持续优化迭代。所以AI+本体不是解决了场景问题，也不是解决是系统功能录入，而是解决了场景问题到系统功能间的分析和决策。AI如何能够做到这样？简单来说就是AI需要懂你的完整业务，懂业务需求和系统功能间的关系，AI需要一个完整的业务语义提供。提供这个完整语义最佳的方式就是本体模型。所以原来我们只谈本体给AI大模型提供了丰富的，精确的业务语义还是没有直达最本质的东西。核心是AI要能够替代关键人员的思考过程。

包括我们谈Palantir的本体论也是同样道理，不是简单来数据集成，解决了OLTP和OLAP间的断裂和鸿沟。更加重要的是从结果能够追溯到过程，类似从指标异常一定能够追溯到具体哪个行为过程导致了指标异常。同时即使追溯到行为过程还不够，最好还能够去解决我要如何做解决这个问题。我要的是改进建议和问题解决，而不是仅仅知道问题本身，要解决问题又涉及到关键的分析和思考，假设，模拟，推理等。这个才是本体的价值，原来靠人去分析和解决的，现在可以靠AI+本体去解决。

所以我原来一直在讲，本体论不是万能的，很多精确化的问题实际不需要本体就能够很好的解决。企业要用本体论，也是首先要思考日常的业务运作里面有哪些痛点？有哪些是传统IT应用难以解决的？有哪些是AI赋能中由于幻觉太重无法满足需求的。有哪些是需要极其的依赖有经验的员工才能够解决的？这些往往就是需要本体模型+AI辅助的关键点。

所以如果你看我前面文章，我其实对经典本体论不太感冒。AI时代只有本体模型+AI大模型两者充分结合才能够真正发挥巨大的价值。经典的本体论更多仍然是精确推理，是演绎推理；而AI+本体更多是动态不确定推理，是溯因推理分析。不是简单的回到是不是的问题，而是要回答问题出来了我应该如何解决和如何决策的问题。

再回头来看Palantir产品，我们理解实际整个产品应该做两层关键沉淀。一个是最下面的Foundry+AIP的本体建模底座和AI分析推理底座的沉淀。还有一个就是面向垂直行业或者说是垂直业务的本体模型经验沉淀。而真正更加重要的我认为反而是中间层内容逻辑的沉淀。简单来说，如果我们现在推FDE模式，本身对FDE工程师本身能力还有极高的要求，FDE还拿高薪，这个本身是不合理的。在行业模型沉淀期FDE价值毋庸置疑，但是真正沉淀了细分领域的行业模型，那么实际再对上层的FDE能力要求应该降低，应该进一步减轻对FDE能力的依赖才是重点。

在谈Palantir的本体建模中的动态建模的时候，有些文章将其分为动态层和动能层。动能层解决的是如何运转的问题，涉及到的是Action和Function建模。而动态层解决的是如何分析决策的问题，涉及到的是场景建模，What-if分析，WorkFlow规划等。而真正最核心的本体知识经验层反而是在动态层。也就是我们常在企业知识管理里面谈到的核心经验模式和方法论。（注意我个人本体建模规范里面包括了规则建模和场景建模，映射到Palantir实际这两者大部分内容都纳入到了动态建模里面。注意Function函数更多仅仅是计算规则而非推理规则）。Palantir通过这三层的协同，构建了一个完整的闭环：语义层定义业务世界（有什么），动能层驱动业务操作（做什么），而动态层则负责优化业务决策（怎么做最好）。当动态层积累的足够的时候，对FDE的依赖也越小，同时本体模型本身具备自我进化，面对从来没有出现过的场景的举一反三的能力。

今天分享就到这里。