LLM Wiki 深度解析

💡 核心论点： LLM Wiki 不是 RAG 的新变种，而是把「知识综合」从查询阶段前移到摄取阶段——每来一篇资料就立刻编译成结构化、可导航的知识页面，让知识成为一份会越用越值钱的长期资产。

1. 范式定位：不是 RAG 变种，而是编译型知识工程

2026 年 4 月初，Karpathy 在推特提出 LLM Wiki。很多人第一反应是「又一个 RAG 变种」，但这个理解是错的。

• RAG 是查询驱动：每问一次就现场检索、现场拼块、现场综合，答完即散，下次类似问题从头再来一遍。
• LLM Wiki 反过来：资料进来时模型立刻把它编译成一层结构化、可导航、可阅读的中间知识页面；真正要用时，你查的是已被反复消化、交叉引用过的知识资产。

更准确的定义：LLM Wiki 是一种以开放文件为载体、以 Schema 为约束、以增量编译为机制的知识工程系统。它不替代 RAG，而是补上 RAG 不擅长的「长期沉淀」那部分。RAG 仍有价值——更适合退到大规模召回层，或在 ingest 前帮 Wiki 找到该读的原始材料。

技术脉络： 2020 年 RAG 解决「外部知识怎么接进生成模型」；2024 年 GraphRAG 把全局主题、社区与关系提取出来；2026 年 4 月 LLM Wiki 把重点从「查询时怎么找答案」前推到「摄取时怎么把知识编译成长期资产」。

2. 三个现实问题

让 LLM 维护 Wiki 本身不新鲜（Notion AI、Obsidian 插件早能做）。真正的创新在于它点破了三个现实问题：

1. 聊天很强，但默认不留资产。 第 17 次对话里的精彩判断，到第 18 次模型已经忘了。这是产品形态之过——Chat 天然把一切丢进对话流。LLM Wiki 把「好答案必须回写」从偶然行为升级成制度。
2. 传统笔记维护成本太高。 Obsidian 最难的不是写，而是维护：链接、分类、查重、发现矛盾、建对比页——这些耗人工的「知识文员活」恰好是 LLM 最擅长的。
3. RAG 每次都在重新发现。 同一份跨文档综合判断今天做一遍、明天又重做。LLM Wiki 把这部分成本前移：一次编译，反复使用。

3. 核心架构：干脆利落的三层切分

Karpathy 最大的贡献，是把整个知识系统切成三层，明确解决「谁负责什么」——很多 AI 知识系统崩掉不是模型不够强，而是原始材料、派生内容、操作规则全混在了一起。

层	职责	铁律
Raw Sources 原始材料层	PDF、会议录音、网页、代码目录等原始输入	不可变：进了 Raw 目录就不许 LLM 回头改，始终保持可追溯、可审计
Wiki 派生知识层	概念页、实体页、对比页、综合页、矛盾页等 LLM 消化产物	可不断被更新、被链接、被查询
Schema 行为约束层	决定页面怎么命名、何时新建、怎么引用来源、遇矛盾怎么处理	没有它 LLM 只是写作者，有它 LLM 才是知识库维护者

graph TD subgraph SCHEMA["Schema 行为约束层（操作系统）"] S1["命名规则 / 新建时机<br/>来源引用 / 矛盾处理"] end subgraph WIKI["Wiki 派生知识层（可更新·可链接·可查询）"] W1["概念页"] W2["实体页"] W3["对比页"] W4["综合页"] W5["矛盾页"] end subgraph RAW["Raw Sources 原始材料层（不可变·可审计）"] R1["PDF"] R2["会议录音"] R3["网页"] R4["代码目录"] end RAW -->|"ingest 编译"| WIKI SCHEMA -.->|"约束"| WIKI WIKI -->|"query 检索"| USER["用户 / Agent"]

4. 运行控制面与页面类型

光有 Raw / Wiki / Schema 三层还不够。成熟的公开实现都会长出一组「运行控制面」文件——成熟的 LLM Wiki 不是「有页面」，而是「有运行面板」。

4.1 控制面文件

• index.md（内容导向）：列出所有页面、分类、摘要，是模型每次进来的第一个导航点。在约 100 个来源、几百个页面规模下，纯 index.md 目录居然出奇好用——很多团队一上来就架向量库、接 GraphRAG，反而把事情搞复杂了。
• log.md（时间导向）：记录何时 ingest 了什么、跑了什么 lint、发起了什么 query。一个告诉你「有什么」，一个告诉你「最近发生了什么」。
• 其他：overview.md（认知快照）、hot.md（上下文缓存）、purpose.md（存在目的）、state（增量缓存）、review.q（人工判断入口）、graph.json（图层导航）。

4.2 八到九种页面类型

页面类型	管什么
source 页	单篇来源的摘要与出处
entity 页	人、公司、产品、库等对象
concept 页	术语、框架、方法、理论
comparison 页	横向对比
question 页	高价值问答的沉淀
synthesis 页	跨来源的综合结论
decision 页	决策与踩坑经验
gap 页	「已知的未知」开放问题
meta 页	导航与控制面

4.3 Front Matter 是约束数（不是装饰品）

每一页必须有 front matter——Markdown 开头的元配置：类型、标题、摘要、来源、标签、状态、自信度、更新时间。没有它就没法做类型过滤、stale 检测、图谱导出、结构化查询。更激进的实现（如 LLM Wiki compiler）甚至在 front matter 里加了 confidence / provenance / state / contradicted_by / inferred_paragraphs，标记出哪些段落是原文抽取、哪些是模型推断、哪些有争议。

5. Ingest 管线与「四件事」

一次 ingest 绝不只是「丢一篇文章、写个摘要」。它可能同时更新 index、entity、concept 甚至 log——在一些实现里，单个来源往往触达 8 到 15 个页面：涉及三个已见概念要更新、提到新实体要新建、与旧结论矛盾要建冲突页，然后 index / overview / log 全刷新。

graph LR A["接收原始材料"] --> B["规范化"] B --> C["读取 Schema"] C --> D["分析 Pass"] D --> E["生成 Pass"] E --> F["交叉引用 Pass"] F --> G["更新控制面"] G --> H["进 Review 队列"]

工程化亮点： atomic-memory 编译器把编译分成「概念抽取」与「页面生成」两阶段，中间用 SHA-256 做 hash，只有变了的地方才重编译——把「生成」工程化成可增量、可缓存、可审计的流水线，是整个范式里最被低估的部分。

让 Wiki 活起来的四件事

动作	说明
Query 查询	查的不是原始文档堆而是编译结果：先读 hot.md 取方向 → 读 index.md 做候选 → 混合检索 → 只读必要页 → 带来源输出
Save 结晶	最重要的一步：把对话中有长期价值的综合判断沉淀为新的 synthesis/comparison/question。不做这步，LLM Wiki 就退化回一个待日志的聊天系统
Lint 治理	结构性检查（死链、孤儿页、重复命名）+ 语义性检查（成就声明、冲突结论）。项目把它拆成不调 LLM 的 house.py 和调 LLM 的 lint.py 两个脚本
Research 研究	从 graph insights 或 review item 自动生成研究主题，派出 search query，把结果回写进 Wiki——Wiki 主动发现自己的知识缺口并去补

6. 对抗性 Ingest：对抗确认偏差

大部分实现现在是「串行单视角」：一篇资料进来，LLM 读一遍、写一遍就完事。最大问题是确认偏差——LLM 容易把一条可疑声明直接写成事实，然后下游所有页面顺着错误往下涨。NVK LLM Wiki 给出了两种对抗性模式：

⭐ Faces 模式： 对一个有争议的命题，不派一个 agent 去综合，而是派 5 到 10 个立场分化的 agent 并行取证（支持方、反对方、机制派、原教旨派、相关领域派）。最后不给一段看似全面的总结，而是给出明确 verdict：supported（被证据支持）/ partially supported（部分支持）/ contradicted（被证据反驳）。

7. 检索层：混合检索与自适应路由

检索不再是单一手段，而是 BM25 + 向量 + 图 三路混合，用 RRF（Reciprocal Rank Fusion）融合排序；并用 Adaptive RAG 按查询类型路由到不同策略。不同范式各有所长：

能力维度	RAG	GraphRAG	LLM Wiki
单跳事实检索	强	中	强
多跳推理	弱	强	强
跨实体关联	弱	强	强
全局主题综合	弱	强	强
长期沉淀	弱	弱	强

8. 边界辨析：它和谁不一样

• vs Agent Memory： Agent Memory 偏「个体记忆、服务当前任务」；LLM Wiki 偏「团队级知识资产、可审计可治理」。
• vs Obsidian / Notion 等 PKM： PKM 靠人工维护链接与结构；LLM Wiki 把维护自动化，且强制 Schema 约束与来源追踪。
• vs 知识图谱： KG 是强 schema 的三元组结构；LLM Wiki 以人可读的 Markdown 页面为主，graph.json 只是导航副产物，更灵活也更易演化。

9. 治理难点

• Confidence（自信度）： 每页/每段标注置信度，低置信内容需人工复核（review.q）。
• Supersession（取代关系）： 新结论如何优雅取代旧结论，而非简单覆盖——需要保留演化轨迹。

10. 最大风险：幻觉回写的自我强化

❗ 如果 LLM 把一条幻觉写进 Wiki，后续 ingest 和 query 会不断引用、强化这条错误，形成自我强化的污染闭环。这也是为什么对抗性 ingest、confidence 标注、review 队列、lint 治理这些「刹车机制」不是可选项，而是系统能否长期可信的关键。

11. 适用与不适用场景

✅ 适合

• 长期主题研究 / 领域知识积累
• 需要跨文档综合、反复复用结论
• 团队级、需可追溯可审计的知识库
• 中等规模（约 100 来源、几百页面）

❌ 不适合

• 一次性问答（不值得架整套治理层）
• 极大规模低价值语料粗筛（先上 RAG 更合理）
• 实时监控告警（它不是观测系统）
• 严格合规的企业级平台终局（基础设施还缺太多）

12. 结语：一个会越用越值钱的知识运行时

LLM Wiki 的真正价值，不在任何一次回答听起来多聪明，而在于它让每一次 ingest、query、research 都变成对同一份知识资产的增量投资。作者用一组比喻收束：

LLM 是编译器 · Chat 是入口 · Wiki 是产品 · Graph 是导航层 · Schema 是操作系统 · Review 是刹车 · Log 是审计轨迹。

本质：把 LLM 从「每次都重来的回答器」升级为「会越用越值钱的知识运行时」。