给 LLM 搭一个不会忘的知识库

用 LLM 越多，越会发现一个尴尬的事实：LLM 的记性其实很差。

每次关掉窗口，对话里讨论过的结论、读过的论文、分析过的工具，全部归零。下次再问同样的问题，LLM 又从头推导一遍——运气好得出一样的结论，运气不好就给你一个新的。

RAG（检索增强生成）试图解决这个问题：把文档切成块，转成向量，存进数据库，查询时召回相关内容塞进 prompt。听起来合理，但实际用起来有几个硬伤：

• 相似不等于相关。向量检索召回的是"语义最接近"的片段，不一定是"你需要"的片段
• 换了 embedding 模型，召回结果天差地别。你今天搭好的管线，下个版本就可能变味
• 每次查询都重新检索。上一轮推导出的好结论，下一轮不会自动复用——因为它从来就没被"记住"过
• 存进去的是 768 维浮点数。出错了你根本不知道是哪条数据惹的祸

所以我最近搭了一个不走向量检索的知识库。思路来自 Andrej Karpathy 的 LLM Wiki 理念。

一、Karpathy 的核心洞察：知识应该编译，不是反复检索

2025 年，Karpathy 发了一个 Gist，标题就叫"LLM Wiki"。核心思想一句话：

"Obsidian is an IDE, the LLM is the programmer, and the Wiki is the codebase."

翻译成人话：把 LLM 当成一个程序员，Obsidian（或任何 Markdown 编辑器）当成 IDE，Wiki 页面当成代码。知识只编译一次，持续更新。每次学到新东西，不是存进向量数据库等着被搜，而是直接修改对应的 Wiki 页面，就像程序员改代码一样。

传统 RAG 的工作方式是"每次查询时去翻书"——每次都要找、读、总结。LLM Wiki 的工作方式是"把书读了，把笔记写好，下次直接看笔记"。

这解决了一个更根本的问题：知识的复利。RAG 每次从零检索，上一次查询的结论不会让下一次查询更快更准。但 Wiki 是积累的——今天写的笔记，明天查询时直接命中，不需要重新推导。

后来社区里有个叫 nashsu 的开发者把这个想法做成了完整的桌面应用，加了不少工程增强。我照着这个思路搭了自己的知识库。

二、三层架构：为什么必须分层？

整个知识库拆成三层，每层有自己的职责和权限，互不越界。

Layer 1 — 原始素材层（只读不写）

这是知识库的"书库"——论文 PDF、网页文章、对话记录、图片，全部原样存放。关键规则：LLM 可以读，但绝不修改。这是整个系统的 facts 来源。Wiki 写错了可以从这里重建。

Layer 2 — Wiki 知识层（LLM 全权维护）

这是知识库的"目录卡片 + 摘要手册"。由 LLM 从原始素材中提取关键信息，写成结构化的 Markdown 页面。LLM 全权维护这一层——新建页面、更新旧页面、拆分过长的、合并重叠的。人只审核和引导，不直接上手编辑。

Layer 3 — Schema 规则层（人定义，与 LLM 共同演化）

这是知识库的"操作手册"——告诉 LLM 怎么分类、怎么写页面、怎么命名、怎么建立交叉引用、怎么处理矛盾信息。由人定义初始规则，LLM 按手册执行，双方在实践中一起改进。

为什么必须分层，而不是一个文件夹搞定？

三层分离背后有三个硬理由：

1. 可重建性：Wiki 是派生产物。如果 Wiki 乱了，可以从 raw/ 重新生成，不会丢失根本
2. 权限清晰：raw/ 不可变保证"事实不被篡改"，Wiki 可自由编辑保证"表达可以持续优化"
3. 人机各司其职：人管"方向和标准"，LLM 管"执行和维护"，原始资料管"真实性"

如果把三层揉在一起——原始素材和 LLM 生成的笔记混在一个目录里——过两个月你自己都分不清哪句话来自原文、哪句话是 LLM 编的。

三、知识域：让资料一眼就能找到

很多知识库只按"笔记类型"分类——概念页放一起，工具介绍放一起，对比分析放一起。但实际上，想查"电池材料"的时候，你希望看到的是所有与电池相关的内容——不管它是概念页还是工具介绍，全部放在一起。

所以我把 Wiki 层按知识域组织，而非按页面类型：

wiki/
├── 01_技术/           # AI、编程、工具、框架
│   ├── AI与LLM/
│   └── 语音TTS/
├── 02_科研/           # 学术论文、领域研究
│   └── 电池材料/
├── 03_创意方法论/      # 灵感激发、创意思考
├── 04_工作方法/        # 内容创作、效率方法
├── 05_产品与商业/      # 产品想法、商业分析
├── 06_技术参考/        # 架构规格、参考实现
└── 07_金融交易/        # 价格行为学、市场分析

每个域下可以继续建子域，按需扩展。关键规则只有一条：内容主要讲什么，就归到哪个域。一条 AI 相关的笔记绝不放进"金融交易"的文件夹。域的分类不是一次定死的——当新内容不属于任何已有域时，就新建一个。

四、两步摄取：先分析，再动笔

这是 nashsu 对原版 Karpathy 流程最重要的增强。

Karpathy 原版的摄取是"一步到位"：读来源 → 直接写 Wiki 页面。但实际用下来有问题——LLM 读到后面忘了前面，或者跳过了不显眼但重要的知识点。就像边读菜谱边炒菜，很容易漏掉"少许盐"这种不起眼的步骤。

nashsu 把这步拆成了两段：

第一步：分析（只读不写）

从源内容中提取五个维度的信息：

这步不需要写成正式文件，但必须在脑子里（或临时笔记中）组织清楚。

第二步：生成（执行写文件）

基于分析结果实际操作：

1. 确定每个页面的操作类型——新建（该主题尚无页面）、更新（补充修正已有页面）、拆分（单页面超过 300 行，拆出独立子页面）、合并（短页面高度重叠，合并）
2. 按模板写页面，页面之间用 wikilink 互相链接
3. 把原始素材存入 raw/ 层，命名格式 YYYY-MM-DD-描述.md
4. 更新全局索引（每个页面一行摘要）
5. 追加操作日志

两步之间有明确的"心理切换"——先理解规划，再动手执行。实践下来这个分离显著减少了遗漏。

每一步都自动检查

每次摄取完成后，自动跑一遍 lint：

• 新增页面的 wikilink 指向的文件是否存在？
• 全局索引有没有漏掉任何 wiki 页面？
• raw/ 层的条目有没有对应的 wiki 页面？
• 有没有跨域重复——同一个主题是否出现在多个域？

发现问题立刻修，不攒到"以后再说"。

五、和 RAG 到底差在哪

简单说：RAG 是"搜索引擎 + 阅读理解"，LLM Wiki 是"笔记系统 + 编译器"。

RAG 适合"这堆合同里找一下违约金条款"这种一次性查档。LLM Wiki 适合"我在持续学习电池材料，每次读新论文都要和已有知识融合"这种长期积累。

六、核心设计原则总结

从 LLM Wiki 的实践中可以提炼出 7 条设计原则：

七、这个系统还不完美

诚实地说，有几个问题还在摸索中：

LLM 完全自主维护是否可靠？ Karpathy 的理念是"LLM 全权维护 Wiki"。但实际上 LLM 确实会引入事实错误。目前的做法是：矛盾信息标注而非静默覆盖，关键页面定期人工抽查。够用，但不完美。

规模上限在哪？ 原版 Karpathy 用 index.md + 页面摘要做检索，声称 100 篇/40 万字规模够用。nashsu 版加了可选的向量检索，召回率从 58% 提升到 71%。我的库目前只有 23 个页面，远没碰到天花板。但规模化后的检索策略仍然是开放问题。

跨域重复怎么处理？ 一条知识可能同时属于多个域。比如"语音合成技术"既可以放"AI与LLM"也可以放"工具与框架"。目前的规则是选主要面向——内容主要讲什么就归哪个域，跨域引用用 wikilink。但这仍然是一个需要人工判断的灰色地带。

参考

• Karpathy — LLM Wiki Gist — 原始设计思想
• nashsu/llm_wiki — 最完整的桌面应用实现
• 腾讯云：Karpathy 的 LLM Wiki — 中文解读
• 腾讯云：别再用 RAG 当"冤大头" — LLM Wiki vs RAG 深度分析