核心结论：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 验证事实”的混合架构。
