Ch42: 挑战深读④——图谱构建、PMI vs LLM 与增量更新

Part 10 · 合并 challenges #4 + #13 · Ch26 PMI 源码 · Ch31 Wiki 自维护 · Ch23 EventManager

结论先行：WeKnora 默认 PMI 统计图谱——便宜、无标注，但噪声边多、无因果、缺消歧；LLM 三元组 准但按 chunk 计费，无法每日全量重建。维护与实时性的共同瓶颈是 增量一致性：文档删改后 PMI 共现、chunk、向量若未级联重算，多跳检索会带过期边。EventManager + DocumentUpdated 插件链 是把 #4 与 #13 合成一条 PR 线的正确切口。

一、日常类比：便利贴墙与画线

知识库像一面贴满便利贴的墙；图谱是在便利贴之间画线。「谁该连谁？」PMI 靠 共现频率 猜——成本低，但「BM25 与向量检索常一起出现」会被画成强边，却不回答「BM25 为何优于向量」。LLM 像请专家逐张读贴再画线——语义对，但墙每改一张就要重读周边。增量更新 就是：改一张贴时，哪些旧线该删、哪些新线该加，且检索在更新过程中仍要自洽。

二、PMI vs LLM：路线对照

混合贡献方向：PMI 产候选边 → LLM 批量校验 top-K 高 PMI 边 → 写入持久化图谱；日常增量仍走 PMI + 校验队列，控制 LLM 预算。

三、增量更新三难（#13）

WeKnora 在 wiki/ 增量 PMI 上领先于多数平台，但 chunk 级 re-embed 与图谱级联 仍可能漏触发——见 Ch23 摄入链是否完整订阅 DocumentUpdated。

四、EventManager 增量链（大师 grep）

rg -n "DocumentUpdated|ChunksIndexed|PMI|pmi" internal/ --glob "*.go" | head -40
rg -n "Register\(|Emit\(" internal/eventmanager/ --glob "*.go"

期望 DAG（概念）：

DocumentUpdated
  → 语义 diff（可选：仅 typo 跳过 re-embed）
  → 受影响 chunk_id 列表
  → re-embed job + 向量 upsert
  → PMI 增量：回滚旧 doc 贡献 → 重算共现 → 删/降权边
  → ChunksIndexed / GraphUpdated 事件

与 lab/corpus 联动：改 weknora-arch.md 中「向量库个数」后，应用 benchmark/smoke-10.jsonl 中 zh-003 类时效题验证图谱+向量是否同步。

五、诊断表

六、五平台更新策略（简表）

七、实验（约 90 分钟）

1. 构建：上传 lab/corpus 10 篇相关 doc，记录图谱边数与 zh-003 baseline。
2. 删除：删 1 篇 hub 文档，检查关联 PMI 边是否消失或降权（应变化）。
3. 对比：「双路 BM25+向量」vs「三路含图谱」在 5 条多跳 hard 上的 Recall@5。
4. 增量：改同一 doc 一段关键事实 → 跑 smoke-10 子集 → PR 附 before/after 四指标（faithfulness / latency / 边数 / chunk 数）。

八、贡献方向（Volunteer PR）

• DocumentUpdated 插件：输出 affected_chunk_ids + 触发 re-embed + PMI 回滚 Ch23
• 中文实体 linking 小词典（产品代号、错误码）
• 冷启动配置与 admin 文档：min_docs_for_graph
• 与 Ch31 巡检联动：过期 doc 自动排队 re-ingest
• 图谱路 超时降级（与 Ch43 延迟章衔接）

章末自检

• 用一句话对比 PMI vs LLM Graph 的 成本与质量 trade-off
• 解释「删文档后 PMI 边仍存活」的根因与 EventManager 修复点
• 说清冷启动时 graph_weight=0 的理由
• 画出从 DocumentUpdated 到 ChunksIndexed 的最小事件链（≥4 步）

延伸阅读

• Ch11 Graph RAG · Ch26 PMI 源码 · Ch31 Wiki 自维护
• Ch23 EventManager · Ch14 动手实验 · smoke-10
• challenges.md §4 + §13 · case-1774 三层 API