从 RAG 到 LLM Wiki：为什么我放弃了向量数据库

两种知识架构的哲学差异，为什么纯文本在个人尺度上赢了

作者：一只阿木木我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统。

每个认真研究过 RAG 的人都经历过的事

2024 年，“RAG” 这个词突然火了。

技术博客、播客、YouTube 教程——到处都是 RAG 教程。你学了一个周末，搭出了一个 demo：把 PDF 切成块（chunk），跑 embedding，丢进 Pinecone，查询时检索 top-K，拼接进 prompt。

它可以工作。真的可以工作。

然后你把它真正用在自己的知识管理上——几十篇论文，几百条笔记，两年的技术文档。

结果：

你问"我们当时为什么放弃了 Celery"，它给你返回了三段关于 Celery 的通用介绍，都来自你 ingest 进去的技术文档。跟你的决策历史毫无关系。

你问"JWT 和 Session 鉴权方案有什么区别"，它检索到了五段相关的内容，但这五段各自说了不同的事——有的互相矛盾——它不知道怎么综合。

你的问题越复杂，答案越让你失望。

你以为问题是 embedding 模型选得不好。换了一个。还是一样。

你以为问题是 chunk size 调得不对。调了十几次。有改善，但根本性的问题还在。

后来你才意识到：问题不是参数调得不好，而是整个架构的设计哲学本身有一个隐藏的天花板。

这篇文章就是要把这个天花板说清楚，然后告诉你 LLM Wiki 模式在什么情况下是更好的答案，在什么情况下不是。

读这篇文章的前提：我不是在否定 RAG

在深入之前，我需要先说清楚一件事：

这篇文章不是 RAG 的批判文。

RAG 已经成为企业 AI 的主导架构，2026 年的企业采用率从 2025 年的 40% 上升到了 85%。这个数字本身说明 RAG 是有效的——对于它设计来解决的问题，非常有效。

这篇文章要做的，是把一个经常被模糊处理的问题说清楚：

RAG 和 LLM Wiki，不是两种实现同一件事的方式。它们在解决不同的问题。混淆这两件事，会让你在错误的场景里用错误的工具。

搞清楚这一点之后，你才能做出真正理性的架构选择。

第一部分：RAG 到底在解决什么问题？

要理解 RAG 的局限，必须先理解它的设计初衷。

RAG 诞生于 2020 年。它源自 Lewis 等人的研究论文，作为一种用动态外部检索来增强 LLM 静态参数知识的方法。

当时的背景是：LLM 的上下文窗口很小（GPT-3 是 4K tokens），但用户想查询的知识库可能有几十万、几百万个文档。怎么办？

答案是：把文档切成块，在 ingest 时嵌入向量存储，在查询时检索语义上最相似的 top-K 块，注入 LLM 的上下文窗口进行合成。

这个设计思路的核心假设是：上下文窗口是稀缺资源，所以你必须在查询时精确检索最相关的内容，而不是把所有内容都加载进来。

在这个假设成立的情况下，RAG 是最优解。

但这个假设，在 2026 年正在发生根本性的变化。

第二部分：RAG 有三个根深蒂固的局限

局限 1：Chunking 破坏了上下文完整性

RAG 的第一步是把文档切成 chunk。这一步看似无害，实则是整个架构里最大的隐患。

把数据切成小块会丢失上下文——想象一本书的书页被打乱了。

问题在于：知识的意义往往不在单个段落里，而在段落之间的关系里。

如果一份医疗报告在第 1 段提到了症状，在第 5 段提到了诊断，标准的 chunking 会把它们当作无关的事实来处理。

程序员场景里这个问题更明显：一个函数被从它的类里切出来，就失去了继承信息。一个方法被从它的调用者里切出来，就失去了使用模式。

你调了多少参数，都是在给一个有缺陷的基础做补丁。如果 chunk 切得很差，所有下游的操作都变成了昂贵的创可贴：reranker、更大的 K、更长的 prompt，更多的"推理"。

局限 2：相似 ≠ 相关，向量检索有盲点

RAG 的检索逻辑是：找到和查询语义最相似的 chunk，认为它就是最相关的内容。

这个逻辑在简单查询时没问题。在复杂查询时，它有一个本质性的盲点：向量搜索可能混淆相似文档——如果你搜索"模型 A 和模型 B 的区别"，系统经常检索到同时提及两者的文本，却没有区分它们，生成混合且不准确的回答。

更深的问题是多跳推理（multi-hop reasoning）的失败：

多跳失败发生在答案需要连接多个独立事实的时候——一条需要 RAG 经常断掉的推理链。标准 RAG 从本质上就会破坏上下文，它把文档切成孤立的 chunk，根据语义相似性找到它们，然后希望 LLM 能把拼图拼回去。 在 HotpotQA 多跳数据集上，传统 RAG 的准确率只有 41%。对于需要跨文档推理的问题，一半以上的回答是错的。

局限 3：重推理发生在查询时，每次从零开始

这是 RAG 最被忽视、但最根本的架构局限。

Embedding 生成发生在 ingest 时。但繁重的推理——合成、生成答案、多跳推断——发生在查询时，每次调用都重来一遍，没有任何记忆曾经做过这件事。

把这句话的含义想清楚：

你问了一个关于"我们的鉴权架构"的问题。RAG 从五十个文档里检索相关 chunk，花了大量推理 token 把它们综合成一个答案。

你明天问一个稍微不同但本质相同的问题。RAG 重新检索，重新综合，重新消耗同样数量级的推理 token——尽管答案的核心内容和昨天的基本一样。

知识没有积累。理解没有复利。每次查询都在重新造轮子。

Naive RAG 默认是无状态的——每次查询从零开始，随着问题变得更复杂，合成质量会退化。

第三部分：LLM Wiki 在哪里做了根本性的不同选择

现在可以来说 Karpathy 的 LLM Wiki 模式了。

LLM Wiki 和 RAG 的区别，是编译时 vs 查询时的知识组装，而不是智能程度的差异。

这句话很关键，值得展开解释。

从"查询时推理"到"编译时推理"

RAG 的设计是：在查询时做推理。你问问题，系统才去读文档、综合答案。

LLM Wiki 的设计是：在 ingest 时做推理。你把资料加进来，系统就立刻读懂它，和已有知识交叉融合，把结果写进结构化的 wiki 页面。查询时只是在已经理解好的知识图谱里导航。

用软件工程的类比：

• RAG 像是解释型语言——每次运行都重新解析源代码
• LLM Wiki 像是编译型语言——先编译一次，之后每次执行的是优化后的二进制产物

Karpathy 的原始设计：三层结构

Karpathy 的原始 Gist 描述了一个三文件夹系统：raw/ 存放原始材料，wiki/ 存放 LLM 编译的摘要文章，以及一个 index.md，它映射所有文章，大小适合放进单个上下文窗口。LLM 首先读取 index.md，然后按需拉取具体文章——不需要 embedding 步骤，不需要向量搜索，不需要检索流水线。  LLM Wiki 模式是一种用纯文本文件构建持久化、Agent 可读的知识库的方法——文件组织得像一个 wiki。 AI Agent 可以直接读取这些文件，跨文件综合信息，并且——关键的——随着它学到新东西，可以把更新写回这些文件。

为什么 index.md 是整个系统的核心创新

Karpathy 的 LLM wiki 用一个 index.md 文件作为导航地图，让 Agent 不需要语义搜索或向量数据库就能找到信息。 大多数关于给 AI Agent 提供知识访问的讨论都假设同样的基本架构：切块文档，embedding 进向量数据库，检索最语义相似的块。这已经成了默认选择。但有一个更安静的方式正在 AI 从业者中获得牵引力——一种完全跳过向量数据库、而是给 Agent 一个更接近目录的东西的方式。

这个"目录"就是 index.md。它让 LLM 在加载任何内容之前，先知道"知识图谱里有什么"，然后精准地只拉取需要的部分。

第四部分：Token 效率——一个让数字说话的对比

这是最能说明两种架构差异的地方。

RAG 的 Token 成本结构

每次查询的成本：

text

1. 生成查询的 embedding（小，可忽略）
2. 向量搜索（基础设施成本，不是 token）
3. 检索 top-K chunk，注入 prompt
   → 如果每个 chunk 平均 500 tokens，top-5 = 2,500 tokens
   → 加上原始查询和指令，每次查询约 3,000-5,000 tokens
4. LLM 合成答案（每次从零推理）

关键点：这个成本在每次查询时重复发生。

最重要的是，成本随查询量线性增长，因为每个问题都要付 embedding、向量搜索和扩展上下文窗口的费用。 企业级 RAG 的隐性成本：在每月 5000 万次查询时，扩展上下文窗口的额外开销达到每月约 43,750 美元，根据 Stratagem Systems 2026 年 3 月发布的分析。

LLM Wiki 的 Token 成本结构

Ingest 时的成本（只付一次）：

text

读取原始文档 + 和已有 wiki 交叉对比 + 写入新页面
→ 每个文档约 40,000-60,000 tokens（一次性）

查询时的成本（每次）：

text

读取 index.md（约 1,000 tokens）
+ 拉取相关页面（约 2,000-3,000 tokens）
→ 每次查询约 3,000-4,000 tokens

总 ingest 成本：大约 40,000-60,000 tokens（输入+输出）。这个成本每个来源只付一次。 后续针对编译好的 wiki 的查询成本要低得多——通常只需要 index.md 加 2-3 个文章页面。

用一张表对比：

很多团队一开始直接把完整文档——整个 PDF、完整的政策手册、非结构化文本——加载进上下文。一个策略文档可能有 20,000 tokens。加载三个就到了 60,000 tokens，不管其中多少内容是相关的。而涵盖同样事实的一个精心策划的 LLM wiki，写得简洁，可能只有 2,000-3,000 tokens。 Karpathy 推广了这个概念，对于小型、聚焦的知识库，与直接加载文档相比，它可以把 token 用量削减高达 95%，同时大幅降低系统复杂度。

第五部分：两种架构处理"复杂问题"的方式差异

这是最能体现本质差别的地方，我用两个具体场景来说明。

场景一：“我们的鉴权方案为什么选了 JWT？”

RAG 的处理方式：

检索包含 “JWT” 关键词的 top-K chunk → 返回几段 JWT 的介绍和比较 → LLM 尝试合成答案

结果：你得到的是关于 JWT 的通用信息，而不是你们团队当时的决策背景。因为"决策背景"分散在会议记录、ADR、Slack 历史记录的不同 chunk 里，向量检索不知道要把它们连起来。

LLM Wiki 的处理方式：

ingest 阶段，系统已经把 RFC-012、ADR-037、相关会议记录里的内容综合成了 wiki/decisions/auth-strategy.md，页面里清楚写着：选 JWT 是因为客户端是第三方 iOS 团队，不支持 Session 方案，以及当时对比过的所有选项。

查询时，Agent 读取 index.md，定位到 auth-strategy.md，直接给你这个答案，并附上原始来源链接。

这就是"预编译"和"每次从零推理"的区别。

场景二：“RFC-012 和 ADR-037 有没有矛盾？”

RAG 的处理方式：

这个问题本质上需要同时读取两个文档并对比。RAG 会检索到两个文档的相关 chunk，但 chunk 是独立的——标准 RAG 流水线把检索到的段落当作独立的、非结构化的文本块处理，强迫模型隐式地连接分散在碎片化上下文中的信息。

LLM 不一定能发现矛盾，因为矛盾的两端可能在不同的 chunk 里，中间没有显式的连接。

LLM Wiki 的处理方式：

在 ingest ADR-037 时，系统已经把它和已有的 RFC-012 对比过了。如果发现矛盾，wiki 页面上已经打了 [!contradiction] callout，矛盾登记册里也已经有了记录。

查询时，矛盾是已知事实，不需要实时推断——因为推断在 ingest 时就做了。

第六部分：两种架构的本质哲学差异

现在可以把最核心的差异用一个框架说清楚了。

两种架构更深层的问题不是选哪个工具，而是：繁重的推理工作发生在哪里——以及这个选择的后果是什么？

索引导航方式更透明、更可预测；RAG 在更大型、更非结构化的语料库上处理得更好。 透明度与效率的张力：可编辑的 Markdown 对抗黑盒检索。

第七部分：不要被"95% token 节省"误导——两个关键细节

你可能已经在想：“那我应该完全切换到 LLM Wiki！”

等一下。先搞清楚两个关键细节，否则这个决定会让你后悔。

细节 1：ingest 时的 token 成本是真实的代价

LLM Wiki 的 token 节省，是查询时的节省。代价是 ingest 时更高的 token 消耗。

成本方面：wiki 编译会消耗前期 token（比如处理 100 个文档），RAG 把成本推迟到查询时。

这意味着：

• 如果你的知识库变化很快（每天新增大量文档），ingest 成本会很高
• 如果你的知识库相对稳定，ingest 成本摊薄后，LLM Wiki 在长期来看更便宜
• 如果你的查询量很大（每天几百次查询），LLM Wiki 的查询成本优势会非常显著
• 如果你的查询量很小（每天几次），两者的成本差异并不大

细节 2：幻觉可能被"固化"进 wiki

这是 LLM Wiki 最大的潜在风险，也是最容易被忽视的。

幻觉不会消失：Ars Technica 的研究人员 2025 年指出，“RAG 不是直接的解决方案，因为 LLM 仍然可以在检索到的材料上幻觉。”

在 RAG 里，幻觉发生在查询时——每次查询都是独立的，一次错误答案不会污染下一次。

在 LLM Wiki 里，幻觉可能发生在 ingest 时——如果 LLM 误解了一个来源，这个误解会被写进 wiki 页面，之后所有基于这个页面的查询都会受影响。

这就是为什么：

1. raw/ 目录里的原始文档永远不能被修改
   ——它是最终的权威来源，当你怀疑 wiki 内容时，可以回头核对
2. lint 操作不是可选的
   ——定期运行，检查内容一致性，发现可能的错误
3. 来源链接是强制的
   ——每个 wiki 页面里的声明，都要能点进去看到原始文档

很多关于 LLM Wiki 的讨论——包括正式的 ingest/lint/query 操作、严格的架构边界和治理层——来自社区实现和博客阐释，而不是原始 idea 本身。Karpathy 的 Gist 是起点，不是规范。

这句话很重要：你需要自己判断哪些约束对你的场景是必须的，而不是盲目照搬。

第八部分：适用边界——谁应该用哪个？

LLM wiki 在 token 效率和个人尺度的简洁性上胜出；当知识超过上下文窗口限制、需要多用户动态访问时，RAG 胜出。

用 LLM Wiki 的场景

LLM wiki 在 token 效率和简洁性上，对小型、稳定、个人尺度的知识库胜出——大约低于 100-200 篇文章和 50,000-100,000 tokens。

具体来说，你应该选 LLM Wiki，当：

• ✅ 你的知识库是个人或小团队的，不需要多用户并发访问
• ✅ 你关心的是"深度理解"而不是"广度检索"（研究、决策、写作）
• ✅ 你的知识有明确的主题聚焦（某个技术栈、某个行业）
• ✅ 你希望系统随时间变得更聪明，而不只是更大
• ✅ 你想要完全可解释的、人类可读的知识存储

LLM wiki 方式是在你的知识库小、聚焦、相对稳定时的正确选择。具体来说，当你整个知识库低于 50,000-100,000 tokens 时，没有技术上的理由要用 RAG。

用 RAG 的场景

RAG 表现良好的场景：大型、动态的文档语料库；单轮事实查询；知识库变化频繁的场景；以及在数千个文档中广度比深度更重要的企业搜索。

具体来说，你应该选 RAG，当：

• ✅ 知识库规模超过 10 万文档（企业级）
• ✅ 需要多用户并发访问和权限控制
• ✅ 知识更新极其频繁（新闻、市场数据）
• ✅ 查询需要跨越大量不同领域（HR + 法务 + 财务）
• ✅ 需要满足企业数据治理要求

企业层面的限制同样诚实。当文档数量达到数千、作者数量达到数百、访问策略需要强制执行时，wiki 在规模上会崩溃。

混合方案：两者并用

对于介于中间的场景，中等规模用例的最强方案是混合：用编译好的 wiki 存储稳定的核心知识，加上 RAG 处理动态或溢出内容。

根据 Techment 收集的数据，到 2026 年底，75% 的企业应用将使用混合架构，把这三种方式结合起来，而不是只选一种。

第九部分：一个更深的视角——上下文窗口革命正在改变游戏规则

最后还有一件事值得说清楚，因为它会影响未来几年的架构选择。

chunk-and-retrieve 模式是为一个上下文窗口只有 4K tokens 的世界设计的，当时 embedding 是压缩知识的唯一方式。当 Gemini 发布 1M+ 上下文、Claude 随后跟进，这个世界就结束了。上下文窗口竞赛改变了这个问题的物理性质。创造了标准 RAG 的那个约束已经不存在了。

这是一个根本性的变化。

当上下文窗口还很小时，"只检索最相关的内容"是唯一的选择。当上下文窗口足够大，你有了另一个选择：把预编译的结构化知识整个放进去。

50,000-100,000 token 阈值是 LLM Wiki 变得不实用的地方。低于这条线，直接文件读取方式比 RAG 流水线更简单、更可靠、每次查询成本更低。超过这条线，你就需要语义搜索——在上下文窗口的信息论限制面前没有捷径。

这条边界会随着上下文窗口的扩大而向右移动。今天的 50-100K 阈值，两年后可能是 500K。

第十部分：给程序员的决策框架

把上面所有内容浓缩成一张可以执行的决策树：

text

你想管理的知识规模有多大？
│
├── < 100 个文档 / < 100K tokens
│   └── → LLM Wiki（零基础设施，直接开始）
│
├── 100-1000 个文档
│   ├── 知识是否有主题聚焦？
│   │   ├── 是 → LLM Wiki + selective loading
│   │   └── 否 → 混合方案（wiki 核心 + RAG 溢出）
│   │
│   └── 是否需要多用户并发？
│       ├── 是 → RAG（需要访问控制）
│       └── 否 → LLM Wiki 仍然可行
│
└── > 1000 个文档 / 企业级
    └── → RAG（LLM Wiki 在这个规模会崩溃）

再加一个维度——你的查询类型：

text

你主要在问什么类型的问题？
│
├── 事实查询（这个函数是什么意思？这个 API 怎么调用？）
│   └── → RAG（单轮检索，速度优先）
│
├── 决策查询（我们当时为什么选这个方案？有没有矛盾？）
│   └── → LLM Wiki（需要预编译的关系理解）
│
├── 分析查询（这两个文档的结论一致吗？）
│   └── → LLM Wiki（跨文档关系已在 ingest 时建立）
│
└── 发现查询（我不知道该问什么，但想了解这个领域的全貌）
    └── → LLM Wiki（Graph View + wiki 结构提供全局视图）

一张贴在桌上的总结卡

text

=== RAG vs LLM Wiki 速查 ===
【选 RAG，当你需要】
→ 企业级（>1000 文档）
→ 多用户访问 + 权限控制
→ 高频更新的动态数据
→ 跨领域广度检索
→ 知识库超过 100K tokens
【选 LLM Wiki，当你需要】
→ 个人 / 小团队（<100-200 文档）
→ 主题聚焦的深度知识
→ 跨文档的关系理解和矛盾检测
→ 知识随时间自动演化（复利）
→ 零基础设施，完全本地
【两者的本质差异】
→ RAG：查询时推理（每次从零）
→ LLM Wiki：编译时推理（一次，之后复用）
【边界】
→ < 50K tokens：LLM Wiki 明显胜出
→ 50K-100K：两者都可，看场景
→ > 100K：需要 RAG 或混合
【不要混淆的事】
→ 两者解决不同规模的问题
→ LLM Wiki 不是"简单版 RAG"
→ RAG 不是"强大版 LLM Wiki"
→ 它们是在不同假设下设计的不同架构

写在最后

2024 年，RAG 是所有问题的答案。每个 AI 教程都从 RAG 开始，每个 AI 创业公司都有 RAG pipeline。

2026 年，我们有了更清晰的视角："标准 RAG"方式——切块文档，embed 它们，检索 top-5，希望结果是好的——现在是遗留技术。

但取代它的不是一个更好的 RAG，而是一个不同的问题框架。

对于企业，GraphRAG 和混合架构在成熟。对于个人，LLM Wiki 模式在 Karpathy 的背书下，正在被重新发现。

两者都不是终点。它们只是在不同的约束下，对"如何让 AI 真正理解你的知识"这个问题，给出了不同的当前最优解。

程序员思维的力量，是不被工具绑架。

你不是在选一个工具。你是在选一个推理发生在哪里的架构决策。

选对了，知识会生长。选错了，你只是有了一个更贵的搜索引擎。

—— 一只阿木木在 AI 时代，每个普通人都该拥有一个自动生长的知识系统。