LLM

一份关于 LLM Wiki 知识编译范式的完整学习文档。涵盖它是什么、思想起源、三层架构、三大操作、工程化落地、以及适用边界。 本文融合了 Karpathy 原始范式的公开资料与一套企业级 LLM Wiki 系统的真实工程实现（已做通用化脱敏）。文末附参考资料与事实核查说明。 一、一句话理解 LLM Wiki LLM Wiki 是一个「知识编译器」：它把杂乱的原始资料（raw）当作源代码，用一个受严格提示词约束的 LLM Agent 作为编译器，产出结构化、相互链接、可持续增量更新的知识库产物（wiki/docs），最后可发布到团队平台供人阅读。 用 Karpathy 本人的类比： “Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。” “LLM 是作者，人是主编。” 人负责机器做不好的事——策展（挑选高质量来源）、探索（决定研究方向）、提问（提出好问题）；LLM 负责那些"无人愿做、成本极低"的繁重簿记：总结、建立交叉引用、归档、记录变更。 二、核心洞察：编译知识，而非检索知识 这是整套范式的灵魂。 如果你用 RAG 搭过知识库，多半有过这种别扭感：明明是同一批文档，用户每问一次，系统就要重新检索、重新塞进上下文、让模型重新"读懂"一遍。答案用完即弃，下一次从零再来。 Karpathy 用一个精准的类比点破了这件事的荒谬： 这就像每次运行程序都重新解释一遍源代码，而不是先把它编译好。 RAG 是解释型语言，LLM Wiki 是编译型语言。 两种范式在"知识何时被处理"这件事上，存在根本分歧： 图 1：RAG 在「查询时」反复现读、不积累；LLM Wiki 在「摄取时」编译一次、之后反复复用并自我生长。 维度 传统 RAG（解释型） LLM Wiki（编译型） 知识处理时机 查询时——每次提问都重来 摄取时——每个源只处理一次 是否积累 不积累，每次从零"重新发现" 随每个源和每次查询复利增长 算力/Token 每次都加载大量原始文档 读索引即可导航，Token 大幅下降 基础设施 向量数据库、embedding 管道 零基础设施，纯 Markdown + Git 可读性 chunk 碎片，人难以直接阅读 人类可读的 wiki，可直接编辑、可 diff 矛盾与缺口 难以显式追踪 元数据里显式记录矛盾与待解问题 维护者 系统（黑盒） LLM（透明、有据可查） ⚠️ 预防针：社区里流传"Token 减少约 95%、比 RAG 高效约 70 倍"之类的说法，这些数字来自个别实践者的估算，并非严格基准测试，请当作"方向性直觉"而非"性能承诺"。 ...