做过几年数据侧的项目我最怕听到的一句话就是帮我把这些文档做成知识图谱。这句话听起来像个需求实际上是个坑文档有多少、长什么样、要回答什么问题、谁来判断对错四个关键信息一个都没有。等真把流水线搭起来你会发现全自动跑出来的图谱实体重复、关系错乱、置信度没法看而纯人工标注一天标不了几百条成本压不住。半自动化知识图谱构建这件事本质上不是技术选型问题而是人机分工比例的设计问题。SAKA 这个平台要解决的就是把这条从原始文档到可用图谱的链路拆开把机器擅长的部分批量做掉把机器做不准的部分收拢到人面前让人只花最少的判断成本。这篇内容适合正在被图谱需求折磨的数据工程师、算法同学以及需要评估这条路值不值得走的业务方看。下面我按实际搭建顺序讲先讲为什么必须半自动再讲架构、本体设计、抽取流水线、完整实操、应用落地和排查经验。1. 先想清楚为什么全自动这条路走不通1.1 全自动流水线的三个塌陷点很多团队第一版都想着全自动接文档、跑模型、写库、上线查询。跑通 demo 很容易跑通生产很难塌陷通常发生在三个地方。第一个塌陷点是本体漂移。模型不会告诉你这个实体到底该归到产品还是型号它只按训练分布输出标签。文档来源一换、领域一换标签体系就开始漂。你今天定义 12 类实体三个月后库里长出 30 类近义标签查询侧根本没法用。第二个塌陷点是错误会累积。实体识别错了关系抽取必然错关系错了实体对齐会把两个不相干的节点合并合并完之后图上的多跳查询会给你一个看似合理、实则荒谬的答案而且没人能追溯是哪一步错的。全自动链路没有刹车错误会一路传导到最终结论。第三个塌陷点是评估没有锚点。你说准确率 85%那 15% 错在哪、错的是哪类关系、错误集中在哪个数据源全自动流水线给不出这个粒度。没有错误分布就没有优化方向只能靠换个更大的模型试试这种玄学。这三点的共同根源是全自动流水线把判断藏起来了。它做了决定但没告诉你为什么做这个决定也没给你改这个决定的入口。半自动的核心价值不是人比机器聪明而是让判断可见、可修正、可回流。1.2 半自动的分界线该划在哪里分界线不是按难易划而是按判断成本 × 错误代价划。我一般用一张四象限来看场景特征处理方式典型环节错误代价低、判断成本低全自动放行高频实体识别、时间地点抽取错误代价低、判断成本高抽样审核 自动放行长尾关系抽取、属性补全错误代价高、判断成本低强制人工确认实体合并、敏感实体挂接错误代价高、判断成本高挂起队列攒够批量处理跨文档冲突消解、本体扩展这张表的实际用法是先给每类抽取任务打上代价和成本标签再决定它进不进人工队列。我见过反面案例一个团队把所有关系都塞进人工审核审核台一天堆两万条标注入员直接放弃最后整条链路退化成跑完就算。SAKA 这类平台的设计思路本质上是把这张四象限表做成了可配置的路由策略每条抽取结果带一个置信度分数路由器按分数和关系类型的权重决定它去自动入库、去抽样池、去仲裁队列还是直接丢弃。这个路由器的阈值不是拍脑袋定的后面 4.5 节我会给一个具体的算分和分档方法。1.3 平台该覆盖到哪一步就收手这一点很关键很多平台做死在这里。知识图谱平台最容易膨胀什么都想管数据接入要管、标注要管、训练要管、服务要管、可视化要管最后变成一个谁都用不动的庞然大物。我的判断标准是平台只负责从原始数据到可查询图谱这一段以及从线上反馈回到抽取策略这一条回路。中间的模型训练可以对接外部训练平台下游的 BI、推荐、问答各自独立。平台的价值在于把中间的脏活标准化统一的本体注册、统一的抽取接口、统一的置信度规范、统一的人工审核入口、统一的版本与溯源。只要这五个统一立住了上面换什么模型、下面接什么业务都不影响主干。反过来如果一开始就想着做全家桶大概率连第一个可用图谱都交付不出来。2. 整体架构四层加一条反馈回路2.1 分层拆解与数据流向SAKA 的整体结构我拆成四层外加一条贯穿的反馈回路。这个分层不是画着好看的每一层的边界都对应一个明确的责任归属出问题时能快速定位该找谁。接入层负责把各种来源的数据拉进来并标准化。文档、表格、日志、接口返回统一转成带元数据的文本块。这一层最容易被低估实际上 70% 的抽取质量问题源自接入层没做干净——编码错乱、页眉页脚混入、表格被压成一行、同一份文档重复导入。抽取层实体识别、关系抽取、属性抽取、事件抽取四个任务共用一套文本预处理和一套结果结构。这一层的原则是多路并行、结果并列不要做成串行管道——串行一旦上一步漏了下一步全废并行的话字典路和模型路可以互相补后处理阶段再合并。融合层实体对齐、冲突消解、去重、置信度汇总。这一层是把碎片拼成图的关键也是最需要人工介入的地方。应用层图查询、子图召回、路径检索、图特征导出以及给检索增强类应用提供结构化上下文。反馈回路人工审核的修正、线上查询的失败样本、业务侧的反馈统一回流成待优化清单用来更新字典、调整阈值、补充训练样本。2.2 为什么把人在回路做成一等公民大多数图谱项目的人工环节是后补的先做流水线发现效果不行再临时拉个 Excel 让人标。这种做法的后果是标注结果没法结构化回流标完就烂在表格里。SAKA 的做法是把人工审核做成抽取流水线的一个正式环节和模型、规则平级。每条抽取结果进库前都会带上三个字段source来自哪条规则或哪个模型、confidence分数、status自动通过 / 待审 / 已确认 / 已驳回。审核台的每一条修改都会被记录成一条修正事件包含原值、新值、操作人角色、时间。这样做的好处是审核数据天然就是训练数据。三个月后你想微调模型直接从修正事件表里导出正负样本不需要重新组织标注。我在一个项目里算过账审核台积累的修正事件大约每 1000 条能带来一次小模型迭代迭代后同类关系的自动通过率能涨 6 到 9 个百分点这个正循环一旦转起来人工成本是逐月下降的。注意事项审核台千万别做成一条一条过的表单流。人会疲劳疲劳就会乱点。正确做法是把相似的抽取结果聚成一批让人一次判断一类判断结果批量应用。批量操作带来的效率差异我实测过同一批 500 条数据逐条过要 40 分钟以上批量聚类后过 12 分钟左右。2.3 选型上的几个取舍存储选型上我倾向属性图 关系型元数据 向量索引三件套而不是硬塞进一个库。属性图模型适合表达节点-边-属性多跳查询天然顺手但图的聚合统计、批量导出、事务性更新反而不如关系型。所以我的做法是图的拓扑和主要属性放图库抽取结果的版本、溯源、审核状态放关系型实体和关系的文本向量放向量索引。三者的主键用同一套 ID 规范对齐。抽取选型上走字典 小模型 大模型兜底的混合路线。原因很实在字典在高频实体上又快又准成本几乎为零小模型在封闭领域上泛化够用、延迟可控大模型适合处理长尾、复杂句式和零样本新类型但成本和稳定性都不适合全量跑。全量用大模型跑一遍的成本通常是小模型的十几倍到几十倍而且延迟撑不住增量场景。ID 规范这件事我要单独说一句因为它是最容易埋雷的地方。我的建议是实体 ID 用类型前缀 规范化名称的哈希比如PROD_9f2a...而不是用自增主键。原因是跨源数据里同一个实体可能先出现后补全自增 ID 会导致合并时主键变化下游全部要改。用规范化名称哈希同一实体的 ID 天生稳定合并只是补属性不动主键。3. 模式层设计决定成败的前置功夫3.1 从业务问题倒推实体和关系本体设计最常见的错误是照抄行业标准本体。那些本体是为通用场景设计的实体类型动辄上百个你的数据根本填不满最后变成一堆空类型加零星实例。正确顺序是反过来先列问题再列答案需要哪些字段最后才定实体和关系。举个具体例子假设业务方要回答某型号产品在哪些项目中出过故障故障件是什么。拆解一下答案需要产品型号、项目、故障事件、故障部件四个对象以及参与发生涉及三条关系。这就够了不需要供应商生产线工艺参数这些当前问题用不上的类型。我一般会做一个问题-实体-关系三列对照表把业务方提出的 20 到 30 个真实问题全部过一遍统计每个实体类型和关系类型被引用的次数。引用次数为 0 的直接砍掉引用次数为 1 的先标记为预留只建类型不建抽取任务。这个表格有两个好处一是防止本体膨胀二是让业务方看到你要的能力和我建的东西是对齐的后面验收少扯皮。3.2 本体最小可用原则与版本演进本体一定要能改而且要能追溯地改。我的做法是给本体加版本号每次变更生成一个新版本抽取结果上记录它按哪个版本抽取的。这样当本体调整后可以精准地找出需要重跑的那批数据而不是全量重来。本体的演进通常走三步第一版只建 5 到 8 个实体类型、5 到 10 个关系类型足够支撑第一批问题跑一两个月后从未识别文本和人工新增实体里找高频模式扩展第二版第三版开始做细化比如把部件拆成标准件和非标件。跳过第一步直接做第三版基本等于自找麻烦因为你对数据的分布还没有感觉。一个实操细节本体变更一定要留兼容窗口。新版本上线后旧版本抽取的结果不要立刻删保留一个过渡期查询侧做双读。否则某天业务方查一个历史数据查不到会以为你把数据弄丢了。3.3 一份可直接抄的 schema 模板下面这份模板是我在多个项目里反复改出来的结构上分成实体定义、关系定义、约束三块。字段不多但每个都有用。ontology_version: 1.2.0 entity_types: - name: Equipment display: 设备 id_prefix: EQP key_fields: [name, model] # 用于对齐的字段 attributes: name: {type: string, required: true} model: {type: string, required: false} vendor: {type: string, required: false} alias_source: [dict_equipment, manual] # 别名词典来源 - name: Component display: 部件 id_prefix: CMP key_fields: [name] attributes: name: {type: string, required: true} spec: {type: string, required: false} relation_types: - name: has_component display: 包含部件 head: Equipment tail: Component cardinality: many_to_many confidence_floor: 0.75 # 低于此分不进主图只进候选池 - name: fault_of display: 故障发生于 head: FaultEvent tail: Equipment cardinality: many_to_one confidence_floor: 0.85 constraints: - rule: unique_key target: Equipment.name Equipment.model - rule: no_self_loop target: all_relationskey_fields这个字段值得单独说。它直接决定实体对齐用什么字段做 blocking分桶写错了会导致大量漏合并或者误合并。经验是优先选稳定且区分度高的字段组合名称 型号通常比名称 厂商好因为型号的区分度更高。如果只有名称那对齐阈值要相应调高宁可少合并。4. 抽取流水线规则、模型、人工怎么配合4.1 数据接入与预处理别在这一层省事预处理这块我吃过最大的亏是一批 PDF 转出来的文本里混着页眉页脚和页码结果第 3 页这类字符串被模型识别成了某种编号实体硬生生在图里造出几千个垃圾节点。预处理要做的事按优先级排编码统一全部转 UTF-8→ 去噪页眉页脚、目录、重复段落→ 分块按语义段落切不按固定字数硬切→ 元数据挂载来源、时间、作者、密级→ 语言识别。分块这一步特别影响抽取质量。硬按 512 字切很容易把一个句子、一个关系三元组切成两半抽取模型拿到半句话只能瞎猜。我的做法是按标题层级和换行先切成语义块再把过短的块少于 80 字向前合并超长的块超过 800 字按句号、分号二次切分。这样切出来的块平均 300 到 500 字关系抽取的召回能提升不少。元数据挂载也别省。每条抽取结果都要能回答你是从哪份文档的哪一段抽出来的这是后续溯源和置信度计算的依据。我在结果表里固定存doc_id、chunk_id、char_start、char_end四个字段出问题时可以直接定位到原文位置。4.2 实体识别字典、模型、后处理的组合拳实体识别我用三路并行字典路用多模式串匹配把已知实体名、别名、缩写一次性扫出来。优点是零误差只漏不错缺点是要维护词典。词典怎么来从历史数据里用频次 规则自动挖掘初版再靠审核台的新增实体操作逐步补充。这条路能把高频实体的召回拉到很高而且是确定性的不用担心模型漂移。模型路用序列标注输出 BIO 标签。输入是分块后的文本输出是实体片段 类型 概率。小模型在这个任务上已经够用关键是训练数据的质量不是模型大小。我一般会用字典路的结果作为弱标注去训练模型再让模型去发现字典没有的实体形成一个互补。大模型路只对前两路都低置信的片段做兜底或者用于处理新出现的实体类型。做法是把候选片段和上下文给大模型要求输出结构化的 JSON然后用 schema 校验器强校验——字段缺失、类型不匹配、值不在枚举内的一律打回。这一层必须有严格的结构校验否则模型会给你编出看起来很合理的东西。后处理是三路合并的关键重叠消解同一位置多个结果按字典 模型 大模型的优先级但类型冲突时要打标记进审核队列。边界修正把某某设备有限公司的冷却泵这种过长片段按停用词表和标点规则裁剪到核心实体。类型归一把近义类型映射到本体里的标准类型映射表由本体注册中心统一维护。置信度打分见 4.5 节。4.3 关系抽取小样本起步别一上来就做大而全关系抽取比实体识别难一个量级因为关系信号更稀疏、更依赖上下文。我见过的失败案例基本都是一上来就想覆盖全部关系类型结果每个类型都只有几十个样本效果惨不忍睹。我推荐的顺序是先做 3 个关系类型做到自动通过率 80% 以上再扩。选哪三个选业务问题里引用次数最多、句式最规整的那三个。规整意味着规则能覆盖一部分规则覆盖的那部分可以当种子去训练模型模型再去覆盖变体形成滚雪球。技术上走三段第一段是规则模板用触发词 句法位置约束。比如X 的 Y在特定语境下表达包含关系。规则的准确率通常很高召回低正好用来做冷启动。第二段是监督模型把头实体 句子 尾实体拼成输入做分类。样本从哪来从规则挖出来的高置信结果当正样本随机替换头尾实体当负样本。这个套路远程监督噪声不小但起步阶段够用。第三段是大模型抽取 校验主要处理长距离依赖和跨句关系。跨句关系是规则和传统模型都头疼的地方比如该设备在去年三月出现异常导致生产线停机六小时故障和停机的因果关系跨了分句。4.4 实体对齐与消歧分桶、打分、人工仲裁实体对齐是整条链路里最容易一发不可收拾的环节。对齐做保守图里同一实体散成十几个节点查询召回不全对齐做激进两个不同实体被合并图上出现荒谬的推理路径。我的做法是四段式第一步分桶blocking。按key_fields生成分桶键只有同一个桶里的实体才需要比较。这一步能把 O(n²) 的比较量压到可接受范围。分桶键可以多套并行比如名称前 4 字 型号和名称拼音首字母 厂商多套取并集避免分桶把真匹配切开。第二步相似度计算。三路打分字符级编辑距离、字符 n-gram Jaccard、语义级文本向量余弦、上下文级两个实体的邻居节点重合度。三路加权成一个总分权重我一般给 0.3 / 0.4 / 0.3邻居重合度这个特征特别有用——两个实体如果邻居高度重叠基本就是同一个。第三步分档。总分高于 0.92 自动合并0.75 到 0.92 进人工仲裁队列低于 0.75 不动。这两个阈值不是固定的要按实体类型分别调——名称很短的类型比如部件名只有两三个字阈值要更高否则误合并率会飙升。调阈值的方法很简单抽 200 对候选出来人工判断画出不同阈值下的准确率和召回选一个业务能接受的平衡点。第四步人工仲裁 规则沉淀。仲裁台的判断结果要沉淀成两类资产一类是确认同义的合并记录用来补别名词典另一类是确认不同的反例用来调阈值和加否定规则。这一步做得好仲裁量会逐月下降。4.5 置信度打分与进图门槛置信度不是一个模型 softmax 分数就完事我用的是一套加权公式conf w1 * p_model w2 * f_rule w3 * s_context - w4 * r_conflict其中p_model是模型概率f_rule是规则命中强度精确模板 1.0宽松模板 0.6无命中 0s_context是上下文一致性分比如实体类型是否与关系定义的头尾类型匹配匹配 1.0不匹配 0.2r_conflict是冲突惩罚同位置出现不同类型、同一关系出现相反方向等。权重我一般取 0.5 / 0.2 / 0.2 / 0.3具体项目要微调。分档策略按 1.2 节的四象限来置信度区间处理预期人工介入比例≥ 0.90自动入主图00.75 ~ 0.90入候选池抽样 10% 审核约 10%0.60 ~ 0.75入候选池全部审核100% 0.60丢弃但保留日志0抽样比例可以算。假设你想把错误率的估计精度控制在 ±3%95% 置信水平根据二项分布近似需要样本量 n ≈ 1.96² × p(1-p) / 0.03²取 p0.1 时 n ≈ 384。所以如果候选池有 4000 条抽 400 条左右就能把错误率估到 ±3% 以内。这个数字比随手抽 50 条看看靠谱得多。5. 完整实操从一批文档到可查图谱5.1 目录结构与运行环境我习惯用固定的目录结构避免跑着跑着自己都找不到文件。saka/ ├── conf/ │ ├── ontology.yaml # 本体定义 │ ├── pipeline.yaml # 抽取路由与阈值 │ └── dict/ # 词典文件 ├── data/ │ ├── raw/ # 原始文档按来源分子目录 │ ├── clean/ # 清洗后文本块jsonl │ └── result/ # 抽取结果jsonl ├── scripts/ │ ├── ingest.sh │ ├── extract.sh │ └── load.sh └── log/运行环境只要能跑 Python 3.10、一个属性图数据库、一个关系型数据库、一个向量检索组件就行。别急着上分布式第一批数据量通常在百万级文本块以内单机加并发就够上了集群反而把调试复杂度拉满。5.2 抽取服务的接口约定接口约定这件事我建议第一天就定死后面所有模块都按这个来。统一的结果结构如下{ doc_id: doc_00123, chunk_id: chunk_00123_07, char_start: 128, char_end: 134, entity: {text: 冷却泵, type: Component, normalized: 冷却泵, id: CMP_8c1f}, relation: {type: has_component, head_id: EQP_2a94, tail_id: CMP_8c1f}, confidence: 0.87, source: model_ner_v3rule_rel_tpl_02, status: pending, ontology_version: 1.2.0 }几个字段的作用source用拼接多路来源方便后面统计哪条规则贡献了多少高置信结果status是审核状态机的入口ontology_version保证本体升级后能精准重跑。5.3 入库幂等、版本、软删除入库这一步最容易出问题因为增量更新会反复写同一批数据。我的三条铁律第一条唯一键要能表达同一条事实。我用head_id relation_type tail_id source_doc做唯一键重复写入时只更新置信度和更新时间不新建记录。这样同一份文档重跑十次库里还是一条。第二条属性冲突不覆盖走候选。同一个设备在两个文档里厂商不一样不要后写的覆盖先写的而是两条都存标上来源和时间进冲突队列。冲突消解的策略可以是取最新取来源可信度最高取多数但一定要显式配置不能默认覆盖。第三条删除用软删。任何删除操作只改status字段不物理删。图谱这东西删了之后想追溯特别麻烦而且下游应用可能还在引用。物理清理放在定期的归档任务里做且要有冷备。增量更新还有个小技巧按文档而不是按实体做版本。同一份文档重新抽取后把这篇文档的所有结果标记为新版本旧版本置为失效查询侧只读最新有效版本。这样避免了实体级版本管理带来的复杂度又保证了数据一致性。5.4 审核台的交互设计审核台不是给工程师用的是给业务专家用的所以交互设计比功能多少更重要。我总结了几条把同类问题聚批一次显示 10 到 20 条相似判断支持全选、反选、批量确认。人的判断力在同一类问题上是稳定的切换到另一类会有明显损耗所以批次之间要尽量类型单一。把证据摆在旁边每条待审结果都要能一键看到原文上下文高亮显示实体位置。让人脱离原文做判断准确率会掉得厉害。把修正动作做成选择题而不是填空题。绝大部分情况就是对类型错该合并不该合并四个选项填空只在极少数情况才放开。自由输入会引入新的不一致。把判断结果实时影响候选池。审核员确认了一条合并系统应该立刻用这条合并关系去扫描候选池里的相似对把连带可以合并的一起推出来。这个连带推荐能省掉大量重复劳动我在一个项目里统计过连带推荐让平均审核耗时从 25 秒/条降到 9 秒/条。6. 应用层图谱要用起来才有价值6.1 图谱增强的检索与问答链路图谱最常见的落地场景是给问答和检索提供结构化上下文。链路一般是用户问题 → 实体识别用图谱里的别名词典→ 子图召回从实体出发取 2 到 3 跳→ 子图序列化成文本 → 和向量召回的原文档片段一起给生成模块 → 输出答案 引用。这里有个关键细节子图不能无脑全取。一个高频实体可能挂着几百条边全取会撑爆上下文长度而且大部分是噪声。我用的裁剪策略是按关系类型的业务权重排序每个类型最多取 N 条通常 5 到 10 条按置信度和时间新鲜度排序总条数控制在 30 以内。这样既保留了关键事实又不会让上下文失控。另一个细节是答案里要带溯源。生成模块输出答案时要求它同时输出引用了子图里的哪几条事实、对应哪份文档。这不仅是可信度问题更是排错入口——用户说答错了你能立刻看出是子图召回错了、还是生成环节理解错了。6.2 图特征进业务模型除了问答图谱的另一大价值是把图结构转成特征喂给现有的业务模型。常见的几类度与路径类实体的邻居数量、二跳可达数量、到某类实体的最短路径长度。这类特征在风险传导、故障影响评估里很有效。聚集类邻居的类型分布、关系类型分布、社区所属。这类特征能刻画实体的角色比如一个部件如果邻居全是故障事件那它大概率是易损件。时序类关系的首次出现时间、最近出现时间、出现频次。这能捕捉新出现的问题和长期存在的问题。导出方式我建议做成定时的特征快照按实体 ID 落到特征表里业务模型直接关联。不要做成实时图查询图的实时多跳查询在并发高的时候延迟很不稳定容易拖垮整个推理链路。6.3 影响面评估哪些场景收益最大不是所有场景都值得建图谱。我按收益从高到低排一下第一档多跳关联查询。比如这个批次的原料用在了哪些产品上这些产品卖给了哪些客户。这类问题在关系型数据库里要写多层 join在图里是一两跳的事收益非常直观。第二档复杂规则的合规校验。规则涉及多个实体和关系的组合判断图谱能把规则表达成模式匹配改规则不用改代码。第三档检索增强。给现有搜索或问答加结构化上下文提升答案的准确性和可解释性。第四档纯统计报表。这种场景用关系型数据库完全够上图谱纯属增加复杂度。我见过硬把报表需求做成图谱的最后查询性能还不如原来的 SQL。7. 常见问题与排查实录7.1 三类典型症状的速查表跑起来之后问题基本集中在三个方向召回不够、噪声太多、对齐混乱。整理成表方便对照。症状常见根因排查动作处理方式某类实体召回低词典覆盖不足分块切断模型训练样本偏抽 100 条漏识样本看原文判断是没抽到还是抽错了补词典调整分块长度补该类样本重训关系噪声高触发词歧义负样本构造太简单阈值过低按 source 字段分组统计准确率收紧模板构造难负样本上调 confidence_floor实体误合并分桶键区分度低阈值过低别名词典有脏数据抽 100 组已合并实体人工复核换分桶键上调阈值清理别名词典实体漏合并分桶键切断了真匹配相似度权重不合理抽查同桶未合并和不同桶未比较两类增加并行分桶键提高邻居重合度权重查询结果荒谬上游错误累积图谱有环缺时间约束沿路径回溯每一条边的来源和置信度加时间过滤低置信边不上查询路径增量更新后数据重复唯一键没覆盖来源维度重跑未做幂等按唯一键 group by 找重复补唯一键重跑写入改为 upsert这张表里我最想强调按 source 字段分组统计准确率这一条。很多人排查只看总体准确率看不出问题出在哪。把source拆开看你会很快发现是某一条规则在大量产错还是某个模型版本整体退化。这个操作成本极低但能砍掉一半排查时间。7.2 性能与成本上的几个现实约束图查询的深度不要超过 3 跳。3 跳以上的查询在稠密图上性能断崖式下跌而且结果的可解释性也差。业务上真需要深链就预先算好物化路径别在线上现算。抽取任务要按优先级排队。全量重跑和增量更新抢资源是常态。我的做法是给任务分优先级增量新高优、本体升级重跑中、全量重建低配合并发上限。别让一个全量重建把实时链路拖死。模型成本要有预算闸门。大模型兜底那条路很容易失控因为长尾数据是无限的。我一般设一个月度 token 预算到 80% 就自动降级为只处理高优先级类型超了就停。这个闸门必须做否则某天账单一来整个项目都得停。存储要预留冗余。图的边数增长往往比预期快因为增量更新、多版本共存、候选池都在涨。规划容量时按预估的 3 倍准备别按 1.2 倍。7.3 我踩过的几个坑第一个坑是过早追求覆盖率。第一版上线时我看着覆盖率只有 40% 很不爽花了两周去扩类型、补规则。结果覆盖率上去了准确率掉到 60%业务方直接不认。后来我反过来先把 Top 5 类型的准确率做到 90% 以上覆盖率 40% 也能用因为那 40% 覆盖了 80% 的查询量。这个道理听着简单做的时候特别容易上头。第二个坑是拿模型的概率当置信度。模型输出的概率是在这个模型视角下的相对置信不是客观上正确的概率。一个在训练集上过拟合的模型会给出虚高的概率。所以置信度一定要融合规则命中、上下文一致性、历史准确率这些外部信号单靠模型分数会翻车。第三个坑是忽略了空结果的价值。早期我只记录抽到的结果没记录某个 chunk 明明应该有实体但没抽到。后来加了负样本日志把高概率应该有结果但没有的片段单独存下来这批数据对优化模型的价值比正样本还高。第四个坑是审核台的权限没分级。一开始所有人权限一样结果实习生把一个核心实体类型批量改错了追溯花了两天。后来加了角色分级普通审核只能确认/驳回合并和本体变更要二级审批。8. 图谱的长期维护它会腐烂得定期打理知识图谱上线不是终点它会随时间腐烂。实体过时、关系失效、别名增加、业务口径变化都会让图慢慢和数据脱节。我一般按三个周期来维护。周级看审核队列的积压情况、自动通过率的变化、抽取失败率的波动。这三个指标如果同时恶化说明数据源或者业务口径变了要立刻查。月级跑一次质量抽检按实体类型各抽 100 条人工判准确率画趋势图。同时看查询侧的失败样本把查不到答错了的问题归类反推是抽取问题还是本体问题。季级本体评审看是否有类型需要合并、拆分、废弃词典做一次全量梳理清理过时别名模型做一次重训用这季度积累的修正事件做增量训练。这套节奏跑下来人工成本是递减的图谱的有效性反而在升。我在一个运营了一年多的项目上看到的数据是第一年人工审核量约 6 万条第二年降到 2.3 万条同时自动通过率从 61% 升到 84%。这个曲线的形状比任何单点指标都更能说明半自动化这条路走对了。最后分享一个我在实操中觉得最值的小技巧给每条边加一个最后确认时间字段并在查询侧把它作为排序因子之一。图谱里的老数据不一定错但一定更值得怀疑。加上这个字段之后很多莫名其妙的查询问题自己就消失了——因为最新的、经过人工确认的事实被排到了前面而那些陈旧的、低置信的边自然沉底。这个改动只加了一个字段和一个排序参数收益却比调模型明显得多。
