当LLM自己能做知识库，RAG还是必需品吗？

副标题：Karpathy的LLM Wiki，正在终结RAG的草莽时代

---

凌晨两点，你盯着屏幕上那条飙升的向量检索延迟曲线，突然意识到一个问题：

为这场搜索付出的工程复杂度，真的值得吗？

---

1

RAG（检索增强生成）统治了这三年。

每家做AI应用的公司，都在吹自己的RAG架构有多先进——向量嵌入、相似性搜索、分块策略、重排序……一套组合拳打下来，文档处理链路的复杂度堪比半个搜索引擎。

然后Karpathy发了一条推。

他展示了自己的知识管理系统：就是一个文件夹，里面装着Markdown。没有任何向量数据库，没有嵌入层，没有复杂的检索逻辑。

唯一的"智能"，来自于LLM本身对文本的理解能力。

1700万浏览量。所有人都震惊的不是这个数字，而是这个做法的朴素。

---

2

我第一次看到这条推的时候，下意识反应是：这不是倒退吗？

RAG的核心假设是：LLM的上下文窗口有限，无法一次消化所有文档，所以需要检索来喂给它最相关的内容。

但Karpathy的LLM Wiki做了一个反直觉的操作：不是让LLM去检索，而是让LLM去编译。

原始素材——论文、博客、代码、截图——先一股脑丢进raw/目录。然后LLM对这些素材进行增量编译，生成一套结构化的Wiki：标题、摘要、标签、正文。

编译的结果才是知识。

不是检索，是生成。

这个区别很关键。检索是在一堆垃圾里找宝藏。编译是把原材料炼成金子。

---

3

你可能会说：文件多了怎么办？10万篇文档塞进上下文，LLM照样爆炸。

这是个好问题。Karpathy自己承认，Wiki的规模大概在100篇文章、40万字左右的时候，这个方法运转得最好。

超出这个规模，LLM的内生理解能力就开始吃力。

但这里有个反直觉的推论：

你真的需要管理10万篇文档吗？

大多数人的知识管理困境，不是文档不够多，是太多。多到根本看不过来，多到收藏夹变成了"知识墓地"。

Karpathy的做法本质上是在说：与其花时间建复杂的检索系统，不如花时间把100篇核心文档真正读懂、编译、吸收。

这不是技术决策。这是认知决策。

---

4

LLM Wiki的架构有多简单？

三个组件：

raw/           ← 原始素材文件夹
wiki/          ← AI编译后的百科
Claude Code    ← 查询界面

没有向量数据库。没有嵌入服务。没有API调用追踪。

所有内容都是Markdown。所有引用都可点击。所有声明都可溯源。

你甚至可以打印出来离线阅读。

这大概是有史以来门槛最低的"AI知识库"。

---

5

RAG的支持者会反驳：复杂场景下你试试？金融合同检索、医疗记录比对、法律条文引用——这些领域需要精确的块检索，不是模糊的语义理解。

没错。这是新方案RAG的边界。

但问题在于：有多少人的知识管理场景，是真正意义上的"复杂场景"？

大多数人的真实困境是：收藏夹里堆了500篇文章，需要用的时候想不起来在哪。Notion数据库越建越复杂，最后自己都懒得打开。Roam Research的双向链接建了三个月，回头发现链接指向的内容早就过时了。

工具建得越来越复杂，人越来越累。

Karpathy的解法是：降维。不是升级工具，是简化问题。

---

6

我上周试着把自己的笔记迁移到这个模式。

第一步，把所有"待读"文章从Pocket迁移到一个raw/文件夹。第二步，让Claude帮我生成每篇文章的摘要和标签。第三步，定期让Claude做"体检"——检测不一致、补充缺失、挖掘关联。

三天后，我有了一个活的Wiki。

不是静态的收藏夹，是会自动生长的知识网络。每一次提问都在训练这个系统。不是模型训练，是知识组织训练。

最大的感受不是效率提升，是焦虑下降。

以前总觉得"还有这么多没读"。现在觉得"已经编译的都在这里了"。

---

7

当然，这个方法不是银弹。

超大规模知识库、安全关键的精确检索、多用户协作场景——这些仍然是传统RAG或向量数据库的主场。

但对于独立开发者、研究者，写作者——那些真正需要管理"自己的知识"的人——LLM Wiki可能是过去十年最接近答案的解法。

从Notion到Roam Research，从Obsidian到双链笔记，我们一直在寻找更好的知识组织工具。

Karpathy说：工具不是答案，系统才是。

而这个系统，可能比你想象的简单得多。