专题深读 · 2026-11-04 · 进阶 · 作者 bombong

本体的虚与实：是护城河还是潮流，引入前需要权衡什么

本体正在成为大型数据平台的基本功能，因此这一概念本身已不再构成差异化。本篇作为终篇，区分炒作与实际价值，比较语义层、知识图谱和平台本体，并整理出从小处着手的检查标准。

系列收尾：第 1~3 篇留下的问题
竞争格局：当本体成为基本功能
比较：语义层·知识图谱·平台本体
'虚'：四种夸大的期待
'实'：留下的三种价值
失败模式与应对
引入判断检查清单与 90 天启动步骤
延伸阅读

要点

Microsoft Fabric IQ 将本体（预览）列为基本项，dbt 语义层则通过 MCP 服务器将指标连接到 AI 工具。因此，留下来的差异化不在于本体这一概念，而在于由谁负责定义并保持其最新。
'虚'是指以为只要建好本体、智能体就会自行正确行动的期待，全公司统一模型，以及在计算中忽略维护成本（'本体税'）的习惯。
'实'是指业务术语只定义一次，为智能体提供规则和上下文，以及持续更新监管所要求的数据血缘。不过，让规则真正得到遵守是确定性执行层的职责。
失败通常不发生在构建阶段，而是在其后。无人负责的图谱、想把范围扩展到全公司的贪念、建好一次就搁置的静态产出物，是典型模式。
从一个用例和一份需要回答的问题清单开始。只公开定义稳定、负责人明确的实体，并从一开始就定好更新周期。

系列收尾：第 1~3 篇留下的问题

本文是“本体的虚与实”系列的第 4 篇，也是最后一篇。前三篇探讨了本体是什么、企业为何寻求它，以及在金融业这类监管严格的领域会带来哪些用处和成本。第 3 篇的结论可以这样概括：把各系统中定义不同的客户、产品归入共同概念，确实有明显效果。但这种效果只与所付出的映射、术语管理、责任体系成本相称。因此，最好从一项业务、一份报告小规模起步。

本篇将这一结论推而广之。问题有三个。第一，曾被视为 Palantir 标志的本体成为通用数据平台的基本功能后，还剩下什么差异化？第二，围绕本体的期待中，哪些是夸大（'虚'），哪些是实际价值（'实'）？第三，我们的组织是否应该引入？如果引入，从哪里开始？

本文并非推荐特定产品。下面的比较和检查清单，是无论选择哪个平台都同样需要考量的标准。

竞争格局：当本体成为基本功能

Microsoft 将 Fabric IQ 介绍为“企业智能层”的一部分。Fabric IQ 由两个核心项组成。一个是本体（ontology，文档标注为 preview 阶段），另一个是 Power BI 语义模型（w1）。根据文档，本体定义实体类型、属性、关系、规则和指标，并将其绑定到实际企业数据上。这样，人、应用程序和 AI 智能体就会使用同一套词汇（w1, w2）。本体不是独立的数据存储。它是只保存定义和绑定的“虚拟上下文层”，实际查询在源数据系统中执行（w2）。此外，可以从现有语义模型创建本体，也可以导入 RDF、OWL 等开放标准（w1）。官方已公告旧版本体体验将于 2027 年 1 月 31 日终止（w2）。这意味着该功能仍在快速变化。

语义层方面也能看到同样的趋势。dbt 文档说明，将指标定义从 BI 工具移到建模层，可以让各部门使用相同的定义。还表示，Claude、ChatGPT 等 AI 工具通过 dbt MCP 服务器连接到语义层后，会使用受管理的指标，而不是去猜测原始表（w4）。可以说，“为智能体提供业务含义”这一承诺，如今已由多个层级的产品共同提出。

这样一来，仅凭本体这一概念无法形成护城河。数据库工程师 Vonng 的博客文章（w7）主张得更激进：Palantir 的 Ontology 在技术上就是数据库建模（对象类型=表，链接=外键），真正的护城河来自政治关系网、安全许可、前线部署工程师（FDE）等其他方面。这应被视为一位批评者的观点。但其对实务的启示很明确：概念通用化之后，剩下的差异化在于组织实际达成并维护定义共识的能力、与源系统的连接质量，以及做这些事的人。

平台本体的位置 本图依据 Fabric 文档绘制。本体不复制数据，只保存定义和绑定。实际查询在源系统中执行。

比较：语义层·知识图谱·平台本体

Thoughtworks 的文章（w6）将模式（schema）、受控词表、语义层、本体、知识图谱视为一条连续谱。越往上，表达能力越强。但成本和治理负担也随之增加，需要有人积极负责。该文将本体区分为“设计图（类、关系、规则）”，将知识图谱区分为“用实际数据填充该设计图的结果，也是智能体实际查询的对象”。

从目的看，差异很明显。语义层擅长标准化指标和定义。但在承载智能体要追踪的关系或逻辑方面存在局限（w6）。构建成本相对较低，维护通常由数据团队通过建模代码负责。智能体连接方面也已有像 dbt 那样通过 MCP 服务器的方式（w4）。知识图谱擅长多步关系推理。但由于需要持续对实际数据进行 Entity Resolution（找出并合并同一对象）和关系抽取，维护负担最大（w5, w6）。平台本体（Palantir 型、Fabric IQ）将定义、规则、指标、绑定、图谱整合在一个平台内。起步容易，但以该平台的数据基础为前提。Microsoft 文档（w1）也写明，没有统一的数据基础就无法从 IQ 层开始。

锁定风险需要单独考量。Vonng 的文章（w7）举了一个例子：2017 年纽约市警察局与 Palantir 终止合作时，曾公开质疑未能以可迁移的格式取得分析结果。而 Fabric 文档则表示可以导入 RDF、OWL 等开放标准（w1）。因此，签约前应确认定义能否以标准格式导出，规则和指标是否只被困在特定引擎中。Thoughtworks（w6）建议，既然图数据库、数据目录、主数据工具、语义层平台已经覆盖了该领域的一部分，就应有意识地判断“在哪些地方，直接建模优于现有工具的配置”。

'虚'：四种夸大的期待

第一，“只要建好本体，AI 就会自行工作”的期待。Thoughtworks（w6）明确指出，本体虽然能在行动前告诉智能体哪些是被允许的，但那只是知识，而非强制。只有当确定性运行时检查规则、遵循检查结果，并能证明已进行检查时，规则才具有约束力。许多运营规则更适合放在策略引擎中。检索质量也是如此。价值来自用实际数据填充的图谱，而非模式。设计图是相对容易的部分。

第二，全公司统一模型。Thoughtworks（w6）称全公司主模型是“给‘煮沸大海’陷阱起了个好听的名字”。并指出，试图为整个现实建模的项目，大多在一年左右后因无法展现价值而告终。Atlan 的文章（w5）也写道，试图抽象表达“整个业务”的图谱既没有停止点，也没有明确的负责人。

第三，在计算中忽略维护成本的习惯。Atlan（w5）将持续管理模式的成本称为“本体税（ontology tax）”。还引用 Improvado 的 2026 年综合资料，称企业知识图谱项目中能越过试点阶段的不到 15%。第四，只换了名字的数据建模营销。正如 Vonng（w7）所指出的，数据建模和系统集成是真正有价值的工作。问题在于把这份价值归功于“本体”这个词。具体追问供应商所称的“本体”功能与现有模式、语义模型有何不同，是第一道防线。

'实'：留下的三种价值

第一是业务术语的统一定义。Microsoft 培训资料（w3）中的例子很好理解。销售团队的“客户”包括经销商，而服务团队的“客户”仅指直接购买者。这样一来，同时查询两个模型的数据智能体就无法知道该用哪个定义。本体通过声明一个所有语义模型都要遵循的共识定义来解决这个问题。日期筛选器或计算列这类只在报告内有意义的内容，仍保留在语义模型中。Thoughtworks（w6）强调，这一价值与其说来自映射本身，不如说来自其后的共识，以及在含义变化时持续更新的负责机制。

第二是智能体行动时所需的规则、指标、权限和审计上下文。根据 Fabric 文档（w2），可以用自然语言承载规则并将其关联到实体。这样就不必在每个提示词、智能体和应用中复制相同的业务指令。指标在源语义模型继续拥有所有权的情况下被导入，使智能体不必新建计算公式，而是使用组织定义的计算。权限和生命周期通过 Fabric 权限体系管理。本体智能体的变更采用“提案优先（proposal-first）”方式，经人工审核后才生效（w1, w2）。不过，如前一节所述，实际拦截并记录执行的机制需要另行设置（w6）。

第三是用于监管应对的数据血缘（数据谱系）。DataHub 的文章（w8）引用了巴塞尔委员会 2023 年 11 月的检查报告。在接受评估的 31 家 G-SIB（全球系统重要性银行）中，完全满足 BCBS 239 全部 14 项原则的只有 2 家。报告指出，许多银行仍缺乏共同的分类体系和完整的数据血缘。该文还称，欧洲中央银行于 2024 年 5 月最终确定了风险数据汇总与报告（RDARR）指引。该文强调的核心是：为应对审计而一次性绘制的血缘图，在下一次检查前就会过时。血缘只有从实际运营元数据中持续更新，才能用作审计证据。该文主张同一血缘基础也可用于 AI 智能体治理，阅读时应考虑到这是血缘工具供应商的视角。

失败模式与应对

Atlan（w5）总结称，企业知识图谱很少在构建阶段失败，而是在此之后因三方面问题叠加而崩溃。组织层面缺少负责人、范围和赞助方；技术层面出现本体漂移、模式僵化和 Entity Resolution 失败；经济层面则是“本体税”成为问题。共同原因在于，没有把图谱作为在受治理的元数据之上持续更新的一层，而是将其搁置为由人工填充的静态产物。该文引用的一项 2025 年调查显示，67% 的已中止项目将内部图谱专业能力不足列为主要原因。该文将此解读为“与其说是缺乏技术，不如说是没有指派持续维护图谱的人”。

针对无人负责的图谱，处方是像对待产品一样对待所有权。Thoughtworks（w6）建议将本体“作为产品而非项目”来对待：需要对有争议术语的决定权、版本管理、与记录系统核对的固定周期，以及淘汰过时概念的流程。它警告说，如果没有管理者和定期的核对工作，模型会在两个季度内过时。

应对范围扩张的办法是将范围限定在单个用例上。Thoughtworks（w6）认为，一次性构建全企业模型的传统方式需要 12～24 个月才能产生价值；相比之下，从单个高回报用例起步的产品方式每次迭代只需 4～8 周。Atlan（w5）转述了从业者的报告：源系统超过 10～15 个时，会到达一个盈亏平衡点，实体重复和模式不一致使集成变得脆弱。针对被搁置为静态产物的问题，则通过确定捕捉漂移的更新周期和负责人来应对。即使表名发生变化，或客户在 CRM 中被合并，也不会报错。因此，如果没有既定的验证，图谱会悄无声息地给出错误的事实（w5）。

引入判断检查清单与 90 天启动步骤

判断是否引入时，第一个问题用 Thoughtworks（w6）的话说，不是“想不想要本体”，而是“解决眼前问题所需的最小语义结构是什么”。该文认为，分析和检索所需的大部分价值，已经由管理良好的语义层和细致的元数据提供。该文列举的本体能证明其成本合理的领域包括多步推理、约束条件自动检查和跨领域集成。因此，如果当前的问题是“各部门的营收数字不一致”，应先考虑语义层。如果是像“订单→配送→温度传感器→冷链脱链”这样需要沿关系追踪才能得出答案的问题（w1 中的例子），则值得考虑图谱和本体。

从小处起步的步骤如下。该文将最初 90 天设为一个验证阶段。1) 选定一个业务用例，让业务部门亲自写下当前系统无法回答的问题。Thoughtworks（w6）将此作为预算审批的条件，并建议把每个问题与决策或金额挂钩。如果提不出问题，那不是缺少语义结构，而是价值不明确。2) 选定实体。只公开定义稳定、多个团队需要且负责人明确的实体（w3）。3) 用 LLM 从现有的模式、语义模型和 wiki 中提取初稿，专家只负责审核（w6）。自动生成的结果，其名称、键和关系方向需要由人确认（w3）。4) 绑定到源数据，用实际问题测试答案。像 Fabric 这样，各产品有各自的数据绑定条件，需提前确认。根据培训资料（w3），要直接用绑定的数据回答问题需要 Direct Lake 模式，Import 和 DirectQuery 模式仅支持定义。5) 确定更新周期和漂移检查负责人，并一直运行到第一次定期检查。

90 天结束时要确认三件事：最初写下的问题中，实际能回答的有多少个？各部门之间同一术语的数字不一致是否减少？源系统变更时，谁在几天内修正了定义？如果没有人能回答第三个问题，就应在扩大范围之前先重建所有权体系。

90 天启动步骤

1
问题清单由业务部门亲自写下当前无法回答的问题
2
选定实体仅限定义稳定、负责人明确的实体
3
生成初稿·审核LLM 生成初稿，专家审核
4
绑定·测试用实际问题验证答案
5
更新周期指定漂移检查负责人

从单个用例开始，完整走一遍直至更新周期的步骤。

引入前检查

必要性

是否是需要沿关系追踪才能解答的问题
语义层是否已经足够
每个问题是否都关联到决策或金额

所有权

每个术语是否都有定义负责人
有争议术语的决定权是否已明确
是否有更新周期和负责人

控制·可移植性

是否有单独的执行层来强制执行规则
变更是否经过人工审核
定义能否以开放标准导出

无论选择哪个平台，都要同样确认的项目。

延伸阅读

想先建立概念全貌，Thoughtworks 的文章（w6）最合适。从模式到知识图谱的连续谱、三种失败原因、产品方式的五项原则都集中在一篇文章中。之后可以通过 Atlan 的文章（w5），从组织、技术、经济三个方面了解构建之后哪些环节会崩溃。

平台本体实际做什么，可以参阅 Microsoft Learn 上的 Fabric IQ 概述（w1）和本体概述（w2）。哪些内容放进本体、哪些留在语义模型中，培训模块（w3）有简短介绍。作为对照，同时阅读 dbt 语义层文档（w4），可以分清两层各自的角色。

批判性视角可参阅 Vonng 的文章（w7），监管视角下的数据血缘要求可参阅 DataHub 的文章（w8）。两篇文章的作者立场（评论者、工具供应商）都很明确，建议将观点与所引用的事实分开阅读。“本体的虚与实”系列到此结束。用一句话概括：本体的价值不在于术语本身，而在于守护定义的人和流程。

参考资料

延伸阅读（官方文档与技术博客）

由 AI 根据所列参考资料撰写并经过审核。详情请查看原始资料。