Wiki知识库和RAG知识库有什么区别？团队选型前先看清适用场景

团队要建知识库时最容易卡在第一步：工具已经选好，内容也有一堆，却说不清自己要的是「给人翻的文档站」还是「给模型查的资料库」。这篇不讲概念史，只给一张对照表和三步决策顺序，帮你在动手之前把适用场景划清，避免花两周搭好一套根本用不上的东西。

团队要建知识库时最容易卡在第一步：工具已经选好，内容也有一堆，却说不清自己要的是「给人翻的文档站」还是「给模型查的资料库」。这两件事经常被混着叫「知识库」，实际从内容单位、维护方式到出错后果都不一样，选错方向白花的时间往往以周计。

下面不讲概念史，只给一张对照表、一组判断标准和三步决策顺序。你不需要先懂向量、切片这些词，只要先回答一个问题：这份资料最终是谁在看——是人，还是模型。答案基本就定了方向；如果两边都沾，那要解决的是同步机制，不是选型。

叫法一样，但两件事根本不是一回事

wiki 知识库的核心是「人写、人读、人维护」，产物是能分享链接、能挂目录、能看历史的页面；RAG 知识库的核心是「切好、存好、能被检索到」，产物是向量库加一条查询链路。前者交付的是文档本身，后者交付的是一个「问一句拿答案」的入口，文档只是原料。

内容单位

wiki 是「页」，一页讲一件事；RAG 是「片段」，切成多大直接决定答得准不准

使用者

wiki 的读者是人，会跳读、会翻目录；RAG 的使用者是模型，只会按召回结果作答

出错表现

wiki 找不到时人知道去哪翻；RAG 找不到时可能仍然给一个看起来很像的答案

判断方法很直接：问一句「这份资料最终是谁在看」。答案是人，优先 wiki；答案是模型或问答入口，才轮到 RAG。不适用的情况也要说清楚——如果文档量极少、问题又高度固定，直接把要点写进提示词可能比两者都省事，不必为了「上知识库」而上知识库。

什么情况下该选 wiki，什么情况下该选 RAG

• 选 wiki：内容需要评审与版本记录、有清晰目录结构和责任人，比如制度、流程、新人手册。
• 选 RAG：问题零散、内容更新快、使用者只想拿结论，比如参数查询、常见问答、内部规范检索。
• 两者叠加：以 wiki 作为唯一内容源头，再加一层检索，是多数团队最终会走的形态；难点在同步机制，不在工具选型。
• 先别选：源头文档本身没人维护、内容互相矛盾时，先修源头，任何工具都救不了脏语料。

内容形态决定了维护成本差在哪

wiki 的内容单位是「页」，一页讲清一件事，人可以跳读、可以只看结论段；RAG 的内容单位是「片段」，切分方式和标题层级会直接影响召回质量。同一份材料，按人读的方式排版和按机器切片的方式排布，结果差别很大，很多答案不准的锅其实在切片，不在模型。

维护成本也完全不同。wiki 靠人工整理和目录运营，工作量集中在「写」和「定期更新」；RAG 靠切分策略、去重和更新节奏，工作量集中在「清洗」和「入库」。语料一旦脏，换模型也救不回来，所以半结构化内容——表格、扫描件、多版本并存的文件——进 RAG 之前必须先做格式转换和去重。

1. 先盘点内容形态把现有资料按「纯文本 / 表格 / 扫描件 / 多版本并存」分类，统计各类占比，占比高的那类决定你的主要工作量在哪。
2. 再决定入库前处理扫描件先做格式转换，表格确认表头和字段是否稳定，多版本先定哪一版为准；转换和检查可以用 本地工具箱（/tools） 里的工具过一遍。
3. 最后才谈切片按标题层级切成语义完整的片段，避免把一句话或一个表格拦腰截断；切完抽十条真实问题试召回，看拿到的片段是否真能支撑答案。

检索与作答：一个给人找路，一个替人回答

wiki 的搜索是关键词匹配加目录导航，找不到时人知道换词、知道去哪一栏翻；RAG 是语义相似度召回，它的优势是「换个说法也能找到」，风险是「找不到时仍然自信作答」。这两者的体验差异不是好坏问题，是责任归属问题——前者把判断交给人，后者把判断交给了链路。

所以判断标准可以写成一句：如果你无法接受「答错但语气很肯定」，就必须给 RAG 配上引用来源和人工兜底入口，或者先退回 wiki。这不是否定 RAG，而是承认它的出错方式更隐蔽，需要额外的验证设计。

• 准备一批真实问题做对照测试，不要只用你熟悉的几个问题，要包含用户真实会问的模糊表达。
• 看召回内容是否真的支撑答案，而不是只看回答读起来顺不顺；顺而不准是最危险的组合。
• 给每个答案保留原文出处链接，让人能一键回到 wiki 页面核对。
• 设一个人工兜底入口，答不出来时能转给具体负责人，而不是让用户自己猜。
• 把答错的样本单独收集起来，定期回看，它们比答对的样本更有信息量。

钱和人力分别花在哪

wiki 的成本主要在人的时间：写、评审、定期更新，软件本身往往很便宜甚至免费，真正的支出是「谁抽时间维护它」。RAG 的成本分三块：入库与切片的一次性投入、每次问答的检索与生成开销、以及长期维护语料新鲜度的持续投入。第三块最容易被低估。

算账时别只算调用费，把「语料谁维护、多久更新一次」折算成人时，很多团队会发现这才是大头。具体单价口径各家中转与官方都有差异，别用记忆里的数字做预算，到 官方 API 价格（/official-api） 和 价格追踪（/price-watch） 页面核对当时的数字更稳妥。

权限与数据边界上的差异

wiki 天然可以按页、按空间分权，谁能看哪个目录是清楚的；RAG 的权限控制更难，因为片段被混在一起检索，很容易把 A 部门的内容答给 B 部门。这不是配置一下就完事的问题，而是要在入库阶段就决定哪些内容根本不进检索库。

做法上先做数据分级，再决定去向：公开级可以进检索库，内部级要绑定访问身份，敏感级干脆只留 wiki 页面、不切片。涉及客户信息、合同、薪酬这类内容时，边界判断可以参考 安全与合规（/safety） 里的说明。不适用的场景也说清楚：全员公开、没有敏感信息的小团队内部问答，可以先不做细粒度权限，等人多了、内容杂了再加。

三步决策顺序：照着走一遍再动手

1. 列出十个真实问题每个问题标注三件事：使用者是谁、多久问一次、答错的代价有多大。代价高的那几条，直接决定你需要多严的验证机制。
2. 判断源头是否稳定内容源头是否唯一、是否已有稳定维护人。源头不稳就先修源头，别急着上检索；这一步没过，后面全是返工。
3. 做小范围对照试点同一批问题分别用 wiki 检索和 RAG 跑一遍，比较「找到」和「答对」两个指标。找到但答错，说明切片或语料有问题；两个都不行，说明问题在源头。

这三步的价值在于：它让你在花两周搭系统之前先花两小时想清楚。试点范围越小越好，五到十个人、一批真实问题就够，重点不是跑通，而是拿到「哪种方式更贴合我们实际使用」的证据。

已经有一边了，怎么补齐另一边

多数团队不是从零开始，而是手里已经有一边。从 wiki 补 RAG 时，先把页面按主题合并去重、统一版本，再切片入库，并且保留原文链接让人能回溯核对；从 RAG 补 wiki 时，把高频被问到、答案稳定的问题沉淀成固定页面，反向减少检索压力，也方便新人自查。

• 定一个「谁负责更新」的具体人名，不要写成「相关同事」。
• 定一个检查周期，例如每季度回看一次过期内容，节假日前额外扫一遍。
• 把高频问答沉淀回 wiki，让检索库只服务那些不好写成固定页面的问题。
• 每次更新语料后抽几条老问题重跑，确认没有把原来答对的搞坏。
• 记录答错样本和对应负责人，半年后回看这批样本，比看总量更有用。

无论走哪条路，都要接受一个现实：知识库不是搭完就结束的项目，而是一个需要有人定期打理的长期资产。工具选型只是开头，真正决定它半年后还能不能用的，是更新规矩有没有落地。