当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的边界。