每个用过RAG的人都经历过同一种挫败感：明明文档里有答案，检索出来的却是无关的片段。你调了chunk size、换了embedding模型、加了rerank，结果好了一点，但本质问题没变——每次提问，系统都在从零开始拼凑答案，永远不会"学到"什么。
Andrej Karpathy最近发布了一个Gist，提出了一个优雅到令人拍案的替代方案：别让LLM每次都去检索原始文档，让它维护一个Wiki。
133★
LLMWiki开源项目GitHub Stars
10-15页
单次Ingest平均触达Wiki页面数
0%
知识维护的人工成本占比
RAG的根本问题：知识不会累积
传统RAG的工作流程是：用户提问 → 向量检索相关片段 → 拼接进Prompt → LLM生成回答。这个流程最大的问题不是检索精度——精度可以优化——而是每次查询都是无状态的。
你昨天问了一个关于MCP协议的问题，LLM花了30秒从5份文档中综合出一个精彩的回答。今天你问了一个相关但不同的问题，LLM不会记得昨天的综合结果，它重新检索、重新拼接、重新推理。如果两份文档存在矛盾，它不会记得上次是怎么解决的，甚至可能给出完全相反的答案。
Karpathy的洞察简洁而深刻：Wiki是一个持久的、可累积的知识工件（artifact）。在Wiki中，交叉引用已经建立，知识综合已经完成，矛盾已经被标记——这些工作不需要在每次查询时重新发现。
三层架构：人类策展，LLM维护
Karpathy提出的架构只有三层，每一层的职责边界清晰得像操作系统的分层设计：
| 层 | 内容 | 所有者 | 规则 |
|---|---|---|---|
| 原始素材 | PDF、文章、笔记、数据文件 | 人类 | 不可变，LLM只读不写 |
| Wiki | Markdown页面：摘要、实体、概念、交叉引用 | LLM | LLM全权维护，人类只读 |
| Schema | 配置文档（如CLAUDE.md），定义Wiki结构和规范 | 人类 | 指导LLM如何组织知识 |
这个分层的精妙之处在于所有权的明确划分。人类负责策展——决定什么素材值得进入知识库，以及知识应该如何组织。LLM负责一切维护工作——更新交叉引用、标注矛盾、保持一致性、在几十个页面之间同步变更。
为什么人类维护的个人Wiki总是半途而废？因为维护负担的增长速度远超价值的增长速度。当你有50篇笔记时，每加一篇新笔记就需要检查十几处交叉引用是否需要更新。LLM不会厌倦，不会忘记更新某个交叉引用，一次操作可以同时触达10-15个文件。
三种核心操作
LLM Wiki的日常使用围绕三种操作展开，每一种都体现了"人类策展+LLM维护"的分工：
1. Ingest（摄入）
当你添加一份新文档时，LLM不是简单地把它切成chunks塞进向量库。它会：
- 通读全文，理解核心论点
- 为文档创建摘要页
- 更新所有相关的实体页和概念页（一次可能触达10-15个Wiki页面）
- 检查新内容是否与现有知识矛盾，如果矛盾则标注
- 在追加式日志（append-only log）中记录变更
这意味着每一份新素材都会编织进现有的知识网络，而不是孤立地存在于某个向量空间中。
2. Query（查询）
用户提问时，LLM搜索的是已经综合好的Wiki，而不是零散的原始文档。知识已经是结构化的、去矛盾的、有交叉引用的。回答的质量天然更高，因为综合工作在Ingest阶段就完成了。
更妙的是：有价值的查询结果可以被反馈回Wiki，成为新的Wiki页面。这意味着你的每次探索都在让知识库变得更丰富——这是RAG永远做不到的。
3. Lint（审查）
定期运行健康检查，让LLM识别：
- 数据不一致和矛盾
- 过时的声明
- 孤立页面（没有交叉引用指向的页面）
- 缺失的交叉引用
- 建议调查的新问题和应该寻找的新素材
这就像代码库的lint工具——自动发现知识库的"技术债务"。
LLMWiki：从理论到产品
Lucas Astorian将Karpathy的理论变成了一个完整的开源产品——LLMWiki（llmwiki.app）。架构设计展现了现代AI应用的典型模式：
auto_awesomeLLMWiki技术架构
前端：Next.js 16 + React 19 + Tailwind + Radix UI 后端：FastAPI + asyncpg + aioboto3 数据库：Supabase（Postgres + RLS + PGroonga全文检索） 存储：S3兼容对象存储 AI接入：通过MCP Server连接Claude 文档处理：Mistral OCR + LibreOffice转换
LLMWiki最关键的设计决策是使用**MCP（Model Context Protocol）**作为Claude与知识库之间的桥梁。这意味着Claude不是通过API被调用来处理文档——而是Claude主动通过MCP工具来读取、搜索、写入和管理Wiki。
MCP Server提供了5个工具：
| 工具 | 功能 | 典型操作 |
|---|---|---|
| guide | 解释Wiki工作方式，列出可用知识库 | 首次连接时自动调用 |
| search | 浏览文件列表或通过PGroonga关键词搜索 | Ingest和Query时检索相关页面 |
| read | 读取文档——PDF支持分页，支持glob批量读取 | 理解原始素材内容 |
| write | 创建Wiki页面、编辑（str_replace）、追加 | 维护Wiki的核心操作 |
| delete | 按路径或glob模式归档文档 | 清理过时内容 |
这种设计的优势在于：知识库的使用体验就是和Claude对话。你不需要学习任何新的界面或API——告诉Claude读取你的素材、编译Wiki、回答问题，它通过MCP工具自主完成所有操作。
与传统RAG的本质区别
很多人会问：这不就是一个复杂版的RAG吗？不是。区别是本质性的：
| 维度 | 传统RAG | LLM Wiki |
|---|---|---|
| 知识状态 | 无状态，每次重新检索 | 有状态，知识持续累积 |
| 综合时机 | 查询时实时综合 | 摄入时预综合 |
| 矛盾处理 | 每次可能给出不同答案 | 摄入时标注，一次解决 |
| 交叉引用 | 不存在 | 自动维护 |
| 知识质量 | 随文档增多可能下降 | 随文档增多持续提升 |
| 探索价值 | 查询结果即用即弃 | 有价值的探索回馈Wiki |
最后一点尤其重要。在RAG系统中，你花30分钟和LLM探讨一个复杂问题，得到了深刻的洞察——然后关闭对话，一切消失。在LLM Wiki中，这些洞察成为新的Wiki页面，永久地丰富了知识库。你的思考在累积，而不是在蒸发。
对企业知识管理的启示
Karpathy在Gist中写道，LLM Wiki的社区反响超出预期。大量开发者开始构建自己的实现——SwarmVault（代码分析）、RTFM（FTS5+语义搜索）、AI-Context-OS（分层记忆+治理）。这说明这个模式击中了一个真实的痛点：我们已经有了足够强大的AI，但我们管理知识的方式还停留在搜索引擎时代。
LLM Wiki不是一个产品，而是一个范式转换。它说的是：别把LLM当搜索引擎用。让它当图书管理员——一个永远不下班、永远不忘记更新卡片目录的图书管理员。当你改变了这个定位，知识管理的整个游戏规则都会改变。
