【本体洞见】企业治理的每一份数据资产，都是本体的一块砖

作者：王仕亿 博士（普元信息）

关键词：本体（Ontology）｜数据资产｜数据治理｜知识图谱｜大模型落地｜企业级智能体

编者按

本体（Ontology）并不是一个新概念，但大模型的出现把它重新推到了企业 AI 落地的中心。【本体洞见】系列试图回答一个问题：当数据治理已经做了多年，本体究竟要另起炉灶，还是可以长在既有资产之上？本文是系列第一篇，给出的判断是后者；也正是这一点，决定了中国企业要走的路径与 Palantir 并不相同。

自大模型诞生以来，为了把企业级智能体真正做好，业界做过很多尝试——建知识库、上 RAG、构建知识图谱，但距离理想的形态仍有不小的差距。问题的根源并不在模型本身的能力：多数情况下它已经足够聪明；可对于一家企业究竟有哪些东西、它们之间是什么关系、哪些事情可以发生在它们身上——这些内容，模型再大，也无从知晓。

企业知识沉淀下来的那套结构与体系，就是今天要讨论的本体（Ontology）。它并不新鲜，也不玄虚。企业 AI 究竟能不能被信任，取决于它脚下这套本体有多确定。

一、为什么最后落到本体

先问一个问题：一家企业的完整业务，有没有可能在企业内部找到一个人讲清楚？

答案几乎是否定的。业务知识散落在每个人的脑子里、很多个系统里、成堆的文档里。让业务专家梳理，他懂业务却捋不全技术细节；让技术人员梳理，他懂系统却不懂业务语义。这件事，一个人甚至一群人都难以做成。数据治理本身就是一场持久的苦活，不能不做却总也望不到尽头，更不必说知识的梳理。

大模型的出现第一次让人看到了希望：杂乱无章的文档可以被低成本、规模化地治理，因为它真正具备了“读懂”语义的能力。但仅仅理解语义，还只是构建完整知识体系的第一步。

很快就会碰到一堵看不见的墙：大模型的上下文是有限的，它装不下整个业务。没有人能把一家银行的全部规则、对象、流程塞进一段提示词。即便拥有无限上下文，依然难以得到理想的结果。这个过程一度令人绝望——人们看不到一个完整知识体系该有的样子，只能反复追问，得到的答案却总不尽如人意。

也许业界正走在一条正确道路的开端，但这注定是一个循序渐进的过程：不能指望一次性把业务“讲清楚”，只能分块理解、逐步构建——一块一块把业务建模出来，慢慢沉淀成一个确定性的结构。

关于本体，业界本就有各种各样的定义。在本文中，我们就把这个沉淀下来的确定性结构称为“本体”。

如果从大模型诞生算起，这条路走得并不长，但期间尝试过的方法与工具已经有不少：

知识库：最先被尝试的是知识库，它解决了知识文本“存得下、找得到”的问题，却不包含逻辑与关系——多数知识库里其实并没有知识，只有海量文本；

RAG：为了更高效地检索，RAG 随之登场。它以更贴近自然语义的方式检索与召回知识，输出也更为专业，但其分析并非深度建立在业务知识之上，更多来自预设的提示词和模型自身的能力——而如上文所述，提示词装不下复杂的企业业务知识。

知识图谱：为了表达业务知识，知识图谱又被推到台前。它把实体对象与关系结构化，支持关系推理，无疑是前进了一大步，但同样称不上完美。复杂的业务逻辑无法仅凭图谱的拓扑结构来表达：关系的构成遵循极为复杂的规则，某个实体会因为一次动作对另一个实体产生影响；整个系统并不是静止的，每个实体节点都在不断变化。这些信息在知识图谱中很难被记录。

但至少，这些努力让人一步步逼近理想中的本体。它们并非“差一口气”，而是通往本体路上绕不开的环节。走到这里，距离真正建成一个本体已经越来越近。

小结

本体不是被一次性设计出来的，而是分块理解、逐步沉淀出来的确定性结构。

二、这个领域走在前面的实践者是怎么做的

谈本体，绕不开 Palantir。它或许并不完美，却是讨论本体时一个现成的参照。

它反复强调一个观点，令人印象深刻：本体代表的是企业的“决策”，而不是“数据”。

每一次决策都会改变本体中的某个实体对象，也因此需要围绕整个系统中的关键实体对象展开分析。

很多做数据平台的人，习惯把一切看成数据——表、字段、指标。但 Palantir 不这么看：数据只是决策的输入，真正要刻画的，是“这家企业到底怎么做决定（分析与行动），以及这个决定会有什么样的影响（预测）”。

暂且放下本体的对象、关系与动作，先来看它为本体运行设定的四个维度：

这四个维度相互协同，保证了本体模型能够相对真实地模拟出业务的动态变化。传统的 ER 模型、维度模型更关注系统的静态结构：多数情况下，数据的查询与变更只是对当下现实世界的映射，或是依托固定指标与规则，在相对确定的场景下做有限的分析。

Palantir 还有一个比喻：数据是“名词”，动作是“动词”，本体要做的，是把名词和动词连成完整的“句子”——“风控业务人员”和“账户”是名词，“冻结”是动词，连起来就是“风控业务人员冻结了一个账户”。

这个比喻点到了本体的关键：它不只是描述世界，还要分析问题，能驱动行动。因此，与传统的关系模型相比，本体在动作、逻辑、安全三个维度上进一步引入了逻辑公理，从而能够反映真实世界中一个对象对另一个对象所产生的影响。

要表达“实体类 + 关系（属性）+ 逻辑公理”，通常要用到 W3C 的 Recommendation（REC）规范，其中包括 RDF、RDFS、OWL、SPARQL 等。

Palantir 在官方文档中同样提到，其本体定义方法受到 RDF、OWL 与 XSD 的启发，但并未完全遵循上述规范。按其在文档中的解释，原因在于 REC 规范难以完整覆盖动作、逻辑与安全三个维度——关于这一点，后续文章将专门展开讨论。

小结

本体的关键不只是描述世界，更在于分析问题、驱动行动——这是它区别于传统关系模型之处。

三、中国企业落地，先要理顺的是顺序

Palantir 的做法隐含一个前提：可以先定义本体，再据此建设数据资产。这与构建数据中台、数据资产管理平台时自上而下推进的做法颇为相似，在其典型客户场景中尤为明显。

流程看似相近，现实中的顺序却正好反过来：多数企业是先有了数仓，如今才回过头来讨论建本体。银行、制造、政企的信息化已经建了几十年，沉淀了成百上千张表与成熟的指标口径。那么，能否以现有的数据治理成果为基础来构建本体？这其实并不是一个是或否的问题——考虑到数据治理的巨大投入，如何基于既有成果构建本体，已经是一个必须回答的问题。

此时本体不再是“设计蓝图”，而是一个“后置的抽象”——先有已经存在的数据资产，再回过头去抽象、去对齐。

这看起来只是顺序问题，却带来一连串实实在在的难题：本体跟既有数据资产、数仓怎么对齐？几百张表怎么映射成对象和属性？

好在，这道坎背后其实藏着一个机会。

企业的数据治理往往已经做了一半。那些辛苦梳理出来的元数据、表结构、字段定义与指标口径，其实已经把业务对象勾勒出了七八分——一张“客户表”的几十个字段，加上信用等级、开户日期这些口径，“客户”这个对象已然呼之欲出。

所以，建本体不是推倒重来，而是站在已有资产上继续往下做。数据资产相关工作向来被视为又苦又累的活，治理得越久越显得力不从心，而本体的构建，或许能让人看到数据治理的最终目标。

小结

建本体不是推倒重来，而是让既有的数据资产找到它的最终形态——这或许正是多年数据治理一直望不到的那个终点。

本体的四个维度——数据、逻辑、动作、安全，基本都能在数据资产中找到对应的形态。而当下，大模型的能力既提供了以自然语言直接消费数据资产的可能，也提供了高效治理数据、构建数据资产平台的能力。

数据资产相关的平台与工具，也因此迎来一次新的机会。

普元也在往这个方向走。这条线上，我们的主要载体是“易数”：在既有的数据治理与数据资产管理能力之上，把智能问数与 AI 辅助治理这类能力并进来，让沉淀在元数据、口径和表结构里的资产，既能继续治理，也能被直接调用。

作者简介

王仕亿，普元信息 AI 科学家，上海交通大学人工智能方向在站博士后。长期聚焦领域本体构建与企业数据治理，主持大型集团 AI 项目领域本体构建，并以第一作者身份在相关国际会议发表数据治理与本体相关研究成果。

本文是系列文章的第一篇。下一篇将从方法层面展开，讨论“从现有数据资产到本体”的实践路径。本体系列将持续更新。

扫码咨询产品专家，了解普元本体能力！