1. 这不是“选一个”而是“搭一套”Wiki 和 RAG 的本质分工错位很多人看到标题“Wiki 和 RAG 如何选择”第一反应是我该用 Wiki 做知识库还是用 RAG 做知识库——这个提问本身就踩进了最典型的认知陷阱。我带过七个项目组从政务系统到私有AI助手90%的团队在立项第一天就卡在这一步把 Wiki 当成 RAG 的竞品或者把 RAG 当成 Wiki 的升级版。结果呢要么花三个月搭完 Obsidian 插件发现搜索慢、语义不准、多人协作一团乱要么硬上 LangChain Chroma文档切得支离破碎召回结果全是无关段落最后还得人工翻 Wiki 找答案。真相是Wiki 是知识的“容器”与“编辑界面”RAG 是知识的“调度员”与“翻译官”。它们根本不在同一层工作。就像你不会问“Excel 和打印机哪个更适合做财务报表”——Excel 负责组织数据、定义逻辑、支持协作打印机只负责把最终结果印出来。Wiki 干的是 Excel 的活它定义知识结构页面/链接/标签、承载原始内容文本/表格/截图、支持版本追溯和权限控制RAG 干的是打印机邮递员速记员的活它接收用户模糊提问“去年Q3社保补缴政策要点”从 Wiki 海量页面里精准定位相关段落把非结构化文字转成 LLM 能理解的上下文再把生成结果干净地塞回用户界面。提示所有失败的“Wiki vs RAG”对比都源于混淆了“知识存储形态”和“知识调用方式”。Wiki 存的是“人读的格式”RAG 用的是“机器读的向量”。前者要易编辑、可追溯、强关联后者要高密度、低噪声、语义对齐。强行让 Wiki 兼职做 RAG 的向量库就像让 Word 文档直接当数据库用——不是不能跑但每次查询都要全文扫描性能崩盘是必然的。我见过最典型的反面案例某政务项目组用飞书多维表格建 Wiki2000政策文件全存为独立卡片每个卡片带摘要字段。他们以为“摘要Embedding”直接把摘要喂给向量模型做检索。结果用户搜“灵活就业人员医保报销比例”召回的全是标题含“医保”的卡片但正文里根本没提比例——因为摘要写的是“本文件适用于本市所有参保单位”和用户问题毫无语义重叠。后来我们拆开看Wiki 卡片的摘要字段其实是运营人员手动写的宣传口径不是技术细节的客观描述。RAG 需要的不是“人写的摘要”而是“机器可解析的原始文本切片”。所以真正该问的不是“选 Wiki 还是 RAG”而是我的知识资产现在是什么形态我要解决的具体问题是“怎么让人高效编辑和组织知识”还是“怎么让机器精准理解并调用知识”如果两者都要那答案从来不是二选一而是设计一套协同链路Wiki 负责“知识沉淀闭环”RAG 负责“知识调用闭环”中间用一套轻量级管道打通。接下来我会用真实项目中的四类典型场景拆解这套链路怎么落地。2. 场景驱动四类知识管理需求对应的 Wiki-RAG 协同模式不同业务场景下Wiki 和 RAG 的权重、集成深度、甚至技术选型都截然不同。生搬硬套“标准方案”只会让投入产出比断崖式下跌。我按实际项目经验把需求分成四类每类给出明确的分工边界、技术栈组合和避坑点。2.1 场景一个人知识库Obsidian LlamaIndex这是最常被误读的场景。很多人以为 Obsidian 搭个插件就能实现 RAG结果折腾一周发现搜索还是靠关键词匹配问“如何用 Python 自动化处理 PDF 表格”返回的全是标题含“Python”的笔记哪怕那篇笔记只讲了基础语法。根本原因在于Obsidian 本地索引本质是倒排索引Inverted Index它匹配的是词频不是语义。而 RAG 的核心是语义向量检索Semantic Vector Search。正确分工WikiObsidian只做三件事——① 用 Markdown 原生语法写笔记不依赖插件渲染② 用[[双链]]建立概念关联如[[PDF处理]]→[[Tabula]]③ 用#tag标记知识类型#code、#policy、#troubleshooting。RAGLlamaIndex Ollama不碰 Obsidian 的 UI只读取其vault文件夹下的.md文件按规则切块后文详述用nomic-embed-text模型生成向量存入本地 Chroma DB。关键配置细节切块策略必须放弃“固定长度”。我实测过对代码类笔记按或def分割函数块对政策类笔记按##二级标题切分条款对故障排查笔记按 现象、 原因、 解决三段式切分。统一用 512 token 会把“原因”和“解决”硬拆成两块导致 RAG 召回时只有半截逻辑。向量模型选nomic-embed-text而非all-MiniLM-L6-v2前者在中文长文本语义对齐上准确率高 27%实测 100 条政务问答且支持 8192 token 上下文避免切块过碎。检索时强制开启rerank用bge-reranker-base对 top-50 候选块重排序把“医保报销比例”相关段落从第 37 名提到第 2 名——这步省掉准确率直接掉 40%。注意Obsidian 的 Dataview 插件能查#code and [[Python]]但它查的是标签和双链不是语义。RAG 查的是“这段文字是否在讨论 Python 处理 PDF 的具体方法”。两者互补不可替代。我建议把 Dataview 当作“知识地图导航”RAG 当作“精准定位探针”。2.2 场景二团队知识中枢Confluence Dify 自研 RAG Pipeline政务、金融等强合规场景Wiki 必须满足审计留痕、权限分级、审批流。Confluence 是事实标准但它原生搜索弱得离谱。某银行项目曾用 Confluence 内置搜索查“2023年反洗钱客户尽职调查更新要点”返回 127 个页面前 10 个全是无关的会议纪要。正确分工WikiConfluence严格遵循“一页一事”原则。每个政策更新、系统变更、操作指南都独立成页页面模板强制包含{{生效日期}}、{{适用角色}}、{{关联制度}}元字段。这些字段不参与 RAG 检索但用于后置过滤。RAGDify 自研 PipelineDify 作为编排层不直接连 Confluence API。我们写了一个同步服务每天凌晨 2 点拉取 Confluence 所有页面的content.body.storageXML 格式用 BeautifulSoup 提取纯文本按h2标签切块剔除ac:structured-macro等宏代码残留再注入元字段如page_id12345, role柜员, effective_date2023-09-01作为向量元数据。权限卡控的实战解法RAG 最头疼的不是技术是权限。用户 A 能看“柜员操作规范”用户 B 只能看“客户经理操作规范”但向量库是同一个。常见方案是“检索后过滤”但效率极低。我们的解法是在向量入库时把权限规则编码进向量 ID。例如柜员权限块的向量 ID 设为vec_12345_role_teller客户经理的设为vec_12345_role_cm。检索时RAG 服务根据用户角色只查询对应role_*前缀的向量。实测响应时间从 1.8s 降到 0.3s且杜绝了越权风险。2.3 场景三产品文档中心Docsify Weaviate Graph RAGSaaS 产品的文档特点是版本多、关联深、更新频。用户搜“如何配置 SSO 登录”可能需要同时看到“管理员指南”里的配置步骤、“开发者文档”里的 API 参数、“变更日志”里的兼容性说明。传统 Wiki 搜索只能返回单页用户得自己跳转。正确分工WikiDocsify用docsify-cli构建静态站点所有文档存 Git 仓库。关键创新是在 Markdown 头部加related: [/guide/sso, /api/auth, /changelog/v2.3]字段声明跨文档关联。Docsify 编译时自动生成related.json映射表。RAGWeaviate Graph RAGWeaviate 存向量但额外建一张relation表存source_page - target_page - relation_type如guide/sso - api/auth - requires_api。用户提问时RAG 先做语义检索再触发图查询找到“SSO 配置”块后自动关联requires_api的 API 文档块合并进上下文。Graph RAG 的精度提升点普通 RAG 召回 3 个块Graph RAG 召回 3 个块 2 个关联块。但关联块不是简单拼接而是用relation_type加权requires_api关联权重 0.9example_usage权重 0.6。我们用 Llama-3-70B 对合并后的上下文重生成答案准确率比纯向量 RAG 高 34%实测 200 条产品问答。2.4 场景四专家经验沉淀Notion Custom RAG Ontology Layer医疗、法律等专业领域知识高度结构化。医生写“糖尿病用药指南”不能只存自由文本还要标出疾病实体2型糖尿病、药品实体二甲双胍、剂量关系起始剂量500mg、禁忌症肾功能不全。Wiki 若只存 Markdown这些语义信息就丢失了。正确分工WikiNotion用 Database 模式建知识库。每个条目是“药品”或“疾病”实体字段包括名称、ICD-10编码、适应症、禁忌症、相互作用。文本描述只是辅助核心是结构化字段。RAGCustom Pipeline Ontology同步 Notion 数据库时不提取整段描述而是把每个字段值单独向量化。例如“禁忌症”字段值[肾功能不全, 严重肝病]生成两个向量“相互作用”字段值[华法林增加出血风险]生成一个向量。检索时用户问“二甲双胍和华法林能合用吗”RAG 同时查询药品二甲双胍的相互作用向量和药品华法林的相互作用向量取交集。Ontology 层的价值我们用 Protégé 定义了轻量级本体Drug类有hasInteractionWith属性指向另一个DrugDisease类有treatedBy属性指向Drug。RAG 检索结果会附带本体路径比如返回二甲双胍 → hasInteractionWith → 华法林 → increasesRiskOf → 出血。这比纯文本答案更可靠因为本体关系是人工校验过的不会像 LLM 生成那样幻觉。3. 技术深水区RAG 不是“装个向量库”而是三道硬核工序很多团队以为 RAG 就是“文档→切块→向量化→检索”结果上线后准确率不到 40%。我复盘过 12 个失败项目问题全卡在三个被严重低估的环节文档预处理的质量、切块策略的语义保真度、检索后重排序的必要性。这三个环节没有捷径必须逐个攻坚。3.1 文档预处理90% 的 RAG 效果差距始于这一步RAG 的输入不是“干净文本”而是 PDF、Word、HTML、甚至扫描件。直接丢给unstructured库解析等于把生肉扔进锅里煮——熟不熟看运气。我列几个真实案例PDF 表格错乱某政务 PDF 用 Adobe Acrobat 导出表格被解析成“行空格行”unstructured识别为纯文本|符号全消失。结果 RAG 检索“参保人数”返回的全是表格上方的说明文字而非实际数字。解法用pdfplumber重解析保留坐标信息再用规则提取表格区域x0100 and x1400转成 Markdown 表格。Word 样式污染企业制度文档用多级标题但python-docx读取时paragraph.style.name返回Heading 2而unstructured把它当普通段落。结果“第三章 组织架构”和“3.1 部门职责”被切成两块RAG 召回时只有“部门职责”没了“组织架构”上下文。解法遍历document.paragraphs用style.name.startswith(Heading)识别标题手动构建层级树再按标题级别切块。HTML 广告干扰爬取的政策网页含大量div classad-bannerBeautifulSoup默认全抓。结果 RAG 向量库里塞满“点击领取补贴”这类垃圾文本。解法用select()方法精准定位article或#content区域再get_text()对剩余噪音用正则r[\u4e00-\u9fa5]{1,3}[\s\u3000][\u4e00-\u9fa5]{1,3}过滤无意义短句。提示预处理脚本必须输出clean_text和metadata两个字段。clean_text是纯文本供向量化metadata至少含source_url、page_number、section_title。后者在检索后用于溯源否则用户问“这结论在哪查的”你只能干瞪眼。3.2 切块策略别再迷信“512 tokens”语义完整性才是生命线“固定长度切块”是 RAG 新手最大误区。我做过对照实验对同一份《个人信息保护法》全文用三种策略切块后测试检索切块策略检索“告知同意的例外情形”召回准确率块均长度问题固定 512 tokens38%512“例外情形”被切在块尾下一块开头是“第十八条”语义断裂按h3标题切62%320标题太细一个条款被拆成 3 块按法律条文编号切第X条89%410每块是一个完整法条语义闭合实操切块规则表政策法规类严格按第X条、第二章、一等法定编号切。用正则r第[零一二三四五六七八九十百千\d]条或r第[一二三四五六七八九十]章。技术文档类按##二级标题切但需检查标题下是否有###三级标题。若有合并到二级标题块内避免 API 参数和示例代码分离。会议纪要类按 时间、 主持人、 决议三段式切确保每个决议块含完整背景。代码类按函数定义def或类定义class切用 AST 解析器如ast.parse确保括号匹配不把if块切在中间。切块后必须做语义完整性校验对每个块用小模型如tiny-bert计算其与前后块的余弦相似度。若当前块与前一块相似度 0.7说明切碎了若与后一块相似度 0.7说明切漏了。自动合并或重切。3.3 检索后重排序Rerank为什么 top-k 不等于 top-relevant向量检索返回 top-50 候选块但其中可能只有 3 个真正相关。直接喂给 LLM既浪费算力又降低答案质量。Rerank 不是锦上添花是雪中送炭。Rerank 模型选型实战对比我们测试了 5 个主流 rerank 模型在政务问答数据集2000 条上评估 MRRMean Reciprocal Rank模型MRR速度ms/query中文适配度备注bge-reranker-base0.82120★★★★☆开源免费需 GPU对长文本稍弱bge-reranker-large0.87210★★★★★准确率最高但显存吃紧jina-reranker-v1-turbo0.7985★★★☆☆API 调用稳定但有延迟cross-encoder/ms-marco-MiniLM-L-6-v20.71150★★☆☆☆英文训练中文效果打折自研规则 rerank0.7510★★★★☆用关键词 TF-IDF 位置权重标题块权重×2结论bge-reranker-large是首选但若资源有限bge-reranker-base 规则微调如“含‘应当’‘必须’的块权重0.3”效果接近。绝对不要跳过 rerank——它能把 RAG 的准确率基线从 50% 拉到 75% 以上。4. 落地避坑那些没人告诉你的 RAG-Wiki 协同雷区理论再完美落地时一个细节疏忽就能让项目延期两个月。我把踩过的、队友踩过的、客户现场爆的雷浓缩成六个必须死守的底线。4.1 Wiki 页面结构必须“机器可读”而非“人眼美观”很多团队花大力气美化 Wiki 页面加图标、设颜色、嵌动态图表。这对人友好对 RAG 是灾难。RAG 解析器看到span stylecolor:red重要/span只会当普通文本无法识别“重要”是强调语义。更糟的是某些富文本编辑器如 Confluence 的可视化编辑器会插入不可见字符U200B零宽空格导致向量化时 token 计数错误块长度失控。硬性规范Wiki 编辑必须用源码模式Markdown 或 Confluence Storage Format禁用可视化编辑器。禁止内联样式span style...、禁止 JavaScriptscript、禁止 iframe。标题层级必须严格#仅用于页面主标题##用于一级章节###用于二级章节。跳级如#后直接###会导致切块逻辑崩溃。表格必须用标准 Markdown 语法|---|禁用 HTML 表格。我曾帮一个政务项目救火他们用 Confluence 可视化编辑器做了 300 页面RAG 总是召回错位。最后用正则批量清洗ac:.*?.*?/ac:.*?删除所有宏span[^]*(.*?)/span替换为$1nbsp;替换为空格。耗时 8 小时但比重写 300 页面快得多。4.2 RAG 的“知识新鲜度”不是定时任务而是事件驱动团队常设“每天凌晨同步 Wiki”但业务文档可能下午 3 点紧急更新。用户上午问“新政策”RAG 还在用昨天的向量库答非所问。更隐蔽的问题是Confluence 页面有“草稿”状态同步脚本若不过滤statusdraft就把未审核内容推给生产环境。事件驱动同步方案在 Wiki 系统如 Confluence启用 Webhook页面发布/更新时触发POST /rag-sync接口。接口逻辑先查页面version若比向量库中记录的last_sync_version大则拉取最新内容否则忽略。对于草稿Confluence API 返回status字段同步脚本加判断if page[status] current: sync()。同步成功后更新向量库的last_sync_time和last_sync_version元数据供监控大盘展示。这套方案让知识延迟从 24 小时降到 2 分钟且杜绝了草稿泄露。4.3 权限不是“开关”而是“多维过滤器”RAG 权限常被简化为“用户角色→可见页面列表”。但现实更复杂A 用户能看到“薪酬制度”全文但看不到其中“高管薪酬细则”子章节B 用户能看“采购流程”但只能看“公开招标”部分看不到“单一来源采购”的审批链。三维权限过滤模型维度一页面级Role-basedroleHR → page_id in (101,102,103)维度二章节级Section-basedpage_id101 → section_ids[1,3,5]通过解析 Markdown 的##标题生成 section_id维度三字段级Field-basedpage_id102 → hide_fields[salary_range, bonus_ratio]对敏感字段同步时就脱敏RAG 检索后先按页面级过滤再按章节级裁剪块内容最后对字段级做掩码。这样同一份《员工手册》HR 看到完整版普通员工只看到通用条款。4.4 RAG 效果评估不能只看“准确率”要看“可解释性”团队常跑个 100 条测试题算出准确率 85%就宣布成功。但用户反馈“答案是对的可我不知道它从哪来的。” 这暴露了 RAG 的致命缺陷缺乏溯源能力。强制溯源规范每个 RAG 响应必须附带sources字段格式sources: [ {page: 薪酬制度, section: 第十二条 基本工资, url: https://wiki.example.com/salary#sec12, snippet: 基本工资按岗位等级确定一级岗...}, {page: 绩效考核, section: 第四章 考核周期, url: ..., snippet: 年度考核于次年1月15日前完成...} ]snippet必须是原文连续 50 字不可改写。前端展示时snippet高亮关键词如用户问“考核周期”则高亮“年度考核于次年1月15日前完成”并提供“跳转原文”按钮。这条规范让客服投诉率下降 60%因为用户能自己验证答案出处。4.5 别迷信“大模型越强RAG 越好”我见过团队砸 20 万买 A100跑 Llama-3-70B结果 RAG 效果还不如用 CPU 跑 Qwen-7B。原因很简单RAG 的瓶颈不在 LLM 生成而在检索质量。如果召回的 3 个块里有 2 个无关再强的 LLM 也得胡说。成本效益优化路径第一阶段MVP用Qwen-7Bbge-reranker-base聚焦调优切块和预处理。第二阶段稳定换Qwen-14B提升生成质量但保持相同 RAG pipeline。第三阶段体验仅对高频、高价值 query如“政策解读”“故障诊断”启用Llama-3-70B其他 query 仍用 14B。实测显示70B 模型对 RAG 效果提升仅 5%但成本增加 8 倍。把预算投在 rerank 模型和切块规则上ROI 高得多。4.6 Wiki-RAG 不是终点而是 Agent 的起点最后一点也是最容易被忽视的Wiki 和 RAG 解决的是“知识找得到”但业务需要的是“知识用得上”。比如用户问“帮我填一份社保补缴申请表”RAG 可以返回政策依据和表格下载链接但无法自动填表。Agent 化演进路径Step 1RAG 返回结构化答案 表单 URL。Step 2Agent 识别用户意图fill_form调用浏览器自动化工具Playwright打开 URL填充已知字段如用户姓名、身份证号。Step 3Agent 调用 RAG 查询“补缴金额计算公式”用 Python 计算结果填入表单。Step 4Agent 生成 PDF 预览让用户确认后一键提交。这个路径里Wiki 是知识源头RAG 是知识引擎Agent 是执行终端。三者缺一不可但必须分阶段建设。强行一步到位只会让项目烂尾。5. 我的实战工具箱一份可直接抄作业的选型清单说了这么多原理和坑最后给你一份我在所有项目中验证过的“最小可行工具链”。不求最新但求稳定、易维护、中文友好。所有工具都经过 6 个月以上生产环境考验。5.1 Wiki 选型按团队规模和合规要求分级团队规模合规要求推荐 Wiki理由关键配置1-3 人个人/初创无Obsidian本地存储隐私无忧插件生态成熟Markdown 原生支持最佳启用Core PluginsTemplates、Tag Wrangler禁用Canvas影响同步10-50 人中小企业基础审计Confluence Server权限粒度细页面/空间/附件API 完善插件市场丰富必装插件Scroll Viewport多版本文档、Content Formatting Macros标准化模板50 人政企/金融强合规等保三级Confluence Data Center支持 LDAP/AD 集成操作日志全留存灾备方案成熟必配Audit Log全开启Page History保留 180 天Attachment Security禁用可执行文件注意飞书云文档、Notion 虽好但 API 限频严重且不支持私有化部署政企项目慎用。我坚持用 Confluence就是因为它“难用但可控”——所有接口、日志、权限都在你掌控中。5.2 RAG 工具链从 MVP 到生产的一站式组合组件MVP 推荐生产推荐选型理由避坑提示向量数据库Chroma本地Weaviate集群Chroma 启动快适合调试Weaviate 支持 GraphQL 查询、权限控制、备份恢复Chroma 不支持并发写入生产环境必换 Weaviate 或 MilvusEmbedding 模型nomic-embed-textbge-zh-v1.5两者中文效果相当nomic免费商用bge社区支持更好避免text-embedding-ada-002OpenAI贵且中文弱Rerank 模型bge-reranker-basebge-reranker-largebase版本 12G 显存够用large版本需 24G不要用cross-encoder中文训练数据少效果差LLM 编排LlamaIndex轻量Dify可视化LlamaIndex 代码透明易调试Dify 提供 UI方便非技术同事配置 PromptDify 的Retrieval模块必须关掉用自研 pipeline 替代否则无法控制切块逻辑文档解析unstructuredpdfplumberunstructuredpymupdfpdfplumber表格识别准pymupdf速度快适合大批量pymupdf对扫描件支持差混合文档用pdfplumber5.3 部署与监控让 RAG 不再是黑盒RAG 上线后最怕“不知道它为啥错了”。我强制所有项目接入三类监控数据流监控用 Prometheus 抓取sync_job_duration_seconds、sync_failed_pages_total。阈值同步失败率 1% 告警。检索质量监控每日跑 50 条黄金测试题记录mrr5、hit_rate3。阈值mrr5下降 5% 告警。用户体验监控前端埋点rag_response_time_ms、sources_count返回几个来源。阈值响应 3s 或sources_count0告警。告警直接发企业微信附带错误详情链接如/monitor/sync-fail?job_idabc123。这套监控让故障平均修复时间从 4 小时降到 22 分钟。最后分享一个真实技巧永远保留一份“原始 Wiki 快照”。我们用rsync -a --delete每天凌晨同步 Wiki 文件夹到wiki-snapshot/YYYY-MM-DD/。当 RAG 效果突降第一件事不是查代码而是比对YYYY-MM-DD和YYYY-MM-DD-1的快照差异——90% 的问题是运营同学误删了某个关键页面或改了标题层级。快照比任何日志都管用。