W
AI-Wiki
CONCEPT

类型化知识图谱

定义

类型化知识图谱，是指在知识库中不给“页面之间有关联”停留在普通 wikilink 层面，而是把关系进一步写成带明确语义的命名边，例如 uses、depends_on、contradicts、supersedes，以及评论区提到的 named edges、derived_from。

在本文语境里，它不是泛指任何 graph，也不是“有个可视化关系图就算图谱”。它特指：为了让 Agent 和人都能回答结构性问题，把实体、claim、决策、来源之间的关系显式建模出来，并且尽量带上可追溯依据。

提出背景

原文把它放在 LLM Wiki 从“能启动”走向“能长期维护”的背景下讨论。

原版 LLM Wiki 主要依赖 Markdown 页面、wikilink 和可视化 graph。这样做的优点是轻：页面之间能互相引用，人也能看到哪些页面连着哪些页面。

但当知识库变大、问题变复杂时，这种连接方式开始不够用。原文给出的典型问题不是“这个术语在哪篇文档里出现过”，而是：

  • 升级某个基础组件会影响哪些服务。
  • 某个鉴权决策牵涉哪些 bug、哪些负责人、哪些后续变更。
  • 两条结论是否互相矛盾。
  • 现在采用的方案替代了哪一个旧方案。

这些问题都要求系统理解“关系的类型”，而不是只知道“它们被链接过”。普通 wikilink 和图可视化能显示页面相连，但难以直接回答升级影响、决策依赖、矛盾关系和责任链。

在本文档中的语境

本文讨论的 类型化知识图谱 是 LLM Wiki V2 生产层的一部分，与 混合检索、memory lifecycle、事件驱动和质量治理一起出现。

它的定位很明确：不是替代原来的 wiki 页面，而是在 wiki 之上补一层“可计算的结构关系”。换句话说，全文仍然保留在 Markdown 页面里，图层负责把其中那些对查询和决策重要的关系抽出来。

因此，它服务的重点不是写作展示，而是查询、影响分析、溯源与决策维护。

关键边类型

原文明确列出了一组关键关系：

  • uses：表示某实体、模块、服务或方案使用了另一对象。适合回答“谁在用它”。
  • depends_on：表示依赖关系，通常比 uses 更强调前置约束或不可缺少的依赖。适合回答“它坏了会牵连谁”。
  • contradicts：表示结论、claim、方案或判断之间存在冲突。适合回答“系统里有没有相互矛盾的知识”。
  • supersedes：表示新信息、决策或实现替代旧信息。适合回答“现在为什么这样做”“旧方案被什么替掉了”。

评论区还补充了两个重要方向：

  • named edges：不要只依靠系统事后推断“它们可能有关”，而是尽量把关系名称显式写出来。
  • derived_from：例如 derived_from::Source 这种边，用来标记某条知识、某个 claim、某段总结是从哪份来源推导或编译而来。

这说明图谱中的边不只是“实体对实体”的工程依赖边，也可以是“结论对来源”的证据边。

关键机制或组成

1. 实体、claim 与关系共同构成图层

原文的落地方向不是只把页面当节点。更可操作的方式是：

  • 有稳定标识的实体。
  • 可被引用和替代的 claim。
  • 带类型的边。
  • 边和 claim 对应的来源证据。

例如某条事实可以有 claim id；它既能通过 derived_from 指回来源，也能通过 supersedes 连到旧版本结论，还能通过 uses 或 depends_on 连到相关实体。这样图谱才能支撑“事实—来源—决策—变更”这一整条链。

2. 图谱与检索层配合，而不是单独工作

原文特别强调，不能把问题简化成“把 index 换成图谱”或“把 index 换成 混合检索 就结束了”。

在 V2 里，BM25 和向量搜索负责找到“此刻相关”的材料，图遍历负责找到“结构上相关”的影响链。两者不是互斥关系。

因此 类型化知识图谱 的价值主要出现在：

  • 影响分析。
  • 历史决策追踪。
  • 替代关系追踪。
  • 矛盾检测。
  • 责任链和依赖链定位。

而术语检索、近义表达召回、页面级找回，仍然更依赖 BM25、向量或其他文本检索方法。

3. 每条边最好带来源和可追溯依据

原文对 numeric confidence 很警惕，认为单独给一个 0.85 之类的分数，很容易制造没有来由的权威感。相比之下，更可靠的做法是证据链。

这意味着图谱中的边最好不要只是抽象推断，例如“系统觉得 A 大概依赖 B”。更理想的是：

  • 这条边来自哪份 ADR。
  • 来自哪次 commit。
  • 来自哪篇 source。
  • 来自哪次 session summary。
  • 最近什么时候被确认过。
  • 是否已被新信息替代。

也就是说，边本身应尽量是可审计的对象，而不是只有模型内部推断。

落地建议

原文给出的建议非常务实：不要一上来就建设完整图数据库系统。更稳的路径是先把图关系从已有 Markdown 知识库里抽出来。

建议顺序大致是：

  1. 先保留原有 raw/、wiki/、index.md、log.md、AGENTS.md 这样的轻量结构。
  2. 每次 ingest 先让 Agent 更新页面，并通过 Git diff 审核改动。
  3. 再给事实补 claim id 和 source_ref。
  4. 在此基础上，把 supersedes、contradicts、uses、depends_on 等关系表示出来。
  5. 图关系先从 Markdown frontmatter 或 sidecar JSON 中抽取。
  6. 图数据库后置，先把实体和边的契约定清楚。

这里“契约”是关键。它指的不是炫技式 schema，而是先明确：

  • 哪些对象算实体。
  • 哪些对象算 claim。
  • 每种边允许连接什么对象。
  • 哪些边必须附来源。
  • 哪些边的写入需要人工审核。

只有这些规则先稳定下来，后面不管是存在文件里、SQLite 里，还是迁到图数据库里，成本才可控。

与证据链的关系

类型化知识图谱 在本文里不是孤立的结构层，而是 evidence contract 的一部分。

原文明确主张把“可信度”尽量落到可展示的证据链上：每个 claim 有稳定 id，每条边有来源，每次替代有链接，每次回答能显示证据链。

因此，一个成熟的图谱至少应回答：

  • 这条关系是谁写入的。
  • 它基于什么材料。
  • 它是直接摘录、人工确认，还是模型归纳。
  • 是否存在相反证据。
  • 是否已经被新的关系替代。

如果只有抽象关系、没有来源，那么图谱虽然能画出漂亮的结构图，但很难真正用于生产决策。

细节与边界

1. 图谱不是全文检索的替代品

原文反复强调，图层的作用不是替代文本检索，而是补足结构相关查询。

如果查询大多是：

  • 精确术语查找。
  • 某个概念的同义表达查找。