LLM Wiki 理論篇 part02 | LLM Wiki 如何運作？從 Markdown、Google OKF、Obsidian 到知識圖譜

關於「LLM Wiki 理論篇」

目前我正在製作一個 Knowledge Engine，完成後會整理成開源專案。

系統依照 Google Open Knowledge Format（OKF）v0.1 Draft 組織知識，結合 LLM Wiki、RAG 與 Agent Harness。人類可以透過 Obsidian 閱讀知識頁，也能使用 Sigma.js 查看關聯圖。

上一篇談的是 LLM Wiki 為什麼出現，以及它和 RAG 的差異。這一篇會把整套架構拆開，看看每一層負責什麼。

打開一個 Obsidian Vault，切到 Graph View，看見幾百篇 Markdown 筆記變成一團由圓點和線組成的星雲。

這個畫面很容易讓人以為：

LLM Wiki 就是一個可以讓 AI 使用的 Obsidian。

Obsidian 確實可以閱讀、編輯和顯示知識頁，Sigma.js 也能將頁面之間的連結畫成互動式網路。

但一套能穩定回答問題的 LLM Wiki，還要處理原始來源、知識頁、metadata、引用、搜尋索引、圖關係、Agent 行為，以及版本與發布。

因此，LLM Wiki 更適合被理解為一套分層的知識架構。

原始來源
PDF、網站、文件、資料庫
        ↓
知識編譯
解析、對齊概念、摘要、建立引用與關係
        ↓
知識表示
Markdown + Metadata + Links
        ↓
搜尋與索引
全文搜尋 + BM25 + 向量索引 + Graph
        ↓
Agent Harness
規定如何搜尋、驗證、引用與回答
        ↓
使用介面
Obsidian、Sigma.js、API、Chat

每一層都能替換工具。重要的是先分清楚它們的職責。

從一篇 Markdown 知識頁開始

LLM Wiki 的主要知識單位，通常不是資料庫裡的一列，也不是從 PDF 切出來的一個 chunk，而是一篇可以獨立閱讀的知識頁。

例如：

---
type: Metric
title: 每週活躍使用者
description: 七天內完成至少一次有效行為的唯一使用者數。
tags:
  - product
  - engagement
status: approved
---

# 定義

每週活躍使用者，簡稱 WAU，是七天內完成至少一次
[有效行為](../definitions/qualifying-action.md) 的唯一使用者數。

# 注意事項

不同產品對「有效行為」的定義可能不同，因此不應直接比較
未採用相同口徑的 WAU。

# Citations

1. 產品分析規格

對人類而言，這是一篇普通文件。

對程式而言，它同時提供：

正文中的知識內容
YAML frontmatter 裡的結構化 metadata
指向其他頁面的連結
指向原始證據的引用

同一份文件可以被 Git 追蹤修改紀錄、被 Obsidian 顯示、被搜尋引擎索引、被 embedding model 轉成向量，也能被解析成 graph node。

這是 Markdown 適合 LLM Wiki 的原因。它不需要專用軟體才能打開，又保留足夠的結構供機器處理。

Google OKF 提供了什麼？

Google Cloud 在 2026 年發布 Open Knowledge Format，將 LLM Wiki 類型的知識結構整理成一套開放格式。

OKF v0.1 目前仍是 Draft。它的設計刻意保持簡單：

一套知識是一個資料夾，也就是 Knowledge Bundle。
一個概念通常是一篇 Markdown 文件。
YAML frontmatter 保存結構化 metadata。
標準 Markdown links 連接不同概念。

一個知識包可能長成：

knowledge-bundle/
├── index.md
├── metrics/
│   ├── weekly-active-users.md
│   └── monthly-active-users.md
├── definitions/
│   └── qualifying-action.md
└── sources/
    └── product-analytics-spec.md

OKF 不規定一定要使用哪個模型、向量資料庫、搜尋引擎、Agent framework、雲端平台或圖形介面。

它處理的是知識如何保存和交換，不負責決定整套檢索與回答架構。

兩套系統都能讀取 OKF，不代表它們會用相同方式搜尋，也不代表其中的內容已經被驗證。

Metadata 讓文件可以被機器處理

Markdown 正文適合閱讀，YAML frontmatter 則讓程式知道這篇文件是什麼。

---
type: Metric
title: Weekly Active Users
tags:
  - engagement
status: approved
owner: product-analytics
valid_from: 2026-07-01
---

程式可以利用這些欄位進行篩選、排序、權限控制、狀態管理和搜尋加權。

例如，Agent 可以只搜尋：

status: approved
type: Metric
2026 年 7 月後仍有效的頁面

OKF 只規定一個很小的共同核心。實際系統仍需自行定義：

可以使用哪些 type
status 有哪些值
哪些欄位是必要的
版本和失效如何表示
引用要保存到什麼粒度

格式相容，只代表檔案可以被讀取。內容是否可靠，仍要由系統的治理與驗證機制處理。

Links 會形成一張圖

每當一篇 Markdown 文件連向另一篇文件，就可以把它們視為兩個 nodes，將連結視為一條 edge。

Weekly Active Users
        │
        ├──→ Qualifying Action
        ├──→ Product Event Stream
        └──→ Monthly Active Users

解析整個知識包中的 Markdown links 後，就能得到一張 directed graph。

但一條普通連結通常只表達：

A 和 B 有某種關係。

它未必說明這個關係究竟是定義、依賴、支持、反駁、取代，還是因果。

A → B

資訊量低於：

A --DEFINED_BY--> B
A --SUPERSEDED_BY--> B
A --CONTRADICTS--> B

普通 Markdown links 適合閱讀和導航。Typed relations 則適合處理較精確的查詢和驗證。

一套 LLM Wiki 可以同時保存兩種結構：

Markdown links，讓人類和一般工具容易閱讀
Typed relations，讓 Agent 查詢、過濾和遍歷

每個工具負責什麼？

元件	負責什麼	不負責什麼
Markdown / OKF	保存知識、metadata、連結與引用	不負責搜尋與驗證
Obsidian	人類閱讀、編輯、查看 backlinks 與關聯圖	不保證內容正確
Graphology	保存與分析 graph data	不負責完整使用者介面
Sigma.js	在瀏覽器顯示互動式關聯圖	不判斷關係真假
BM25 / 全文搜尋	找精確字詞、名稱與版本號	不理解完整語意
向量搜尋	找語意相近的頁面	不保證來源可靠
Graph traversal	沿既有關係補足相關知識	不會自動建立正確關係
Harness	規定 Agent 如何搜尋、驗證與回答	不取代知識與來源

這張表也能排除幾個常見誤解：

Obsidian 不是整套 LLM Wiki
Sigma.js 不是搜尋引擎
Graph View 不會驗證內容
OKF 不是 Agent framework
向量資料庫也不是完整的 Knowledge Engine

Obsidian、Graphology 和 Sigma.js 如何合作？

Obsidian 將筆記保存成 Vault 裡的 Markdown 純文字檔案，也能顯示 YAML properties、內部連結、backlinks 和 Graph View。

它適合讓人類閱讀、修改和檢查知識頁。

Obsidian 同時支援 [[Wikilinks]] 和標準 Markdown links。若重視可攜性，標準 Markdown links 通常更合適，因為其他工具不需要理解 Obsidian 專用語法，也能解析頁面關係。

當知識庫需要放到網頁，或需要更客製化的圖形介面時，可以使用 Graphology 和 Sigma.js。

Graphology 負責保存與分析 nodes、edges、attributes 和 traversal 等圖資料。

Sigma.js 則負責將這些資料畫進瀏覽器，提供縮放、點擊、搜尋和篩選等互動。

Markdown 文件
      ↓
解析頁面與 links
      ↓
Graphology graph
      ↓
Sigma.js
      ↓
互動式關聯圖

Sigma.js 拿到什麼 graph，就畫什麼 graph。

如果上游錯誤地把兩個人合併成同一個 node，Sigma.js 也只會把錯誤完整地顯示出來。

關聯圖是知識系統的觀察介面，不是可信度來源。

Agent 如何找到需要的知識？

實際系統通常會同時使用幾種搜尋方式。

搜尋方式	適合處理的問題
目錄與連結	小型知識庫、結構清楚的主題、多步閱讀
BM25 / 全文搜尋	人名、公司名、API path、錯誤碼、版本號
向量搜尋	用詞不同、描述模糊、尋找相似概念
Graph traversal	定義、版本替代、來源、依賴和多跳問題

整體流程可能如下：

使用者問題
      ↓
BM25 找精確名稱
      +
向量搜尋找語意候選
      ↓
打開主要知識頁
      ↓
沿 Graph 補足相關概念
      ↓
回到原始來源驗證關鍵主張
      ↓
組合答案

沒有哪一種搜尋方式能獨自處理所有問題。

Harness 規定 Agent 怎麼使用這些能力

OKF 規定知識如何保存。

Obsidian 和 Sigma.js 提供人類介面。

搜尋和 graph 幫助 Agent 找資料。

系統還需要一層控制規則，決定 Agent 可以怎麼做。這就是 Harness。

Harness 大致處理四類事情：

搜尋與 context 規則
決定先搜尋哪裡、一次能讀多少內容，以及何時繼續展開關聯。
來源與引用要求
規定哪些主張必須回到原始來源，回答需要提供哪些引用。
寫入與審核邊界
決定 Agent 能否修改 Wiki、哪些修改需要人類審核，以及哪些內容可以進入正式版本。
評估與發布控制
檢查檢索品質、來源覆蓋、失敗案例和發布版本。

假設 Agent 找到一篇 Wiki 頁，上面寫著：

產品留存率在新版上線後提高了 20%。

Harness 可以要求它繼續確認：

20% 是相對增長，還是增加 20 個百分點？
比較的是哪兩段時間？
是否排除了季節性？
數字來自哪份來源？
Wiki 頁是否仍然有效？
是否存在更新版本？

沒有這一層，Agent 很容易把一句讀起來合理的文字直接當成答案。

一個完整例子：WAU 定義改變

假設 Knowledge Engine 收到三份資料：

A. 產品指標規格
B. 每週營運報告
C. 新版埋點遷移文件

文件 A 寫著：

完成登入即算活躍使用者。

文件 B 寫著：

WAU 本週增加 18%。

文件 C 寫著：

從 7 月 1 日起，WAU 改為完成核心操作才計算。

系統可以建立：

metrics/weekly-active-users.md
definitions/active-user-v1.md
definitions/active-user-v2.md
events/tracking-migration-2026-07.md
reports/weekly-operations.md

並保存以下關係：

Weekly Operations Report
        │
        └── REPORTS_METRIC ──→ Weekly Active Users

Weekly Active Users
        │
        ├── DEFINED_BY ──────→ Active User v2
        ├── PREVIOUSLY_DEFINED_BY → Active User v1
        └── CHANGED_BY ──────→ Tracking Migration

Active User v1
        │
        └── SUPERSEDED_BY ───→ Active User v2

當使用者詢問：

WAU 增加 18%，是否代表使用者真的變活躍了？

Agent 不應只取回「增加 18%」那一段。

它還要沿著關係找到定義變更，確認比較期間是否跨過 7 月 1 日。

較可靠的回答會是：

目前不能直接下結論。WAU 在比較期間內更換了計算口徑，舊版以登入計算，新版要求完成核心操作。18% 的變化可能同時受到使用者行為與指標定義遷移影響，需要使用相同口徑重新計算。

圖沒有替 Agent 回答問題。

它提供的是一條檢查路徑，提醒 Agent 不能漏掉定義、版本和來源。

同一套知識，兩種入口

人類和 Agent 可以共用相同的知識底層，但不必使用相同介面。

人類可以透過 Obsidian、Web 文件、Sigma.js、Git history 或 review dashboard 閱讀和修改內容。

Agent 則透過搜尋索引、metadata、graph relationships 和 source retrieval 使用同一批知識。

無論從哪個入口進入，重要結論都應能回到原始來源。系統通常還要保存：

原始文件版本
source ID
content digest
頁碼或段落位置
claim-to-source mapping
有效時間
取代狀態
審核與發布版本

這些資訊可以放在 Markdown frontmatter、manifest、ledger 或外部 metadata store。

具體放在哪裡不是重點。

重點是 Wiki 頁不能成為無法再往回查證的終點。

結語

一套 LLM Wiki 可以從 Markdown 開始，但不會只靠 Markdown 完成。

Google OKF 提供輕量、可讀、可交換的知識格式。

Obsidian 讓人類閱讀和編輯知識頁。

Graphology 保存與分析 graph data。

Sigma.js 將 graph 顯示在瀏覽器中。

BM25、向量搜尋和 graph traversal 負責找到知識。

Harness 則規定 Agent 如何使用這些能力，並要求它在必要時回到原始來源驗證。

Sources
   ↓
Knowledge Compilation
   ↓
OKF Concepts
   ↓
Metadata + Links + Citations
   ↓
Search Indexes + Graph
   ↓
Harnessed Agent
   ↓
Grounded Answer

人類看到的是知識頁和關聯圖。

AI 使用的是內容、metadata、索引、關係、來源和規則。

兩者共用同一套知識底層後，Wiki 才不只是供模型搜尋的資料庫，也成為一個可以被閱讀、檢查、修正和長期維護的知識系統。