LLM Wiki 批评：错误放大

原文：raw/sources/vishalmysore-rag-memory-wiki.md（dev.to《RAG vs. Agent Memory vs. LLM Wiki: A Practical Comparison》，Vishal Mysore，2026-04-19）。独立作者的三方对比——本库期待已久的非 Karpathy 阵营视角，含对 LLM Wiki 的实质批评。

核心框架：“重推理发生在哪里”

作者认为三种方案的本质区别不是工具选型，而是架构决策：重推理发生在何时——RAG 在查询时（每次从零综合）、agent memory 分两相（对话时抽取写入 + 查询时读回）、LLM Wiki 在摄入时（预编译综合）。这个决策同时决定维护负担、失败模式、扩展上限与个性化能力。

对 LLM Wiki 的三大批评（本库首批反方论据）

1. 错误放大（error amplification）：RAG 每次查询重读原文，错误是孤立的；LLM Wiki 把 LLM 的解读烘焙进知识库——ingest 时读错一次，之后每个答案都带着这个错误，且用户无从察觉。复利优势只在 ingest 质量高时成立，质量差时反转为复利劣势。
2. 持续知识工程（continuous knowledge engineering）：真正的限制不是上下文窗口，而是持续维护成本——页面一致性、schema 漂移、LLM 编辑造成的静默质量退化、ingest 错误沿链接传播的验证。
3. 图书馆没有图书管理员：wiki 知道领域，但不知道谁在读、为什么读——同一页面对外科医生和患者读起来一模一样。这是维护解决不了的结构性缺口（agent memory 恰好补这一块）。

重要的正本清源

• Karpathy 的 gist 是 idea 不是 spec：“formal ingest/lint/query 操作、严格架构边界、治理层”都来自社区实现与博客阐发，不是原始构想的一部分。
• LLM Wiki 不是检索的替代品，是可以叠在检索系统之上的组织层；Karpathy 本人也建议大规模时加 BM25/向量混合搜索。
• 三方不是竞争关系：wiki 管领域知识、memory 管用户知识、RAG 管大规模文档检索——生产系统日益三者并用，而团队普遍低估的是底下的治理层（数据质量/新鲜度/权限）。

对本知识库的印证与警示

• 本库的 lint 双层化、红队审计、生成纪律（schema-common §8）正是对“错误放大”与“持续知识工程”的针对性防御——批评成立，防御已建。
• 详见更新后的 RAG vs 编译式 Wiki 与新页 Agent Memory。