Karpathy：从 RAG 到 LLM WikiHERMES & AGENT ENGINEERING · 课时 06

6.1 Karpathy 和那篇 LLM Wiki 文章

在讨论 RAG 和 LLM Wiki 之前，需要了解下 Karpathy。

Andrej Karpathy 是 AI 领域非常有影响力的人。他是 OpenAI 的联合创始人之一，也曾经担任 Tesla 的 AI 负责人。很多读者知道他，可能是因为他的深度学习课程、关于神经网络的讲解文章，或者后来被反复讨论的 “vibe coding”（是的，这个现在几乎程序员人人都在用的编程范式的命名，就是来自于这个人的一篇博客）。

他后来在 GitHub Gist 上发了一份 llm-wiki.md。严格说，这不是一篇传统博客文章，更像是一份可以直接丢给 Agent 使用的 idea file。它的目的不是发布一个软件，也不是给出一套固定代码，而是描述一种模式：怎样让 LLM 帮人维护个人知识库。

这篇文章之所以会火，是因为它抓住了很多人使用 AI 知识库时的共同痛点。过去大家很容易把 AI 知识库理解成 RAG：把资料切块、建索引、提问时召回。但 Karpathy 提醒大家，个人知识系统不应该只停留在“问的时候找资料”。资料进入系统以后，LLM 就应该开始阅读、整理、融合，把这些资料编译成一组长期维护的 Wiki 页面。

这个转向很关键。它把 AI 知识库从“检索系统”推向了“知识维护系统”。

很巧的是，这篇文章发布于2026 年的 3 月，但我一直没有去阅读这篇文章。我是一个被动学习者，我所有的知识获取都是“任务驱动”的。如果不是为了完成某项任务或者功能，我很少主动去看一些文章或者博客。

当我做 Hermes 这个教材的时候，一直在想给读者提供怎样的价值。我觉得知识库是一个不错的选题案例。于是我先起草了前面几节的思路，然后开始阅读 Karpathy 的文章。我发现我的很多想法和他是一致的。

当然 Karpathy 比我想的更周全，也更科学。

这一节讨论 Karpathy，不是为了给他做人物介绍，也不是为了追热点。我们真正关心的是：他的 LLM Wiki 思路，为什么能解释胶囊系统要做的事情。

6.2 普通 RAG 解决的是检索问题

很多人一说 AI 知识库，第一反应就是 RAG。

RAG 的基本思路并不复杂：先把资料切成片段，放进索引里。用户提问时，系统从索引里找出相关片段，再把这些片段交给大模型生成回答。这个方案很有用，尤其适合企业文档搜索、客服问答、法规查询这类场景。

但个人知识系统面对的问题不完全一样。

个人资料真正麻烦的地方，通常不是“搜不到”。更常见的问题是：资料彼此没有关系，同一个概念被看过很多遍，却没有沉淀成一条清楚的知识线；相关问题问过很多次，答案却散在聊天记录里；新资料不断进入，但旧理解没有被修正。

如果只做 RAG，系统很容易变成一个更会搜索的收藏夹。

普通 RAG 大概可以理解成下面这条链路：

原始资料
  ↓
切块
  ↓
建立向量索引
  ↓
用户提问
  ↓
召回相关片段
  ↓
临时生成回答

这条链路的重点是“问的时候能找到”。资料进入系统以后，系统主要做的是切块和索引；真正的理解，往往发生在用户提问的那一刻。

这就带来一个问题：每次提问都像重新开始。今天问一次，系统检索一批片段，临时总结一次；过几天再问相近问题，它又重新检索、重新总结。它可能给出不错的答案，但这个答案不一定会变成系统里长期存在的知识结构。

对搜索系统来说，这可能已经够用。但对个人知识系统来说，它少了“积累”。

人的知识不是靠每次重新搜索形成的。一个概念反复出现以后，它会慢慢和其他概念发生关系，也会逐渐形成更短、更清楚的判断。胶囊系统要追求的，正是这种长期积累。

6.3 Karpathy 的 LLM Wiki 讲了什么

Karpathy 提出的 LLM Wiki，关键变化在于：不要只让 LLM 在查询时生成答案，而是让 LLM 在资料进入时就参与整理，维护一组长期存在的 Wiki 页面。

可以先把它理解成这样：

原始资料
  ↓
LLM 阅读和整理
  ↓
更新长期 Wiki 页面
  ↓
用户阅读、搜索、引用这些页面

这里的 Wiki 页面不是一次性的摘要。它们会长期存在，也会随着新资料进入不断被修订。新资料如果补充了某个主题，就融合进对应主题页；如果解释了一个基础概念，就更新概念页；如果修正了旧说法，就把旧页面里不准确的地方改掉。

这和普通 RAG 的方向不一样。RAG 更像是在原始资料上加一层检索能力；LLM Wiki 则试图让 LLM 成为 Wiki 的维护者。它要做的不是每次临时回答，而是让知识库本身逐渐变得更有结构。

Karpathy 还提到过一个很有意思的比喻：可以把 Obsidian 看成 IDE，把 LLM 看成程序员，把 Wiki 看成代码库。这个比喻的重点不在 Obsidian，而在分工：工具负责承载页面，LLM 负责修改页面，Wiki 则像代码一样被长期维护。

放到胶囊系统里，也可以这样理解：

这个对应关系很重要。它说明胶囊系统不是要复刻某个工具，而是把 LLM Wiki 的思想放进自己的分层里。

6.4 胶囊系统借鉴了什么

本章前面已经讨论过，胶囊系统有证据层、索引层、理解层、演化层和内化层。Karpathy 的 LLM Wiki 给我们的启发，正好可以落在这几层上。

第一，证据和整理结果要分开。

原始资料不能随便改。它们是来源，也是后面核对的依据。Hermes 可以重写主题页、合并概念页、调整综合页，但不能把整理后的文章当成唯一真相。证据层存在的意义，就是让系统始终能回到原始资料。

第二，资料进入时就要开始整理。

普通 RAG 往往把主要工作推迟到提问时。胶囊系统不能这样做。资料进入以后，Hermes 就应该判断它和已有主题是什么关系：它是在补充某个主题，还是修正某个判断，还是解释一个概念，或者对当前 Wiki 没有贡献。

第三，Wiki 页面要长期维护。

胶囊系统里的主题页不是资料列表。比如“Embedding 向量”这篇主题页，后面如果收到一篇讲余弦相似度的资料，不应该在页面末尾追加一段“新资料摘要”。更合适的处理方式，是把余弦相似度融合进原来解释“向量距离和语义相似度”的部分，让整篇文章仍然像一篇完整文章。

第四，规则要写进 Skill。

如果没有规则，Hermes 每次都会按当前对话里的感觉处理资料。今天它把某个资料建成主题页，明天它可能把类似资料只写成摘要。时间一长，Wiki 会变得很乱。所以胶囊系统必须把规则写清楚：什么时候新建主题页，什么时候更新旧主题页，什么时候拆成概念页，什么时候判定资料没有贡献，哪些内容必须保留证据来源。

这些规则本身，比某一个具体工具更重要。

6.5 用 Embedding 例子看区别

还是用前面一直使用的 Embedding 向量来举例。

如果用普通 RAG，用户问：

为什么 Embedding 能用于语义检索？

系统会从资料库里召回一些片段，比如 Embedding 的定义、向量空间、余弦相似度、语义相近文本的距离关系，然后生成一个回答。这个回答可能是对的，但它通常只是这一次提问的结果。

如果按照 LLM Wiki 和胶囊系统的思路，处理方式就不一样。系统会维护一篇“Embedding 向量”主题页，也会维护“Token”“向量空间”“余弦相似度”“语义相似度”这类概念页。每次新资料进入，Hermes 都要判断它应该改动哪一页。

比如新资料讲的是余弦相似度，Hermes 不应该简单生成一篇新的摘要。它应该判断：

这样处理以后，用户以后再打开“Embedding 向量”主题页，看到的是当前最好的版本，而不是一串资料摘要。主题页里可以保留这样的核心判断：

Embedding 的关键价值，是把文本之间的语义关系变成可以计算的距离关系。

这句话不需要每次都重新生成。它应该存在于主题页里，并且随着新资料进入被校正、压缩和保留。内化层要发挥作用，靠的就是这种长期维护出来的页面和判断。

6.6 和后面实现的关系

后面几节会使用 Hermes + 飞书来实现胶囊系统，但这不是唯一方案。

在 AI 时代，思路比实现更重要；方案比细节更重要；思路稳定后，实现方式可以是多种多样的。胶囊系统的核心思路，是把原始资料、Wiki 页面、规则文件和 Agent 维护流程组织起来。至于具体用什么工具承载这些东西，并没有唯一答案。

你可以用 ChatGPT 加 PostgreSQL 数据库来保存资料、索引和状态。你甚至可以继续使用 Obsidian、Notion、本地文件夹，或者自己写一套更适合团队的系统。只要它能保存证据、维护 Wiki、记录索引，并且让 Agent 按规则持续更新，它就可以实现胶囊系统的核心思想。

本教材选择 Hermes + 飞书，只是因为这套组合更适合后面的演示。

飞书负责保存和展示。证据页、主题页、概念页、综合页、索引表，都可以放在飞书里。它提供的是稳定的工作空间，而不是替 Hermes 思考。

Hermes 负责理解和维护。资料进入以后，它要读取证据，判断关系，更新 Wiki 页面，并且按照 Skill 里的规则控制页面粒度、证据来源、主题融合和当前判断。

飞书 CLI 负责把这两个系统连接起来。Hermes 不是在浏览器里手工点来点去，而是通过 CLI 创建文档、读取文档、更新表格和维护目录结构。

6.7 ■ 学点英语