企业上知识图谱与本体论，最难的不在算法而在场景与团队。文章以中后台、电商、医疗三类AI客服为切口，拆解确定性推导、情绪意图与循证证据链三种能力边界，指出多数项目卡在数据与产研协同，而非模型本身，并给出团队配置与成本判断。

我们之前说过，在 AI 世界的三年，在持续稳定消耗 Token 的业务有：

1. 各种官网如 ChatGPT、DeepSeek、豆包；
2. 视觉 AIGC，核心为文生图、文生视频；
3. AI Coding；
4. 最后就是三年屹立不倒的 AI 客服及其各种变形了；

只不过，之前各个公司在 AI 客服的需求还比较简单，多数是在中后台玩玩而已：把制度、产品手册、项目材料放进去，员工问一句，AI 帮忙找到相关内容，再组织成一个答案。

也有不少公司在线上核心业务启用 AI 客服，但实际做起来还是很慎重的，会有明显的边界和风险等级划分：

前两年虽然已经有公司在这条路上走得比较远、比较深了，但多数公司依旧在隔靴搔痒，但在我今年拜访、陪跑的企业里面，关于知识库的需求明显变多、变深了：

1. 中后台场景

今年中后台 AI 客服面对的问题明显不一样了，比如：

1. 这个客户与哪些合同、订单、回款和风险有关？
2. 某个供应商如果断供，会影响哪些生产计划和客户订单？
3. 同一个设备在不同渠道用了不同名字，到底是不是同一款产品？

因为之前各个公司喜欢在内部试错，所以现在反而是这块走在了前面，这种企业内部 AI 客服想要解决的是确定性世界的复杂推导。

什么意思呢，他只是当前复杂 AI 知识库的一个品类，中后台的困难，主要来自企业对同一件事用了不同名称、编码和口径。

在这个场景下主要的逻辑是闭合的，但关系、层次会变多，名字也会很乱，AI 在这个场景的角色相当于一个数据 BI 负责人，已经不是最初简单的 AI 客服了，他要把数十张表格的关系理清、让他有价值，但推理又不能出错。

这是很多企业追求的内部运营大脑具象化的体现，因为是内部业务，错了顶多被骂两句，也不会影响线上业务，于是 AI 化在这块就彻底疯狂了。

但是，这种东西当前状态是比较奇怪的，他负责人往往会是财务、或者招聘一波数据团队，但这两个团队都不是能把这件事做好的人，所以实际能做好的公司是很少的。

我看见少数做得不错的公司，一般是一号位工程，或者是某个产研给了足够的空间在带队…

2. 电商场景

电商也是我们咨询、陪跑的大头，也很典型，变化也很大，甚至可以说去年的案例是所有人对 AI 的试探，因为之前实际交给 AI 的工作是比较少的，并且往往有真实的客服在后面兜底，比如以下问题几乎完全是我们臆想出来的用户问题：

1. 七天无理由退货规则是什么？
2. 这个商品有哪些颜色？
3. 清洁设备应该怎么使用？
4. 物流一般需要几天？
5. …

上述问题是很理想化的，并不是说他们每项不会发生，而是真实场景用户他不这么玩，他的问题输入是五花八门的，比如：

1. 页面写着七天无理由，为什么这个用户的这笔订单不能退？
2. 用户发来一张破损照片，应该补发零件、换货还是整机退款？
3. 用户要求周五前收到替换商品，不然就投诉！当前库存和物流能不能满足，还是不用管他安抚下就好？

综上，我们之前在试探、熟悉 AI 边界时候，希望 AI 做的工作是回答规则是什么，而其实用户压根不关注规则是什么，他们真实的需求是这笔订单应该适用哪条规则，并把事情办完。

所以，在电商场景 AI 客服的演进也就很清晰了：会说话的 FAQ → 真实的客服数字分身。

这里传统的 RAG 就比较难受了，因为用户很多问题是没有完全可重用固定路径的，还极度依赖上下文，AI 在这块不仅要做意图识别还得扮演情感大妈，并且要做权限分析乃至动作设计，这里就难咯。

所以，电商类 AI 客服其实是在解决人性化世界的情绪与混乱的意图，但这在医疗类场景又会有所不同：

3. 医疗场景

在医疗、金融甚至严肃教育类场景中，AI 客服的进一步深度需求又会有所变化，需要解决的是依据问题，也就是概率世界的证据链问题。

还是以医疗场景为例：患者症状不等于病因，指南推荐不等于患者就一定能用，这里面对的是一个概率的世界。

在这个场景中：

AI 结果正确是及格线，AI 过程正确才是准入线

AI 在这个场景里面像一个专业助理，提供最新的文献证据、指南推荐，辅助医生判断，他要求每个决策背后都需要清晰的逻辑链和依据，这就不是 RAG 这个概率框架能够碰瓷的了…

这里还是举个例子做对比：

1. 去年的典型问题：最新指南如何推荐这种疾病的治疗？
2. 今年的典型问题：患者同时存在肾功能不全、药物过敏和多种长期用药，新药是否存在风险？

如果上述问题，您敢用 AI RAG 直接上答案，我敢称您一声英雄！

医疗AI的角色因此出现了变化：医学搜索和文书助理 → 循证助理和临床信息整合者。

RAG在价值：找到指南、论文和说明书，再帮助医生阅读和整理；、

复杂问题需要同时处理：

• 患者历史状态；
• 当前检查结果；
• 药物与疾病关系；
• 确定性安全规则；
• 医学指南与文献证据；
• 概率性风险；
• 医生的最终判断；

综上，我根据近期市场上对 AI 知识库的一些需求变化，再结合自己三年来的一些项目实践的一些感受，这些事情合在就同时指向了一件事：

当前各个公司的知识库需求，已经逐渐超出了传统 RAG 的舒适区

本体论的故事

RAG 擅长从文档中寻找相关片段，至于相关片段与 AI 需要的知识是否相关，又可以大力出奇迹的多召回、再用 AI 判断一次即可，他是粗糙了点，但确实在一个阶段的解决了一些问题。

但企业现在需要 AI 识别业务对象、理解对象之间的关系、执行稳定的判断规则，这就不是 RAG 能够插手的部分了。

比如，上述三个场景的问题该如何解决，最终都大概率要回归到知识图谱与本体论。

其中，知识图谱大家多少都听说过，就算在大模型之前，他都还是有很多应用场景和落地的，而本体论就抽象多了，至少我就确实做过图谱但对本体没什么概念。

就我实践的结果和历史的经验，逻辑上来说，正经公司原本不太可能随便碰这个东西：实施贵、见效慢、跨部门扯皮多，做完以后还要长期维护，怎么看都不像一个能快速汇报成果的好项目。

它最近重新走红，一个重要推动者是 Palantir。

Palantir 的神奇之处在于，很多人嘴上说它是外包公司，它的市值却一度冲进数千亿美元区间，资本市场显然把它当成了一家极其稀缺的软件公司。于是业内开始研究它的商业模式、FDE 组织、共创式交付、AI 操作系统，以及被它反复强调的 Ontology。

Palantir 官方对 Ontology 的描述也远远超出了传统知识图谱：它把数据、逻辑、动作与安全统一进一个以决策为中心的企业模型，让人和 Agent 在同一套业务语义上查询、推理和行动。对象、属性、关系、Action、Function、权限都在这套体系里。

于是这里就有了一个很诱人的故事：

只要把企业里的人、货、场，设备、订单、供应商、客户，以及它们之间的关系全部建模出来，AI 就能真正理解企业，最后长成一个企业级 AI 操作系统

听起来非常美好，甚至有点像企业 AI 的终局。

但只要真正做过一次知识图谱或者本体项目，就会知道这里面还有另外一个个故事：

1. 建模建到一半发现对象拆错了；
2. 多个部门为了一个词争论几个月；
3. 数据清洗花掉一半预算；
4. 业务改了一条规则，所有历史数据、接口、页面和测试集都要重新检查；
5. 最后项目团队撤了，剩下一个没人敢改的知识底座；

所以到底什么是本体论，他的真正价值是什么，这个才是我们今天要讨论的事情，大家可以带着四个问题看这篇文章：

1. 企业语境下的本体到底是什么？
2. 什么问题确实需要它，什么问题用 RAG、SQL 和 API 已经足够？
3. 一套生产级本体系统到底怎么建？
4. 企业决定建设本体时，真正需要承担的成本是什么？

如果这四个问题说不清楚，本体论就很容易变成下一轮 AI 项目的高级包装词。

本体论在解决什么问题

关于什么是本体论，可以回到我们之前对知识进行拆解的方法：先穷举，再分类，再寻找关系，最后总结规则。

想象一下，你穿越到了一个修仙世界，第一天就问宗门大佬：

这个世界到底有什么？

他需要先告诉你，这里有修士、宗门、功法、法器和灵气。

然后还要继续解释：修士属于某个宗门，修士可以修炼功法，使用法器可能需要特定境界，修炼功法会消耗灵气，不同功法之间还可能相生相克。

也就是你拿到了一套关于这个世界如何组成、各种事物如何关联的说明书。

在传统知识工程中，本体负责定义一个特定领域里的概念、类别、属性、关系和约束。例如购物平台里可以定义：

商品是一类对象

价格是商品的属性

买家是一类对象

买家购买商品是一种关系

电子产品是商品的一个子类

这里要特别注意：本体定义了购买关系，并不会自动得到买了电子产品的人一定喜欢电子产品这个结论。要得到这个结果，还需要额外定义业务规则，例如：

如果用户在90天内购买某品类商品两次以上

并且没有发生全部退货

则将该品类记录为高置信度兴趣标签

概念、事实和规则经常被混在一起，这也是很多本体构建最容易迷糊的地方：

为了便于理解，可以把企业知识系统拆成七层：

传统 RAG 主要工作在前两层。它把问题转换成检索请求，找到相关片段，再交给模型生成答案。

而企业本体试图向下继续一层层走：把文档里的供应商识别成一个真实业务对象，找到它供应了哪些原材料，这些原材料进入了哪些生产计划，最后影响了哪些订单；系统再依据合同、库存和交付规则判断风险，并决定是否需要调整排产。

所以，本体论的价值，是让企业把自己的业务世界表达得足够清楚，再让 AI 在其中寻找知识、理解关系并执行判断。

规则引擎、知识图谱和本体

多数同学能理解规则引擎和知识图谱/本体的区别，但涉及到知识图谱与本体的时候就有点迷糊了，因为他们貌似相似度很高？

其实他们都是想要用语言（自然语言/代码语言/数据结构语言）去描述、表征真正的世界，现阶段虽然本体、图谱这边复杂度已经很高了，但他们依旧会有缺漏，仅仅是尽量补足。

规则引擎相对于后两者，信息量就尤为不足了，至于具体他们的区别，我们这里从后往前理：

本体：定义这个世界允许如何被描述

本体解决的是有哪些类型、属性、关系和约束。比如电商场景允许出现的业务对象及关系：

# 对象

用户

订单

商品

……

售后政策

退款

# 关系

用户创建订单

订单包含订单明细

……

售后政策适用于某个商品类别和销售渠道

这时候还没有判断用户能不能退款，只是把电商售后这件事里的名词、关系和边界定义清楚了。

如果客服系统认为赠品是一个普通商品，结算系统认为赠品属于促销权益，售后系统又认为赠品依附于主商品，三个系统后面一定会产生冲突。

本体在这里像一套概念字典加语法规则。从案例来说，也可以理解成：企业对订单、商品、赠品、优惠券和退款分别是什么的统一定义。

知识图谱：记录这个世界

知识图谱记录的是具体事实，他会想尽量客观的记录真实世界的关系。

他与本体论的关系是：本体规定数据应该按照什么结构表达，知识图谱保存按照这套结构生产出来的事实。

当然，真实工程里边界不会这么干净。有的图数据库里只有事实，没有本体；有的关系型数据库也在承载非常完整的业务对象和约束。

本体是一种语义建模方法，不依赖某一种数据库，你爱用撒用撒，用 Excel 都行。举个例子：

用户U1001 创建了订单O20260818

订单O20260818 来自直播渠道

订单包含精华液A、面霜B和赠品C

精华液A 实付分摊金额为189元

订单使用了优惠券C88和2000积分

赠品C已经拆封

精华液A存在漏液问题

用户提交了照片E102

售后申请S9001只针对精华液A

本体定义订单可以包含商品，知识图谱记录订单 O20260818 包含精华液 A； 本体定义售后申请可以针对订单明细，知识图谱记录申请 S9001 针对精华液 A，这里保存的是业务世界里已经发生的具体事实。

规则引擎：执行判断而已

规则引擎就比较简单了，他就是我们实际 SOP 的一部分，执行 if/else 判断即可，这个很简单，我们就不详细说明了：

配件类型符合安装位置

AND 物理接口兼容

AND 支持设备所属代际

AND 不存在更高优先级排除规则

→ 适配

最后，我们再聊聊图谱和本体的问题：

图谱与本体

最后用最初的说法：我之前做过知识图谱但没有做过本体是怎么个事，这句话是一个非常经典的案例，因为他的说法是错的，我已经涉及到了本体相关知识，只是我不知道！

在 CDSS 里记录下这些事实：

{

“患者张三”: {

“体温”: 39.2,

“心率”: 115,

“呼吸频率”: 24,

“血压”: “85/55”,

“白细胞计数”: 14000,

“主诉”: “发热、寒战”,

“就诊时间”: “2026-08-20 14:30”

}

}

但系统要判断是不是某具体疾病，脑子里面会有一套完整的逻辑的，而这套逻辑就是医学本体，比如：

{

“本体_综合征定义”: {

“脓毒症”: {

“判断逻辑”: “感染证据 + 器官功能障碍”,

“器官功能障碍的判断标准”: [

“体温 > 38.3 或 < 36”,

“心率 > 90”,

“呼吸频率 > 20 或 PaCO2 < 32”,

“白细胞 > 12000 或 < 4000”,

“收缩压 < 90”

],

“触发条件”: “以上标准中至少符合2项”

}

},

“本体_时间约束”: {

“脓毒症筛查窗口”: “上述异常指标必须在同一时间段（6小时内）同时存在”

},

“本体_动作定义”: {

“脓毒症预警”: {

“触发前提”: “符合脓毒症定义”,

“推荐动作”: “立即启动qSOFA评分、乳酸检测、考虑经验性抗生素”

}

}

}

这堆定义不是某人（张三）特有的，是全球脓毒症指南里写死的医学共识，也是医生大脑里面的核心知识，这东西其实就是本体…

系统真正跑判断时，是这么合成的：

{

“患者张三”: {

“事实”: “体温39.2，心率115，呼吸24，血压85/55，白细胞14000”,

“本体匹配”: [

“体温39.2 > 38.3 → 符合”,

“心率115 > 90 → 符合”,

“呼吸24 > 20 → 符合”,

“白细胞14000 > 12000 → 符合”,

“收缩压85 < 90 → 符合”

],

“匹配计数”: 5,

“本体规则”: “符合≥2项即触发脓毒症预警”,

“最终结论”: “脓毒症高危，立即启动预警流程”,

“推荐动作”: “qSOFA评分 + 乳酸检测 + 经验性抗生素”

}

}

所以，现在最粗暴的解释可能就出现了，本体论是某业务完整的 KnowHow，KnowHow 分为 SOP 与 数据，本体可以是 SOP（规则、定义、标准），Data 可以是图谱：

什么场景真的需要本体？

首先，大家要明确知道，无论本体论还是知识图谱，都属于比较重的技术路径了，这套东西打下来成本是很高的，所以：

适合本体的场景，通常具有相对稳定的语义核心、复杂的对象关系、较高的错误代价，以及长期重复发生的判断需求

这里说语义核心稳定，并不是要求业务完全不变，毕竟业务变化是不可避免的：医疗指南会更新，法律法规会修订，电商商品会增加。

业务变化是不要紧的，但你不能一个变化就需要改最根本的知识结构，并且图谱层和本体规则层修改的成本是不一样的：

下面六个点可以为你的判断提供一些依据：

1. 答案需要经过多跳关系才能得到

很多问题无法通过一张表、或者一次检索直接得到答案，它需要沿着多个业务对象连续向下寻找。还是以我最熟悉的医疗场景为例：

患者症状与检查指标

→ 可能疾病

→ 诊疗指南

→ 推荐治疗方案

→ 患者禁忌证

→ 当前用药

→ 药物相互作用

→ 可用方案

这里从症状到最终的解决方案，绝不可能仅仅是通过一次概率计算就算了。

2. 存在严重的对象身份混乱

企业系统中经常存在同一个东西拥有多个身份的情况非常普遍，例如，同一个客户可能同时存在：

CRM里的客户名称；

合同里的公司全称；

销售人员口中的客户简称；

本体可以将上下级对象、关联对象、历史版本等关系明确表达出来，让企业各类系统基于同一套对象身份继续判断，只不过得出的过程会存在严重的扯皮。

3. 存在继承、例外和组合规则

我们在做规则时候不得不偷懒，很少永远保持一条条件对应一个结果。以电商售后为例，基础规则可能是商品签收后七天内可以退货，实际执行时还需要同时判断：

商品是否已经拆封；

商品是否属于定制品、生鲜或者虚拟商品；

……

套装中的部分商品能否单独退回；

当前订单适用哪一版本的售后政策。

这里可能同时出现了类型继承、规则覆盖、时间有效性、例外条件和组合判断。本体可以明确：

1. 某个对象属于什么类型；
2. 它继承哪些通用规则；
3. 哪些特殊规则具有更高优先级；
4. 哪些条件共同成立时才能触发结论；
5. ……

4. 要求过程、结果可解释

有些场景只要结果大致合理即可，有些场景则必须说明每一步判断依据。例如，医疗辅助决策系统给出该患者暂不适合使用某种药物的结论时，需要同时展示：

使用了哪一版指南；

患者的哪些检查指标触发了限制；

存在哪些禁忌证；

当前用药是否存在相互作用；

哪条规则最终改变了推荐结果；

哪些关键信息仍然缺失。

这里跟多跳判断逻辑有点类似，模型生成一段听起来合理的解释，并不能直接作为审计证据。生产系统需要保存一条可以复核的判断链：

原始数据 → 业务对象 → 对象关系 → 命中规则 → 中间结论 → 最终结果

这块其实是很多生产场景真正选择本体论/只是图谱最核心的原因。

5. 同一套语义被多个业务系统重复使用

客服、商品、售后和供应链都在维护设备型号和适配关系，但每个系统都有自己的版本，错误和重复成本不断增加。

以医疗场景为例，这里的问题就会变成 A 医院有一套全面的知识图谱、B医院也有一套，但他们的症状类信息要不要统一存储问题。

6. 结论要进一步驱动业务动作

如果系统最终需要调整库存或者执行赔付，本体所提供的统一对象和动作边界会非常有价值。

上述就是可以考虑本体的场景，反过来，以下场景一般不要碰重型本体：

1. 普通知识问答；
2. 文档总结与内容生成；
3. 一次性研究任务；
4. 低风险、允许模糊的推荐；
5. 业务模式还在频繁试错；
6. 数据基础极差；
7. 项目结束后没有长期负责人；

下面就用一个我们之前做过的案例，把这个过程完整走一遍…

PS：案例脱敏用了 AI，可能稍微会有点失真

案例：CDSS

我们最初在做 CDSS 的时候对本体论是没有概念的，也没有完全使用 OWL、RDF 这类标准，但现在回看确实是一套完整的本体逻辑。

假设一位老年患者因为肺部感染住院，医生准备给他使用一种抗感染药物。如果只是查询：

这个药可以治疗哪些疾病？

普通知识库或者 RAG 就能解决。

药品说明书、诊疗指南和医学文献里都有明确描述，系统找到相关内容，再整理成答案即可，事实上有很多用药助手产品就是这样玩的，但这里并不是没有工作量，药品说明书还是需要录入的…

只不过上述场景只能用于显示用户自发查询用着玩，如果医生面对的问题逻辑就变了：

这个患者现在能不能使用这个药？

问题一下就复杂了。因为这位患者可能同时存在：

• 肾功能不全；
• 某类药物过敏史；
• 长期服用抗凝药；
• 年龄较大；
• 当前还在使用其他几种药物。

指南可能推荐这款药治疗肺部感染，但指南推荐不代表这个患者一定能用。系统还需要继续判断：

• 患者的过敏史与这款药有没有关系；
• 当前肾功能是否需要调整剂量；
• 这款药与正在服用的抗凝药有没有相互作用；
• 老年患者是否需要额外监测；
• 当前证据是否足以支持系统给出明确结论。

所以，医疗 AI 里有一句话非常重要：

结果正确只是及格线，过程正确才是准入线，这里涉及到了符合医疗逻辑的 CoT 了

这是什么意思呢，意思是：系统的判断路径，就是本体的推理路径。

当医生问出这个患者现在能不能用这个药时，系统不能把资料扔给大模型自由发挥。它必须按照一套固定的、符合临床逻辑的顺序执行判断：

第一步：确认适应症 → 这款药是否适用于当前疾病

第二步：检查过敏史 → 患者是否对同类药物过敏

第三步：评估个体条件 → 年龄、肝肾功能是否影响用药

第四步：检查联合用药 → 与当前服用的药物有无相互作用

第五步：综合风险等级 → 决定输出提示、警告还是拦截

第六步：给出可追溯依据 → 每条结论都附上证据来源

这套流程的背后，其实隐含了一个完整的业务本体，它定义了这个世界有哪些对象：

患者、疾病、症状、检查结果、药物、药物类别、禁忌、相互作用、证据来源

它定义了这些对象之间有哪些关系：

患者 → 患有 → 疾病

患者 → 存在 → 状态（如肾功能异常）

患者 → 正在服用 → 药物

药物 → 用于治疗 → 疾病

药物 → 属于 → 药物类别

药物 → 受影响因素 → 状态

药物类别 → 与过敏史相关 → 过敏物质

药物 → 与其他药物存在 → 相互作用

它还定义了系统如何使用这些关系完成判断：

适应症检查、过敏筛查、个体条件评估、相互作用检查、风险分级、证据引用

这三层合在一起，就是一个完整的业务世界表达。只不过当年我们用数据库表、规则引擎和代码逻辑共同实现了它，没有单独贴一个本体的标签。

接下来大家感受下伪代码：

用 JSON 把当前患者的情况组织起来

从输入问题开始，系统先得把分散在病历各处的信息归集到这个患者名下：

{

“患者”: {

“年龄”: 68,

“当前诊断”: [“肺部感染”, “肾功能不全”],

“过敏史”: [“某类抗菌药”],

“长期用药”: [“抗凝药”],

“关键检查”: {

“肾功能”: “异常”

}

},

“本次任务”: {

“拟使用药物”: “药物A”,

“目标”: “判断当前患者的用药风险”

}

}

这份 JSON 记录了这个患者当前是什么状态，没有任何判断逻辑。接下来进入判断流程。

第一步：适应症检查

系统先查药物 A 的适应症范围，发现它覆盖肺部感染。对应到本体里，这条关系是：

药物A —[用于治疗]→ 肺部感染

当前患者患有肺部感染，所以适应症检查通过。

第二步：过敏史检查

系统查询药物A所属的药物类别：

药物A —[属于]→ 某类抗感染药

再查患者过敏史：

患者 —[过敏于]→ 某类抗菌药

系统继续查这两者之间的关系。本体内存储的医学事实显示：

某类抗感染药 —[与]→ 某类抗菌药 —[存在]→ 交叉过敏风险

于是系统知道：这个患者对同类药物存在过敏可能，风险等级上升。

第三步：个体条件检查

系统检查患者的肾功能状态：

患者 —[存在]→ 肾功能异常

药物A —[受影响因素]→ 肾功能状态

本体内还存储了一条规则：

肾功能异常 + 药物A → 需要评估剂量调整

同时系统查年龄：

患者.年龄 = 68

老年患者（≥65岁）+ 药物A → 需要关注不良反应

第四步：相互作用检查

系统检查患者长期用药记录，发现正在服用抗凝药：

患者 —[正在服用]→ 抗凝药

药物A —[与]→ 抗凝药 —[存在]→ 相互作用风险

第五步：综合输出

经过上述检查，系统合成的结论可能是：

适应症：通过

过敏：存在交叉过敏风险（等级：中）

肾功能：异常，需调整剂量

年龄：老年，需关注不良反应

相互作用：与抗凝药存在相互作用风险

综合结论：不建议系统直接授权使用，建议医生复核

同时附上完整的判断依据，每条依据都指向具体的医学证据来源…

这应该是本体论乃至知识图谱比较简单的理解方式了，大家可以再回顾回顾，真实场景的难度应该是这里的 10-100 倍吧…

这里需要特别提醒的是：不要用技术思维去思考问题，比如一来就想用什么图谱技术，图数据库当然重要，但它只是存储和查询的一部分。

本体可以落在 RDF 三元组数据库、属性图数据库、关系型数据库，也可以使用混合架构，甚至多维表格都可以搞定，所以先跑业务闭环，再考虑技术问题。

最后，我们探讨下成本问题。

本体建设成本

不得不说，现在大模型生成本体初稿并不困难，这也许是 Palantir 选择这个技术路径的核心原因。

大家可以理解现在无论本体还是图谱，成本只有 AI 之前的 1/10 甚至更低！

给模型几十份产品文档，它可以抽取实体，也可以做出关系，甚至直接生成 RDF、OWL 或者图数据库导入脚本，这些能力显著降低了早期生产成本。

比如下面这些事，在之前都是有专业壁垒需要真人成本的：

从文档抽取候选实体与关系；

发现别名和同义词；

生成本体初稿；

辅助旧数据映射；

把自然语言问题转换成 SQL 或图查询；

根据规则与事实解释结论；

寻找潜在冲突；

生成边界测试案例。

现在的话，AI 把上面的搞定了，专业人员就只需要思考下面的事情：

下单应该建成事件还是关系；

一个批次是否值得成为独立对象；

两个部门对有效客户的定义冲突时听谁的；

某条例外应该成为正式规则还是临时处理；

高风险动作可以自动执行到什么程度；

一次本体升级带来的业务损失由谁承担。

既然现在无论本体还是图谱成本都急剧下降了，那么每个公司应该如何开始呢？

我最近很喜欢跟一下老板聊天，因为项目名称一听客单价就很高：

1. 建设集团统一知识图谱；
2. 打造企业级数字孪生；
3. 构建 AI 时代的数据本体底座；

每次看着这些 PPT 标题，我内心就很兴奋，但真的做起来就不是那么回事了，他们实际上会选个 10万 级别预算的业务开始…

PS：白瞎了那套宏伟的 PPT 啊！

虽然我嘴里在吐槽，从成本角度出发，从小场景出发可能是最优路径。

但还是贵

我们前面说，AI 时代做本体/图谱的成本可能只有之前的 1/10 就觉得这东西很便宜，那可能你就想多了，这东西依旧很贵！

首先本体建设整个过程就很抽象，也没有唯一正确的标准，需要专业人员参与，需要反过来追问：业务里到底有什么，这些东西应该如何划分，又应该以什么关系存在。

企业本体的成本大概可以拆成五类：

没有唯一建模答案

我们之前就说了，本体和图谱是想用语言（自然语言、数据语言、代码语言）去描述、表征真实的世界，那么这东西就只有合不合适没有正不正确了。

什么意思呢？只要他错了，大家会感觉很清晰、但只要不是明确的错误，大家只会觉得不合适，比如下述问题：

1. 下单是事件、关系还是一个订单对象的创建动作？
2. 症状要不要拥有独立 ID？
3. 商品批次是属性还是对象？
4. 一次推理命中两个高置信度实体，是只选一个还是同时保留？

不同方案可能都说得通，差别在于是否适合查询、推理、维护和业务动作。

所以，本体项目中的很多争论，表面上在讨论技术方案，底层争夺的是企业业务定义权。

企业数据很脏

绝大多数企业的数据都是“脏”的。

比如，我们之前帮助某电商公司做 AI 原生转型的时候，他们都没有一个人能完整的说清楚完整的业务流程！，过程中会有很多坑。

比如：同一个东西，在不同部门嘴里叫法完全不一样。

比如“线索”，销售叫“商机”，运营叫“潜在客户”，财务叫“待回款对象”。

又比如“学员转化”，交付部门叫“入学”，销售部门叫“成单”，财务部门叫“确认收入”。

在这种情况下，你如果能把本体做出来，那就奇了…

构建本体意味着要把这些烂账全部映射到这张新地图上。这个清洗过程是很花钱的（偶尔会超过 50%），这是典型的脏活累活，是不性感甚至还可能出错返工的！

管理成本高

最后可能也是最烦的事情了，本体不是技术部门闭门造车就能造出来的。

它需要一个业务-技术混编团队，既懂具体业务细节，又懂抽象建模逻辑。这种复合型人才极其昂贵，且可遇不可求。

很多知识是依赖于专业人员，如医生、律师，这种非互联网工种根本无力整理自己的认知，于是需要互联网人组织他们，大家要相信，管理医生和律师去工作是很简单的，但要让他们做知识输出是很难的。

比如我之前的下属有北大和首都医科大学（安贞医院）的硕士，他们是很轴的…

但如果真的要实施本体论，其中的 KnowHow、数据与技术架构、模型特性几者的纠缠会很复杂，如果不是本身水平很高的人做一号位，要么把这个事情理不清楚，要么没有管理能力去调动各个专业口的人员；

但如果已经是高管的人，很难沉下心来一点点梳理 KnowHow 与数据，这是本体论难以落地的核心原因，所以大家可以理解到：现在想让 FDE 来做这些是很天真的，不是这个价格……

在这个基础下我们再来聊聊业务频繁变化的问题：

数据错了有多痛？

这里大家可以先做一个选择题：

你在做一次难度较高、规模较大的本体实施，你确定技术架构、基本数据结构后后，开始生产、清洗数据，并且已经有 50% 数据构造结束了，这个时候你突然发现技术路径有问题，跟数据结构不太匹配，这个时候的选择是什么：

1. 马上叫停，并重新构造
2. 汇报老板后，叫停构造，改造后重新构造
3. 装作不知道，然后等待暴雷
4. 想办法离职
5. 其他…

大家要注意了，上面的情况是在表达：本体模型已经进入批量数据生产，做到一半才发现，现有对象、关系和约束无法表达真实业务，或者无法支撑后续查询、推理与业务动作。

这个会导致项目所有人员无与伦比、绝望的心理压力，而这个还只是正常情况发生的“无心之失”，但如果是业务变化频繁，那么每次业务变化的时候，都可能导致上述雪崩似的灾难！

牵一发而动全身

普通程序是代码耦合，本体论是语义耦合。

假设你的本体定义了客户与订单是 1 对多关系。某天业务变了，允许一个订单包含多个客户（集团采购），你只是修改了这个关系定义。

那么，接下来可能会发生：所有依赖这个关系的 AI 推理逻辑失效，所有数据管道报错，所有前端页面显示异常，所有历史数据需要重算。改一个点，等于把整个地基重打一遍。

外部业务变化可能导致雪崩是第一个问题，那么发生问题不可怕，我们把问题改了是不是就好了？

这就涉及第二个问题了：

修改成本也很高

这里先说结论：关系定义本身的修改通常很便宜，真正贵的是这个关系已经被多少数据、规则、接口、页面和统计口径使用了…

所以，技术改动成本可以忽略不计、但数据再次清理/标注所产生的成本、数据迁移、BUG 测试兜底等所造成的成本及团队压力往往是巨大而难以估量的。

大家设想下：当本体从 V1.0 升级到 V2.0 时，系统里同时存在旧数据（按老规则存）和新数据（按新规则存）。

为了让AI能同时理解新旧两种语义，你需要写极其复杂的本体映射桥接代码。

很多时候，这个桥接代码的复杂度甚至超过了本体本身，最终导致系统逻辑彻底混乱。

而我看到的少数真实场景，团队都是打死不愿意去升级，意思是：本体模型从建立成功那一天开始，他可能就已经是一个巨大的维护成本、巨大的坑了，因为没人敢改、敢升级，所有的业务都要围绕这东西做将就、做让步…

用我好基友的话来说：我宁愿重新做一套，也不愿意去升级他…

至此，各位应该能够理解为什么我会说：在业务固化场景下才适合本体论/知识图谱这种技术范式了。

结语

篇幅已经很长了，我也写得很累了，现在开始收尾吧，最后再讨论下做本体项目的团队大概长什么样的。

本体不是技术部门关起门来能造出来的，也不能把业务专家拉进几个会就算业务共创。一套生产级本体通常需要几个角色：

• 业务一号位：确定目标，并对重大语义冲突做最终裁决；
• 领域专家：提供事实、规则、例外和历史经验；
• 本体或产品架构人员：设计对象边界和语义结构；
• 数据工程人员：负责清洗、映射、血缘和更新管道；
• 应用工程人员：把查询、推理和动作接入业务系统；
• 测试与评测人员：维护黄金测试集与回归流程；
• 本体管理员：负责上线后的日常治理。

岗位可以根据项目规模合并，他实际上体现出来可能是这个样子：