写给那些被各种「RAG解决方案」和「LLM Wiki教程」淹没的人。先说一个常见的误解很多人聊 RAG上来就问「你用什么向量数据库分块策略怎么定召回率多少」这个问题本身就错了。RAG 不是一种架构。它是一种原则——用检索来增强生成。检索什么怎么检索增强哪一段生成这些问题没有标准答案因为答案取决于你想让AI更好地回答什么问题。LLM Wiki 也是一样。Karpathy 到底在说什么最近 Karpathy 在 一份 Gist 里分享了他的个人知识管理方法。他没有提供什么「LLM Wiki 架构图」只是描述了一个工作流你把来源丢给 LLM → LLM 提取知识、更新 wiki → 你基于 wiki 提问 → LLM 回答并标注来源听起来很简单对吧但真正有价值的部分不在这个流程里。有价值的是LLM 在维护什么它在做这些事情知识抽取从原始来源里提取实体、概念、关系写成结构化的 wiki 页面关联维护每当新来源进来更新所有相关的交叉引用矛盾标注当新数据和老知识冲突时标注出来一致性检查定期 lint找出孤立的页面、过时的声明、缺失的链接这些「脏活累活」才是让知识库真正有用的东西。为什么 RAG 没能做到这一点传统 RAG 的问题不是技术是时机。RAG 在「查询时」才做检索——每次都是临时抱佛脚。LLM 需要综合五份文档来回答一个问题那就找五份文档拼凑起来下次再找一次。没有积累。没有关联维护。没有「知识已经在那儿了」的底气。LLM Wiki 的关键区别在于知识被编译一次然后保持最新而不是每次查询时重新推导。打个比方RAG 像图书馆的「自助借阅系统」——你要什么自己找找完就走LLM Wiki 像有人帮你把书读薄了还画好了知识地图你要的时候直接用所以重点是什么不是用什么工具不是用什么格式不是分块大小不是向量维度。重点是这三个问题我需要维护哪些知识决定了你要摄入什么来源知识之间是什么关系决定了你的 wiki 结构要不要分领域、要不要维护交叉引用谁来维护这些关系决定了你要不要让 LLM 帮你做 lint、要不要定期检查矛盾这三个问题回答了工具自然就选对了。Karpathy 的方案里用的是 Obsidian LLM Agent。GitHub 上有人实现了 karpathy-llm-wiki用的是 Agent Skills。都可以。这些都是实现细节。真正重要的是你想让 LLM 帮你管理知识而不是每次都重新发现知识。人类做不了的LLM 做得更好维护知识库最累的部分是什么不是读书不是思考。是在读了很多书之后还能记住更新哪些交叉引用、标注哪些矛盾、合并哪些重复内容。人类做这个会累会忘会放弃。LLM 不会。它可以一次处理 15 个文件更新所有受影响的页面把矛盾标记得清清楚楚。这不是魔法这是因为LLM 擅长的是「按照规则系统性地做大量文本操作」而知识维护恰恰就是这类工作。所以 Karpathy 说Obsidian 是 IDELLM 是程序员wiki 是代码库。你不需要写代码你只需要提出问题和检查结果。怎么开始不需要一开始就搭一个完美的系统。从一个简单的结构开始然后做三件事摄入每次读到有价值的内容让 LLM 帮你写成 wiki 页面查询有问题先问 wiki看 LLM 怎么用已有的知识回答Lint定期让 LLM 检查 wiki 的健康状况不需要完美。wiki 会随着时间自己变好。总结RAG 不是架构LLM Wiki 也不是。它们都是一种关于知识管理的原则——知识要积累、关系要维护、回答要基于整理过的内容而不是每次重新检索。区别只在于谁来维护这些关系RAG 是人来维护索引隐性地。LLM Wiki 是让 LLM 来显性地维护这些关系。你想让 LLM 成为你的知识库管理员而不是每次都在临时检索。做到这一点很多「工具选型」的问题就自然消失了。