这是同一问题的两种完全不同的解法。
RAG（Retrieval-Augmented Generation）：把文档切成碎片，向量化存库。每次提问时临时检索，从碎片堆里拼答案。无记忆、无积累、无复利。
LLM Wiki（Karpathy 2025）：人负责收集素材放入 raw/，LLM 负责将素材"编译"成互链的 Markdown Wiki。知识在摄取时就被消化——写摘要、更新概念、标注矛盾、建立交叉引用。每次摄入让整个 wiki 更聪明。
RAG 问"答案可能在哪个 chunk 里"；LLM Wiki 问"我已经知道了什么，新信息怎么融入"。一个是搜索引擎的延伸，一个是知识系统的构建。
原始素材存储区。LLM 只读不改，永远保留原文完整。人往里丢文章、PDF、对话记录——不需要整理格式，不做预处理。
一句话：丢进去就是投入，不需要"先整理好"。
LLM 全权维护的结构化知识层——相互链接的 Markdown 文件。包括摘要、概念、对比、综合讨论。LLM 自己写、自己改、自己维护交叉引用。
类比：Wiki = 代码库，LLM = 程序员，Obsidian = IDE。
CLAUDE.md / AGENTS.md 文件定义目录结构、页面格式、命名规则、操作步骤。所有指令集中于此，Wiki 增长时只需更新 schema，无需修改每个页面。LLM 严格遵循 schema 维护 Wiki，人通过修改 schema 控制生态系统走向。
一篇新素材可能触碰 10-15 个已有页面
不是从碎片拼答案，而是从已组织好的知识页合成
Wiki 级别的健康检查，防止知识腐烂
基于语义相似度的 top-K chunk 天然偏向"最像"而非"最相关"。关键证据可能出现在与查询用词不同的段落里，但 embedding 距离很远，直接被跳过。跨文档的关联性完全丢失。
同一个问题，不同 chunk 来源不同时期、不同作者、不同立场。RAG 把它们等权拼接，LLM 在碎片间左右横跳——前一句引用 2024 年的结论，后一句引用 2026 年的修正，但不标注矛盾。
RAG 不区分"已被新证据推翻的旧事实"和"当前有效的新事实"。新旧 chunk 混存，同等对待。没有版本管理、没有冲突标记、没有过期机制。知识越加越脏。
LLM Wiki 的设计就是针对这三个病灶的：Ingest 时整合跨文档关联（治①）、标注矛盾来源（治②）、维护更新过期内容（治③）。
以知识库实际对话为例——用户问"Agent 记忆系统选型建议"：
根据我们之前的调研（2026-07-16 上交清华 12 系统评测），Agent 记忆没有通吃方案，需要先判断你的主要失败模式：
跨会话聚合失败 → 选图/树结构（Zep/Cognee），它们有时间版本管理，能标记旧事实过期。
长对话精确事实丢失 → 保留原始内容比摘要更重要，SimpleMem 在 Locomo Recall@1 达 39.0。
成本敏感 → LightMem 3.67s/查询，Zep 155s/查询。成本不由结构复杂度决定，由维护范围决定。
我们的记忆系统（CLAUDE.md + recent.md + topics/）对应论文四模块雏形，但缺显式时间版本管理和冲突处理。详见 [[2026-07-16-Context-Token失效机制]]。
↳ 每个判断都有出处、有时间、有来源标注。跨文档知识已在家整理好。
根据检索结果，Agent 记忆系统包括 Mem0、Letta、Zep、Cognee 等方案…
（chunk 3 来自 2025 年的 Mem0 宣传文，说"一行代码接入记忆"）
（chunk 7 来自 2026 年论文，说"没有通用赢家"）
…两者在结论层面存在分歧…
（chunk 2 缺失——关于成本的核心数据被 embedding 排序挤到了第 6 名没被召回）
↳ 碎片拼接、观点冲突不标注、跨文档关联全丢。每次查都得重新拼。
| 维度 | LLM Wiki | 传统 RAG 向量库 |
| 知识加工时机 | 摄取时编译——进库即消化、关联、整合 | 查询时检索——来了问题才从零搜索 |
| 知识累积模式 | 复利增长——每次 Ingest/Query 都让 wiki 更丰富 | 无状态——查 100 次和第一次没区别，无积累 |
| 数据形态 | 互链 Markdown 页面（摘要+概念+对比），人类可读 | 向量碎片（chunk），人类不可直接阅读 |
| 维护者 | LLM 全权负责——人只投喂素材和提问 | 人管 chunk 大小、索引策略、embedding 模型版本 |
| Token 效率 | 高——按需钻 2-3 个页面（claude-obsidian 实测降 95%） | 低——top-K chunk 全塞 prompt，同质片段重复消耗 |
| 知识一致性 | 强——来源/日期/作者可追溯，矛盾可标注可修正 | 弱——碎片拼接，新旧混存，"精神分裂" |
| 跨文档关联 | 天然——编译过程中通过 wikilink 显式建立引用图 | 丢失——chunk 间无显式关联，依赖 embedding 隐式相似 |
| 版本/过期管理 | 内置——旧事实可标记过期，新事实更新实体页 | 无——不区分新旧，等权检索等权拼接 |
| 回答可溯源性 | 完全可追溯——每个结论都有 wikilink 回原文 | 弱——可以追溯 chunk 但不知道 chunk 的上游文档 |
| 规模边界 | ≤40 万字最优；400 万+需引入检索辅助 | 天生大文档量，但小规模时过度设计 |
| 查询模式 | Index → 定位页面 → 钻取 → 合成（结构导航） | 语义搜索 → top-K → 拼接（相似匹配） |
| 人类可读/可浏览 | ✅ Obsidian 当浏览器，可随意翻阅探索 | ❌ 不可读，不可浏览 |
| 典型工具 | Claude Code + Obsidian · claude-obsidian · llm-wiki · Moxt | LangChain · Pinecone · Weaviate · Chroma · Qdrant |
| 最好用的场景 | 个人知识库 · 小团队文档 · 调研积累 · 第二大脑 | 企业知识库 · 客服 FAQ · 大文档量快速检索 |
Karpathy 原话："40 万字以内扁平索引+LLM 导航够用。400 万字以上同套办法会垮——须引入检索。但关键是：编译模式解决的问题（只见局部/无维护概念/无复利）对所有规模都成立。"
| 局限 | 说明 | 缓解方案 |
| 规模天花 | 数百篇后 LLM 在 Ingest 时难以准确判断所有需更新的关联页面 | 引入 QMD/向量索引辅检索；按领域分库 |
| Agent 场景失效 | Markdown Wiki 作为 Agent 运行时记忆层结构性失效——token 预算不够、数据格式不匹配 | 混合架构：Markdown 服务人，结构化 DB 服务 Agent（Mercu 方案） |
| 小体量无效益 | 少于 10 篇时编译成本 > 手动整理 | 边界条件：只在页面可压缩"分散在多来源里的事实"时才赚 |
| 过度关联风险 | LLM 可能建立过多低质量 wikilink 导致 wiki 膨胀 | Lint 操作 + 人工剪枝 + 关联质量评分 |
| "外包理解"陷阱 | 让 LLM 替你读和总结 = 可能外包了你的理解（学习型使用致命） | 区分学习型 vs 研究型使用；关键领域自己读原文 |
raw/ Raw 层 — 只读只追加，9 个子目录，原始素材不可变，有路由脚本自动分域wiki/ Wiki 层 — summaries/ + concepts/ + All-Sources + All-Concepts，编译流程全量重建CLAUDE.md Schema 层 — 项目指令、路径约定、编译规则、输出规范QMD 搜索 检索补充 — 全文 BM25 + 语义向量 + HyDE，规模增长后的导航辅助memory/ 记忆层 — 用户画像、行为偏好、项目状态、家庭财务等话题文件健康检查 Lint 层 — 四类自动扫描（摘要完整性 / 概念健康 / 索引一致性 / cron 调度一致性），含断裂链接修复、文件名违例检测、疑似重复检测、概念别名覆盖率、raw 未知子目录检测、月度 LLM 语义去重| 阶段 | 代表 | 核心思路 | 关键局限 |
| 1. 纯关键词搜索 | Elasticsearch · Solr | BM25 匹配，返回原文段落 | 不懂语义，"苹果股票"和"水果价格"无法区分 |
| 2. 向量语义检索 | Pinecone · Weaviate · Chroma | embedding 化 → 语义相似 → top-K 拼接 | 只解决"找到"，不解决"理解"和"积累" |
| 3. Agentic RAG | LangChain · LlamaIndex · Cohere | LLM 自主规划检索步骤，多轮检索+综合 | 仍是从零检索，每次跑完整流程 |
| 4. LLM Wiki | Karpathy llm-wiki · claude-obsidian | 摄取时编译，持久化知识层，复利累积 | 规模上限约 40 万字纯结构导航 |
| 5. 混合架构（当前前沿） | Oh My KB（Wiki+QMD）· Moxt · Mercu | Wiki 层服务人类 + 检索层服务 Agent + 混合导航 | 系统复杂度上升，需同时维护两套体系 |