在我今年拜访、陪跑的企业里面，关于知识库的需求明显变多、变深了，我预估未来两年都会是知识库应用的大年；
在这个趋势下，有两个专业名词出现频率明显变高了：知识图谱与本体论，而且他们还真不是说说而已的故意碰瓷，我看他们的场景，不用这种深度技术可能还真的搞不定！！！
只不过，知识图谱是什么大家应该会比较清晰，但这个本体论是什么就有点抽象了。所以逻辑上来说，正经的公司不大可能去尝试什么本体论，毕竟那是并不“通用”、或者“成熟”的技术路径。
那为什么这个名词频率变得如此高呢？原因是 Palantir 这个公司，它是这一轮本体论在企业 AI 场景中重新走红的重要推动者。
Palantir CEO Alex Karp在公开场合反复强调本体论是成功的关键，这让整个行业开始关注和跟风。
那又凭什么，Palantir 说撒就是撒呢？这就不得不说这家神奇的公司了：
关于 Palantir 最直观的反差是：很多人会戏称 Palantir 是一家外包公司，但这家所谓“外包”公司的估值竟一度高达 3700 亿美金。
于是这里最大的不合理出现了：
正经的 SaaS 公司 PS 不过 4-7 倍，而 Palantir 把 PS 干到了 60-70倍，也就是他是同类公司的接近 10倍！！！
于是业内开始了对 Palantir 疯狂的模仿，包括商业模式、组织模式、实施方法论等等：
所以，Palantir 这里搞火的不止是本体论还有 FDE、AI 操作系统等，而如果哪天 Palantir 不行了，也有可能 FDE、本体论都会变成伪科学。
比如，有个人在某公司分享本体论，如果他没说他是 palantir 的，就容易被各种质疑；而就算是也不用担心，咱们也可以不认，因为 Palantir 的本体不适合中国环境，我们要搞有中国特色的本体方法论！
三位一体的管控本体，五位一体的治理本体，八横八纵的战略本体，十大流程的场景本体！
好了，扯犊子结束，接下来正儿八经来说说他们的技术路径关键词：本体论（Ontology）！
本体论
关于什么是本体论，其实可以回归我们之前对知识框架的拆解方法论：先穷举、再分类、再总结提参。
本体论是一套解释性框架、构建世界的规则说明书，他需要用数据去表征真实的世界：
这是什么意思呢？想象下你穿越到了修仙世界，你问宗门大佬：这里到底有什么东西？问题就会很有意思了：
你得先列出种类，这里不仅有修士，还有功法以及灵气；
然后你就得列出这些种类之间的关系了，修士修炼要有灵气，修士能使用功法，但会消耗体内存储的灵气。
这个存在哪些东西 + 它们之间怎么关联的清单，就是本体论。简单说，本体论就是万物清单的底层说明书。
在这个基础下，我们再映射到技术语言，在 AI 或者知识图谱里，本体论就会变得很具体了：
它是一套形式化的规范，用类（Class）、属性（Property）、关系（Relation）来描述一个特定领域
举个例子：做一个购物平台本体。
你要定义商品是类，价格是属性，买家和商品之间是购买关系。机器根据这套本体，才能推理出如果 A 买了 B，且 B 属于电子产品，那么 A 喜欢电子这种东西。
这里的本体论，就是给机器看的概念字典和语法书。
以上就是我们对本体论最简单的解释了，在这个基础上就可以聊聊其适用场景了：
这里先说结论，再解释为什么，最后举一些行业案例，结论是：
一定是相对固化的场景才适合本体论这套技术路径
为什么呢？因为本体论这套东西实施的成本及难度都是很高的，如果构建出来的本体变化频率很高，甚至业务变化频率很高，那基本上就是完犊子了！
PS：这块只有做过知识图谱，并且失败过的人会有更深的体会...
成本在哪
现在 AI 编程直出代码的质量已经很高了，但他不值钱并不是现在开始的，早在 AI 出来前编程人员就过剩了，也就是说以程序员写代码类比构建本体的过程，那难度不可同日而语：
写代码是用 if/else 这种语言描述真实的业务流程，而本体论是在抽象世界
现阶段大模型也可以生成本体论，而且按道理说他们也擅长这个事情，比如 GraphRAG、Palantir AI FDE 等：
又比如，最近比较火的 LLM Wiki（Obsidian 知识库系列） 底层就会有轻量级本体论的影子。
只不过这些东西效果都不好，并且我预测长期来说效果都不会太好，因为市面上没有相关或者完全通用的数据可以拿去被训练。
比如当前图谱化最成熟的医疗场景，想要直接输入符合公司业务需求的实体关系，都会各种磕磕绊绊，综上：
当前，在实体梳理或者图谱形成这个事情上，需要很多“真功夫”，偷不得懒
具体来说什么地方会导致难度、成本较高呢？这里跟我们之前做生产级 AI 项目时候的数据工程难点是类似的：
真实世界难以完全表征
第一，高难度的业务抽象。你需要把现实世界中杂乱无章的业务。
比如管理咨询、客户下单、物流派送提炼成有限的类（Class）与明确的关系（Relation）；
大家可能不太理解为什么这个东西会很难，原因是用语言表征真实世界过程中没有正确与否只有合不合适，这里会涉及很多话语权之争，尤其是产研与业务方，比如：
下单是一个事件属性还是一个独立实体； 医疗场景在最终产出解决方案前到底要追溯几层，高糖 → 糖尿病 → 糖尿病足； 属性（比如症状）到底要不要拥有独立的 ID，还是直接使用自然语言即可； 如果这次推导出两个实体（命中率都超过 90%），是处理一个还是两个； ......
这种争论在团队内部可能持续数周甚至数月（最夸张的是输家一年后还会重复诉说自己的合理性）。这里会导致的问题是：
如果业务专家和技术专家的认知不统一，项目连起点都推不动，总之都是扯皮
数据清洗/标注成本
大家要理解：绝大多数企业的数据都是“脏”的。
比如，我们之前帮助某电商公司做 AI 原生转型的时候，他们都没有一个人能完整的说清楚完整的业务流程！，过程中会有很多坑。
比如：同一个东西，在不同部门嘴里叫法完全不一样。
比如“线索”，销售叫“商机”，运营叫“潜在客户”，财务叫“待回款对象”。
又比如“学员转化”，交付部门叫“入学”，销售部门叫“成单”，财务部门叫“确认收入”。
在这种情况下，你如果能把本体做出来，那就奇了...
构建本体意味着要把这些烂账全部映射到这张新地图上。这个清洗过程是很花钱的（偶尔会超过 50%），这是典型的脏活累活，是不性感甚至还可能出错返工的！
管理成本高
最后可能也是最烦的事情了，本体不是技术部门闭门造车就能造出来的。
它需要一个业务-技术混编团队，既懂具体业务细节，又懂抽象建模逻辑。这种复合型人才极其昂贵，且可遇不可求。
很多知识是依赖于专业人员，如医生、律师，这种非互联网工种根本无力整理自己的认知，于是需要互联网人组织他们，大家要相信，管理医生和律师去工作是很简单的，但要让他们做知识输出是很难的。
比如我之前的下属有北大和首都医科大学（安贞医院）的硕士，他们是很轴的...
但如果真的要实施本体论，其中的 KnowHow、数据与技术架构、模型特性几者的纠缠会很复杂，如果不是本身水平很高的人做一号位，要么把这个事情理不清楚，要么没有管理能力去调动各个专业口的人员；
但如果已经是高管的人，很难沉下心来一点点梳理 KnowHow 与数据，这是本体论难以落地的核心原因，所以大家可以理解到：现在想让 FDE 来做这些是很天真的，不是这个价格......
在这个基础下我们再来聊聊业务频繁变化的问题：
数据错了有多痛？
这里大家可以先做一个选择题：
你在做一次难度较高、规模较大的本体实施，你确定技术架构、基本数据结构后后，开始生产、清洗数据，并且已经有 50% 数据构造结束了，这个时候你突然发现技术路径有问题，跟数据结构不太匹配，这个时候的选择是什么：
马上叫停，并重新构造 汇报老板后，叫停构造，改造后重新构造 装作不知道，然后等待暴雷 想办法离职 其他...
大家要注意了，上面的情况是在表达：本体模型已经进入批量数据生产，做到一半才发现，现有对象、关系和约束无法表达真实业务，或者无法支撑后续查询、推理与业务动作。
这个会导致项目所有人员无与伦比、绝望的心理压力，而这个还只是正常情况发生的“无心之失”，但如果是业务变化频繁，那么每次业务变化的时候，都可能导致上述雪崩似的灾难！
牵一发而动全身
普通程序是代码耦合，本体论是语义耦合。
假设你的本体定义了客户与订单是 1 对多关系。某天业务变了，允许一个订单包含多个客户（集团采购），你只是修改了这个关系定义。
那么，接下来可能会发生：所有依赖这个关系的 AI 推理逻辑失效，所有数据管道报错，所有前端页面显示异常，所有历史数据需要重算。改一个点，等于把整个地基重打一遍。
外部业务变化可能导致雪崩是第一个问题，那么发生问题不可怕，我们把问题改了是不是就好了？
这就涉及第二个问题了：
修改成本也很高
这里先说结论：关系定义本身的修改通常很便宜，真正贵的是这个关系已经被多少数据、规则、接口、页面和统计口径使用了...
所以，技术改动成本可以忽略不计、但数据再次清理/标注所产生的成本、数据迁移、BUG 测试兜底等所造成的成本及团队压力往往是巨大而难以估量的。
大家设想下：当本体从 V1.0 升级到 V2.0 时，系统里同时存在旧数据（按老规则存）和新数据（按新规则存）。
为了让AI能同时理解新旧两种语义，你需要写极其复杂的本体映射桥接代码。
很多时候，这个桥接代码的复杂度甚至超过了本体本身，最终导致系统逻辑彻底混乱。
而我看到的少数真实场景，团队都是打死不愿意去升级，意思是：本体模型从建立成功那一天开始，他可能就已经是一个巨大的维护成本、巨大的坑了，因为没人敢改、敢升级，所有的业务都要围绕这东西做将就、做让步...
用我好基友的话来说：我宁愿重新做一套，也不愿意去升级他...
至此，各位应该能够理解为什么我会说：在业务固化场景下才适合本体论/知识图谱这种技术范式了。
什么时候需要本体
这里先给结论，适合本体论/知识图谱的领域，通常满足一个核心特征：业务本质稳定，但对结果要求极高、需要深度关联推理的。比如此图最后一列：
医疗场景是本体论最经典的场景，它适合本体，是因为医学概念之间存在大量稳定而复杂的语义关系，错误理解的代价也很高。
比如同样是肺炎，会有很多额外关系会被带出来：
病变部位； 致病原因； 严重程度； 临床表现； 并发症； 治疗方式； ...
在不同业务场景下，对应的知识是一个都不能少啊！
除此之外，近来由 Palantir 带火的各种企业运营本体案例也有不少。
把工厂、设备、物料、订单、供应商、物流、客户和交易等数据映射为业务对象，再在对象之上定义规则、权限和动作。
例如发生供应商断供时，系统可以穿透：
供应商
→ 原材料
→ 生产计划
→ 工厂
→ 客户订单
→ 收入影响
→ 调整动作
这里的本体已经不只是知识表示，还承担运营决策和业务动作的统一接口。
小场景
这里开始是我们的实践场景了，前面聊的本体模型/知识图谱动不动就是一个行业，其实这种压力是很大的。
在我们实际实施过程中会发现：其实本体不一定要覆盖整个行业、整个公司，也可以只服务一个边界清晰的业务闭环。
PS：大家要注意，这种是小而美的策略，肯定是有其场景所在的局限性的
因为这东西就是个孤岛，他做不大，要变大就变小而碎了...
上面说了很多了，我们最后给个阉割小案例：
案例：电商小场景
某电商商家主要销售清洁设备，包括滚刷、拖布、尘袋和清洁液等。客服每天都会收到大量类似问题：
我家是X200青春版，这款滤芯能用吗？
这里看起来只需要查一下型号，貌似是简单 AI 客服场景，搞个 RAG 就了事了，但能找到我这里来的都一定不简单，比如：
同一台设备在不同渠道可能使用不同名称；同一个系列又分为标准版、青春版、Pro 版和海外版。有些配件整个系列通用，有些只适配特定代际，还有些配件外形相似，但卡扣、尺寸或者通信协议不同。
PS：总之很复杂，上面的问题我都记不住，从之前的文档拷出来的
普通 RAG 可以找到包含“X200”或者“滤芯”的资料，但“X200青春版可以使用滤芯F”这句话未必存在于任何文档中。适配结论需要根据设备所属系列、产品代际、安装位置和接口规格推导出来。
因此，我围绕设备与配件适配建立了一个小型本体：
第一步：定义核心对象
这个本体只包含几类对象：
设备品牌；
设备系列；
设备型号；
渠道型号；
产品代际；
配件；
配件类型；
安装位置；
物理接口；
通信协议。
然后定义类型层级：
清洁设备配件
→ 过滤配件
→ 滤芯
清洁设备配件
→ 清扫配件
→ 主滚刷
滤芯和主滚刷都属于配件，但承担的功能和安装位置不同，不能因为外形或者尺寸接近就判断为适配。
第二步：定义关系和约束
系统需要描述这些关系：
设备型号 → 属于某个设备系列
设备型号 → 属于某个产品代际
渠道型号 → 对应某个标准型号
设备型号 → 使用某种安装接口
配件 → 属于某种配件类型
配件 → 适用于某个安装位置
配件 → 支持某种安装接口
在此基础上建立适配规则：
配件类型必须符合安装位置要求
配件接口必须与设备接口兼容
配件支持的产品代际必须覆盖设备代际
通信类配件还必须满足协议要求
明确排除的型号不得继承系列通用关系
第三步：根据本体进行推理
接下来，开始重新走流程，某位消费者询问：
我家是X200青春版，这款滤芯F能不能用？
商品资料中没有直接写明两者是否适配，但本体中存在以下事实：
X200青春版是渠道名称
X200青春版对应标准型号X200 Lite
X200 Lite属于X200第二代系列
X200 Lite的滤芯接口为K2
滤芯F适用于X200第二代系列
滤芯F支持K2接口
因此，系统可以推导出：
滤芯F适配X200青春版。
另外一款滤芯G也标注支持X200系列，但本体中记录了一个例外：
滤芯G不支持X200 Lite使用的K2接口
所以系统会排除滤芯G。
这里没有维护“滤芯F适配X200青春版”这条具体关系。系统根据系列归属、型号映射、产品代际和接口兼容关系推导出了新的结论。
如果只使用商品与型号的对应表，每增加一个渠道型号，就需要重新维护它与大量配件的适配关系。本体建立以后，只需要确认渠道型号对应哪个标准型号，以及配件支持什么系列和接口，具体适配关系就可以自动计算。
......
一些难点
上述案例是我将完整案例给 AI 脱敏 + 大幅度阉割的版本，大家体会下就好，在这次实践里面最难的是：继承与例外。
某款配件可能适用于整个X200系列，但不适用于其中的Pro版；某个型号名称没有变化，厂家却在后续批次中更换了接口；不同供应商还可能对“通用”和“兼容”使用不同标准。
系统也需要区分两种情况：
已经确认不适配； 当前资料不足，暂时无法判断。
如果把资料不足直接理解为不适配，会错过可以销售的商品；如果默认适配，又可能带来退货和投诉。因此，系统需要输出“适配”、“不适配”、“有条件适配”和“信息不足”四种结果。
PS：大家可能不太能理解这里说的是什么，我这里举个例子，实体关系里面可能出现父子关系，一般子是具备父的特性的，但也有不具备的情况，这个时候收敛起来就会很麻烦
后续的发展
大家看到的这个阉割场景实施成本并不高，但真实场景复杂度不可同日而语，总之上线后是取得了一致好评的，并且持续时间还挺长的，直到那一天的到来...
甲方团队并没有人能维护该系统，久而久之就一定会出问题
后续，随着商品增加，型号别名、系列层级和例外规则会越来越多。本体如果缺少统一负责人，很容易出现两个运营人员给同一型号设置不同归属的情况。
厂家在不修改商品名称的情况下更换配件接口，也可能导致旧规则失效。因此，本体必须记录产品批次、规则版本和适配依据。
如果滤芯、清洁液、维修件分别建设独立本体，又没有统一设备型号和接口标准，后续仍然会形成语义孤岛。
所以，这类小本体可以快速产生价值，但必须控制范围，统一核心型号，并持续维护例外和版本
结语
篇幅已经不小了，这边收一收。
我们从 Palantir 的高估值和行业模仿开始，解释了本体论到底是什么；又花了很长篇幅讨论它为什么难、难在哪里、适合什么场景。
最后，为了便于大家轻松了解这东西，我们又把视角缩小到了一个电商配件适配场景。
PS：我再次强调，真实场景会复杂很多
这个案例只围绕设备、型号、配件、接口和适配规则，解决了一个普通 RAG 很难稳定回答的问题。
这个小案例最后依旧遇到了本体项目绕不开的问题：随着商品、批次和例外规则越来越多，如果没有明确的负责人持续维护，今天建立起来的知识结构，迟早会在业务变化中逐渐失真。
所以，回到文章最开始，思考个更深层的问题。
为什么我今年拜访、陪跑的企业里面，知识库需求明显变多、变深了？为什么知识图谱和本体论出现的频率越来越高？
因为很多企业已经发现，过去那种上传一批文档，让 AI 搜索并回答的知识库，只能解决相对简单的问题。
当业务继续深入，AI 需要理解的不再只是某段文档写了什么，它还需要知道企业里面存在哪些业务对象，这些对象之间是什么关系，哪些规则可以继承，哪些情况属于例外，信息不足时应该继续追问什么，以及完成判断以后能够执行什么动作。
企业知识库的建设目标，已经开始由让 AI 找到知识，逐渐延伸到让 AI 理解业务。
AI 要完整的模拟人思考的整个过程，这个会很难
这也正是本体论重新受到关注的根本原因
但这里也要说清楚：传统 RAG 不够用，并不代表所有企业都应该直接建设本体。
能够用文档检索、SQL、API和规则引擎解决的问题，继续使用简单方案通常更加划算。只有当对象关系足够复杂、判断结果要求足够高，并且同一套知识需要被多个业务流程长期复用时，本体的投入才可能产生对应的价值。
未来两年，我认为会是企业知识库应用的大年。
只是随着大家逐渐进入深水区，决定项目成败的因素会越来越少地停留在模型和工具上，更多落到企业能否整理自己的 KnowHow，能否统一不同部门的业务认知，能否控制知识结构的复杂度，以及有没有人愿意长期对这套知识负责。
本体论最终逼问企业的是：你是否真的理解自己的业务，并愿意持续维护这份理解。
毕竟，想让 AI 理解一家企业，企业首先得把自己说清楚。
最后，如果你想看看企业级本体模型长什么样子的，也许可以看看下面的商品
然后对 AI 深度学习感兴趣的可以点击：
