LLM Wiki：超越 RAG 的持久化知识积累范式

为什么写这篇文章

最近读了 Karpathy 发布的一篇关于 LLM Wiki 的 Gist，它对 RAG 的批评不是"检索不够准"，而是"根本模式就有问题"。这个判断是否成立值得深入探讨。

我在过去一年里真正用过 RAG 来管理技术文档，也亲历过它的局限：问一个需要综合多篇论文的问题，答案往往是碎片化的。切换到 LLM Wiki 工作流之后，感受到的差异是实质性的，不只是工具层面的差异。

这篇文章想回答的问题是：LLM Wiki 的核心机制是什么，它真正解决了哪些 RAG 解决不了的问题，以及适用边界在哪里？

RAG 的根本局限：每次都在从零开始

RAG（检索增强生成）的工作方式是：你有一堆文档，问问题时检索相关片段，LLM 基于这些片段生成答案。这个模式有效，但每次都在从零重新发现知识。

用一个具体场景来说明这个问题：

你在研究一个技术领域，已经积累了 50 篇论文和 20 篇博客。现在你想问：

"这个领域目前有哪些矛盾的观点？"
"哪个方案在实践中被验证效果最好？"
"最近三个月的新来源改变了哪些早期结论？"

对于 RAG，每次问这些问题，它都必须重新扫描、重新拼凑。没有任何东西在上次查询后"留下来"。更重要的是，矛盾检测 和 知识演化追踪 这类需要跨文档推理的问题，RAG 的结构天然难以支持。

这个问题在三类场景下尤为严重：

跨文档推理：需要综合多个来源才能得出结论，RAG 的片段检索无法预先建立跨文档关系
知识演化追踪：新旧观点存在矛盾，RAG 不知道哪个更新，索引里新旧并存
长期研究积累：持续添加来源，但每次查询都好像是第一次见到这些材料

Karpathy 对这个问题的诊断更直接：Wiki 系统历来的失败，不是因为没有内容，而是因为维护负担增长速度快于价值。个人 wiki 往往在建立初期充满热情，几个月后因为维护代价太高而废弃。更新交叉引用、标记矛盾、保持摘要最新这些"簿记"工作，没有人愿意长期坚持。

这两个问题的根源是同一个：知识管理需要持续的簿记工作，而人类不擅长这件事。LLM Wiki 的核心洞察是：LLM 恰好最擅长这类机械性、一致性要求高的工作。

LLM Wiki 是什么？

LLM Wiki 不是一个软件，而是一种工作范式。它的核心思路是：

不要在查询时从原始文档检索，而是让 LLM 增量构建并维护一个持久化的 wiki —— 一个结构化、互相链接的 Markdown 文件集合，位于你和原始来源之间。

知识是一次性编译的，然后持续保鲜，而不是每次查询时重新派生。

这个设计的关键洞察是：LLM 接管了所有的簿记工作 —— 更新交叉引用、保持摘要最新、标记矛盾、维护页面间的一致性。Wiki 历来失败的那个根本原因，在 LLM 面前不存在了。

人类的工作只剩下三件事：策划来源、指导分析、提出好问题。

三层架构的设计逻辑

层级	职责	谁操作	关键特点
原始数据层	不可变的真实来源	用户添加，LLM 只读	永久保留，任何时候可重新摄取
持久化知识层	结构化的 wiki 内容	LLM 完全拥有和维护	主要工作区，可随时查阅
行为规范层	告诉 LLM 如何维护 wiki	用户编写一次	Schema 驱动，让 LLM 内化约定

三层分离的意义在于关注点分离：原始来源是事实基础（只读），wiki 是 LLM 的输出工件（读写），schema 是 LLM 的工作约定（配置）。这种分离确保：

原始来源不会被改写。即使 wiki 页面出错，原始来源永远在那里，可以重新摄取
LLM 行为可配置。通过修改 CLAUDE.md，可以调整 wiki 的组织结构、命名约定、摘要风格
知识积累可审计。git 记录每次 ingest、每次 lint 的变更，完整的操作历史

CLAUDE.md 在实践中长什么样？

CLAUDE.md 是 schema 层的核心文件，它定义了 LLM 维护这个 wiki 时必须遵守的约定：

# LLM Wiki 维护规范

## 目录结构约定

- /entities/ 实体页（人物、工具、框架、组织）
- /concepts/ 概念页（技术术语、方法论、设计模式）
- /synthesis/ 综合页（跨领域分析、对比研究、趋势判断）
- /sources/ 来源摘要（每个原始来源一页）
- index.md 全局目录，按类别组织
- log.md 操作日志，仅追加

## 页面格式约定

每个实体页必须包含：

- 一行定义（what it is）
- 关键属性列表
- 与其他实体/概念的关系（wikilinks）
- 来源引用（[[source-name]]）

## 矛盾标记约定

当发现两个来源存在矛盾时，在相关页面添加：

> ⚠️ **矛盾**: [来源 A] 提到 X，但 [来源 B] 提到 Y。待调查。

## Ingest 流程

1. 读取来源，与用户讨论 3-5 个关键收获
2. 创建或更新 /sources/ 下的来源摘要页
3. 更新所有相关实体页和概念页
4. 检查是否有新矛盾需要标记
5. 更新 index.md
6. 追加 log.md 条目（格式：## [日期] ingest | 来源标题）

这个文件只需要写一次，之后 LLM 每次操作 wiki 时都会自动遵守这些约定。这是把维护成本从"每次操作"变成"一次性配置"的关键机制。

三种核心操作的机制细节

Ingest：整合而不是建索引

Ingest 是 LLM Wiki 最核心也最耗时的操作。它的工作量远超 RAG 的"建索引"：

典型 Ingest 流程（以摄取一篇技术论文为例）：

LLM 阅读论文全文
与你讨论 3-5 个关键收获，确认理解是否准确
在 /sources/ 创建来源摘要页（标题、作者、核心主张、方法、局限性、相关引用）
更新相关实体页（论文提到的工具、框架、作者）
更新相关概念页（论文涉及的技术概念、方法论）
检查是否有新来源与现有页面内容产生矛盾，如有则标记
在已有的综合页中补充这篇论文的观点（如果该综合页存在）
更新 index.md，追加 log.md 条目

一篇来源可能同时影响 10-15 个 wiki 页面。这就是"知识积累"的实质：Ingest 一次，整个 wiki 的相关知识同步更新。对比 RAG 的"建索引"操作，RAG 只是把内容分割成片段，填入向量数据库，页面间的关系、矛盾、综合分析一概不做。

当你再次 Query 时，差异就体现出来了：

RAG 的回答：检索到片段 A、B、C，拼凑成答案
LLM Wiki 的回答：读取已综合的概念页 + 综合页，直接给出结构化分析

Query：基于已综合知识的回答

Query 操作的流程是：LLM 搜索相关 wiki 页面（通过 index.md 导航或 qmd 搜索），读取内容，综合答案并附带页面引用。

但更重要的是一个常被忽视的设计：好的答案可以归档回 wiki。

你做的每一次深度 Query，这次分析的过程和结论是有价值的，不应该消失在聊天历史里。把它存为一个新的综合页，下次同类问题就能直接复用这个分析成果。这就是"知识复合增长"的含义：不只是来源积累，探索本身也会积累。

一个综合页的示例：

---
title: RAG vs LLM Wiki 对比分析
date: 2026-04-09
sources:
  - [[karpathy-llm-wiki]]
  - [[langchain-rag-guide]]
  - [[weaviate-rag-benchmark-2025]]
---

## 核心差异

RAG 和 LLM Wiki 解决的根本上是两个不同的问题：

- RAG 解决"如何从大量文档中快速检索相关信息"
- LLM Wiki 解决"如何让知识随时间积累而非每次从零发现"

## 矛盾观点

⚠️ [[weaviate-rag-benchmark-2025]] 声称 RAG 在精确度上优于摘要方法，
但 [[karpathy-llm-wiki]] 认为精确度不是关键指标，知识积累才是。
待调查：两者的评估维度可能不同。

## 综合判断（2026-04-09）

在以下场景 LLM Wiki 有优势...
在以下场景 RAG 更合适...

这种结构化的综合页，包含了来源引用、矛盾标记、时间戳，比任何 RAG 查询结果都更有价值。

Lint：知识库的自愈机制

Lint 是最容易被忽视但对长期质量最关键的操作。建议每周或每次积累到足够新来源后执行一次。

一次完整的 Lint 会检查：

## Lint 检查项

### 矛盾检查

- 扫描所有带 ⚠️ 标记的页面
- 查找可能产生矛盾但尚未标记的新旧内容
- 询问用户是否有新来源可以澄清

### 陈旧内容检查

- 查找时间戳超过 6 个月的声明
- 对比最新摄取内容，标记可能已过时的信息

### 孤立页面检查

- 找出没有被任何其他页面链接的页面
- 建议添加到相关页面的引用中

### 遗漏概念检查

- 找出在多个来源中被提及但没有独立页面的概念
- 列出建议新建的页面

### 缺失链接检查

- 找出提到实体 X 但未使用 wikilink [[X]] 的位置

一个 Lint 发现矛盾的真实场景：

你的 wiki 里有一个关于"Transformer 注意力机制计算复杂度"的概念页。早期摄取的 2022 年论文说它是 O(n²)，近期摄取的 2025 年论文介绍了一种新的线性注意力变体，复杂度降到了 O(n)。Lint 发现这个矛盾，在概念页添加警告，附上两篇来源的引用，并在建议区指出可能需要创建"线性注意力"的子概念页。

Lint 的本质是让知识库具备自愈能力：矛盾不会悄悄积累，陈旧声明不会长期保留，知识库质量随时间提高而非降低。

index.md 与 log.md：两种维度的导航

这两个文件是 LLM Wiki 基础设施里非常务实的设计，值得专门解释。

index.md：内容导向的全局目录

# Wiki Index

## Concepts

- [[attention-mechanism]] - Transformer 的核心机制，包含线性注意力变体
- [[context-compression]] - LLM 上下文压缩技术综述
- [[rag-architecture]] - 检索增强生成架构模式
- [[llm-wiki-paradigm]] - 持久化知识积累范式

## Entities — Tools

- [[obsidian]] - 知识库 IDE
- [[claude-code]] - AI 编程辅助工具
- [[qmd]] - 本地 Markdown 搜索引擎

## Synthesis

- [[rag-vs-llm-wiki]] - 两种知识管理范式的深度对比
- [[2026-ai-agent-landscape]] - 2026 年 AI Agent 生态全景

index.md 替代了向量数据库的角色。在中等规模（~100 个来源，数百页面）下，这个简单的文件表现出乎意料地好。LLM 可以快速扫描 index.md 找到相关页面，比语义检索更透明、更可控。

log.md：时间顺序的操作历史

## [2026-04-09] ingest | karpathy-llm-wiki

- 创建来源摘要页
- 更新了 [[llm-wiki-paradigm]]，[[rag-architecture]] 概念页
- 新建了 [[obsidian]]，[[qmd]] 实体页
- 发现与 [[weaviate-rag-benchmark-2025]] 的矛盾，已标记

## [2026-04-07] lint

- 发现 3 个孤立页面，已添加到 index.md
- 标记 2 个可能陈旧的声明（超过 6 个月）
- 建议新建 [[linear-attention]] 概念页

## [2026-04-05] query | RAG vs LLM Wiki 核心差异

- 生成综合页 [[rag-vs-llm-wiki]]，已存入 /synthesis/

log.md 使用统一的前缀格式（## [日期] 操作类型 | 标题），这让它可以用简单的 Unix 工具解析。想知道过去一个月 ingest 了哪些来源，一条 grep "ingest" log.md 就够了。

LLM Wiki vs RAG：如何选择？

维度	RAG	LLM Wiki
知识积累	无，每次查询重新派生	有，持久化复合工件
跨文档推理	弱，依赖检索质量	强，Ingest 时预建关系
矛盾检测	无	Lint 时主动标记
查询延迟	快（实时检索）	首次慢（Ingest 编译），后续快
维护成本	无额外成本，但也不积累	LLM 接管，近乎零
适用规模	大规模（万级文档）	中等规模（百级来源）
语义模糊查询	强（向量相似度）	弱（依赖 index.md 导航）
知识演化追踪	无	有，Lint + 时间戳
审计与溯源	弱	强（log.md + git）

核心取舍总结：

选 RAG：需要在大量文档中做模糊语义检索；不需要积累知识，只需要即时回答；来源变化频繁，维护一个 wiki 的代价大于收益
选 LLM Wiki：在固定领域深耕，来源有限但需要深度综合；需要追踪知识演化，检测矛盾；需要让探索本身变成可复用的知识资产

两者也不是非此即彼。一个成熟的知识管理系统可以是：用 LLM Wiki 维护深度结构化知识，用 qmd/BM25 做基础的文字匹配检索，不需要引入向量数据库也能覆盖大多数查询需求。

工具链的轻量哲学

Karpathy 建议的工具链刻意保持轻量，背后有明确的设计理由：

工具	用途	为什么这个而不是替代品
Obsidian	Wiki IDE	原生 Markdown + wikilinks，无锁定，本地存储
git	版本历史	版本控制、分支、diff 全部免费获得
qmd	本地搜索	BM25 + 向量混合，全本地，有 MCP 接口
index.md	导航文件	替代向量数据库，中等规模够用，完全透明
Marp	Markdown 幻灯片	Query 结果可直接输出为演示文稿

没有引入向量数据库和 RAG 基础设施，这本身就是一个设计选择：简单文件导航损失了语义模糊性，但换来了完全的透明度、可调试性和零运维成本。

一个重要的延伸点：wiki 即 git 仓库。这意味着：

任何一次 ingest 的变更可以完整 diff，知道 LLM 修改了哪些页面
可以创建分支探索新的分析方向，不满意就 revert
多人协作通过 PR 合并知识，code review 的方式审核知识更新
完整的操作历史，什么时候摄取了什么来源，一清二楚

Vannevar Bush 的 Memex：这个想法的哲学前身

LLM Wiki 在精神上与 Vannevar Bush 在 1945 年设想的 Memex 高度相关。Bush 在论文《As We May Think》里描述了一种个人策划的、文档间具有关联路径的知识存储系统。

Bush 的核心洞察是：文档间的关联本身，与文档一样有价值。一条精心建立的概念链接，把两篇看似无关的来源联系起来，这个关联行为本身就是知识创造。

但 Bush 无法解决的问题是：谁来做维护工作？ 建立关联需要持续的智力劳动，而人类的注意力和时间有限。

LLM Wiki 解决了这个问题。LLM 不会厌倦更新交叉引用，不会忘记维护一致性，可以在一次 Ingest 中同时更新十几个页面。维护成本趋近于零，Memex 的愿景才真正可行。

总结

LLM Wiki 不是更好的 RAG，而是一种根本不同的范式转变：从"每次查询时重新发现知识"，到"让知识作为复合工件持续积累"。

四个核心判断：

RAG 的问题不是检索不准，而是知识不积累。每次从零派生答案意味着每次都在浪费 LLM 的整合能力。
Wiki 历来失败的原因是维护成本，LLM 解决了这个问题。簿记工作正好是 LLM 擅长且不厌倦的事情。
Lint 机制是 LLM Wiki 的杀手级能力。自愈的知识库，矛盾主动被发现，陈旧声明自动被标记，这是 RAG 架构上无法实现的特性。
轻量工具链是刻意的设计选择。不需要向量数据库，index.md + git 在中等规模下完全够用，换来的是零运维和完全透明。

适用边界：个人研究、领域知识深度积累、长期项目、需要追踪知识演化的场景。不适合：海量文档的企业知识库、来源极度动态变化的场景、需要快速语义模糊检索的场景。