【本体论 01】企业缺的不是数据，而是业务定义

库存报表显示某个商品即将缺货。

对人来说，这不是一个孤立数字。运营会继续问：哪些订单会受影响？在途库存什么时候到？供应商是否可靠？有没有替代商品？补货需要谁审批？

数据库不会主动理解这些问题。它只保存商品表、订单表、库存表、供应商表和一批状态字段。表与表能 Join，不代表系统理解“缺货”在业务里意味着什么。

这就是企业本体论要解决的问题。

本文讨论的不是哲学史，也不是一套新的数据库技术，而是企业数据与 AI 场景中的 Ontology：如何把分散的数据重新组织成一个可理解、可验证、可操作的业务世界。

企业真实运行的不是表

一个企业由客户、商品、订单、合同、库存、供应商、广告账户、投放计划、审批和异常构成。

数据库里的表，是这些真实对象在某个系统中的记录。CRM 记录客户和商机，ERP 记录订单和财务，WMS 记录库存，广告平台记录计划和消耗，飞书或邮件记录审批过程。

现实业务只有一套，数据投影却有很多套。

同一个客户可能有 CRM ID、会员 ID、手机号、设备 ID 和广告平台人群 ID。同一个商品可能同时拥有 SPU、SKU、ERP 物料编码和媒体商品 ID。同一个“销售额”，也可能分别指签约金额、开票金额、支付金额或回款金额。

因此，企业的数据问题通常不是单纯“没有数据”，而是三类意义问题：

同一个对象被不同系统重复描述。
同一个概念被不同团队赋予不同口径。
表之间存在技术关联，却缺少稳定的业务含义。

以智能问数为例，系统可以把自然语言转换成 SQL，但它未必知道“良品率”“合格率”“一次通过率”和 FTQ 在当前企业里是否等价。生成 SQL 只是完成了查询，真正困难的是确定用户问的究竟是哪一个业务概念。

这里的关键是：数据可访问，不等于业务可理解。

从第一性原理重新推导

先暂时忘掉 Ontology 这个词。

假设我们要让一个刚入职的同事理解库存异常，他至少需要知道：

企业里有哪些重要对象。
如何唯一识别每个对象。
对象有哪些属性和当前状态。
对象之间有什么关系。
哪些规则决定状态如何变化。
谁能查看、修改或审批。
可以发起哪些业务动作。
动作完成后，结果如何被记录。

机器理解业务也绕不开这八个问题。

把它们连接起来，可以得到一条完整链路：

从现实业务到可执行定义

对象告诉系统“什么存在”；属性告诉系统“它现在是什么样”；关系提供上下文；规则形成判断；权限划定边界；动作改变业务状态；反馈让模型跟随现实持续更新。

本体论的核心，就是把这套结构从人的经验和散落文档中提取出来，形成稳定、可复用、可治理的业务定义。

“本体论”有三种不同语境

本体论之所以显得晦涩，一个原因是三套语境经常被混用。

语境	主要问题	典型产物
哲学本体论	世界由什么构成，什么可以被认为真实存在	关于实体、属性、关系和存在的理论
形式化本体	机器如何表达概念、分类、关系和约束	类、属性、个体、规则和推理体系
企业本体	企业如何统一描述并操作真实业务世界	业务对象、关系、函数、权限、动作和反馈

哲学本体论提供了思想源头：在讨论世界之前，先说清楚世界里有什么。

语义网把这个问题转成机器可以处理的形式。W3C RDF 用“主体—谓词—客体”表达资源之间的陈述；OWL 2 用类、属性、个体等要素描述领域知识；SHACL 则用形状和约束验证数据是否符合规则。

这些标准关心的是机器能否正确表达和判断概念。

企业语境还要多走一步：定义完成之后，业务能否基于这些对象和规则继续运行。

Palantir 的官方定义把 Ontology 称为组织的 operational layer。它位于底层数据集、虚拟表和模型之上，既包含 Objects、Properties、Links，也包含 Actions、Functions 和 Dynamic Security。

这已经不只是“机器看懂”，而是“企业可以围绕同一套定义进行决策和操作”。

用产品语言理解：名词、形容词、关系和动词

对于产品经理，可以把本体论理解成一套业务语法。

本体元素	业务语法	广告投放示例	解决的问题
Object	名词	广告账户、计划、创意、商品、线索	明确业务世界里有哪些对象
Property	形容词或状态	预算、消耗、审核状态、库存、毛利	统一对象画像和当前状态
Link	关系	计划推广商品、创意属于计划、线索归因到创意	建立对象之间的业务上下文
Function	计算和规则	ROI、预算消耗率、素材疲劳度、风险评分	沉淀可复用的判断逻辑
Action	动词	调整预算、暂停计划、替换素材、发起审批	定义可以怎样改变业务
Security	边界	谁能查看成本、谁能调预算、何时必须审批	控制人和 AI 的行动范围

传统页面设计容易从“列表展示哪些字段、页面放哪些按钮”开始。本体论思维会先问：

当前页面操作的是哪个业务对象？
对象处于什么状态？
它与哪些上下游对象相关？
什么规则决定按钮是否可用？
动作执行后会改变哪些对象？
结果写回哪里，又会影响谁？

页面只是对象的一种交互界面。对象、规则和动作才是更稳定的产品结构。

静态定义与可执行本体

很多项目已经在做业务词典、实体关系图或知识图谱。它们同样会定义对象、属性和关系，但这还没有覆盖企业本体的全部价值。

假设系统已经知道：

投放计划 A 推广商品 X。
商品 X 的库存低于安全线。
计划 A 的预算消耗速度高于预期。

到这里，系统完成了业务表示和关系分析。

如果要继续处置，它还需要知道：

库存风险如何计算。
是否应该降低计划预算。
哪个角色有权修改。
超过什么金额必须审批。
修改后写回哪个广告平台。
执行失败如何回滚。
最终转化和库存变化如何回流。

这条分界线很重要。

这条分界可以压缩为：静态本体解释世界，可执行本体定义如何改变世界。

Palantir Actions把一次对象变更定义为业务事务。Action Type 可以规定允许修改的对象、属性和链接，也可以包含校验、权限、审批及外部副作用。用户或 Agent 不需要直接修改数据库，而是发起一个具有明确业务含义的动作。

这也是 operational system 和 analytical system 的区别。分析系统帮助人发现问题；操作系统还需要把判断转成动作，并把动作结果重新纳入系统。

本体论最终交付的不是一张图

一张对象关系图可以帮助团队对齐概念，但它不能自动解决数据映射、规则复用、权限控制和动作写回。

真正可运行的企业本体，至少要形成七类长期资产：

业务对象模型：企业里有哪些对象，如何唯一识别。
语义口径：术语、指标、状态的权威定义。
关系网络：对象之间有哪些稳定业务关系。
规则函数：指标、评分、约束和预测如何计算。
权限治理：谁能看、谁能改、什么情况需要审批。
动作目录：系统允许发起哪些业务变更。
反馈闭环：动作、结果、日志和模型版本如何被记录。

因此，本文给企业本体论的定义是：

本文采用的定义是：本体论是企业对现实业务世界的可执行定义系统。

它定义什么存在、如何被识别、处于什么状态、彼此如何关联、遵循什么规则、谁能操作、如何行动，以及行动结果怎样回到系统。

用产品公式表达：

本体论 = 业务对象模型 + 语义口径 + 关系网络 + 规则函数 + 权限治理 + 可执行动作 + 反馈闭环

产品经理如何判断一个方案

以后再遇到“本体平台”“企业知识图谱”或“AI 业务中台”，可以先检查四件事。

第一，系统描述的是业务对象，还是把数据库表换了一个名字。

第二，对象关系是否具有权威业务含义，还是临时查询时拼接出来的技术关系。

第三，规则和动作是否成为可复用、可测试、可审计的资产，还是散落在页面、脚本和 Prompt 中。

第四，权限是否进入对象和动作层，执行结果能否写回并形成反馈。

只有对象和关系，方案主要解决“理解和查询”；加入函数，可以形成稳定判断；加入权限、动作和反馈，才开始接近企业可执行本体。

这也解释了为什么本体论会在企业 AI 里重新受到关注。大模型已经能读文档、写 SQL、调用接口，但它并不天然知道企业真实世界如何构成，更不知道自己被允许改变什么。

下一篇会继续划清边界：本体论与关系模型、数仓、语义层、知识图谱、数字孪生和 UEI，分别解决什么问题，又如何组合。

参考资料

系列导航

下一篇：【本体论 02】别再把本体论等同知识图谱

【本体论】企业缺的不是数据，而是业务定义