RAG 负责召回，LLM Wiki 负责沉淀：团队知识系统为什么不能只做检索

原文链接 ：AI 小老六

很多团队在知识建设上都会经历同一个阶段：文档越来越多，检索越来越强，问答也能跑起来，但真正需要复用的判断却始终沉不下来。你能把资料找回来，却很难保证下一次不用再理解一遍。

这也是我看 Andrej Karpathy 提出 LLM Wiki 时最有感的一点。它真正切中的，不是"再造一个知识库产品"，而是把一个长期被忽略的问题说透了：有些知识适合在查询时临时拼装，有些知识则应该在入库时就先完成一轮整理、抽象和连接。前者更接近 RAG，后者更接近 wiki 式的知识编译。

如果把这两类机制混成一件事，知识系统很容易沦为一个更昂贵的搜索入口。它能回答问题，但不能稳定复用判断；能召回原文，却不能把经验真正积累下来。

问题不在"能不能找到"，而在"要不要反复理解"

RAG 的价值从来都不小。它擅长保存原始语义，适合挂接大规模资料，也适合处理那些低频、长尾、临时出现的问题。对于"某份方案里有没有提过这个字段""去年的会议里谁说过这件事"这类问题，RAG 的路径非常合理：先把资料找出来，再让模型基于上下文完成理解。

问题在于，团队里并不只有这类问题。

很多真正消耗协作成本的内容，恰恰不是"找不到"，而是"每次都要再想一遍"。比如：

为什么当时选了方案 A，没有选方案 B。
某类系统约束为什么一直存在，不能轻易改。
一个业务规则的边界到底在哪里，历史上踩过哪些坑。
几份零散资料之间，究竟能抽出什么稳定结论。

这类内容只靠检索并不划算，因为它们的成本不在召回，而在重复理解。

RAG 的能力边界：保存原料，按需取用

从系统设计角度看，RAG 更像一种"存储优先"的范式。它尽量不提前改写知识，而是把原始材料保留下来，在用户发问时再做上下文拼装。

这种范式有三个天然优势：

信息保真度高，离原始出处近。
扩展资料规模相对直接。
对冷门问题更友好，不需要提前判断哪些内容值得加工。

但它也有明显边界。只要一个问题会高频重复出现，RAG 就会不断重复支付同一种理解成本。系统每次都要重新检索、重新组装、重新归纳。短期看没问题，长期看就会暴露出两个症状：

回答能出来，但稳定性依赖当次召回质量。
知识能访问，却没有真正形成可维护的资产。

换句话说，RAG 很擅长"把资料带到现场"，却不天然负责"把判断沉淀下来"。

如果把两种思路并排看，差异会更直观：

图：RAG 负责把原始资料带回现场，LLM Wiki 负责把高频判断沉淀成可复用资产

维度	RAG	LLM Wiki
处理时机	查询时再理解	写入时先做一轮抽象
主要目标	找回原始资料	固化可复用判断
更适合的内容	冷区、长尾、低频问题	半熟、高频、反复解释的问题
典型产物	检索结果、引用片段、即时回答	概念页、实体页、专题判断
成本曲线	每问一次，理解成本支付一次	前置加工一次，后续持续复用

LLM Wiki 的关键，不是整理文档，而是编译知识

LLM Wiki 更有意思的地方，在于它把"理解"这件事往前移了一步。

它不是等问题来了再临时组织答案，而是在资料进入系统时，就先把其中可复用的部分抽成更稳定的知识对象。原本分散在报告、聊天、会议纪要、设计文档里的内容，会被改写成更适合长期复用的页面、概念、关系和阶段性判断。

这也是为什么我更愿意把它理解为"编译"，而不是"整理"。

"整理"通常意味着换个目录、改个标题、把东西放整齐；"编译"则意味着结构发生了变化。原始资料是高噪声、低结构的，而编译后的知识对象应该具备更强的复用性，至少要回答清楚下面几类问题：

这件事到底在讲什么。
它跟哪些概念或对象有关。
哪些判断是稳定的，哪些只是阶段性的。
当新资料进来时，原有结论要不要更新。

如果没有这一步，知识库再大，也可能只是文档仓库；只有当资料之间开始形成关系，判断开始拥有版本感，系统才真正进入"知识资产"阶段。

Obsidian 在介绍 backlinks 时强调过一件很重要的事：知识的价值不只在单页内容，也在页面之间的相互引用和反向链接。Obsidian Backlinks^[1] 这点放到团队场景里尤其成立。真正有复用价值的，不是某一份孤立文档，而是文档之间逐渐显露出来的关联结构。

真正值得编译的，是"半熟知识"

并不是所有内容都值得用 wiki 方式做重度沉淀。

一个实用的判断方法，是按"出现频率"和"单次理解成本"把知识分层。最值得编译的，往往不是最热的内容，也不是最冷的内容，而是那部分反复出现、但每次都要花脑力重新确认的"半熟知识"。

可以把它简单理解成下面这张表：

知识类型	特征	更合适的机制
热区知识	团队已经烂熟于心，几乎不需要查	人的直觉与日常协作
冷区知识	很少用到，但需要时必须能找回原文	RAG / 搜索
半熟知识	经常会碰到，但每次都要重新解释一遍	LLM Wiki / 编译式沉淀
失效知识	已经过时或只剩历史价值	归档与保留引用

这类"半熟知识"在不同角色里都很常见。

对产品或运营来说，它可能是：

竞品分析里反复出现的稳定结论。
某条关键指标波动背后的因果链。
过去几个版本反复验证过的用户分层逻辑。

对研发团队来说，它更可能是：

某个系统边界为什么不能轻易打破。
一类故障的典型触发条件与规避方式。
技术选型背后真正的取舍，而不是表面上的功能对比。

这些知识的共同特征是：你通常知道个大概，但不敢完全凭记忆拍板。只要这种"我得再确认一下"的场景频繁出现，就说明这部分知识已经值得被编译。

更靠谱的架构，不是二选一，而是分层协作

把 RAG 和 LLM Wiki 视作对立路线，往往会把问题想得过窄。它们解决的其实不是同一层问题。

RAG 更像召回层，负责把原始资料带回来；LLM Wiki 更像沉淀层，负责把已经证明会重复使用的知识加工成稳定结构。一个偏"找到"，一个偏"留住"。

更实用的系统通常长这样：

图：原始资料同时流向召回层与知识编译层，回答与沉淀各走一条链路

这个结构背后的分工很清楚：

原始资料层负责保真，不急着下结论。
检索层负责覆盖面，解决"去哪找"。
编译层负责提炼高频判断，解决"值不值得反复再想"。
复用层负责把这些沉淀后的内容重新喂回团队协作。

一旦这样拆开，很多争论就会自动消失。不是"RAG 还是 LLM Wiki"，而是"哪些内容只需要被检索，哪些内容值得被编译"。

判断一套知识系统有没有长出来，要看它会不会复利

一个只有问答能力的系统，本质上仍然偏工具型。你问一次，它答一次；你换个问法，它再临时拼一次。它当然有用，但这种有用更接近即时服务，而不是长期积累。

真正成熟的知识系统会出现另一种迹象：新的资料进入后，不只是"可被搜到"，而是会改变已有理解；旧的判断也不是静态躺在那里，而是能被补充、修正、链接和替换。到这一步，知识才开始复利。

这时你会看到两个变化：

同类问题的回答越来越稳定，因为底层判断已经被沉淀。
团队对关键概念的理解越来越一致，因为大家复用的是同一批经过编译的页面，而不是各自从原文现推一次。

Karpathy 提醒我们的，恰恰是这一点：知识系统不能只追求"把答案找出来"，还得关心"哪些理解值得留下来"。llm-wiki^[2]

结语

所以，知识库的终点并不是在 RAG 和 LLM Wiki 之间二选一。

更准确的说法是：RAG 让系统保有回到原始资料的能力，LLM Wiki 让系统把高频、昂贵、值得复用的判断沉淀成资产。前者解决信息召回，后者解决知识复用。

如果一个团队只有 RAG，它拥有的是更强的检索；如果它同时拥有一层持续更新的 wiki 式沉淀，它才真正开始拥有自己的知识系统。

引用链接

[1] Obsidian Backlinks: https://obsidian.md/help/backlinks

[2] llm-wiki: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f