场景图谱系列3：场景图谱——本体论之争的误区

作者：Kirk Marple

原文：https://x.com/KirkMarple/status/2008082060817342869

场景图谱系列— 第3部分（共3部分）

这是探索新兴场景图谱基础设施层的三篇系列文章之一，首先探讨智能体为何需要运营场景才能捕获决策轨迹，然后深入研究构建时间事实存储的技术架构，最后解决困扰业界的本体论问题。这些文章共同描绘出一幅完整的图景，展现了构建企业人工智能所需的上下文层究竟需要哪些要素。

第一部分：上下文层

第二部分：事件时钟

第三部分：本体论问题（本文）

过去两周，关于上下文图谱的讨论呈爆发式增长。这波热议由基石资本（Foundation Capital）发布的《上下文图谱：人工智能的万亿级机遇》一文率先引爆，阿尼梅什・科拉塔纳（Akoratana）发布的关于协调系统的系列推文，进一步深化了该领域的技术框架体系；丹尼尔・戴维斯（Daneil Davis）则发表《上下文图谱宣言》，将这一概念与语义网的发展积淀关联起来。我本人也撰写了两篇回应文章，分别探讨业务运营场景层与事件时钟的构建方法。

这场对话很有价值，其中提出的问题——我们如何赋予智能体组织记忆？我们如何捕捉决策轨迹？我们如何构建能够从实际工作中学习的系统？——都是值得探讨的正确问题。

但我发现一种框架正在形成，这个框架我认为它忽略了重点。鉴于我已经构建场景基础设施三年多了，我想提出一些不同的看法。

我的论点很简单：实体本体论的大部分问题已经由现有标准解决。真正尚未解决的问题是时间有效性、决策轨迹和事实解析。学习有助于解决这些问题，但对实体层面却无济于事。这种二分法并非预设与学习的对立，而是先采用基础，然后再学习新的内容。

当下争论的核心框架

当前的讨论已经围绕着一个二分法展开：预设本体与学习本体。

一方面是Palantir（美国一家数据公司，译者注）。这种观点认为，Palantir凭借预先设定的本体论，打造了一家市值超过4000亿美元的公司——预先定义模式，将杂乱的企业数据映射到其中，然后部署工程师为每个客户进行定制。这种方法虽然有效，但成本高昂、速度缓慢且难以扩展。

另一方面：代表未来方向的习得本体论。源于实际工作运作方式的架构，而非人为设计。将智能体轨迹作为训练数据，决策轨迹编译成企业组织的世界模型。这样的本体论并非预先设定，而是需要去探索发现。

贾亚（Jaya Gupta）直接把它放进一个最新帖子：

Animesh Koratana 对此进行了扩展，提出了一个技术框架——五个互不共享键的坐标系（时间线、事件、语义、归属、结果）。其论点是，智能体轨迹是学习嵌入的训练信号，这些嵌入编码了跨这些坐标系的“连接兼容性”，本体论正是从这些行走过程中涌现出来的。

这种框架在理论上很精妙，它将可学习的本体论定位为民主化的未来，与Palantir昂贵的定制化过去​​形成对比。

只有一个问题：它忽略了二十年来已有的本体论研究成果。

伪二元对立：预设VS习得

预设框架与学习框架提供了两种选择：

1. Palantir模式
   ：花费数月甚至数年时间，让前线工程师为每个企业构建定制本体。这种方法成本高昂、速度缓慢，但对于负担得起的企业来说行之有效。
2. 习得模式
   ：让结构从主体的轨迹中涌现。不要预设，而要探索，本体论会从工作实际发生的方式中自我构建。

这种论述方式遗漏了第三种选择，而这种选择其实一直就在我们眼前：

目前的讨论似乎将本体论视为要么是昂贵的定制产品（Palantir），要么是足够多的智能体运行后涌现出的属性（学习型视角），但双方都忽略了过去二十年来在本体论领域所做的研究。

已经存在的本体

在讨论习得型本体论之前，值得一提的是，这方面的工作在生产系统中已经有很多了，让我介绍一些在本次讨论中似乎被忽略的现有技术。

Schema.org

Schema.org是一个面向网络结构化数据的协作词汇体系。它由谷歌、微软、雅虎和Yandex于2011年创立。它为重要的实体定义了规范类型，例如：人、组织、地点、事件、产品、创意作品等等，以及数百种其他实体。

Schema.org这并非纸上谈兵，而是在数十亿个网页上得到了实际应用。当你在谷歌搜索结果中看到丰富的摘要信息——活动日期、产品价格、食谱评分——那就是Schema.org正在解析和显示标记。

这些类型定义明确，“人员”包含姓名、职位和与“组织”的雇佣关系，“组织”包含名称、地点和员工，“事件”包含开始日期、结束日期、地点和组织者。

这不是需要某人构建的自定义本体，它已经存在，并且有人维护。它的设计初衷正是为了满足上下文图谱所需的实体建模需求。

WAND 和 CDM

当我重新发现它时，连我自己都感到惊讶：微软的通用数据模型（为 Dynamics 365、Power Platform 和微软企业级产品栈提供技术支持的架构）竟然是从其他地方获得许可的。

WAND （Warehouse Integrated Designer，仓库集成设计器）数十年来一直致力于构建企业分类体系和本体，他们的工作比当前的 AI 浪潮早了好几年。当微软需要一个用于企业实体（例如客户、联系人、潜在客户、商机、案例、产品和市场活动）的规范数据模型时，他们并没有从零开始构建，而是从已经完成这项工作的团队那里获得了授权。

CDM （Microsoft 通用数据模型）定义了企业软件运行所依赖的实体，这并非仅仅停留在理论层面，而是在生产环境中，在数千家运行微软商业应用程序的组织中得到实际应用。

这一点鲜为人知，但却意义重大。企业本体论问题由那些对企业如何构建运营模型有着深刻理解的专家们长期研究。微软并没有重新发明轮子，而是获得了授权。

行业特定标准

除了Schema和CDM，还存在着经过多年实际应用不断完善的行业特定本体。例如，医疗保健领域有用于临床数据交换的FHIR，用于医学术语的SNOMED，金融领域有用于金融工具和商业实体的FIBO，制造业、物流业、能源业等，每个领域都有其特定的标准。

这些并非学术探讨，而是实际生产基础设施。例如，FHIR 定义了如何表示患者、病情、药物、观察结果和临床工作流程。当我们与生物制药公司合作，利用药物发现数据构建知识图谱时，我们并非从零开始创建实体类型，而是采用 FHIR 的基本元素，并根据领域需求进行扩展，同时将精力集中在真正具有创新性的功能上，例如追踪化合物的观察结果如何在试验阶段中演变，或者将不同研究的发现联系起来。

关键不在于单一的本体论能解决所有问题，关键在于定义“什么是病人、什么是药物、什么是账户”的工作已经完成——而且是经过数十年反复、仔细的探讨。基础已经存在，问题在于你是否利用了这些基础。

Palantir 的实际作用

针对阿舒·加格（Ashu Garg）的论述，丹尼尔·戴维斯提出了一个重要的见解：

这一点值得深入分析，Palantir 的高昂成本并非源于“预设本体难以构建”，而是因为他们为每个部署场景都定制开发。他们没有采用现有标准，而是为每个客户特定的数据环境创建专属模型。

这是商业模式的选择，而非既定本体的固有属性。你可以采用Schema.org无需花费数年时间进行自定义建模，即可创建类型、扩展 CDM 模式并添加特定领域的实体。

Palantir 的方案之所以昂贵，是因为它本质上是披着平台外衣的定制咨询服务。预设的本体论本身并非瓶颈所在，真正的瓶颈在于拒绝利用现有资源。

习得本体论的真正作用

我并不想完全否定习得的本体论观点，它确实有其合理之处，但我认为它被应用到了问题的错误层面。

实体本身——人、组织、账户、联系人、事件——无需学习，我们知道它们是什么，其类型是稳定的，核心关系也已明确。等待智能体轨迹去“发现”账户和联系人是重要的实体，就好比等待搜索引擎去发现名词的存在一样，纯属多此一举。

CRM的经验和教训

这里有一个有趣的相似之处，但上下文图谱的讨论并没有承认这一点：CRM 定制本质上是本体建模。

企业搭建现代客户关系管理系统（CRM），例如 Attio、HubSpot 或 Salesforce，大部分工作都集中在定义自定义对象和关系上。风险投资公司会为基金、投资、投资组合公司和有限合伙人等对象建立模型，并定义它们之间的关系，招聘公司会构建候选人、职位、客户和招聘结果等模型，房地产公司则会跟踪房产、房源、买家和经纪人等信息。

这就是本体论问题的实际应用，每个 CRM 系统的实施都是在押注“哪些实体对这家企业至关重要，以及它们之间是如何连接的？”

我们曾与一些风险投资公司合作，帮助他们建立数据模型来追踪跨基金的投资情况，这项工作与本体设计并无本质区别。他们实际上是在定义实体类型、属性和关系——只不过他们没有这样称呼而已。

当下一大批主打 “AI 原生客户关系管理系统”（AI-native CRM）的初创企业正试图走这条捷径，代表企业包括Lightfield、Clarify、Forge AI，Day.ai等，它们的核心理念是：无需提前配置数据模型，让系统自主学习、完成构建即可。这正是习得本体论的核心理念，被直接应用到了客户关系管理系统的产品设计中。（关于这些企业的技术路径细节，详见附录深度解析。）

但即使是最激进的“自助式CRM”方案，仍然假定你需要了解“交易”有阶段，“联系人”属于“客户”，“活动”将人与商机联系起来，核心对象在不同企业中保持稳定——这就是为什么Salesforce的标准对象与HubSpot的标准对象大致相同，而HubSpot的标准对象又与Attio的标准对象大致相同。

推理真正发挥作用的地方在于：发现哪些自定义字段真正重要，哪些关系被使用，哪些对象对于特定团队的工作方式至关重要，哪些对象是次要的。这是建立在基础之上的组织智能，而不是基础本身。

具体而言，是组织特定层面：

• 对于这笔交易而言，客户方哪些联系人真正起决定性作用？
• 真正的决策过程是什么（与组织结构图相对）？
• 哪些例外情况会被批准，哪些不会被批准？
• 究竟有哪些先例指导决策的制定？

这是隐性知识。它不属于任何本体论范畴，因为它与该组织的运作方式密切相关。它存在于人们的头脑中，存在于Slack讨论串中，存在于客户服务问题升级的解决模式中。

这就是从发展轨迹中学习的意义所在，不是“发现客户经理是一个实体”，而是“发现尽管客户关系管理系统显示她的上司是 Sarah Chen，但实际上她是真正的决策者”。

这种习得本体论观点混淆了两个截然不同的问题：

1. 实体建模
   ：存在哪些类型的事物以及它们之间有何关系？（已解决——或者至少可以使用现有标准解决）
2. 组织智能
   ：这个特定的组织实际是如何运作的？决策遵循哪些模式？（这确实是一个全新的概念，需要真正学习）

第一点是基础设施，第二点是洞察力。它们并非同一回事，也不需要采用相同的方法。

冷启动难题

这就是习得本体论愿景遇到的实际困难所在：在智能体有效运行之前，你无法从智能体轨迹中学习。但如果没有基础上下文，智能体就无法有效运行。

这一点我在上一篇——《构建事件时钟》一文中进行了阐述：

Animesh 使用的 node2vec 类比实际上很好地说明了这一点，Node2vec 从现有边（Existing Edges）的行走模式中学习嵌入向量，而不是从零开始发现节点和边，图谱必须先存在。

智能体工作流的运行方式是相同的，智能体框架根据预先构建的映射表协调工具调用。该映射表代表运营时的上下文：已解析的实体、已建立的关系和时间状态。首先构建映射表，然后智能体才能高效地遍历它。

那么，如何进行引导呢？基于习得本体论愿景并没有一个明确的答案，“运行智能体并让结构涌现”的前提是，你已经有了可供智能体运行的对象。

首先从Schema.org实体类型开始，对企业对象采用 CDM 模式。使用这些已建立的类型，从内容中提取实体，解析身份——电子邮件中的 Sarah Chen 与@sarah在 Slack 中构建图表。

然后运行智能体，然后从轨迹中学习，轨迹会告诉你本体论无法解释的东西：哪些关系最重要，哪些模式会反复出现，哪些例外会成为先例。

真正未解之谜

如果实体建模在很大程度上已被现有标准解决，那么真正的创新之处在哪里？上下文图谱需要解决的难题是什么？

时间有效性

大多数系统都能告诉你现在什么是真理，但几乎没有哪个系统能告诉你过去某个特定时间点什么是真理，或者真理是如何随着时间演变的。

“Paula在微软工作”是事实，但并非全部事实，她是什么时候入职的？她现在还在那里工作吗？2022年的情况又是怎样的？

这就是Animesh Koratana所说的“事件时钟”——它不仅用于追踪当前状态，还用于追踪状态随时间的变化。它包含带有validAt和invalidAt时间戳的事实，它能够查询“我们在做出该决定时对这个账户的看法是什么？”

现有的本体论无法解决这个问题。Schema.org它定义了人员和组织，但没有提供“此关系从日期 X 到日期 Y 为真”的原生基本属性。CDM 对帐户和联系人进行建模，但没有跟踪这些实体的属性如何演变。

决策轨迹

Foundation Capital 的原文章说得对：将数据与行动联系起来的推理从未被记录为数据。

当续保代理人提出20%的折扣，而保单规定的折扣上限为10%时，系统会从多个系统中提取相关信息。财务部门批准后，客户关系管理系统（CRM）记录了“20%折扣”。然而，所有使这一决定变得清晰明了的信息——包括输入数据、保单评估、例外处理流程以及审批链——都消失了。

捕捉决策轨迹并非传统意义上的本体论问题，而是一个工具化问题。你需要进入决策执行路径，即决策最终生效的路径，不仅要记录发生了什么，还要记录为什么允许这些事情发生。

这确实是一个全新的领域，现有的本体中没有“这项决定是根据政策v3.2做出的，但副总裁Sarah Chen根据第二季度Acme交易的先例批准了一项例外”这样的基本概念。

事实核验

从内容中提取事实时，你得到的是断言，而非真相。内容可能存在错误、过时或自相矛盾之处。

“客户正在续订”可能出现在三月份的邮件中。“客户已流失”可能出现在九月份的 Slack 讨论串中。两者都是从内容中提取出来的事实。但它们不可能同时为真。

事实认定——确定哪些是权威的、哪些已被取代的、哪些得到了证实——确实非常困难。它需要对时间有效性、信息来源的权威性以及后来的信息如何更新先前的论断做出判断。

这不是本体论能发挥作用的地方，而是另一种问题：如何在证据不断积累的情况下，保持认知判断的一致性。

为什么这对构建很重要

这个等式的需求方很明确。亚伦·莱维（Aaron Levie）在最近的一篇文章——《场景时代》中写过：

他说得没错，企业正逐渐意识到，智能体的效能取决于它们所接收到的场景信息。

但是，如果你要构建上下文基础设施，框架就很重要，因为它决定了你将精力投入到哪里。

“习得性本体”框架表明，你应该关注轨迹捕捉、嵌入学习和涌现结构，构建基础设施，使智能体能够通过使用发现本体。

我建议采取不同的做法：关注那些真正尚未解决的问题。

• 实体建模？采用现有标准即可，别花几个月时间定义“帐户”是什么，微软已经从 WAND 获得了相关授权。
• 时间有效性？这才是关键所在。事实会随着时间而改变。查询历史状态的能力。事件时钟。
• 决策轨迹？机会就在这里，身处执行路径之中，将推理过程捕捉为数据。
• 事实认定？这正是人工智能的难点所在，需要利用逻辑逻辑模型来确定哪些是权威的，哪些已被取代，以及如何从零散的观察结果中综合出时间线上的事实。
• 组织学习？这正是发展轨迹真正发挥作用的地方——但它是建立在基础之上的，而不是取代基础。

在场景基础设施领域脱颖而出的公司，不会是那些从零开始学习本体论的公司，而是那些采用现有技术并将创新重点放在真正新颖领域的公司。

我们正在构建什么

在Graphlit公司，自 2021 年以来我们一直采用这种方法，令我们感到惊讶的是：本体论问题从来都不是瓶颈，我们采用了Schema.org很早就找到了方向，而且从未后悔，真正的难题总是在别处。

我们将Schema.org定义的实体类型 —— 人物、组织、地点、事件等 —— 以 JSON-LD 格式进行序列化处理。我们并非刻板遵循 RDF 或三元组存储的技术规范，核心关注点始终是实体类型与关联关系。通过在 JSON 数据中增设 @type 字段这一方式，既实现了与Schema.org体系的兼容，又无需要求任何人学习整套语义网技术栈。

现实迫使我们构建了一个混合存储系统，其中实体同时存在于向量存储、JSON 元数据存储和图存储中。这使我们能够同时跨多个维度进行查询：时间维度（这件事何时发生的？）、地理空间维度（这件事发生在何处？）、语义维度（哪些内容相似？）、全文维度（哪些内容提到了这个术语？）以及图谱维度（它们之间有何关联？）。大多数系统只能选择一到两个维度，而组织知识却同时存在于所有这些维度中——例如，一次销售会议发生在特定的时间、特定的城市，涉及特定的客户，其语义内容与其他对话相关，并通过关系图谱与人员和产品相连，你需要同时查询所有这些信息。

我们正在构建现有本体所缺乏的时间层，并将其扩展到决策轨迹。我们的 MCP 服务器位于智能体的上下文检索路径中，当智能体通过 Graphlit 执行工作流时，我们不仅可以捕获它们访问的内容，还可以捕获它们展现的推理模式。

我们正在构建事实判定——LLM 支持的基础设施，用于从累积的断言中确定当前的真实情况，从分散的观察中综合时间线事实，并在证据积累的过程中保持连贯性。

语义网将成为主流

这场关于上下文图谱与本体论的讨论，背后贯穿着一条值得被正视的核心脉络。

语义网社区（RDF、OWL、链接数据）几十年来一直在研究这些问题。Schema.org正是源于这一传统。机器对结构化、可互操作数据进行推理的愿景并非人工智能领域在2024年才提出的。

甚至“场景图谱”这个术语的学术渊源也早于当前的讨论。2024年6月发表于arXiv的论文——《场景图谱（Context Graph）》正式引入了“场景图谱”这一概念，作为“知识图谱”的扩展，它包含了时间有效性、地理位置和来源溯源——这些维度恰恰是三元组表示所缺失的。研究人员证明，添加这一上下文层能够显著提升知识图谱任务的推理性能。Foundation Capital 为企业级人工智能领域推广的这一概念，此前已在学术研究中完成了理论体系的形式化。

阻碍其普及的并非理念本身，而是过于复杂的语法。RDF、SPARQL、OWL——这些核心技术的学习曲线极其陡峭，大多数开发者最终都未能掌握。

大语言模型LLM 改变了这一切，它们可以原生读取 JSON-LD，它们可以从训练数据中理解和提取Schema.org的类型，它们无需自定义查询语言或形式化推理引擎，即可对结构化数据进行推理。

语义网的概念胜出，专属技术语法败下阵来。但这也没什么不好——JSON-LD 让你无需付出代价就能享受到所有好处，上下文图谱的讨论实际上是语义网讨论的重现，而 LLM作为全新的推理层，最终使语义网核心理念因为门槛的降低得以实现。

我们的立场

这种“预先设定”与“后天习得”的二分法过于简单粗暴，这些实体并不需要学习，它们只需要被接受——Schema.orgCDM、WAND，这些工作已经完成。

三个原则：

1. 沿用现有方法，不要重复发明轮子。实体建模问题已经得到了很好的解决，不要把创新预算浪费在重新发现它上面。

2. 构建时间层。包含具有有效期的事实，可查询的历史记录，时间作为一级维度。

3. 将学习重点放在真正新的内容上。例如组织模式、决策动态以及该组织特有的隐性知识，这正是发展轨迹发挥作用的地方——它是在现有基础上构建的，而不是取代现有基础。

场景图谱的愿景是可以实现的，问题在于，我们是应该在现有基础上继续发展，还是应该浪费数年时间重新发现它。

我们知道我们要采取哪种方法。

附录：AI原生CRM与习得本体论

“AI原生CRM”浪潮值得我们深入研究，它堪称对习得本体论理论的一次现实检验。这些初创公司试图通过从使用情况中推断结构来简化传统的CRM配置。但仔细观察，它们可以归为两类：

A类：模式演进。 Lightfield（来自 Tome 创始团队打造）方案最明确地阐述了如何从非结构化输入中推断和演化数据结构。他们谈到“灵活的、可回填的模式”以及“根据组织的需求对非结构化数据进行模式化”。这最接近字面意义上的“习得本体论”。

B类：AI辅助配置。其他大多数都是“经典CRM模型，但AI让设置和维护变得像零配置一样简单”：

• Clarify
  上的市场定位是“可自动配置的 CRM”——只需指定一个字段，人工智能就会选择字段类型、编写指令并自动填充。
• Forge AI声称：“描述你的流程，然后看着 CRM 系统自动构建。”
• Da
  y.ai自动
  捕获沟通内容并将其整理成 CRM 记录。

你仍然可以在可识别的对象（帐户、联系人、交易、活动）中操作，人工智能减少了摩擦，但并没有消除底层架构。

这一区别对于更广泛的本体论辩论至关重要，即使是最激进的“学习型”方法仍然依赖于稳定的基础对象。学习发生在组织层——哪些字段重要，哪些关系被使用——而不是实体类型层。