Skip to content
个人学习网站
11 分钟阅读

本体（Ontology）不是知识图谱：AI 时代企业为什么重新需要它

把 Ontology、知识图谱、数据库 Schema、工作流、Agent 的边界一次划清楚，并说明我的判断——企业不该自上而下建全局本体，而应该由 Agent 被允许执行的动作倒推着建。

上一篇写 Glean 时，我的结论是企业 AI 的护城河不在模型，在权限和上下文。写完之后有个问题一直没放下：上下文层解决的是「AI 找得到」，可我做 Agent 运行时真正卡住的是下一步——AI 找到了，然后呢？它凭什么知道这条记录能不能改、这个动作该不该执行？

往下追一层，答案指向一个被讲了二十多年、最近突然又被反复提起的词：Ontology，本体。

现在关于它的讨论里，有大量把本体、知识图谱、数据库 Schema、工作流混着说的内容。这篇先把边界划清楚，然后给出我自己的两个判断：一个是本体在 AI 时代到底变了什么，另一个是绝大多数企业该怎么建——以及更重要的，不该怎么建。

先把几个混着用的词分开

计算机领域最常被引用的定义来自 Tom Gruber 1993 年那篇论文：本体是「对某个概念化的显式规约」（an explicit specification of a conceptualization）。这句话很抽象，但有个关键词是显式——把原本藏在人脑和惯例里的概念约定，写成机器能读的形式。

放在企业里，它和邻近的几个东西是这样分工的：

它 回答的问题 典型形态
数据库 Schema 数据怎么存 表、列、外键
知识图谱 世界里发生过什么（事实） 三元组实例
Ontology 世界里有什么、能变成什么（定义） 对象类型、关系、状态、动作、约束、权限
工作流 下一步去哪 流程图、状态机
规则引擎 条件满足时做什么 IF / THEN
数字孪生 现在怎么样 实时状态映射
Agent 这次任务怎么做 规划 + 工具调用
Prompt 这一轮对话带什么上下文 几秒钟的临时语义

最容易混的是本体和知识图谱。本体定义类型，知识图谱记录实例：本体说「存在『客户』这类对象，它可以与『订单』发生『下单』关系」，知识图谱说「华为在 3 月 4 日下了这张订单」。一个应该相对稳定，一个每天都在变。说「我们建了个知识图谱」通常意味着攒了一堆事实，不意味着有人定义过这些事实该怎么解释。

本体和 Schema 的区别更隐蔽。同一张 customer 表，在销售系统里那条记录是买方，在采购系统里是供应商，在合同里是签约主体。Schema 存得下这个字段，存不下这个区别。而对一个要替你执行动作的 Agent 来说，这个区别就是「该向谁付款」和「该向谁收款」的区别。

二十年不温不火，为什么现在被翻出来

本体不是新东西。W3C 的 OWL 2 是 2009 年的推荐标准，2012 年出了第二版，RDF、Protégé、语义网这一整套配套齐全了十几年，企业软件的主流始终没有真正采纳它。

我认为原因不在技术，在于过去本体的使用者是人，而人有一个模型没有的能力：遇到语义缺口会停下来问。一个字段叫 status，人看到会去问是订单状态还是审批状态，问不到就去翻代码、找同事；关系不完整、推理链断掉，人也能靠常识补上。所以严格语义对人来说收益有限，成本却很实在——于是二十年来它一直是辅助系统。

大模型改变的正是这一点。歧义对人是摩擦，对概率模型是自由度。 LLM 看到 status 不会停，它会挑一个最像的解释继续往下推理，而且语气笃定、不留痕迹。你不会收到一个报错，你会收到一个看起来很合理的错误结论。

所以本体的用户换了：它从「帮人理解数据」变成「压缩模型的自由度」。这也解释了它为什么突然被翻出来——不是技术进步了，是终于出现了一个愿意为严格语义付钱的消费者。

真正的分水岭：可描述的本体与可执行的本体

不过，把今天的企业本体等同于当年的 OWL，也是一种误读。这两代东西的目标不一样。

语义网那一代本体的核心能力是推理和一致性检查：子类关系、等价类、约束冲突。它能告诉你 A 是 B 的一种，但推不出「这张订单现在该不该被改期」。它的产物是可描述的本体，本质上是一份非常严谨的文档。

今天被反复引用的样板是 Palantir Foundry 的做法。按其公开文档，它把本体拆成两部分：语义部分（object types、properties、links）和动能部分（action types、functions、dynamic security）——也就是说，动作和权限是本体的一等公民，而不是外挂在上面的应用逻辑。

分水岭就在这里，不在建模精度：

一个本体如果只能回答「订单是什么」，它是文档； 能回答「谁、在什么状态下、可以把这张订单改期，改完写回哪里、留什么痕」，它才是运行时的一部分。

这条正好接上我在 Glean 那篇里的第三个判断：Agent 落地的瓶颈已经从能力变成授权。 而做授权判断所需要的信息——这是什么对象、这是什么动作、谁被允许、改完写回哪、出事找谁——不在 LLM 的权重里，也不在向量库里。它们只能被显式写下来，而写下来的地方就是本体。

我不同意的部分：不要自上而下建全局本体

最近的讨论里有个很有诱惑力的叙事：企业应该先建立一个统一的业务世界模型，把整个公司描述清楚。听上去很对，但我认为按这个思路启动的项目，大概率会死在和二十年前完全相同的地方。

主数据管理、企业级数据模型，这两波都试过全局统一。失败的原因通常不是建模技术不行，而是建模的产出没有消费者。一个没有人、也没有程序每天调用的模型，一定会和现实脱节；脱节之后它就从资产变成负债——因为它还在，还看起来权威，但已经是错的。

这一点在 MBSE 里已经是常识。系统工程界花了很多年才认清：模型的价值不在于覆盖多完整，而在于它是否处在交付路径上。不在路径上的模型，画得再漂亮也只是一次性文档，评审完就开始腐烂。企业本体是同一个问题换了一批人重新踩，没有理由认为这次会不一样。

所以我的做法是由动作倒推：先确定 Agent 被允许执行哪些动作，再往回推这些动作需要哪些对象、状态、前置条件和权限，只建这一部分。一个最小可用的本体条目大概长这样：

Action: reschedule_order          # 订单改期
  对象:     Order（唯一标识取 ERP 的 order_no）
  前置状态: 已确认 且 未发货
  约束:     新交期不得晚于合同 SLA；顺延超过 3 天需上级审批
  权限:     订单归属销售，或其所在区域的销售经理
  写回:     ERP 交期字段 + 变更留痕（谁改的、依据什么）
  来源:     SLA 定义来自合同系统，权限来自 HR 汇报关系

这个条目里没有任何一行是 LLM 能自己推出来的，全部是企业私有知识。而它的规模不取决于企业有多少张表，取决于你允许 Agent 做多少件事。

本体的边界应该由授权范围决定，而不是由数据资产盘点决定。 这是我目前最有把握的一条判断，也是我在自己的 Agent 运行时里正在往回收敛的方向——运行时做得再稳，只要答不上「这个动作该不该被允许」，在企业里就是不可用的，而这个答案不可能由运行时自己发明。

真实代价不在建模，在治理

如果只看建模，本体项目看起来很划算：画几十个对象类型能有多难。真实成本在后面三件事上，而且都不是技术问题。

一、实体解析，最脏的活。 Huawei / HUA001 / 华为技术有限公司 / Huawei Technologies 是同一个对象——这件事没有优雅解法，只能靠规则、人工核对和持续维护。它和 Glean 那批连接器同属一类：苦活，是护城河，也是最好用的拖延理由。跳过它直接建本体，等于把统一语义盖在四套互相冲突的 ID 上。

二、语义所有权。 谁有权修改「战略客户」的定义？改之前谁要会签？没有本体的时候这个问题不存在，因为每个系统各自理解，冲突被部门墙吸收了；一旦统一，定义就变成了公共资产，必须有主人。卡住绝大多数本体项目的是这一步，不是建模工具。 技术条件具备而组织条件不具备时，做出来的东西没人维护。

三、语义漂移，我最担心的一类故障。 改一个定义，所有依赖它的 Agent 行为会同时改变，而且不会报错——只会开始做出略微不同的决定。没有堆栈，没有告警，只有指标慢慢变形。 所以本体必须像对外 API 一样管理：有版本、有废弃期、有变更评审，改动要能回溯到具体的人和理由。

什么时候不该上本体

反过来说更有用。以下几种情况我认为不该做：

  • 只做问答和文档检索，没有写操作。 这种场景 RAG 就够了，本体的收益追不上它的治理成本。
  • 业务规则本来就集中在一两个系统里，不存在跨系统的语义冲突——那统一语义要解决的问题根本不存在。
  • 组织里没有人能对定义拍板。 这条最关键：能建，但建完无人维护，两年后它会变成一份没人敢删又没人敢信的遗产。
  • 数据质量差到实体解析做不了。 先解决主数据。本体建在错的 ID 上只会放大错误，还让错误显得权威。

值得做的信号则很明确：你已经有 Agent 或自动化在跨系统写数据，并且已经出过一次「它改了不该改的东西」。 出过一次之后，讨论就不再是要不要建，而是建到什么粒度。

我还没想清楚的

  • 分层是否成立。 有观点认为本体会分成两层：企业级的规范本体（缓慢演进、按产品治理）和任务级的临时本体（Agent 规划时临时构造）。我倾向认同这个方向，但没想清楚临时那层的产物要不要沉淀、由谁审——不沉淀等于每次重新猜，沉淀了就是在无人治理的情况下扩张公共语义。
  • LLM 能不能自己抽本体。 从文档和表结构里生成候选类型，技术上已经可行，诱惑很大。但本体里最值钱的那部分——谁被允许做什么、什么情况下必须两人复核——恰恰不在文档里。自动抽取能给你骨架，给不了判断，而判断才是要命的那部分。
  • 本体与 MCP 工具定义会不会合流。 一个写得好的工具定义（名字、参数、前置条件、副作用、权限）其实就是一条贫瘠的本体条目。如果工具定义继续变厚，两者的区别会越来越像同一件事的两种序列化方式。这个问题我在写运行时的时候天天遇到，目前没有结论。

小结

上一篇的结论是：模型不是护城河，权限和上下文才是。这一篇往下走一层——权限和上下文本身也要有个地方被显式定义下来，那个地方就是本体。

但它不该被当成一个「先建三年、建完再用」的基础工程。LLM 决定 AI 能不能听懂人话，本体决定 AI 能不能被信任去动一张订单；而你需要定义的世界，只有 AI 被允许动的那一部分。

参考资料

事实性内容来自以下公开来源，判断部分是我自己的：