OKF 与 LLM Wiki 深度解析：从知识库到可编译知识操作系统
LLM Wiki 不是“给大模型看的百科页面”，而是把组织知识编译成一种人能读、机器能检索、Agent 能遍历、系统能验证的长期知识结构。
先澄清一个容易混淆的点：OKF 在开放知识领域通常指 Open Knowledge Foundation；而本文讨论的 OKF 是面向 LLM Wiki 的 Open Knowledge Format，可以理解为一种工程规范提案，用来约束 AI 原生知识库的目录、页面、元数据、引用、链接、校验和演进方式。
截至 2026-06-19，LLM Wiki 更像一个快速成型的系统范式，而不是已经被 W3C、ISO 或某个基金会正式标准化的协议。腾讯研究者在 2026 年 5 月的 LLM-Wiki 论文中，把它描述为一种“Retrieval as Reasoning”的检索范式：把原始文档编译成结构化 Wiki 页面，提供搜索、阅读和链接跟随工具，并用 Error Book 记录和修复知识构建错误。本文的 OKF 则是在这个方向上给出一套更可落地的格式规范。
一句话理解
传统 RAG 的核心对象是 Chunk：
原始文档 -> 切块 -> 向量化 -> Top-K 检索 -> 塞给 LLM
LLM Wiki 的核心对象是 Page：
原始文档 -> 编译 -> 结构化 Wiki 页面 -> 索引/链接/校验 -> Agent 搜索、阅读、遍历
OKF 的核心对象是 可校验的知识格式：
Page + Metadata + Facts + Sources + Links + Quality Rules + Change History
如果用操作系统类比：
| 层级 | 传统 RAG | LLM Wiki / OKF |
|---|---|---|
| 存储单元 | Chunk | Page / Fact / Source |
| 组织方式 | 扁平列表 | 目录、页面、双向链接、关系图 |
| 检索方式 | 一次性 Top-K | 搜索、阅读、跟链接、多轮充分性判断 |
| 质量控制 | 依赖分块和 rerank | 来源追踪、结构校验、冲突检测、错误账本 |
| 人类可维护性 | 弱 | 强，页面可读、可审、可编辑 |
| Agent 适配 | 被动上下文注入 | 主动工具调用和路径遍历 |
关键差异不是“有没有向量数据库”，而是知识是否被组织成可推理的结构。
为什么传统 RAG 不够用？
RAG 很适合回答局部事实问题，比如“某份合同的付款周期是多少”。但当问题变成下面这种形态时，扁平 Chunk 会越来越吃力：
- 跨文档比较：A 产品和 B 产品的 SLA 差异是什么？
- 多跳推理：某个功能的负责人是谁，他最近修改过哪些相关模块？
- 时序判断：这个政策在 2025 年和 2026 年有什么变化？
- 证据审计：答案里每个结论来自哪个原始来源？
- 知识治理：某条知识过期了，怎样找到所有依赖它的页面？
传统 RAG 的典型问题有三类。
1. Chunk 没有身份
Chunk 通常只是一个文本片段。它可能有 document_id、chunk_id、embedding，但它不是一个稳定的知识对象。
当文档更新后：
- Chunk 边界可能变化；
- 向量 ID 可能重建；
- 引用它的问答无法稳定追踪；
- 旧答案很难知道自己依赖的是哪一版知识。
LLM Wiki 则会把“实体、概念、流程、事件、决策”抽象成稳定页面。页面可以持续演进，来源可以追加，结论可以被修订。
2. Chunk 之间没有显式道路
向量相似度擅长“找相似文本”，不擅长“沿关系走路”。
例如用户问：
哪个团队负责上季度事故中被回滚的那项功能？
这个问题可能需要路径：
事故复盘 -> 回滚功能 -> 功能 RFC -> Owner 信息 -> 团队页面
向量检索可能命中事故复盘，却不一定继续找到 RFC 和团队页面。LLM Wiki 的页面链接则给 Agent 提供了可遍历路径：先读事故页，再跟随 rolled_back_feature，再跟随 owned_by。
3. Chunk 难以治理
RAG 管道常见的质量问题是静默发生的：
- 分块截断表格；
- 旧文档和新文档相互冲突；
- LLM 总结时丢掉关键限定条件；
- 页面之间出现孤儿链接；
- 答案引用了没有权限的来源；
- 同一实体有多个名字，索引没有合并。
LLM Wiki 要求这些问题被显式记录、验证和修复。它把知识库从“索引产物”升级成“长期维护的工程资产”。
LLM Wiki 到底是什么？
LLM Wiki 可以定义为：
一种面向 LLM/Agent 的结构化知识库。它把原始资料编译成稳定的 Wiki 页面，每个页面包含元数据、摘要、事实、来源引用、关系链接和质量状态；Agent 可以通过工具搜索页面、读取页面、跟随链接，并在证据足够时回答。
它有四个基本特征。
1. Human-readable：人能读
LLM Wiki 不应该只是向量库、三元组表或压缩摘要。它首先应该是人类可阅读的 Markdown/Wiki 页面。
原因很简单：知识库会出错。只要会出错，就需要人类能审查、修改、合并和回滚。
2. Machine-traversable：机器能走
页面不仅是文章，还要提供结构化元数据：
- 稳定 ID；
- 别名；
- 标签；
- 页面类型；
- 关系边；
- 来源 ID；
- 更新时间；
- 可信度；
- 权限级别。
这些字段让 Agent 能够有计划地搜索、筛选、跟随、比较和溯源。
3. Source-grounded：结论能溯源
每个事实都应该尽量指向来源，而不是只保留“模型总结过的话”。
claim -> source_id -> original artifact -> line/page/section/hash
没有来源的内容可以存在，但必须标记为 inferred、hypothesis 或 needs_review，不能伪装成事实。
4. Self-evolving：知识能演进
LLM Wiki 不是一次性离线生成结果。真实组织知识每天变化，因此它需要：
- 增量摄入；
- 页面合并；
- 链接修复；
- 过期检测；
- 冲突检测；
- 错误模式沉淀；
- 质量评分回归测试。
这也是 Error Book 的价值：把反复出现的问题变成下一轮编译的约束。
从 RAG 到 LLM Wiki 的架构迁移
这张图里最重要的变化是：索引不再是唯一产物，页面本身才是主产物。
向量库、BM25、图数据库仍然有用，但它们是 LLM Wiki 的访问层，不是知识本体。
OKF 要规范什么？
OKF 的目标不是发明一个复杂的新文件格式，而是给 Markdown Wiki 增加一层可验证的结构约束。
一个可落地的 OKF 规范至少要管八件事。
| 规范对象 | 要解决的问题 | 典型字段或规则 |
|---|---|---|
| 身份 | 同一知识对象如何稳定定位 | id、slug、kind、canonical_title |
| 来源 | 结论来自哪里 | source_id、locator、hash、retrieved_at |
| 事实 | 哪些内容是可断言知识 | claim、confidence、valid_from、valid_until |
| 链接 | 页面如何互相连接 | wikilinks、relations、backlinks |
| 目录 | Agent 如何浏览知识空间 | _index.md、topics、collections |
| 质量 | 页面是否可信可用 | review_status、coverage、staleness |
| 权限 | 哪些知识可被谁读取 | visibility、data_classification |
| 演进 | 知识如何更新和回滚 | version、change_log、supersedes |
这八件事合起来，才让知识从“文本”变成“可操作对象”。
OKF 推荐目录结构
一个最小可用的 LLM Wiki 可以这样组织：
knowledge/
okf.yaml
sources/
source-manifest.jsonl
raw/
2026/
q2/
incident-2026-05-18.pdf
api-rfc-0042.md
pages/
concepts/
llm-wiki.md
retrieval-as-reasoning.md
systems/
payment-risk-engine.md
people/
platform-team.md
decisions/
adr-0042-use-hybrid-search.md
procedures/
rag-quality-regression.md
indexes/
_index.md
aliases.json
graph.json
page-manifest.jsonl
quality/
error_book.yaml
validation-report.json
eval-sets/
multi-hop-qa.yaml
freshness-qa.yaml
okf.yaml
仓库级配置，定义版本、命名空间、页面类型、关系类型和质量门槛。
okf_version: "0.1"
namespace: "rainlib"
default_language: "zh-CN"
license: "CC-BY-4.0"
page_kinds:
- concept
- entity
- system
- decision
- procedure
- event
- dataset
relation_types:
- depends_on
- owned_by
- supersedes
- contradicts
- implements
- referenced_by
quality_gates:
require_source_for_facts: true
forbid_dangling_links: true
max_unverified_fact_ratio: 0.15
stale_after_days: 90
source-manifest.jsonl
来源清单。每一行是一个来源对象，便于增量处理和哈希校验。
{"source_id":"src:api-rfc-0042","title":"API RFC 0042: Hybrid Search","kind":"markdown","uri":"git://docs/rfc/0042.md","hash":"sha256:8f3a...","created_at":"2026-04-03","retrieved_at":"2026-06-19","visibility":"internal"}
{"source_id":"src:incident-2026-05-18","title":"2026-05-18 Payment Incident Review","kind":"pdf","uri":"s3://knowledge/incidents/2026-05-18.pdf","hash":"sha256:ab91...","created_at":"2026-05-20","retrieved_at":"2026-06-19","visibility":"restricted"}
page-manifest.jsonl
页面清单。它是搜索、权限、增量构建和链接校验的入口。
{"id":"okf:concept:llm-wiki","path":"pages/concepts/llm-wiki.md","kind":"concept","title":"LLM Wiki","aliases":["AI Native Wiki","Agent Wiki"],"tags":["llm","rag","knowledge-base"],"updated_at":"2026-06-19","review_status":"reviewed"}
{"id":"okf:decision:adr-0042-use-hybrid-search","path":"pages/decisions/adr-0042-use-hybrid-search.md","kind":"decision","title":"ADR 0042: 使用混合检索","aliases":["Hybrid Search ADR"],"tags":["search","rag"],"updated_at":"2026-06-19","review_status":"draft"}
OKF 页面格式长什么样？
OKF 页面建议使用 YAML Frontmatter + Markdown Body。Frontmatter 给机器读，正文给人和模型读。
下面是一个完整示例。
---
okf_version: "0.1"
id: "okf:concept:llm-wiki"
kind: "concept"
title: "LLM Wiki"
canonical_title: "LLM Wiki"
aliases:
- "Agent Wiki"
- "AI Native Wiki"
language: "zh-CN"
tags:
- llm
- rag
- knowledge-base
summary: "一种把原始资料编译为结构化 Wiki 页面，并通过搜索、阅读和链接遍历支持 Agent 推理的知识库范式。"
source_ids:
- "src:llm-wiki-paper-2605.25480"
- "src:wicer-paper-2605.07068"
relations:
- type: "extends"
target: "okf:concept:retrieval-augmented-generation"
- type: "related_to"
target: "okf:concept:graph-rag"
quality:
review_status: "reviewed"
confidence: "medium"
coverage: "introductory"
last_verified_at: "2026-06-19"
stale_after: "2026-09-19"
security:
visibility: "public"
data_classification: "public"
---
# LLM Wiki
## TL;DR
LLM Wiki 是一种面向 Agent 的知识组织方式：它将文档编译为结构化页面，页面之间通过显式链接连接，并通过工具接口让 Agent 可以搜索、阅读、跟随链接和检查证据是否充分。
## 定义
LLM Wiki 与传统 RAG 的区别在于，它不把知识主要表示为扁平 Chunk，而是表示为可维护的 Wiki 页面。每个页面应包含来源、事实、关系和质量状态。
## 关键事实
- `fact:llm-wiki:001`：LLM Wiki 将原始文档编译为结构化、互相链接的 Wiki 页面。
- 来源：`src:llm-wiki-paper-2605.25480#abstract`
- 可信度：`high`
- `fact:llm-wiki:002`：LLM Wiki 的访问方式应包括搜索、阅读和链接跟随。
- 来源：`src:llm-wiki-paper-2605.25480#method`
- 可信度：`high`
## 关系
- 扩展：[[okf:concept:retrieval-augmented-generation|RAG]]
- 相关：[[okf:concept:graph-rag|GraphRAG]]
- 依赖：[[okf:concept:source-grounding|来源扎根]]
## 适用场景
- 多跳问答
- 企业知识库
- 研发文档导航
- 合规和政策问答
- 长期个人记忆
## 限制
- 编译过程可能遗漏细粒度事实。
- 页面链接可能出现孤儿链接或错误关系。
- 对时效性要求高的知识需要强制过期和重验证机制。
## 变更记录
- 2026-06-19：创建页面，基于公开 LLM-Wiki 与 WiCER 研究整理。
这个格式有几个设计重点：
id稳定，不随文件路径变化；kind明确页面类型；aliases解决同义词和缩写；source_ids连接来源清单；relations提供机器可遍历关系；quality告诉 Agent 这页能否直接信任；- 正文中的事实条目保留来源定位。
页面类型应该怎么划分？
LLM Wiki 最大的设计误区，是把所有内容都写成“文章”。这样看起来整齐，但 Agent 很难选择阅读策略。
建议至少拆出七类页面。
| 类型 | 用途 | 示例 |
|---|---|---|
concept | 概念解释 | LLM Wiki、Hybrid Search、Source Grounding |
entity | 稳定实体 | 某个产品、团队、客户、供应商 |
system | 系统/服务 | 支付风控引擎、推荐服务、知识编译器 |
decision | 决策记录 | ADR、架构取舍、政策变更 |
procedure | 操作流程 | 发布流程、事故处理、质量回归 |
event | 事件记录 | 事故、发布、迁移、会议 |
dataset | 数据资产 | 指标口径、样本集、评测集 |
页面类型影响 Agent 的读法：
- 读
concept：关注定义、边界、与其他概念关系； - 读
decision：关注背景、备选项、取舍、后果； - 读
procedure：关注前置条件、步骤、回滚； - 读
event：关注时间线、参与者、影响和后续动作。
这比“所有页面都一个模板”更适合自动化。
事实、观点和推断必须分开
LLM Wiki 最怕的一件事，是把模型推断写成事实。
OKF 应该强制区分三类内容。
| 类型 | 含义 | 是否必须有来源 | 示例 |
|---|---|---|---|
fact | 来源直接支持的事实 | 是 | “API v2 在 2026-04-03 被批准。” |
interpretation | 对事实的解释 | 最好有 | “该决策主要优化查询延迟。” |
hypothesis | 待验证假设 | 不一定，但必须标注 | “召回下降可能来自别名索引缺失。” |
推荐写法：
facts:
- id: "fact:adr-0042:approved-date"
claim: "ADR 0042 于 2026-04-03 被批准。"
source_refs:
- source_id: "src:api-rfc-0042"
locator: "frontmatter.status.approved_at"
confidence: "high"
valid_from: "2026-04-03"
interpretations:
- id: "interp:adr-0042:latency-goal"
claim: "该决策的主要工程目标是降低跨文档问答的检索延迟。"
based_on:
- "fact:adr-0042:approved-date"
- "fact:adr-0042:benchmark-result"
confidence: "medium"
hypotheses:
- id: "hyp:search-quality:alias-missing"
claim: "近期召回下降可能与别名索引缺失有关。"
evidence_status: "needs_experiment"
owner: "search-platform"
这样做会增加编译成本，但能显著降低“知识库越用越自信、却越来越不可靠”的风险。
链接规范：别只写 Markdown 链接
普通 Markdown 链接只告诉你“跳到哪里”，不告诉你“为什么跳”。
LLM Wiki 需要两种链接：
1. 展示链接
给人看的链接：
参考 [[okf:decision:adr-0042-use-hybrid-search|ADR 0042]]。
2. 语义关系
给机器看的关系：
relations:
- type: "implements"
target: "okf:decision:adr-0042-use-hybrid-search"
evidence:
- "fact:payment-risk-engine:hybrid-search-rollout"
- type: "owned_by"
target: "okf:entity:platform-search-team"
evidence:
- "src:service-catalog#payment-risk-engine.owner"
关系类型应该被白名单化，否则知识图会失控。
常用关系包括：
depends_on：依赖；owned_by：负责人或团队；implements：实现某个决策；supersedes：取代旧页面或旧决策；contradicts：与某页面或事实冲突；derived_from：从来源或上游知识生成；part_of：属于某个系统或主题；related_to：弱相关，谨慎使用。
related_to 很容易变成垃圾边，应该限制比例。一个成熟 Wiki 里，强语义关系应该多于弱相关关系。
Error Book：让知识库越用越准
Error Book 是 LLM Wiki 的关键部件。它不是普通日志，而是“错误模式数据库”。
一个 Error Book 条目可以这样写：
errors:
- id: "err:2026-06-19:dangling-link:001"
status: "open"
severity: "high"
category: "dangling_link"
symptom: "页面 pages/systems/payment-risk-engine.md 链接到不存在的 okf:entity:risk-core-team。"
root_cause: "编译器根据来源中的团队简称创建了 WikiLink，但没有先查询 aliases.json。"
affected_pages:
- "okf:system:payment-risk-engine"
constraint: "创建 wikilink 前必须先检查 page-manifest.jsonl 和 aliases.json；无法确认目标时使用纯文本并加入 unresolved_links。"
verifier:
type: "deterministic"
command: "okf validate links"
created_at: "2026-06-19"
last_seen_at: "2026-06-19"
常见错误类别：
| 错误 | 表现 | 修复方式 |
|---|---|---|
| 孤儿链接 | 链接到不存在页面 | 查别名、建页面、降级纯文本 |
| 来源缺失 | 事实没有 source ref | 回到原文重提取，或标记为推断 |
| 事实冲突 | 两页对同一事实给出不同值 | 保留版本和适用时间，标记冲突 |
| 页面重复 | 同一实体多个页面 | 合并页面，别名重定向 |
| 摘要过度压缩 | 关键限定条件丢失 | 引入 probe 问题回归 |
| 权限泄漏 | 公共页引用受限来源 | 阻断发布或生成脱敏版本 |
| 过期知识 | 旧政策仍被回答引用 | 设置 valid_until 和 stale check |
Error Book 的核心不是“记录错误”，而是把错误变成下一次编译的规则。
LLM Wiki 的运行时工具接口
Agent 使用 LLM Wiki 时，不应该直接拿到整个知识库，而是通过受控工具访问。
最小工具集：
type WikiSearch = (input: {
query: string;
kind?: string[];
tags?: string[];
visibility?: string;
limit?: number;
}) => Array<{
id: string;
title: string;
kind: string;
summary: string;
score: number;
matched_by: Array<"title" | "alias" | "tag" | "content" | "relation">;
}>;
type WikiRead = (input: {
ids: string[];
sections?: string[];
include_sources?: boolean;
include_relations?: boolean;
}) => Array<{
id: string;
title: string;
content: string;
relations: unknown[];
source_refs: unknown[];
}>;
type WikiFollow = (input: {
id: string;
relation_types?: string[];
depth?: number;
}) => Array<{
from: string;
relation: string;
to: string;
evidence?: string[];
}>;
建议再加三个治理工具：
type WikiTrace = (factId: string) => {
claim: string;
sources: Array<{ source_id: string; locator: string; excerpt?: string }>;
};
type WikiReportError = (input: {
page_id: string;
category: string;
description: string;
evidence?: string[];
}) => { error_id: string };
type WikiSufficiencyCheck = (input: {
question: string;
visited_pages: string[];
collected_facts: string[];
}) => {
sufficient: boolean;
missing_evidence: string[];
suggested_next_queries: string[];
};
工具接口的关键规则：
- Agent 回答前至少要
wiki_read一个页面； - 对高风险问题必须返回事实来源；
- 不允许越权读取受限页面；
- 如果证据不足，应继续搜索或明确说“不足以判断”；
- 读到冲突事实时，必须呈现冲突和适用条件。
建设 LLM Wiki 的完整流水线
第 1 步：确定知识边界
不要一开始就说“把公司所有文档做成 LLM Wiki”。这会失败。
先选一个边界清晰、问题高频、来源稳定的领域：
- 某个产品线；
- 某套内部平台；
- 某类政策合规；
- 某个工程知识域；
- 某个客户交付项目。
定义三件事：
scope:
domain: "支付风控平台"
users:
- "平台工程师"
- "值班 SRE"
- "产品经理"
core_questions:
- "某个服务的 owner 是谁？"
- "某个告警的处理流程是什么？"
- "最近一次相关事故的根因是什么？"
- "某个架构决策为什么这么做？"
excluded:
- "客户隐私原始数据"
- "未脱敏的生产日志"
边界越清楚，页面类型、权限、评测集就越容易设计。
第 2 步：建立来源层
来源层是整个系统的地基。没有来源层，LLM Wiki 会退化成“模型写的百科”。
来源层需要保存：
- 原始文件；
- 来源 URI；
- 获取时间；
- 作者或系统；
- 哈希；
- 版本；
- 权限级别；
- 解析后的结构；
- 行号、页码或段落定位。
不要只存解析后的文本。PDF、网页、PR、工单、会议纪要都要能追溯到原始 artifact。
第 3 步：解析与规范化
不同来源需要不同解析器：
| 来源 | 解析重点 |
|---|---|
| Markdown | 标题层级、代码块、表格、frontmatter |
| 页码、标题、表格、图注、OCR 置信度 | |
| Git | 文件路径、commit、diff、作者、时间 |
| Issue/Ticket | 状态、评论、参与者、标签、时间线 |
| Slack/飞书 | 线程、回复关系、参与者、权限 |
| 数据表 | schema、字段解释、指标口径、血缘 |
解析输出不要急着进入 LLM。先变成统一的 Document AST，再进入编译器。
第 4 步：实体和主题识别
编译器需要知道“哪些东西值得成为页面”。
候选页面来源包括：
- 标题；
- 专有名词；
- 服务名；
- 团队名；
- ADR 编号；
- 指标名；
- API 名；
- 高频问题；
- 已有页面的 unresolved link。
实体识别不要完全依赖 LLM。服务目录、代码仓库、组织架构、数据目录等确定性系统应该优先。
第 5 步：页面规划
页面规划决定知识库的骨架。
输入：来源批次 + 现有 page-manifest + aliases + unresolved links
输出：新增页面、更新页面、合并页面、废弃页面计划
示例计划：
plan_id: "compile-plan-2026-06-19-001"
source_batch:
- "src:incident-2026-05-18"
- "src:api-rfc-0042"
actions:
- action: "update_page"
page_id: "okf:system:payment-risk-engine"
reason: "事故复盘包含新的依赖和告警流程。"
- action: "create_page"
page_id: "okf:event:incident-2026-05-18-payment-timeout"
kind: "event"
reason: "新的生产事故，需要独立事件页。"
- action: "update_page"
page_id: "okf:procedure:payment-timeout-runbook"
reason: "事故后 runbook 已更新。"
没有页面规划，LLM 很容易每次都创建新页面，导致重复和混乱。
第 6 步：页面编译
页面编译不是简单总结，而是结构化重写。
编译 Prompt 应该包含：
- 当前页面旧版本；
- 相关来源片段；
- 目标页面类型模板；
- OKF 字段规则；
- Error Book 中仍然 open 的约束；
- 禁止创建无来源事实；
- 禁止创建未验证 wikilink；
- 输出 diff 或完整页面。
核心原则：
只把来源支持的内容写入 facts；
推断必须进入 interpretations 或 hypotheses；
缺证据的问题进入 open_questions；
不确定链接进入 unresolved_links；
冲突内容进入 conflicts。
第 7 步：确定性校验
第一层校验应该由代码完成，而不是 LLM。
必做校验：
- YAML frontmatter 可解析；
- 必填字段存在；
id全局唯一；kind属于白名单；relations.type属于白名单；- 所有 wikilink 目标存在；
- 所有
source_id存在于 manifest； valid_from小于valid_until；- 页面权限不低于引用来源权限；
- 没有明显泄漏密钥、Token、PII。
第 8 步：来源扎根校验
第二层校验要回答：
页面里的 claim 是否真的被 source 支持？
可以分三级：
| 级别 | 方法 | 成本 | 适用 |
|---|---|---|---|
| L1 | 字符串/结构匹配 | 低 | 日期、编号、owner、状态 |
| L2 | Embedding entailment 检索 | 中 | 摘要、解释性句子 |
| L3 | LLM verifier | 高 | 多句推断、冲突判断 |
高风险知识至少要 L2，关键决策和合规内容要 L3。
第 9 步：索引构建
LLM Wiki 通常需要多索引并存：
- 全文索引：标题、别名、正文；
- 向量索引：语义搜索；
- 图索引：关系遍历；
- 时间索引：版本、有效期、更新时间；
- 权限索引：可见性过滤；
- 来源索引：从 source 找到 page/fact。
不要迷信单一向量库。成熟系统往往是混合检索。
第 10 步：评测与回归
LLM Wiki 的评测不应该只看答案对不对，还要看路径对不对。
建议评测维度：
| 维度 | 指标 |
|---|---|
| 答案质量 | EM、F1、人工评分、LLM-as-judge |
| 证据质量 | 引用覆盖率、来源支持率、错误引用率 |
| 遍历效率 | 平均工具调用数、平均读取页面数、延迟 |
| 结构健康 | 孤儿页面数、孤儿链接数、重复页面数 |
| 新鲜度 | stale 页面比例、过期事实命中率 |
| 权限安全 | 越权召回率、脱敏失败率 |
| 演进能力 | 修复后错误复发率、Error Book closure rate |
一个很实用的评测集结构：
questions:
- id: "qa:incident-owner:001"
question: "2026-05-18 支付超时事故中，被回滚功能的 owner 团队是谁？"
expected_answer: "Platform Search Team"
required_pages:
- "okf:event:incident-2026-05-18-payment-timeout"
- "okf:decision:adr-0042-use-hybrid-search"
- "okf:entity:platform-search-team"
required_facts:
- "fact:incident-2026-05-18:rollback-feature"
- "fact:adr-0042:owner-team"
type: "multi-hop"
risk: "medium"
什么时候该用 LLM Wiki？
不是所有知识库都需要 LLM Wiki。
适合
- 知识会长期复用；
- 问题经常跨文档；
- 需要明确证据链；
- 页面本身要被人维护；
- 知识会不断更新；
- Agent 需要自主探索；
- 组织愿意维护质量规则。
不适合
- 一次性问答；
- 文档很少且结构简单；
- 更新频率极高但不需要历史；
- 只做关键词搜索；
- 没有任何来源追踪要求；
- 团队无法承担治理成本。
一个判断标准：
如果你的问题主要是“找一段相关文本”，RAG 足够。
如果你的问题是“沿着知识关系找证据”，LLM Wiki 更合适。
与 GraphRAG、LightRAG、知识图谱的关系
LLM Wiki 不等于 GraphRAG，也不等于传统知识图谱。
| 方案 | 核心表示 | 优点 | 局限 |
|---|---|---|---|
| RAG | Chunk | 简单、通用、上线快 | 多跳和治理弱 |
| GraphRAG | 实体/社区/摘要图 | 全局主题和关系聚合强 | 页面可读性和事实追踪不一定强 |
| 传统 KG | 三元组/本体 | 形式化强，可推理 | 构建成本高，覆盖叙述性知识难 |
| LLM Wiki | 结构化页面 + 链接 + 来源 | 人机共读，适合 Agent 遍历 | 编译质量和治理成本高 |
| OKF | 页面格式和治理规范 | 可验证、可迁移、可协作 | 需要工具链支持 |
最合理的生产架构通常是组合：
OKF Pages 作为知识主干
Graph Index 负责关系遍历
Vector Index 负责语义召回
BM25/全文索引负责精确匹配
Source Archive 负责证据追踪
Verifier 负责质量门禁
生产级架构参考
这个架构有三个关键边界：
- 来源层不可被编译结果替代：页面只是派生物，原始来源必须长期保留；
- 知识层以页面为主干：索引可以重建，页面和来源历史不能随意丢；
- 运行时工具必须受权限控制：Agent 读知识也要经过 ACL、脱敏和审计。
建设路线图
0 到 2 周：做最小闭环
目标不是平台化，而是证明 LLM Wiki 比普通 RAG 更适合某个场景。
交付物：
- 选定一个知识域；
- 收集 50 到 200 个来源；
- 定义 3 到 5 个页面类型；
- 写出
okf.yaml； - 生成 30 到 100 个页面；
- 实现
wiki_search和wiki_read； - 做 30 道人工问题评测。
不要一开始做图数据库和复杂 UI。先证明页面结构和答案质量有价值。
2 到 6 周：引入质量门禁
交付物：
- source manifest；
- page manifest；
- link validator；
- source validator；
- Error Book；
- 基础 CI；
- 别名表；
- 冲突页面列表；
- 评测集扩展到 100 到 300 题。
这个阶段的目标是让知识库可以持续更新，而不是一次性生成。
6 到 12 周：平台化
交付物：
- 增量编译；
- 权限过滤；
- 多索引检索；
wiki_follow和wiki_trace；- 人工审阅工作台；
- stale fact 检测；
- 版本快照；
- 业务系统接入。
此时可以把它从实验工具升级为团队基础设施。
12 周以后：知识操作系统
长期方向：
- Agent 自动提出页面修订；
- 人类审批高风险变更；
- 高频问答自动沉淀为 FAQ 或 procedure；
- 事故、PR、ADR 自动关联；
- 评测失败自动打开 Error Book；
- 领域专家只处理冲突和高价值页面；
- 知识覆盖率成为工程健康指标。
编译 Prompt 模板
下面是一个可直接改造的页面编译 Prompt 骨架。
你是 OKF Page Compiler。你的任务是根据来源资料和现有页面，生成或更新一个符合 OKF v0.1 的 Markdown 页面。
硬性规则：
1. 只把来源直接支持的内容写入 facts。
2. 推断、解释、假设必须分别放入 interpretations 或 hypotheses。
3. 每个 fact 必须包含 source_ref。
4. 不得创建不存在的 wikilink；不确定目标写入 unresolved_links。
5. 不得删除旧页面中的有效事实，除非新来源明确 supersedes。
6. 如果来源之间冲突，保留冲突并写入 conflicts。
7. 输出必须是 YAML Frontmatter + Markdown Body。
页面类型：
{page_kind}
现有页面：
{old_page}
可用页面清单：
{page_manifest}
别名表：
{aliases}
来源片段：
{source_chunks}
Error Book 约束：
{open_constraints}
请输出更新后的完整页面。
生产环境中，建议让模型输出结构化 JSON patch，再由代码渲染 Markdown。这样更容易做字段校验和 diff 审查。
CI 校验清单
把 OKF 当成代码仓库来管理，CI 至少应该检查：
[structure]
- frontmatter parse
- required fields
- valid page kind
- unique id
- valid relation type
[links]
- wikilink target exists
- relation target exists
- alias points to one canonical page
- no circular supersedes chain
[sources]
- source_id exists
- source hash exists
- source visibility >= page visibility
- every fact has source_ref
[quality]
- stale_after not expired
- confidence present
- review_status valid
- unresolved_links below threshold
[security]
- no secret patterns
- no restricted source in public page
- PII policy check
[eval]
- golden questions pass
- source support score above threshold
- no regression on critical questions
如果知识库是给生产 Agent 使用，CI 不通过就不应该发布新快照。
常见坑
1. 把 LLM Wiki 当成“自动写百科”
这会制造大量漂亮但不可靠的页面。正确目标不是写得像百科，而是把来源知识编译成可验证结构。
2. 页面过大
一个页面如果覆盖太多主题，Agent 会读到注意力稀释。建议按实体、决策、流程拆页，再通过关系连接。
3. 页面过碎
过度拆分会导致遍历成本太高。判断标准是：一个页面是否代表一个稳定的知识对象。如果只是某个段落，就不一定需要独立页面。
4. 弱关系太多
到处都是 related_to，图就没有信息量。关系应该尽量有语义和证据。
5. 没有过期机制
知识不是越多越好，过期知识会主动伤害答案。每个页面和关键事实都应该有 stale 策略。
6. 权限后补
权限必须从来源层开始继承。不要先生成公共页面，再尝试从正文里删敏感内容。
7. 只评测回答，不评测证据
答案对了但证据错了，在生产系统里仍然是失败。LLM Wiki 的价值就是可追踪，评测必须覆盖证据链。
一个最小实现可以怎么写？
如果只做 MVP，可以用非常朴素的技术栈：
| 模块 | MVP 选择 |
|---|---|
| 页面存储 | Git + Markdown |
| 来源清单 | JSONL |
| 全文索引 | SQLite FTS 或 Meilisearch |
| 向量索引 | pgvector / Qdrant / LanceDB |
| 图索引 | JSON + NetworkX，后续再换 Neo4j |
| 校验 | Node/Python CLI |
| Agent 工具 | HTTP API 或 MCP Server |
| 审阅 | Pull Request |
MVP 的关键不是技术复杂度，而是格式纪律：
每个页面有 ID
每个事实有来源
每个链接可校验
每次更新可 diff
每个错误可沉淀
每次发布可回滚
做到这些，哪怕没有炫酷 UI，也已经比很多“向量库 + 聊天框”的知识库更可靠。
OKF 的成熟度模型
| 等级 | 状态 | 特征 |
|---|---|---|
| L0 | 文档散落 | 文档存在，但没有统一索引和来源清单 |
| L1 | 可检索 | 有 RAG 或全文搜索，但以 Chunk 为主 |
| L2 | 可阅读 | 有 Markdown/Wiki 页面，人能维护 |
| L3 | 可追踪 | 页面事实连接来源，支持引用追踪 |
| L4 | 可遍历 | 页面有稳定关系，Agent 可多跳检索 |
| L5 | 可验证 | CI 校验结构、来源、权限和评测 |
| L6 | 可演进 | Error Book、增量编译、自动修复和回归 |
| L7 | 可治理 | 权限、审计、版本、组织流程完整接入 |
大多数团队不要直接追 L7。先从 L2/L3 做起，补上来源追踪，再引入遍历和 Error Book。
总结
LLM Wiki 的本质，是把知识管理从“检索一段文本”推进到“维护一个可推理的知识结构”。
OKF 的本质，是给这个结构加上工程约束：
- 页面有稳定身份；
- 事实有来源；
- 链接有语义；
- 权限可继承；
- 质量可校验；
- 错误可复用；
- 更新可回滚；
- Agent 可通过工具遍历。
如果说传统 RAG 是给 LLM 接一台搜索引擎，那么 LLM Wiki 是给 Agent 接一个知识操作系统。搜索仍然重要，但它只是入口；真正的价值在于页面、关系、证据和演进机制共同形成的长期复利。
参考资料
- Open Definition, Open Definition 2.1, 2015.
- Haoliang Ming, Feifei Li, Xiaoqing Wu, Wenhui Que, Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki, 2026-05-25.
- Juan M. Huerta, WiCER: Wiki-memory Compile, Evaluate, Refine Iterative Knowledge Compilation for LLM Wiki Systems, 2026-05-08.