9 月 12 日刷 GitHub Trending，看到一个挺扎眼的项目：nashsu/llm_wiki，一个跨平台桌面应用，截至本文写作时 18800 颗星、2100 次 fork、856 次提交。官方一句话介绍是「一个会自己生长的个人知识库」：LLM 读你的文档，搭出一座结构化的 wiki，并且让它保持更新。

让我停下来多看两眼的是它那句口号：替代传统 RAG。

RAG（检索增强生成）这两年几乎成了「给大模型接私有知识」的代名词，突然冒出个项目说要替代它，第一反应容易是又一个蹭概念的开源玩具。但把 README 和它背后的来龙去脉读完，我发现这个项目的价值不在口号里，而在它选的那条路：它的蓝图直接来自 Andrej Karpathy 的一篇 gist，核心思路一句话就能讲完：知识应该被编译一次、持续维护，而不是每次提问都从头检索一遍。

这篇文章基于 llm_wiki 的公开 README（有中英日韩四个语言版本）和 Karpathy 的原始设计文档写成，功能描述和数字都来自项目官方口径，我没法在写作时逐项实测，文末附了全部来源。

「替代 RAG」这个说法，只说对了一半

先回忆一下 RAG 的标准流程。文档被切成小块，逐块算 embedding（向量嵌入）存进向量库；用户提问时，把问题也转成向量，捞回最相似的几块，塞进上下文让模型作答。

这套流程的毛病已经被说烂了：切块把完整的论述切得七零八落；语义检索只能看到「局部相似」，缺全局视野；答案到底来自哪份文档的哪一段，追溯起来经常要靠运气。

llm_wiki 的 README 开头有一句话，我认为是整个项目的题眼：

Knowledge is compiled once and kept current, not re-derived on every query.

知识被编译一次并保持更新，而不是在每次查询时重新推导。

注意它的措辞。它反对的不是「检索」本身，而是「每次都从头检索、现查现答」这个模式。顺着这个措辞往下想，RAG 和 llm_wiki 的关系其实可以借一对编程语言的旧概念来理解：RAG 更像解释执行，每次运行都现场读源码；llm_wiki 更像编译执行，先把知识「编译」成一份带结构、带链接的 wiki 产物，之后查询发生在这份产物上。

所以开头那个口号，只对了一半。它真正做的事，是把智能开销从查询时挪到摄取时，拿前置的成本换查询的质量。这笔账划不划算，后文再算。

蓝图来自 Karpathy 的一篇 gist

llm_wiki 不是拍脑袋的项目。Karpathy（前 Tesla AI 总监、OpenAI 创始成员）发过一篇名为 LLM Wiki pattern 的设计文档，gists 是 GitHub 上分享代码片段和短文档的功能，这篇 gist 本身只有几千字，却给出了一个完整的知识库架构模式。

模式的核心是三层：

• Raw Sources：原始素材层。PDF、笔记、网页剪藏，只进不改，是唯一的事实来源；
• Wiki：AI 维护的知识层。LLM 从素材层提炼生成的 wiki 页面，互相之间用 [[wikilink]]（双链）连接，可以随时重建；
• Schema：结构与约定层。wiki 的组织规则、页面类型、命名约定。

还有一句话被它原样继承了下来：Human curates, LLM maintains。人负责策展，决定什么值得进库、什么判断需要复核；LLM 负责维护，让这座知识库保持新鲜、保持连通。

llm_wiki 是这个模式的完整桌面级实现。技术栈是 Tauri（跨平台桌面框架）加 Rust 后端、React 前端，GPL v3 协议，在 Karpathy 原始设计的基础上扩了不少东西：多模态摄取、知识图谱、本地 API，甚至内置了 MCP 服务器。

两步摄取：先读懂，再动笔

llm_wiki 往库里加一份文档的过程，README 称为「两步思维链摄取」，分开来看很清楚。

第一步是分析。LLM 通读源文件，产出的不是摘要，而是一份结构化分析：这份材料里有哪些实体和概念，它们和 wiki 里已有的条目是什么关系，有没有互相矛盾的说法。这一步的产出会带源文件溯源，并且做了增量缓存，同一份文档不需要反复分析。

第二步才是生成。基于第一步的分析，LLM 决定是新建页面、更新已有页面，还是只在现有页面上补一条链接。wiki 的索引页、更新日志、概览页同步维护。拿不准的条目不会被直接写进正文，而是进入一个异步 Review 队列，等人来裁决。

这个 Review 机制值得单独说一句。很多「AI 知识库」产品默认 LLM 写的就是对的，用户事后发现错误也很难定位。llm_wiki 把「LLM 标记可疑、人做最终判断」做成了产品里的常态流程，Karpathy 那句「人来策展」落到产品上，就是这个队列。

摄取还覆盖了多模态：PDF 里的图片会被抽出来，交给视觉模型生成事实性描述后一并入 wiki。工程上的细节也做得比较扎实，比如持久化的摄取队列，串行处理、崩溃恢复、失败自动重试三次。

查询的时候，检索管线并没有消失

先把一个误会说清楚：llm_wiki 并没有扔掉检索。它查询时跑的是一条多阶段管线：先词法搜索，然后可选的向量语义搜索，接着做图谱扩展，最后按 token 预算组装上下文。

向量搜索这层是可选的，基于 LanceDB（一个嵌入式向量数据库）。README 给出的官方口径是，加上向量搜索后召回率从 58.2% 提升到 71.4%。这是项目自己的基准数字，我按原样引用，不构成独立验证。

真正有意思的是图谱扩展这一环。llm_wiki 在 wiki 之上维护了一张知识图谱，边不是只有「页面 A 链接到页面 B」一种，而是四种信号加权合成：直接链接（权重 3.0）、源重叠（权重 4.0，两页引用了同一份原始文档）、Adamic-Adar（权重 1.5，一种衡量两个节点共享邻居程度的图算法）、类型亲和（权重 1.0，同类型页面相互加分）。再跑 Louvain（一种图社区检测算法）自动发现知识聚类。

源重叠那一项权重最高，这个设计很诚实：两个页面讲了同一份源文档，它们的相关性比「恰好互相链接」更硬。查询命中某个页面后，沿着图谱把邻居页面也拉进上下文，等于让「结构」参与了召回。这正好呼应了我在标题里的判断：双链不只是给人看的导航，它本身就是给模型的提示词。

wiki 的洞察页还会主动报告两类东西：「意外连接」（图谱发现的两处远距离关联）和「知识缺口」（素材里提了但 wiki 还没建条的空白），都可以一键发起深度研究，走 Tavily、SerpApi 或自建的 SearXNG 去补。

对 Obsidian 用户，它还有层特别的意思

如果你本来就在用 Obsidian，看 llm_wiki 的 wiki 层会觉得眼熟：[[wikilink]] 双链语法、YAML frontmatter、页面互相链接成网，README 明确说 wiki 层与 Obsidian 兼容。

这不是巧合。Karpathy 的模式本来就把「人写双链笔记」的经验抽象成了架构，llm_wiki 换个方向把它自动化：过去你在 Obsidian 里手工做的事，读文档、提炼概念、建条目、连双链、发现「这两篇其实在讲同一件事」，被挪给了 LLM，而且是增量的、带溯源的、拿不准会标记出来的。

手上已经压了几千份文档的人，多半卡在两个选项之间：继续手工维护双链，可大多数库的双链密度其实远低于理想值；或者整个丢给黑盒 RAG，答错了连错在哪都查不出来。llm_wiki 给的是第三条路：结构由 AI 维护，判断由人保留。

工程上它也留了口子：本地 HTTP API 和 MCP 服务器（默认 127.0.0.1:19828，token 保护），意味着你可以把这座 wiki 接进 Claude Code 之类的工作流里当知识源用。另有 Chrome 剪藏扩展，网页一键收进素材层。

什么场景别用它

编译式不是免费的。摄取要花 token 和时间，知识变了要重新编译，wiki 层本身也成了需要管理的资产。要不要上，先问自己三个问题。

**文档规模是第一道门槛。**几百到几万份相对稳定的文档（书籍、论文、课程、项目文档），编译一次的收益能把成本摊薄；要是每天涌入上千份快消型文档，wiki 层的维护速度根本追不上摄入速度。

**更新频率是第二道。**知识一旦「编译」，变更就意味着再编译，行情、新闻流、监控数据这类高频信息源天生属于检索式，硬塞进这套范式只会互相折磨。

**最后是你平时问什么。**问「A 和 C 之间有什么关系」「这个领域有哪些主题簇」，图谱和双链的价值最大；问「某个配置项的确切值是多少」，全文检索甚至 grep 往往更快更准。llm_wiki 自己也留着向量搜索的选项，说明作者清楚纯图谱召回有盲区。

一句话版本：问答越依赖「关系」，编译式越划算；问答越依赖「单点事实」，检索式越划算。

写在最后

回到标题里那两个概念。RAG 和「编译式知识库」并不是替代关系，而是同一光谱的两端，llm_wiki 自己都把向量搜索装回了查询管线，真正的分歧在于：智能开销花在查询时，还是花在摄取时。

前者的成本跟着查询次数走，每问一次都要付一次检索和推理的钱，换来的是知识永远是「现拉的」，不存在过期。后者把成本前置到摄取时，查询变轻变快、答案有结构可溯，但你要接受一座需要持续投入维护的 wiki 层，接受「知识编译产物」和「源文档」之间永远存在滞后。哪个划算，取决于你的文档规模、更新频率和问题类型，没有普适答案。

而 Karpathy 那个模式里，我认为最值得抄的其实不是三层架构，是那句话的语序：Human curates, LLM maintains。LLM 负责让知识库保持新鲜、保持连通，把文档变成条目、把条目连成网、把可疑的标记出来；人负责那些机器不该替你做的事，决定什么值得进库、争议说法信哪边、Review 队列里的存疑条目怎么裁。

18800 颗星，与其说是投给一个桌面应用的，不如说是投给这个分工的。工具会换代，这个语序大概率会留下来。

参考来源

• nashsu/llm_wiki：GitHub 仓库与 README
• Andrej Karpathy：LLM Wiki pattern（原始设计文档 gist）
• GitHub Trending（2026-09-12 当日榜单）
• 文中界面截图均取自 llm_wiki 项目 README 公开资料，版权归项目作者所有，仅作介绍评论用途

以上来源用于确认功能描述与项目口径，本文未对 llm_wiki 做独立安装实测；星标数、召回率提升等数字均为抓取时点或项目官方口径，不构成独立基准测试结论。