工单堆里长出来的图谱：知识图谱构建的脏活与边界

凌晨两点，设备科老周给我打电话。语气很冲：“你们那个知识库，搜‘3号空压机跳机’啥也没有，PPT上不是挺能跳吗？”我打开后台，图谱演示页确实漂亮，设备节点、故障节点、备件节点，连线像地铁图。可现场搜不到……问题不在图漂不漂亮，在知识图谱构建时我们漏了脏活：实体没对齐，schema拍脑袋，更新没人管。

说白了，图谱不是把关系画出来就完事。它更像维修师傅脑子里的联想：听到“3号空压机高温跳停”，能想到上次换过油滤、复位过温控、备件库里还剩两个滤芯。你要让机器也能顺着这条线找，才叫构建。

先别画漂亮的本体，先问谁会来搜

很多团队一上来就搭大本体。设备、部件、故障、工单、人员、备件、供应商，全要。画了三十页，评审时人人点头，上线后没人用。为什么？本体是给人查问题用的，不是给汇报看的。

我后来学乖了，先蹲在工单系统旁边看三天。看维修工怎么搜，看调度怎么问，看备件员怎么翻记录。结论很土：高频问题就几类——“这台设备出过什么毛病”“这个毛病上次怎么处理的”“处理时用了什么件”“谁修的”。够了。先建四类实体：设备、故障现象、处置动作、备件。关系也别贪：设备发生故障、故障对应处置、处置使用备件、工单记录处置。就这些，能跑起来再长。

有人问，知识图谱构建不就是抽实体、抽关系吗？对，但抽之前得知道边界。比如“温度高报警”和“高温跳机”算不算一个故障现象？在工单里它俩经常混着写，可处置逻辑不一样。报警可能要清滤网，跳机可能得复位甚至换温控。你要是硬合成一个节点，后面推荐处置就会串。这个判断没人能替你拍，得拉着老师傅吵半小时。

我见过一个反例。某厂把“设备”和“部件”合成一个大类，结果查“空压机”能出来“油滤”，查“油滤”又回到“空压机”，图谱看着热闹，根因分析时层级全乱。别笑，这种错在评审会上很难看出来，一上查询就露馅。

抽取不是“上模型”就完事，脏活都在对齐

工单文本有多脏？这么说吧，“#3空压机”“3号空压机”“空压机A”“三号机”可能指同一台。还有错别字，“跳机”写成“跳鸡”，别笑，真有。你拿一个命名实体识别模型直接跑，能抽出“空压机”，但抽不出它到底是哪台。这就麻烦了，图谱里冒出三个设备节点，历史工单各挂各的，查询自然碎。

我的做法很土：规则先兜底，模型补长尾，人工做复核。设备台账里有的编号、别名，先做词典匹配；工单里的“3号”“#3”“A机”用正则和上下文规则拉齐；模型负责那些没见过的写法。对齐完还要归一化，把温度、压力、振动这些量纲统一，不然“85度”和“85℃”都能成两个值。对吧，听着琐碎，可这就是知识图谱构建里躲不开的脏活。

关系抽取也别迷信大模型。大模型能帮你从长句里找“更换油滤后复位”这种处置链，但它会编。工单里明明写“未更换”，它可能给你抽成“更换”。所以得加约束：抽取结果要能回指原文，每个关系边上留句子编号和片段，方便质检。我们抽检时随机拉一百条，人工看二十条，错得多的模板回流改规则。别嫌慢，图谱错一条，查询就敢错一片。

还有一个容易忽略的点：实体对齐不是一次性工作。新设备进厂、新别名出现、老师傅换个叫法，图谱就旧了。我们后来加了个“别名候选”队列，工单里出现未知设备写法先挂起，一周清一次。清的时候别让算法自己拍板，让人点一下。就这一下，省掉后面很多扯皮。

图谱上线后，真正难的是它开始变旧

上线那天大家都很嗨，大屏一转，节点发光。三个月后没人维护，图谱就成了电子标本。知识图谱构建这件事，构建只是前半截，运营才是长尾。设备改造了，关系要改；处置方案更新了，边要改；备件替代了，映射要改。没有版本和责任人，图谱很快会变成“看起来有，查起来错”。

风险也说透。脏数据进图谱，会被关系放大。一个设备别名没对齐，可能让十张工单挂错节点；一个故障现象合并错，可能让推荐处置串到另一条线。大模型抽取还有幻觉，你不留原文回指，出了问题连追都追不回来。还有权限，工单里有班组、有人员，图谱查询别一把梭，该脱敏脱敏。

那它适合干啥？高频、关系相对稳定的场景。设备维保、备件替代、故障处置推荐、客服工单归因，这些都能用。你要拿它硬编码复杂因果，比如“某种操作一定导致某类失效”，那得谨慎。图谱擅长把已知关系串起来，不擅长替你做因果证明。长尾问题还是得靠检索加人工，别指望一张网兜住所有事。

回到老周那通电话。我们后来没加什么炫酷功能，只做了三件事：设备别名对齐、故障现象分层、处置关系回指原文。再搜“3号空压机跳机”，能落到故障现象节点，下面挂着历史工单、处置动作、用过的备件。老周没说好，只说了句“这还差不多”。行，知识图谱构建的价值，有时候就是少打一个电话。