Karpathy 在2024年底抛出了 LLM Wiki 这个概念，短视频平台随即炸了锅：「RAG 要凉了」「省 95% token」「AI 知识库革命」。

我花时间认真跑了一圈，小规模确实好使，一放大就踩坑。

这篇文章做三件事：30 秒讲清 LLM Wiki 是什么、拆解 5 个没人认真说的真实缺点、给出一套理性的选型框架。

LLM Wiki 到底是什么：三层结构拆解

先把概念摆清楚，再谈优劣。

LLM Wiki 的本质，是在「原始资料」和「LLM 回答」之间插入一个结构化中间层。

三层架构：

  • Raw 层：原始资料，未经处理的文档、笔记、PDF、网页内容
  • Wiki 层：由 LLM 维护的 Markdown 知识页，结构化、去重、互相关联
  • Schema 层：规则和索引，定义 wiki 页面之间的关系和导航路径

传统 RAG 的逻辑是：用户问问题 → 检索原文 chunk → 拼装 prompt → LLM 回答。每次问都要从头检索，每次都要读原始资料。

LLM Wiki 的逻辑是：新资料进来 → LLM 通读原文、更新 wiki 页面 → 用户问问题时直接查 wiki，不翻原文。

听起来很美，对吧？

「知识先煮熟了再吃」这个比喻确实很形象。Karpathy 强调的是，重复知识不需要每次都从原文检索，应该提前编译成可复用的中间层。

但接着就来了——

缺点一：Token 没省，只是挪了个地方烧

「省 95% token」这个说法，有条件的。

RAG 的 token 消耗在「查的时候」：每次提问，检索 chunk，拼 prompt，传给 LLM。高并发场景下，token 消耗确实惊人。

LLM Wiki 的 token 消耗在「写的时候」：新资料进来，LLM 要通读原文，更新索引，改相关页面，重新总结。

Karpathy 自己提过：加一个新 source，可能要联动修改 10 到 15 个 wiki 页面。

什么时候 wiki 省 token？

  • 同一批知识被反复问（稳定知识库，高重复查询率）
  • 资料更新频率极低

什么时候 wiki 比 RAG 烧得还猛？

  • 资料更新快，每次更新都要重写 wiki
  • 问题类型杂，每次检索覆盖面广
  • 知识库在快速扩张期

结论：token 没省，只是从「查的时候」挪到了「写的时候」。场景不对，wiki 的 token 消耗是 RAG 的数倍。

缺点二：容量有天花板，而且不太高

Karpathy 原话用的是「moderate scale」，大约 100 个 sources，效果不错。

过了几百个之后，index 加链接导航就开始转不动了。

当 wiki 规模超过 5 万到 10 万 token，效率明显下降。

原因不只是上下文窗口装不下——

核心问题是：页面多了，「该看哪页」本身又变成了检索问题。

  • 页面之间的链接越来越绕
  • LLM 规划阅读路径时会漏、会重复、会走错
  • wiki 大了之后，导航层本身就需要一个 RAG 来支撑

有人把这个现象叫「RAG with preprocess」——说的没错。

你绕了一圈，最后还是在解决 RAG 本来就要解决的那些问题：如何找到相关的信息，如何避免遗漏，如何处理路径规划。

只不过现在多了一层 wiki 维护成本。

缺点三：写错了比 RAG 更难发现

这个缺点是我觉得最被低估的。

RAG 的错误通常是「这次没检索到」——一次性的，下次可能就好了。错误不会传染。

Wiki 的错误不一样：写进去，就一直在那儿。

后续的所有回答，都基于这个错误的 wiki 内容生成。

具体会出现的问题：

  • 总结时出现了错误判断，后续查询全跟着跑偏
  • 反复改写后，意思逐渐漂移（语义腐化）
  • 新资料进来，旧结论没有被正确覆盖，产生矛盾

这些错误不会报错，不会有任何明显提示。

LLM 会用错误的 wiki 内容，自信地给出错误的回答。

RAG 的问题更像一次性失误；wiki 的问题会沉淀下来，持续污染之后每一次查询。纠错成本远高于 RAG。

缺点四：高频更新的场景，wiki 基本转不动

LLM Wiki 的假设前提是：知识相对稳定。

以下场景，wiki 会非常痛苦：

  • 新闻流：每天大量新内容，每条新内容进来都要重新编译
  • 频繁改动的文档：产品需求文档、政策文件、价格体系
  • 实时业务数据：库存、价格、状态
  • 多人同时编辑的知识库：协同场景下冲突处理极其复杂

这类场景下，wiki 的维护成本是指数级的：不停地重新编译，处理冲突，清理过期页面和坏链接。

RAG 在这类场景更顺：数据更新完，重建索引就行，查的时候自动拿最新的。

一句话：wiki 是把知识攒下来慢慢用的；RAG 是随用随取的。

高频更新场景下，「慢慢攒」这件事本身就不现实。

缺点五：企业场景，基本没法用

这是最终的一刀。

企业里最头疼的是权限控制。

  • A 部门的东西，B 部门不能看
  • 不同角色看到不同内容
  • 审计要能追溯

RAG 做这些天然方便：在检索层加权限控制，某个用户的检索请求只能访问特定数据块。

Wiki 呢？

Wiki 是编译完的整体——整个 wiki 是融合了所有来源的知识中间层。你要怎么实现「只给某个人看某一部分」？

两种思路，都有问题：

  • 给每个人编一份：维护成本爆炸，N 个角色 = N 套 wiki
  • 编一份再裁剪：编译时已经混进了不该看的内容，裁剪不干净

这也是为什么 Karpathy 自己定位很清楚：个人研究工具，或者小团队玩具。

企业级知识库，wiki 方案目前距离可用还很远。

7 段文案拆解：这条视频为什么值得学

【1】开头钩子（前 3 秒）

文案：「Karpathy 方案被吹过头了，这 5 个缺点没人说」

钩子类型：反共识 × 信息缺口

这是一个经典的「反吹捧」开场。核心逻辑：权威人物 + 被过度美化 + 我有内情要说。

这个钩子的底层逻辑：

  1. 「Karpathy」是权威背书，引起关注
  2. 「被吹过头了」是反共识信号，触发好奇
  3. 「5 个缺点没人说」是信息缺口，勾着你往下看

评分：9/10。强开场，三秒把「值不值得看」这个问题解决掉了。

【2】人设 & 声音

人设标签：技术理性派 × 反炒作 × 有实测经验

「我自己跑了一圈，小规模确实好使，一放大就踩坑」——这句话完成了两件事：建立可信度（有实测），预告结论（放大有问题）。

声音风格：口语化 + 节奏快 + 不贩卖焦虑

作者没有跟风喊「RAG 要凉了」，而是提供反向的理性分析。这个人设在 AI 技术内容里反而稀缺——大多数人在喊风口，这条在泼冷水。

受众定位：看了一圈 LLM Wiki 宣传、但还没实际落地的技术从业者

【3】信息密度 & 节奏

视频时长 4 分钟，覆盖了：

  • LLM Wiki 三层结构讲解
  • 5 个具体缺点（每个独立拆解）
  • RAG vs Wiki 对比框架
  • 选型建议 + 混用方案

每个缺点控制在 30-45 秒，节奏一致，不拖沓。

节拍点设计：

  • 每个缺点有颜色编码（紫蓝粉橙红绿）
  • 文字逐行打字机式出现，引导视线
  • 每个缺点结尾有「核心对比句」收锚

这种「高密度 + 短模块 + 视觉区分」的结构，适合 AI 技术类内容，降低认知负担。

【4】讲解手法 & 内容结构

结构类型：破立式（先破「省 95% token」的神话，再立「选型框架」）

各段角色：

  • 前段（0-37s）：建立问题共识（「全网跟风」是铺垫）
  • 中段（38-196s）：逐一拆解缺点（5 个并列）
  • 后段（197-239s）：给出解法（选型 + 混用）

最强具体化手法：数字锚定

「加一个新 source，可能动到 10-15 个 wiki 页」、「wiki 量一过 5 万到 10 万 tokens，效率不如 RAG」——这些具体数字，把抽象的「token 消耗转移」变成了可感知的代价。

最强句：「wiki 就是把知识先煮熟了再吃，RAG 就是现吃现做」

【5】金句 & 记忆点

核心金句（可二次传播）：

  • 「Token 没省，只是从查的时候挪到了写的时候」
  • 「Wiki 一大，你猜怎么着，又遇到 RAG 当初要解决的那些事了」
  • 「Wiki 就是把知识先煮熟了再吃，RAG 就是现吃现做」
  • 「别非要选一个，混着用就对了」

最强记忆点：煮饭比喻

「煮熟了再吃 vs 现吃现做」这个比喻把技术差异变成了生活场景，极易传播和记忆。这是这条视频最出彩的地方——一个比喻解决了所有对比的理解问题。

可复用金句模板： 「[技术A] 就是把 [X] 先 [处理] 好，[技术B] 就是随用随 [处理]。前者适合 [稳定场景]，后者适合 [动态场景]，别非要选一个。」

【6】收尾 & CTA

收尾是选型框架总结 + 一句话比喻：

「别非要选一个，混着用就对了」

CTA 类型：认知沉锚（不是行动号召，是留下一个可重复引用的结论）。

这个结尾设计很聪明：它没有让你「马上去试试 LLM Wiki」或者「关注我」，而是给了你一个可以在下次对话里直接说出来的结论。

这类「可复用结论式结尾」比行动 CTA 更难被跳过——它让你感觉自己「学会了什么」，满足感更强，评论转发率更高。

【7】可复制文案骨架

[权威名字]+「方案被吹过头了」，这 [N] 个缺点没人认真说

我自己跑了一圈，[小规模场景] 确实好使，一放大就踩坑。

[缺点1]：[技术假设] 换了个地方 [代价]
[具体数字说明]：[对比场景A] vs [对比场景B]，[转折结论]

[缺点2]：容量有天花板
[原话/原始定位] → 实际 [数量/规模] 之后 [问题]

[缺点3]：错误更难发现
[对比方案] 错误是 [一次性] 的，[本方案] 错误会 [沉淀/传染]

[缺点4]：不适合 [动态/高频] 场景
[场景列举]：这些用 [本方案] 会很折腾

[缺点5]：[大场景] 基本没法用
最难的是 [核心需求]，[对比方案] 做起来天然，[本方案] 很难裁剪

选型结论：
→ [本方案] 适合：[场景A/B/C]
→ [对比方案] 适合：[场景D/E/F]
→ 最稳的是混着来：[本方案] 做 [X]，[对比方案] 做 [Y]

一句话：[本方案比喻] vs [对比方案比喻]，别非要选一个。

四角度反思：这条视频对我们意味着什么

对【我们】做的事

LLM Wiki 和 RAG 的选型困境，直接影响橙子知识库的架构决策。

橙子目前运行的知识库（~/橙子知识库 + Obsidian），本质上更接近 LLM Wiki 的思路：先把知识编译成判断卡，复用时直接用，不每次去原始资料里检索。

可落地动作：

  • 判断卡（LLM Wiki 思路）适合橙子自己的经验沉淀——稳定、高频复用、个人工具
  • 原始信息检索（RAG 思路）适合群友问题检索、外部知识库查询——动态、多样、权限隔离
  • 两者混着用已经是现实——不需要刻意取舍，认清各自边界即可

视频给的框架直接能用于橙子知识库的维护策略调整。

对【橙子自己】有什么帮助

学到一种很好的「反炒作」内容生产框架。

「[权威名字]方案被吹过头了 + N 个缺点 + 理性选型」这个结构，是 AI 技术内容里极具传播力的范式：

  1. 不跟风鼓吹，而是做理性分析
  2. 有实测经验做背书（不是空谈）
  3. 结论落地：场景选型 + 混用建议

以后橙子遇到类似「某某技术被过度神化」的情况，可以直接套这个破立框架：先破神话（有数据有细节），再立选型（有场景有边界），最后给混用建议（不极端）。

金句提炼技巧也值得复制：找到两个方案最本质的区别，用一个日常场景比喻，一句话说清楚。「煮熟了再吃 vs 现吃现做」这类比喻的构造方法可以迁移到很多技术对比内容中。

对【老大的机构】有什么帮助

公考培训内容的知识库建设，正好卡在 LLM Wiki vs RAG 的岔路口。

公考知识有两类：

  • 稳定知识（申论框架、行测逻辑、历年高频考点）→ 适合 wiki 思路：提前结构化，复用率高，橙子反复查不重复检索
  • 动态内容（新政策文件、时事素材、真题解析更新）→ 适合 RAG：随时更新，查时拿最新，不需要每次重新编译

具体落地建议：

  • 建两套索引：高频稳定内容走 wiki（申论素材库、行测知识点）；时效内容走 RAG（政策、时事）
  • 不要把所有内容都往 wiki 里打——新出的政策文件直接向量化检索就够了，不用花代价「煮熟」它

这个分层本来就是合理的知识库架构，视频给的框架帮助验证了这个方向。

对【未来发展】有什么帮助

「Karpathy 方案被过度吹捧」这个现象本身，是一个信号。

每次顶级研究员抛出一个新概念，市场的第一反应总是「一切都要变了/旧方案要凉了」。实际上：

  1. RAG 不会凉：它解决的问题（动态知识检索、权限控制、实时更新）在企业场景里无法被 wiki 替代
  2. LLM Wiki 有真实价值：个人研究、内容创作、小团队知识沉淀——这些场景 wiki 真的更好
  3. 「混合架构」是未来方向：不是谁替代谁，而是各管各的边界

趋势判断：

  • 未来 2-3 年，「知识库中间层」会成为 AI 应用的标配——不是 wiki 或 RAG，而是根据内容类型动态选择架构的「自适应知识层」
  • 企业级 AI 的权限控制需求会推动 RAG 进化，而不是转向 wiki
  • 个人 AI 工具（橙子这类）更适合 wiki 思路，但需要配合手动维护避免错误传染

可布局的方向：在公考 AI 产品中，明确区分「稳定知识库（wiki 式）」和「动态知识库（RAG 式）」，这本身就是架构竞争力。

值得借鉴的 5 条判断

判断一：「省 token」的宣传需要追问「在哪个环节省/在哪个环节烧」

省 95% token 的说法不是谎言，但是条件句。任何技术宣传里的「省 X%」，先问「省的是哪步的，烧的是哪步的，场景是什么」。

判断二：规模是一切技术方案的照妖镜

小规模好使的方案，放大了可能完全失效。LLM Wiki 在 100 sources 以内很优雅，几百页 wiki 之后导航本身就成了问题。评估任何 AI 方案时，先问「1000 倍规模下还成立吗」。

判断三：错误传播路径决定系统的可维护性

RAG 的错误是「一次性失误」；wiki 的错误是「沉淀性污染」。系统设计时，宁要高频小错误，也要警惕低频但能扩散的错误——后者的维护成本是指数级的。

判断四：「混用」往往比「非此即彼」更接近正确答案

「wiki 还是 RAG」这个问题，正确答案几乎从来不是「选一个」，而是「用来做什么、对什么数据」。任何「A vs B」的技术对比，最终的理性结论往往是「视场景而定 + 边界清楚时混用」。

判断五：权限控制是企业场景的 make-or-break 能力

LLM Wiki 在企业场景失败的核心原因：权限控制做不了。这个教训普适：任何面向企业的 AI 方案，如果不能在检索层或推理层精确控制「谁能看什么」，就不要指望企业买单。

选型指南：用这张表做决策

场景推荐方案原因
个人研究/内容创作LLM Wiki知识稳定，高频复用，无权限需求
小团队主题知识沉淀LLM Wiki同上，规模可控
长期跟踪单一领域LLM Wiki深度积累，知识逐渐熟化
企业知识库RAG权限控制，海量文档，多角色
高频更新的内容RAG实时性，重建索引即可
客服/高并发问答RAG低延迟，查询时成本可控
概念梳理 + 事实核验混用Wiki 做沉淀，RAG 做召回校验

最稳的策略：Wiki 做概念梳理和关系沉淀，RAG 做原文召回和事实校验。

两者不是竞争关系，是互补关系。

一句话总结

Wiki 就是把知识先煮熟了再吃，RAG 就是现吃现做。

前者适合天天吃同一桌菜的人，后者适合随时逛超市买新鲜的。

别非要选一个——混着用，才是真正理性的技术决策。