LLM-Wiki总论：把知识库编译成 Wiki，再把检索权交给 LLM——彻底搞懂LLM Wiki第一篇

30 秒判断 ：这是一篇总论，材料是一篇论文（arXiv 2605.25480）＋ Karpathy 的一篇 gist（llm-wiki.md）。一句话：LLM-Wiki 换掉的不只是检索算法，而是"知识库什么时候被组织、由谁来组织" ------把组织工作前移到编译期，把检索权交给 LLM。方向我认为是对的，但它还不具备被直接依赖的条件：最基础的那一步（知识编译），两篇材料都语焉不详。

适合谁读：读完（或读过我那个 GraphRAG 系列）之后想看清"下一个范式长什么样"的人；正在给知识库选型的人；以及打算自己搭一套"预编译＋ agent 检索"的人。

结构速览：§1 为什么该把检索权交给 LLM；§2 为什么先编译；§3 编译成什么（三个要求如何推出 Wiki）；§4 为什么纠错是必选；§5 它和 GraphRAG 的差别到底从哪来；§6 落地前要验什么、拿什么验。前五节是"读通"，§6 是"还没证"------后面几篇验证文分别对应 §6 的三节。

证据标记 ：📎 原文 （论文／gist 原话）· 📄 源码／README （核过的实现）· ✅ 实测 （本项目的实验）· 🤔 推断（会明确标出）。

0. 先把两个对象钉死

① 论文 ：《Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki》。arXiv 2605.25480，2026-05-25；作者 Haoliang Ming／Feifei Li／Xiaoqing Wu／Wenhui Que，WeChat, Tencent Inc.。它给了三件东西：Wiki 化编译 、组合式检索 （两个工具 wiki_search ／ wiki_read）、Error Book （错误账本）。评测用三个多跳问答基准各取前 500 例，编译与推理用 GLM-5.1。它没有开源代码 ------全文 open-source／code is available 出现 0 次。

② Karpathy 的 gist ：llm-wiki.md，自称 "idea file"。三层：原始材料不可变／wiki 由 LLM 全权生成／schema 是那个关键的配置文件、由人和 LLM 共同演化；三个操作：Ingest（读进一个源，可触及 10--15 个页面）、Query、Lint（体检：孤儿页、缺页、缺交叉引用）。

两者是同一件事的两端：论文把 Karpathy 的构想做成了可评测的系统，Karpathy 那篇是这个构想的原始形态。 所以后面凡是"机制怎么写"，主要看论文；凡是"这套东西该长什么样"，两边都要看。

1. 为什么要换思路：把检索自主权交给 LLM

驱动力来自一个朴素的观察：知识库上的问题五花八门，固定流程应付不了。

"固定 top-k 检索＋一次生成"擅长局部事实------答案就在少数几段里，按相似度捞得准。但问题一旦变成：

全局的：整份语料在讲什么？
多跳的：A → B → 答案，中间隔了两跳；
枚举的：这一类都有哪些？
比较的：这两者有什么异同？

......"先取固定几段、再一次性回答"就失灵了------因为在读之前，系统根本不知道该看哪几段。全局问题没有判别性关键词；多跳问题的中间实体，往往不是问题里出现过的词。

而 LLM 有推理能力 ，可以自己承担"先看什么、下一步看什么、够了没有"这些判断。于是把检索自主权交给它：检索不再是一次性的取数动作，而是由推理驱动的一段过程 ------论文管这叫 retrieval-as-reasoning，并给了两条典型路线：search-first （从实体出发锚定）与 browse-first（开放式与枚举型：先看全景，再逐级下钻）。

论文自己有两句话，正好是这条推理的两端（📎 原文）：

该做： "The bottleneck lies in how knowledge is organized and exposed to the agent, not merely in the retrieval algorithm." （瓶颈在"知识怎么被组织、怎么暴露给 agent"，而不只是检索算法）
能做：agent 已经具备 ReAct 式的"推理＋行动"工具调用循环，可以把"搜索／阅读／跟随链接／判断够了没有"拆成原子动作再组合。

一个现成的反例就在旁边 ：GraphRAG 的 Global Search 默认检索行为 仍是确定性的------取哪些社区报告，由调用方交给它的 community_level 决定（命令行默认 2，语义是 level ≤ N；只有传 None 才是全层不过滤），然后把这批报告扫一遍、map-reduce 出答案。也就是说， "该看多细"这个判断被外包给了调用方 ，而不是交给 LLM。（GraphRAG 另有 Local／Basic／DRIFT 等模式，只有 Dynamic 把"某个社区要不要"这一步让给了 LLM。详见层级参数篇与 Local 与 DRIFT 篇。）

2. 为什么要先编译：原始文本也能给自主权，编译只是更好

先把话说实：不编译也能做自主检索。 把原文直接交给 agent、给它搜索与阅读的工具，它照样能多轮探索------已有的 agentic RAG 就是这么干的。所以编译不是"能不能自主检索"的必要条件，它换来的是三件增量：

省掉"每次重新发现" 。原始文本是平的，每一次提问都要从头把散落的信息找出来、临时拼起来；编译把这些工作一次性提前做完。
提供原文里不存在的指针 。原文只有顺序，没有"这两段在讲同一件事"的显式提示；编译把关系与指针物化出来，遍历才有依托。
把成本前移、摊薄查询期 。论文的说法是 "Front-loading organization to compile time" ；Karpathy 的说法更直白： "the LLM is rediscovering knowledge from scratch on every question. There's no accumulation." ------编译之后，知识是累积（compounding） 的，而不是每次重算。

第 3 条同时也意味着这是一笔提前下的注：一次性的编译开销，要靠之后反复提问才摊得平。这一点在 §6 会变成一条具体的验证项。

3. 编译成什么：三个要求推出"Wiki"

编译的产物该长什么样？把约束列出来，答案几乎是唯一的。

3.1 要求一：得能承载知识------借 KG 的核心概念，不背它的形式包袱

承载知识，目前已知较好的框架就是知识图谱那一套：实体＋关系 。但它很重------本体、类型系统、推导规则、一致性约束都要人定义和维护。所以只借它的核心概念，不借它的形式约束。 论文列举的那些页面（摘要、实体、概念、对比分析、概述、综合介绍），大体可归成三类：

语义类	LLM-Wiki 里的形态	GraphRAG 里的形态
实体（名词单位）	实体页（标题＋ aliases 别名）	实体表（name ＋ type ＋ description）
关系（谓词，含被实体化的）	链接＋其后的关系说明（如 `-- father of John V`）＋对比分析页＋实体页里的结构化陈述	关系表（source → target ＋ description）
聚合体（把一组内容压成一个单位）	摘要页、概述页、主题／综合介绍页	社区报告（层级摘要）

一句要紧的澄清： "摘要／概述"不是"被实体化的谓词"，而是一元聚合 ------它把一组内容压成一个可读单位，并不对应任何具体关系。这个区分不是抠字眼：聚合体的粒度是"机制给的"，不是"语义给的" （在 GraphRAG 那边实测：L2 社区 100% ≤ 10 个实体，粒度来自 max_cluster_size=10 这个算法常数）。

这个选择有一个前提：推断这一步已经由 LLM 承担了。 本体、类型系统、推导规则在传统 KG 里是承重结构 ------它们管的是"两个概念能不能这么连""能不能从已知事实推出新事实""数据里有没有自相矛盾"，没有它们，机器既推不动、也检不出。而在 LLM-Wiki 这里，这些判断由 LLM 直接在自然语言上完成（和 §1 说的"LLM 有推理能力"是同一条）。形式层于是不再是承重的，可以省。

所以"只借概念"不是图省事的简化，而是把这一层的职责换了个承担者 ：从形式系统换成了模型本身。代价也要认------没有本体、没有推导规则、没有全局一致性保证，一致性得靠"编译期校验＋纠错机制"来兜（这正是 §4 的由来）。

3.2 要求二：得能支撑自主检索，尤其是"遍历"

自主检索要能边走边看，就需要三样：可寻址的单位 （能指名某个东西去看）、显式的指针 （能从一个走到另一个）、全景入口（不知道从哪下手时先看目录）。这三样正好落在"页面（标题即地址）＋双向链接（带关系说明）＋目录索引"上：

检索期需要什么	组织上就得提供什么	出处
已知实体的局部事实	可寻址的实体页（标题唯一＋ aliases 兜别名）	📎 论文 §6；Karpathy 的 entity pages
关系跟随／多跳桥接	显式链接（页与页的双向 wikilink，成为可跟随的指针）	📎 论文 §6；附录 E "bidirectional wikilinks expose explicit traversal paths"
证据枚举／跨文档聚合	主题页与聚合页（把一组内容压成可列举、可综览的单位）	📎 论文 §6
开放式探索（不知道从哪下手）	目录层（`index.md` ：先看全景，再逐级下钻）	📎 Karpathy： "the LLM reads the index first to find relevant pages, then drills into them."

结构上真正的区别是：链接提供"任意关联" ------跨目录、跨层级、任意两页都能连，所以桥接与跨文档聚合靠链接走，而不是靠翻层级。两条限定也要记住：

① 链接是 LLM 生成＋校验 出来的，完备性与正确性都没有保证 ------悬空链接（dangling link）是论文实测里第一大错误类，占检测到错误的 29.1--63.8% ；

② wikilink 本身不带类型参数，关系靠紧跟其后的自由文本说明 承载------所以人读得懂、机器能查出"悬空"，但不能按关系类型机检／过滤。（对照 GraphRAG：边的端点在关系表里可机读、可筛选，但 description 同样是自由文本。）

3.3 要求三：大规模编译必然用 LLM ⇒ 产物必须"人可读"（两条理由）

语料一大，"靠人写编译产物（分类、摘要、关联）"的成本不可承受，用 LLM 编译是必然选择 ；而 LLM 会出错（§4 详述），所以必须有人在环中检查 ；要让人能检查，产物就得是人能直接读的------这是"人可读"的第一条理由。

还有第二条理由，而且它跟问答没关系：知识库的定位本身就包含"给人读"。 人会直接翻阅、检索、核对这份编译产物（wiki 这种形态存在的意义正在于此），而不是只把它当成问答管线里的一段中间数据。对组织级／个人知识库来说， "能被人直接读懂、直接查"本身就是交付物的一部分 。所以"人可读"不只是为了让纠错流程跑得通而做的被动妥协，它是一个独立的产品需求。

三个要求合起来是个交集：机器可寻址、可遍历（要求二）∩ 人可以直接阅读（要求三）＝以页面＋链接为载体的文本 ------也就是 Wiki。论文自己的措辞正是这个交集（📎 原文）： "human-readable and machine-traversable substrate" 。

顺带回答"为什么不是别的形态"：

只有"遍历"这一条，会推出图／三元组（机器友好，人不好读）；
只有"人可读＋人检查"这一条，会推出普通文档（人友好，但没有指针、不能遍历）；
两条的交集，才唯一指向"页面＋链接" 。Karpathy 的说法很直白： "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." ------wiki 是给人读、也给机器跑的同一份东西。

4. 用 LLM 编译，错误是必然的 ⇒ 纠错机制是必选

LLM 写出来的页面不会天然自洽。论文实测的错误分布，是这条推理最硬的证据 ：在它统计的七类系统性错误里，悬空链接占检测到错误的 29.1--63.8% 、malformed references 占 18.9--28.5% ------结构类错误是第一大类；此外还有内容类的：无据断言、跨页矛盾。

错误类别	典型形态	谁来查
结构类	悬空链接、页面不完整、引用格式错、未见覆盖、索引不一致	确定性校验（代码）
内容类	无据断言、跨页矛盾	与源对齐的 LLM 校验＋跨页一致性检查

它的解法是 Error Book ：把"反复出现的错误"沉淀成约束规则 ，注入后续编译提示词，并驱动修复。五个阶段------发现 → 归因 → 写成规则 → 注入编译提示词 → 定期复验并关闭 ；落盘为 error_book.yaml，每条含现象／根因／约束规则／验证方式／状态（open／closed）。修复分两层：代码层 跑确定性修复（悬空链接、格式、索引不一致），LLM 层处理需要推理的问题（缺页、摘要不完整、无据断言、跨页矛盾），定稿前再跑三轮"代码修复 ↔ LLM 修复"回环收敛。

顺便说清一件容易被误读的事： "人必须在环"不等于"人得逐条读" 。它能成立，靠的是把错误分流 ------结构类由程序确定性查出、也能自动修；留给人的只有内容类，而内容类本来就只能抽检。所以"人可读"实际买到的是可审查性（inspectability） ，而不是"人工逐条验收"。

5. 它和 GraphRAG 的差别，来自各自锚定的目标不同

一句话概括两者关系：语义层同构、机制层不同构 。都用"实体---关系"的骨架来装知识，区别只在形态；机制上最要紧的差别是------ "可读的那一层"和"可遍历的那一层"，是不是同一层 。这两个轴来自论文自己的判据（📎 原文： "...whether the resulting knowledge base exposes explicit, traversable structure that an agent can search, read, and traverse" ）：

线	产物	人读	机器遍历
GraphRAG	图（实体＋关系）＋社区报告（层级摘要）	△ 可读与可遍历不在同一层：报告是文本、可读；图那一层不天然给人读	△ 能但受限：可沿社区上下级行走，也可沿实体的关系邻域寻址；但缺"页面级稳定寻址单位"，跨社区／跨源也没有任意关联的边
LLM-Wiki	页面＋链接＋索引	✅ 能（markdown 页天然可读）	✅ 能（页面可寻址＋链接可跟随＋索引可下钻）

这条差别不是偶然的，根源是两者锚定的目标不同：

GraphRAG 锚定的是"把一份语料上的全局性问题答好" ------所以它要的产物天然是跨文档的多粒度抽象 ：社区层级就是给"把该层报告扫一遍、map-reduce 出答案"准备的。至于"哪些内容该算一个主题"，它交给了图的结构 ------用层次 Leiden 在实体图上按边划分社区（无向划分，📄 源码核过），而不是让 LLM 去判主题。这个目标在索引期就被押注进去了：实体类型表、报告模板那一组提示词，正是"目标已知"这个前提的产物。
LLM-Wiki 锚定的是"把检索主动权交给 LLM、面向事先不知道的问题" ------所以它要的产物必须是可寻址、可跟随的单位 ：页面＋链接是从这个目标直接推出来的；而目标本身以可编辑的 schema 形式留在外面，由人和 LLM 一起演化。

回到 §1 那个反例：这正好解释了为什么 GraphRAG 会把"该看多细"交给调用方------它的目标把粒度押在索引期的全局结构上，查询期只需选层；而 LLM-Wiki 把判断交给 LLM，因为它的前提就是"问题事先不知道"。

一句话收口：GraphRAG 回答"目标已知时怎么省"，LLM-Wiki 回答"目标未知时怎么找"。

6. 落地前要验什么：三个机制，三种不同的确定性

读到这儿，机制是通了；但它能不能被依赖，是另一回事 。三个机制的信息密度差得很远：知识编译 是落地时最基础的一环，却也是两篇材料讲得最含糊的一环；错误处理 机制清楚，要验的相对少；检索给的数据最详细、机制也好理解，但有一个数字反直觉。后面几篇验证文就按这个顺序来。

6.0 实验台：WeKnora

要验就得有台子。我们选的 WeKnora （Tencent/WeKnora，Go，v0.8.2，31.2k★，2026-09 仍在高频迭代）------理由是它的三种模式共用同一套知识管线，正好一条腿踩住下面三件事：

待验	WeKnora 里对应的能力（📄 README 口径）
知识编译	Auto Wiki ：把知识库文档里的 people／products／concepts 抽成带来源引用的页面、按目录组织；知识图展示页面间关系；页面可直接编辑，每次改动都能回滚
增量／删除	上述的编辑＋diff＋回滚，加知识库目录树、chunk 编辑与修订、文档解析的分阶段时间线
错误处理	只有"人工纠错"这一半（编辑／diff／回滚）；没有 Error Book
检索	Agent 模式＝ReAct agent 在知识库与工具上跑多步；另有 hybrid search（关键词＋向量）＋ rerank ＋ GraphRAG（Neo4j）可当对照臂
计时口径	Langfuse 逐步追踪推理、工具调用与 token 用量------正好补上论文时延表缺的口径

三条得认的限制：① 它不是论文的实现 （论文无代码），结论属于"WeKnora 的 wiki 模式"，不是"论文方法"；② 错误处理只能验人工兜底那半 ；③ 迭代很快，实验必须锁版本号 ，README 承诺的能力要核过代码再用。（另一个候选 nashsu/llm_wiki 更贴 Karpathy 的描述，但检索侧没有 agent 工具循环与可观测性，我们把它留作"编译实现对照"。）

6.1 知识编译：最不清楚、也最基础

这是把原始语料变成 wiki 的那一步，后面检索全靠它的产物；而两篇材料恰恰在这里最含糊------论文没给编译提示词原文 、没写 SelectPages 的选择机制 、没有命名／合并规则；Karpathy 那边则把这一层整个交给 schema，只说"和 LLM 一起演化"。要验的三件事，正好对应编译面临的三种输入变化：

全量怎么编 ------从 schema／目标出发的三步：视角选择 （schema 定下什么该进 wiki）、抽取（页面与陈述从哪些源、以什么粒度产出）、合并（同一实体的别名、同一主题的多页：归并还是并存）。
增量怎么处理 ------追加新源后页面级更新是否真局部？目录／索引／命名冲突这些全局结构谁维护？改一次 schema 再追加，先量新旧页面混存的比例 与跨代链接的完整性 ，再对同一批问题各问一次，看答案会不会自相矛盾。（论文 Limitations 自认索引会失控、stale-fact 是 future work。）
删除怎么处理 ------删掉一个源，量悬空链接数、孤儿页数 ，并检查答案里是否还在引用被删内容；同时要区分"知识作废 "与"来源撤回"两种语义。

已知的对照 （📄 论文 Limitations ＋ ✅ 我们的 GraphRAG 实测）：GraphRAG 的增量是追加式（社区不重划、度数不重算）⇒ 结构分代 ，同一份语料追加两轮后根节点数 9 → ＋6 → 15 ；删除则是"删除被忽略 "（退出码 0、索引与删除前完全一致）⇒ 只剩全量重编译一条路。这两条正是"LLM-Wiki 在增量与删除上逻辑更好"的依据，但也仅止于逻辑上------它没有这些问题，是因为它没有全局算法，不是因为有谁验证过删除协议。

6.2 错误处理：机制清楚，要验的少

论文给了错误分布（悬空链接占检测错误的 29.1--63.8%、malformed refs 18.9--28.5%）与五阶段流程，做法直白：把反复犯的错写成约束，喂回下一轮编译 。所以它更像"要不要照做"，而不是"怎么做"。要留意的只有两点：错误率是否随迭代收敛 ，以及这套规则换一份语料还管不管用------规则是从本语料的错误里长出来的，跨域迁移没有先验理由。

6.3 检索：机制好懂，但有一处数据反直觉

机制层面不难理解：检索权交给 LLM，靠两个工具加遍历，"下一步看什么"由模型自己决定；它依赖的就是 LLM 的推理能力------所以"效果好不好"与"模型强不强"是同一件事。论文在这一块的实验也最细（三个多跳基准各 500 例，另按跳数分层）。

但耗时这一项，按结构算它一定是慢的。 稠密向量检索是"一次检索（毫秒级）＋一次生成"；而 LLM-Wiki 走的是串行推理循环 ------工具调用预算 T_max=15（连续 3 次空搜索即停，且回答前至少得读一次页），而每次工具调用前后都要过一次 LLM ，所以是十几轮串行推理。多出来的全是实打实的开销，而且轮与轮之间有依赖，并行摊不掉 。所以看到论文附录 G 的时延表里它在 HotpotQA 上是 14.9 秒/题 、快过稠密检索的 16.3 秒 （MuSiQue 27.1 vs 26.9、2WikiMHQA 15.9 vs 15.6 反而略慢；正文那句 "comparable to or faster than BM25 and Dense RAG" 比数据要宽）时，要解释的不是"它为什么慢"，而是"它凭什么能快到这个程度" 。

只有三种可能，而且都能验：① 每轮调用极短 ------一轮只读一页、只输出几十个 token，轮数多但每轮便宜；② 最后那次生成比稠密检索短得多 ------生成是自回归的，稠密检索要塞 5--10 个 chunk 原文，模型容易写得长；③ 测量条件本来就不同 ------同一个表里 GraphRAG 是更强的旁证 ：它是 map 上百份报告再 reduce，结构上比谁都贵，却在三个基准上都最快（14.0／13.9／10.8 ）⇒ "同等条件"这个前提本身就值得怀疑。这张表口径缺四样 ：端点定义（首 token 还是总时长）、测量条件（并发／顺序／重试／硬件或服务）、每方法输入与输出 token 数、失败样本怎么算------全文 A100／GPU／throughput／concurrency／output tokens 出现次数全是 0 。所以它现在的身份是 "待解释的数据"，不是证据。

要验的是：① 逐轮记账 ------固定模型与并发，把轮数、每轮的输入／输出 token、各段耗时都记下来，这是唯一能回答"时间到底花在哪"的口径；② "优势随跳数增长"这个趋势换一份语料能否复现（不求复现绝对分数）；③ 多路径 vs 单一路由键------wiki 允许多条链接路径到达同一实体，推断是"召回更鲁棒、但枚举更难穷尽"，这条怎么测。

附：材料、核对手册与系列导航

一手材料（全部本地可查，仓库里也有快照）：

论文：arxiv.org/abs/2605.25...（HTML 版含附录 A--H；页面 schema 在附录 E、编译 Algorithm 1 在附录 D、时延表在附录 G）
Karpathy 的 gist：gist.github.com/karpathy/44...
实验台：github.com/Tencent/WeK...（核至 v0.8.2）

前情（GraphRAG 系列，按阅读顺序）：

本系列后续（验证篇，按 §6 的三节排）：

知识编译篇------在 WeKnora 上跑全量编译，量视角选择／抽取／合并，以及增量的结构分代与删除的引用完整性；
错误处理篇------Error Book 那半论文没给实现，就退一步量"人工兜底"的可用性与成本；
检索篇------同一份语料、同一个模型，把 wiki-agent 与稠密向量、GraphRAG 摆在一个计时口径下，先把那张时延表重做一遍。

本文的性质 ：这是一篇总论，基于论文与 gist 原文、以及我们自己在 GraphRAG 线上的实测；凡标 🤔 的是推断，未做实验的部分会明确写"待验"。完整记录与代码：github.com/lipeidonggz...

如果你正在给知识库做选型，欢迎把你那份语料的规模、提问类型分布、以及一次全局问题要花多久贴到评论区------这三样一摆出来，就知道该走预编译还是查询期现算。