Karpathy 的 LLM Wiki 两周后:维护这件事他看对了,但规模一大就撑不住

两周前我写了第一篇 ceiling 文章,里面讲了三个撞墙点:schema 层本质上是编程任务、Agent 已经不住在你的笔记本上、lint 到几百页之后就做不动。

这一篇我想写得锋利一些。一半是因为我欠几处修正,一半是因为这两周里社区做出来的东西,比我上一篇本身能讲的更多。

看过上一篇的可以跳过回顾段。没看过的,一句话版本:LLM Wiki 这套模式,讲"瓶颈在哪"讲对了;讲"出了个人规模该怎么办",则完全没说。 这一篇是证据。

Karpathy 讲对的那一条(我想反复说)

任何长期运行的知识库,瓶颈不是检索,是维护。

交叉引用会腐烂,摘要会和源头偏离,概念页会慢慢重复。大多数个人 wiki 最后死掉,从来不是因为找不到东西,而是因为没人愿意继续维护。Karpathy 把这一点讲透了:LLM 是唯一有耐心、够细心、边际成本几乎为零的东西,它可以一直把这份维护工作做下去。

他给的最有杀伤力的那一招叫 file-back:一次查询产出了有价值的东西,就把它写回 wiki,变成新的页面。对话从此不再只消耗上下文,而开始生产上下文。

这一条我没看到任何严肃的反驳。这两周里所有高质量的回应,都接受了这个前提,争的只是实现怎么做。

个人规模这块甜蜜区,以及 Karpathy 自己给的补丁

这里我要先修一处上一篇写得含糊的地方。

原 gist 里有一句"works surprisingly well at moderate scale"——大约 100 篇源资料、几百页编译出来的 wiki。我上一篇有时候把它写得像 Karpathy 给这套方案划了条硬上限。他没有。这是经验上观测到的甜蜜区,不是架构上的定理。

更重要的是:在 gist 的 "Optional: CLI tools" 一节,Karpathy 明确推荐了 qmd。qmd 是一个 CLI 工具,做 BM25 + 向量检索 + LLM 重排,自带 MCP server。他建议你在 wiki 长大到 index.md + grep 开始撑不住时用上它。

这一点重要,因为很多解读——包括我上一篇的某些措辞——把 LLM Wiki 放进了"file 派 vs RAG 派"的路线之争。那是误读。Karpathy 并不反对向量检索,他反对的是在个人规模就过早搭一套复杂的 RAG 基建。他自己说得清楚:wiki 长大之后,你会想要一个像样的检索层。

gist 没回答的有意思问题是:当"个人规模"变成别的什么——多设备、多 Agent、一个团队、一个要从托管 API 读你知识库的产品——那一层"像样的检索层"应该长什么样?这正是两周社区工作走向的方向。

出了个人规模会在哪里撑不住:三处证据

我不打算从头论证,社区已经把活干完了,方向很难看错。

1. rohitg00 的 LLM Wiki v2:混合检索是必须,不是可选

Rohit 把 LLM Wiki v2 的定位写得很明确:"extending Karpathy's pattern with lessons from building agentmemory"。它跑 BM25 + 向量检索 + 一个 582 节点的知识图谱,用 Reciprocal Rank Fusion 融合排序,每个节点带置信度评分。在 LongMemEval-S 这个长程记忆 benchmark 上,它拿到 95.2%。

他给的架构理由很直接:扁平的 index.md 查找在 200–500 文档之后会显著退化。 不是因为 token 不够,而是因为 LLM 要在上千个候选项里做相关性判断时,注意力会稀释——而你判断不出来什么时候开始稀释、漏掉了什么。

这是关于 LLM Wiki 天花板最硬的一条数据:已经有跑通了的、带 benchmark 的替代方案,而它默认就把混合检索当成底层假设。

2. gulliveruk 的原则:scoping 该确定,reasoning 才概率

gist 评论区里被引用最多的一句,是 gulliveruk 写的:

Scoping should be deterministic. Reasoning should be probabilistic.

翻译成实操:Agent 在判断"哪些知识和这个 query 相关"时,那是一个集合操作。你要的是一个确定性的预过滤(向量相似度、tag 匹配、图边)来缩小候选集。你不想让 LLM 花 token 去扫一份上千行的索引,然后悄悄从注意力里漏掉一些。

LLM 是在预过滤完的小集合上做推理的正确工具。它不是做预过滤本身的正确工具。

这一句直接诊断出纯 index.md 模式为什么会快速变脆——它让 LLM 去做本该在 query 层就接住的集合操作。

3. Graphify:同一个天花板,从另一个角度凿

safishamsi/graphify 发布 48 小时就拿了 2,000+ stars。它把 Karpathy 方案里 index.md + LLM 重排那一整套换成了图拓扑。

具体做法:代码侧用本地 tree-sitter 解析,零 token 消耗;非代码侧用并行 LLM 子代理做语义抽取;之后用 Leiden 社区发现算法 在边密度上做聚类。附 SHA-256 缓存、文件监听、Git 钩子集成。一行命令:/graphify .

Graphify 为什么存在、为什么 48 小时就火,跟 rohitg00 的混合检索是同一个原因:原版 index.md + grep 工作流到一定规模就放不下了。 Graphify 选择完全跳过 embedding,押图拓扑;rohitg00 选择两个一起上。哪个更好不是重点。重点是:同一周里两个独立做的、最 starred 的模式扩展,都在原版没有的地方加了一层结构化检索。

这是高质量技术讨论里,最接近"共识"的一个结果。

产品化并扩展,而不是"我们干赢了 Karpathy"

我在做 KnowMine,想把它在这个语境里的定位说清楚。

KnowMine 不是"一个更好的 LLM Wiki"。Karpathy 的 gist,按他自己的说法,是一份思路文件——故意写得抽象,设计来被 copy-paste 到任意 coding Agent 里,让 Agent 自己去落地。它不是一个产品。KnowMine 是同一个洞察,被产品化并扩展之后的样子。

产品化具体指什么:

• Schema 层预装出厂。 你不需要从空白文件开始写 AGENTS.md。19 个工具组成的 MCP 接口就是 schema。每次 add_knowledge 调用都会自动做标题抽取、tag 推断、folder 归类,不需要你写一行配置。
• 检索从第一条知识起就是混合的:语义预过滤、类型化关联、版本历史——而不是等到 500 条门槛才拼装上去。
• 接口是 MCP,不是本地文件系统。 任何 MCP 兼容的运行环境——Claude Code、ChatGPT、Cursor、OpenCode、跑在 VPS 上的定时 Agent——读写的是同一个知识库。三档权限模板(只读 / 读写 / 完全控制)让 Agent 跑在不完全可信的环境时,你仍能约束它能碰什么。

扩展具体指什么:

• file-back 是一个工具调用,不是手动步骤。 add_knowledge 在 LLM 判断"这东西值得留"的瞬间就写回。没有"先丢文件再跑 ingest"的那个循环。
• 类型化关联是显式的,不是从 [[wikilinks]] 解析出来。 add_knowledge_link 让 LLM 明确声明两条知识为什么相关:based_on(基于)、refutes(反驳)、extends(扩展)、evolved_from(演化自)、related_to(相关)。这张图是有意的,不是偶发的。
• 版本历史内置。 每次有意义的更新都通过 get_knowledge_history 留下版本记录。"lint"这件事——什么过期了、什么被反驳了、一个决策是怎么一步步演化的——有了可以运行的底层。
• 记忆和知识分开存。 add_knowledge 存文档、文章、想法;save_memory / recall_memory 存决策、教训、偏好、领域见解。大多数个人 wiki 把这两类混在一起,后来慢慢付代价:模型分不清一页到底是"关于世界的事实"还是"你持有的立场"。KnowMine 在工具层就把这条线画开。
• Soul。 同一套接口里还有 generate_soul / get_soul——根据累积记忆和知识生成的用户画像,可以按需刷新。你换 Agent 时,新 Agent 读一下你的 Soul,就开始表现得像它认识你。Karpathy 的 wiki 给 Agent 的是你的知识,KnowMine 还给它一个关于你的模型。

KnowMine 诚实的定位是这一句:它把维护瓶颈从 LLM 上下文窗口,迁到了一个可工程化的检索与数据层。这不是"没有瓶颈",是"一个我们知道怎么监测、扩容、付费的瓶颈"。

一条迁移路径,benchmark 在路上

如果你已经在 Karpathy 风格的 wiki 上投了时间,也长出了超过个人规模的甜蜜区,你不需要把它丢掉。

作为这篇的后续,我会发一个 Karpathy-pattern → KnowMine 迁移 skill。它接收一个本地 wiki 目录(标准的 raw/ + wiki/ + index.md 结构),用 add_knowledge 批量写入每一页,把 [[wikilinks]] 解析成 add_knowledge_link 的类型化关联,最后给你一个可以从任意 MCP 运行环境访问的 workspace。

为了让这个对比是数据驱动、不是市场话术,skill 发布时会配一个公共数据集的 benchmark(≈100 篇 arXiv 上的 ML 论文,按 Karpathy 风格的 schema 导入)。同一组 20 个问题,三档配置:

1. index.md + LLM 导航(Karpathy 原生)
2. BM25 + 向量(qmd 或等效方案)
3. KnowMine MCP(语义预过滤 + 类型化关联 + 版本历史)

四个指标:召回(相关知识有没有被找到)、引用准确度(答案有没有指对源)、成本(token + API 调用 + 实际耗时)、人工修正量(答案需要多少编辑才能用)。

数字会放在 migration skill 的发布文章里,不在这一篇。我宁愿先发方法论、等真数据出来再发结果,也不要发一堆听起来合理但没有证据的说法。

诚实的边界

如果你在做个人研究,用一个 coding Agent、一台笔记本、Karpathy 的 pattern 对你跑得通——不要动。 那个场景下它就是对的答案。gist 写得极好,qmd 推荐能接住你大部分成长。

KnowMine 是写给以下三件事中至少有一件变了的人:

• 规模。 几百条之后你会想要确定性的预过滤。LLM 负责 reasoning,不负责 scoping。
• 运行环境。 你的 Agent 不再只是笔记本上的 Claude Code,也是手机上的 ChatGPT、Slack 里的 bot、VPS 上的定时任务。文件走不到那些地方,协议可以。
• Schema 所有权。 你不想从零写 AGENTS.md。你想要合理的默认值,外加后期可以调的选项。

如果这三件都没变,LLM Wiki pattern 正在做它该做的事。这不是话术,我自己也会从那里起步。

收尾

Karpathy 的 LLM Wiki,在唯一一件真正重要的事情上讲对了:维护才是真正的工作,而 LLM 是唯一会有耐心把它做下去的东西。其他都是实现选择。

两周的社区工作把实现选择讲清楚了。几百条之后,混合检索不是可选的。集合操作该在 query 层,不该占 LLM 的注意力。图结构是扁平索引的真正替代。Agent 一走出笔记本,pattern 就撑不住了。

KnowMine 是这组实现选择中的一种,一致、作为产品发布。同样会复利的知识,同样的 file-back 循环,没有本地锁定。

如果你已经在撞天花板,migration skill 下周发,benchmark 数字一起发。