Karpathy 提出 LLM 知识库新范式：用“编译”替代 RAG，构建可生长的个人 Wiki

Andrej Karpathy，OpenAI 创始成员，前特斯拉 Autopilot AI 总监，也是 Vibe Coding 概念的提出者。2022 年离开特斯拉后，他专注于 AI 教育，其 YouTube 课程是很多人入门深度学习的起点。

今年 4 月，Karpathy 发了一条推文，标题只有三个词——“LLM Knowledge Bases”。这条推文获得了超过 1500 万次浏览和 9 万次收藏，成为了今年 AI 圈传播最广的个人分享之一。

他探讨的正是许多人（包括我）正在琢磨的事：如何让大型语言模型真正帮你管理知识——持续维护一个你自己的知识库，一个会自动生长的个人 Wiki。这与聊完就扔的 ChatGPT 对话，或只是上传文件再问答的 NotebookLM 有着本质区别。

三天后，他又发布了一条跟进推文，并将这个想法写成了一份详细的 GitHub Gist（llm-wiki.md）。这份文档的内容比推文丰富得多，包含了完整的架构设计、操作流程、工具推荐和理论思考。

我们先从一个核心问题开始：为什么现有的“AI 知识库”方案总让人觉得不够好？

RAG 的困境与结构性限制

目前主流的 LLM 处理文档方式，Karpathy 用了一个词概括——RAG（Retrieval-Augmented Generation）。你上传文件，系统将其切片、生成向量存储，查询时通过向量相似度找到相关片段，再塞进 LLM 的上下文窗口来生成答案。从 NotebookLM 到 ChatGPT 的文件上传，再到市面上大多数“知识库”产品，基本都遵循这个模式。

这个模式能用，但仔细拆解，会发现几个结构性的硬伤：

第一，Chunk 边界导致语义断裂。 RAG 系统需要把文档切成小块（chunk），但切在哪里是个难题：小 chunk（100-256 tokens）检索精度高，但丢失了上下文，一个段落的因果关系可能被切成两半；大 chunk（1024+ tokens）保留了上下文，但向量匹配会变得模糊。Vectara 2025 年的研究发现，语义分块产生的片段平均只有 43 个 token，检索是干净了，但给 LLM 的上下文太少，答案反而不准确。

Mintlify 每天处理 3 万+对话的文档助手也踩了同样的坑——当答案需要跨多个页面时，传统的 top-K 检索直接失灵。他们最终绕过 RAG，为 AI 助手搭建了一个虚拟文件系统。

第二，每次查询都是无状态的。 问一个需要综合五份文档的问题，LLM 每次都得重新找到那五份文档、把碎片拼起来。一篇 arXiv 论文（2602.05152）说得很直白：“RAG 方法本质上仍然是无状态的：每次查询都会重新计算适配内容，然后丢弃，无法实现累积学习。” 每次查询的结果都被丢弃了，下次问类似问题，一切从头来过。

第三，“大海捞针”问题随规模恶化。 LangChain 的 Multi-Needle 测试发现，当需要同时检索多条分散在不同位置的信息时，成功率会显著下降。更麻烦的是“Lost in the Middle”现象——LLM 对上下文窗口开头和结尾的信息更敏感，中间部分容易被忽略。文档越多，这个问题越严重。

第四，Embedding 模型会过时。 更换 Embedding 模型需要重新处理整个语料库。文档内容变更后，对应的向量也需要更新。对于频繁变动的知识库，这是持续的计算开销。

这些都是 RAG 架构固有的约束，仅靠修修补补难以解决。

从“检索”到“编译”：构建持久可增值的 Wiki

Karpathy 提出了一条新路：让 LLM 增量地构建和维护一个持久的 Wiki——一组结构化的、互相链接的 Markdown 文件。当你添加新的信息来源时，LLM 会阅读整份文档，提取关键信息，然后将其整合进已有的 Wiki 中：更新实体页面、修订主题摘要、标注新数据与旧结论之间的矛盾。

用他的原话说：

The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read.

Wiki 是一个持久的、不断增值的产物。 交叉引用已经建好，矛盾已被标记，综合分析已经反映了你读过的所有内容。知识被“编译”一次，然后持续更新。

这个“编译”的比喻非常精确。如果你写过代码，可以这样理解：

编译器概念	LLM Wiki 对应
源代码	raw/ 目录中的原始文档
编译产物	wiki/ 目录中的 Markdown 页面
编译器	LLM
构建配置	Schema（例如 CLAUDE.md）
增量编译	新文档摄入只更新受影响的 wiki 页面
依赖图	交叉引用和反向链接
Lint / 静态分析	Wiki 健康检查

在编程中，增量编译器不会因为你改了一个文件就重新编译整个项目——它只重新编译受影响的部分。LLM Wiki 的摄入操作同理：一个新来源进入系统，LLM 只更新与之相关的 wiki 页面。

用这个比喻来看，RAG 的问题就很清楚了：RAG 相当于每次运行程序都重新编译整个项目。没有中间产物，没有缓存，每次都从源码开始。而 LLM Wiki 则把知识“编译”成了可以直接使用的产物，后续查询直接读取编译结果，极大地提高了效率。这正是 Selman & Kautz 在 1996 年提出的“知识编译”概念的核心：用预处理时间换取查询速度。

三层架构与核心设计

整个系统的架构非常简洁，分为三层：

1. 第一层：原始来源（Raw Sources）。 你策划收集的原始文档——文章、论文、代码仓库等。这一层是不可变的（immutable），LLM 只读不写。它是所有信息的源头和事实依据。

2. 第二层：Wiki。 由 LLM 生成和维护的 Markdown 文件目录，包含摘要、实体页面、概念页面等。LLM 完全拥有这一层的写入权。

3. 第三层：Schema。 一份告诉 LLM Wiki 结构、约定和工作流的配置文件。这是整套系统的关键，它决定了 LLM 是一个有章法的 wiki 维护者，而不是一个漫无目的的聊天机器人。

一个典型的目录结构如下：

wiki-root/
├── CLAUDE.md              # Schema：定义 wiki 结构和工作流
├── raw/                   # 第一层：不可变的原始资料
│   ├── articles/          # 网页文章（通过 Obsidian Web Clipper 抓取）
│   ├── papers/            # 学术论文
│   ├── transcripts/       # 播客/视频文字稿
│   └── data/              # 数据集、CSV、JSON
├── wiki/                  # 第二层：LLM 维护的 Wiki
│   ├── index.md           # 总索引——每个页面一行摘要
│   ├── log.md             # 操作日志（纯追加）
│   ├── entities/          # 实体页面（人物、公司、工具）
│   ├── concepts/          # 概念页面（理论、框架、方法论）
│   ├── sources/           # 来源摘要（每个摄入的来源一个）
│   ├── comparisons/       # 对比分析
│   └── maps/              # 主题导航页（概念集群的入口）
└── assets/                # 图片、图表

Wiki 页面的 Frontmatter 设计

每种页面类型都有对应的 YAML frontmatter 结构。这不仅是为了规整，更重要的是让 Obsidian 的 Dataview 插件能进行动态查询，也让 LLM 在检查时能程序化地验证一致性。

一个概念页面的 frontmatter 示例：

---
type: concept
title: "LLM Knowledge Bases"
aliases: [llm-wiki, llm-kb]
created: 2026-04-02
updated: 2026-04-06
source_count: 5
sources:
- raw/articles/karpathy-llm-kb-tweet.md
- raw/articles/karpathy-idea-file-gist.md
related:
- concepts/rag.md
- concepts/memex.md
- entities/karpathy.md
tags: [knowledge-management, ai-workflow]
status: active
confidence: high
---

confidence 字段是个巧妙的设计，它量化了信息的可信度。一个基于 5 个交叉验证来源的页面，与一个只基于单篇博客的页面，其权重完全不同。status 字段则服务于健康检查流程，标记页面是“活跃的”、“待完善”还是“需要更新”。

四个核心操作：让 Wiki 运转起来

1. 摄入（Ingest）

将新文档放入 raw/ 目录，然后指示 LLM 处理它。一次完整的摄入流程可能包含以下步骤：

1. LLM 阅读完整的原始文档。
2. 与你讨论关键要点（2-3 条摘要 + 值得关注的论断）。
3. 得到确认后，在 wiki/sources/ 创建来源摘要页面。
4. 更新或创建相关的实体页面（wiki/entities/）。
5. 更新或创建相关的概念页面（wiki/concepts/）。
6. 检查新来源与已有 wiki 内容的矛盾，并用标注标记。
7. 更新所有受影响页面的交叉引用。
8. 更新总索引 wiki/index.md。
9. 将操作追加到日志 wiki/log.md。
10. 向你报告：创建了什么、更新了什么、有无矛盾。

一个信息来源可能触发 10-15 个 wiki 页面的更新。 Karpathy 偏好逐个摄入并全程参与，这有助于在早期引导 LLM 的关注重点。

以 Claude Code 作为 LLM Agent 为例，一次摄入会话可能如下：

你：ingest raw/articles/karpathy-llm-kb-tweet.md

Claude Code:
  → Read("raw/articles/karpathy-llm-kb-tweet.md")
  → “这篇文章有三个核心论点：1) ... 2) ... 3) ... 要继续吗？”

你：继续，重点关注和 RAG 的对比

Claude Code:
  → Write("wiki/sources/karpathy-llm-kb.md", ...)     # 创建来源摘要
  → Read("wiki/entities/karpathy.md")                 # 检查实体页面
  → Edit("wiki/entities/karpathy.md", ...)            # 更新实体页面
  → Write("wiki/concepts/llm-knowledge-bases.md", ...) # 创建概念页面
  → Read("wiki/concepts/rag.md")                      # 检查是否有矛盾
  → Edit("wiki/concepts/rag.md", ...)                 # 添加对比引用
  → Edit("wiki/index.md", ...)                        # 更新索引
  → Edit("wiki/log.md", ...)                          # 追加日志
  → “完成。创建了 2 个页面，更新了 2 个页面。RAG 概念页面新增了
     和 LLM Wiki 的对比章节，没有发现矛盾。”

Claude Code 的 Edit 工具在这里至关重要，它通过精确的字符串匹配进行替换，可以安全地只修改大文件中的一小部分。

2. 索引与导航系统

有两个特殊文件帮助管理不断增长的 Wiki。

• index.md 是内容导向的总目录，LLM 在回答查询时会先读它来定位相关页面。
• log.md 是按时间顺序的纯追加操作记录，便于用 grep 等工具进行追溯分析。

3. 查询（Query）

直接向 Wiki 提问。LLM 会搜索相关页面、阅读它们，然后综合出带引用的回答。关键在于：一次高质量的查询结果可以回填到 Wiki 中，成为一个新页面，让你的探索也在知识库中积累下来。

查询的 prompt 可以多种多样，例如：

# 事实性查询
Wiki 里关于 Karpathy 对 RAG 的看法记录了什么？

# 跨来源综合
基于 wiki 中所有内容，LLM 能力天花板最有可能受限于什么因素？引用具体来源。

# 指定输出格式
把 wiki 中关于 AI 监管的内容整理成 5 页 Marp 幻灯片，保存到 assets/ai-regulation-slides.md。

4. 健康检查（Lint）

定期让 LLM 对 Wiki 进行“体检”，检查项目包括：页面间的矛盾、过时的内容、孤立页面、存根页面、缺失的链接、Frontmatter 不一致以及 raw/ 目录中尚未摄入的文件。Lint 报告还能给出下一步行动建议，让 Wiki 保持健康生长。

工具链深度集成

Obsidian：Wiki 的 IDE

Karpathy 将 Obsidian 作为前端，形象地比喻为：“Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.” 你很少手动编辑 Wiki 内容，就像很少手动编辑编译产物一样。

关键插件包括：

• Obsidian Web Clipper：浏览器扩展，一键将网页转为带元数据的 Markdown 保存到本地。
• Graph View：可视化图谱，直观展示页面间的关联，识别孤立节点。
• Dataview：基于 Frontmatter 进行动态查询，将 Vault 变为数据库。
• Marp：基于 Markdown 的幻灯片格式，LLM 可直接从 Wiki 内容生成演示文稿。

qmd：本地的 Markdown 搜索引擎

当 Wiki 增长到数百个页面时，仅靠 index.md 导航会变得低效。此时可以引入 qmd，这是 Shopify CEO 开发的一个本地 Markdown 搜索引擎。它完全离线运行，提供从快速全文检索到高质量混合搜索的多种模式。

更重要的是，qmd 可以作为 MCP Server 集成到 Claude Code 中，为 LLM 提供高效的搜索工具，使其能快速定位相关页面后再深入阅读。

整个 Wiki 就是一个 Git 仓库，版本历史、协作、回滚——所有代码管理的优势都天然具备。

思想谱系：从 Memex 到 AI 驱动的第二大脑

Karpathy 的构想并非凭空出现，它根植于一条漫长的思想谱系：

• Memex (1945)：Vannevar Bush 设想了一种能通过“关联性路径”连接知识的设备，其私有性、主动策划和连接价值与 LLM Wiki 的核心特征惊人相似。
• Zettelkasten (1950s-1998)：社会学家 Niklas Luhmann 用超过 9 万张互链的卡片构建了一个“对话伙伴”式的知识系统，催生了现代数字笔记工具。
• 第二大脑 (2022)：Tiago Forte 的 CODE 框架定义了知识管理的流程。

LLM Wiki 的突破在于，它将其中最耗时、最繁琐的“组织”和“提炼”步骤自动化了。 人类负责策展来源、提出好问题和进行高层思考，而 LLM 负责其余的一切维护工作。这解决了传统知识库因维护成本过高而最终被废弃的核心痛点。

开源实现与社区反响

推文发布后，GitHub 上迅速涌现了大量实现，例如 llm-wiki-compiler、karpathy-wiki 等。甚至有社区整理了 awesome-llm-knowledge-bases 列表，收录了 80 多个相关工具。这些实践表明，在中等规模下，这种“编译”方法能显著降低查询的 token 消耗（有报告称降低了 84%），并使知识库真正可持续地生长。

核心启示：分享想法，而非代码

在 LLM Agent 时代，Karpathy 选择分享一份详细的“想法文件”而非具体代码，这本身就极具启示。因为一个知识库系统的结构高度依赖个人偏好和领域特点，与其提供一套需要大量修改的固定实现，不如清晰地阐述架构思路，让每个人的 AI 助手去定制和构建属于自己的版本。

这套范式不仅适用于个人学习与研究，在团队内部知识沉淀、商业竞品分析等场景同样具有巨大潜力。它代表了一种人机协作的新模式：人类成为知识世界的架构师和提问者，而 AI 则是永不疲倦的建造者和维护者。如果你也在寻找一种更聪明的方式来管理你不断积累的数字化知识，不妨到 云栈社区 的人工智能板块，与更多开发者一起探讨和实践这一前沿思路。