LLM 知识库：Karpathy 的第一手方法论全解析

> **参考对象**：Vannevar Bush《As We May Think》(1945) + Tiago Forte《Building a Second Brain》+ 编译器设计思想 --- ## 引子：来自源头的声音 2026年4月，Andrej Karpathy 在 GitHub Gist 上发布了一份名为《LLM Knowledge Bases》的文档。这不是推文，不是演讲，是一份**设计文档**——专门用来复制粘贴给你的 LLM Agent（Claude Code、Codex、OpenCode 等），让它帮你构建个人知识库。 这份文档的精髓可以用一句话概括： > **"传统的 RAG 每次查询都在重新发现知识，而 LLM Wiki 让知识自己生长。"** 本文基于 Karpathy 的原始 Gist，完整拆解这套方法论的核心思想、三层架构、三大操作，以及为什么它可能是 Vannevar Bush 1945 年 Memex 愿景的真正实现。 --- ## 第一部分：为什么传统 RAG 不够聪明？ ### RAG 的问题 大多数人的 LLM 文档体验是这样的： ``` 上传文件 → 查询时检索相关片段 → LLM 生成答案 ``` **问题在哪？** | 问题 | 说明 | |------|------| | **没有积累** | 每次提问，LLM 都要从头找、重新拼凑 | | **没有合成** | 需要综合5份文档的微妙问题，LLM 每次都要现场拼凑 | | **没有演化** | 知识不会随着时间变得更丰富、更关联 | NotebookLM、ChatGPT 文件上传、大多数 RAG 系统都是这样工作的。 ### Karpathy 的洞察 Karpathy 提出的方法完全不同： ``` 原始素材 → LLM 编译 → 持久化 Wiki → 查询时直接读取已编译知识 ``` **关键区别**： - **不是索引后等待检索** - **而是读取、提取、整合到已有知识网络** 当你添加新素材时，LLM 会： - 读取它 - 提取关键信息 - 更新实体页面 - 修订主题摘要 - 标记新旧数据的矛盾 - 强化或挑战 evolving synthesis **知识被编译一次，然后保持最新**——不是每次查询都重新推导。 --- ## 第二部分：三层架构——优雅的分离 ``` ┌─────────────────────────────────────────────────────────────────────┐ │ Karpathy 三层架构 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ Layer 3: Schema (配置层) │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ • CLAUDE.md / AGENTS.md │ │ │ │ • 定义 wiki 结构、命名规范、工作流程 │ │ │ │ • 让 LLM 成为"有纪律的 wiki 维护者"而非"通用聊天机器人" │ │ │ │ • 你和 LLM 共同演化 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ ↑ 指导 │ │ Layer 2: The Wiki (知识层) │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ • LLM 生成的 markdown 文件目录 │ │ │ │ • 摘要、实体页面、概念页面、比较、综述 │ │ │ │ • LLM 全权维护：创建、更新、维护交叉引用、保持一致性 │ │ │ │ • 你读它，LLM 写它 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ ↑ 编译 │ │ Layer 1: Raw Sources (原始层) │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ • 你策划的源文档集合 │ │ │ │ • 文章、论文、图片、数据文件 │ │ │ │ • 只读——LLM 读取但永不修改 │ │ │ │ • 真相的来源 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ ``` ### 三层详解 #### Layer 1: Raw Sources（原始素材） **是什么**：你策划的源文档集合 **内容**：文章、论文、图片、数据文件 **关键原则**：**immutable（不可变）** - LLM 读取它们 - 但永不修改它们 - 这是你的**真相来源** #### Layer 2: The Wiki（知识层） **是什么**：LLM 生成的 markdown 文件目录 **内容**： - 摘要（Summaries） - 实体页面（Entity pages） - 概念页面（Concept pages） - 比较（Comparisons） - 综述（Synthesis） **所有权**： - **LLM 全权维护** - 创建页面 - 新素材到达时更新 - 维护交叉引用 - 保持一致性 **你的角色**： - 你**读**它 - LLM **写**它 #### Layer 3: The Schema（配置层） **是什么**：告诉 LLM 如何维护 wiki 的文档 **文件名**： - `CLAUDE.md`（Claude Code） - `AGENTS.md`（Codex） **内容**： - wiki 的结构 - 命名规范 - 工作流程：如何摄入源、如何回答问题、如何维护 wiki **关键作用**： - 让 LLM 成为**"有纪律的 wiki 维护者"** - 而非**"通用聊天机器人"** **演化方式**： - 你和 LLM **共同演化** - 随着你弄清楚什么对你的领域有效 --- ## 第三部分：三大操作——完整的知识工作流 ### Operation 1: Ingest（摄入） **流程**： ``` 丢入新素材到 raw/ ↓ 告诉 LLM 处理它 ↓ LLM: - 读取源 - 与你讨论关键要点 - 在 wiki 中写摘要页面 - 更新索引 - 更新相关实体和概念页面（可能涉及 10-15 个页面） - 追加条目到 log ``` **Karpathy 的个人偏好**： > "我更喜欢一次摄入一个源并保持参与——我读摘要、检查更新、指导 LLM 强调什么。" **替代方案**： - 你也可以批量摄入多个源，减少监督 - 开发适合你风格的 workflow - 记录在 schema 中供未来会话使用 ### Operation 2: Query（查询） **流程**： ``` 向 wiki 提问 ↓ LLM: - 搜索相关页面 - 读取它们 - 综合答案（带引用） ↓ 答案形式取决于问题： - markdown 页面 - 比较表 - 幻灯片（Marp） - 图表（matplotlib） - canvas ``` **关键洞察**： > **"好的答案可以作为新页面归档回 wiki。"** 你要求的比较、分析、发现的联系——这些有价值，不应该消失在聊天历史中。 **知识复利**： - 摄入的源会 compound - 探索也会 compound ### Operation 3: Lint（健康检查） **做什么**：定期让 LLM 健康检查 wiki **检查项**： | 检查项 | 说明 | |--------|------| | **矛盾** | 页面间的矛盾 | | **过时声明** | 新源已取代的旧声明 | | **孤立页面** | 没有入链的页面 | | **缺失页面** | 提到但缺乏自己页面的重要概念 | | **缺失交叉引用** | 应该有的链接 | | **数据缺口** | 可以用网络搜索填补的缺口 | **价值**： - LLM 擅长建议新问题调查 - 建议寻找的新源 - 保持 wiki 健康增长 --- ## 第四部分：两个特殊文件——导航工具 ### index.md：内容导向 **作用**：wiki 内容的目录 **内容**： - 每个页面列出：链接 + 一句话摘要 - 可选元数据：日期、源数量 - 按类别组织：实体、概念、源等 **更新时机**：每次摄入后自动更新 **查询时使用**： ``` LLM 先读 index → 找到相关页面 → 深入阅读 ``` **规模表现**： - ~100 源、~数百页面 的中等规模下工作得很好 - 避免了 embedding-based RAG 基础设施的需求 ### log.md：时间线导向 **作用**：append-only 的记录，记录发生了什么、何时发生 **内容**： - 摄入 - 查询 - lint 通过 **格式技巧**： ```markdown ## [2026-04-02] ingest | Article Title ## [2026-04-02] query | Question asked ## [2026-04-03] lint | Health check ``` **Unix 工具友好**： ```bash # 最后5条记录 grep "^## \[" log.md | tail -5 ``` **价值**： - wiki 演化的时间线 - 帮助 LLM 理解最近做了什么 --- ## 第五部分：可选工具链 ### 搜索：qmd **问题**：小规模时 index 文件足够，但 wiki 增长后需要 proper search **解决方案**：qmd - 本地 markdown 文件搜索引擎 - 混合 BM25/vector search - LLM re-ranking - 全设备端运行 - CLI（LLM 可以 shell 调用） - MCP server（LLM 可以作为原生工具使用） **替代方案**： - 让 LLM 帮你 vibe-code 一个简单的搜索脚本 ### 网页剪藏：Obsidian Web Clipper - 浏览器扩展 - 将网页文章转换为 markdown - 快速将源放入 raw 集合 ### 图片处理 **设置**： 1. Obsidian Settings → Files and links 2. "Attachment folder path" 设为固定目录（如 `raw/assets/`） 3. Settings → Hotkeys，搜索 "Download" 4. 找到 "Download attachments for current file"，绑定热键（如 Ctrl+Shift+D） **使用**： - 剪藏文章后，按热键 - 所有图片下载到本地磁盘 **好处**： - LLM 可以直接查看和引用图片 - 不依赖可能失效的 URL **注意**： - LLM 不能原生读取带内联图片的 markdown - 变通：先读文本，再单独查看引用的图片 ### 可视化：Obsidian Graph View - 看 wiki 的形状 - 什么连接到什么 - 哪些是 hub 页面 - 哪些是孤立页面 ### 幻灯片：Marp - markdown-based slide deck 格式 - Obsidian 有插件 - 直接从 wiki 内容生成演示文稿 ### 查询：Dataview - Obsidian 插件 - 在页面 frontmatter 上运行查询 - 如果 LLM 添加 YAML frontmatter（标签、日期、源数量） - Dataview 可以生成动态表格和列表 --- ## 第六部分：为什么这套方法有效？ ### 核心洞察 维护知识库的繁琐部分不是阅读或思考——而是**记账工作**： | 繁琐工作 | 人类的问题 | LLM 的优势 | |---------|-----------|-----------| | 更新交叉引用 | 会忘记 | 不会忘 | | 保持摘要最新 | 会厌烦 | 不会厌烦 | | 标记新数据与旧声明的矛盾 | 会遗漏 | 一次 pass 能 touch 15 个文件 | | 维护跨数十页面的一致性 | 负担增长快于价值 | 维护成本接近零 | **结果**：wiki 保持维护，因为维护成本接近零。 ### 人类的新角色 | 传统 | Karpathy 模式 | |------|--------------| | 策划源 | 策划源 ✅ | | 直接分析 | 指导分析 ✅ | | 提出好问题 | 提出好问题 ✅ | | 思考这一切意味着什么 | 思考这一切意味着什么 ✅ | | 记账工作 | LLM 处理 | ### 历史回声：Vannevar Bush 的 Memex 1945 年，Vannevar Bush 在《As We May Think》中描述了 Memex： - 个人的、策划的知识存储 - 文档间的 associative trails（联想路径） **Bush 的愿景 vs 互联网**： - Bush 的愿景更接近 **私有、主动策划** - 文档间的连接和文档本身一样有价值 - 互联网变成了 **公共、被动消费** **Bush 没能解决的问题**：谁来做维护？ **LLM 解决了这个问题**。 --- ## 第七部分：应用场景 Karpathy 列举了多种应用场景： ### 个人 - 跟踪自己的目标、健康、心理学、自我提升 - 归档日记条目、文章、播客笔记 - 随时间构建自己的结构化图景 ### 研究 - 数周或数月深入一个主题 - 阅读论文、文章、报告 - 逐步构建带有演化论点的综合 wiki ### 读书 - 边读边归档每章 - 构建人物、主题、情节线索页面 - 以及它们如何连接 **类比**： - 像 Tolkien Gateway 这样的粉丝 wiki - 数千页互链页面，覆盖人物、地点、事件、语言 - 由志愿者社区数年建成 - **你可以在阅读时个人构建类似的东西** - LLM 做所有交叉引用和维护 ### 商业/团队 - LLM 维护的内部 wiki - 源：Slack 线程、会议记录、项目文档、客户电话 - 可能有人类在循环中审核更新 - wiki 保持最新，因为 LLM 做团队没人想做的维护 ### 其他 - 竞争分析 - 尽职调查 - 旅行规划 - 课程笔记 - 爱好深入 **共同点**：随时间积累知识，希望它有条理而不是分散 --- ## 第八部分：实施建议 ### 文档的意图 Karpathy 强调： > "这份文档故意是抽象的。它描述的是想法，不是具体实现。" **可变部分**： - 确切的目录结构 - schema 规范 - 页面格式 - 工具链 **取决于**： - 你的领域 - 你的偏好 - 你选择的 LLM ### 模块化哲学 > "上面提到的所有内容都是可选和模块化的——挑选有用的，忽略无用的。" **示例**： - 你的源可能只有文本 → 不需要图片处理 - wiki 可能足够小 → 只需要 index 文件，不需要搜索引擎 - 你可能不关心幻灯片 → 只需要 markdown 页面 - 你可能想要完全不同的输出格式集合 ### 正确的使用方式 > "正确的方式是把它分享给你的 LLM Agent，一起 instantiate 一个适合你需求的版本。" **文档的工作**：传达模式 **你的 LLM 的工作**：弄清楚其余部分 --- ## 附录：Karpathy 的原始 Gist **链接**：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f **标题**：LLM Knowledge Bases **副标题**：A pattern for building personal knowledge bases using LLMs **用途**：设计为复制粘贴给你自己的 LLM Agent **目标受众**：OpenAI Codex、Claude Code、OpenCode / Pi 等 --- **从 RAG 到编译型知识库，这可能是个人知识管理的范式转移。** **而这一次，维护的负担终于有人承担了。** #Karpathy #LLM #知识管理 #RAG #Wiki #智柴外脑