Ontology深度研究备忘录

全文概要

Ontology 正经历一个罕见的结构性分裂：同一个术语承载着两个不同的范式家族。学术意义上的 Formal Ontology（O=<C,H,R,A> + OWL 2 DL 公理 + 描述逻辑推理）是一个在理性上高度自洽但在工程实践中严重断裂的领域——理论完成于 1990s，W3C 标准栈成型于 2010s，但工程工具链仍处在"前 DevOps 时代"。而 工业意义上的 Operational Ontology（业务语义+数据绑定+治理+操作层的综合平台）正在以 Palantir 的 $4.48B 年营收和微软 Fabric 的入场证明其商业价值。这两个"物种"（指 Academic Formal Ontology 与 Industrial Operational Ontology）共享同一个词语，但其定义、标准栈、工具链、商业模式和投资逻辑已分属不同领域。这是本项目最核心的结构性发现。

工程层面的核心困境： 本体理论（Gruber/Guarino/Studer 三代定义、NeOn 九场景方法论、W3C 五层栈）已充分成熟，但中间工具基础设施严重滞后——本体演化管理"几乎空白"（Santos et al. 2020 测试 7 款工具在 93 种变化类型上的覆盖情况，无一完整覆盖），Git 不适用于本体差异追踪（语义等价的公理可采用不同的序列化表示，文本 diff 完全失效）。这是一个陡峭的断层：上层是高度自洽的理性建筑，下层是缺乏 DevOps 基础设施的工地。

AI 层面的核心判断：LLM 增强而非替代 ontology。 OLLM 端到端本体学习在 Wikipedia 上达到 Fuzzy F1=0.915，但非 taxonomy 关系提取仍处"初阶"，公理提取"几乎空白"。GraphRAG 的 entity graph（实体图）缺乏形式化语义约束和一致性保证。这正是 ontology 的四道 AI 围墙：形式化壁垒、一致性壁垒、治理壁垒、公理提取壁垒。市场的推论是清晰的——本体不会因 AI 而被淘汰，而是成为 AI Agent 的语义基础设施。

商业层面的核心发现： 本体技术商业化以 Palantir 为唯一锚点。11.2B 剩余交易价值验证了 ontology-as-operating-system（本体即操作系统）的可行性。但除 Palantir 外所有本体/KG 厂商财务不透明，NRR 等关键指标完全缺失。本体更接近"平台功能特征"而非"独立投资类别"——它的商业价值主要在平台内部实现而非作为单独产品。

贯穿全文的叙事主线：形式化程度与采纳率成反比。 最形式化的本体（FIBO OWL 2 DL）用户最少，最轻量的方案（Wikidata/LEI）最广泛。对投资而言，"最好的 ontology"不等于"最成功的 ontology"——中等形式化的操作型 ontology 产品（Palantir 范式）在中期的商业捕获力可能远超任何纯形式化本体。

Part I: 本体是什么——定义、框架、标准

I.1 学术定义：三代迭代，已定形

在进入精确定义之前，先理解 ontology engineering（本体工程）是怎么来的、变成了什么。

Ontology 的源头是哲学。两千多年前亚里士多德研究"存在什么"——这门学问叫"本体论（ontology）"。跟工程没有一丝关系。

1990 年代，AI 研究者遇到一个困境：要让机器"理解"知识，得先有一套语言把知识的结构说清楚。他们从哲学借来了 ontology 这个词，把它变成了工程师做的事——用逻辑语言手工搭建知识的"骨架"。这就是 ontology engineering 的起点。

此后它经历了三次跃迁：

现在你已经知道"故事"了。下面三段定义迭代（Gruber→Guarino→Studer）就是学者在阶段①中，对"ontology 到底是什么"给出的三个版本的回答：

💡 比喻：一块空地，三种规划思路。 想象你要开发一块空地。

•                              Gruber 说： "先画个规划图，标清楚这块地用来干嘛。"（specification）

•                              Guarino 说： "规划图永远画不完美，实际建出来的楼跟规划总有偏差——你只能无限逼近。"（approximation）

•                              Studer 说： "规划好的方案得大家都签字同意才行，而且得按施工标准来写。"（shared + formal）

三个人说的都是同一块地（ontology），但在回答不同层面的问题。

Iteration 1 — Gruber (1993)：

"An ontology is a specification of a conceptualization."

提出于知识共享语境，简洁但粗糙——"specification"暗示精确对应，这是后来的修正点。

Iteration 2 — Guarino (1998)： 关键修正——ontology 不是 specification，而是：

"logical theory approximating intended models"

他证明任何 ontology 描述的"模型集合"都大于设计者"意图中的模型集合"——精确对应不可能，只能逼近。这是 Guarino 对领域最根本的理论贡献，不是语义游戏。

💡 类比：分子结构图 vs 真实分子。
化学家在黑板上画一个水分子的结构式（H-O-H，108°夹角），这是对真实水分子的"近似描述"——它精确表达了我们知道什么，但永远无法穷尽真实水分子在量子层面的所有行为。

同样的，任何 ontology 描述的"模型集合"都大于设计者"意图中的模型集合"——精确对应不可能，只能逼近。

Iteration 3 — Studer (1998)： 实用主义综合——

"An ontology is an explicit formal specification of a shared conceptualization."

增加 shared 和 formal 两个限定词。这是最常被引用的版本。

可操作判定法：Du et al. (2024) 的O = <C, H, R, A> 公式。

仅含 taxonomic hierarchy（分类层级结构）的结构不是 ontology。该公式提供了一个二元边界判断：有公理+关系=formal ontology，仅 taxonomy 不是。剩余争议属于术语政治而非技术判断。

💡 以汽车为例：

•                              C（概念） = 车、发动机、轮胎

•                              H（层次结构） = 跑车 is-a 汽车 is-a 车辆

•                              R（非分类关系） = 驱动(发动机, 车轮)、载客(汽车, 人)

•                              A（公理） = "每辆车有且只有一个发动机"——违反这条公理的模型不算"车"

仅有 C+H 是 taxonomy，加 R+A 才是 ontology。

2024 的现实：一个术语，两个物种。 学术定义指向 O=<C,H,R,A> + axioms + OWL 推理——即 Formal Ontology（形式化本体）。工业界（Palantir, Microsoft Fabric）将 ontology 重新定义为"业务语义+数据绑定+治理+操作层的综合平台"——即 Operational Ontology（操作型本体）。Palantir 的 Ontology 产品包含 Actions/Functions/Security（操作/函数/安全）层，这些不在任何学术定义中。这两个物种共享同一个词但已分属不同范式。

I.2 W3C 标准栈：哪些层级真的有用

在 W3C（World Wide Web Consortium，万维网联盟，互联网标准组织）出标准之前，每个做知识图谱的团队都用自己的一套格式。 你的数据我的工具读不了，我的本体你的系统看不懂——就像城市里每条街的路牌用不同语言在写。W3C 要解决的就是这个：出一套大家都遵守的知识表示语法，让不同的系统能互相沟通。

但问题是：标准从"规定知识长什么样"（RDF）一路堆到了"知识推理规则"（OWL Full），越往上越复杂、越难落地。结果这五层标准至今没有一层被真正大规模采用。下面一层一层来看，哪些有用、哪些是摆设。

W3C 技术栈由五层严格依赖组成，但实用性分布极不均匀。

L1 — RDF (Resource Description Framework)：数据模型层。实战有用。
三元组（subject-predicate-object）是知识图谱的基础数据模型。RDF 与 Property Graph 模型的差异已不是关键问题——两个社区的工具都在互相吸收功能（RDF* / SPARQL Property Paths）。SPARQL Property Paths 提供正则路径查询——这是 SQL recursive CTE 需要多行代码才能实现的表达力。

例：一句话"苹果总部在加州，Tim Cook 是 CEO"拆成 RDF 三元组就是：

每行一个事实，机器能读、能查、能推理。想象把整份年报拆成几百万个这样的小三元组——这就是知识图谱。

L2 — SPARQL：查询语言。实战有用，但非所有场景必需。
严格来说 SPARQL 是跨层查询语言——可以查 RDF 也可以查 OWL 推理结果。多数图数据库同时提供 Cypher/Gremlin 等接口。

例：接上面的 RDF 数据，查"所有总部加州的上市公司及其 CEO"：

返回 (Apple, Tim Cook)。比 SQL 直观的地方：不需要 JOIN——三元组本身就是关联。

L3 — RDFS (RDF Schema)：轻量语义。有限有用。
提供类（class）、子类（subclass）、属性域/值域（domain/range）等简单推理能力。表达力远低于 OWL，主要作为 RDF 数据的类型层使用。

例：定义"上市公司是组织的子类；CEO 必须是 Person 类型"：

有了这层 schema，推理器能自动推断：如果 :Apple rdf:type :PublicCompany，那么 :Apple 也是 :Organization——不需要显式声明。这就是"轻量推理"。

L4 — OWL 2 + SHACL：推理层和验证层。最重要的一层但需分开看待。

•                              OWL 2：Web Ontology Language 2（Web 本体语言 2）

•                              SHACL：Shapes Constraint Language（形状约束语言）

•                              OWL 2 DL：Description Logic（描述逻辑）— 保证可判定推理

•                              OWL 2 Full：全表达力 — 不可判定

三者的关键差异：

关键判断：OWL 2 Full 几乎没有实际用途——不可判定推理意味着没有任何推理器可以支持其全部表达力。

💡 为什么叫"不可判定"？不是"太复杂算不出来"，而是"不存在通用算法来保证一致性"。好比让你写一个程序判断任意一段英文有没有逻辑矛盾——理论上就不可能。这就是 OWL 2 Full 的处境。

例（OWL）：定义"上市公司至少有一名 CEO，且 CEO 不能同时是另一家上市公司的 CEO"：

推理器会自动检查数据是否违反这些规则——比如数据里 :Apple :hasCEO :TimCook 和 :Tesla :hasCEO :TimCook 同时存在就会触发冲突（因为 FunctionalProperty 规定一个人最多只能是一家公司的 CEO）。这是 RDFS 做不到的级别。

SHACL 2017 是 W3C 对 OWA/CWA 张力的迟来回应——在 RDF/RDFS/OWL 采用 OWA 的二十年之后，SHACL 以 CWA 方式补上数据校验层。

例（SHACL）：规定"每家公司必须有 headquarteredIn 且值不能为空"：

与 OWL 不同，SHACL 不做推理——只检查数据是否"长对了样子"。更像 JSON Schema 而非类型系统。

L5 — 领域本体（Domain Ontologies）。 这是最终交付物。RDF/RDFS/OWL/SHACL 都是工具，领域本体才是目标——它决定了"我们的行业里有哪些概念、怎么关联、规则是什么"。

例：FIBO（金融行业业务本体）定义了 2000+ 金融概念的精确语义——Swap（互换合约）与 Derivative（衍生品）的继承关系、LegalEntity（法律实体）的合规属性，让摩根大通和高盛在同一定义下交换数据。没有 FIBO，A 银行的"swap"和 B 银行的"swap"可能是两回事；有了它，跨机构数据对账自动完成。

全栈采用建议： 新项目可以安全地只采用 RDF（Resource Description Framework，资源描述框架，数据模型）+ OWL 2 DL（描述逻辑，推理）+ SHACL（形状约束语言，验证）。RDFS（RDF Schema，RDF 模式）可以用 OWL 替代。序列化格式的争论（Turtle vs XML vs JSON-LD）没有实际意义——三者本质互转。

核心设计张力是 OWA vs CWA： 大多数数据从业者在关系数据库的 CWA 世界中成长，W3C 栈的 OWA 假设造成了可量化的认知摩擦——在企业销售周期中体现为额外沟通成本。

💡 医院病历 vs 大学录取。

•                              OWA（开放世界） = 医院病历：记录没写"病人不发烧"不代表病人不发烧——可能只是护士忘记测体温了

•                              CWA（封闭世界） = 大学录取系统：录取名单上没有你的名字 = 你没被录取

W3C 技术栈默认 OWA（因为语义网需要容纳不完整信息），但大多数企业 IT 系统在 CWA 下运行——这种世界观冲突是本体产品不好卖的深层原因之一。

不再值得争论的问题： RDF vs Property Graph 优劣之争（2015 年后已收敛，两个社区在互相吸收功能）；OWL 2 Full 的不可判定性（自 2012 年 OWL 2 发布以来无变化且不会变化）；序列化格式之争（Turtle/XML/JSON-LD 可无损互转）。

I.3 本体工程生命周期：方法论成熟，工具断层

NeOn 方法论（9 场景）已充分覆盖本体工程的全空间。 从零构建到完全重用，覆盖了本体网络环境下的所有可行路径。提供了情境化选择框架：不是"方法论规定你怎么做"，而是"根据你的场景选场景"。方法论层面的充分性已获文献共识。

9 个场景按"新建 vs 重用"光谱排列，实质只回答三个问题：有没有现成的？能用多少？要不要改？

① 从零新建（约 10%）

•                              场景 1：从零构建。 没有现成本体可用，从规范文档直接建模。

•                              例：基因本体（Gene Ontology, GO）始建于 1998 年——当时根本没有现成的分子生物学词汇标准。三位创始人（Ashburner 等人）从文献中手工提取基因功能、细胞组分、生物过程三类概念，逐条定义，一步步建成了今天生物学引用最多的本体之一。整个过程耗时数年，全是人工。

② 基于现有资源改造（约 60% — 实战最密集区）

•                              场景 2：从非本体资源重建。 企业里最有价值的路径。数据库 schema、XML 结构、Excel 表格、API 接口定义——这些不是本体但编码了领域知识。NeOn 提供了系统化方法把它们"翻译"成本体。

•                              例：一家银行要做巴塞尔协议 III 合规报告，现有 200 张关系表定义了客户、账户、交易、抵押品及其关系。这些表的 schema 本质上是隐式的领域模型——"客户有一对多账户"、"交易属于一个账户且有类型字段"。场景 2 就是把这套隐式模型显式化为 OWL 本体，把外键关系转为 object property，把枚举字段转为 classes。实战中很多"本体项目"实际走的就是这条路，只是不叫 NeOn。

•                              场景 3：直接重用现有本体。 找到现成本体，不做修改直接集成。

•                              例：一家生物科技公司做基因功能注释，直接从官网下载 GO 本体文件，导入内部系统即可使用——GO 设计之初就是为了被直接重用的，它的 IRI 体系、版本机制、文档都为此优化。这类"拿来就能用"的情况在本体世界相当少见，通常只有经过长期打磨的公共本体才能做到。

•                              场景 4：重用并改造现有本体。 更现实的版本：本体大致能用但需要修改——增加新概念、调整层级、适配本地术语。

•                              例：一家中国医院采用 SNOMED CT（国际医学术语本体）做电子病历编码。SNOMED CT 覆盖了大部分临床概念，但缺少中文语境下的中药材和针灸术语，部分疾病分类层级也与国内临床路径不完全匹配。医院需要在原本体基础上新增数百个本地概念，并调整少数分类关系——本体主体是现成的，但必须改。

③ 合并多个来源（约 20%）

•                              场景 5：重用并合并多个本体。 一个本体不够用，需要从多个来源各取一部分拼在一起。

•                              例：一家制药公司要做药物重定位研究，需要同时用到 DrugBank（药物）、ChEBI（化学实体）、GO（基因功能）和疾病本体（DO）四个来源。问题在于：DrugBank 把"阿司匹林"定义为"药物"，ChEBI 定义为"化学实体"，DO 里可能根本就不存在这个物质。合并的核心工作是对齐这些异质定义——"不同来源的同一个概念，它的真正含义一致吗？"这是纯人工工作，也是本体工程中最贵的环节。

•                              场景 6：重用+合并+改造。 最复杂的场景——从多个来源取，还要改。

•                              例：英国 NHS 建设全国健康数据交换平台，需要整合各地医院使用的不同编码系统（Read Codes、ICD-10、SNOMED CT 的本地变体），合并成一个统一的健康信息本体。每个来源都有自己的层级、编码规则和本地扩展，还不能简单映射了事——因为映射错误会影响临床决策。这类项目的交付周期通常以年计，也是 Palantir Bootcamp 交付中最常见的企业场景起点。

④ 模式套用与结构调整（约 10%）

•                              场景 7：重用本体设计模式。 不重用整个本体，只重用解决特定问题的通用模式。

•                              例："部分-整体关系"（mereology / part-of）是跨领域通用的模式——汽车的轮子是汽车的一部分、科室是医院的一部分、章节是书的一部分。Ontology Design Patterns（ODP）库收录了这类通用模式，新项目可以直接套用，不需要重新建模。好比写代码时不从零实现排序算法，直接用标准库的 sort()。

•                              场景 8：重构本体结构。 本体内容不变，但重新组织结构——拆分过大的类，合并冗余的层次。

•                              例：一个金融机构的内部合规本体经过 5 年自然生长，"LegalEntity" 类下直接挂了 150 个子类，包括按地区分的（"UKEntity"、"CNEntity"）、按类型分的（"BankEntity"、"InsuranceEntity"）、按监管分的（"BaselEntity"、"SolvencyEntity"）——混合了多种分类维度。重构的目标是把这 150 个子类按维度拆成中间层（地区/类型/监管各一层），让本体结构可维护。

⑤ 直接拿来用（约 10%）

•                              场景 9：完全重用（仅本地化适配）。 本体本身不动，只做地区或语言适配。

•                              例：FIBO（金融行业业务本体）被一家日本证券公司采用。他们直接使用 FIBO 对衍生品、互换合约、法律实体的标准定义，核心 OWL 文件一行不改，只做日语标签翻译和日本金融厅（JFSA）的法规映射。FIBO 的 IRI 体系保证了跨机构数据交换时"swap"的含义完全一致——这是场景 9 的理想状态，可惜现实中这种开箱即用的本体屈指可数。

实战分布的 80/20： 场景 1（从零）和场景 9（全重用）是两端，各占约 10%。中间 80% 的实际项目落在场景 2-6，也就是"有东西可改，但没法直接用"——这正是 Palantir Bootcamp 式交付的市场基础，也解释了为什么本体工程本质上是咨询/服务生意，而非纯产品生意。

什么叫"Bootcamp（训练营式交付）"？Palantir 不卖软件让客户自己部署，而是派工程师到客户现场，用几周时间做一个沉浸式集成项目——目标是跑通第一个真实业务用例。客户付钱参加 Bootcamp，结束后如果效果好再扩展（更多场景、更大规模）。这个模式之所以存在，是因为本体工程的核心瓶颈不在技术而在领域翻译——客户比 Palantir 更懂自己的业务，Palantir 比客户更懂如何建模，两者必须在同一间屋子里才能把业务知识编码成本体。纯产品（买个软件自己装）在这种场景下行不通。这就是"本体工程是服务生意"的本质。

做本体需要一套上下游工具。 就像写代码需要 IDE（写）→ Git（存）→ CI/CD（自动跑）→ 测试（验证），本体工程也需要编辑、存储、自动化、验证这四类工具串起来——这套东西就叫"工具链"。目前每类都有东西可用，但各有短板：

关键缺口：本体演化管理——这是工具链里最薄弱的环节。 软件开发有 Git 跟踪每一行代码的变更历史，能回滚、能 diff、能合并分支。但本体不行——因为本体的"变化"不是文本行的增删，而是语义结构的变更。一个概念改名了、一个分类层级调整了、两个类合并了——这些在 Git 看来只是"一堆行的增删"，看不出语义上发生了什么。

Santos et al. (2020) 做了迄今最系统的基准评估：他们定义了一份本体工程中可能遇到的 93 种变化类型，然后拿 7 款主流工具逐一测试覆盖情况。结果——没有一款工具能完整覆盖所有 93 种。

这些变化类型按复杂度分三层：

•                              简单变化（多数工具支持）： 添加/删除一个叶子类（比如在"汽车"下面加一个"SUV"）、添加/删除一个属性。这类操作就像在 Excel 里新增一行——基本的编辑功能。

•                              复杂变化（多数工具不支持）： 重命名一个类（改名后所有引用它的地方都要更新）、把一个类拆成两个、把两个类合并成一个、把一个类从层级的一个位置移到另一个位置。这些操作在软件开发里已经是 IDE 自动重构的标配了，在本体工具里却要大费周章。

•                              变化传播与影响分析（几乎空白）： 如果我把"公司"类拆成了"法律实体"和"商业组织"两个类，哪些公理需要更新？哪些数据实例需要重新映射？影响范围有多大？——这些问题没有任何工具能回答。这才是最要命的缺口，因为企业级本体不可能永远不变，但变了之后没人知道会坏掉什么。

为什么 Git 帮不上忙？因为本体用 Turtle/XML/JSON-LD 等格式序列化时，语义等价的两段代码可以有完全不同的文本表示。一个 OWL 约束用 owl:equivalentClass 写和用 rdfs:subClassOf + owl:inverseOf 组合写逻辑等价，但 Git 文本 diff 告诉你"完全不一样"。

💡 一个具体的例子：你建了一个企业本体，定义了"子公司"和"母公司"两个类以及它们之间的关系。半年后业务调整，"子公司"被重新定义为"分支机构"的一个子类——这看起来只是改了一个继承关系。但实际影响是：所有标注为"子公司"的数据实例是否需要重新分类？所有引用"子公司"的查询逻辑是否需要重写？所有基于"子公司"定义的业务规则是否还成立？在没有影响分析工具的情况下，改一个关系可能需要人工检查数百个文件和数千个数据实例。

💡 两本书的"差异"。
假设有人用中文写了本小说，另一个人把情节不变但换成英文重新出版。Git diff 会告诉你"每个字都改了"——但从语义上什么都没变。

本体也一样：[owl:equivalentClass] 和 [rdfs:subClassOf, owl:inverseOf] 两种写法逻辑等价，但 Git 文本 diff 认为完全不一样。

所以本体需要自己的版本管理工具，不能直接套 Git。

评估体系的缺口： McDaniel & Storey (2019) 将评估方法分为 5 类 21 个指标，覆盖了"本体建得好不好"的各个维度，但没有任何工具实现了这些指标的完整集合。这 5 类分别是：

•                              ① 黄金标准对比（Gold Standard）——拿你的本体跟一个公认的"标准答案"逐条对比。比如你建了一个金融本体，拿它跟 FIBO 对一遍，看概念覆盖率和定义一致性。精确但依赖标准本体的存在。

•                              ② 任务驱动（Task-based）——不关心本体结构好不好看，只关心它能不能完成具体任务。比如做一个"财报实体识别"任务，用这个本体 vs 不用，精度差多少。实战中最有说服力，但只能评估"在特定任务上的表现"。

•                              ③ 数据驱动（Data-driven）——拿真实数据来测试：有多少数据实例能被本体的类正确归类？有多少实体落进了本体的定义范围？这好比用真实流量压测一个系统。

•                              ④ 专家评审（Expert-based）——找领域专家人工审查本体质量。最可靠但也最贵——一个大本体可能需要十几个专家审几周。FIBO 的审核流程就接近这个模式。

•                              ⑤ 结构性评估（Structural）——纯自动检查：有没有循环继承（A is-a B 且 B is-a A）？有没有孤立概念（定义了但从不引用）？有没有冗余定义？这些可以自动化跑。

问题不是"有没有评估方法"，而是"这些方法分散在不同的工具里，彼此不通"。 OOPS 做结构性检查（⑤），OAEI 做本体对齐测试（①的应用），但数据驱动（③）和任务驱动（②）几乎没有工具化支持。这就像体检报告把血压、血常规、CT 分成三份不同语言的报告——信息都在，但没法综合作出判断。

判断：本体工程工具链处于"前 DevOps 时代"。 软件开发行业在 2010 年代已解决的版本控制、CI/CD、回归测试、环境隔离——本体工程领域一个都没有。本体领域需要自己的 Git + CI/CD。

💡 2003 年的软件开发。
当时程序员写代码：

•                              用 Vim（Protégé 的类比），保存到本地（无版本管理）

•                              手动跑测试（无 CI/CD）

•                              手动部署

没有 GitHub、没有 CI 流水线、没有自动回归测试、没有容器化。今天本体工程所处的阶段就是这个。

软件开发在 2000s 经历了一场"基础设施革命"——Git → GitHub → CI/CD → Docker → K8s，而本体世界还在等自己的 GitHub 时刻。

I.4 上层本体：三种哲学立场的工程投影

前面 I.3 讲的是怎么建本体——方法论、工具、评估。但还有一个更根本的问题没回答：本体里该放什么？ 上层的分类框架（"万物可以分为哪几大类"）应该长什么样？

这就是上层本体（upper ontology）出场的地方。它不是"一个具体的行业本体"，而是给所有行业本体提供地基的元框架——定义了"存在""事物""关系""过程"这些最顶层概念应该怎么分类。好比写程序：你需要一个标准库提供 Object、String、Number 这些基础类型，上层本体就是本体世界的"标准库"。

但问题来了："世界的基本构件是什么"这个问题没有标准答案——不同的哲学立场给出不同的答案。

上层本体（upper ontology / foundational ontology）回答一个元问题："世界的基本构件是什么？"——然后将这些构件编码为形式化理论。这不是技术选型，是本体论承诺（ontological commitment）的选择——意思是：你选择了哪套上层本体，就等于承诺了"世界上存在哪些东西"。选了 BFO 就等于承认"持续者 vs 发生者"是真实的基本划分；选了 DOLCE 就等于认为"认知者如何概念化世界"才是关键。这不是工程师选数据库那种"哪个性能好选哪个"，而是选一套世界观。

BFO (Basic Formal Ontology) — 实在论 + ISO 标准。

实在论的核心理念：世界上的事物真实存在，不依赖于我们是否知道它们。BFO 认为本体工程师的工作是发现世界的真实分类，而不是发明分类。

最核心的划分是 continuant（持续者）vs occurrent（发生者）：

•                              持续者：随时间持续存在的实体。一个人、一栋楼、一家公司——今天在，明天也在，换了零件还是同一个体。

•                              发生者：在时间中展开的事件或过程。一场手术、一次并购、一次心跳——有开始有结束，结束就不再存在。

例：一家医院用 BFO 建模"患者接受心脏手术"：

•                              患者 → continuant（住院前、住院中、出院后是同一个人）

•                              心脏手术 → occurrent（有开始结束，不会永久持续）

•                              医院 → independent continuant（独立于患者存在）

•                              病历 → generically dependent continuant（依赖载体但内容可迁移）

BFO 的这种严格分类迫使每个设计者回答"这个事物到底是哪一类"——看似增加工作量，实则保证两个都用 BFO 的本体在"患者"的含义上完全一致。

•                              标准地位： ISO/IEC 21838-2，允许政府采购直接指定"符合 ISO 21838-2"

•                              采用规模： 550+ 项目，OBO Foundry 强制对齐，生物医学/政府/国防领域主导

•                              关键优劣势： 标准护城河是制度性的（ISO 可写入采购合同），但标准化后更新流程冗长

DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering) — 描述论 + 完全公理化。

DOLCE 的核心理念跟 BFO 完全相反：ontology 不是描述客观世界，而是描述人类如何概念化世界。同一事物，不同文化不同语言的人可能有完全不同的概念化方式——DOLCE 要捕捉这种多样性，而非追求唯一的"真实分类"。

例：同样是"患者接受心脏手术"，DOLCE 关注的跟 BFO 完全不同：

•                              区分物理对象（心脏、手术刀）和社会对象（医保合约、知情同意书）——后者是"人类约定的存在"，不是自然界本来就有的

•                              可以表达"同一物理事件在不同文化中被赋予不同意义"——比如开胸手术在某种文化中可能有宗教含义

•                              关注患者如何理解这次就医经历——包括预期、感知、社会角色

这就是为什么 DOLCE 在文化遗产领域特别受欢迎。欧洲博物馆用 DOLCE 描述文物——同一件文物在不同历史时期承载了完全不同的"意义"，DOLCE 能同时表达这些层次，BFO 做不到。

•                              技术特征： 完全 FOL modal（一阶逻辑模态）公理化，一致性经逻辑证明——但因此不可计算（FOL 的不可判定性意味着无法用推理引擎跑）。有 OWL 近似版 DUL（DOLCE Ultra-Lite），但失掉了大部分表达力。

•                              关键优劣势： 理论最严谨，但"严谨到没法用"——像一本建筑规范精确到每个螺丝钉的扭矩值，但实际施工中没人能完全照做。

SUMO (Suggested Upper Merged Ontology) — 实用主义 + 最大规模。

SUMO 不走哲学路线，走"能用就行"路线。目标是覆盖尽可能多的领域，不在任何一个领域死磕哲学深度。

例：同样建模"患者接受心脏手术"，SUMO 的做法很直接：

•                              已经有现成的 Heart、Surgery、Patient、Hospital 类——几乎不需要新建概念

•                              但分类比较粗——Surgery（手术）和 Cooking（烹饪）在 SUMO 里可能同属 Process 大类，不会像 BFO 那样严格区分"自然过程"和"意图性过程"

•                              优势是马上能用：NLP 应用直接用 SUMO 做语义标注，不需要像 BFO 那样逐个审核分类是否正确

好比三个人翻译同一段话：BFO 是专家级人工翻译（准确但贵），DOLCE 是带文化注释的学术翻译（精确但复杂），SUMO 是 Google Translate（覆盖面广、马上用、别要求太深）。

•                              技术特征： 约 25,000 术语 / 80,000 公理，唯一完整映射 WordNet 的上层本体

•                              维护状态： 基础设施过时，更新缓慢。适用 NLP 应用、术语对齐

•                              关键优劣势： 广度无人能及，但深度和维护均弱于 BFO

选型格局已收敛： 生物医学/政府/国防 → BFO；认知科学/文化遗产 → DOLCE；NLP/术语对齐 → SUMO。BFO 在机构和标准层面的领先是压倒性的（ISO + 550+ 项目），但 DOLCE 的 FOL 公理化在理论完整性上无可比肩。投资分析中 BFO 需在核心地图呈现（ISO 护城河），DOLCE 和 SUMO 做背景级理解即可。

💡 三张世界地图。

•                              BFO（实在论） 相当于地质图——标注山脉、河流、地层，认为这些东西独立于人存在

•                              DOLCE（描述论） 相当于不同文化的人各自画的心理地图——关注人如何感知世界，同一个城市可以有完全不同的"心理地图"

•                              SUMO（实用论） 相当于 Google Maps 的聚合层——不纠结哲学正确性，只要覆盖够广就行

它们在"世界是什么"这个最底层的假设上就已经分了叉。

辩论：BFO 的 ISO 标准是护城河还是包袱？ ISO 提供法理地位和采购合规性（正方），但标准化后更新灵活度降低，可能拖慢与 AI/LLM 等新技术对齐（反方）。缺乏标准化对本体长期适应性影响的量化数据。

I.5 Formal vs Operational：分裂中的两个物种

这是本项目最深刻的发现。2024 的现实是学术定义指向 Formal Ontology；工业界正在重新定义 Ontology。以下是对比全景，然后逐维拆解：

四个关键维度的深入拆解：

① 建模语言：OWL 公理 vs OCL 操作，本质是"描述世界"和"改变世界"的区别。

Formal 用 OWL 公理描述"世界应该长什么样"——比如"上市公司至少有一名 CEO"是一条公理，数据违反它就报错。OWL 的语义是声明式的（declarative）：你说了"是什么"，推理器自动推导"意味着什么"。

Operational 用 OCL 定义对象类型、链接和可执行动作——比如"当审批状态变为'已通过'时，自动更新贷款账户余额并通知客户经理"。OCL 的语义是操作式的（imperative）：你说了"怎么做"，系统就执行什么。Palantir 的 Object Types 相当于数据库的表定义，Links 相当于外键关系，Actions 相当于存储过程——全是工程概念，不是逻辑概念。

这就好比小学数学题和大学数学论文的区别。前者说"5+3=8"——结论是确定的，全世界都同意（OWL 公理）。后者说"用黎曼几何重新定义平行线"——不同的前提推导出不同的结论，关键是你选择了什么框架（OCL 操作）。

② 世界观：OWA vs CWA 的连锁反应。

通过 I.2 你已经知道两者的区别。但它的影响远超"数据有没有"的层面——它决定了整个系统的设计哲学：

这就是为什么 Formal Ontology 在企业销售中多出 1-3 个月——不是因为产品不好，而是因为 OWA 这个前提跟企业 IT 六十年的"数据=事实"传统完全相反。

③ 工程方法：NeOn 方法论 vs Bootcamp 交付。

NeOn（I.3 详述）是学术界的产物——列举所有可能的场景，让你自己选。完备、严谨，但落地时"9 个场景，我该怎么选"本身就是一个需要专家帮助的决策。

Bootcamp 是 Palantir 的答案——不给你方法论文档，派工程师到你现场，两周内跑通第一个用例。不是"根据你的场景选场景"，而是"我们一起做，边做边学"。代价是：深度绑定 Palantir 的私有工具和流程。

好比学做饭。NeOn 是买一本《法国蓝带烹饪大全》（所有技法都写清楚了，但普通人翻开不知道从哪开始）。Bootcamp 是请一个大厨到你家厨房，手把手教你做三道菜（马上能吃，但离开大厨你自己不一定能举一反三）。

④ 商业本质：两种完全不同的赚钱方式。

Formal Ontology 的商业逻辑是间接的——资助标准制定（欧盟 Horizon 项目、NIH 资助）、卖咨询和培训（"来参加我们的 OWL 建模训练营吧"）、卖推理引擎许可（Pellet、HermiT 等小众市场）。

Operational Ontology 的商业逻辑是直接的——平台订阅费（Palantir 的 $4.48B 营收）、决策效率可量化（缩短贷款审批周期、减少合规人工审核）。客户付钱不是因为"语义一致性"这个抽象价值，而是因为"以前需要 5 个人审 3 天的流程，现在 10 分钟搞定"。

架构对比：三层 vs 四层。

两个物种的差异可以简化为一个架构图：

Formal 的三层全部在"知识表示"范畴内——写知识、描述知识、推理知识。Operational 加了上面两层（Action + Security），把 ontology 从"知识表示系统"变成了"业务操作系统"。多出来的这两层，就是 Palantir 的 $4.48B 跟所有学术本体项目之间的全部差距。

Palantir 的 Ontology 不是 W3C 标准的"本体"——它不使用 RDF/OWL/SHACL，没有描述逻辑推理器，其建模语言是私有的 Object Types/Links/Interfaces（OCL，操作约束语言）。但它确实在做"业务语义的理解、表达和操作"——这是本体在较高抽象层面的合理定义。"算不算本体市场"的争论在投资层面没有实际价值——更好的问题是：谁在为它付钱、为什么付钱、付多少。

关于"两个物种"的辩论状态： 这是本项目中最重要的活跃辩论——共享"语义共享理解"的核心目标但工业版舍弃 axioms（公理）/rules 并增加操作层（Actions/Functions/Security（操作/函数/安全）），结构已质变。缺乏能被双方共同接受的定义框架是当前僵局的核心原因。

💡 一座桥的两个说法。

•                              结构工程师会说：桥是"由预应力混凝土构建的简支梁结构，承载力 50 吨"（Formal Ontology：精确、形式化、可计算）

•                              城市规划师会说：桥是"连接两岸的交通通道，每天通行 10 万辆车，两端有收费站"（Operational Ontology：功能、操作、可行动）

同一个词（桥），两个范式，各自合理。 当 Palantir 说他们在做 Ontology，他们指的是城市规划师的版本——关注怎么用，而不是由什么构成。

Part II: 本体如何构建与应用

II.1 LLM + Ontology：双向协同

本体学习（Ontology Learning with LLM, OLLM，基于LLM的本体学习）

在 LLM 之前，本体构建是纯粹的手工活——学者和领域专家坐在一起，用逻辑语言一条一条写公式。 FIBO 的几百条公理是几十个人写了十几年的结果，Guarino 的分子模型也是人手搭出来的。一份像模像样的本体，投入几十个人年都是常态。

LLM 改变了这一格局。Lo et al. (2024) 提出的 OLLM 框架（End-to-End Ontology Learning with Large Language Models, NeurIPS 2024）通过微调 LLM 配合正则化约束，从领域文本语料中端到端提取本体 taxonomy 骨架，在 Wikipedia 语料上达到 Fuzzy F1=0.915。但定量结果揭示了一个结构性分化：LLM 在不同本体层的表现差异显著，且恰好与本体核心价值层反向对应。以下为 OLLM 的主要指标：

Wikipedia 上的 Fuzzy F1=0.915 全面超越传统流水线方法（0.78-0.83），但 arXiv 学术论文上的 0.570 提示跨领域泛化能力仍是重大挑战。更关键的发现是 LLM 的"能力天花板"恰好对应 ontology 的核心价值层：

💡 三层厨师。

•                              L0-L1（术语提取） = 帮厨切菜——成熟，LLM 做得跟人一样好

•                              L2（taxonomy 分类） = 按菜谱配料——接近成熟，偶尔出错但可用

•                              L3-L5（关系提取+公理+校验） = 创作新菜谱——LLM 做的菜能吃但不好吃，经常把不该放一起的食材放一起（关系混乱），且无法保证每道菜做出来是一致的（一致性校验失败）

Formal ontology 的核心价值恰好落在 L3-L5，也就是 LLM 做不好的那几层。

核心结论： 非 taxonomy（分类）关系提取（如 part-of, causes, treats 等）和公理提取分别处于"初阶"和"空白"阶段。Du et al. (2024)（A Short Review for Ontology Learning: Stride to Large Language Models Trend, arXiv:2404.14991）在其系统性综述中明确主张：

"LLM 完全自动本体构建不太可能实现"

所有审查文献一致认为 Human-in-the-loop（人在回路）是当前唯一可行的实践模式。

💡 家谱 vs 社交圈。

•                              Taxonomy 关系 = "曹操 is-a 人，人 is-a 生物"——这是分类，结构简单，LLM 拿得准

•                              Non-taxonomy 关系 = "曹操挟天子、天子赐曹操九锡、曹操率军于官渡击败袁绍"——这些（挟、赐、率、击败）就是 non-taxonomy 关系，LLM 经常搞错谁对谁做了什么

这恰好是本体学习中最大的技术瓶颈。

LLM 能力边界的结构性根源：Transformer 架构与 Ontology 各层的对齐与错位

上述能力分层（L0-L2 成熟 vs L3-L5 薄弱）并非偶然，也不是数据不足带来的暂时性问题——它是 Transformer 架构的结构性产物。

LLM"提取概念"的技术实质是分布语义匹配（distributional semantic matching），不是逻辑推理，也不是"理解"。

Transformer 的核心机制是自注意力（self-attention），它学习的是 token 在上下文中的共现模式（co-occurrence patterns）。当预训练语料中包含"苹果是一家科技公司""苹果发布了新款 iPhone"各数百万次后，其嵌入空间（embedding space）自然将"苹果"与"公司""科技""产品"等词汇的距离拉近。这就是术语提取的全部——不是什么对世界的理解，而是对词汇使用模式的统计压缩。这套机制对不同本体层的适应能力截然不同：

关键推论：这不是 scale 问题。

模型规模从 7B 到 70B 到 700B，L0-L2 的表现在持续改善，但 L3-L5 的瓶颈始终未突破。因为问题不在参数数量，而在架构的底层能力边界——这个边界由 Transformer 的"模式匹配而非符号演绎"本质决定。Lo et al. (2024) 观察到 CoT（思维链）在本体学习中无效，与 CoT 在数学/逻辑任务上的成功形成鲜明对比，正是这一结构性限制的实证：CoT 帮助的是多步符号推演（数学/逻辑），而本体学习依赖的是分布语义理解（语言理解），后者是 Transformer 前向传播一步就能完成的事，不需要也不受益于多步分解。

这个结构限制推导出投资层面的推论： LLM 增强而非替代 ontology。未来的分工格局是——LLM 处理 L0-L2（术语提取和分类的低成本自动化），人类聚焦 L3-L5（关系和公理的高价值设计）。这恰好形成一个互补分工而非替代关系，也是"Human-in-the-loop（人在回路）不是权宜之计而是架构必然"的根本原因。

LLM 与 OWL 推理器：最佳组合而非竞争

LLM + OWL 推理器混合架构被证明是两者的"最佳组合"——LLM 处理自然语言查询并将结构化查询路由给 OWL 推理器（如 HermiT、Pellet），推理器返回结果再包装回自然语言。直接要求 LLM 在 OWL 知识库上推理的效果显著差于传统推理器——LLM 在处理多个 OWA 推理步骤时的错误率急剧攀升，这是 transformer 架构依赖 token-level pattern matching 而非符号演绎的本质限制。

关于 CoT 的发现： 自洽性与大语言模型思维链（Chain of Thought, CoT）在本体学习中无效——本体学习依赖语言理解而非多步推理，CoT 的多步 decomposition 并未带来本体构建质量的提升（Lo et al. 2024）。这与 CoT 在数学/逻辑任务上的成功形成鲜明对比，提示本体学习与数学推理分属不同能力维度。

💡 两种解题思路。

•                              学生 A： 看到一道数学题，一步一步推导（CoT 思维链）——最后算对了

•                              学生 B： 被要求"看懂一篇文章后归纳它的知识结构"——这时候一步步推理没什么用，需要的是语言理解能力而不是多步推导

本体学习更多依赖后者，所以 CoT 帮忙不大。这就是 Lo et al. (2024) 发现 CoT 不 work 的原因。

反向路径：Ontology 增强 LLM

本体对 LLM 的反向增强往往被忽视，却是双向协同中最具商业价值的方向：

综合判断： LLM 和 ontology 是共生关系，非零和博弈。LLM 在构建侧降成本、在本体使用侧增渠道；本体在 LLM 输出侧提质量、在 Agent 约束侧加安全。双向协同的商业价值大于任何一方单独的价值。

II.2 KG / GraphRAG / Agent：Ontology 的 AI 时代接口

本节涉及三个容易混淆的概念。在进入对比之前，先定义清楚两个基础概念（Agent 已在 I.5 讨论过）：

知识图谱（Knowledge Graph, KG） 是以图结构组织知识的系统——实体为节点、关系为边。Google 在 2012 年提出这个术语（推出了 Google Knowledge Graph 改善搜索结果），但底层技术远早于此：语义网络（1960s）、RDF（1999）、语义网（2001）都是它的前身。KG 与 ontology 的关系是：KG 侧重实例层（"苹果公司的 CEO 是 Tim Cook"）和存储查询，ontology 侧重模式层（"公司必须有至少一位 CEO"）和语义约束。实际系统中两者往往共存——KG 是本体实例化的载体。

GraphRAG（图检索增强生成，微软开源 2024） 是 RAG 的进化版本。传统 RAG（向量相似度检索 + LLM 生成）擅长找具体事实（"苹果 2024 年营收多少？"），但做不了全局理解（"这份财报的主要风险点有哪些？"）。GraphRAG 的解法是：先用 LLM 从文档中提取实体-关系图，再对图做社区检测（Leiden 算法），在每个社区上生成摘要，形成层级化结构——全局查询时先定位相关社区再回答。但其构建的 entity graph（实体图）没有形式化模式层——没有类别约束、没有属性定义域/值域、没有一致性保证。它不是 KG 意义上的"知识图谱"，更像是一张从文本中统计提取的实体关系网。

以下对比说明这张"网"与 formal ontology 的根本区别：

Formal Ontology vs GraphRAG Entity Graph：根本区别

GraphRAG 构建的 entity knowledge graph 不是 formal ontology：

Ontology 的四项不可替代能力： (1) 形式化语义约束与推理——OWL 的描述逻辑保证自动一致性判定；(2) 版本化治理与权限控制——分支合并、角色审核、变更追溯；(3) 跨系统互操作性与共享词汇——联盟本体使不同系统对同一概念有相同理解的契约基础；(4) 业务规则一致强制执行——Action/Logic 层的绑定超出"查询-回答"，涉及写入和执行。

💡 一张即时贴地图 vs 一本法律条文。

•                              GraphRAG 提取的 entity graph（实体图） 好比一堆同事在会议室白板上贴即时贴："张三联系了李四""李四认识王五""王五在腾讯工作"——有结构但没约束，谁都可以贴，贴错了也没人管

•                              Formal ontology 好比中华人民共和国民法典——每条定义都有精确的适用范围、法律效力和执行方式

前者灵活但松散，后者严谨但笨重。GraphRAG 不能替代 ontology，正如即时贴不能替代民法典。

场景决策矩阵：

Agent 对 Ontology 的三层需求

Agent 对 ontology 的需求取决于其行动范围，呈非线性增长：从只读到写入到安全敏感，每上一级都引入新的语义约束要求。

逐层展开来看：

L1 阅读型——ontology 作为"概念校准器"。 Agent 直接对接 KG 或 GraphRAG 时，ontology 提供的是概念的"官方定义"——比如"营收"是指 GAAP 口径还是 Non-GAAP、"活跃用户"的判定标准是什么。没有这层校准，Agent 在不同语境下可能用同一个词指不同东西。不妨设想一个行业研究 Agent：它读财报时知道"operating income"和"EBIT"在哪些场景下可以互换、哪些场景下不能——这背后就是 ontology 在给它做概念对齐。

L2 写入型——ontology 作为"操作边界"。 Agent 一旦开始动手改数据，ontology 就从参考书变成了规则书。可能的应用场景：

•                              保险理赔 Agent：根据 ontology 中定义的理赔状态机（已提交→审核中→已批准/已拒绝→已支付），Agent 只能沿合法路径推进，不能跳状态

•                              供应链 Agent：ontology 定义了"订单"和"发货单"之间的映射关系，Agent 在创建发货单时必须引用合法的订单号，且不能超出 ontology 中定义的数量约束

•                              临床试验数据 Agent：ontology 规定了不良反应的分级标准（CTCAE 1-5 级），Agent 录入数据时只能在允许的级别范围内做选择

这些场景的共同逻辑是：ontology 定义了什么能做、什么不能做，Agent 在框内行动。

L3 安全敏感型——ontology 作为"权限语义层"。 最有趣也最未被充分探索的一层。这里 ontology 要解决的问题不是"数据对不对"，而是"谁应该看到什么、谁可以操作什么"。权限不再是基于文件或数据库表，而是基于语义类别：

•                              一个医疗 Agent 可以看到"患者张三"的诊断记录，但不能看到他的基因测序原始数据——因为 ontology 将"诊断记录"和"基因数据"标记为不同的敏感度类别

•                              一个合规审查 Agent 可以读取所有交易记录，但不能修改——ontology 在类型层面就禁止了写入权限，而不是靠上层应用逻辑

•                              跨机构 Agent 协作时，ontology 定义了"哪些信息可以共享给合作伙伴、哪些必须脱敏、哪些禁止出境"——权限规则嵌入在语义层，而非写在每个接口的代码里

这套逻辑如果成型，意味着 ontology 会成为 Agent 时代的"权限宪法"——不是一行行 if-else，而是在概念层定义谁可以做什么。

还远未定型。

当前 Agent 产品基本集中在 L1，少数触及 L2 早期（如 Palantir AIP 的 Action 层），L3 几乎只有概念验证。一个有意思的开放问题是：L2 和 L3 的需求是否会随 Agent 的行动能力扩展而自然涌现？还是说行业需要某个"监管触发事件"（比如一起 Agent 越权操作导致的事故）才会推动 ontology 级权限的落地？

不确定。但值得留意。

II.3 公共本体案例：形式化程度与采纳率成反比

公共本体（public ontology）就是某个行业共同维护的一份知识参考词典。 最早是生物医学界发现：不同实验室都在给基因和疾病起名字，各起各的，结果谁也没法跟谁对数据。于是学界和政府出钱，做出了第一个公共本体——Gene Ontology（1998），供全世界免费使用。

这个模式后来被复制到了其他领域：临床医学、文化遗产、金融、政府数据……每个领域都有了自己的共用词典。但一个问题随之而来：这些本体该做得多精确、多形式化？有的像口头约定一样松（谁都能加词条），有的像法律文书一样严（每个定义要两个委员会联审）。下面九个案例展示了这个光谱的完整范围。

九大公共本体覆盖从轻量声明到重形式化的完整光谱。最关键的发现是 形式化程度与采纳率成反比：

形式化策略分歧：

•                              覆盖广度优先（SNOMED CT 350K concepts + ELprofile）——牺牲形式化深度换取临床覆盖面。EL profile 是有意识的产品决策：比 OWL 2 DL 轻量但仍可做分类推理。

•                              形式化深度优先（FIBO OWL 2 DL 全公理化）——追求法律/合规级一致性保证，但部署率最低。FIBO 的几百条公理是 10+ 年人力产出，LLM 完全无法自动生成。

•                              实用主义中间（GO 部分 OWL，部分 OBO/ROBOT 编译）——BFO 顶层框架 + 逐步 OWL 化的务实路径。

治理模式差异： 政府/学术资助（GO/UMLS）追学术质量，生命力最长（GO 28 年，UMLS 40+ 年）；会员制（SNOMED CT）平衡商业与开放；基金会（Wikidata）追求覆盖广度优先于一致性；标准组织（DCAT W3C）法理地位强但更新慢；双组织共管（FIBO EDM Council + OMG）决策链条长。

关键 insight： 生物医学是唯一"本体即基础设施"的领域——GO、SNOMED CT、UMLS 在生物信息学中是必须层级。这源于 (a) 生命科学知识本质上是分类学和层级结构，本体在此天然适合；(b) NIH 等政府资金长达 20-40 年的持续投入提供了不可替代的治理稳定性。

💡 三种合同。

•                              Wikidata（最轻量） = 口头约定——大家都能参与，用得最多

•                              SNOMED CT（中间） = 标准租房合同范本——有章可循，44 个国家在用

•                              FIBO OWL 2 DL（最形式化） = 跨国并购法律文书——每个条款都由两个律所联审（EDM Council + OMG），精确到标点，但也因此只有大银行用得起

选择的不是"哪个更正确"，而是"哪个够用"。

II.4 开源生态：G1 基础设施 vs G2 AI 时代

本体开源生态呈现清晰的两代断层。G1 是 15-20+ 年的稳态维护工具，解决"知识表示怎么做"；G2 是 2-3 年的 AI 爆发工具，解决"LLM 怎么编排"。两代之间几乎没有重叠，但正在出现桥接层。

G1：知识表示基础设施（15-20+ 年）

由 Stanford BMIR / Apache Foundation / NIH 治理，断裂风险极低。每个工具的具体定位和局限：

Protégé Desktop — protege.stanford.edu
本体编辑器的金标准，始于 2000 年前后 Stanford 医学院。本体圈有个经验法则：如果你不是用 Protégé 建的，它可能就不是一个正经本体。 插件生态庞大（推理器、可视化、版本对比），GUI 覆盖了 OWL 本体构建的完整生命周期。局限：桌面单机应用，不支持多人实时协作；界面风格停留在 2010 年代；对非技术用户的学习曲线陡峭。

OWL API — github.com/owlcs/owlapi
Java 生态中操作 OWL 本体的核心库，相当于"Java 本体世界的字节码层"。Protégé 本身也构建在 OWL API 之上。几乎所有工业级 Java 本体代码都直接或间接依赖它。局限：Java 绑定意味着 Python 生态的 LLM 工具链无法直接调用；接口设计偏底层，学习成本高。

Apache Jena — jena.apache.org
语义 Web 的全栈框架：包含 TDB（原生 RDF 存储引擎）、Fuseki（SPARQL 服务器，支持 HTTP 查询）、ARQ（SPARQL 查询引擎）、推理子系统。ASF（Apache Software Foundation）治理保证了长期可用性——不会因为某个公司倒闭而消失。局限：RDF 存储性能在现代图数据库面前没有优势；推理层的表达能力远低于专用 OWL 推理器（HermiT/Pellet）。

RDFLib — rdflib.readthedocs.io
Python 生态唯一稳定可用的 RDF 库。早期主要是学术用途，随着 LLM 工具链（LangChain、LlamaIndex 都在 Python 生态）的爆发，它的间接战略价值在上升——LLM 工具链越繁荣，RDFLib 越不可替代，因为它是 Python 世界接入 RDF 数据的唯一成熟的桥头堡。局限：单机库，不支持分布式/大规模场景；社区维护力量有限。

ROBOT — robot.obolibrary.org
OBO Foundry 出品的 CLI 工具，是目前本体工程最接近 CI/CD 的东西。支持本体编译、推理、验证、报告生成、模板化批量编辑。可 Docker 化，适合嵌入自动化管线。局限：主要服务 OBO 生态（生物医学），对 OWL 全功能覆盖不全；无原生 Git 集成——本体 diff 仍然是个未解决问题。

补充值得一提的工具：

•                              OOPS! (Ontology Pitfall Scanner) — oops.linkeddata.es — 本体语法层自动扫雷器，可以检测命名不一致、冗余定义、遗漏标注等常见错误

•                              HermiT / Pellet — 两个最主流的 OWL 2 DL 推理器。HermiT 基于 Hypertableau 算法，是 Protégé 默认推理器。Pellet 更早但维护已停滞

•                              Stardog — stardog.com — 唯一将 OWL 推理商业化（在性能层面）的图数据库。技术上介于 G1 和商业产品之间

G1 的系统性工程局限： 无原生版本管理（Git 不适用于本体——语义等价的公理可用不同序列化表示，文本 diff 完全失效）、无集成 CI/CD、无统一健康检查、无自动化回归测试、协作基本靠邮件和共享目录。

G2：AI 编排工具（2-3 年快速爆发）

这些不是本体工具——它们解决的是 LLM 编排、RAG、Agent 协作问题。但对本体生态有深刻影响，因为它们决定了 LLM 是否/如何消费知识表示。

LangChain / LangGraph — langchain.com
LLM 编排的事实标准框架（500K+ PyPI 月下载）。LangGraph 是其 Agent 状态机扩展。对本体生态的价值：提供了将结构化知识注入 LLM 工作流的管道——但仅限于"接受任何文本"，没有原生 RDF/OWL 理解能力。理论上可以通过自定义工具调用 SPARQL 端点，但这需要额外工程，不在框架的开箱即用能力内。

LlamaIndex — llamaindex.ai
数据框架，定位比 LangChain 更偏"数据接入"。它提供了当前唯一的 G1→G2 桥接层：KnowledgeGraphIndex 组件可以从 RDF 三元组构建索引，让本体知识进入 RAG 管道。这是本体生态与 AI 工具链之间最直接的工程交叉点。

MS GraphRAG — microsoft.com/graphrag（GitHub 20K+ stars）
微软 2024 年开源的全局 RAG 方案。前面 II.2 已详细讨论过。关键点：它构建的是 entity graph（实体图）而非 formal ontology——没有 OWL 级别的语义约束。对本体生态最大的影响是让"图上做 RAG"这个范式进入主流视野。

AutoGPT / CrewAI
AutoGPT 是自主 Agent 的先驱项目（2023），CrewAI 是多 Agent 编排框架。它们与本体生态的关系更间接——通过 Agent 调用 ontology API（如 Palantir Ontology MCP）来执行操作。这与本节的"编排 vs 知识表示"二分法一致。

💡 比喻：电力公司 vs 智能家居 APP。

•                              G1（Protégé/Jena/RDFLib） 就像电力公司——你感觉不到它的存在，但没有它，整个城市（知识表示基础设施）就会断电

•                              G2（LangChain/LlamaIndex） 就像智能家居 APP——你天天在用，界面好看，功能不断更新，但它本身就建立在电力系统之上

智能家居 APP 替代不了电力公司，因为 APP 解决的是"设备编排"问题，电力公司解决的是"供电"这个底层问题。G2 替代不了 G1，本体基础设施不是 AI 工具的"高级功能"，而是 AI 工具的*前置依赖。*

G1→G2 桥接：当前仅有的两个交叉点

1. LlamaIndex KnowledgeGraphIndex — 允许 RDF 三元组进入 RAG 管道。这是工程层面的直接桥接。

2. SPARQL-to-NL 工具链 — 用 LLM 将自然语言转为 SPARQL 查询（如 LangChain SPARQLQA Chain）。这是查询层面的桥接。

两个桥接都还很浅——没有触及"LLM 理解本体语义"这个核心问题。更深层的融合（如 LLM 直接消费 OWL 公理进行推理）仍在研究阶段。

核心洞察：Ontology as Infrastructure vs Ontology as Product

两个世界对比：

两者不是竞争而是互补：基础设施型为产品型提供知识基础和跨组织互操作标准；产品型为基础设施型提供工程化验证和 AI 集成通道。

Part III: 商业与投资

III.1 金融行业五大本体路线

金融的命脉是数据互通、合规可追溯、语义无歧义——恰好是本体的核心承诺。本项目发现至少五种截然不同的"本体"方案，互不竞争，解决不同层面的语义问题。以下逐一展开。

① 规范推理型：FIBO（Financial Industry Business Ontology）

官网：edmcouncil.org / omg.org/fibo

FIBO 是全球唯一采用 OWL 2 DL 全公理化的金融本体。由 EDM Council（企业数据管理委员会）和 OMG（对象管理组织）双组织共管。拥有 200+ 模块、覆盖 2000+ 金融概念的精确语义定义——从"利率掉期"到"信用违约互换"，每个概念都有 OWL 公理级别的精确定义。

它是怎么运作的？ FIBO 不是软件，而是一套 OWL 2 DL 文件——你可以用 Protégé 打开它、用 HermiT 对它做推理。理论上 FIBO 能做到其他方案做不到的事：自动检测两个衍生品合约是否语义一致，或者新金融产品是否违反了既有分类体系。但正是这个"理论上"暴露了它的困境。

问题在哪？ OWL 2 DL 推理的计算开销高，在大型金融数据集上做实时推理不现实。部署率低、实施成本高（一个中型银行 12-24 个月）、ROI 数据完全缺失。买方（资管公司）几乎没人用——他们不需要 OWL 级别的语义精确性。FIBO 目前的实际用户群局限在欧美大型银行的合规和研究部门。

它的价值不应被低估： FIBO 是目前唯一能将"衍生品"和"证券"的形式化区别写进公理的方案。如果未来某天金融监管要求"语义级一致性审计"而不只是"字段级一致性审计"，FIBO 会瞬间从备选变为强制。但这一天是否到来、何时到来——不确定。

② 标识锚定型：LEI（Legal Entity Identifier, ISO 17442）

官网：gleif.org

LEI 是非本体的"本体"。它的做法很简单：给每个参与金融交易的法人实体发一个 20 位字母数字代码，附带最基本的元数据（名称、注册地、注册号、母公司关系）。不做推理，不做约束，只做标识。

它为什么算"本体路线"？ 因为 LEI 解决的是最底层、最痛的语义问题："你说的'高盛'指的是伦敦办公室还是纽约总部？是不是同一个法律实体？"在 FIBO 这类重型本体之前，先得知道你在讨论哪个实体。LEI 就是那套基础标识系统。

护城河极强——监管强制 + 自然垄断。 2008 年金融危机后，G20 推动全球统一法人标识制度。GLEIF（全球法人机构识别编码基金会）是唯一的 LEI 发行协调机构，经过 60+ 家本地发行单位（LOU）授权分发。全球 250 万+ 实体持有 LEI，且所有参与金融衍生品交易、证券发行的法人必须持有。没有替代方案。

局限： LEI 只解决"谁是谁"，不解决"什么是"——它不定义"掉期交易"是什么意思，也不约束交易数据的一致性。这就是为什么同一家银行会同时用 LEI（标识）和 FIBO（语义）。

③ 报告标记型：XBRL（eXtensible Business Reporting Language，可扩展商业报告语言）

官网：xbrl.org

XBRL 不是通常意义上的本体，但它可能是影响最广的"金融语义方案"。本质上是把财务报表的每个字段打上标准化标签（taxonomy），让计算机能理解"第 3 行第 2 列的数字是营业收入，不是总资产"。70+ 国家的监管机构强制要求上市公司用 XBRL 格式提交财务报告，包括美国 SEC（EDGAR 系统）、英国 HMRC、欧盟 ESMA。

技术本质： XBRL 使用 XML Schema + 链接库（linkbase）定义概念间的关系——本质上是一个结构化 taxonomy（分类体系），但不到 OWL 的 expressivity 级别。每个报告中的数字都带着上下文标签（实体、期间、单位、场景），使得跨公司、跨期间可比的财务数据成为可能。

护城河来源： 监管强制 + 网络效应。一旦全市场都采用 XBRL 格式上报，转换成本极高。XBRL 国际联盟（XII）为非营利标准组织。

局限： XBRL 的 taxonomy 更新缓慢（SEC 每年更新一次 US GAAP taxonomy），对新型金融产品（加密货币、ESG 指标）的覆盖滞后。同时它只解决了"报告格式"问题，不解决"报告背后的语义一致性"问题——两个公司可能对同一概念用不同的 taxonomy 标签。这就是 XBRL 和 FIBO 之间的互补关系。

④ 桌面互操作型：FDC3（Financial Desktop Connectivity and Collaboration Consortium）

官网：fdc3.finos.org

由 FINOS（Fintech Open Source Foundation）运营，Symphony、Bloomberg、FactSet 等金融科技公司共建。FDC3 解决的不是数据格式问题，而是金融桌面应用的运行时互操作——让 Bloomberg 终端可以向 Salesforce 发消息说"用户正在查看 $AAPL，你把它的研究数据调出来"，而不需要两家公司分别开发 API 对接。

技术本质： FDC3 定义了三个核心构件：(a) 应用目录——哪些应用可以通过 FDC3 通信、(b) 意图协议（Intents）——"我想查看这个股票的研究报告"是一个标准化的意图、(c) 上下文（Context）——传递的数据格式（一个"instrument"上下文包含 symbol、ISIN、name 等字段）。本质上是一个轻量行为合约（JSON Context），不做形式化推理。

护城河： 认证生态。BlackRock 的 Aladdin 已通过 FDC3 认证，Bloomberg 终端也已支持。一旦某个金融机构的关键工作流依赖 FDC3 连接多个桌面应用，迁移成本就会出现。

局限： FDC3 不解决任何数据层面的语义问题——它只是让应用之间能"对话"，但对话内容的语义准确性由各应用自己保证。它的价值完全在运行时互操作，不在数据一致性。

⑤ 操作语义型：Palantir Ontology

前面 I.5 已详述。简单回顾：它使用私有 Object-Types+Links+Actions 建模语言（OCL），在 W3C 标准栈之外运行。核心价值不是定义"什么是衍生品"，而是让银行可以定义"衍生品交易的状态转换规则"并让 Agent 执行操作。同一家银行的交易部门会同时使用 Palantir（操作语义）和 FIBO（规范语义）——各管各的事。

总结——不是五个方案在竞争，是五个完全不同的语义问题：

一个大型银行会使用全部五种：合规部门用 LEI/XBRL/FIBO，交易部门用 FDC3/Palantir，走不同的预算来源和技术栈。

💡 比喻：一个人的桌面上放了五种不同的工具。
一个人（大型银行）要做五件事：

•                              拧螺丝（合规）→ 用螺丝刀

•                              钉钉子（交易）→ 用锤子

•                              裁纸（报告）→ 用剪刀

•                              打电话（桌面互操作）→ 用手机

•                              开车（操作语义）→ 用车钥匙

没有"最好"的工具，只有最合适的——你不会因为有了螺丝刀就扔掉锤子，也不会因为有了手机就不再开车。
银行同理：合规部门用 LEI/XBRL/FIBO，交易部门用 FDC3/Palantir——各管各的事，互不替代。

关键发现： FIBO 是全球唯一 OWL 2 DL 全公理化金融本体，最大短板是 OWL 2 DL 推理开销限制了买方（资管公司）采用，部署率低、实施成本高，缺乏 ROI 数据。LEI 的护城河最强——监管强制+自然垄断，所有参与金融市场交易的法人实体必须持有。FDC3 解决的是"不同桌面应用之间的运行时互操作"——本质上是一个轻量行为合约（JSON Context），不做形式化推理。

III.2 三层市场结构

本体/KG 市场不能当作单一市场分析。本项目提出三层嵌套框架，各层不可叠加统计：

关键发现：三层之间不是上下游关系。 Palantir 不依赖 L2 的标准栈，Stardog 不参与 L3 的标准制定。每一层有独立的竞争逻辑和买家决策链。

L1 基础设施层的补充： Neo4j（Property Graph DB，~$100-250M 营收——项目估算，经 [[10_事实提取/S5_独立复核/T11_S2_商业化|S5 独立复核]] 确认）、Amazon Neptune（AWS 云原生图数据库）、MS GraphRAG（开源框架，20K+ stars —— GitHub）——它们提供图存储和/或 GraphRAG 能力，但本身不是 ontology 产品。Palantir 产品分类的特殊性在于：它虽然直接命名为 Ontology，但不属于 L2 语义平台层——它不在 W3C RDF/OWL/SHACL 栈上运行，而是使用私有 Object-Types+Links+Actions 建模语言（OCL）。

III.3 Palantir：唯一锚点

SEC 数据（FY2025）：

Palantir 的商业模式核心引擎是 Bootcamp（训练营式交付）——通过几天沉浸式集成帮助客户跑通首个实际用例。这不是免费的销售支持（Palantir 向客户收费提供 Bootcamp），而是一个"强制交付机制"，通过深度绑定压缩三重认知摩擦（OWA/CWA、专家在环、术语混淆）造成的销售周期成本。Palantir Ontology 架构的核心逻辑是四支柱：

切换成本分三层：

1. 数据层 — 多源数据已集成和语义绑定。迁移不仅重做 ETL，还要重建所有语义映射。

2. 逻辑层 — 业务规则通过 OCL/Functions on Objects 编码在平台上。这些是"可执行的知识"，但以私有格式存储。

3. 动作层 — 决策输出直接写回生产系统。这是最深的依赖——移除 Palantir 不仅要替换分析层，还要重建操作回路的整个管道。

这构成了操作系统级依赖。Top 20 客户平均 revenue expansion 达到 +45%，是明确的 revealed preference 信号。

💡 比喻：从 Notion 迁移到其他笔记软件。
假设你用了两年 Notion，所有笔记都在里面，建了复杂的数据库关联（数据层）、写了自动化公式和按钮（逻辑层）、还把 Notion 集成到了日历和邮件（动作层）。想迁出去？

•                              数据层： 需要重新整理所有笔记和数据库结构，还可能丢失格式

•                              逻辑层： Notion 的公式和自动化功能在其他软件里根本不支持——相当于用 Excel 公式在 Google Sheets 里重写一遍

•                              动作层： 需要重建所有集成管道

这还只是一个*个人用户——企业的 Palantir 依赖是 Notion 的百倍级别，涉及几十个生产系统的读写操作。这就是为什么 Top 20 客户平均 revenue expansion 达到 +45%——不是因为 Palantir 太便宜而是因为太深了，走不掉了。*

但 uncertainty 同样显著：

•                              NRR（Net Revenue Retention，净收入留存率）完全不披露

•                              39-45% 营收受 termination for convenience（为便利而终止）条款约束（<12 个月通知可终止）

•                              所有切换成本论述来自公司自述，无独立第三方量化评估

核心判读：Palantir 有护城河——但不知道有多宽多深。

III.4 市场规模：数据系统性稀缺的根源

除 Palantir 外，所有本体/KG 平台厂商财务数据完全缺失——无上市公司、无 Gartner/IDC 级定量研究、无行业共识定义。TAM（Total Addressable Market，可寻址市场总规模）估算可跨数量级偏差：

•                              最小定义（仅 Formal Ontology 工程）： TAM ~$500M-1B。本体编辑工具、推理引擎、本体咨询市场。Palantir 不算。

•                              中位定义（传统语义 KG 平台）： TAM ~$2-3B。Stardog/Ontotext/TopBraid/PoolParty + 相关咨询和集成。Palantir 不算。

•          最大定义（Operational Ontology 全谱）： TAM ~4.48B + 语义平台 (~500M-1B) + 大平台入局 (Fabric/Neo4j) 的潜在释放。

数据稀缺的四个根源： (1) 除 Palantir 外无上市公司；(2) 定义分歧导致 TAM 跨数量级偏差；(3) 三层嵌套不可叠加；(4) 卖本体和卖图数据库混为一谈。

核心判断： 精确的市场规模在当前数据环境下无法确定——这不是分析的失败，而是行业的早期特征。更合理的投资问题是"本体定义下的可捕获价值是多少"，而非"市场有多大"。

💡 比喻：问"交通市场有多大"。
问"本体市场有多大"就像问"交通市场有多大"——答案取决于你指什么：

•                              如果你算上所有地面交通（最小定义），市场是几百亿

•                              如果你加上航空和海运（中位定义），是几千亿

•                              如果你把物流、供应链、仓储全算上（最大定义），是万亿级

每个答案都是对的——但回答的是不同的问题。
本体市场也一样：2-3B（含语义平台）、$10B+（含操作型 ontology）——三个数字都对，关键是你问对了问题。

III.5 投资论点

本体作为一个"可独立投资的行业类别"在当前环境下很难成立。

理由：

1. 唯一纯正的二级市场标的：Palantir (PLTR)。 其他本体/KG 厂商均为私营公司（营收 $5-50M 级且深度不透明）

2. Palantir 本身的高估值风险。 PS（Price-to-Sales，市销率）~66x 隐含极高增长预期，而 NRR、政府续约率等关键验证指标均未公开

3. 本体业务不是独立赛道。 大多数"本体"厂商在内部被归类为图数据库、数据治理、合规科技——本体是增强叙事而非核心商品

本体更接近"功能特征"而非"独立投资类别"： Palantir 的 5-20M）。定义太模糊无法形成行业共识（TAM 在 10B+ 之间取决于定义）。

💡 比喻：汽车引擎 vs 整辆车。
一辆好车（好的企业平台）离不开一个好引擎（本体能力）。但没人会去投资"引擎公司"作为独立标的——你会投资 Toyota、BMW、Tesla，而不是一个只做引擎的供应商（除非你活在 1900 年汽车工业刚起步的时候）。

本体也一样：Palantir 的 5-50M——不是引擎不重要，而是*引擎的价值在车里实现，不是在修理厂里单独卖的。*

三个可追踪的前瞻性指标：

1. Palantir NRR（Net Revenue Retention，净收入留存率）的首次披露 —— 护城河验证的关键

2. Fabric Ontology GA（General Availability，正式发布）时间表 —— 语义层主流化转折点

3. Neo4j IPO —— 本体/KG 行业的可比基准，将提供毛利率、NRR、客户增长效率等 Palantir 之外完全缺失的指标

真正的投资机会可能在"需要语义基础设施的 AI Agent"这一交叉领域，而非本体平台本身。 如果"本体会成为 AI Agent 的基础设施"的叙事成立，主要受益方可能不是本体平台厂商（它们太小），而是云巨头（AWS Neptune、Azure Cosmos KG、MS Fabric Ontology）。

Palantir vs 语义平台对比：

Part IV: 12 研究问题的答案

以下展开每条研究问题的推理链（证据 → 中间判断 → 结论），而非仅给出最终答案：

T1 — Ontology 的定义边界在哪里？ [A]

•                              Gruber (1993) 给出经典定义："explicit specification of a conceptualization"——这个定义足够宽泛，从 XML Schema 到 OWL 任何结构化知识表示都可纳入。问题在于：太宽了，无法区分"ontology"和其他知识表示。

•                              Guarino (1998) 收窄为"explicit, formal specification of a shared conceptualization"——增加"formal"（机器可读，逻辑形式化）和"shared"（社会共识，非个人观点）两个关键限定，排除了非形式化的知识表示。这是定义的第一代收敛。

•                              Du et al. (2024) 综述进一步形式化为 O=<C,H,R,A>——概念集（C）+ 层级关系（H）+ 非分类关系（R）+ 公理/规则（A）。这个公式第一次统一了此前分散的定义。关键切割线：仅有 C+H（taxonomy）不是 formal ontology，必须包含 R+A。

•                              Guarino (2009) 提出三分光谱：轻量级（C+H）→ 中量级（C+H+R）→ 形式化（C+H+R+A），对应"概念体系 → 关系模型 → formal ontology"。

•                              工业实践正在并行定义 Operational Ontology：Palantir 和 MS Fabric 称其产品为 Ontology，但不需要完整 OWL 公理化。市场正在用采纳率投票，使得"什么是 ontology"出现了学术和工业两条定义线。

•                              结论： 学术定义三代迭代已定形，收敛于 O=<C,H,R,A>；工业界正在开辟 Operational Ontology 的平行轨道。实践中存在一条从轻量声明的 taxonomy 到全公理化 formal ontology 的光谱，选位取决于使用场景而非哲学偏好。

T2 — 上层本体有哪些，根本差异是什么？ [A]

•                              三大上层本体的分歧本质上是本体论承诺（ontological commitment）的分歧——它们对"世界存在什么"给出了不同的哲学回答，因此选择上层本体不是技术选型，而是在元层面的立场选择。

•                              BFO（Basic Formal Ontology）：实在论立场——ontology 应描述客观存在的实体，而非人类认知。已通过 ISO 21838-2 国际标准，550+ 项目采用，主要在生物医学领域。基于倾向（disposition）的理论框架使它能建模疾病倾向、药物作用机制等生物医学核心概念。

•                              DOLCE（Descriptive Ontology for Linguistic and Cognitive Engineering）：描述论/认知立场——ontology 应建模人类如何概念化世界，而非客观现实本身。在 FOL 中完全公理化，因此不可计算（无判定可判定的推理子集）。核心区分：持续者（endurant，存在于时间中不变）vs 发生者（perdurant，随时间展开）。

•                              SUMO（Suggested Upper Merged Ontology）：实用论立场——从实用角度合并已有本体为最大可用结构。约 25K 术语、80K 公理，是规模最大的上层本体。部分映射到 WordNet，实用性强，但哲学严谨性最低——它是"工程合并"而非"哲学建构"的产物。

•                              OAEI（本体对齐评估倡议）长期跟踪上层本体间的自动对齐：典型 F1 ~0.6-0.7——即使自动对齐，三者间的概念映射也存在根本性瓶颈，这印证了它们底层本体论承诺的不可通约性。

•                              结论： 三个上层本体对应三种哲学立场：BFO = 实在论 + ISO 标准（生物医学主导），DOLCE = 描述论 + FOL 完全公理化（不可计算），SUMO = 实用论 + 最大规模（哲学严谨性最低）。选哪个不是技术问题，是立场问题。

T3 — W3C 标准栈的结构和核心张力是什么？ [A]

•                              W3C 语义网标准栈有五层严格依赖关系：RDF（三元组数据模型）→ SPARQL（查询语言，依赖 RDF）→ RDFS（简单 schema，类型/属性层次）→ OWL 2 / SHACL（逻辑推理 + 约束验证）→ 领域本体（应用层实现）。每一层必须在下层基础上构建——不能越过 RDF 直接使用 OWL。

•                              贯穿所有层级的根本设计张力是 OWA vs CWA：OWA（开放世界假设）认为"未知 ≠ 假，可能为真"，这是 Web 推理天然假设，也是经典描述逻辑的语义基础；CWA（封闭世界假设）认为"不在数据库中 = 假"，这是 SQL 和关系数据库的语义基础。W3C 栈默认采用 OWA，但工业界大量需求 CWA。

•                              OWL 2 的三个 profile 是在表达力与可计算性之间的三种工程妥协：EL（EL++，面向生物医学大规模分类推理，多项式时间）、QL（面向查询回答，可翻译为 SQL）、RL（基于规则，使用规则引擎实现推理，最接近 CWA 世界观）。

•                              OWL 2 Full：包含 OWL 2 全部语言特性且不对底层 RDF 做任何限制——代价是不可判定（undecidable），不存在能处理所有情况的实际推理器。

•                              SHACL（2017 年加入标准栈）为约束验证提供支持，部分弥补 CWA 缺口——但 SHACL 与 OWL 推理器之间缺乏深度集成，两者在语义上存在张力和重叠。

•                              结论： 五层依赖链严格递进。OWA vs CWA 是最根本的设计张力（Web 语义 vs 数据库语义），贯穿每个设计决策。OWL 2 Full 因不可判定而无实用推理器。SHACL（2017）部分弥补 CWA 缺口但集成不完善。

T4 — 本体工程现状、方法和关键缺口？ [A]

•                              方法论层已经成熟：NeOn 方法论（2008）定义了 9 种开发场景——从"从零开发"到"全面重用/再工程"——完整覆盖本体工程全谱系，方法论层面已无重大缺口。

•                              工具链层严重断层：Santos (2020) 对 7 款主流本体演化管理工具的评估显示，93 种变化类型中无一款工具能完全覆盖。复杂变化检测（如涉及多个类的公理修改）评级为"extremely weak"。

•                              根本原因：本体工程工具链缺少对标软件开发基础设施的组件。Git 用于本体版本管理存在天然不匹配——本体的"差异"不是行级 diff（代码风格），而是概念级 diff（类层次迁移、公理修改、推理一致性检查），这对 diff 算法和合并策略提出了完全不同要求。

•                              OOPS（Ontology Pitfall Scanner）是少数可用的检测工具，但只做静态模式匹配，不能做语义层面的一致性检查和演化验证。

•                              类比判断：本体工程目前处于"前 Git + 前 CI/CD"阶段——有编辑器（Protégé）、有编译环境（OWL API/推理器），但没有版本管理、没有持续集成、没有自动化测试。这是从学术作坊进入工业化生产的瓶颈。

•                              结论： NeOn 9 场景方法论已覆盖本体开发全谱系，但工具链存在根本性断层——演化管理"几乎空白"。本体领域需要自己的"Git + CI/CD"，才能使本体工程从学术手工作坊进入工业化生产。

T5 — LLM 能在多大程度上自动本体学习？ [A]

•                              分析框架：Ontology Learning Layer Cake 定义了从底层到顶层的六层能力阶梯——术语提取 → 同义词发现 → 概念形成 → taxonomy（层级关系） → 非分类关系（non-taxonomic relations） → 公理/规则提取。越往上越难。

•                              底层（概念 + taxonomy）表现强：OLLM（Mistral 7B 微调，端到端子图生成）在 Wikipedia 数据上 Fuzzy F1=0.915，证明小规模开源 LLM 经过微调可以在概念提取和 taxonomy 构建上达到高水准。但注意：这是 Wikipedia（通用百科知识），专业领域表现可能显著下降。

•                              中层（非 taxonomy 关系）处于"初阶"：LLM 可以识别部分成对关系（如 hasPart、causes），但在关系类型归约（对齐到标准关系类型体系）、多关系联合建模上表现弱。这限制了从概念层次向完整关系模型的跃迁。

•                              顶层（公理提取）"空白"：LLM 无法从文本中提取形式化约束（传递性、不相交公理、函数依赖、复杂角色包含等）。这是 LLM 本体学习的根本瓶颈——没有公理就没有 formal ontology。

•                              反直觉发现：Chain-of-Thought 在数学/推理任务上有效，但在本体学习中无效。原因：本体学习的核心瓶颈不是推理深度（CoT 解决的是这个问题），而是定义概念的建模质量——CoT 无法弥补这个基础能力的缺失。

•                              唯一可行的工业化路径：Human-in-the-loop——LLM 作为半自动化助手完成术语提取和候选关系生成，领域专家负责关键判断（关系归约、公理设计、一致性验证）。这是所有被审查文献的共识。

•                              结论： LLM 在 Layer Cake 底层（术语、taxonomy）已可实用（OLLM F1=0.915），但在中层（非分类关系、初阶）和顶层（公理、空白）表现逐级衰减。CoT 无效。完全自动化不可行，Human-in-the-loop 是唯一可行模式。

T6 — KG / GraphRAG / Agent 与 formal ontology 的关系？ [A]

•                              四者是不同抽象层级，不是替代关系：Ontology = 蓝图设计（定义"世界应该长什么样"），KG = 实施层（存储"世界实际是什么"），GraphRAG = 检索模式（利用图结构增强 LLM 检索），Agent = 执行主体（在图/本体约束内行动）。

•                              KG 可以没有 formal ontology。 Neo4j 官方文档明确承认：多数 KG 从简单结构开始，在需要 formal semantics 或 interoperability 时才引入 ontology。证明 ontology 不是 KG 的必要条件。

•                              GraphRAG 的 entity knowledge graph 不是 formal ontology。 GraphRAG 用 LLM 从文档中提取实体和关系构建图索引，通过社区检测生成摘要。这个过程没有 OWL/RDFS 约束，不保证一致性，不包含公理，不支持形式推理。它本质上是"提取式实体关系图"而非本体。

•                              Ontology 的四项不可替代能力（KG 和 GraphRAG 缺失的）：

1. 形式化语义约束（如 disjointness：同一个人不能同时是 Employee 和 Customer）

2. 版本化治理（变更需推理一致性检查 + 权限控制）

3. 跨系统互操作（通过共享公理实现语义保真的数据交换）

4. 业务规则强制执行（将规则编码为公理，在数据层面强制保证一致性）

•                              Agent 的三层需求层次（非线性增长）：L1 = Agent 仅"阅读"结构化 schema → 当前 LLM + GraphRAG 已够用；L2 = Agent 按约束"写入"数据 → 需要 formal semantics 保证写入合规；L3 = Agent 涉及安全敏感操作（如 Palantir Ontology SDK + Actions——类型安全、身份验证、变更审计）→ formal ontology 是基础设施。从 L2 到 L3，需求不是线性增长而是跃迁。

•                              结论： 四者是补充而非替代关系。Ontology 提供 KG/GraphRAG 无法替代的三到四项能力。Agent 对 ontology 的需求随安全层级的提高非线性增长（L1 无需 → L3 必须）。Palantir Ontology SDK 和 MS Fabric Ontology 是 ontology-as-product 的工业级实践——定义 ontology 为"Agent 操作的共享语义上下文层"。

T7 — 哪些重要的公共本体？形式化程度和治理模式如何？ [A]

•                              本项目覆盖九大案例，横跨四领域：生物医学（GO、SNOMED CT、UMLS）、通用知识（Wikidata、DBpedia）、数据互操作（DCAT、FIBO）、建筑系统（Brick Schema）和文化遗产（CIDOC CRM）。

•                              形式化程度与采纳率成反比：FIBO（OWL 2 DL，形式化程度最高）部署率最低；Schema.org（轻量声明，形式化程度最低）被数千万网站嵌入。这不是巧合——形式化程度越高，使用门槛越高、所需专业能力越强，但推理能力也越强。

•                              生物医学是唯一"本体即基础设施"领域：GO 的 45K 术语、630 万注释覆盖 3,200 个物种；SNOMED CT 的 350K+ 概念是临床信息系统的强制标准；UMLS 作为术语集成框架已运行 40+ 年。其他领域没有这么深的本体绑定。

•                              治理模式决定可持续性：GO = NIH 资助的联盟制 → 优先学术研究质量；SNOMED CT = SNOMED International（非营利会员制）→ 平衡商业和学术需求；Wikidata = Wikimedia 基金会 → 开放性和广度优先；DCAT = W3C 标准 → 寿命最长、版本控制严格。政府资助的产品最长寿（UMLS 40+ 年），而纯社区驱动的项目面临人员流失和停滞风险。

•                              资金模式解释了设计取舍：NIH 资助 → 质量优先（GO）；会员费 → 实用优先（SNOMED CT 350K+ 临床概念的商业价值）；基金会 → 广度优先（Wikidata 100M+ items 但形式化约束弱）。

•                              结论： 九大案例覆盖从轻量到全形式化的光谱。形式化程度与采纳率成反比。生物医学是唯一"本体即核心基础设施"领域。政府/标准组织资助 + 明确治理结构 = 最长生命周期（UMLS 40+ 年）。理解资金模式才能理解本体的设计取舍。

T8 — 重要的企业本体产品和市场格局？ [A]

•                              三层市场结构（非竞品关系）：

￮       L1 基础设施（Neo4j、Amazon Neptune、MS GraphRAG）：图数据库/检索基础设施层。Neo4j ~$100-250M 营收（项目估算，经 S5 独立复核），是底层图存储。不卖 ontology，卖图数据库。

￮       L2 语义平台/中间件（Stardog、Ontotext、TopBraid EDG、PoolParty）：面向 CDO/数据治理的语义中间件。均为私营公司，不披露营收（估计 $5-50M 级）。在语义推理和 KG 能力上各有侧重：Stardog NASA 案例、Ontotext 金融合规案例、TopBraid 治理+policy-as-code 独特定位。

￮       L3 企业操作系统（Palantir Ontology、Microsoft Fabric Ontology）：最高的集成度和最完整的 ontology 产品化。Palantir $4.48B 已验证商业模式；Fabric Ontology 设计理念先进（NL2Ontology、ontology graph）但仍处 preview 状态，1-2 年不可进入生产选型。

•                              Palantir 的 ontology 是最完整的企业实现：对象类型 + 链接 + Actions + 版本管理 + 权限控制 + AIP AI 集成 + 类型安全 SDK。其他产品在"本体完整度"（对象 → 行动 → 治理 → AI 集成）这个链条上有不同程度的缺失。

•                              所有产品都在快速集成 LLM / GraphRAG 能力——Neo4j 推出 GraphRAG Python 包，Ontotext 强调 GraphDB 的 LLM 集成，Palantir 推出 AIP。这标志着"AI 时代本体"正从纯形式化建模转向"语义 + 检索 + Agent 操作"的融合模式。

•                              结论： 三层市场（基础设施→语义平台→企业操作系统）互相补充而非竞争。每层有独立的买家决策链和竞争逻辑。Palantir 是唯一经过完整商业模式验证的 ontology 产品（$4.48B）。所有厂商正在加速 AI 集成——本体产品形态正从"建模工具"转变为"AI 操作系统"。

T9 — Ontology 开源生态的重要工具和代际结构？ [A-B]

•                              两个代际，差异巨大：

￮       G1（传统本体栈，15-20+ 年稳态维护）：Protégé Desktop（Stanford BMIR，~1,071 stars）、Apache Jena（Java RDF/OWL 框架）、RDFLib（Python，15+ 年）、ROBOT（OBO 标准，命令行工具）——这些工具功能完备、稳定可靠、不追热点。社区活跃度低但从不"死掉"。

￮       G2（AI 代数据栈，2-3 年爆发期）：LangChain、LlamaIndex（47K-50K stars）、LangGraph（31K-36K stars）、MS GraphRAG——社区规模比 G1 大 1-2 个数量级，但它们不是本体工具。它们解决的是"AI 工作流"问题，与本体栈在语义层有重叠但不替代。

•                              唯一桥接层：LlamaIndex 的 KG Index 组件——在 G2 的 AI 框架中提供了对 G1 式 KG 的集成点，是两条代际之间唯一的"双向翻译层"。

•                              G1 的特点：以 OWL/RDF/SHACL 为核心、支持推理、面向本体工程师。G2 的特点：以 vector + entity graph 为主、不支持推理、面向 AI 应用开发者。这两套工具栈的使用者几乎完全不重叠。

•                              开源 vs 商业非对立：G1 开源工具已是产业基础设施（像 Linux），商业化价值在上层产品和集成服务中实现。

•                              结论： G1（15-20+ 年成熟维护）与 G2（2-3 年 AI 爆发）是两个几乎不重叠的开源生态。G2 社区规模大 1-2 数量级，但非本体工具。LlamaIndex KG Index 是唯一的双向桥接层。选型的关键不是"哪代更好"，而是"你的问题是本体工程问题还是 AI 工作流问题"。[A-B]

T10 — Ontology 在金融领域如何应用？ [A-B]

•                              五种并行路线，互不竞争——每个路线解决金融行业中不同层级的语义问题：

1. FIBO（EDM Council）：OWL 2 DL 金融业本体，覆盖金融工具、商业实体、LEI 集成。双组织治理（EDM Council + ISO）。形式化程度最高，部署率最低。核心场景：监管报告（BCBS 239）、风险管理、合规。

2. LEI（GLEIF）：法律实体标识符标准，G20 背书。全球唯一标识系统——不是完整本体，但提供了最基础层的语义锚点（谁是交易对手？）。

3. XBRL：监管报告标准，全球多数监管机构强制使用。核心贡献：将财务报告从文本流转化为结构化标记数据。

4. FDC3（FINOS）：桌面互操作协议——解决"金融从业者桌面上的多个应用无法通信"的问题。FDC3 的描述称此为 "integration nightmare"。数十家金融机构已认证。

5. Palantir Foundry：专有动态元数据本体路径——非 W3C 标准栈，将本体定位为"数据管道与应用之间的胶水层"。

•                              一条主线贯穿：金融的命脉在于数据互通 + 合规可追溯 + 语义无歧义——这些恰好是本体的核心承诺。这不是巧合，是天然寄生关系：金融行业的根本需求与本体的技术能力高度匹配。

•                              谁付费？ 行业标准（FIBO/FDC3）由联盟成员费/基金会资助；LEI 由 GLEIF 运营收费；XBRL 由监管强制 + 软件认证收费；合规系统由金融机构的合规预算直接买单。监管强制力是最强的驱动因素。

•                              结论： 五种路线解决不同层级问题，互不竞争。金融与本体存在天然寄生关系——金融的核心痛点（数据互通、合规、语义无歧义）正好是本体的核心承诺。监管强制力是最强的落地驱动力。[A-B]

T11 — Ontology 技术如何商业化？商业模式和市场规模？ [B]

•          三层嵌套不可叠加模型（来自 III.2 市场结构分析）：L1 数据/决策平台（Palantir 5-50M 级，私营不披露）→ L3 行业标准（~$500M-1B 隐含，非商业）。三层有独立的买家决策链和盈利模式，不可简单叠加求总。

•                              仅 Palantir 有公开财务数据——这是整个投资分析中最重要的限制条件。L2 公司（Stardog、Ontotext、TopBraid、PoolParty）均为私营，不披露营收。L3 由标准组织/联盟治理，不存在"营收"概念。因此整个市场规模分析依赖于一个公开数据点 + 估算。

•                              网络效应偏弱——与传统平台企业（AWS、Salesforce）不同，本体的价值主要在对内整合和垂直场景绑定中实现，而非跨组织的网络效应。这限制了 TAM 扩展速度。

•                              AI Agent 正在改写叙事：Palantir Ontology MCP 和 MS Fabric Ontology 的方向性信号是——ontology 正在从"知识存储"转变为"Agent 的操作系统"。如果这一叙事成立，L1 的 TAM 可能重新定义。

•                              核心商业模式分三种：（1）平台订阅（Palantir，$4.48B 的 SaaS 模型）、（2）许可+咨询（Stardog/Ontotext，中小企业购买许可证+集成服务）、（3）标准会员费（FIBO/LEI，联盟治理模型）。前两者是企业级软件模式，第三是基础设施模式。

•                              结论： 三层嵌套不可叠加，仅 Palantir 有公开财务数据。网络效应偏弱——价值在对内整合而非跨组织连接中实现。AI Agent 正在改写 L1 的叙事——ontology 从"建模工具"变为"Agent 操作系统"可能重新定义 TAM。总体置信度 B——因仅一个公司有公开财务数据。[B]

T12 — Ontology 公司的投资护城河是什么？Palantir 的护城河有多深？ [B]

•                              Palantir 的三重锁定模型（由宏观到微观递增黏性）：

1. 数据锁定：迁移成本极高——ontology 与客户的私有数据模型深度绑定。将 Palantir 的 ontology 层迁移到竞品，等价于重新建模整个业务的数据语义。

2. 逻辑锁定：嵌入操作流程的"manufacturing triage models"等专有模型——不是只存储数据，连怎么做决策的逻辑也在 Palantir 内部运行。

3. 动作锁定：Actions 和 workflow 绑定后，日常操作都依赖 Palantir 运行。这是"移除 Palantir 业务就停摆"级别的深度锁定。

•                              Top 20 客户 expansion +45% ——这是最强的 revealed preference（显示性偏好）信号：现有客户在持续扩大采购。在 enterprise SaaS 中，expansion 率是产品黏性的第一指标。

•                              但关键指标缺失：NRR（净留存率）未披露——这是 SaaS 公司护城河深度的标准度量。没有 NRR 就无从定量判断"客户锁定有多深"。

•                              风险因子：39-45% 的政府收入受 termination-for-convenience 条款约束——美国政府可以在任何时间以"便利"为由终止合同而无需违约。这意味着近半收入池存在理论上的年中断风险。

•                              竞争可替代性：NASA 案例提供了从 Protégé 迁移到 Palantir 的全过程记录，证明了本体平台的"迁移路径存在"——迁移可行但成本高、周期长。

•                              核心判断：有护城河，但不知道有多宽多深。 三重锁定模型在逻辑上有说服力，+45% expansion 是强力实证信号。但 NRR 缺失使深度不可量化，39-45% 的政府收入受 termination 约束是结构性弱点。FedRAMP 认证是进入壁垒，但不是不可跨越的。[B]

Part V: 结论——本体的现在与未来

V.1 核心论点

Ontology 技术栈正在分裂为 Formal Ontology（学术/标准）和 Operational Ontology（企业/平台）两个范式，而商业价值主要在 Operational Ontology 侧实现。 这一分裂不是学术问题——它决定了 TAM、产品形态、竞争格局和估值锚点。

支撑这一判断的三个理由：

1. 市场已用营收投票。

￮       Palantir $4.48B 选择了操作型路线

￮       微软 Fabric Ontology 入场确认了大趋势

￮       L2 语义平台（Stardog/Ontotext 等）营收仅 $5-50M 级，差距 1-2 个数量级

2. AI Agent 对"可操作的语义基础设施"的需求远大于对"可推理的形式化模型"的需求。

￮       Palantir Ontology MCP 的推出是方向性信号——本体不再是知识存储，而是 Agent 的操作系统

3. 定义边界本身在模糊化。

￮       当 Palantir/Fabric 称自己的产品为 Ontology，市场接受度在上升而非下降

￮       Operational Ontology 正在用自己的商业成功重新定义这个术语

V.2 四个关键不确定性

V.3 对 invest2 读者的操作指引

本体作为投资类别——几乎不可投。

•                              唯一纯标的 PLTR 估值偏高（PS ~66x）且关键指标缺失

•                              本体更接近"平台功能特征"而非"独立投资类别"——其商业价值在平台内部实现

这一判断（"不可独立投资"）与 I.5 中"四道不可替代能力"（形式化语义约束、版本化治理、跨系统互操作、业务规则强制执行）并不矛盾——不可替代 ≠ 可独立投资，因为价值主要在对内整合中实现而非作为独立产品捕获。

本体作为技术趋势跟踪——有价值。 关注三个信号：

1. Fabric Ontology GA 时间表 —— 决定"semantic layer as data platform standard"的大趋势

2. Neo4j IPO —— 第一个本体/KG 可比较基准

3. 非 taxonomy 关系提取和公理提取的突破 —— 谁先解决本体自动化的瓶颈

在 AI/Agent 趋势中嵌入本体视角。 真正的投资机会可能在"需要语义基础设施的 AI Agent"这一交叉领域。Palantir Ontology MCP 和 MS Fabric Ontology 的发展，以及 Agent 框架（LangGraph/CrewAI）对结构化语义的集成深度——将是决定 ontology 商业价值释放速度的关键变量。

贯穿全文的最终建议：最好的 ontology 不等于最成功的 ontology——在形式化光谱上选择合适的中等位置，匹配治理能力和商业路径，才是正确的投资分析框架。

Part VI: Sources & Methodology

来源说明

本文基于 95 份原始来源（49 Tier A 标准/论文 + 41 Tier B 产业/产品 + 5 Tier C 博客），经由三阶段处理：

1. Phase 1-1.5： 来源审计 → 12 主题证据映射

2. Phase 2： S1 事实表 → S2 全量初提 → S4 修复 → S5 独立复核 → S6 终稿（12 主题）

3. Phase 3-4： 三组综合（理论根基/应用生态/商业金融）→ 产品对标矩阵 → 本备忘录

代表性来源列举（按层级分类）：

学术与标准（Tier A — 核心理论）：

•                              Lo et al. (2024) — OLLM: End-to-End Ontology Learning with LLM — Wikipedia F1=0.915, CoT 无效

•                              Du et al. (2024) — Ontology Learning LLM Review — 三阶段演进，六子任务框架，形式化 O=<C,H,R,A>

•                              Santos et al. (2020) — Ontology Evolution Management — 93 变化类型覆盖测试

•                              W3C OWL 2 Overview — 标准栈核心，OWA vs CWA

•                              Gene Ontology — 45K 术语, 630 万注释, 3200 物种

•                              SNOMED CT — 350K+ 临床概念，SNOMED International 治理

•                              UMLS / NLM — 术语集成框架，40+ 年政府资助

企业产品与文档（Tier B — 产业/产品）：

•                              Palantir FY2025 10-K (SEC) — 唯一公开财务数据 ($4.48B)

•                              Palantir Ontology Overview — 企业 ontology 产品定义

•                              Microsoft Fabric Ontology Docs — NL2Ontology, ontology graph, Preview

•                              Stardog NASA Case Study — KG 驱动的语义中间件案例

•                              Ontotext Finance Ontology Blog — 金融领域 KG 应用

•                              TopBraid EDG — 治理 + Policy-as-Code

•                              MS GraphRAG GitHub — 开源 GraphRAG 框架 (20K+ stars)

•                              EDM Council FIBO — 金融业本体标准 (OWL 2 DL)

•                              Protégé Desktop (GitHub) — G1 本体编辑器 (20+ 年维护)

•                              Apache Jena — Java RDF/OWL 框架

•                              Neo4j (Latka) — 营收推测 ($199.8M, 经 S5 复核)

行业评论与报告（Tier C — 博客/行业分析）：

•                              Neo4j Taxonomy vs Ontology vs KG — 三概念区分

•          KG Market Report (MarketsandMarkets) — 9.88B 预测

•                              Ontotext KYC Compliance — 金融合规场景

参考文献

本文正文中引用的关键文献：

1. Lo, A., Jiang, A. Q., Li, W., & Jamnik, M. (2024). End-to-End Ontology Learning with Large Language Models. NeurIPS 2024. arXiv:2410.23584. — OLLM 框架，Wikipedia Fuzzy F1=0.915，CoT 在本体学习中无效的发现。

2. Du, H. et al. (2024). A Short Review for Ontology Learning: Stride to Large Language Models Trend. arXiv:2404.14991. — 明确主张"LLM 完全自动本体构建不太可能实现"。

3. Santos, J. S., Silva, V. T., Azevedo, L. G., Soares, E. F. S., & Thiago, R. M. (2020). An Experimental Analysis of Tools for Ontology Evolution Management. ICEIS 2020. DOI: 10.5220/0009395601110121. — 93 种变化类型在 7 款工具上的覆盖测试，本体演化管理"几乎空白"结论的来源。

关键数据缺口

1. 财务数据： 除 Palantir 外所有本体/KG 厂商财务数据完全缺失。Palantir NRR 未披露。Neo4j 未上市。

2. 第三方评估： 独立切换成本量化分析缺失。所有护城河论述依赖厂商自述。

3. 地理覆盖： 中国市场全景完全缺失。

4. 产品基准： 独立 ontology 产品基准测试完全缺失。所有产品比较依赖厂商文档。

时效性说明

G2 工具（LangGraph / LlamaIndex）的演进速度极快（月级发布），本文的版本信息在撰写时可能已部分过时。建议每季度刷新关键指标。

免责声明

本文不是投资建议。所有非 Palantir 厂商财务数据为行业估算，仅作分析参考。