1. 先说清楚:RAG 和 Wiki 各自解决什么问题1.1 RAG 解决“找答案”的痛我在过去一年多里反复被问到同一个问题:“我已经有了公司内部的 Wiki,但没人去看,一问事情还是得私聊,有没有办法让它自动回答?”这个诉求的本质,是“找答案”的成本太高。你可能有几百篇文档、几千个词条,信息都在,但人不知道自己要搜什么关键词、不知道答案在哪一页、甚至不知道自己该去哪个子目录找。这时候 RAG(Retrieval-Augmented Generation,检索增强生成)就派上了用场。它做的事情可以概括成三步:先把文档切成片段、让模型把片段转成向量存进向量库,当有人提问时,系统把问题也转成向量,在库里找最相关的几个片段,再把这些片段连同问题一起交给大模型,由模型根据片段内容组织答案并给出引用来源。我见过很多人把这个过程想玄了,其实它就是“先搜后写”。搜索部分负责把候选材料捞出来,生成部分负责把材料组织成通顺的答复。所以 RAG 的价值不是让大模型更聪明,而是让大模型的回答“有据可依”。1.2 Wiki 解决“长知识”的痛Wiki 的任务则是“长知识”。它解决的是知识的存量、组织与演进问题:今天你踩了一个坑,写下解决方案;明天同事踩了同一个坑,打开 Wiki 搜到你的记录,就能避开;三个月后这个方案过时了,你回到同一篇文档里修订。这是典型的长期复利型知识管理,由人维护,由人阅读,强调可靠、可回溯、可演进。但 Wiki 有一个天然的弱点:它要求读者主动去翻。没人会把公司 Wiki 当小说每天读,大多数人的行为是“遇到问题先私聊,私聊解决不了才去搜”。而私聊得到的答案往往是不完整的、没有上下文的,甚至过几天就被人遗忘。Wiki 的形式感越强、目录越深、词条越多,被真正读到的比例反而可能越低——这很反直觉,但确是很多知识库的通病。1.3 为什么两者天然互补RAG 增强了“查”的体验,Wiki 沉淀了“存”的资产。把 RAG 架在 Wiki 之上,等于给知识库装了一个“主动应答”的入口:人不用再去翻目录,直接问就好,系统替他完成检索、引用和整合;同时,答案的出处永远指向 Wiki 里的原文档,人想深究就可以点进去看完整上下文。我个人的判断是:未来的知识管理不是“要么 Wiki,要么 RAG”,而是“Wiki 负责长知识,RAG 负责把知识送到嘴边”。本文后面所有内容,都围绕这一句话展开。不管你是个人搭建笔记库,还是团队维护内部文档,这套思路都可以落地。2. 知识库底座:Wiki 应该如何组织才能喂给 RAG很多人以为 RAG 效果不好是模型或检索工具的问题,但我在实际项目里发现,60% 以上的问题出在源头——文档本身不适合被检索。Wiki 内容要喂给 RAG,不能像原来写给人看那样随意,需要在结构、命名、元数据三个层面做调整。2.1 页面结构与命名规范先说页面命名。传统的 Wiki 命名会带很强的层级语义,比如“运维手册/服务器管理/nginx/反向代理配置”,这样的名称对人有意义,但对模型语义匹配不友好。RAG 检索时,是对查询词和文档片段做相似度匹配,它更关注片段里“写了什么”,而不是它在目录里的位置。所以我建议在保留目录结构的同时,让每个页面的标题尽量用“名词场景”的写法,例如:好的页面名:Nginx 反向代理配置(含 HTTPS 卸载)不太好的页面名:技术笔记 0314另外一个容易忽略的点是短名和别名。如果 Wiki 支持别名或重定向,尽量给常用说法建别名,比如“反代”“nginx proxy”都能跳转到那篇配置文档。RAG 检索不到内容,很多时候不是内容不存在,而是同一个意思在文档里用了一种说法、在问题里用了另一种说法,语义检索不见得每次都能兜住这种差异。2.2 段落粒度与内容密度这一条是重点,直接决定 RAG 命中率。RAG 最常见的一种切片方式是“按固定长度切”,比如每 500 字切一段,这么做在很多场景下是可行的,但你的 Wiki 文档如果本身结构混乱,切出来的片段就是“语义碎片”:前半段在讲环境准备,后半段突然跳到排错案例,模型拿到这种片段根本没法组织答案。我给出的建议是:Wiki 写作时,尽量遵守“一段一主题、小节即切片单元”的原则。也就是说,你在 Wiki 里写文档时就想好——这篇文档大概会被检索系统切成几个独立片段,每个片段能不能独立回答一个问题?如果一个片段脱离全文后读起来莫名其妙,那它就是不合格的。实际操作中,我喜欢用这样的检查标准:把每个二级/三级小节的标题单独拎出来问自己,“用户问什么问题时,应该命中这个小节?”凡是答不出来,说明这个小节的主题不清晰。另外注意内容密度的问题。纯概念铺垫的文字,检索系统命中以后对模型生成答案没什么帮助;而堆砌名词术语又没有上下文解释,同样没用。最好的情况是:每个小节里包含“场景描述 具体操作步骤或参数 结论/坑点”,这样的片段对 RAG 来说是高价值的。2.3 元数据设计的学问如果你用的向量库或 RAG 框架支持元数据过滤,那 Wiki 的标签、文档类型、更新时间、负责人这些字段千万别浪费。举个例子:公司内部可能有 300 篇文档讲各种系统的部署流程,用户问“测试环境的 xxx 服务怎么部署”,如果系统能先按环境标签过滤出“测试环境”相关文档,再在这些文档里做相似度匹配,准确率会大幅提升。实践中我建议的元数据字段包括:文档类型(流程、排错、配置参考、规范等)适用环境(生产、测试、本地)最后更新时间服务的名称或模块名称这里额外提醒一句:维基(包括很多企业知识库系统)自带的标签体系往往比较随意,喂给 RAG 之前要做一次清洗,否则元数据本身就变成了脏数据,过滤反而帮倒忙。3. RAG 落地的技术选型与实现路径3.1 解析与切片:决定 RAG 下限的环节RAG 流程里最容易被轻视、对结果影响最大的环节是“解析与切片”。先讲解析。你在 Wiki 里导出的文档可能是 HTML、Markdown、PDF 或 Word 格式。不同的格式解析难度差异极大:Markdown 最好办,HTML 需要去掉标签保留正文,PDF 则要看是文本型还是扫描型,扫描型还需要 OCR。我建议在项目初期统一走“Markdown 化”的路线:把 Wiki 里的文档都导出或转成 Markdown 再进入后续流程,不要直接拿 HTML 或 PDF 去做切片,原因很简单——Markdown 保留了标题层级,而标题层级正是切片的重要依据。再讲切片策略。常见的三种做法:固定窗口切片:比如每 500 字符一段,带 100 字符重叠。实现简单,但语义完整性没有保障。结构化切片:依据 Markdown 的标题层级,把每个二级标题下的内容作为一个候选块;如果块太长,再往下按三级标题细分或进一步切。语义切片:使用 embedding 模型检测句子间的语义断点,在语义变化处切。效果最好但耗时更长。我的选择基本是第二种,原因是它能跟 Wiki 的结构化优势结合在一起,而且不对计算资源造成压力。如果块还是太长,再叠一个固定窗口就够用了。这里给一个可参考的配置示例:块内最大字符数:800子块重叠字符数:100切片优先锚点:## 二级标题 ### 三级标题 段落边界切片之后记得做一个“自检步骤”:抽样几十个切片,人工判断“这些切片能否独立回答问题”。如果超过 10% 的切片明显语义不完整,那就说明你的切片策略或文档结构需要调整。3.2 向量化与检索:选模型比选库更重要向量化这一步,很多人一上来就纠结“用哪个向量数据库”,这在项目初期根本不是一个重要问题。早期用 Chroma 或 FAISS 就够了,它们都能满足小型知识库的检索需求。反而是 embedding 模型的选择影响巨大:同一个问题,用不同的 embedding 模型,检索出来的 Top5 片段可能完全不同。我的建议是:优先用“中文效果好的通用 embedding 模型”,不少开源模型在生产场景下已经被验证过。如果你的语料有很强的专业领域属性,比如医药、法律、工程运维,那就要评估是否应该用领域微调的 embedding 模型,或者先用通用模型跑一版,再用命中率指标决定要不要换。检索阶段有几个参数值得调试:TopK:返回多少个片段供生成参考。K 太小会漏,通常 4~8 之间比较合适。相似度阈值:低于阈值的片段直接丢弃,避免把不相关的内容硬塞给模型。重排(Rerank):如果条件允许,在第一轮向量检索后用一个 cross-encoder 做重排,能够显著提升排序质量。这相当于“初筛”之后再“精挑”。我用一个很俗但贴切的类比:向量检索相当于“候选人初筛”,重排是“面试官终面”。初筛保证候选池里大概率有对的人,终面保证最后送到模型面前的是最有说服力的那几份材料。3.3 生成与引用:别让模型自行发挥生成环节的核心不是“让模型写得更流畅”,而是“让模型不越界”。大模型有一个老毛病:材料不足的时候,它会自己脑补。RAG 领域有个专门的词叫“引用幻觉”,指的是模型在根本没有检索到相关依据的情况下,编造一个听起来很合理的答案,甚至编造出不存在的来源。要抑制这种问题,我常用的做法是:在 prompt 中明确规定:只能基于给定材料回答,材料中没有的信息直接说“未知”。要求模型在回答末尾列出引用的片段 ID 或文档标题,并在代码层面做校验,确保引用真实存在。适当降低模型温度,设到 0.2 以下,减少自由发挥的空间。关于引用,我想多说一句:很多人觉得引用就是给用户看一个来源链接,形式上好看就行。但引用真正的价值是“可审计”——当答案错了的时候,人能从引用出发,快速找到错误根源是文档写错了、检索错了还是模型理解错了。没有引用的 RAG 系统跟直接问 ChatGPT 没本质区别,因为它丧失了“责任链路”。4. 实操中常见的四个坑:我踩过,希望你绕开4.1 切片把上下文切“碎”了这是最常见的翻车现场。有一次我把公司的一篇“项目上线检查清单”文档切成了几百个片段,结果用户问“上线前数据库备份需要注意什么”时,系统给出的答案乱七八糟,它把备份事项的前半截和后半截拼接在一起,逻辑根本不通。排查后发现,那篇文档每个小节都是一个长长的表格,表格在 Markdown 里是连续的,我的切片脚本没有对表格做特殊处理,导致一个 200 行的表被拦腰截成了 4 段。后来我的解决方式很简单:在切片前先把表格整体提取出来,按行分组、表头重复补充,保证每个切片都携带完整的表头信息。现在回想,如果当时在 Wiki 写作阶段就把大表格拆成多个小表,根本不会有这个问题。再次印证了第一条原则:源头结构比切片算法更重要。4.2 Embedding 模型与领域语料不对齐第二个坑是中文效果不佳的 embedding 模型带来的“假检索”。项目中有一段时间,系统对运维类问题的召回率特别低。用户问“磁盘满怎么办”,系统检索到的却是“磁盘分区规划”这类概念性文章,TTL(Time-To-Live)和磁盘告警处理相关的排错文档反而排在后面。我做了个小实验:用同一组问题分别测试两三个不同的 embedding 模型,对比各自 Top10 返回到手动标注的相关率,发现某个通用模型的分数明显偏低。换成本文刚才说到的更适合中文的模型后,命中率立刻上来了。这里特别想提醒:如果你直接用了某个开源通用模型,没有做领域适配,别急于怀疑你的数据,先花半天做一轮模型对比实验,这是性价比最高的优化。4.3 用户提问方式与文档表述不一致第三个坑来自用户侧。同一个问题,在 Wiki 里写的是“报错 500 网关超时”。用户提问时说的是“网站打不开,页面转圈很久”。这两种表述字符层面几乎不重叠,语义层面也只有微妙关联。如果你的 embedding 模型语义理解能力不足,或文档里没有覆盖这种口语化表述,检索基本会失败。应对办法有两个方向:一是在 Wiki 写作时多写“同义短语”和“症状关键词”;二是给知识库做一轮“Query 扩写”映射,把口语化问题映射到文档里的标准术语。前者治本,后者治标,我两个都做。凡是用户高频提问,我都把典型问法记录到文档开头的“相关常见问题”小节里,等于给未来的检索系统提前做了标注。4.4 知识更新与增量索引最后一个坑是“旧知识覆盖新答案”。你的 Wiki 已经运行了两三年,里面有一篇 2023 年的文档说“服务部署方式是手动 Jenkins”,但 2025 年已经改成了自动流水线。如果 RAG 检索把这篇文章捞出来了,模型给出的答案就是过时的,而且看起来很有依据。这块我的经验是:建立增量索引机制,Wiki 内容变更后自动触发对应文档的重索引。对文档标注“适用有效期”或“最后确认时间”,超过一定时间未确认的文档,在检索时降低权重或加上“请核对时效”的提示。设置禁用词或停用文档,只对仍有效的文档做检索,避免旧政策/旧配置出现在答案里。Wiki 和 RAG 都有“知识有寿命”这个属性,一个系统如果不处理“知识过期”的问题,它就会随着时间推移,从“智能助手”慢慢退化成“错误助手”。这部分工作和检索优化一样重要,但常常被人忽略。5. 落地路线:从个人知识库到团队级应用聊了这么多原理和坑,接下来给一条我实践下来比较顺的落地路线,你可以根据自己的情况裁剪。5.1 个人版:零门槛闭环如果你想在自己的笔记/知识库里先跑通一遍 RAG,不需要买显卡,不需要折腾太多服务。最基本的组合是三件套:笔记工具:Obsidian 或其他支持 Markdown 的知识管理工具,把内容分别放进不同目录,每篇笔记坚持“二级标题是切片单元”书写习惯。本地检索框架:使用 Ollama 跑一个本地 embedding 模型和本地大模型。零基础环节可在搜索引擎里找“Ollama 简易本地 RAG 知识库教程”作参考。界面层:用开源的检索问答前端,或者直接用 Python 脚本写一个几千行的问答 CLI 工具,足够自用。个人版的核心目标不是做大而全的系统,而是让你亲手操作一遍“切分、向量化、检索、生成、引用”的完整链路。跑通之后,你的直觉会比看十篇文章更准。5.2 团队版:与现有 Wiki 系统集成团队级使用,我的建议是不要丢掉现有 Wiki 系统去专门建一个 RAG 平台(成本太高,队友也不会配合)。实际项目中我推荐的做法是:在现有 Wiki 和 RAG 管道之间加一个同步网关。网关负责监听 Wiki 的更新事件,并把改动内容推到文档解析与索引服务。权限问题一定要早点考虑。如果 Wiki 里有些文档只对部分人可见,那么 RAG 服务必须结合上游的权限系统做好访问控制,否则等于把私有知识泄露给了所有提问者。给 RAG 服务加一个“回答后反馈”入口,用户可以对答案打标“正确、部分正确、完全错误”,这些反馈标签定期回流到索引优化逻辑里。这是团队级 RAG 效果持续提升最关键的机制,没有反馈闭环的团队级系统,效果会慢慢衰减。5.3 效果评估:别只看个别问答演示效果最后谈一下评估。RAG 系统的效果评估不能靠“随手问几个问题看起来不错”来判断。我给团队做了一套简单评估方案,周期是一周一测:建立 50~100 条验证问答对,覆盖高频问题、冷门问题、容易混淆的问题三类。每次跑完记录 Hit Rate(检索命中率:Top5 中是否包含正确文档)和 Answer Accuracy(答案正确率:模型回答与标准答案对比)。 用这两个数字对比每次改动前后的差异,判断改动是正向还是反向。我在自己的项目里观察到的现象是:Hit Rate 上去了,Answer Accuracy 不一定同步提升;但 Hit Rate 不行,Answer Accuracy 几乎肯定不会好。所以前期的优化重心应该放在检索,后期再集中火力调生成与提示词。这是一个很朴实但有效的工作节奏。6. 写在最后:让“找答案”和“长知识”形成正循环我见过不少知识库项目,投入大量精力搭建了光鲜的平台,却忽略了两个最朴素的问题:内容是否还有人持续维护?答案是否真的越来越好?RAG 与 Wiki 的结合,最理想的状态不是“用机器替代人读文档”,而是“机器先把最相关的文档送到人面前,人负责最终判断和内容沉淀”。当一个提问者通过 RAG 得到一份答案,他点开引用链接、发现某个步骤需要补充,顺手在 Wiki 里改了一笔,这个动作会让下一位提问者得到更好的答案——这就是知识管理的正循环。我个人在实操中还有一个小习惯,分享出来供参考:我每周固定抽出 30 分钟,浏览一遍本周 RAG 系统里回答得分最低的 20 个问题,找出其中的规律,要么是文档缺失,要么是表达偏差,要么是权限问题。这 30 分钟远比我去调一堆复杂参数值更能提升系统的实际体验。毕竟,系统再聪明,它依赖的语料质量最终还是要靠人来兜底。如果你正准备在团队里做类似的事情,我的建议是先拿一小块真实场景的文档跑通最小闭环,让团队看到“问一句话就能得到带出处的答案”到底是什么体验,再谈扩大范围。往往到了这一步,后面的事情就是顺水推舟了。