LLM Wiki ，使用AI来构建你的知识飞轮

LLM Wiki这个概念，最早是由 karpathy 在今年四月份提出的，其原始文档在：

LLM Wiki

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

这条gist不是在讲RAG，而是提出了一种新的知识管理模式，其核心观点为：

让 LLM 不只是“查资料”，而是成为一个持续维护 Wiki 的知识工程师（Knowledge Compiler）。

浓缩成一句话：

RAG 是用户提问时才实时处理，而 LLM Wiki 是数据导入时就提前处理好了。

知识预处理

Wiki，或者叫“知识库”，这个概念并非一个新鲜事物。Wiki，我们更习惯叫它维基，维基百科这个产品出现的时间可以说是相当的久远，我们可以简单的理解其为一个词条驱动的知识库，WikiPedia这个产品通过信息链接将其站内与站外的信息组织成了一张巨大的信息网络，这个庞大的信息网络其实就是一个知识库。
大模型兴起之后，用来连接LLM与信息的RAG将知识库这个概念进一步得到推广，只是过去我们的业务流程一直是：

文档 -> Embedding -> Vector DB -> 用户提问 -> Retrieve -> LLM回答

这种模式是每问一次，都得重新搜索一次。
一个典型的案例：

帮我总结 Kubernetes Operator 与 Controller 的区别

上面这个问题丢改大模型之后，大模型需要做的事情为：

1. 找文档A
2. 找文档B
3. 找文档C
……
N. 将信息拼凑起来回答你的问题

下一次，你继续提问：

Operator 为什么适合状态管理？

你的大模型继续工作：

1. 找文档A
2. 找文档B
3. 找文档C
……
N. 将信息拼凑起来回答你的问题

⚠️ 太棒了！是个Loop！！！
你的AI给到了你答案，但是它却在重复劳动，你的Token也被烧得冒烟。

为了节省你的Token，Karpathy 大佬提出了一个新的概念：

新增文档的时候，就让 AI 完成所有工作。

举个例子：

新资料
    ↓
LLM阅读
    ↓
更新Topic页面
更新人物页面
更新概念页面
更新Summary
更新索引
更新引用
更新冲突记录

在每次进行原始资源汇入时，你的LLM都会预先进行档案阅读、理解，并更新你的知识库（Wiki）。
在此种情况下，你的AI以后回答你的问题不再是读取你杂乱无章的原始档案资料，而是读取已经被整理过的Wiki！
这个工作流程大致为：

Raw Data (原始数据)
    ↓
LLM Extra & Transform (LLM整理)
    ↓
Persistent Wiki (储存为Wiki)
    ↓
Question (你来提问)
    ↓
Answer (你的AI来回答)

这样的好处是：

知识提前整理，而不是回答时临时整理。

知识持久化

Karpathy 大佬认为，你真正有价值的东西是Wiki (知识库)，而不是所谓的Vector DB (向量数据库)。一个优秀的知识库可以是：

AI/
├── Transformer.md
├── Attention.md
├── GPT.md
├── Claude.md
├── Scaling Law.md
├── MoE.md
├── RAG.md
├── Inference.md
└── Prompt Engineering.md

这个知识库中的内容，相互引用，组成了一张知识网：

Transformer
├── Attention
├── Scaling Law
├── GPT
└── MoE

这个过程中，大模型负责了以下工作：

- 新增页面
- 更新页面
- 建立链接
- 删除过期内容
- 标记冲突

最终的产物，不再是一堆一堆的PDF，而是真正的知识网络！

LLM Wiki的三层架构

Karpathy 对于LLM Wiki的设计非常简洁！

• • Raw Sources 原始数据
• • Wiki 知识库
• • Schema 摘要

原始数据 可以是 Paper、书籍、文章、Office文件、PDF档案、图像…… 原始数据永远不会被修改！

Source of Truth!

知识库 由AI读取Raw sources之后得到的档案：

wiki/
├── Transformer.md
├── Attention.md
├── CUDA.md
├── TensorRT.md
├── Summary.md
└── Concept/

知识库由AI来维护，人基本上不需要杜撰。

摘要 用来定义和约束AI行事风格，给其制定执行规则！以下这两个文件，你肯定不会陌生：

AGENTS.md
CLAUDE.md

这两个文件规定形如以下的事项：

- 新增论文怎么办？
- 如何命名？
- 如何分类？
- 什么时候创建新页面？
- 什么时候更新旧页面？
- 引用格式是什么？

Schema 相当于：

Prompt + Workflow + SOP

LLM 每次都按 Schema 工作。

除此之外，非常建议增加以下两个文档：

index.md
log.md

这两个文件，一个用来做Wiki的目录索引；一个用来记录Wiki的变动日志！

LLM Wiki的三个动作

Karpathy定义整个LLM Wiki系统就三个动作：

• • Ingest (资料新增)
• • Query (信息查询)
• • Lint (纠错与整理)

资料新增 非常简单，直接将原始资料丢到 Raw source即可！例如：

你：
把Transformer论文.pdf丢到Source文件夹

AI：
读取
↓
总结
↓
更新Transformer.md
↓
更新Attention.md
↓
更新Scaling Law.md
↓
更新Summary
↓
记录Log

由于知识是网状的，一个文件可能会触发多个文件的Update！

信息查询 不再是读取PDF，而是查询Wiki！甚至，回答结束之时，如果你觉得此次回答具有价值，你还可以将结果保存成Wiki页面！

Question
↓
Answer
↓
保存成Wiki页面

比如，你问了：

GPT4和Claude差异

AI的回答让你心满意足，此时你可以让AI（或者你自己）保存结果到Wiki为：

GPT4_vs_Claude.md

在这个过程，你和AI的每次QA都可以是一次知识沉淀！

Lint 如果你是程序员，这个词儿就很熟悉了！除非你是个不守规矩的“犟种”（纯属调侃，绝无冒犯）。
这个词儿的本质是检查、纠错！过去我们写代码是 Code lint，现在我们玩知识库则为 Knowledge Lint !
你的AI可以定期/不定期的为你的知识库做检查：

有没有：
- 孤儿页面
- 死链接
- 过期内容
- 互相矛盾
- 引用缺失
- 需要拆分的大页面
- 缺失的重要Topic

更有好(第四声)事的AI甚至可以：

- 建议补充 XX。
- 应该读 XX Paper。

如此一来，你的知识库就越来越健康了！

工具推荐

其实工具无所谓，范式才最重要！但是K大佬推荐你使用 Obsidian ，因为这玩意儿有一个 Graph View ！
整个模式闭环下，你也可以试试：

- Web Clipper
- Dataview
- Marp
- Git

如果你的知识库越来越大，读起来很蛋疼，那这个 qmd 工具你也可以整上！

Why LLM Wiki

传统的RAG，文档 - 调用 - 回答 - 结束，这个过程就一个一次性的QA，你的知识得不到增长！
而Wiki based模式：

Documents
↓
LLM整理
↓
Wiki
↓
Question
↓
Answer
↓
Answer继续写回Wiki
↓
知识越来越丰富

如此一来，你的Knowledge Flywheel（知识飞轮）就形成了！你的每一次都会让知识库变得更完整，而不是回答完就消失（像用完即丢的小程序😂）。