作者：JessicaTalisman （杰西卡·塔利斯曼）

原文：https://metadataweekly.substack.com/p/ontologies-context-graphs-and-semantic

编者按：我们研究语义表示已经几十年了——知识图谱、本体、语义层，JessicaTalisman阐明了它们究竟是什么，以及人工智能需要它们做什么。

2012年，Looker携LookML和其愿景问世：只需定义一次指标，业务用户即可无需SQL即可自助服务。几乎在同一时期，生命科学、医疗保健和研究机构也在构建正式的本体（Ontology）和知识图谱（Knowledge Graph），以对其数据和领域进行建模。

两种方法都旨在使数据更有意义。十年后，一种方法用于构建数据仪表盘，另一种方法则用于药物研发（用于识别癌症疗法）、临床决策支持（用于预防致命的药物相互作用）以及人工智能推理系统（情报机构信赖这些系统，并由其做出关乎生死的重要决策）。

一种技术为我们提供了更漂亮的报告，另一种技术则为我们提供了能够真正理解意义的机器。我们是否从根本上误解了我们试图解决的问题？人工智能即将迫使我们重新审视这一切。

我们原以为语义层可以解决的问题

语义层诞生于一场真正的数据危机。2000年代末，每个拥有多个数据库的组织都面临着同样的噩梦：不同的团队对“收入”的计算方式各不相同，分析师80%的时间都花在数据清理和准备上，而高管们无法信任仪表盘上的数字，因为这些数字会随着构建者的不同而变化。

这个承诺非常巧妙：只需定义一次指标，集中管理，即可让业务用户自助服务，无需编写 SQL 代码。Looker 的联合创始人 Lloyd Tabb 将 LookML 描述为“SQL 的进阶之作”，它是一种可以让数据团队在原始数据库之上创建语义抽象层的语言，使数据“对非技术用户来说也易于访问和理解”。

就其设计目标而言，它确实奏效了。使用语义层的组织确实实现了更一致的指标定义。数据团队也确实规范了自己的工作。语义层完全兑现了它的承诺。

但数据问题已经解决的想法只是假设，并没有得到最终证实。

我们曾以为核心问题在于计算，认为只要能规范指标的计算方式，意义自然就会随之而来。我们曾以为从原始数据到商业理解的路径是一条数学路径。

但意义并不等同于衡量。知道收入的计算公式是 SUM(order_total) WHERE order_status = 'completed'，并不能告诉你为什么第三季度收入下降，哪些客户面临风险，或者你应该采取什么措施。

本体论究竟是什么

当BI行业致力于完善指标一致性时，其他领域却在解决一个截然不同的问题。生命科学机构需要整合数千项研究成果，而这些研究往往使用不同的术语。医疗保健系统需要能够理解患者数据，以及医学知识的临床决策支持系统。语义网社区则在构建标准，使机器能够理解语义，而不仅仅是处理语法。

他们都在构建本体（共享概念的正式、明确的规范），通过对意义进行建模来解决系统冲突和管理歧义。

本体是使用诸如 OWL（Web 本体语言）、SKOS（简单知识组织系统）和 RDF（资源描述框架）等标准对领域知识进行结构化表示。它们定义了事物的类别、这些事物可以拥有的属性、特性（本体成员元素的描述性修饰），以及它们之间的关系，所有这些都以机器可读的格式呈现，并支持逻辑推理。

医学本体论的一个很好的例子是基因本体论（Gene Ontology，简称GO），二十多年来一直是生物信息学的基础。它不仅定义了基因的度量指标，还构建了基因模型，阐明了基因的本质、参与的生物过程、执行的分子​​功能以及所属的细胞组分。最终，研究人员可以通过查询GO来可靠地获取诸如“该通路中基因的数量是多少？”之类的信息，或者理解这些生物学概念之间的相互关系。

另一个经过充分验证的例子是医疗保健领域的SNOMED CT，这是一个包含超过35万个概念和数百万个关系的综合性临床术语库和配套本体。它使系统能够理解“心肌梗死”和“心脏病发作”指的是同一件事，它是一种“缺血性心脏病”，并且与症状、治疗和解剖结构有着特定的关联。

当我们试图用本体论来定义意义时，归根结底，我们是在讨论知识表示。除了度量之外，本体论还致力于组织和管理知识，以便支持对数据等信息的准确捕获和表示。

你可能会想，与语义层之间的差异为什么重要？这是因为它们的结构和目标从根本上来说是不同的。

• 语义层
  通过将文本标签规范化为自然语言，更可靠地告诉你诸如收入是多少或网页访问次数之类的信息。
• 本体
  可以表示客户被定义为一个具有特定属性和特性的类。该客户下了订单，并且所订购的商品通过特定直接和间接关系与其他产品在特定定义的市场中相关联。该市场被定义并表示为具有特定特征。由于本体支持推理，系统能够从显式关系中推断并推导出新的知识。

语义层架构体现了一种截然不同的知识理论。语义层旨在进行分析，帮助人们通过BI工具，使用自然语言来理解数据。本体则旨在进行推理，帮助系统和人工智能充分理解领域，从而消除数据歧义、探索场景、进行推断并支持决策。

Palantir看到了我们没看到的东西

当 BI 行业在 2012 年完善 LookML 时，Palantir 正在情报机构和企业中推广 Foundry（Palantir提供的本体操作系统），并采取了不同的策略——本体论而非语义层。

Palantir 致力于构建用于执行决策的系统，在这些系统中，理解实体关系和因果链至关重要。例如，情报分析、供应链协调和金融犯罪检测。

该架构以场景为先，而非指标为先。在 2012 年，这看起来像是为大多数企业并不面临的问题而过度设计。但到了 2026 年，随着人工智能暴露出基于 YAML 的指标定义的局限性，这种做法显得极具前瞻性。

他们一直都是对的吗？还是说他们解决的问题与大多数组织实际需要的问题并不相同？

从仪表板到AI推理

答案可能在于理解 Palantir 实际上构建的是什么，不仅仅是本体，而是运营场景图谱（Operational Context Graph）。

场景图谱究竟捕捉了什么

尽管 Palantir 的本体是封闭的，并且依赖于工具，但有人可能会认为，他们构建的是一个专有的、特定于 Palantir 工具和环境的场景图谱。

当副总裁批准一项超出政策限额的折扣时，传统系统会记录该决定，但不会记录其背后的原因。当维修技师修改某个流程时，其理由仅存在于他们的脑海中，而非系统中。场景图谱旨在创建此类决策推理的动态记录，回答“为什么允许 X 发生？”，而不仅仅是“发生了什么？”

理解二者的区别至关重要。知识图谱告诉你客户下了订单，场景图谱也是一种知识图谱，场景图谱可以告诉你，尽管订单违反了标准条款，但为什么还是被批准了；之前有哪些类似的例外情况；谁有权批准订单；以及哪些情况使这种偏差合理化。

构建此类系统需要正式的方法来表示过程知识。由Cefriel的研究人员与西门子、博世等工业合作伙伴共同开发的程序知识本体（PKO），提供了场景图谱所需的语义架构。PKO区分了程序（如何完成某事的抽象规范）和执行（执行这些程序的具体实例）。安全锁定程序规定了通用步骤，锁定执行则表示特定技术人员在特定日期执行该程序，并记录了特定观察结果和结果。

该本体将知识组织成六个概念领域：流程规范、细粒度操作步骤、变更跟踪（谁在何时修改了什么）、执行历史、代理角色和权限以及支持文档。这些共同构成了AI智能体处理模糊且需要判断的情况所需的审计跟踪和先例记录。

西门子等公司已在实践中证明了这种方法的有效性。通过将微电网设备的运行建模为具有特定状态和转换的程序，他们将之前未记录的控制器逻辑转化为明确的、可查询的知识。电动汽车车主现在可以了解他们的充电模式为什么出现了这种状况——不仅仅是充电速度慢，而是了解其原因（光伏发电量低、电网需求高、电池容量限制），以及最佳充电条件通常何时出现。运营商可以分析各个设备的执行模式，并在完全场景可见的情况下排查异常情况。

但关键挑战在于：这本质上是一个知识管理问题，场景图谱需要系统地挖掘隐性知识——观察工作实践、访谈专家、提取未记录的推理过程，并将其编码成形式化表示。如果没有对知识工程的投入，决策轨迹就会被困在Slack聊天记录、电子邮件往来和机构记忆中，任何系统都无法对其进行索引或查询。

能够解决这个问题的组织——将上下文捕获视为核心竞争力而不是附属项目——将拥有人工智能时代可能具有决定性竞争优势的能力：不仅能够解释发生了什么，还能解释为什么允许它发生

YAML问题

让我们直截了当地指出我们的错误之处：试图在 YAML 文件中编码业务含义。

看看 dbt 语义层的工作原理：MetricFlow的工作逻辑是“利用语义模型和指标 YAML 配置中的信息，在用户的数据平台上构建和运行 SQL”。现代语义层的整个架构都建立在 YAML 声明可以捕获业务语义这一假设之上。

yaml

semantic_models:

- name: orders

defaults:

agg_time_dimension: order_date

entities:

- name: order_id

type: primary

measures:

- name: order_total

agg: sum

对于指标治理而言，这的确是一个非常不错的解决方案。但它绝非业务模型，YAML 配置是计算模型，它捕获的是 SQL 表和列的表示形式。它们是数据库实体，仅此而已——缺乏关系、自然语言、定义和丰富的上下文。它们之间的关系仅仅是连接路径，而缺少语义关系或业务流程。

这与本体论如何表示同一领域形成对比：

Turtle（简介RDF三元组语言）

EXPLICIT::Alice :placedOrder :Order001 .

:Order001 :hasItem :Item001 .

:Item001 :itemProduct :Laptop .

:Alice :customerLifetimeValue “1250.00”^^xsd:decimal .

INFERRED (what you get automatically):

:Alice a :HighValueCustomer . # Reasoner infers this

:Alice :purchased :Laptop . # Property chain inference

:Order001 :orderedBy :Alice . # Inverse property

:Laptop :frequentlyBoughtWith :Mouse . # Symmetric property

:Alice :knowsCustomer :Carol . # Transitive reasoning

本体表示能够捕捉到 YAML 无法表达的含义，本体可以描述订单是一种业务交易类型，它由客户下单，而客户又是一种特定类型的人，订单不同于报价单和发票。本体的功能远不止于标签和验证这些标签是否存在，本体包含支持推理的逻辑语义断言。

我们原本以为结构化元数据就足够了，但整个科技行业正在逐渐意识到（尽管进展缓慢），我们之前想当然地认为数据团队可以对业务逻辑进行建模，我们在这三个方面都错了。（这三个方面指：技术手段层面—— 误判 “结构化元数据足以承载业务语义”，团队能力层面—— 误判 “数据团队可独立完成业务逻辑建模”，底层载体假设层面—— 误判 “YAML 类静态配置格式能捕捉复杂业务语义”）

尽管元数据确实具有结构性，但即便名为“语义层”，它也绝非语义性的。其逻辑仍然停留在语法和计算层面，缺乏表征性、描述性和上下文丰富的特性。要构建本体，需要领域专业知识，以及正规的知识工程技能，而大多数数据团队恰恰缺乏这些技能。本体构建需要理解如何表示知识，而不仅仅是如何计算指标。

这绝非对数据团队的批评，我们必须面对一个残酷的现实：

就像你不会要求财务分析师构建临床术语一样，你当然也不会指望数据工程师来构建你所在领域的知识结构模型，或者你会吗？

人工智能为何改变一切

2025

年10月，dbt Labs在Coalesce大会上发布了一项引人注目的公告：他们将根据Apache 2.0许可证开源MetricFlow。给出的理由是：“事实证明，语义层是构建人工智能与结构化数据之间桥梁的关键组件。”

他们对问题的判断是正确的，但解决方案可能需要超出他们当前架构所能提供的资源。

业界已经认识到，大语言模型（LLM）需要的是场景和意义，而不是仪表盘。LLM需要理解事物是什么、它们之间如何关联以及可以采取哪些行动。本体和知识图谱提供的正是这些，而不是语义层的功能。语义层用于查找，而本体用于提供上下文和推理。

场景需求

我们已经明确

，AI智能体需要运营场景（Operational Context）。Anthropic 的工程团队最近写道——“场景工程是一门设计系统的学科，该系统以正确的形式提供正确的信息和工具，使LLM能够获得完成任务所需的一切。”

在此框架下，场景包括“提示词、记忆、小样本示例、工具描述”，即模型运行的完整语义环境，这并非语义层能够完全提供的。

知识图谱和本体论正是为提供此类上下文而专门构建的。它们不仅表示数据，还表示赋予数据意义的概念、关系和约束。LLM 可以查询知识图谱，并获取远超语义层和度量指标定义所提供的结构化领域知识。

这就是为什么医疗保健人工智能系统越来越依赖临床本体，药物研发平台构建于生物医学知识图谱之上，以及企业级人工智能部署开始融合语义技术的原因。那些在正规知识表示方面投入巨资的领域已经走在了场景理解的前沿，能够展示人工智能推理在规模化应用中的实际效果。

人工智能系统已经证明，我们必须构建动态且描述性的知识基础设施，以支持人类和机器对知识的理解和运用。由于人工智能在自然语言领域运作，因此SQL 化的标签和数据句法表示无法满足人类对数据表示方式的迫切需求。

尽管指标定义最终都是为了方便人类通过可视化工具和仪表盘进行理解而优化的，但其底层语义实际上却缺失了，知识图谱和本体则兼顾了机器和人类的可读性，同时还支持推理和推断。

真正的架构差异

让我们来

看看语义层和本体架构提供了哪些功能：

语义层是为人通过 BI 工具来使用而设计的。它们提供指标定义和计算、用于分析的维度模型、SQL 抽象（因此业务用户无需具备技术技能），以及跨报告工具的一致性。它们回答基于指标的问题，并且仅限于“X 是什么？”

本体和知识图谱旨在帮助理解系统和领域。它们提供规范的概念定义和分类、具有语义含义的显式关系类型、对逻辑推理的支持、通过标准格式（RDF、OWL、SKOS）实现的互操作性，以及将领域专业知识集成到机器可读的形式中，它们提供场景信息，而无需SQL和表约束。

架构上的差异反映了人们对数据系统用途的不同理论。

• 语义层概念源于BI行业对报告和指标的关注，其核心问题在于如何实现跨工具和团队的一致性衡量，解决方案是集中式指标管理。
• 本体论是一种神经符号人工智能形式，它源于知识管理、图书馆学和人工智能研究，这些领域的核心问题在于如何表示和推理领域知识。解决方案是采用标准进行正规的知识表示，从而实现互操作性和推理能力。

虽然两种方法都有效，但它们的目的不同，旨在实现不同的目标。

2026 年的难题

人工智能

作为数据架构的主要使用者，其出现给业界带来了一些棘手的问题。

是否存在折衷方案？能否构建“场景感知的语义层”，既能维护指标治理，又能提供本体论所赋予的丰富语义信息？dbt Labs 与 Snowflake 和 Salesforce 于 2025 年共同加入的开放语义交换 (OSI) 计划，似乎正朝着这个方向发展。

但是，指标定义和规范本体之间的差距可能太大，一开始就难以弥合，因为 YAML 配置和本体格式代表了不同的理论、操作要求、开发资源和含义。

语义层能否演化成知识图谱？数据基础设施已经存在，指标定义也已经存在。组织能否在其语义层之上叠加本体结构，或者将其与语义层连接起来？

一些公司和研究机构正在尝试。但是，向一个专为 SQL 生成而设计的系统中添加类、属性和推理规则，可能需要进行根本性的架构变更，实际上相当于从头开始构建知识图谱。

我们是否需要一个全新的类别？或许“语义层”和“本体”都无法准确概括人工智能原生数据架构的真正需求。“场景工程‘’（Context Engineering）已经获得了广泛关注，Shopify 首席执行官 Tobi Lütke 将其描述为“为 LLM 能够合理解决的任务提供所有必要的场景信息”的艺术。

但场景工程是一种实践，而非平台。“场景操作系统”究竟会是什么样子？或许会是将指标治理与知识表示相结合的某种东西——但这说起来容易做起来难。

dbt 的语义层在未来将扮演怎样的角色？MetricFlow 的开源以及 OSI 倡议表明，dbt Labs 将人工智能视为未来的主要应用场景。他们的文档现在将语义层描述为能够让“AI智能体利用可信的指标定义进行受控的对话分析”。

但它受制于对话分析足够了吗？还是说智能体需要只有规范本体和知识图谱才能提供的领域知识和场景理解？

指标优先范式是否已经过时？这或许是最难回答的问题。整个现代数据架构都建立在“测量是理解的基础”这一假设之上。但人工智能系统的推理方式与人类分析师截然不同，它们需要的不是图表形式的指标，而是概念、关系和推理能力。

这是否意味着以指标为先的范式已经过时，还是意味着指标将成为更丰富的知识架构的一个输入？

但我们以前不是听过这种说法吗？

这里有一

个令人不安的问题：本体论是否开始了又一个炒作周期？

语义网本应在20年前彻底改变互联网，知识图谱也曾被认为会取代数据库。然而，大多数尝试构建本体的组织要么失败，要么最终放弃。

质疑者的观点：本体构建需要稀缺技能（知识工程、形式逻辑）、多年的投入以及很少有公司能够坚持的组织承诺。或许语义层架构本身并没有错，或许我们是在寻找解决组织问题的技术方案。

反驳观点：这次情况不同，因为人工智能改变了格局。医疗保健和生命科学领域投资本体论并非出于追逐潮流，而是因为他们的工作需要形式化的知识表示。基因本体论已成为生物信息学20多年的基石，因为其他替代方案根本行不通。

如今，人工智能使得知识推理对所有企业都至关重要。问题不在于本体论是否有效（在那些投资于本体论的领域，本体论确实有效），而在于你的组织是否会真正构建一个本体论。

实际上这意味着什么

如果你要

构建一个AI分析器，你需要的是知识表示，而不仅仅是指标。你的AI不会读取仪表盘，而是读取语义表示。如果这种表示只包含指标定义，而没有概念层次结构、关系类型或领域知识，那么你的AI只能回答计算问题，而无法回答推理或推断问题。

如果你正在评估语义层，请问自己：“这是面向人类还是面向人工智能？”答案决定了指标治理是否足够，或者你是否需要更丰富的知识建模。大多数组织两者都需要，但面向人类和面向人工智能的构建可能需要不同的架构。

如果你正在考虑构建知识图谱或本体，请做好投入不同寻常的准备。与数据团队可以相对快速定义的语义层不同，本体需要领域专业知识、知识管理和工程技能，并且通常需要数年的迭代完善。那些在生命科学、医疗保健和金融等领域取得成功的组织，都将知识表示视为核心竞争力，而不是产品或项目。

最终的赢家将是那些探寻意义而非仅仅追求计算结果的人。一致的指标只是基本要求，真正具有竞争优势的，是那些数据架构能够支持人工智能对概念、关系和领域知识进行推理，超越简单的聚合和过滤的组织。

接下来我们该何去何从？

我认为真

正的事实是：语义层与本体框架本身可能过于狭隘。

语义层是为人类通过仪表盘获取数据而设计的。本体则是为那些以知识推理（而不仅仅是数据查询）为核心需求的领域而设计的。两者都有其合理之处，具体取决于手头的任务。

但人工智能改变了局面。

问题不在于是否采用语义层或本体，而在于你的数据架构能否为人工智能系统提供所需的知识，使其能够对你的领域进行推理。对于某些用例（例如指标查找、计算一致性、基础分析），语义层仍然足够。但对于其他用例（例如复杂推理、推断、意义提取和特定领域人工智能），语义层则不足以胜任。

更重要的问题是：我们现在该怎么办？

无论我们称之为语义层2.0、知识图谱、场景工程、场景图谱，还是其他什么全新的说法，基于指标的思维时代都即将结束。人工智能系统需要理解你的领域：概念、关系、约束和推理规则。

知识架构与定义指标完全是两码事，需要的技能也截然不同。它更接近图书馆员、分类学家和知识工程师几十年来一直在从事的工作，其工作流程也与数据团队如今的典型工作流程大相径庭。它要求理解如何正式地表示领域知识，而图书馆学、信息架构和语义网研究等领域多年来一直在发展这些技能。

那些撸起袖子、着手构建能够真正理解自身领域逻辑的人工智能系统的组织将会胜出。那些不敢迎接挑战的组织，虽然能做出非常可靠的计算结果，但却缺乏人工智能真正需要的知识基础设施。

问题不在于你最终是否需要它，而在于你是现在就开始建设，还是等到你的竞争对手领先三年之后再行动。

医疗保健和生命科学行业早在20年前就做出了投资，Palantir在2012年推出了封闭式本体系统，你的决定是什么？