Karpathy提出LLM Wiki，一种让AI自动构建结构化知识库的元框架，或将改变我们管理信息的方式。
核心内容：
1. LLM Wiki的核心理念：从RAG的“解释器”模式转向“编译器”模式
2. 当前RAG技术的局限与LLM Wiki提出的解决方案
3. LLM Wiki作为元框架对未来知识管理的影响

LLM Wiki的起源：Karpathy 重新定义个人知识管理

2026年4月，OpenAI创始成员、特斯拉前AI总监Andrej Karpathy在X上分享了一套自己正在实践的工作流，称之为“LLM Wiki”。这条帖子在X上浏览量超过1700万，引发了整个开发者社区的广泛讨论。

Karpathy将这套想法整理成一份gist（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）进行分发。他在其中提出一个判断：在LLM Agent时代，分享具体代码或应用的意义正在变弱，现在只需要分享想法，把它交给Claude、Grok等Agent，它就可以根据你的需求自动搭建一个属于你自己的个人知识库。

这不是一个具体的工具或软件，而是一种元框架（meta-framework）——它不依赖某个具体模型或技术栈，而是在尝试定义一种人类与AI协作管理知识的方式。

估计很多老一点的程序员可能对wiki这个词很熟悉！维基百科就是这样做的。你也可以把LLM Wiki理解成给Agent用的一个“维基百科”。（说完这个，年龄立马暴露了）

01

—

需要从RAG的困境说起

LLM领域的知识层出不穷，RAG还都没有用明白呢！LLM Wiki又出来了。但是这个LLM Wiki还真应该了解了解，它不是一个赶时髦的概念，也许真的会成为Agent知识管理中一个非常重要的技术。

要理解LLM Wiki的价值，首先要看清当前主流方案RAG的局限。

目前我们使用LLM处理文档的方式，本质上类似于RAG（检索增强生成）：上传一组文件，模型在查询时检索相关片段，然后生成答案。NotebookLM、ChatGPT的文件上传功能，以及大多数企业级RAG系统，都遵循这一模式。

Karpathy指出了RAG的根本问题：每一次提问，模型都在从零重新发现知识，重新拼凑。

如果你问一个需要综合五篇文档才能回答的复杂问题，模型每次都要重新定位、拼凑相关片段——没有任何东西被沉淀下来。Karpathy的原话是：“没有积累”（There's no accumulation.）

用计算机科学的术语来说：RAG表现得像解释器——运行时重新求值一切。

02

—

从“解释器”到“编译器”

LLM Wiki提出的是一种完全不同的思路：不是在查询时从原始文档中临时检索，而是让LLM逐步构建并维护一个持续存在的、结构化、相互链接的Wiki。不是让人来手动构建wiki，而是让大模型根据设定的格式和目标，来自动创建这个wiki。

Karpathy引用了一个程序员一听就明白的类比：RAG像解释器，LLM Wiki像编译器。

编译器做什么？它把源代码预先处理成可执行的程序，之后每次运行都基于编译产物，而非反复阅读源代码（Java就是这样处理的）。

LLM Wiki同理——将原始资料预先“编译”成结构化的Markdown Wiki，后续所有检索都基于这个编译产物展开，而非反复阅读原始材料。

03

—

LLM Wiki的架构设计

LLM Wiki采用清晰的三层架构：

第一层：原始资料（Raw Sources）——不可变层

将所有原始资料（论文、文章、PDF、网页剪藏等）放入raw/目录。这一层是不可变的——LLM只读取，绝不修改。这是事实基准，如果Wiki出了问题，可以从原始素材重建。

第二层：Wiki——已编译的知识图谱

LLM读取raw/中的素材后，主动“编译”出一整套结构化的Markdown Wiki。包含实体页面（人物、公司、论文）、概念页面（思想、方法、框架）、主题摘要、对比表格等，并构建一个全局视图index.md，这个全局视图就是将来Agent用来定位wiki页面的目录。

第三层：Schema——行为契约（可选）

通过SCHEMA.md或AGENTS.md等配置文件，定义知识库的主题边界、写作风格、知识粒度，约束LLM提炼知识的方向，保证全站风格统一。

04

—

查询知识

用户提问后，Agent的工作路径如下：

1. 完整读取顶层索引 index.md——这相当于知识库的“目录”，列出了所有页面标题与核心摘要

2. 根据摘要自主判断哪些页面与问题相关

3. 读取相关Wiki页面的完整全文——注意，不是碎片化的chunk，是完整的、结构化的页面

4. 沿[[wikilink]]进行多跳推理——从一个页面跳到另一个页面，通过知识网络完成深度推理

5. 基于完整的上下文生成答案

这一过程零向量检索、零分块、零碎片割裂，是LLM Wiki最纯正的原生使用方式。Agent不再像传统RAG那样从原始文档中拼凑片段，而是在一个已经编译好的、结构清晰的知识库上进行查询和检索。

05

—

知识库的自我生长

Karpathy反复提到“compounding（复利） ”一词。

标准个人知识管理工作流中，信息的增长充其量是线性的——收藏了200篇文章，190篇原封不动地躺着。知识不会自己相互关联，每次需要用到时，结构都得手动搭建。

LLM Wiki改变了这一点。模型不只是写一个摘要页面，它会通读整个现有Wiki，找出新内容与已有实体页面、概念页面的交集，然后更新所有相关内容。

每一个新输入都被整合进现有知识结构，而非堆叠在上面。矛盾被标记，交叉引用被添加，综合页面被修订。

这就是复利效应的实质：摄入的内容越多，新材料被解读时所处的上下文就越丰富。 普通的知识库里，添加第100条笔记不会让第50条笔记变得更聪明——但在LLM Wiki模式下，会。

看到这里，很多人已经隐隐感觉到了tokens在起飞，每一次wiki的重建，都需要重新构建整个知识连接，tokens的消耗确实是一个无法回避的问题。但这就是权衡，你得考虑要优质的内容，还是要省钱，毕竟RAG利用本地Embedding模型的话，几乎是0 tokens消耗。

但有些帐要长远地算，如果说RAG检索出的内容质量差，导致Agent Loop飞转起来，估计多余的两三轮Loop，节省出来的tokens就又搭进去了。

06

—

适用场景

Karpathy在gist中列举的适用场景包括：个人知识管理、长期研究某个主题、边读书边建立角色/主题/线索页、团队内部Wiki、竞品分析、尽调、旅行规划、课程笔记等。

这些场景有一个共同点：资料会不断累积，问题不会只问一次，人想要的通常不只是“找到片段”，而是“把结构慢慢整理出来”。

Karpathy指出，在约100篇文章、40万字规模的实践中，这套方案的效果显著优于传统RAG，且完全人类可读、可审计。如果只是临时查一个问题，RAG已经够用；但如果一个主题会反复碰、反复问、反复补材料，Wiki这层就开始产生真正的价值。

技术没有绝对的优劣，只有是否适配具体的使用场景。

登录查看剩余 70% 内容