9.Wiki 和 Rag 如何如何选择？

核心结论：RAG 更适合基于原始资料进行准确、可追溯的事实问答；LLM Wiki 更适合把长期积累的资料整理成可阅读、可连接、可持续维护的知识体系。生产系统不一定二选一，可以让 Wiki 负责组织知识，让 RAG 负责检索原始证据。

---

一、什么是 LLM Wiki

1. 基本概念

LLM Wiki 是一种由大模型帮助创建和维护 Wiki 知识库的方法。它不是让用户手工编写所有 Wiki 页面，而是让 LLM 阅读原始资料，将知识整理成相互关联的 Markdown 页面，并随着新资料加入不断更新。

它主要解决的问题是：普通 RAG 每次回答问题时，都要重新从原始文档中寻找和拼接相关片段，之前完成的归纳和知识连接通常不会自动沉淀下来；LLM Wiki 则把整理结果保存为长期存在的知识成果。

当前讨论较多的 LLM Wiki 方法来自 Andrej Karpathy 在 2026 年 4 月 4 日发布的构想。它目前仍是较新的知识管理模式，工程标准和最佳实践尚未像 RAG 一样成熟。Karpathy 的 LLM Wiki 原始说明

2. 三层结构

一个典型的 LLM Wiki 包含三层：

原始资料层 Raw Sources
  ├─ PDF
  ├─ 网页
  ├─ 会议记录
  ├─ 代码和技术文档
  └─ 图片、表格等资料
          ↓ LLM 阅读、提取、归纳和连接
Wiki 知识层
  ├─ 主题页面
  ├─ 实体页面
  ├─ 概念页面
  ├─ 对比与总结
  └─ 页面之间的链接
          ↑
Schema 规则层
  ├─ 页面目录和格式规范
  ├─ 来源引用规则
  ├─ 新增与更新规则
  ├─ 冲突处理规则
  └─ 检查与维护流程

• 原始资料层是事实来源，通常保持原样，不由 LLM 修改。
• Wiki 知识层是 LLM 根据资料生成和维护的结构化知识。
• Schema 规则层告诉 Agent 应怎样整理资料、命名页面、保存来源、更新旧结论和处理矛盾。

3. 资料进入 Wiki 时发生什么

加入一份新资料
  ↓
LLM 阅读并提取重要事实、概念和实体
  ↓
检查 Wiki 中是否已有相关页面
  ├─ 没有：创建新页面
  └─ 已有：更新、补充或标记冲突
  ↓
增加页面之间的双向链接
  ↓
保存原始来源、处理时间和修改记录

例如导入多篇 RAG 论文后，系统可能形成：

wiki/
├── index.md
├── RAG.md
├── 文档分块.md
├── 向量检索.md
├── 混合检索.md
├── Reranker.md
├── GraphRAG.md
└── RAG评测.md

当新论文对已有结论提出不同观点时，LLM 不只是保存一个新文档块，还要修改相关主题页，并记录不同来源之间的差异。

4. LLM Wiki 的查询方式

小型 Wiki 可以从 index.md 开始，让 Agent 根据页面标题和简介找到相关页面；规模增大后，可以加入：

• 文件名和关键词搜索；
• BM25 全文检索；
• 向量语义检索；
• 页面链接和知识图关系检索；
• Reranker 重排序。

因此，LLM Wiki 并不意味着完全没有检索。它与 RAG 的主要区别在于：检索对象可以是已经整理好的知识页面，而不只是原始文档切块。现有开源实现也常组合全文、图关系和可选向量检索。LLM Wiki 开源实现与技术架构

5. LLM Wiki 的优势

• 知识可以持续积累，不必每次问答都从头归纳。
• 页面可由人直接阅读、检查和修改。
• 适合表达概念、人物、事件以及它们之间的关系。
• 适合跨多篇资料形成长期总结和研究脉络。
• Markdown 文件容易使用 Git 做版本管理、差异比较和回滚。
• Agent 可以把一次有价值的分析重新写回 Wiki，成为后续任务的知识。

6. LLM Wiki 的主要风险

• LLM 在整理阶段产生的错误可能被保存下来，并影响后续页面。
• 新资料加入时，可能没有正确更新所有相关页面。
• 同一事实可能被复制到多个页面，之后发生内容漂移。
• Wiki 的总结可能丢失原文中的限定条件、数字或例外条款。
• 生成和维护页面需要额外的 LLM 调用，导入成本较高。
• 企业场景中必须继承原始资料的访问权限，不能让 Wiki 合并后突破权限边界。

因此，Wiki 页面应当保存来源、更新时间、版本以及必要的审核状态。重要事实的最终回答仍应回到原始资料验证。

---

二、什么是 RAG

RAG 是 Retrieval-Augmented Generation，即检索增强生成。它在回答问题前从外部知识库中检索相关资料，并把这些资料作为上下文交给大模型生成回答。

典型流程如下：

文档导入阶段
文档 → 解析 → 分块 → Embedding → 向量库/搜索引擎

问题回答阶段
用户问题 → 查询改写 → 检索 → 重排序
        → 拼接相关原文 → LLM 生成 → 返回答案与引用

RAG 的核心价值是让模型使用私有、专业或最新资料回答问题，同时保留对原始资料的引用能力。现代 RAG 方法源自 2020 年的经典研究，经过多年发展，向量检索、混合检索、Reranker、评测和可观测性工具已经相对成熟。RAG 原始论文

RAG 的优势

• 原始文档是直接事实来源，比较容易提供引用。
• 新增或删除资料后，可以更新相应索引，不必重新整理完整知识体系。
• 适合海量文档和经常更新的资料。
• 对数字、条款、时间、产品参数等精确信息更加友好。
• 组件和工程生态相对成熟。

RAG 的主要风险

• 文档分块不合理可能把完整语义切断。
• 检索器可能没有召回真正需要的片段。
• 相似度高不代表资料能回答当前问题。
• 跨多篇资料的复杂问题可能需要多轮检索和推理。
• 每次提问都要执行检索和上下文拼接，之前的综合分析通常不会自然沉淀。

---

三、LLM Wiki 与 RAG 的核心对比

对比维度	RAG	LLM Wiki
知识处理时间	主要在查询时检索和组合	主要在导入时提前整理和连接
主要知识形态	原始文档切块	结构化 Wiki 页面
事实来源	原始文档片段	Wiki 页面，必要时回溯原始资料
精确引用	相对直接	必须专门维护页面到原始资料的引用
多文档综合	每次查询重新组合	综合结果可以长期保存
数据更新	更新文档和索引	更新资料后还要维护受影响的页面
数据规模	更适合大规模语料	更适合中小规模、高价值、长期积累的知识
人工阅读	原始切块不适合作为完整笔记阅读	Wiki 页面可以直接作为知识库阅读
导入成本	解析和向量化为主	需要 LLM 生成、合并、交叉引用和检查
查询成本	每次检索，复杂问题可能多次检索	已整理知识可减少重复归纳，但仍可能需要搜索
主要错误	检索不到、检索错误、上下文不完整	生成错误、知识漂移、更新不完整
工程成熟度	较成熟	较新，仍在快速演进

---

四、怎样进行技术选型

1. 优先选择 RAG 的场景

• 企业客服和内部知识问答；
• 政策、制度、合同和产品手册查询；
• 知识库规模较大；
• 原始资料更新频繁；
• 回答必须给出原文证据；
• 经常查询精确数字、日期、参数和条款；
• 对审计、权限和数据删除要求较高。

例如：

"退款制度第 12 条具体是什么？"
"产品 A 当前支持哪些操作系统版本？"
"这份合同的付款期限是多少天？"

这些问题最好直接检索原始文档并引用对应段落。

2. 优先选择 LLM Wiki 的场景

• 个人知识库和第二大脑；
• 课程笔记和长期学习；
• 论文阅读、行业研究和竞品分析；
• 项目文档和代码知识整理；
• 经常需要跨资料总结概念和关系；
• 希望整理结果能够持续积累并由人直接阅读；
• 原始资料数量可控，且能够进行人工抽查。

例如：

"这些论文对混合检索的观点有什么变化？"
"过去三个月这个项目做过哪些架构决策？"
"把课程中出现的缓存方案整理成知识体系。"

这类问题的价值在于持续积累和组织知识，适合写入 Wiki。

3. 快速决策表

你的主要需求	建议方案
从大量文档中准确回答具体问题	RAG
回答必须引用原文	RAG
数据每天或实时变化	RAG
整理学习资料并长期积累	LLM Wiki
建立概念、实体和主题之间的关系	LLM Wiki
既要形成知识体系，又要保证答案有原文依据	LLM Wiki + RAG
目前无法确定	先做 RAG，再增加 Wiki 派生层

4. 决策流程

回答是否必须以原始证据为依据？
  ├─ 是 → 以 RAG 为基础
  └─ 否
       ↓
是否需要长期积累跨资料的总结与关系？
  ├─ 是 → 考虑 LLM Wiki
  └─ 否 → 普通全文搜索或 RAG 通常足够

如果两个答案都是"是"
  → 使用 LLM Wiki + RAG 混合架构

---

五、推荐的混合架构

对于正式知识系统，更稳妥的设计是保留两条知识处理链路：

                         ┌→ 分块 → Embedding → 原始资料索引 ─┐
原始资料 → 解析与权限处理 ┤                                  ├→ 查询路由 → LLM 回答
                         └→ LLM 整理 → Wiki 页面与关系索引 ─┘

两层的职责分别是：

原始资料 + RAG：事实层
Wiki：知识组织和综合分析层

查询路由可以采用以下规则：

问题类型	查询路径
数字、条款、日期、原文内容	优先检索原始资料
概念介绍、关系分析、主题总结	优先查询 Wiki
跨资料综合且要求证据	Wiki 提供结构，RAG 补充原始证据
涉及实时业务数据	查询业务数据库或 API，不直接使用静态 Wiki 回答

最终回答中，Wiki 可以帮助模型确定"应该关注哪些概念和关系"，RAG 则提供可以引用和核验的原始片段。

---

六、技术组件选择

1. RAG 基础组件

文档解析：PyMuPDF、Unstructured、MinerU 等
文本分块：递归分块、标题分块、语义分块
Embedding：云端 Embedding 或本地向量模型
向量存储：pgvector、Qdrant、Milvus 等
全文检索：Elasticsearch、OpenSearch 等
重排序：Reranker 模型
API：FastAPI
缓存：Redis
评测：自建评测集 + 检索和回答指标

选择向量存储时可以从现有基础设施出发：

• 已经使用 PostgreSQL、数据规模不大：优先评估 pgvector；
• 强调关键词与向量混合检索：优先评估 Elasticsearch/OpenSearch；
• 向量规模较大或检索能力要求较强：评估 Qdrant、Milvus 等专用向量库。

2. LLM Wiki 基础组件

原始资料目录：raw/
Wiki 页面：Markdown 文件
规则文件：AGENTS.md、CLAUDE.md 或独立 schema.md
版本管理：Git
人工阅读：Obsidian 或普通 Markdown 编辑器
基础搜索：文件名、grep、ripgrep、BM25
增强搜索：向量检索、图关系检索、Reranker
维护任务：ingest、query、lint、review

小规模 Wiki 不必一开始就部署向量数据库，可以先使用清晰的目录、index.md 和全文搜索。页面增多、搜索效果下降后，再增加向量和图检索。

---

七、评测指标

RAG 重点评测

• Recall@K：正确资料是否被召回；
• Context Precision：召回内容中有多少真正相关；
• Faithfulness：回答是否由检索资料支持；
• Citation Accuracy：引用是否对应正确原文；
• 无答案拒答率：资料中没有答案时能否正确拒答；
• 延迟和单次查询成本。

LLM Wiki 重点评测

• 来源覆盖率：重要原始资料是否被正确整理；
• 事实可追溯率：Wiki 中的重要结论是否能定位到来源；
• 更新正确率：新增资料后是否修改了所有相关页面；
• 冲突发现率：不同来源矛盾时能否被标记；
• 陈旧内容比例：已经失效但仍保留的结论有多少；
• 孤立页面比例：没有入口或关联的页面有多少；
• 人工审核通过率和单份资料导入成本。

不能只用"回答看起来不错"作为评测标准。两种方案都应准备带标准答案和来源的测试集，持续执行回归评测。

---

八、学习与落地建议

对于正在学习知识库工程的人，建议按以下顺序推进：

第一阶段：标准 RAG
文档解析 → 分块 → Embedding → 检索 → Reranker
→ Prompt → LLM → 引用 → 评测

第二阶段：结构化知识
为文档增加来源、主题、实体、版本和权限元数据

第三阶段：LLM Wiki
让 LLM 创建和更新 Markdown 页面
→ 保存来源 → 建立链接 → 检查冲突和陈旧内容

第四阶段：混合架构
问题分类 → Wiki 查询 / 原始资料 RAG
→ 合并知识结构和原始证据 → 生成最终回答

最终选型原则是：

企业事实问答优先以 RAG 为基础；个人学习、研究和长期知识沉淀可以使用 LLM Wiki；既需要知识组织又需要事实可靠性的系统，采用"Wiki 组织知识，RAG 验证事实"的混合架构。