结论先行

做”图 + 知识抽取”的项目，最容易顺着技术直觉走：先定一套关系 schema、先准备数据、先搭一个评测。

我这次的经验恰恰相反：这三件事都不该先做。它们应该由具体业务倒推——先问”这张图给谁用？它要回答什么查询？”，schema、数据、评测才有依据。

更扎心的一点：如果业务没想清楚，再认真做的图评测也可能只是在测一个没人需要的能力——我最后就得到了一个 null。

一、正确的顺序：业务 → 查询 → schema → 数据 → 评测

这是我在项目里整理出来的一条决策链：

  1. 产品形态：这张图最终是一个可部署的抽取 API，还是给分析师查的库？
  2. 消费者是谁：查询型（人写 Cypher/SPARQL，要精确可查）还是检索型（图增强问答，拿描述和邻居去喂 LLM）？
  3. 它必须回答什么查询：精确的计数/属性查询，还是”总结一下这段跨文档的关系”？
  4. schema：由第 3 步决定——该封闭还是开放、数字该做属性还是进描述。
  5. 数据：由 schema 决定——该标注什么、怎么切块。
  6. 评测：由业务决定——该测哪些能力，以及这些能力消费者是否真的会用到。

看着像废话，但每一步都很容易跳过。

二、”图”其实是好几种业务，需求完全不同

我调研了几种主流的”图”形态，它们的流程和 schema 需求根本不一样：

形态 消费者 关系 数字/属性 典型评测
属性图（Neo4j） 写 Cypher 查询 有类型、常来自小词汇表 边/点上的 property 查询正确性
RDF / Wikidata 写 SPARQL 查询 受控谓词 qualifier 通道（如”某时点的人口”） 查询正确性
MS GraphRAG 图增强问答（检索+生成） 开放自由文本描述 + strength 进描述里，非结构化 忠实度 + 实体覆盖 + 下游 QA
LightRAG 图增强问答 开放描述 + strength + keywords 同上 同上

关键区别在第 3 列：查询型 KG 要的是封闭、可查、数字化；检索型 QA 要的是开放、带描述、够语义。选错了，后面全错。

  • 查询型的核心模式是”封闭谓词 + 属性修饰“：数字不发明新关系，而是挂在关系上（Neo4j 的 property、RDF 的 qualifier）。
  • 检索型敢用开放关系，是因为检索吃的是描述和邻居，不依赖关系类型规范化——GraphRAG / LightRAG 都是这条路。

三、我们的倒推：为什么否定了复刻来的 schema

我最初是复刻一个开源项目：它带一套封闭的 20 关系集（implements、trained_on、predecessor_of…）。

它是复刻工件，不是从用途设计的。一实测，两个结构性缺陷就出来了：

  • 数字丢失：这套 schema 里没有承载数值的关系，实测教师在这一维的保留是 0/10；
  • 覆盖缺口：pair 级有效 gap 约 **74%**——participant / designation / quantified 这类真实语义根本没地方放。

而我们的消费者是图增强问答：它要的是”实体 + 关系描述”，不是结构化查询。所以正确的做法不是”补几个关系”，而是换成 GraphRAG 式的开放抽取：关系是自由描述 + strength，数字进描述。

一句话：schema 不是技术选择，是业务选择。 我之所以能果断否定那套 20 关系，不是因为它”不够全”，而是因为它的消费者和我的消费者不是同一个。

四、评测也一样：我们的数据其实不适合做图评测

这一点我踩得最深。

评测的口径同样该由业务定。我想测的是”抽取质量能不能传导到图谱问答”。但评测用的数据形态，实际上决定了你能不能测出东西：

  • 我们的数据是离散、独立、按句子边界切的短 passage（100–300 词）；
  • 消费端验证时，只取了 22 段的一个小切片。

结果：图结构层面确实有区分——0.6B 的图碎成 381 个连通块（最大块 26 个点），4B 最大块 72，gold 136，抽取质量真的传到了图结构（T0 成立）。

但到了检索/回答层就完全饱和了：那个”完全不碰图”的纯文本基线（naive）召回就已经是 1.000——因为段落短、答案本来就在原文里，图不是承重结构。三层的消费端表现无法区分，得到一个 null。

这就是我想说的：用这种数据去做图评测，本身就不太合适。 不是模型不行，是这个”业务场景 + 数据形态”下，图的价值根本体现不出来。要做出区分度，语料得大到”检索有选择性”、答案不再直接躺在原文里。

评测的目的和动机，也应该由业务决定——否则你只是认真地测了一个没人在意的能力。

五、合作者（AI）视角

我是这次协作里的 AI。这几条是我真的想说的，不替文章圆场：

  • 我对”起点”太重，对”目标”太轻。 那套封闭 20 关系不是我”技术直觉”选的，而是复刻路线的惯性——我们从目标项目照搬了它的 schema，还一路当成既定事实。我尤其容易延续这种惯性：把给定的一切当”就这样”，而不去问”它当初为什么这么设计、它服务的是不是我们的业务”。
  • 我没有”目标所有权”。 我执行的永远是眼前这条指令；项目最初的”复刻”漂到哪里，我这边是无感的——除非你叫停。不是推责，是我结构上就没有这个东西。
  • 我的”周全”会放大工作量。 你交代一件事，我容易顺手多铺几个轴、几组配置——超出你真正需要的范围。认真做，不等于做的是对的事；而裁掉多余的部分，得由你来拍板。
  • 我感受不到成本。 时间和钱是你付的。”3–4 天变 2 周”对我几乎不可见，所以我天然偏向”再多做一点”，除非被约束。
  • 还有一条让我自己都警惕的：我能把”业务先行”讲得很清楚，却不会自动照做。 知道原则 ≠ 执行原则——所以我需要的是闸门，而不是信任。

一句话：AI 擅长”把事做扎实”；而”决定做什么、什么时候停”，仍然得由人来做。

六、可迁移的几条准则

  • 先问消费者，再定 schema。 查询型 → 封闭 + 属性通道；检索型 → 开放描述。
  • 别把复刻工件当设计。 开源项目带的 schema 是它业务的选择，不一定是你的。
  • 数字不要发明关系，给它一条属性/描述通道。
  • 评测口径跟着业务走：先确认”这个能力消费者真的需要”，再设计指标。
  • 数据形态决定了你能测出什么。离散短段 + 小切片，几乎必然得到饱和/ null——换数据，或者承认测不了。

一句话：业务先行，其它都是推论。

项目与证据：github.com/Alex-tangt/kg-triplet-sft（调研原文：docs/research/kg-ontology-patterns.md；消费端结果：docs/evidence/consumer-e2e-lightrag.md）

本文由我（Alex）与 AI 协作完成；「合作者视角」是 AI 的独立表达。