RAG 之后：LLM Wiki 正在成为个人知识库的新范式

本文为中文整理与评述，基于 Jahangir 发布在 Stackademic 的文章 RAG Is Dead. LLM Wiki — Andrej Karpathy’s Idea — Is What Comes Next。本文保留原文的主要信息框架，并结合中文读者的个人知识管理与本地 AI 使用场景做了重新组织。

过去两年，RAG 几乎成了“让大模型读文档”的默认答案：把文档切块，放进向量数据库，用户提问时再检索相关片段，让模型基于片段回答。这个模式解决了很多即时问答问题，但也暴露出一个越来越明显的短板：它擅长回答当下的问题，却不擅长沉淀长期知识。

Andrej Karpathy 提出的 LLM Wiki 思路，正是对这个短板的一种回应。它不是让 AI 每次都从检索开始、回答结束，而是让 AI 阅读资料后主动维护一个由 Markdown 页面组成的知识库。每个页面对应一个概念、人物、项目或主题，页面之间用类似维基的链接相互连接。随着资料不断增加，知识库会被持续更新，而不是一次次把上下文丢进聊天窗口再忘掉。

这背后的变化很重要：AI 不只是“回答问题的接口”，而开始变成“帮你整理理解的知识维护者”。对于研究、写作、产品调研、代码学习和长期项目管理，这可能比单次问答更接近真实工作流。

为什么传统 RAG 不够用

传统 RAG 的核心流程是：用户提出问题，系统从文档库里检索相关片段，模型读取片段并生成答案。它的优势是简单、可扩展、适合客服、内部知识库问答和文档搜索。但它也有几个天然限制。

第一，RAG 不会自动整理知识结构。它能告诉你“某个问题的答案”，但不会主动把你的资料组织成主题、概念和关系。第二，RAG 的结果往往是一次性的。你今天问到的好答案，如果没有手动记录，明天仍然要重新检索和生成。第三，RAG 对跨文档、跨时间的理解并不自然。它可以拼接片段，却不一定知道这些片段之间的长期关系。

LLM Wiki 的目标不是替代所有 RAG，而是把“问答”推进到“知识沉淀”：文档被读过之后，不只是生成一个回答，而是变成可以浏览、可以链接、可以修订的知识页面。

LLM Wiki 到底是什么

LLM Wiki 可以理解为一个由大模型维护的个人或团队维基。你把 PDF、网页、笔记、会议记录、聊天记录、代码文档等资料交给它，它会抽取主题、拆分概念、生成 Markdown 页面，并在页面之间建立链接。后续资料进来时，它不是重新写一份孤立报告，而是更新已有页面、补充引用、修正关系。

这就像从“问图书管理员一个问题”变成“让图书管理员帮你重新整理整个图书馆”。前者解决一次查询，后者让你的知识库本身越来越好。

一句话理解：RAG 是“提问时临时找资料”；LLM Wiki 是“读完资料后持续建设知识库”。

四个值得关注的实现

原文梳理了当前几个比较有代表性的开源实现。它们都围绕 LLM Wiki，但切入点完全不同：有的是桌面应用，有的是 agent 插件，有的是聊天记录挖掘工具，有的是 MCP 驱动的文件夹维基。

1. nashsu/llm_wiki：桌面应用路线

nashsu/llm_wiki 是最像“产品”的实现。它基于 Tauri 和 React，提供跨平台桌面应用，界面通常包括知识树、聊天区和实时预览，还能用知识图谱展示概念之间的关系。

它适合希望有图形界面、支持多种文档类型、并且想直接浏览知识图谱的用户。资料来源可以包括 PDF、DOCX、PPTX、图片、视频和网页。它还支持 OpenAI、Anthropic、Google、Ollama，以及自定义 OpenAI-compatible endpoint。对于不想在命令行里折腾太久的人，这是最容易理解的一类入口。

2. nvk/llm-wiki：Agent 插件路线

nvk/llm-wiki 不是一个单独应用，而是更像给 Claude Code、OpenAI Codex 或其他 LLM agent 使用的一套工作方式。它的特点是可以并行启动多个 agent 从不同角度研究一个主题，然后把结果整理成互相引用的 wiki 页面、报告、幻灯片或学习材料。

这种路线很适合已经在 Claude Code、Codex 或本地 agent runner 里工作的人。它的关键价值不是“漂亮 UI”，而是把研究过程变成可复用的知识生产流程：每次研究都不只是一个答案，而是可以继续积累的页面。

3. Pratiyush/llm-wiki：从聊天记录里挖知识

Pratiyush/llm-wiki 解决的是另一个很真实的问题：很多人已经和 Claude Code、Cursor、Gemini CLI、Codex、Copilot 聊了几个月，里面有大量决策、调试过程和项目知识，但它们分散在本地日志和 JSONL 文件里，基本没有被组织起来。

这个工具会读取这些聊天记录，生成一个可以离线浏览的静态 HTML 知识库。它强调页面生命周期管理、敏感信息清理、MCP 接入，以及面向 AI 消费的导出格式。对于经常通过 AI 做开发、研究和调试的人，这类工具的价值很直接：把“被遗忘的对话历史”变成可检索、可维护的项目知识。

4. lucasastorian/llmwiki：MCP 驱动的文件夹维基

lucasastorian/llmwiki 更关注“文件夹里的资料怎么长期维护”。它让 Claude 通过 MCP 访问一个目录，对文件进行索引、生成 wiki 页面，并在文件变化后更新摘要、链接和引用。底层仍然保留你的文件系统作为事实来源，wiki 则是生成出来的组织层。

这对研究人员、写作者和长期资料收集者很有吸引力。很多人不是没有资料，而是资料太多、太散、太难维护。MCP 加上本地索引，可以让 AI 更像一个持续整理资料库的助手。

快速对照

本地运行：Ollama 还是 vLLM

LLM Wiki 很适合本地运行，因为它经常会读取个人文档、研究资料、会议记录和代码上下文。把这些资料全部发给云端模型并不总是理想选择。原文把本地运行分成两个层级：Ollama 和 vLLM。

Ollama 的优势是简单。拉取模型、启动服务、接入应用，流程都很直接，适合个人实验和小规模使用。如果你只是想先体验 LLM Wiki，Ollama 是最稳妥的起点。

vLLM 的优势是吞吐和并发。它更适合长上下文、多文档并行处理、多个 agent 同时工作这类场景。如果你要批量整理资料、持续吸收大量文档，或者让多个研究任务并行跑，vLLM 会更接近生产级选择。

模型怎么选

LLM Wiki 对模型的要求和普通聊天不完全一样。它需要长上下文、结构化写作能力、稳定的指令遵循，以及跨页面保持一致的能力。原文推荐 Qwen2.5-14B-Instruct 作为多数人的起点，因为它有较长上下文、结构化输出能力好，并且能在消费级硬件上运行。

如果你有更强硬件并追求推理质量，可以考虑 Llama-3.1-70B-Instruct。若处理超长资料，例如整本书、大型研究档案或长时间会议记录，Qwen2.5-1M 这类长上下文模型会更合适，但通常需要 vLLM 和更认真配置。

为什么这件事值得关注

LLM Wiki 的核心意义，不是又多了一个知识库工具，而是改变了我们使用 AI 的默认姿势。聊天窗口把每次交互都当成一次性事件；LLM Wiki 则把每次交互当成知识库的一次增量更新。

这更接近真实研究团队的工作方式。一个团队不会每天从零开始问同样的问题，而是会维护文档、记录假设、更新结论、保留反证、建立索引。AI 如果要真正进入长期工作流，也需要从“回答问题”转向“维护理解”。

当然，这些工具还处在早期阶段。链接质量、引用准确性、页面去重、版本管理、敏感信息处理，都还有大量工程细节要打磨。但方向很清楚：未来的个人 AI 助手，不应该只记住聊天历史，而应该能把你的资料变成一个持续生长的知识系统。

一个简单开始方式

第一步：选一个实现。如果想快速上手，先看 nashsu/llm_wiki；如果已经在 Codex 或 Claude Code 里工作，可以看 nvk/llm-wiki。

第二步：先用 5 到 10 份聚焦文档测试，不要一开始就把所有资料丢进去。

第三步：用 Qwen2.5-14B-Instruct 或你手头稳定的长上下文模型跑第一版。

第四步：检查生成页面之间的链接关系，看看它是否真的帮你发现了新的连接。

如果说 RAG 是让 AI 帮你“在资料里找答案”，那么 LLM Wiki 更像是让 AI 帮你“把资料整理成可以不断复利的知识库”。对个人研究者、开发者和内容创作者来说，这个方向非常值得提前实验。

参考链接：Stackademic 原文；原文配套仓库。