比
RAG vs 编译式 Wiki
查询时检索与编译式知识库的对比:双方论据齐备——积累性优势 vs 错误放大与持续维护成本,及三方互补的完整图景
RAG vs 编译式 Wiki
依据三份独立来源:Karpathy 原文(wiki 一方)、Vishal Mysore 三方对比(批判视角)、MindStudio 选型分析(RAG 辩护 + 混合模式)。正反论据均已入库,交叉印证后 confidence 升为 high(2026-07-03,此前单一来源标 medium)。
本质区别:“重推理发生在哪里”
这是一个架构决策而非工具选型(Mysore 框架):RAG 的重推理在查询时——每次调用现场检索、现场综合,没有做过的记忆;编译式 wiki 的重推理在摄入时——预先编译综合,查询时读已结构化的页面。这个决策同时决定维护负担、失败模式、扩展上限。
| 维度 | RAG(查询时检索) | 编译式 Wiki |
|---|---|---|
| 积累性 | 默认无状态——“每次从零重新发现知识”(可以工程化补状态,但每一步都是额外工作) | 持久复利——交叉引用、矛盾标记、综合分析一次构建持续复用 |
| 错误传播 | 错误孤立:每次重读原文,上次答错不影响下次 | 错误放大:ingest 读错一次,烘焙进库,之后每个答案都带着它 |
| 扩展上限 | 数百万文档 | 约数百份资料(有界、精选的语料) |
| 结构保留 | chunking 破坏文档结构(实体关系、跨源矛盾在 512-token 切片中消失) | 结构即产品 |
| 可解释性 | 检索黑盒,难调试 | 人可读可改,错了改页面即可 |
| 维护成本 | 更新需重嵌入/失效管理 | 持续知识工程:一致性、schema 漂移、静默退化、错误传播验证 |
| 基础设施 | 向量库 + 嵌入管线 | markdown + 索引(近零设施) |
反方论据(wiki 的真实弱点,两份独立来源)
- 错误放大是编译式的结构性风险:复利优势只在 ingest 质量高时成立,质量差时反转为“复利劣势”,且用户无从察觉(Mysore)。
- 持续知识工程才是真限制,不是上下文窗口:不主动维护就过时,“然后 agent 输出错误指导”(Mysore + MindStudio 一致)。
- “团队不维护 wiki”是真实约束:做不到持续策展时,自动 re-indexing 的 RAG 更稳健(MindStudio)。
- 图书馆没有图书管理员:wiki 知道领域但不知道谁在读、为什么读——这个缺口由 agent memory 补位,不是 wiki 自己能解决的(Mysore)。
收敛结论:互补而非替代
三份来源在此点上罕见地一致:LLM Wiki 不是检索的替代品,是可叠加的组织层。Karpathy 本人建议大规模时加 BM25/向量混合搜索;实践中的混合模式(MindStudio):wiki 管架构/约定类知识 + RAG 管大规模搜索,或 wiki 索引作 RAG 的路由层。选型依据:语料是否有界、是否有人长期维护、问题是搜索型还是综合型。
对本知识库的意义
- 本库场景(个人长期积累、有界语料、agent 持续维护)落在 wiki 的甜区;
- 反方批评已转化为防御设计:lint 双层化 + 红队审计 + 生成纪律(对“错误放大”)、每次操作后自检 + 关系图谱(对“持续知识工程”)——批评成立,防御在建,长期有效性待实践检验(本库推断);
- 规模逼近数百份资料时,按 Karpathy 与 Mysore 的共同建议评估引入本地混合搜索。