LLM Wiki 和 RAG 最大的区别是什么？

RAG 在每次查询时临时检索原始文档片段，再拼出答案，是无状态的。LLM Wiki 在写入新知识时就把内容编译成结构化的 markdown 页面，查询时直接读成品。一个是每次现做，一个是提前做好。

LLM Wiki 会取代 RAG 吗？

不会完全取代。要搜几十万张工单、文档每天都在变的场景，RAG 还是唯一现实的选择。LLM Wiki 适合的是需要深度理解、知识相对稳定、规模在几百页以内的场景，比如业务规则、领域知识、Agent 的长期记忆。

LLM Wiki 比 Ontology 好在哪里？

结构更简单：就是 markdown 文件加链接，不用先设计 schema。人看得懂：业务方可以直接审阅和改。好维护：改知识就是改文件，有 git diff，不用维护图数据库和本体工程师团队。

LLM Wiki 有什么明显的缺点？

规模天花板低，经验值是超过 150-200 页后 Agent 看不全整个 wiki，需要靠索引文件续命。另外它不是零维护，每几周要花一点时间做矛盾检查和术语统一。

调研了一圈 LLM Wiki，我觉得它比 RAG 和 Ontology 更适合复杂业务 Agent

TLDR： LLM Wiki 是让 AI 把知识提前"编译"成一堆互相链接的 markdown 文件，查询时直接读，而不是像 RAG 那样每次现搜现拼。Karpathy 今年 4 月提出这个模式后，gist 拿了 5000+ star，社区已经有不少实现。对比下来：它比 RAG 更稳（不用赌检索质量），比 Ontology 更简单（人看得懂、改得动）。我的观点是：对于业务非常复杂的 Agent，LLM Wiki > Ontology 和 RAG。缺点是规模上不去，几百页就是天花板。

先说说 LLM Wiki 是什么

一句话：RAG 是搜索引擎，LLM Wiki 是编译器。

今年 4 月，Karpathy 在一个 GitHub gist 里描述了这个模式。不是什么框架，就是一段提示词，大意是：别每次提问都去原始文档里检索了，让 Agent 把资料读一遍，写成一堆互相链接的 markdown 页面，以后查询就是读这些页面。

他的原话我印象很深："知识只编译一次，然后保持更新，而不是每次查询都重新推导。" 还有个比喻："Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。"

这个 gist 现在 5000+ star、5000+ fork。一个纯文本提示词能到这个热度，说明确实戳中了什么。

大家都是怎么实现的

我翻了一圈，目前大概有这么几类玩法：

直接用 gist + 编码 Agent。 最原始的方式：Obsidian 建个库，把 gist 贴进 Claude Code 或 Codex 的系统提示词，往 sources/ 里丢文档，Agent 自己往 wiki/ 里写页面。有人这么跑了三个月，wiki 自己长到了 147 页，他一行没手写（来源）。
打包成插件/Skill。 比如 llm-wiki.net 做的 LLM Wiki Kit，给 Claude Code、Codex、OpenCode 用，支持导出"知识检查点"。也有做成 coding agent skill 的，比如 llm-wiki-agent。
桌面应用。 比如 nashsu/llm_wiki，把文档自动变成组织好的知识库。
Git 驱动的团队 wiki。 有团队让 Agent 维护 markdown + git 的知识库，每次更新都有 diff 可审（案例）。

共同点是：都没有向量数据库，没有 embedding，没有检索管线。就是文件夹 + markdown + 一个会读写的 Agent。这个朴素程度，一开始我是怀疑的，看完数据之后不怀疑了。

和 RAG 比：赢在"稳"

RAG 的问题不是它不好，是它每次查询都要赌一把。赌 chunk 切得对不对、embedding 排得准不准、塞进去的片段模型看不看得见。这个赌注经常输：

Gartner 预测到 2025 年底，至少 30% 的 GenAI 项目在 PoC 之后被放弃，主要原因就是数据质量和风险控制；到 2026 年，60% 缺乏 AI-ready 数据的 AI 项目会被放弃（Gartner 新闻稿）。
"Lost in the Middle"那篇论文（Liu et al., TACL 2024）证明了模型对塞在中间位置的信息就是会漏看，准确率呈 U 型曲线。RAG 检索回来的片段放哪儿，直接影响答案对不对。
Chroma 今年的 Context Rot 研究测了 18 个前沿模型，输入越长，所有模型表现都下降，没有一个例外（报告）。
arXiv 上有篇论文专门总结了 RAG 系统的七个典型失败点，从缺内容到切错块到拼错答案，每个环节都能翻车。

LLM Wiki 绕开了这一整条失败链，因为它把"理解"这件事从查询时挪到了写入时：

	RAG	LLM Wiki
理解发生在	每次查询，临时拼	写入时，一次编译好
状态	无状态，每次从头来	持久积累，越用越厚
知识点之间的关系	靠 embedding 猜相似度	靠 markdown 链接写明
矛盾处理	没有，冲突随机冒头	写入时主动标记矛盾
基础设施	向量库 + embedding + 检索管线	一个文件夹
适合规模	百万级文档	几百页

对 Agent 来说，具体好在哪

我做了点复杂业务 Agent 的开发，感受最深的两点：

第一，更好懂。 Agent 读 wiki 就是读文件，拿到的是一整页讲清楚一个概念的文字，带前因后果和交叉链接。RAG 给它的是 5 段不知道从哪切下来的碎片，它得自己猜这些碎片什么关系。业务逻辑复杂的时候，碎片的拼接错误就是幻觉的温床。链接是显式的，相似度是猜的——这个差别在调试的时候特别明显：wiki 里 Agent 为什么知道一件事，你顺着链接就能查到；RAG 里你只能去翻 embedding 的 top-k 列表。

第二，更稳。 同一个问题问两遍，wiki 给出一样的答案，因为读的是同一个文件。RAG 可能因为检索排序抖一下，答案就变。而且 wiki 可以进 git——知识变了有 diff，错了能回滚，上线前能 review。做业务 Agent 的都知道，"知识变更可追溯"这一条，在合规和甩锅两个场景下都救命。

和 Ontology 比：赢在"简单"和"人看得懂"

复杂业务的知识管理，还有一条老路：建本体（Ontology）/ 知识图谱。这条路的问题不是理论不行，是太贵、太慢、太硬：

企业级知识图谱从启动到上线，典型周期是 6-12 个月（Rebase 的数据）；单个域的图谱构建也要 6-12 周（Atlan）。
Cutter Consortium 估算企业知识图谱的长期总成本在 1000-2000 万美元（转引自这篇分析，数字仅供参考，但量级应该没离谱）。
而且建本体是 schema-first：得先有专家把"业务里有哪些概念、概念之间什么关系"定义清楚，才能往里填数据。业务一变，schema 就得跟着动。

LLM Wiki 在这三点上正好是反的：

结构更简单。 不用先设计 schema。页面和链接就是全部结构，Agent 写入时自己归纳，归纳错了改文件就行。
人看得懂。 业务方打开 markdown 就能审，不用学 Sparql，不用看图数据库。知识库第一次变成了业务和技术能一起读的东西。
更好维护。 改知识 = 改文件 + git diff。不需要本体工程师，不需要图谱迁移脚本。维护的负担从"养一个团队"降到"每几周花半小时让 Agent 跑一遍矛盾检查"。

说句公道话：Ontology 在需要严格推理、保证一致性的场景（比如医疗术语、监管合规）还是不可替代的。但大部分业务 Agent 要的不是逻辑完备性，是"别答错、错了能查、查了能改"。

我的观点：复杂业务 Agent，LLM Wiki > Ontology 和 RAG

理由收敛成一条：业务越复杂，知识的价值越在"关系"和"判断"里，而不在"事实"里。

RAG 擅长取事实，但关系和判断藏在文档的字里行间，切块检索天然会丢掉它们。
Ontology 能表达关系，但表达不了判断（"这种情况一般这么处理，除非……"），而且维护成本随复杂度爆炸。
LLM Wiki 的页面里，事实、关系、判断可以写在同一段话里，人和 Agent 都能读，编译一次就一直可用。

一个有点反直觉的推论：上下文窗口越大，这个模式越强。现在 150-200 页的天花板是窗口限制出来的，等 10M token 窗口普及（很多人觉得 2027 年前后），这个天花板基本就没了。而 RAG 的检索抖动和 Ontology 的维护成本，不会因为模型变强而消失。

什么时候别用它

诚实一点，三种情况别选 LLM Wiki：

文档几十万上百万、每天更新——RAG 仍然是唯一现实解。
需要严格的形式化推理和一致性保证——那是 Ontology 的地盘。
你就偶尔查个东西——直接 ChatGPT 传文件就行，别折腾。

以及它不是零维护。经验值是每 2-3 周要花 30-45 分钟做矛盾检查和术语统一。比手动维护知识库轻松得多，但"扔那就不管"会烂掉。

未来大概率是混合架构：RAG 管广度和时效，Wiki 管深度和关系。但如果只能选一个给复杂业务 Agent 打底，我现在会选 Wiki。