RAG 是临时查资料，LLM Wiki 是让知识开始复利

RAG 是临时查资料，LLM Wiki 是让知识开始复利

1. 问题不是“选 RAG 还是选 Wiki”

在企业 Agent 落地时，一个很容易出现的问题是：

到底应该做 RAG，还是做 LLM Wiki？

如果你还没有读过 Karpathy 的 LLM Wiki 原文，可以先看我整理的中文翻译仓库：

• 中文翻译仓库：huajiexiewenfeng/llm-wiki-cn

本文不重复翻译原文，而是基于 Karpathy 的 LLM Wiki 思路，继续讨论它和 RAG 在企业 Agent knowledge runtime 中的选型关系。

这个问题表面上是在选技术方案，实际上是在问另一个更底层的问题：

企业知识到底应该在什么时候被加工？

RAG 的答案是：用户提问时再加工。

Karpathy 式 LLM Wiki 的答案是：资料进入知识库时就开始加工，并且持续维护。

这两个方向不是简单替代关系。它们真正的差别，不在于有没有向量数据库，也不在于是不是 Markdown，而在于知识处理发生的阶段不同。

• RAG 是 query-time retrieval。
• LLM Wiki 是 ingest-time / maintenance-time synthesis。

RAG 更像临时查资料。

LLM Wiki 更像让知识开始复利。

2. 普通 RAG 的工作方式

普通 RAG 的典型流程是：

1. 收集企业文档
2. 文档解析和切分
3. 建立关键词索引或向量索引
4. 用户提问
5. 系统检索相关 chunk
6. LLM 基于检索结果生成答案

它解决了一个非常实际的问题：LLM 本身不知道企业内部知识，所以需要在回答时动态取回上下文。

比如用户问：

“PDS-2024-017 项目的验收标准是什么？”

系统可以从项目文档、验收报告、合同附件中找到相关片段，然后让 LLM 汇总回答。

这个模式对文档问答非常有效。

但它也有一个结构性问题：

每一次复杂问题，LLM 都在重新从原始资料里拼答案。

今天用户问“这个项目的验收标准是什么”，系统检索一次。

明天用户问“这个项目为什么延期验收”，系统又检索一次。

后天用户问“这个项目和另一个项目的交付风险有什么不同”，系统还是重新检索、重新拼装。

每一次回答可能都不错，但综合结果通常不会沉淀下来。

也就是说，RAG 很擅长回答“此刻的问题”，但不天然擅长积累“长期的知识结构”。

3. Karpathy 式 LLM Wiki 的工作方式

Karpathy 提出的 LLM Wiki 模式，核心不是“让 AI 写 Wiki 页面”，而是：

让 LLM 持续维护一个持久化、可链接、可演化的 Markdown Wiki。

它通常有三层：

• raw sources：原始资料，作为事实源，不随意修改。
• wiki：LLM 维护的 Markdown 页面，包括概念页、实体页、摘要页、比较页、综合页。
• schema：约束 LLM 如何维护 Wiki 的规则文件，比如AGENTS.md、CLAUDE.md或自定义说明。

当新资料进入时，LLM 不只是把它放进索引里等未来检索，而是会把它编译进已有 Wiki：

• 新建 source summary
• 更新概念页
• 更新实体页
• 增加 cross-reference
• 标记新旧资料冲突
• 更新 index
• 追加 log
• 把有价值的 query 结果沉淀成新页面

所以它的关键不是生成，而是维护。

这也是它和普通“AI Wiki”的区别。

普通 AI Wiki 更像是：AI 帮你写页面。

Karpathy 式 LLM Wiki 更像是：AI 像维护代码库一样维护知识库。

4. 核心差异：知识处理时机不同

RAG 和 LLM Wiki 的根本区别，可以放在一张表里看。

一句话总结：

RAG 把综合放在问题发生之后。LLM Wiki 把综合前移到资料进入和知识维护阶段。

这就是为什么 LLM Wiki 在一些场景可以替代 RAG。

它替代的不是所有检索能力，而是替代了“每次都从 raw chunks 里临时拼答案”的工作方式。

5. 为什么 LLM Wiki 在一些场景可以替代 RAG

假设你正在研究企业 Agent memory。

你收集了 50 篇文章、几篇论文、一些项目笔记和几段技术讨论。

如果用普通 RAG，当你问：

“Agent memory 有哪些主流路线？”

系统会从这些资料里检索相关 chunk，然后让 LLM 临时总结。

如果你过几天再问：

“RAG、long-term memory、LLM Wiki 的关系是什么？”

系统又要重新检索、重新综合。

但如果用 LLM Wiki，这些资料在进入时就已经被整理成了页面：

• Agent Memory.md
• RAG.md
• Long-term Memory.md
• LLM Wiki.md
• Knowledge Runtime.md
• Open Questions.md
• Source Index.md

当你再提问时，LLM 可以先读这些整理后的页面。

很多答案不需要再从 50 篇 raw sources 里重新拼，而是基于已经形成的知识结构继续推理。

这就是 LLM Wiki 能部分替代 RAG 的原因：

它把“每次问才综合”变成“持续综合、持续沉淀”。

适合这种替代的场景通常有几个特点：

• 知识规模中小
• 主题边界相对清楚
• 用户愿意参与校准
• source 质量相对可控
• 知识需要长期积累
• 经常出现跨文档综合问题
• 答案不一定每次都必须直接引用原始 chunk

典型场景包括：

• 个人知识库
• 论文研究
• 读书笔记
• 课程学习
• 竞品分析
• 尽职调查
• 项目复盘
• 小团队知识库
• 专题研究型 Agent

在这些场景里，LLM Wiki 往往比纯 RAG 更有价值。

因为用户需要的不是一次检索结果，而是一套不断变好的知识结构。

6. 为什么它不能完全替代 RAG

但 LLM Wiki 不能无条件替代 RAG。

尤其在企业场景里，很多问题仍然必须依赖 RAG 或搜索系统。

第一，企业知识规模可能很大。

一个企业可能有几十万份文档、工单、合同、会议记录、客户资料和系统日志。全部都靠 LLM 维护成 Wiki，成本和复杂度都很高。

第二，企业知识更新很频繁。

制度、价格、合同、组织架构、项目状态、客户信息都可能变化。如果 Wiki 更新不及时，就会变成一个“看起来很权威但其实过期”的知识层。

第三，权限控制很复杂。

RAG 系统通常可以在检索层做 metadata filter 和 ACL filter，确保用户只能看到有权限的文档。LLM Wiki 如果把多个 source 综合成一个页面，就必须非常小心权限污染：一个用户能不能看到这个综合页面，取决于它引用了哪些 source。

第四，很多问题必须引用原文。

法务、财务、合规、人事制度、合同审查等场景，不能只给综合结论。它必须告诉用户依据来自哪个原始文档、哪一条款、哪个版本。

第五，很多问题高度不可预测。

企业用户会问各种临时问题，比如某个错误码、某个合同编号、某个客户名称、某个表字段、某个接口参数。对于这类精确查询，搜索和 RAG 仍然非常重要。

所以更准确的判断是：

LLM Wiki 可以替代一部分 RAG 的临时综合工作，但不能替代企业级检索、权限、实时性和原文追溯能力。

7. Hybrid Search 为什么仍然重要

企业 RAG 里，一个非常基础但重要的能力是 hybrid search。

它通常指：

• 关键词检索
• 向量检索
• rerank
• metadata filter

关键词检索擅长精确匹配：

• 合同编号
• 客户名称
• 项目编号
• 工单号
• 错误码
• 接口名
• 表字段
• 制度编号

向量检索擅长语义匹配：

• 同义表达
• 模糊问题
• 用户没有使用原文关键词的问题
• 概念相近的问题

比如用户问：

“员工离职后多久要关账号？”

文档里可能写的是：

“人员离岗后，应在 24 小时内完成系统权限回收。”

这里向量检索有价值。

但如果用户问：

“PDS-2024-017 的验收标准是什么？”

这里项目编号必须精确命中，关键词检索很重要。

所以在企业 Agent 里，hybrid search 仍然是基础能力。

即使引入 LLM Wiki，也不是不要搜索，而是搜索对象可以变得更高级：

• 不只搜索 raw chunks
• 也搜索 Wiki pages
• 必要时再回到 raw sources

这样就形成了更稳的知识运行时。

8. 企业 Agent Knowledge Runtime 的组合方式

如果把 RAG 和 LLM Wiki 放在企业 Agent knowledge runtime 里，我更推荐把它们分层看。

这个架构里，各层职责不同：

• Raw Sources：事实源。
• LLM Wiki：知识综合层。
• RAG Index：证据检索层。
• Hybrid Search：召回 raw chunks 和 wiki pages。
• Agent Runtime：理解任务、调用工具、生成回答。
• Lint / Eval：检查冲突、过期、缺引用、错误回答。

这里最关键的是：

LLM Wiki 不应该替代 raw sources。它应该站在 raw sources 和 Agent runtime 中间。

它负责把知识整理得更好。

RAG 负责在需要证据时回到原文。

Agent 负责把整理后的知识和原始证据用于回答、推理和行动。

9. 不同场景怎么选

可以用几个问题来判断。

更具体一点：

如果你做的是制度查询、合同条款问答、客服知识库，先做 RAG。

如果你做的是长期研究、项目知识沉淀、专题分析、小团队经验库，优先考虑 LLM Wiki。

如果你做的是企业级 Agent，不要二选一。

应该组合：

• 用 RAG 保证证据可追溯
• 用 LLM Wiki 保证知识可积累
• 用 hybrid search 保证召回质量
• 用 schema 约束 LLM 如何维护 Wiki
• 用 lint/eval 保证知识层不腐化
• 用权限系统保证知识不会越权泄露

10. 一个容易踩的坑：把 LLM Wiki 当成自动摘要库

很多团队看到 LLM Wiki 后，可能会直接做成：

“把所有文档摘要成一堆 Wiki 页面。”

这其实还不够。

如果只是生成页面，而不维护页面之间的关系，不更新旧结论，不记录来源，不检查冲突，不把 query 结果回写，那它只是一个 AI 摘要库。

Karpathy 式 LLM Wiki 的关键在于四个动作：

• Ingest：新 source 进入时整合进 Wiki
• Query：基于 Wiki 提问
• Write-back：有价值的回答写回 Wiki
• Lint：定期检查冲突、过期、孤岛和缺引用

没有这些动作，就没有复利。

只有内容生成，没有知识维护。

11. 另一个坑：让 Wiki 变成新的幻觉源

LLM Wiki 最大的风险，是错误会沉淀。

RAG 回答错了，可能只是一次回答错。

LLM Wiki 如果把错误写进页面，后续页面又引用它，错误就会变成知识库的一部分。

所以企业场景里必须有治理机制：

• raw sources 不可随意修改
• Wiki 页面保留 source 引用
• 重要结论标记来源和时间
• 新旧资料冲突要显式记录
• 高风险内容需要人工审核
• 定期 lint
• 定期 eval
• 支持版本回滚
• 权限继承必须清楚

LLM Wiki 的正确定位不是“替代事实源”。

它是一个可维护的知识中间层。

事实仍然要回到 raw sources。

12. 我的建议：三种落地路线

如果是个人或小团队，我建议先从轻量 LLM Wiki 开始。

用 Markdown、Obsidian、Git、index.md、log.md和一个明确的 schema，就可以跑起来。

不一定一开始就上向量数据库。

如果是中型团队知识库，可以采用 LLM Wiki + 本地搜索。

例如：

• raw sources 保持原样
• wiki pages 由 LLM 维护
• index/log 作为导航
• Markdown 搜索或 BM25 作为检索能力
• 关键页面人工 review

如果是企业级 Agent，则建议 RAG + LLM Wiki + hybrid search 一起设计。

也就是：

• RAG 负责证据
• LLM Wiki 负责综合
• hybrid search 负责召回
• tools 负责执行
• governance 负责安全和质量

这时不要把 LLM Wiki 看成一个文档产品，而要看成 Agent knowledge runtime 的一层。

13. 结论

RAG 和 LLM Wiki 的区别，不是“向量库 vs Markdown”。

真正的区别是：

RAG 在提问时临时检索和综合。

LLM Wiki 在资料进入和维护过程中持续整理和沉淀。

RAG 让 LLM 会查资料。

LLM Wiki 让知识开始复利。

在个人研究、小团队知识库、专题积累场景中，Karpathy 式 LLM Wiki 可以替代一部分 RAG。

在企业级 Agent 场景中，它更适合作为 RAG 的上游知识综合层，而不是完全替代 RAG。

最终比较稳的架构不是二选一，而是：

用 LLM Wiki 沉淀知识，用 RAG 查证事实，用 hybrid search 找到上下文，用 Agent runtime 把知识变成行动。

这才是企业 Agent knowledge runtime 更合理的方向。

参考资料

• Karpathy 的 LLM Wiki Gist
• 中文翻译仓库：huajiexiewenfeng/llm-wiki-cn
• CSDN 翻译文章：Karpathy LLM Wiki 中文翻译