面试官爱问：RAG 和 LLM Wiki 到底什么区别？90% 的人第一句就答错

在 AI 应用面试里，有一个问题出现频率越来越高：

“RAG 和 LLM Wiki 有什么区别？” “我们已经有 Wiki 了，为什么还要做 RAG？” “RAG 能不能替代 Wiki？”

很多候选人一听到就懵：RAG 我知道，向量检索、知识库问答；LLM Wiki 是什么？是企业 Wiki 吗？它跟 RAG 不就是一个东西吗？

这篇文章用最直白的方式，把两者的本质、边界、适用场景和面试回答模板全部讲清楚。

一、先对齐概念：RAG 和 LLM Wiki 分别指什么

1、RAG：检索增强生成

RAG 全称是 Retrieval-Augmented Generation，中文叫“检索增强生成”。

它的核心思想很简单：

大模型本身的知识是“冻结”在训练参数里的，很多企业内部知识、最新信息、私域文档它不知道。于是我们在提问时，先从外部知识库中“检索”出相关内容，拼接到 Prompt 里，让大模型基于这些材料来生成答案。

一个典型 RAG 流程如下：

离线阶段

把企业文档（PDF、Word、网页、数据库记录等）加载进来
切分成一个个小的文本块，叫 chunk
用 Embedding 模型把每个 chunk 转成向量
存入向量数据库，如 Milvus、Pinecone、FAISS、Weaviate 等

在线阶段

用户提问：“公司年假怎么算？”
将问题也转成向量
在向量库中做相似度检索，召回最相关的 top-k 个 chunk
把这几个 chunk 拼进 Prompt，例如：“请根据以下资料回答：……”
大模型生成最终答案，并可以附上引用来源

RAG 本质上解决的是：

大模型知识过时
大模型不知道私有数据
大模型容易“幻觉”，需要外部证据
企业希望低成本、快速接入大量已有文档

2、LLM Wiki：面向大模型的结构化知识库

“LLM Wiki”这个词在业界并没有一个绝对统一的标准定义，但大多数语境下，它指的是：

一种以 Wiki 页面形式组织的、供大模型读取或检索的结构化知识库。

它可能是：

企业内部已有的 Confluence、Notion、MediaWiki、语雀、飞书知识库
专门为 AI 应用搭建的 Markdown 知识库
把核心制度、流程、FAQ、产品说明整理成一篇篇主题明确的页面

Wiki 的特点是：

人工整理： 由人编写、审核、维护
结构化强： 有标题、目录、层级、链接、标签
页面完整： 一个页面通常围绕一个主题讲清楚
版本可管理： 修改有记录，可以回滚
可读性强： 不仅机器能读，人也能直接阅读

当 LLM 使用 Wiki 时，一般有两种方式：

直接读取页面： 根据用户问题，找到对应的 Wiki 页面，把整个页面或部分章节作为上下文传给 LLM
Wiki 内搜索 + LLM 生成： 先搜索 Wiki，再让 LLM 基于搜索结果回答

所以，LLM Wiki 更偏向“知识管理”和“内容沉淀”，而 RAG 更偏向“检索技术”和“生成流程”。

二、核心区别：一张表看懂

维度	RAG	LLM Wiki
知识形态	非结构化/半结构化原始文档，如 PDF、Word、网页	结构化/半结构化页面，人工整理过
组织方式	自动切块，向量化，相似度检索	目录、层级、链接、标签、搜索
维护成本	低，接入快，但需要维护索引和更新流水线	高，需要专人编辑、审核、更新
检索粒度	chunk 级，通常 200-1000 token，精细但可能碎片化	页面级或章节级，信息完整但可能有冗余
知识质量	依赖源文档质量，可能包含噪声、矛盾、过时内容	经过人工筛选和整理，更权威、一致
答案可解释性	可追溯到具体片段，但来源可能是碎片	可追溯到完整页面，路径清晰
更新机制	重新抓取、切分、向量化，有一定延迟	编辑保存即可，版本可追溯
适用场景	海量文档、长尾问题、快速上线	核心制度、标准流程、高频 FAQ
典型技术栈	向量数据库、Embedding、Rerank、LangChain/LlamaIndex	Wiki 平台、搜索接口、页面解析、目录树
本质	一种“现用现查”的检索技术	一种“先整理后用”的知识管理方法

一句话总结：

RAG 是“从垃圾堆里翻出可能有用的纸片”，LLM Wiki 是“把重要内容写成一本本手册”。

三、深入拆解：为什么面试官爱问这个问题

面试官问这个问题，通常不是想听你背定义，而是想考察三点：

1、你是否理解 RAG 的本质不是“接个向量库”

很多候选人一说 RAG，就是“把文档扔进向量数据库，然后检索”。

但实际上，RAG 是一个完整的工程链路：

文档解析
清洗
切分策略
Embedding 模型选择
向量库选型
检索策略
Rerank
Prompt 拼接
引用溯源

如果连 Wiki 和 RAG 的区别都说不清，说明你对知识库问答的理解还停留在表面。

2、你是否具备“知识工程”的思维

面试官真正想听到的是：

不是所有知识都适合用 RAG 自动检索，也不是所有知识都值得人工整理成 Wiki。你需要根据知识的特点、更新频率、使用场景来选择合适的方案。

这体现的是候选人的架构能力和工程判断力。

3、你是否知道“RAG + Wiki”的混合架构

在实际生产中，很少只用一种方案。通常是：

用 RAG 覆盖大量非结构化文档，快速接入长尾知识
用 Wiki 沉淀高频、核心、需要稳定答案的知识
两者结合，通过路由分发或混合召回

如果你能主动提到混合架构，面试官会眼前一亮。

四、举个例子，立刻理解

假设你在一家互联网公司做智能客服。

你有以下知识资产：

50 个产品使用手册 PDF
200 篇历史工单记录
30 篇内部 Wiki 页面，包括“退款流程”“账号注销”“隐私政策解读”
10 个常用 FAQ

如果只用 RAG

把所有 PDF 和工单记录切块、向量化
用户问：“我要退款，怎么操作？”
系统从某个 PDF 的第 37 页召回了一段：“退款需在订单完成后 7 天内申请……”
但是这段话可能缺少前置条件、例外情况、最新政策更新
用户可能得到不够完整的答案，甚至漏掉“虚拟商品不可退款”的说明

如果只用 Wiki

用户问：“我要退款，怎么操作？”
系统找到 Wiki 页面“退款流程”
但用户问的是某个非常冷门的活动规则，Wiki 里没有写
系统就答不上来，或者只能让用户转人工

如果用 RAG + Wiki

用户问高频问题，优先匹配 Wiki 页面，答案完整、权威
用户问长尾问题，走 RAG 从大量文档中检索
回答时如果有 Wiki 页面命中，优先引用 Wiki，RAG 结果作为补充
这样既保证了核心问题的质量，又覆盖了长尾需求

这就是面试官想听到的答案。

五、RAG 的优缺点

优点

接入成本低：无需人工整理，只要文档在，就能快速建立知识库
覆盖范围广：海量文档都能覆盖，长尾问题也能找到可能相关的片段
更新自动化：文档更新后，重新抓取、切分、向量化即可
可追溯性：能给出具体来源片段，便于用户核实

缺点

检索精度问题：向量相似度不等于语义完全匹配，可能会召回不相关内容
上下文碎片化：chunk 可能切断完整逻辑，导致答案不完整
文档质量参差不齐：如果源文档本身有错、有矛盾，RAG 也会把错误信息喂给 LLM
答案稳定性差：每次检索结果可能不同，同一个问题可能得到不同的答案
需要调优：切分大小、Embedding 模型、Rerank 策略等都需要反复实验

六、LLM Wiki 的优缺点

优点

答案质量高：人工整理过的内容更权威、一致、完整
结构清晰：目录、链接、层级让知识更容易定位
可解释性强：直接指向某个页面，用户可以自己阅读
版本管理：可以追溯修改历史，回滚到任意版本
答案稳定：同一页面内容不变，LLM 生成的答案更稳定

缺点

维护成本高：需要专人编写、审核、更新
覆盖范围有限：不可能把所有文档都整理成 Wiki
更新有延迟：新知识需要人工整理后才能进入 Wiki
检索方式相对传统：如果 Wiki 平台搜索能力弱，可能找不到正确页面
页面冗余：一个页面可能很长，包含大量与当前问题无关的内容，影响 LLM 的生成效果

七、什么时候用 RAG，什么时候用 Wiki？

优先用 RAG 的场景

文档数量大，人工整理不现实
文档更新频繁，来不及维护 Wiki
问题类型长尾，无法预测用户会问什么
需要快速上线 MVP
知识源本身就是非结构化文档，如合同、报告、邮件

优先用 Wiki 的场景

高频问题，需要稳定、权威的答案
核心制度、流程、规范
需要人工审核和版本控制的敏感知识
知识本身结构化程度高，适合用页面组织
答案要求完整、无歧义，不能被碎片化

混合架构才是最佳实践

一个成熟的企业 AI 知识库，通常是：

Wiki 作为“官方知识层”： 核心知识、高频问题、标准答案
RAG 作为“长尾知识层”： 覆盖大量非核心文档
路由层： 根据用户问题，判断走 Wiki、RAG、数据库查询，还是三者结合
反馈层： 将 RAG 中反复出现的高频问题，沉淀成新的 Wiki 页面

这就是知识库建设的“飞轮效应”。

八、常见误区

误区一：认为 RAG 可以完全替代 Wiki

错。RAG 只是“检索”，不会自动整理知识。如果源文档质量差，RAG 输出的答案也会差。Wiki 的人工整理和审核价值不可替代。

误区二：认为 Wiki 就是 RAG 的一种

不准确。Wiki 是知识组织方式，RAG 是检索增强技术。Wiki 可以作为 RAG 的数据源，但两者不是包含关系。

误区三：觉得有了 LLM 就不需要 Wiki

错。LLM 会因为上下文窗口限制和幻觉问题，更需要结构化、权威的知识来源。Wiki 是 LLM 的“高质量燃料”。

误区四：所有文档都切成 chunk 扔进向量库就行

错。切分策略、元数据、结构化信息都会影响检索效果。很多文档更适合直接解析成结构化数据，而不是简单切块。

九、面试回答模板

30 秒简短版

RAG 是从非结构化文档中自动检索相关片段，拼接给大模型生成答案，优点是接入快、覆盖广，缺点是检索可能不准、上下文碎片化。LLM Wiki 是人工整理的结构化知识库，优点是答案质量高、稳定、可追溯，缺点是维护成本高、覆盖有限。实际生产中通常两者结合：核心知识用 Wiki 沉淀，长尾知识用 RAG 覆盖。

2 分钟完整版

首先，RAG 和 LLM Wiki 解决的是不同层面的问题。RAG 是一种检索增强技术，它把原始文档切块、向量化，根据用户问题做相似度检索，把最相关的片段塞给大模型生成答案。它的优势是能快速覆盖海量非结构化文档，适合长尾问题。缺点是受限于源文档质量和检索精度，答案可能不完整或不稳定。

LLM Wiki 则是以 Wiki 页面形式组织起来的知识库，通常由人工编写和维护。它的特点是结构化强、内容权威、版本可管理，答案更稳定、可解释性更好。但缺点是维护成本高，不可能覆盖所有长尾知识。

所以，两者不是替代关系，而是互补关系。常见做法是：用 Wiki 沉淀高频、核心、需要稳定答案的知识，用 RAG 覆盖大量非核心文档和长尾问题。同时可以加一个路由层，根据问题类型分发到 Wiki 或 RAG，甚至多路召回后合并。这样既保证了答案质量，又保证了覆盖范围。

十、最后总结

RAG 和 LLM Wiki 的区别，本质上可以归结为一句话：

RAG 是“从原始材料中现查现用”，LLM Wiki 是“把知识先整理成册再使用”。

面试时，不要只回答技术名词，更要展示你的知识工程思维：

哪些知识值得沉淀？
哪些知识适合自动检索？
如何设计混合架构？
如何通过反馈机制让知识库越用越好？

这才是面试官真正想听的。