1. 为什么我放弃了“只做RAG”和“只做Wiki”先说个我自己的经历。早两年做知识库项目团队内部吵过好几次搞算法的坚持上RAG觉得语义检索是王道做内容的坚持维护Wiki认为结构化沉淀才是根本。吵到后面干脆各做各的结果是——RAG这边召回的答案经常张冠李戴Wiki那边文档写得很全但没人翻。后来我想明白一件事RAG和Wiki根本不是替代关系而是互补的上下楼关系。Wiki负责“知识进来”RAG负责“答案出去”。前者解决的是知识积累和结构化的根问题后者解决的是知识触达和使用的最后一公里。你现在看那些热词——agentic rag、graphrag、ontology rag——本质都是在给“找答案”这件事叠buff但不管怎么叠底层都得有一块整理得当的知识地基这块地基就是Wiki。这篇博文我打算把一套实战方案完整拆开怎么用Wiki作为知识源怎么把它喂给RAG流程以及我自己踩过的一堆坑分块策略、命中率优化、引用溯源这些。这适合正在搭知识库但效果一直不理想的团队也适合个人想用本地模型跑通一个“纯本地RAG”的朋友——后面会给出可复制的零基础配置路径。2. 先厘清两个词RAG到底在“找”什么Wiki到底在“长”什么2.1 RAG的本质不是搜索是“带着材料的阅读理解”RAGRetrieval-Augmented Generation这个名字听着高级拆开就是“先检索再生成”。但很多人忽略了一点检索不是目标生成才是。系统先根据用户的问题从知识库里捞出一批候选段落再把这些段落当成“参考资料”交给大模型让模型基于这些材料组织答案。这里有个很关键的区别传统搜索引擎给你十条链接你自己判断点哪条RAG要求系统一次性把“最有用的几段”选出来并让模型直接消化。所以RAG项目里最核心的指标不是模型本身多强而是检索质量。检索质量差了后面模型再聪明也只能“一本正经地胡说八道”。之前看到有人在热词里搜“rag hit rate”这就是在问命中率怎么算。业内常用的评估方式是先准备一批“问题-标准答案段落”的测试对跑一遍检索看正确段落是否出现在top-k结果里。Hit Rate5意思是正确段落出现在前5个结果里的比例。我建议新项目上线前至少准备50组测试对不然你根本分不清效果差是模型的问题还是检索的问题。2.2 Wiki的价值结构化的知识不是文档堆是“知识网络”Wiki在过去二十年里几乎成了“团队知识库”的代名词——但大多数人用Wiki的方式其实是错的他们把Wiki当成了网盘只会往里面扔文档。真正的Wiki应该具备三个特征词条化、链接化、版本化。词条化意味着每个页面围绕一个明确主题而不是一篇流水账链接化意味着页面与页面之间用引用关系织成网而不是孤立的存在版本化意味着每一次更新都有历史记录可以追溯“这条知识是什么时候被谁改的”。这一点在热词里出现过的“obsidian搭建知识体系”其实也是同一套逻辑——本地双链笔记本质就是一个私有Wiki。所以别纠结工具叫什么名字Obsidian、MediaWiki、语雀、飞书Wiki、甚至Git仓库里的Markdown只要符合“词条链接版本”三要素都可以当成Wiki来用。2.3 为什么要打通知识被写下来≠知识能被用起来Wiki最大的痛点是什么使用门槛。内容写了但用户不知道关键词该搜什么就算搜到了还要自己翻上下文。RAG最大的痛点是什么知识源头没整理。拿一堆杂乱文档直接切片灌进向量库召回的自然也是乱七八槽的结果——业界有个说法叫“garbage in, garbage out”喂进去垃圾出来的答案就是垃圾。打通两者的正确姿势是Wiki负责保证知识的组织质量RAG负责降低知识的使用门槛。Wiki里定义好了规范、术语、标准答案的表述方式RAG检索到的段落就更有可能是高质量的“标准说法”而不是某个同事随手写的吐槽。注意这里有个容易混淆的概念RAG知识库能存图片吗能但存的是图片的描述文本或者OCR识别后的文字向量化的是文本而非像素。指望RAG直接“看懂”图片内容并回答那是多模态模型的活儿和RAG本身没关系。类似的热词里有人搜“rag知识库能存储图片嘛”准确地说答案是可以存储图片文件但检索和生成环节利用的是图片周边的文字信息。3. 整体架构设计一份可以照着抄的知识库方案3.1 数据流从Wiki到答案的完整链路我推荐一个比较成熟的链路这个结构在好几个生产项目里验证过稳定性和可维护性都不错知识写入内容团队在Wiki里维护词条所有页面遵循统一的编写规范后面细说规范。定时同步通过脚本Git拉取或API轮询定期把Wiki页面导出为Markdown或纯文本。清洗分块去掉模板噪音导航栏、页脚按标题语义进行智能分块。向量化入库用Embedding模型把每个块转成向量同时保留原文引用信息文档路径、标题层级、行号范围。双路检索用户提问时同时走关键词检索BM25和向量检索用RRFReciprocal Rank Fusion合并排序。引用生成把检索到的Top-K块拼进Prompt要求模型回答时带上引用编号。第5步是很多入门教程不会讲的。只用向量检索容易漏掉精确词条比如产品型号“A3-2024”这种专有名词只用关键词检索又没法处理“帮我找一下上个月讨论过的那个降本方案”这种语义模糊的问题。BM25向量检索RRF融合是我测试下来性价比最高的组合比单纯向量检索的Hit Rate5能高10到15个百分点。3.2 工具选型本地部署还是云端API工具选型一直是新人最头疼的部分。我的建议很简单先看你的数据量级和隐私要求再看预算。如果只是个人玩、数据量在几千个文档以内强烈推荐本地部署路线Ollama拉起一个Embedding模型比如bge-m3或者nomic-embed-text再拉一个生成模型qwen2.5:7b或者llama3.1:8b向量库用ChromaDB或者LanceDB——这四个东西加在一起对显存的要求大概8GB到12GB一台普通游戏本就能跑。热词里出现的“ollama 简易本地rag知识库【零基础可复制教程】”说的就是这个套路。如果是团队生产环境数据量上十万级那别折腾本地模型了。Embedding模型直接用OpenAI的text-embedding-3-large或者国产的BGE旗舰版本向量库用Milvus或Qdrant生成模型按业务场景选API还是私有化部署。这里没有标准答案核心原则是Embedding模型决定检索上限生成模型决定表达下限——前者选错了后面再调都是事倍功半。还有个容易被忽略的点后端框架别花太多时间挑。LangChain、LlamaIndex、Haystack都行甚至裸写几百行代码也可以。我在生产环境反而更推荐LangChain4jJava生态或者直接自己封装API因为底层依赖越少排查Bug越容易。热词里看到有人在搜“基于langchain的rag流程”说明这个方向还是有热度但LangChain本身迭代太快跟着它升级版本是个无底洞。3.3 为什么先做小规模验证再全量迁移我看到太多团队一上来就想把几千份文档全量导入结果向量化跑了三天两夜最后发现Embedding模型选错全部白干。正确做法是先挑50个最能代表业务场景的词条做小样。走通“Wiki导出→清洗→分块→入库→检索→生成”全流程先人工判断答案质量再量化计算Hit Rate。小样本验证达不到80%以上的命中率就别往全量走先回头调分块和检索策略。这一步花的时间不会超过一天但能帮你节约至少一周的返工时间。不要跳过也不要贪快。4. Wiki侧的功夫知识结构决定RAG上限4.1 词条编写规范让机器好懂先让人好读RAG的输入是文本段落所以Wiki页面写的质量直接影响检索效果。但团队里每个人写作习惯不一样这就需要规范。我总结了三条最重要的第一一段话只说一件事。一个段落里又是背景、又是方案、又是注意事项的分块的时候会很为难——切断了语义不完整不切断又掺着多个主题。一个段落100到200字为佳最多不超过300字。第二首次出现的术语必须给定义。RAG检索经常命中的是“第一次介绍概念”的段落如果这段里只有简称没有全称模型就容易误解。比如写“本系统采用RAG方案”最好写成“本系统采用RAGRetrieval-Augmented Generation检索增强生成方案”。第三结论前置。把结论和答案放在段落开头背景和推导放后面。这不仅仅是为了人类读者扫读方便更关键的是——向量检索在匹配时段落前半部分的权重通常更高这取决于Embedding模型的池化策略但很多模型默认取均值或CLS向量结论前置能把最核心的信息放在语义最突出的位置。4.2 双链与命名规范让Wiki成为“可导航的知识图谱”Wiki页面之间的链接关系不只是给人看的它还能成为将来做GraphRAG的基础。我给团队定了几条命名规范词条命名用“名词短语”不用句子。比如“库存扣减流程”而不是“我们来聊聊库存扣减是怎么做的”。页面内固定结构定义区、使用场景、注意事项、相关词条。每个区域用二级标题隔开。相关词条区必须用Wiki双链语法为将来GraphRAG提取实体关系做铺垫。说到GraphRAG最近热度确实很高热词里也有人搜“graphrag llm wiki 本体rag”。GraphRAG的思路是在纯向量检索之外额外把文档中抽取的实体和关系构成知识图谱支持多跳问答比如“A项目影响了哪些模块这些模块又依赖哪些外部系统”——纯RAG很难回答这种复杂关联问题GraphRAG却能通过图遍历做到。但GraphRAG也有代价抽取实体需要额外的LLM调用构建索引的成本比普通RAG高一到两个数量级。我的建议是内容少时不用GraphRAG先靠Wiki双链人工维护关键词关系内容多到几千词条再说。还有一种折中方案就是ontology rag——先定义领域本体比如“项目-依赖-影响”三类实体、两种关系再让LLM按本体约束去抽取这样构建出来的图谱更干净不会变成一团乱麻。4.3 版本管理RAG问答出错了怎么追责这一点很少被提及但我认为它是生产环境最关键的环节。RAG系统上线后必然会出现错答、幻觉运维人员需要快速定位“这个错误答案是哪来的”。如果没有版本管理排查链路是断的你只知道模型给了个错误答案但不知道它参考了哪份文档更不知道那份文档是谁写的、什么时候改的。有了Wiki版本历史之后追溯路径就清晰了——向量库里的每个块都存有“文档版本号块ID”发现错误答案后先反查引用来源再对比该文档当前版本是不是已经修正过。如果Wiki已经修正但库里还是旧版说明同步脚本没跑如果Wiki本身就没写对那就该找写文档的人了。我在实际项目里反复强调一句话RAG系统出了问题90%不是模型的问题是知识源的问题。5. RAG侧实战分块、检索、生成的细节和坑5.1 分块策略别迷信固定窗口按语义走分块是RAG项目里最“细节决定成败”的环节。常见做法有两种固定字符窗口比如每512个字符切一块重叠128字符和语义分块按标题、段落边界切。我的经验是能用语义分块就别用固定窗口。原因很简单固定窗口经常把一句话从中间切开或者把“上半部分是背景、下半部分是结论”的语义单位拆得七零八碎。召回时看着命中了但内容是不完整的生成质量自然差。实操的语义分块逻辑可以这么定以Markdown标题层级为骨架遇到二级标题强制切块二级标题下的内容如果超过800字再按三级标题或空行二次切分单个块最小不低于100字太短的信息密度不够最大不超过1000字太长的容易稀释语义。这块没有开箱即用的通用工具大部分是写几十行脚本自己处理。有人搜“有没有本地的rag文本拆解工具”——答案是有但都只是半成品像LlamaIndex里的SentenceSplitter可以按句子边界切Unstructured库可以按文档结构切但真正适合你自己业务的规则还得自己加。5.2 Embedding模型选型与本地部署Embedding模型的选择直接决定检索质量但这个领域更新太快我只说几个判断标准中文场景优先看C-MTEB榜单中文语义向量评测基准别只看英文榜单。模型参数量不是越大越好关键是训练数据是否符合你的垂直领域。通用领域就用BGE系列法律、医疗等垂直领域建议选对应领域微调的版本。本地部署用Ollama时注意向量维度的一致性。入库时用的模型和查询时用的模型不一致查询向量的维度都对不上这是新手最常见的坑。本地部署Ollama的命令很简单Windows/Linux都可以# 拉取BGE-M3中文本体模型 ollama pull bge-m3 # 拉取生成模型7B参数级别家用显卡能跑 ollama pull qwen2.5:7b # 开发模式下启动服务端口默认11434 ollama serve然后Python端调用就极简了import requests resp requests.post( http://localhost:11434/api/embed, json{model: bge-m3, input: [库存扣减流程说明]} ) embedding resp.json()[embeddings][0]整个过程加起来不到十分钟这就是“零基础可复制教程”的含金量。不过有一点提醒bge-m3支持8192的上下文窗口但嵌入质量在超过1000字后会明显衰减所以我前面说的单块控制在1000字以内跟模型特性也是吻合的。5.3 检索调优从“找得到”到“找得准”检索阶段的核心目标是提高Hit Rate我有三个屡试不爽的调优手段第一个是查询改写。用户原始问题往往口语化严重例如“那个扣库存的老是出错怎么办”——这种问题直接拿去检索和文档里的表述“库存扣减异常处理方案”语义距离较大。可以在检索前先用LLM把问题改写为更规范的查询语句再拿改写后的文本去检索命中率会有明显提升。第二个是混合检索加RRF融合。BM25擅长精确匹配术语向量检索擅长语义召回二者结合后按RRF公式重排score Σ 1/(k rank)k通常取60。这个公式不复杂但融合后的效果通常比单一检索高一截。第三个是Top-K动态调整。别死板地固定K5。问题简单、答案大概率集中在一个块里的K3就够了K大了反而给模型塞入噪声问题复杂、涉及多步骤操作的K应该上调到8甚至10。实际项目里建议根据问题长度和检索置信度做一个简单的规则映射跑一次测试集对比不同K值下的答案质量再定。5.4 Prompt设计不是把材料丢给模型就完事了检索做好了Prompt设计也不能拖后腿。我常用的RAG Prompt模板核心结构是你是一名技术支持专家。请基于下列“知识库片段”回答问题。 要求 1. 如果片段中找不到答案直接说“知识库中暂无相关信息”禁止凭空编造。 2. 回答末尾标注引用来源编号例如[1][2]对应下方的片段序号。 3. 如果多个片段存在矛盾指出矛盾之处并优先采用片段中明确标注为“最新版本”的内容。 知识库片段 [1] {chunk_1} [2] {chunk_2} 用户问题{query}这个模板有三层用意拒绝幻觉找不到就直说、强制引用方便追责和用户验证、矛盾识别多个知识源不一致时的处理原则。最后一条非常重要——当Wiki页面在两周内被改过两版向量库里很可能同时存在旧版和新版的块模型必须有能力识别版本冲突而不是强行融合成一个自相矛盾的答案。5.5 评估闭环RAG不是上线就完事的系统最后聊聊评估。RAG系统上线只是开始真正的挑战在于持续优化。每次版本更新都需要跑一遍测试集对比Hit Rate和答案质量。我建议维护三类评估数据标准问答对50到200组作为回归测试集每次调整分块、检索或Prompt后跑一遍防止优化一个问题带崩另外三个。Bad Case池把生产环境中用户反馈的不满意回答收集起来定期分析是检索漏召回还是模型生成出错。引用准确率检查模型回答中标注的引用编号是否真的对应有依据的段落这是评估“有没有幻觉”最直接的指标。这个评估闭环没有终点。RAG是一个需要持续运营的系统想做到“越用越聪明”就得靠这套反馈机制不断反哺Wiki内容质量和检索质量。6. 常见问题速查与排查思路我把实战中遇到最多的问题整理成一个清单每个问题后面附上排查思路碰到类似情况可以直接对照处理现象可能原因排查与处理答案和知识库内容完全无关分块太大导致语义稀释或Embedding模型不适合领域检查单块字数换垂直领域Embedding模型回答总说“知识库中暂无相关信息”检索命中率太低正确段落没进Top-K在测试集上算Hit Rate5尝试查询改写和混合检索答案陈旧引用的是旧版本内容同步脚本异常向量库未更新核对文档版本号和向量库入库时间重新触发同步任务回答张冠李戴把A产品的说明放在B产品上命名规范不统一产品名在不同文档中表述不一致在Wiki中统一术语表检索前对查询做术语归一化用户问“上个月讨论过的那个方案”这种模糊问题查询太过口语化直接检索效果差用LLM做查询改写补充时间、主体等缺失信息同样的Ask两次答案不一样生成阶段温度参数过高或模型采样随机性调低temperature至0.1以下检索阶段开启缓存入库文档包含大量表格、扫描件表格结构在文本化过程中丢失扫描件无法直接向量化对表格转成Markdown并逐行描述扫描件先跑OCR再入库排查的时候记住一个原则从数据源头往链路末端逐层检查。先看Wiki文档本身是否准确再看同步任务有没有跑成功然后看分块结果是否可读最后才怀疑模型问题。跳过前面的链路直接换大模型是最常见的无效调优。7. 进阶方向从RAG到Agentic RAG再到领域知识图谱如果基础RAG已经跑通了想进一步提升上限可以按这个顺序往下走。第一步是多轮对话状态管理。普通RAG是“有问必答、答完即走”但真实用户往往需要追问——“那影响有哪些”“有没有办法规避”——第二句话脱离了上下文根本没法检索。这需要引入对话历史管理把前几轮的关键信息整合进当前查询再检索也就是记忆增强式的Agent行为。第二步是Agentic RAG。这里的“Agentic”不是营销词它指的是RAG不再是一次性的检索-生成而是让模型具备“自己判断要不要再查一次”的能力。比如用户问的问题在Top-K里没找到满意答案模型可以主动改写查询重新检索或者调用另一个知识库的API甚至整合多个数据源之后再综合回答。这需要给LLM配上工具调用能力工程复杂度上一个台阶但对复杂问题的回答质量提升非常明显。第三步是本体RAG与领域图谱。前面提到ontology rag本质是为知识图谱定义一套明确的本体模型例如“故障现象—根因—解决方案—涉及系统”这样的四类实体和三类关系。让抽取模型严格按这个本体输出图谱之后多跳推理和归因分析就不需要每次临时抽取了。这项工作量最大但做好之后整个知识库的“可计算性”会彻底改变——不仅RAG能用数据分析和决策支持也能共用这套图谱。这三步走完你会发现自己对“知识库”这个词的理解已经不一样了。它不再是存文档的地方而是一个真正能推理、能追溯、能演进的知识系统。8. 最后一剂实战心得这几套方案都不是我在纸上推演出来的每一个坑都是真金白银换来的。最后分享几条最有感觉的经验第一别一上来就上最强方案。GraphRAG、Agentic RAG听着很酷但底层的基础检索还没调好之前上再多的进阶方案都只是在掩盖问题。先把“Wiki写规范、分块切合理、检索能命中”这三件基本功练好进阶方案是水到渠成的事。第二Wiki的规范执行比工具选型重要一百倍。用MediaWiki还是飞书还是Obsidian其实不影响大局但词条命名混乱、结构随意、没有版本纪律的Wiki不管接什么RAG都救不回来。知识管理归根结底是管理人的写作习惯不是管理软件。第三评估集是你的命根子。没有测试集的RAG项目就像没有单元测试的代码库每次改动都在赌。宁可花三天时间整理评估集也不要急着上线一个没有评估标准的系统。如果你想在这个方案基础上更进一步我建议从“用Wiki双链构建小规模图谱”开始试——不需要上GraphRAG那么重型的方案先把Wiki内部的知识关联理顺你会发现检索命中率都会随之变好。这就是“RAG找答案Wiki长知识”这句话的真正含义找答案的能力上限取决于长知识的质量下限。