RAG之后，知识库开始自己长大

推荐语

这个开源项目让知识库从静态仓库变成会自我生长的城市，帮你告别重复检索的烦恼。

核心内容：
1. RAG 知识库的局限性：每次查询都需重新检索，无法积累知识
2. LLM Wiki 的创新架构：三层结构实现知识编译与自动维护
3. 个人知识管理的产品化：从理论到桌面应用的实践突破

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

你有没有这种感觉：资料越存越多，脑子反而越来越乱。

网页剪藏、PDF、会议纪要、聊天记录，都躺在文件夹里。真正要用时，还是从搜索开始，从摘要开始，从一堆片段里重新拼答案。

这不是懒。是传统知识库有个老毛病：它只负责存，不负责长大。

LLM Wiki 想改掉这件事。这个 GitHub 项目已经拿到 10897 Stars，它把 Karpathy 提出的 LLM Wiki 思路，做成了一个跨平台桌面应用。

知识库不是仓库，是一座会修路的城市

RAG 每次都在重新打井

过去两年，RAG 是很多 AI 知识库的标准答案。

你把文档丢进去，系统切块、向量化、检索，再让模型生成回答。听起来很先进，但它像一个临时工：每次来上班，都要重新翻箱倒柜。

问一个简单问题还好。问一个需要综合五篇文章、三次会议、两份报告的问题，它就开始吃力。

RAG 的问题不是不会找资料，而是找完以后什么都不留下。

下一次，你又得重新付一遍 token，重新等一遍检索，重新赌一遍模型能不能把关系拼对。

LLM Wiki 先编译，再查询

LLM Wiki 换了个思路。

它不把原始资料当成“每次查询时再翻的仓库”，而是让大模型在资料进入系统时，就把它编译成一套结构化的 Markdown Wiki。

一份新资料进来，模型会读它，提炼它，更新已有页面，建立交叉引用，标记矛盾，把新信息织进旧知识网络里。

这就像从“每次现查地图”，变成“每天有人帮你更新城市路网”。

它真正厉害的地方，是把维护变成默认动作

三层架构很朴素

LLM Wiki 的底层架构并不花哨，甚至有点土。

第一层是 Raw Sources，原始资料不可变。PDF、网页、图片、笔记，都先放这里。

第二层是 Wiki，由 LLM 生成和维护。这里有摘要页、实体页、概念页、索引页、日志页。

第三层是 Schema，告诉模型怎么维护这套知识库。命名规范、链接方式、来源引用、冲突标记，都写在规则里。

越朴素，越容易跑起来。Markdown、Obsidian、Git，这些老工具反而成了新基础设施。

Ingest 不是摘要，是重构

很多工具说“导入文档”，其实只是生成一段摘要。

LLM Wiki 的 Ingest 更像一次小型重构。

它会先做分析：这份资料里有哪些实体、概念、论点，和已有 Wiki 有什么关系，有没有冲突，有没有值得延伸的问题。

再做生成：更新 source 页面，补 concept 页面，改 index，写 log，把需要人判断的地方放进 Review。

项目 README 里把它叫 Two-Step Chain-of-Thought Ingest。说白了，就是先想清楚，再动手改文件。

这对知识库很关键。因为真正值钱的不是“又多了一篇摘要”，而是旧知识因为新资料被重新排列了一次。

个人知识管理，终于有了产品形态

桌面应用降低了门槛

Karpathy 原始想法更像一份“idea file”，适合懂 Agent 的人复制进 Claude Code 或 Codex 里自己搭。

LLM Wiki 往前走了一步：它做成了 Tauri v2 + Rust + React 的跨平台桌面应用，支持 Windows、macOS、Linux。

界面是三栏：左边看知识树和文件树，中间对话，右边预览。

这种设计很重要。因为普通人不是不想要知识复利，而是不想先学一堆命令行。

它不是抛弃 Obsidian，而是给 Obsidian 装发动机

LLM Wiki 的 Wiki 目录本身兼容 Obsidian。

这意味着，你不是被锁进一个新 App。知识还是 Markdown 文件，链接还是 `[[wikilink]]`，可以用 Obsidian 打开，可以用 Git 管理，也可以用脚本处理。

文件优先于应用，这一点很先进。

很多 AI 知识库的问题，是把你的资料和记忆锁在自己的云里。LLM Wiki 的方向相反：应用只是工作台，知识资产仍然属于你。

这件事看似小，其实决定了它能不能长期用。

从文件夹到知识图谱，中间差一个持续维护者

四个信号判断知识关系

当 Wiki 变大，光靠标题和链接就不够了。

LLM Wiki 加了一个 4-Signal Knowledge Graph：直接链接、来源重叠、Adamic-Adar、类型亲和度。

这些词听起来有点技术，但意思不复杂：它不只看两篇文章有没有互相链接，还看它们是不是引用了相同来源，是不是共享邻居，是不是属于同一类知识。

然后，它用 Louvain Community Detection 自动发现知识簇。

人类看见的是一张图。模型看见的是一堆可以继续追问、继续补全、继续研究的关系。

Deep Research 把缺口变成任务

更有意思的是 Graph Insights 和 Deep Research。

系统不仅能告诉你“这些知识有关联”，还会提示“这里可能缺一块”。

比如，一个概念被多处提到，但没有独立页面；两条结论互相矛盾，但缺少新的来源；某个主题有很多事实，却没有综合判断。

这时 Deep Research 可以把缺口变成搜索任务，通过 Tavily、SerpApi 或 SearXNG 找资料，再自动摄入 Wiki。

好的知识库不只是回答问题，还会生成下一个问题。

这类项目真正指向的，是 Agent 的长期记忆

Chatbot 的记忆太薄了

很多产品都在讲“AI 记住你”。

但多数记忆是黑箱。它记了什么，你不知道；它什么时候忘，你也不知道；它把哪两件事混在一起，你更不知道。

LLM Wiki 给了另一种答案：把记忆显性化。

所有知识都落在文件里，有来源，有链接，有更新时间，有冲突标记。模型可以读，人也可以审。

显性记忆比神秘记忆更可靠。

对 Agent 来说尤其如此。一个能长期工作的 Agent，不能只靠聊天历史活着。聊天历史像水，流过去就没了；Wiki 像地基，会一层层往上长。

企业知识库也会被重新定义

这件事如果放进企业里，想象空间很大。

公司每天产生会议纪要、需求文档、客户反馈、代码评审、竞品报告。大多数都进了飞书、Notion、Confluence，然后慢慢过期。

真正的问题不是没有知识库，而是没人维护。

LLM Wiki 这类项目给了一个新分工：人负责输入和判断，AI 负责整理、链接、更新、体检。

知识管理从“写文档”变成“养系统”。这变化不小。

值得警惕的，也正在这里

自动维护不等于自动正确

越是会自己长大的系统，越要小心长歪。

LLM 可能误读资料，可能把弱关联当强关联，也可能把一次综合判断写成确定事实。

所以 LLM Wiki 里的人审机制很重要。它有 Async Review System，会把需要人工判断的内容单独标出来。

这不是多余步骤。恰恰相反，AI 负责勤快，人负责把关，这是知识库长期可信的底线。

适合中小规模，别幻想一口吞掉全公司

LLM Wiki 很适合个人研究、团队小知识库、特定项目资料库。

但如果你想把几百万份企业文档一口气丢进去，它未必是最优解。

它更像“高价值知识的编译器”，不是“大规模文档垃圾场”。

这点要分清。工具不是越大越好，场景对了才有价值。

开源项目信息

关键数据

• 项目：nashsu/llm_wiki
• GitHub：https://github.com/nashsu/llm_wiki
• Stars：10897
• 定位：跨平台桌面版 LLM Wiki / AI 第二大脑
• 技术栈：Tauri v2 + Rust + React
• 核心能力：Ingest、Query、Lint、Knowledge Graph、Deep Research、MCP Server、Agent Skill

一句话总结

LLM Wiki 把知识库从“存资料的柜子”，变成了“会自己整理书架的研究助理”。

如果说 RAG 解决的是“资料在哪里”，LLM Wiki 解决的就是“资料之间到底发生了什么关系”。

这一步，才是 AI 知识库真正开始有复利的地方。