企业官网建设流程全解析

做过几年数据侧的项目，我最怕听到的一句话就是"帮我把这些文档做成知识图谱"。这句话听起来像个需求，实际上是个坑：文档有多少、长什么样、要回答什么问题、谁来判断对错，四个关键信息一个都没有。等真把流水线搭起来，你会发现全自动跑出来的图谱，实体重复、关系错乱、置信度没法看；而纯人工标注，一天标不了几百条，成本压不住。半自动化知识图谱构建这件事，本质上不是技术选型问题，而是"人机分工比例"的设计问题。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_relations

key_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 校验器强校验——字段缺失、类型不匹配、值不在枚举内的，一律打回。这一层必须有严格的结构校验，否则模型会给你编出看起来很合理的东西。

后处理是三路合并的关键：

1. 重叠消解：同一位置多个结果，按"字典 > 模型 > 大模型"的优先级，但类型冲突时要打标记进审核队列。
2. 边界修正：把"某某设备有限公司的冷却泵"这种过长片段，按停用词表和标点规则裁剪到核心实体。
3. 类型归一：把近义类型映射到本体里的标准类型，映射表由本体注册中心统一维护。
4. 置信度打分：见 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，无命中 0），s_context是上下文一致性分（比如实体类型是否与关系定义的头尾类型匹配，匹配 1.0，不匹配 0.2），r_conflict是冲突惩罚（同位置出现不同类型、同一关系出现相反方向等）。权重我一般取 0.5 / 0.2 / 0.2 / 0.3，具体项目要微调。

分档策略按 1.2 节的四象限来：

抽样比例可以算。假设你想把错误率的估计精度控制在 ±3%（95% 置信水平），根据二项分布近似，需要样本量 n ≈ 1.96² × p(1-p) / 0.03²，取 p=0.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_v3+rule_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 三类典型症状的速查表

跑起来之后，问题基本集中在三个方向：召回不够、噪声太多、对齐混乱。整理成表方便对照。

这张表里我最想强调"按 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%。这个曲线的形状，比任何单点指标都更能说明半自动化这条路走对了。

最后分享一个我在实操中觉得最值的小技巧：给每条边加一个"最后确认时间"字段，并在查询侧把它作为排序因子之一。图谱里的老数据不一定错，但一定更值得怀疑。加上这个字段之后，很多莫名其妙的查询问题自己就消失了——因为最新的、经过人工确认的事实被排到了前面，而那些陈旧的、低置信的边自然沉底。这个改动只加了一个字段和一个排序参数，收益却比调模型明显得多。