本体论紫皮书:四种本体的技术本质、实践案例与选型决策电子书

内 容 提 要

作 者 简 介

总序 一套书，五种问法

前言

第1章 本体论的源流：从亚里士多德到工程落地

1.1 哲学源流：亚里士多德的范畴论

1.2 信息科学引入：Gruber的经典定义

1.3 技术分化：一条河流的四个分支

1.4 当前的混乱与本书的立场

第2章 四象框架：四种本体的定位与区分

2.1 分类维度：静态－动态×严谨－务实

2.2 四象定位图

2.3 四种本体速览

2.4 一个类比

2.5 本书的阅读路径

第3章 面向严谨工业标准规范的本体

3.1 技术本质

3.1.1 描述逻辑

3.1.2 开放世界假设

3.1.3 本体五件套

3.2 核心构件与建模流程

3.3 代码实战

3.3.1 代码块1：OWL/RDF Turtle本体定义

3.3.2 代码块2：SHACL约束校验

3.3.3 代码块3：Python推理实战（rdflib+owlready2）

3.4 技术架构与部署选型

3.4.1 三元组存储选型

3.4.2 推理机选型

3.4.3 TBox/ABox分离架构与增量推理vs批推理

3.4.4 建模协作流：Protégé+版本管理

3.4.5 部署拓扑

3.5 行业案例：民航适航本——体发动机型号推理

3.5.1 背景

3.5.2 建模过程

3.5.3 推理结果

3.5.4 业务价值

3.6 补充案例一：医疗SNOMED CT——临床术语本体的描述逻辑实践

3.6.1 背景

3.6.2 建模过程

3.6.3 推理结果

3.6.4 业务价值

3.7 补充案例二：制造业产品BOM配置——用OWL公理自动检测配置冲突

3.7.1 背景

3.7.2 建模过程

3.7.3 推理结果

3.7.4 业务价值

3.8 补充案例三：政务法规合规推理——条款传递引用与豁免推理

3.8.1 背景

3.8.2 建模过程

3.8.3 推理结果

3.8.4 业务价值

3.9 实现坑点

3.9.1 坑点一：用OWA思维写闭口约束

3.9.2 坑点二：滥用owl:unionOf/任意复杂构造子导致推理爆炸

3.9.3 坑点三：命名空间与URI混乱导致三元组无法关联

3.9.4 坑点四：把本体当数据库用，忽视TBox/ABox分离

3.9.5 坑点五：推理机不收敛/超时的工程应对

3.9.6 坑点六：本体版本演化与迁移治理

3.10 本章小结

第4章 面向数据治理和搜广推工程落地的本体

4.1 技术本质：遍历而非推理

4.2 核心构件与建模流程

4.3 代码实战

4.3.1 创建Schema约束与索引

4.3.2 创建节点与关系实例

4.3.3 多跳遍历查询

4.3.4 Python+GraphRAG：Text2Cypher模式

4.4 技术架构与选型

4.4.1 图数据库选型决策

4.4.2 索引策略与查询优化

4.4.3 写入路径：流式Ingestvs批量ETL

4.4.4 GraphRAG架构深入

4.4.5 部署拓扑

4.5 行业案例：金融反欺诈——隐藏关联挖掘

4.5.1 背景

4.5.2 图谱建模

4.5.3 多跳查询发现隐藏关联

4.5.4 业务价值

4.6 补充案例一：搜广推关联推荐——用户－商品－行为图谱做关联推荐

4.6.1 背景

4.6.2 图谱建模

4.6.3 多跳推荐查询

4.6.4 GraphRAG增强

4.6.5 业务价值

4.7 补充案例二：公安情报反诈——多跳图谱发现隐藏犯罪团伙

4.7.1 背景

4.7.2 图谱建模

4.7.3 多跳查询

4.7.4 业务价值

4.8 补充案例三：药物重定位——多跳遍历挖掘老药新用候选

4.8.1 背景

4.8.2 图谱建模

4.8.3 多跳查询

4.8.4 业务价值

4.9 实现坑点

4.9.1 坑点一：LPG不具备推理能力，不要把它当OWL用

4.9.2 坑点二：标识局部性——Neo4j没有全局URI

4.9.3 坑点三：Schema弱约束——灵活是双刃剑

4.9.4 坑点四：大规模图查询性能——不是所有多跳都能秒出

4.9.5 坑点五：图数据写入热点与锁竞争——超级节点拖垮批量写入

4.9.6 坑点六：图谱Schema演化与历史数据回填——改了Schema，存量数据不一致

4.10 本章小结

第5章 面向数据自动化操作系统的本体（Palantir Ontology）

5.1 技术本质：不是语义层，而是决策操作系统

5.2 核心构件与建模流程

5.3 代码实战：OSDK定义与闭环模拟

5.3.1 代码块1：定义Object Type与Link Type

5.3.2 代码块2：定义Action Type与Function

5.3.3 代码块3：Python伪代码模拟完整闭环

5.4 技术架构与选型

5.4.1 Build-vs-Buy：什么场景值得Foundry，什么场景该自建

5.4.2 Object映射策略：虚拟化vs物化

5.4.3 Writeback模式：同步/异步/批量

5.4.4 AIP Agent集成模式：Proposal→Action的安全衔接

5.4.5 部署拓扑

5.4.6 选型本质

5.5 行业案例：供应链应急调度——从感知到执行的自动化闭环

5.5.1 背景

5.5.2 事件触发

5.5.3 Agent生成Proposal

5.5.4 Function遍历备选供应商

5.5.5 Action执行改单

5.5.6 副作用通知

5.5.7 数据回流

5.5.8 关键启示

5.6 补充案例一：航班改航——天气突变下的AIP辅助决策闭环

5.6.1 背景

5.6.2 事件触发

5.6.3 Agent生成Proposal

5.6.4 Function评估备降机场

5.6.5 Action执行改航

5.6.6 副作用与回流

5.7 补充案例二：电力电网调度运营——秒级闭环的安全约束

5.7.1 背景

5.7.2 本体建模

5.7.3 闭环执行

5.7.4 业务价值

5.8 补充案例三：零售门店运营决策——缺货预警驱动的跨店闭环

5.8.1 背景

5.8.2 本体建模

5.8.3 闭环执行

5.8.4 业务价值

5.9 实现坑点

5.9.1 坑点一：平台锁定——Ontology不是可移植的资产

5.9.2 坑点二：建模沉重——过度建模的刚性陷阱

5.9.3 坑点三：Action副作用级联——隐式依赖链的灾难

5.9.4 坑点四：Ontology命名误导——语义本体团队的预期落差

5.9.5 坑点五：Object映射与源系统Schema漂移——映射层的隐性断裂

5.9.6 坑点六：Action权限模型设计过粗或过细——安全与敏捷的两极失衡

5.10 与语义本体的关键区别

5.11 本章小结

第6章 面向Agent决策治理的本体（Agent Ontology）

6.1 技术本质：约束而非推理，治理而非执行

6.2 核心构件与建模流程

6.3 代码实战

6.3.1 代码块1：Agent Ontology YAML定义

6.3.2 代码块2：Harness约束校验类

6.3.3 代码块3：完整Agent执行循环

6.4 技术架构与选型

6.4.1 Harness放置位置：进程内vs网关SidecarvsSDK内嵌

6.4.2 规则引擎选型

6.4.3 工具契约：MCPvsOpenAI Function Calling

6.4.4 Prompt注入与Guardrail分层防御

6.4.5 评测与可观测性

6.4.6 部署拓扑

6.5 行业案例：民航维修工卡助手——约束驱动的安全查询Agent

6.5.1 背景

6.5.2 Ontology定义

6.5.3 交互示例

6.5.4 正常查询场景

6.5.5 业务价值

6.6 补充案例一：金融投资顾问——合规约束下的推荐Agent

6.6.1 背景

6.6.2 本体定义

6.6.3 交互示例

6.6.4 业务价值

6.7 补充案例二：电商客服退款助手——资损防线Agent

6.7.1 背景

6.7.2 本体定义

6.7.3 交互示例

6.7.4 业务价值

6.8 补充案例三：法律合同审查助手——防幻觉只读审查Agent

6.8.1 背景

6.8.2 本体定义

6.8.3 交互示例

6.8.4 业务价值

6.9 实现坑点

6.9.1 坑点一：把Agent Ontology当Palantir Ontology用——混淆约束治理与执行

6.9.2 坑点二：约束过紧导致Agent失去灵活性——过度治理的刚性陷阱

6.9.3 坑点三：语义层与LLM能力不匹配——定义了LLM理解不了的概念

6.9.4 坑点四：缺少反馈闭环——规则不随执行结果进化

6.9.5 坑点五：规则爆炸与可维护性——规则膨胀到几十条后失控

6.9.6 坑点六：LLM版本升级导致约束失效——模型一换，规则全废

6.10 本章小结

第7章 四维对比矩阵：本质区别一览

7.1 全景对比表

7.2 架构对比图

7.3 三个关键分水岭

7.3.1 分水岭一：推理vs遍历vs执行vs约束

7.3.2 分水岭二：开放世界vs封闭世界

7.3.3 分水岭三：只读vs读写vs治理

第8章 选型决策框架与路径

8.1 决策树

8.2 场景匹配表

8.3 组合使用模式

8.3.1 模式一：Semantic Ontology（知识层）+KG Schema（查询层）

8.3.2 模式二：KG Schema（数据层）+Palantir Ontology（执行层）

8.3.3 模式三：Palantir Ontology（业务层）+Agent Ontology（治理层）

8.4 选型常见误区

8.4.1 误区一：用知识图谱替代一切

8.4.2 误区二：混淆概念层级与实例关联

8.4.3 误区三：忽视世界假设的后果

8.4.4 误区四：过早追求全栈组合

第9章 行业案例集锦

9.1 民航业

9.1.1 适航审查→Semantic Ontology

9.1.2 航线网络分析→KG Schema

9.1.3 运行控制决策→Palantir Ontology

9.1.4 维修工卡Agent→Agent Ontology

9.2 金融业

9.2.1 反欺诈关联分析→KG Schema

9.2.2 投顾Agent→Agent Ontology

9.3 医疗健康

9.3.1 临床术语标准化→Semantic Ontology（SNOMED CT）

9.3.2 诊疗辅助Agent→Agent Ontology

9.4 制造业

9.4.1 供应链调度→Palantir Ontology

9.4.2 设备维修Agent→Agent Ontology

9.5 跨行业启示

附录一 术语对照表

附录二 技术栈速查卡

附录三 术语索引

致谢

后记