Karpathy LLM Wiki 模式
不用 RAG，用 LLM 把语料增量编译成 markdown wiki —— 一次编译，多次复利查询。selfwiki 整套架构的灵感来源。
主张（Claim）
知识库的核心痛点不是”检索”而是”bookkeeping”——更新交叉引用、合并重复、识别空白。RAG 把这些痛点放到了查询时（每次重算），代价巨大。Karpathy 的洞察：让 LLM 一次性把原始素材 compile 成 markdown wiki（摘要 + 实体页 + 概念页 + 交叉引用），之后的查询只需小窗口综合 + wiki lookup，号称比 RAG 效率高 70 倍。LLM 拿 bookkeeping 的体力活，人负责选源和提问。
为什么重要
对于个人知识库（语料能塞进 LLM 上下文窗口的规模），LLM Wiki 模式完爆 RAG：
- 复利：每次查询的答案落档成新 wiki 页，下次同问直接 lookup
- 可读性：wiki 是给人看的，RAG chunk 是给机器看的
- 零基础设施：纯 markdown 文件，不需要向量数据库
- 跨工具：Claude / Codex / Gemini 都能直接读
selfwiki 整套架构（CLAUDE.md schema + skills + compile_stage + log.md）就是 Karpathy 模式的实现。
证据（Evidence）
- douyin_01 —— Garry Tan GBrain 项目的相关讨论（用 OpenClaw + Hermes 实现类似模式）
- Karpathy 原始 gist：github.com/karpathy/442a6bf555914893e9891c11519de94f
- VentureBeat 报道：“Karpathy shares LLM Knowledge Base architecture that bypasses RAG”
三层架构
第一层 · 原始素材（不可变） ← 文章、视频、转写
第二层 · WIKI（LLM 拥有） ← 摘要 / 实体页 / 概念页 / MOC
第三层 · SCHEMA（人和 LLM 共遵守）← CLAUDE.md / index.md / log.md
详见 CLAUDE 第 2 节。
三大操作
- Ingest：扔新源 → LLM 读完，一次更新 10-15 页 + append log
- Query：问问题 → 答案回写成新页（复利）
- Lint：周期性查矛盾、过时、孤儿页
连接
- 实现工具：claude-code、obsidian-mcp
- 关键操作：agent-orchestration（compile 阶段就是 agent 自我编排）
- 对照：rag-retrieval（传统方法，被绕开）
待解决的问题
- 当 wiki 规模超过 LLM 上下文窗口（>1M tokens），Karpathy 模式会不会失效？
- 多人协作时怎么管理写入冲突？（git 已经在用了）
- 完全本地化（用 Ollama）有可能跑通整套流水线吗？
Evidence
- douyin_20260527_Obsidian_终于能同时跑两个_AI_Obsidian_的_Claudian_插件刚更新到_v2 — Markdown knowledge architecture pattern successfully applied with Claudian