知识图谱装事实，本体定规矩：企业语义项目别再搞反顺序

某制造企业的数据平台上，一个标着「知识图谱」的模块上线了半年。技术团队把 ERP、MES、售后工单三套系统的数据抽出来，建成三元组灌进图库，演示时点开是一张密密麻麻的节点网络。但业务方问了一个很具体的问题——这台设备为什么在第三年故障率突然上升——系统却答不上来。它知道设备维修过四次，却不知道「维修」背后是部件更换，更不知道更换之后还有质保窗口。节点和边都在，规矩不在。

存了事实，丢了语义

这是语义项目最常见的死法：存了事实，丢了语义。而它多半源于一个容易被忽略的混淆——把知识图谱和本体论当成同一件东西的两个叫法。这两个词天天被并排提起，出现在同一份方案书的相邻两页，被同一批供应商打包出售，可它们解决的是不同层面的问题。混着用，轻则架构跑偏，重则团队对「建成什么样才算成功」根本没共识。

一个记事实，一个定规矩

一句话分清两者：知识图谱回答「正在发生什么」，本体回答「这是什么意思」。知识图谱以图结构组织数据，节点代表实体，边代表关系，只认实例层，价值能立刻被应用消费；本体则是对领域共享概念化的形式化规定，定义有哪些类型、允许什么关系、有什么约束，像一份语法书，规定了句子该怎么造，而不是替你写句子。

落地难在接缝与解耦

从多年产业实践经验来看，真正难的不是概念，而是把两者建起来并接得住。传统做法要求团队先设计本体，再通过复杂 ETL 管道把关系数据转成图、加载进专用图数据库，模式演进与实例摄入被死死绑在一起，每改一次模型就要重跑一遍管道，迭代慢、成本高、运维脆。近年出现的虚拟图方案提供了另一条路：在既有数据系统之上用轻量 JSON 声明式定义图模式，把顶点、边类型映射到底层表和键，源到图之间不再有 ETL。同一份数据写不同模式文件，就能得到多个图模型——做客户 360 是一种切法，做反欺诈是另一种切法，底下的表一张都不用动。语义建模与物理存储一分开，知识图谱就能增量地建、增量地改，模型可以随便改而数据不动，数据可以随时进而模型不重跑。

五条判断清单

给正在做选型的团队五条可执行的判断。第一，先问要回答的问题长什么样：问题本身是路径，图谱优先；问题本身是定义，本体优先。第二，把本体当活文档写，不必一上手就上 OWL 全套，先用节点标签和边标签把类型定下来，用得上的最小本体胜过躺在文档里的完整本体。第三，警惕模式与摄入的耦合，改一次模型要重跑一遍 ETL，就应考虑虚拟图路线——迭代速度是语义项目能不能活下来的第一变量。第四，别为了图而图，表格类负载继续走 SQL 引擎，关系密集的查询才交给图引擎，两者共享同一份源数据是最省成本的形态。第五，用真实查询验证性能，六跳、十跳这些数字要跑在自己的数据上，能力上限不是你的起点。

先定语义，再连数据，顺序反过来，图建得再漂亮也只是张关系网。没有一个团队会因为「图太大」而失败，却有很多团队因为「没人说得清这些边是什么意思」而放弃。把那份约定写下来，比换一套引擎更值钱。