LLM Wiki 不是 RAG：知识系统的范式转换

公众号名称：极客BIM设计工坊

作者名称：朗朗晴空

发布时间：2026-05-16 09:24

#LLMWiki #RAG #知识管理 #Karpathy

长话短说

RAG 有一个没人讨论的致命缺陷：它永远不会真正学习。每次查询都是一次从零开始的临时推理，知识不会积累、不会演化、不会沉淀。Karpathy 提出的 LLM Wiki 模式改写了这个架构——把知识从「每次临时检索」变成「持续构建并积累理解」。这不是改进，是范式转换。

75+

GitHub Stars

0→1

学习成本

90%

维护成本降低

RAG 的致命缺陷：它从不学习

如果你用过「和 PDF 对话」「AI 知识库」这类产品，你可能已经习惯了这样的体验：上传文档，提问题，得到回答。这看起来像 AI 在「理解」你的资料，但背后的真相非常不同。

每次你提问，系统都会重复同样的循环：把文档切成片段、向量检索最相关的几块、塞给大模型生成答案、然后丢掉这次合成的结果。下一次提问，一切重新来过。

模型听起来很智能，但底层是在每一次查询上重建理解。没有持久化的合成、没有演化的结构、没有知识的复利。只有原始上下文窗口上的临时推理。

这不是某个产品的缺陷。NotebookLM、PDF 聊天应用、企业 AI Copilot、甚至 ChatGPT 的上传功能——它们都是这个模式。有用吗？当然有用。但本质上都是无状态的。

核心问题　传统 RAG 有数据的记忆，但没有理解的记忆。它记住了文件在哪里，但从未「理解」过文件在说什么。

Karpathy 的回答：让知识自己长出来

Andrej Karpathy 提出的 LLM Wiki 模式，引入了一个非常不同的思路：如果模型不是临时检索，而是持续持有并进化知识呢？

区别听起来很小，但架构完全不同了。系统不再把文档当作需要反复扫描的对象，而是构建一个持久的 Wiki 层——介于用户和原始材料之间。

这个层不是嵌入索引，而是演化的知识基质。结构化的 Markdown 页面、互相链接的概念、实体图谱、摘要、对比、矛盾点、待解决问题、长期合成——这些都是 Wiki 的一部分。最重要的是，系统会持续更新这个层。

当你添加一篇新论文或一段文字时，模型不是简单地「存储」它。它会整合进来，可能同时发生这些事情：修正已有摘要中与新信息矛盾的部分、修改相关实体页面的描述、建立全新的概念关联、浮出隐藏的矛盾点、加强或弱化已有的结论。知识库本身在复利增长。

传统 RAG

每查询重建知识

片段级检索

无状态推理

知识不累积

维护成本高

LLM Wiki

持续构建理解

概念级合成

持久化认知

知识复利增长

维护趋近于零

这里最关键的部分是：知识系统的瓶颈从来不是智能，而是维护。人类创建的知识系统注定会衰退——链接断掉、笔记碎片化、矛盾堆积、分类体系漂移、上下文丢失。最终系统维护的成本超过了重建的成本。大语言模型第一次改变了这个等式：它们让持续的组织化维护几乎免费。

RAG 检索上下文，LLM Wiki 积累知识。这两件事不是同一种能力。

小白先看懂：它到底是什么

**给谁用的。**写笔记和整理知识的任何人——研究人员、工程师、学生、产品经理、创业者。不需要会编程也能理解理念，但动手搭建需要一些终端基础。

**解决什么核心问题。**你读过的资料不会自己消化。传统 RAG 每次帮你临时翻书，LLM Wiki 帮你建一个会自我更新的第二大脑——今天读的笔记会自动修正昨天建立的认知。

**典型场景。**梳理某篇论文的全部相关研究、追踪某个技术领域的演进脉络、积累团队的项目文档和经验教训、个人长期的读书笔记和思考系列。

**不适合谁。**只需要临时查一下文档的人（RAG 更快更直接）；不想维护知识库、只想提问的人；习惯单篇阅读、不需要跨文档关联的人。

适合

研究者 · 工程师 · 知识工作者 · 长期学习者

不适合

临时查询者 · 零维护意愿者 · 单篇阅读者

动手搭建你的第一个 LLM Wiki

下面是最简单的方式——用 ekadetov 实现的 llm-wiki（Claude Code 插件版）来体验完整流程。它把 Karpathy 的模式落地成了一个可操作的 CLI 工具。

▸　零数据库 — 所有知识存成纯 Markdown 文件，可以在 Obsidian 中直接浏览和编辑

▸　三层架构 — raw（原始来源不可变）→ 实体/概念/对比页（知识持久化）→ SCHEMA（页面规范）

▸　自动关联 — 新资料被消化后，自动修正已有页面、建立新链接、标出矛盾点

▸　健康检查 — 内置 lint 机制：找孤立页面、断链、过期内容、矛盾页面

第一步，把插件安装到 Claude Code 环境中：

git clone https://github.com/ekadetov/llm-wiki claude plugin install /path/to/llm-wiki

第二步，开始使用——初始化 Wiki 结构，然后投喂文档：

/wiki-init # 创建目录结构 /wiki-ingest # 投喂一篇网页文章 /wiki-ingest # 投喂本地文件 /wiki-query “你的问题” # 查询已合成的知识 /wiki-lint # 检查知识库健康度

当你投入 5-10 篇资料后，知识库开始显现实力——查询结果不再是碎片拼凑，而是已经消化好的连贯理解。同一个概念在不同文章中出现时，系统已经帮你比对过，直接给出综合后的判断。

FIX新手上路注意

别贪多 — 同一域下先投 3-5 篇核心资料，让系统建立基础框架后再扩展

分类要准 — 给每篇资料打上正确的标签，否则后续关联会混乱

定期检查 — 每周跑一次 lint，关注 flagged 的矛盾点和孤立页面

为什么这件事比你想象的更重要

LLM Wiki 的意义不止于一个更好的知识库工具。它重新定义了 AI 在知识管理中的角色。过去我们认为 AI 是「检索工具」——告诉你去哪里找信息。现在它可以成为「认知伙伴」——和你一起构建理解，而不是替你翻书。

这带来几个连锁影响：研究系统可以持续演化而非一次性产出；个人知识库可以随着时间成熟——一年前写下的笔记会被自动修正和补全；团队记忆可以复利增长而不是每季度重置。

当维护成本趋近于零，新的知识架构才开始变得可行。Karpathy 这个想法真正重要的地方，在于它把我们从「按需检索信息」推进到了「持续构建和理解」的阶段。这两件事，不是同一种东西。

cover_image

Original 朗朗晴空极客BIM设计工坊

内容效果不满意？点此反馈