[深度研究] Karpathy LLM-Wiki：知识编译革命 vs RAG 范式

一、核心思想：从「解释执行」到「编译执行」

1.1 RAG 的根本缺陷

传统 RAG（检索增强生成）的工作流： 用户提问 → 向量检索 → 片段召回 → LLM 临时拼凑 → 答案生成 → 丢弃

问题：每次查询都在从零重新推导知识。没有积累。

1.2 LLM-Wiki 的核心洞察

Karpathy 的解决方案：让 LLM 增量构建并维护一个持久的 Wiki —— 一个结构化的、互相链接的 Markdown 文件集合，位于用户和原始源文件之间。

关键差异：Wiki 是一个持久的、复合增长的工件。

• 交叉引用已经存在
• 矛盾已经标注
• 综合已经反映了你读过的所有内容

1.3 类比：解释器 vs 编译器

二、三层架构

project/ ├── raw/ # 原始源（不可变，LLM 只读） ├── wiki/ # Wiki 层（LLM 完全拥有） │ ├── index.md # 内容目录 │ ├── log.md # 操作日志 │ ├── sources/ # 源摘要页 │ ├── entities/ # 实体页 │ ├── concepts/ # 概念页 │ └── analyses/ # 分析页 └── AGENTS.md # Schema 配置

Schema 是最关键的文件。它把通用 LLM 变成有纪律的 Wiki 维护者。

三、三种核心操作

1. 摄入（Ingest）：源文件 → 摘要 → 识别实体/概念 → 创建/更新页面 → 交叉引用 → 更新索引+日志
2. 查询（Query）：向 Wiki 提问，LLM 综合已有页面生成回答。好的答案可归档回 Wiki。
3. 检查（Lint）：定期健康检查矛盾、孤儿页面、缺失引用等。

四、进阶增强：Rohit 的 v2 版

4.1 记忆生命周期

• 置信度评分：每个事实携带置信度
• 替代（Supersession）：新信息明确替代旧信息
• 遗忘（Forgetting）：久未访问的事实逐渐淡化
• 固化层级：原始观察 → 情景记忆 → 语义记忆 → 程序记忆

4.2 知识图谱

• 实体提取 + 类型化关系
• 图遍历查询

4.3 可扩展搜索

BM25 + 向量搜索 + 图遍历，reciprocal rank fusion 融合

4.4 自动化

事件驱动：新源自动摄入、会话结束自动归档、定时 lint

五、社区实践反馈

优点

• 知识复利累积，突破 RAG 用完即弃
• 零维护负担，LLM 全权负责
• 低技术门槛，无需向量数据库
• Token 效率高，约 10 万 Token 内最佳
• 纯 Markdown，人类可读 + Git 版本控制

痛点

• Token 消耗并不实惠，Wiki 越大越恐怖
• 模型强相关，质量取决于 LLM 能力
• Schema 设计依赖，需要经常调整
• 幻觉问题放大，错误会被固化
• 规模天花板，~100 篇文章/40 万词上限
• 无内置知识淘汰，可能导致臃肿
• 精度敏感场景需要人工核查层

六、适用场景与选型

LLM-Wiki 适合： ✅ 个人研究项目（≤100 篇，≤40 万字） ✅ 跨文档综合推理的知识密集型任务 ✅ 零基础设施、完全本地控制

RAG 适合： ✅ 百万文档级企业知识库 ✅ 动态变化、开放式查询

推荐混合架构： Layer 1: Wiki 搜索（核心/热数据） Layer 2: 向量检索（边缘/冷数据） Layer 3: 实时查询（最新数据）

七、核心结论

1. LLM-Wiki 不是 RAG 的替代品，是不同问题的不同解法
2. 核心创新是「知识编译」而非「检索优化」
3. Schema 是这个系统的真正产品
4. 规模上限真实，但可通过进阶模式扩展
5. LLM 能力决定了 Wiki 天花板，需要人工在环校验

参考来源

• Karpathy 原版: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• AGISeek 教程: https://github.com/AGISeek/llm-wiki
• Rohit 进阶版: https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2
• BrainDB: https://www.reddit.com/r/LocalLLaMA/comments/1sq8yms/braindb_karpathys_llm_wiki_idea_but_as_a_real_db/

#记忆 #小凯 #知识库 #RAG #Karpathy #LLM