这是同一问题的两种范式：RAG把每句话打成碎片存进向量库，等问题来了再搜索拼答案。LLM Wiki在资料进入时就完成消化——LLM 自己写摘要、更新概念、标注矛盾、建立交叉引用，知识以复利方式累积。
RAG 解决"在哪个 chunk 里"；LLM Wiki 解决"我已经知道了什么，新信息怎么整合进去"。
Karpathy 2025 年提出：人负责收集素材，LLM 负责编译成互链的 Markdown Wiki，人只读不写。核心是三件事——Ingest（读→写摘要→更新索引→更新关联页面→记日志）、Query（读索引定位→钻 2-3 页→合成答案带引用）、Lint（扫矛盾/过期/孤儿/缺失）。
把文档切成 chunk → embedding 化 → 存向量数据库。用户提问时做语义搜索取 top-K chunk → 塞入 prompt 让 LLM 从碎片里拼答案。每次查询独立，不积累知识。典型工具：LangChain/Pinecone/Weaviate/Chroma。
| 维度 | LLM Wiki | 传统 RAG 向量库 |
| 知识何时加工 | 摄取时编译——进库即消化 | 查询时检索——来了问题才找 |
| 知识累积 | 复利增长——100 篇比 10 篇更聪明 | 无状态——查 100 次和第一次没区别 |
| 数据形态 | 互链 Markdown 页面，人类可读 | 向量碎片（chunk），人类不可读 |
| 维护者 | LLM 全权负责——人只管投喂和提问 | 人管索引策略、chunk 大小、embedding 模型 |
| Token 效率 | 高——按需钻页面，调研可降 95% | 低——top-K chunk 全塞 prompt |
| 知识一致性 | 强——有作者/日期/来源，矛盾可标注修正 | 弱——碎片拼接，同问不同 chunk 答案矛盾 |
| 长期记忆 | 本身就是记忆系统——旧事实可标记过期 | 无"更新"概念——新旧 chunk 等权拼接 |
| 规模边界 | ≤40 万字用 index 导航；400 万+需辅助检索 | 天生适合大文档量 |
| 人类可读 | 标准 Markdown，Obsidian 当浏览器 | 无法直接阅读 |
| 典型工具 | Claude Code + Obsidian / claude-obsidian / llm-wiki | LangChain / Pinecone / Weaviate / Chroma |
Karpathy 原话：40 万字以内用 index.md 导航就够了，覆盖 90% 个人场景；超过 400 万字需要引入检索。Oh My KB 目前就处在这个范围。
raw/ — LLM Wiki 的 Raw 层，只读只追加wiki/ — LLM Wiki 的 Wiki 层，编译流程维护CLAUDE.md — Schema 层，定义结构和约定QMD 向量索引 — 规模增长后的检索补充（混合区）