先给世界画张地图，再让 AI 住进去，一个技术人重读本体论的笔记

先说一件小事。前段时间朋友感冒发热我陪他去楼下药店买退烧药。柜台里摆着两种布洛芬和对乙酰氨基酚。驻店药师多问了一句有没有肝病史。他说有轻度脂肪肝她点点头把对乙酰氨基酚往回放了放递过来布洛芬。走出药店我愣了一会儿。这个判断是怎么完成的药师知道对乙酰氨基酚禁忌于肝病患者药师知道眼前这位客人属于肝病患者药师还知道感冒发热需要退烧药。三条知识一拼答案自己就蹦出来了她全程没碰搜索引擎。这就是本体论在干活只不过它藏在人的脑子里一藏就是几十年。而过去这两年我大部分工作时间都在干同一件事把这张藏在我们每个人脑子里的地图画出来画到机器能读懂的程度。这篇文章是我这段时间的笔记。不打算从定义讲起定义你们都查得到。我想把几件纠缠在一起的事情拆开哲学里的本体论到底是什么Palantir 的本体论到底做了什么以及为什么我判断AI 本体论是另一条更野的路。中间会夹不少我在一个真实平台上折腾的细节有代码有踩过的坑。一片药引出两千年的学问Ontology 这个词拆开看很朴素ontos 是存在logos 是学说。合起来关于存在的学说。听起来很玄但亚里士多德在《形而上学》里干的活其实特别接地气他试图回答四个问题。这个世界里有什么东西真实存在这些东西该怎么分类它们之间有什么关系会如何相互作用这些关系和相互作用随着环境变化会发生什么变化你把这四个问题挪到医院就是内科、外科、骨科的挂号体系。挪到我们家药箱就是布洛芬作用于发热对乙酰氨基酚禁忌于肝病。挪到一家制造企业就是供应商、工厂、订单、物料、工艺路线以及它们之间那些说不清道不明的恩怨。所以本体论一点都不新。医院靠它挂号了几十年药典靠它编了几版老会计靠它定科目。它的核心作用就一句话消除歧义建立共识。让所有参与方对这是什么“它属于哪一类”它跟别的东西什么关系有一致的理解。真正的变化发生在最近几年。有人开始要求这张地图不能只画给人看还得画给机器看。人看地图模糊一点没关系上下文一补就懂了。机器看地图每一个概念、每一条关系、每一条约束都得是明文写出来的可查询可校验可推理。这个要求一提出来事情就变了。你画的 ER 图缺了半个世界写代码的人看到对象、关系第一反应往往是这不就是数据建模吗ER 图、类图、领域驱动设计我们干了二十年了。我原来也这么想。直到有一次我在一个项目里试图回答一个很简单的问题库存周转率跌了系统为什么不自己处理把当时的流程摊开看。分析师在 BI 报表里发现周转率跌了 18%截图拉会查数定位到华东仓的补货策略出了问题。然后呢打开 ERP手工调整补货计划再发个邮件通知采购。前后三天。这三天里那个 18% 在报表里躺得笔直真实世界照旧在转该缺的货照缺。问题出在哪不在于没有数据也不在于没有系统。ERP、CRM、SRM 这些跑事务的 OLTP 系统都在BI、数据中台这些做分析的 OLAP 系统也在。问题在于这两边是两拨人、两套模型、两种语言建出来的。分析系统发现问题之后到业务系统执行动作之间隔着人工隔着截图隔着会议室。我见过最典型的一次打架。CRM 团队和数据分析团队对客户的定义谈了一下午CRM 说客户是签了合同的法律主体分析侧说客户是所有有过成单记录的账号财务那边幽幽补了一句客户是回款方。三个定义都没错三套系统各建各的于是同一个自然人在三家系统里有三个身份。这种事每家公司都在上演只是规模不同。后来大家搞 TP/AP 一体化把数据打通了。但很快发现数据层面的融合解决不了根本问题因为割裂发生在更上面一层语义层。库存周转率这个概念在 BI 里是一张物化视图在 ERP 里是几十张表的隐含逻辑在采购经理脑子里是一段经验。三者之间没有一张共同的地图。传统数据建模为什么补不上这个缺因为 ER 图只回答了有什么东西和东西之间有什么外键关系。它不回答这个东西能干什么“干这件事要遵守什么规则”“状态怎么流转”。换句话说它建了名词漏了动词和法则。而真实业务里值钱的恰恰是动词和法则。你去看任何一个资深业务专家和新手的差距从来不在名词表上在于他脑子里那套什么情况下该做什么、什么操作绝对不能碰的东西。ER 图装不下这个文档装得下但机器读不懂。Palantir 的桥聪明但只修在旧河上这时候可以请出 Palantir 了。很多人对 Palantir 本体论的印象是在数据模型上加了层关系。这个理解是错的而且错得关键。Palantir 本体真正的核心是行为建模也就是把促进数据形成的行为和促进数据流转的行为也建进模型里。对象会执行行为行为会调用规则和约束三者互相咬合是一个整体。它的运作机制拿供应链中断这个经典场景走一遍就很清楚。某种核心材料断供了这首先是一个事件。事件进入消息管道触发两类规则采购计划调整规则和客户交期承诺调整规则。规则算出具体的调整结果然后通过业务系统开放的 API把结果回写进 ERP 和 CRM。人的角色退到只剩审核审完自动更新。发现问题分析问题解决问题整条链路是连贯的、自动化的。你仔细看这个机制会发现Palantir 干的事本质上是在已有的 OLTP 系统和 OLAP 系统之间架了一座桥。数据中台的指标触发预警本体层的 Function 行为关联到具体对象事件流进管道规则计算行动方案API 回写业务系统。桥修得很漂亮闭环也真的闭上了。但我总觉得这里面少了点什么。这座桥是修在旧河上的。河两岸的城市OLTP 一座OLAP 一座当年是分开规划、分开施工、各自为政建起来的。Palantir 没有重建城市它在两岸之间做了连接让分析与执行终于能握手。可如果今天你要建一座新城还要先按老图纸把两座割裂的城市盖出来再花大价钱修桥吗这就是我判断 AI 本体论是另一条路的起点。另一种野心让 AI 从第一天就搬进来住AI 本体论的目标用一句话讲是为 AI 构建一套完整的业务语义模型。关键词是为 AI。这张地图存在的意义是让大模型真正读懂业务的对象、行为和规则进而做语义对话、做智能编排、做深层推理。它有两条腿。面对存量系统它同样能打通已有的 OLTP 和 OLAP这一点和 Palantir 重合。但另一条腿是 Palantir 不走的它可以从零到一构建系统。一套系统在诞生之初底层就是同一个本体模型从第一天起就不分什么 OLTP 和 OLAP事务和分析跑在同一张地图上。这件事为什么成立因为 AI 原生应用的逻辑变了。传统做法是先把系统建好再挂一个 AI 模块上去像给房子后装空调。AI 原生的做法是AI 的能力从你有建系统这个想法的那一刻起就在里面跟系统一起长。它参与建模参与写代码参与测试参与运行态的进化。我在平台上完整跑过一遍这个流程四步。第一步跟 AI 多轮对话迭代本体模型。你说人话它画实体、连关系、定状态机来回掰扯几轮最后落成一份精确的语义定义。第二步基于这份模型让 AI 开发能力层的 Skills 技能包。第三步生成本体驱动的混合交付式前端界面。第四步进入运行态用户按意图自然语言操作。效果是有点吓人的。一个合同管理的 AI 原生应用AI 编程两三个小时出头就吐出来了能跑。后来又跑通了供应链智能计划。当然前提是本体模型先立住了这不是 prompt 念咒先有地图再有施工队。多说一句第一步多轮对话迭代建模是什么体验。你说构建一个商机驱动项目交付的应用它先反问你商机的唯一标识是什么一个商机可以对应几个交付单延期由谁判定。你会发现自己答不上来的地方恰恰是系统将来必然出错的地方。跟 AI 掰扯本体的过程本质上是一次业务知识的体检很多公司做了十几年生意从来没把这些东西白纸黑字写下来过。对象、行为、规则一个都不能少回过头把融合建模这个事掰开。一套完整的本体模型我认为至少要覆盖三层少一层都是残废。对象层实体、关系、属性、状态、生命周期。比如战场态势场景里的 Situation 这个实体它不是一行记录它有状态机OBSERVED → ASSESSED → MITIGATED └──────→ REROUTED(异常分支)行为层事件和状态转换。工厂停机是一个事件FULFILLS 边从有效切到中断是一个状态转换这些都是模型里的一等公民不是日志里的一行字。规则层约束和计算。比如 severity 不是人填的是系统从 confidence 算出来再写回去的{rule_id:r_situation_severity,source:V:Situation.confidence,target:V:Situation.severity,compute:same_object expr,checks:[type_match,dead_knowledge,route_compile]}三层合起来才有资格谈那件最值钱的事打通从分析到执行的路线。注意是合起来只有对象的模型就是个好看的 ER 图只有行为的模型是个工作流引擎只有规则的模型是个规则引擎。融合才是本体。有了这张地图查询不再是对着几十张表写 join而是直接在语义上提问MATCH (s:Supplier {tier:A})-[:SUPPLIES]-(f:Factory)-[:FULFILLS]-(o:Order) WHERE o.status IN_TRANSIT AND f.status STOPPED RETURN s.name, count(o) AS impacted_orders问的是业务答的也是业务中间的翻译地图替你做了。把它做出来一个平台的手记道理讲完了讲讲落地。这一年我在一个本体构建平台上把上面的想法完整实做了一遍挑几个我觉得最关键的环节说说。第一个环节数据接入得贪心。企业里的数据散落在各种库关系型的 MySQL、PostgreSQL、Oracle国产的达梦、人大金仓时序的 TDengine、InfluxDB数仓的 ClickHouse图的 Neo4j向量的 Milvus消息队列 Kafka。接进来之后自动扫表结构、字段类型、注释、主外键人工确认后进入资产目录。这一步没有捷径地图的地基本来就是又脏又碎的活。source:mysql.sup.local:3306/suppliertype:RDBMSextract:-table_structure-field_types-comments-primary_and_foreign_keys第二个环节工作流要能自己转。数据源、数据处理、子图建模、本体库四类节点在画布上连成流水线然后编排引擎每隔几分钟扫一遍就绪的节点自动执行。哪一步出错回溯到具体节点调试源表字段和目标实体的映射一行行摆在那里。这一点我特别想强调很多人做 AI 生成代码生成完就完了出了问题不知道改哪。而在工作流这套结构里每个处理节点都挂着三样东西AI 生成的代码、在线跑的单测、字段级映射预览。代码可以重新生成映射可以人工修正单测保证改了之后不会悄悄坏掉。可调试性不是锦上添花是没有它第二条流水线就没人敢用。第三个环节我认为是整套东西的灵魂闭环。两个闭环。推演失败的时候系统自动识别缺口是派生规则没覆盖这个场景还是状态机少了分支然后回改本体重新推演。孪生页面空白的时候定位到缺了一个查询自动补上重建页面。AI 改的不只是代码是企业运行的这个世界而且每一次改动都留痕有证据编号可回溯。第四个环节验收必须铁面。系统里有条硬规则可交付检查六项全过才算交付完成不等于可交付。很多人觉得这苛刻我的看法相反AI 参与构建之后这条规则是唯一能让人睡得着觉的东西。最后是知识库。文档进来语义分片建三层索引向量、实体、三元组。抽出来的三元组直接写进图谱这一步特别妙文档知识和图谱知识从此不再分家。检索的时候四路召回混着来向量相似、实体关联、推理路径、社区摘要各带权重向量 0.4 实体 0.3 推理 0.2 社区 0.1实测下来比纯向量检索的命中率高一截这是能拿到桌面上讲的数字。地图画好之后上面能长出什么平台是骨架真正的价值长在骨架上面。这一年多我看过不少跑起来的应用归纳下来大概七类挑有代表性的说说你就知道这张地图的承载力有多大。最普遍的是智能客服。以前的客服机器人靠关键词匹配和意图分类硬撑用户换个说法就露馅。有了本体之后不一样退货这个词背后挂着订单的状态机、售后期的约束、退款的规则AI 是真的理解用户在问什么回答自然就准。和它一体两面的是知识助手重点从听懂挪到答准术语歧义在语义层被消除每句话都有出处答案有据可查。再往深一层是数据分析 Bot。前面说过客户三个定义打架的事反过来讲只有本体把指标口径对齐之后AI 分析师才敢放开手脚。你问库存周转率为什么跌了它知道这个指标关联哪些实体、哪些关系、算到哪一层不会拿 BI 的口径去 join ERP 的表。同名异义这种坑在语义层就被填掉了。更激进的是业务流程自动化代理。传统 RPA 本质是录屏回放界面一改就全废。本体驱动的代理不一样状态怎么流转、每一步谁有权操作规则全是明文AI 在规则框里行动越权操作在模型层面就被拦住。我个人觉得这一条比效率更值钱敢把操作权交给 AI 的前提是它碰不了不该碰的东西。然后是本体推理决策最接近本体论原始野心的用法。基于关系网络推理从当前态势推出几条可行的行动方案评估每条方案的连带影响挑出最优的那条军方管这个叫 COA。供应链断供那个例子就是这一类规则和关系都在图谱里所谓推理不过是顺着边把后果走了一遍。数字孪生也离不开这张地图。实体状态实时映射工厂停没停、订单走到哪、哪个仓要爆态势一屏可见。本体的作用是给孪生体一副统一的骨架否则各系统各画各的孪生拼到一起还是三张互相不认识的图。走得最远的是具身智能和世界模型。机器人要在物理世界里行动光有视觉不够得有空间和因果的先验结构什么东西在哪里碰了会怎样影响怎么传导。这套结构化的世界知识说到底就是一套本体。这个方向还早但方向感是对的再聪明的脑子也得装在一个有秩序的世界里。摊开对比有本体和没本体上面讲的是能看见的应用。再往回退一步说说这套东西到底改变了什么。四组对照每一组我都亲眼见过两边。第一组是语义。没有本体的组织词不达意是常态同一个词在不同系统里含义不同开会一半时间在对着暗号有了本体语义统一人和人对概念的理解一致人和机器之间也是。第二组是知识。没有本体知识散落在代码、文档和老员工的脑子里机器读不懂人也找不全本体把业务规则从这些地方显式地提出来变成机器可读、可推理的明文知识第一次成为可计算的资产。第三组是推理。没有本体的 AI能回答问题但执行不了动作分析和执行之间隔着断崖有了本体分析发现问题推理找到原因行动函数执行变更事件回流验证结果闭环真正闭得上。第四组是维护。传统系统里业务规则一变就要改代码牵一发动全身响应速度永远追不上业务本体的规则和计算是模型的一部分改规则不改代码模型在线更新系统跟着业务一起长。所以那句话我越来越信本体不是数据模型它是让 AI 拥有业务常识的操作系统。AI 不是黑盒也不该是实习生写到这儿有个绕不开的问题把这么多权力交给 AI凭什么信它我的答案朴素让每一步都看得见。需求澄清的产物落在docs/requirements.md执行计划有版本号每次推演有证据记录Agent 的思考过程可以展开看它检索了哪条知识、命中了哪条规则。AI 干了什么依据是什么改了哪里结果如何四问皆有账可查。还有一条容易忽略知识是会陈旧的。推演得出的结论审核之后归档进知识库变成下次推理的依据。AI 用得越多企业这张语义地图就越厚这是一个会复利的资产而不是一次性的外包交付。我管这个叫AI 不是黑盒也不该是无证上岗的实习生。它是拿着完整操作手册、每一步都签名的正式员工。一套模型走到底绕了两千年收个尾。从亚里士多德的存在之问到医院的挂号表到 Palantir 架在旧系统上的桥再到让 AI 从第一天就住进来的新系统本体论这条线其实一直在回答同一个问题我们如何对世界的结构达成共识并且让这个共识可以被使用。分歧在于给谁用。给人用ER 图加文档就够了。给分析引擎用Palantir 的桥够了。给 AI 用并且要让 AI 参与建设那就必须从对象、行为、规则的融合建模开始把系统建在本体上而不是把本体补在系统后头。我的判断未来企业 IT 的底座会收敛成一套模型事务和分析不再各建各的分析与执行之间的墙由本体和 AI 一起拆掉。有人给这个方向起了个名字业务语义操作系统。名字不重要重要的是方向地图先画好AI 再住进来然后让它们一起长。至于那座桥还要不要修要的。存量世界那么大桥永远有生意。只是别再让新城按老图纸施工了。