本体论和本体建模-从核心要素到应用场景

Hello，大家好，我是人月聊IT。

今天准备再聊下我关于本体论的一些核心观点。这两年讲本体论的人越来越多，包括讲哲学本体论的，讲经典 OWL 本体和知识图谱的，讲 Palantir 本体论的。但是很多人听了还是一头雾水，搞不清楚本体论究竟应该长什么样子，究竟该如何建，包括建设完能解决什么问题。今天我准备从五个方面来聊下我的一些观点。有些观点实际我在前面文章视频也专门提到过。

图片

第一个点，本体建模的核心是对象、行为、规则。本体既包括了静态结构关系，又包括了动态的行为规则。

先说对象。对象就是你业务世界里那些真实存在、值得被管理的人事物。合同是对象，客户是对象，开票单是对象，物料也是对象。对象下面挂两样东西，一个是属性，一个是关系。属性重点是描述对象自己，比如合同金额、签订日期、合同状态。关系描述它跟谁有关，比如合同属于哪个客户、对应哪些产品、生成了哪张开票单。

再说行为和规则。对象是静态的，光有对象，模型是死的。行为回答的是这个对象能做什么，比如合同可以提交、可以审批、可以变更、可以关闭；开票单可以开具、可以作废。规则回答的是什么不能做，比如合同金额不能为负，开票总额不能超过合同总额，合同关闭以后不能再开票，合同提交要符合预算校验规则等。简单来说，行为和规则两者都重要，行为负责推动状态往前走，规则负责守住边界不让它走歪。规则还要尽量形式化到可执行、可校验的程度，不然只是写在文档里，落不了地。

但是仅仅有对象、行为、规则还不够。这三样东西合起来只是一堆零件，零件不会自己变成一台机器。

所以我一直强调，最上面还要再加一层，场景。场景是把对象、行为、规则串起来的那根线。举个例子，合同签订到开票收款就是一个场景，它横跨合同、开票单、收款单三个对象，调用了提交、审批、开票、收款四个行为，中间还用到了金额校验和账期校验两条规则。你把这根线画出来，才知道这些零件是怎么协同的。

所以本体的结构可以归成三层。最底下一层装对象，中间一层装行为和规则，最上面一层装场景。如果你是做软件开发，就很容易理解这三层和软件面向对象分析建模是很类似的。

第二个点，本体建在抽象层，不是建在实例层。

这一步是最容易被搞混的地方。本体建模分两层，一层叫 TBox，中文一般叫术语层或者概念层；另一层叫 ABox，中文叫断言层或者实例层。TBox 是模具，ABox 是这套模具压出来的零件。TBox 里定义的是合同这个 Class（类），包括定义有哪些属性、跟客户是什么关系、必须遵守什么规则。ABox 才管具体的对象实例，比如张三签的那份合同，金额八十万，并在十月一号生效。

那为什么本体建模一定要先建 TBox？

因为规则建在 TBox 上，才能在本体层面自然泛化到大量实例，复用起来最省事。你在 TBox 里写一条，每份合同必须有且只有一个签约客户，那么后面不管灌进来一百份合同还是一万份合同，这一万份全部自动受这条规则约束，不用你再写一万遍。这就是抽象层的规则能泛化到实例层。反过来说，如果你跳过 TBox 直接去整理实例，你能得到的只是这两条数据之间有关系，你永远说不出什么情况下必然产生这种关系。那是知识图谱的做法，不是本体建模的做法。

所以结论很干脆。本体建模的成本要花在 TBox 上，ABox 只是数据装载。ABox 装载的时候也要受 TBox 约束校验，不然实例层照样会脏。判断一个团队是不是真在做本体，就看他有没有在抽象层下功夫。如果打开模型一看全是实例数据，那就不叫本体建模，那叫数据整理。

第三点，本体建模本质上是业务建模。

很多技术人员以为本体建模是个技术活，要会 OWL，要会图数据库，要会推理引擎。这些工具当然要会，但那些不是难点，真正的难点在业务。包括我早就提出，业务只要足够清晰，本体模型就一定能建清楚；业务讲不清楚，模型一定建不出来，换什么工具都没用。

为什么敢这么说？

因为建本体模型的原料，全部是业务语言。你把一个业务讲透，无非讲清五样东西：流程是怎么走的，里面有哪些业务对象，每个对象能做什么行为，要遵守什么规则，哪些角色参与。这五样东西凑齐了，本体模型基本就自己长出来了。

反过来，这五样东西含糊，你在建模工具里画再多框也没用。我见过太多项目卡在这里。不是技术实现不出来，是业务语义不够精确。最典型的是客户这个词。销售说的客户是签约方，财务说的客户是付款方，售后说的客户是使用方。三个角色、三种口径、三套数据，你把它塞进同一个对象里，模型一跑就矛盾。这种问题，靠调参数、换模型、加算力，一个都解决不了。怎么解决？不是硬塞，而是把客户拆成签约客户、付款客户、使用客户几个角色，或者用一个统一的主体对象加角色关系来建模，让口径各归各位。

所以正确的顺序是两步。第一步做业务建模，把流程、对象、行为、规则、角色写清楚，形成一份完整的业务文档。第二步把这份文档转成本体模型。第二步可以交给 AI 辅助，第一步必须由人来，而且必须是懂业务的人。

第四点，一套模型，两个用途。

讲到这里，很多人会问，本体建完到底拿来干什么。标准答案是做分析推理。这个答案没错，但只说了一半。我这两年一直在试的另一半是，同一套本体模型，能不能既用来构建 AI 原生应用，又用来做后续的分析推理。现在我的答案是能，而且中间不需要做模型转换。

为什么能？

因为这两个用途消费的是同一份语义，只是消费的角度不一样。建应用的时候，对象和关系决定数据结构与关联方式，行为决定接口，规则决定校验逻辑，场景决定流程怎么编排。相当于模型往下走一步，映射到数据库和接口，应用就生成出来了。做分析的时候，同一批对象决定要查什么，关系决定怎么连表，规则决定口径怎么算，场景决定分析路径怎么走。相当于模型往上走一步，接上大模型，分析就出来了。

关键在于本体模型站在中间。它往下能映射到数据库表和接口，往上能支撑应用生成和智能分析。中间不再做模型级的语义转换，唯一的转换发生在逻辑计划翻译成物理 SQL 这一步，本体模型本身不复制、不维护第二套语义。这一点很重要，一旦模型需要转换，就说明你在维护两套语义，两套语义迟早会对不上。一套模型两个用途，最大的好处是口径统一。

在本体同步维护的前提下，业务系统改了字段，分析口径不会滞后；报表口径变了，源头系统也知道。原来那种业务系统一套、数据仓库一套、报表再来一套的三层翻译，被压成了一层。

第五点，本体和大模型，谁也离不开谁。

这也是最近被问得最多的一个问题。有了大模型，还要本体干什么？

先说大模型的两个毛病。第一个叫语义口径不清，也可以叫概念边界不清。你给它一张表，字段叫 amount，它不知道这个金额含不含税、含不含运费、扣没扣退款，它就敢直接算。第二个叫数字幻觉。它其实不擅长算数，很多数字是猜出来的。本体正好能治这两个毛病。本体给大模型的不是一张名词表，是一整套语义，这个概念怎么定义、跟谁有关系、口径怎么算、边界在哪里。大模型在这个语义边界里面推理，就不容易跑偏。这就是我讲的大模型借助本体，解决业务语义精确化的问题。

但反过来，本体也离不开大模型。经典本体论那套推理，本质是演绎，而无法做溯因推理分析。

举个例子来说，当前供应链某个关键物料供货中断了，我可以基于本体模型推理分析是否影响到一个关键客户的产品交期。但是我们反过来看，比如是一个关键VIP客户的产品交期延误了，我需要分析具体导致延误的原因，包括分析有哪些改进建议，这个就是溯因推理，经典本体论无法做，但是AI大模型可以做。

对于溯因分析和推理，往往可能原因的集合是开放的、无限的、天天在变的，你穷举不完。这恰恰是大模型擅长的，它能靠常识和模式识别往下推。这就是本体借助大模型的分析推理能力。

所以两者的关系不是谁替代谁，是分层协作。确定性的活，查数、聚合、口径校验，交给代码和规则，不要让大模型直接生成最终结果；开放性的活，归因、解释、给建议，交给大模型。中间加一道护栏，本体的输出就是大模型推理的输入约束，事实不能被推翻，推断必须标出来源。落地的时候，无非是约束校验、查询下推、结果溯源、置信度标记这几招。

好了，今天就聊到这里，希望对大家有所启发。