“RAG 找答案Wiki 长知识”——这句话我在本地知识库项目里泡了快两年之后越来越觉得它是对整个领域最简洁也最准确的概括。今年我陆续搭了好几套基于 Ollama 的本地 RAG 问答系统也帮团队把几十份产品文档、技术资料和 SOP 搬进了 Wiki再用 RAG 把这些内容变成能回答问题的机器人。真正跑起来才发现很多人把 RAG 和 Wiki 当成同一种东西以为“只要有个知识库大模型就能答好”结果折腾几个星期答案不是凭空编造就是翻遍文档也找不着出处。这篇文章我不打算讲那种泛泛的概念介绍而是把“RAG 找答案”和“Wiki 长知识”这两件事掰开揉碎先搞清楚它们各管哪一环再给一套零基础能落地的本地 RAG 搭建流程接着聊聊 Agentic RAG、GraphRAG、Ontology RAG 这些热度一路走高的进阶玩法最后把我实测中踩过的坑和排查方法整理出来。不管你是在做企业知识库、个人笔记问答还是给开源项目做智能文档助手这篇内容应该都能让你少走不少弯路。1. 先把概念掰开RAG 管“找答案”Wiki 管“长知识”很多人一上来就想做“知识库问答”但“知识库”这三个字其实包含了两套完全不同的系统。一套是内容的生产与组织系统负责把零散信息变成结构化的、可追溯的、持续更新的知识资产典型形态就是 Wiki另一套是检索与生成系统负责在用户提问时快速找到相关片段并组织成有依据的回答典型形态就是 RAG。这两套系统互相依赖但绝不能混为一谈。1.1 RAG 是什么不是替代大模型是给大模型配一个资料库RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它解决的底层问题是大模型的知识是“练出来的”训练完成那一刻知识就冻结了既不知道你公司内部的新 SOP也不知道你最近更新的产品参数更不知道那些只存在于少数专家脑子里的经验。RAG 的思路非常朴素——既然模型不知道那就别让它硬答先从一个外部知识库里把相关资料“搜”出来再让模型基于这些资料作答。打个比方这就像一场开卷考试。大模型本身是那个记忆力不错、但课本版本过时的考生RAG 是那个负责翻资料找答案的助手Wiki 则是考场里允许你翻阅的参考书。没有参考书的开卷考试是伪开卷没有 RAG 的知识库也只是一堆躺在角落里没人看的文档。反过来如果参考书本身内容混乱、缺章少页助手再勤快也翻不出有用的东西。所以 RAG 的定位从来不是“替代大模型”而是“给大模型配一个可以实时翻看的资料库”。它的效果上限很大程度不取决于模型多聪明而取决于你喂给它的资料是什么、怎么组织、怎么检索。1.2 Wiki 是什么知识仓库不是答题器Wiki 的核心价值在于知识的结构化沉淀。一个合格的 Wiki 不只是几十个 Markdown 文件堆在一起它应该具备清晰的目录层级、稳定的命名规范、页面之间的交叉引用以及持续维护的版本记录。像很多开源项目用 Wiki 管理开发文档、硬件项目用 Wiki 记录编译烧录步骤本质上都是在做同一件事让知识从个人脑子里流动到团队层面并且随时能被找到、被更新、被校验。我见过不少团队做知识库的时候第一个动作就是把一堆 Word、PDF 拖进某个“AI 问答工具”里结果检索质量惨不忍睹。原因很简单那些原始文档很多是给“人读”而不是给“机器检索”写的结构混乱、术语不统一、重复内容遍地都是。Wiki 做的是另一件事——它先把这些内容重新组织成一个体系让每一条知识都有明确的归属、出处和上下文。做好了这些后面无论接 RAG 还是接别的什么检索方式效果都不会差。1.3 为什么说这两个能力必须分开建设把 RAG 和 Wiki 分开建设不是因为它们不能整合而是因为它们的维护节奏和评价标准完全不同。Wiki 是一个“慢系统”。它的内容是积累出来的需要人来写、来审、来更新。评价一个 Wiki 做得好不好看的是知识是否齐全、是否最新、导航是否顺畅。RAG 则是一个“快系统”。它要在用户提问的几百毫秒内完成检索和生成。评价一个 RAG 系统好不好看的是命中率hit rate、回答的准确性和引用的可溯源性。如果你把这两件事混在一起比如直接在聊天工具里让团队成员往某个数据库里扔文档然后指望 AI 自动整理成一个好 Wiki大概率会得到一个“既不像知识库、也答不准问题”的四不像。正确做法是先用 Wiki 把知识结构立起来再基于这个结构做 RAGRAG 回答得不好时回头去改 Wiki 的内容质量而不是盲目换模型、调参数。2. 一条 RAG 问答链路是怎么跑通的想把 RAG 玩明白必须先完整理解一条问答链路上每个环节在做什么。很多人在检索结果不理想时上来就调 embedding 模型、调相似度算法其实问题往往出在最前面的文档处理阶段。2.1 三个阶段准备期、检索期、生成期一条完整的 RAG 链路可以分成三个阶段。准备期是把知识文档切分为小块chunk、计算向量embedding、存入向量数据库的过程。这个阶段决定了系统“知道什么”。检索期是用户提问后把问题转成向量、在向量库里做相似度检索、取出最相关的若干文档片段的过程。这个阶段决定了系统“能想起什么”。生成期是把检回来的片段和用户问题一起拼进提示词交给大模型生成回答的过程。这个阶段决定了系统“怎么说”。这三个阶段环环相扣但经常被忽略的是每个阶段都有自己的成功标准。准备期看的是“切块是否合理、向量能否表达语义”检索期看的是“相关片段有没有被召回”生成期看的是“回答是否忠实于检索内容”。排查问题时先定位是哪一段坏了比盲目重试有用得多。2.2 分块和嵌入是质量地基分块chunking是整个 RAG 里最不起眼、但影响最大的环节。块切得太小比如一句话一个块检索时可能会切断上下文模型拿到的片段语义不完整块切得太大比如一整页一个块检索时噪声会很多还会快速撑爆上下文窗口导致答案被无关细节淹没。我的实践经验是中文场景下chunk_size 通常取 200 到 400 个 tokenoverlap 取 10% 到 20%。overlap 的作用是让相邻块之间保留重叠信息避免一个完整段落恰好被从中间切开的尴尬。英文文档可以适当放大到 400 到 500 token因为英文的语义边界更清晰。但这只是起点不同文档类型差异很大——代码类文档要把函数定义和注释放在同一块表格类文档则要尽量整表保留。嵌入embedding模型的选择同样关键。本地场景中我比较常用的是 bge-m3、m3e 这类开源中文嵌入模型对中文语义的支持比通用英文模型好不少。判断一个嵌入模型合不合适不要只看某个公开榜单最好拿你自己的真实文档跑一批样例问题看看召回的片段是不是你真的需要的。换嵌入模型比换大模型对 RAG 效果的提升通常更明显这个我实测过很多次。2.3 RAG 能存图片吗多模态知识库的现状很多人问我“RAG 知识库能不能直接存图片”包括网上搜这个问题的人也非常多。直接回答传统 RAG 不能因为标准 RAG 链路处理的是文本和向量图片本身无法直接参与相似度检索。但这不意味着知识库里的图片只能被丢弃。目前比较务实的做法有三条路径。第一OCR 把图片里的文字抽出来图片转成文本块参与向量化原始图片作为附件挂在该文本块的上下文里用户提问时模型可以看到图片路径甚至被引用的图片。第二生成图片的文字描述用多模态模型给每张图片写一段说明文字描述入库图片本身存附件。第三直接上多模态 embedding 模型比如 CLIP 类模型图片和文本都映射到同一个向量空间可以做到“以图搜图、以文搜图、以图搜文”但本地部署成本高对硬件要求也高。我的建议是除非你的知识库中有大量“看图才能懂”的内容否则先走 OCR 文字描述入库最划算。把 attention 花在核心问答质量上不要让多模态炫技拖慢整个项目。3. 零基础也能复制的本地 RAG 搭建方案网上搜“rag 实战”“rag 教程”能搜到一大堆方案但很多一上来就上 LangChain OpenAI API要么付费、要么依赖在线服务。这里我分享一套完全本地跑的方案用的全是开源工具零基础也能照着复现。热词里那篇“Ollama 简易本地 RAG 知识库【零基础可复制教程】”走的也是同一个方向。3.1 工具选型Ollama、嵌入模型、向量库、编排框架怎么挑完整的本地 RAG 栈通常有四层模型层用 Ollama 跑本地大模型和嵌入模型。大模型推荐 qwen2.5 系列或 llama3.1 系列嵌入模型推荐 bge-m3。嵌入与向量层负责把文本变成向量、存进向量库。入门用 ChromaDB 最省心数据量大了换 Qdrant再大换 Milvus。编排层负责把“检索 拼提示词 生成”串起来。Python 生态用 LangChain 或 LlamaIndexJava 生态用 LangChain4j热词里的“langchain4j easy rag”就是这个方向不想写代码的可以用 Dify 或 FastGPT。知识源层就是你要灌进去的文档最好先整理成 Wiki 形态。选型逻辑很简单先看你想花多少精力维护再看你要处理多少文档。一个人做个人知识库ChromaDB LangChain 就够用几十个人协作的企业知识库建议上 Qdrant 和正式的 Wiki 系统如果用户提问模式高度固定、不需要复杂 Agent 能力甚至可以不用 LangChain手写一个 50 行的 Python 脚本也能跑通 RAG。3.2 从安装到跑通第一个问答以最简方案为例假设你已经装了 Ollama。第一步先拉模型# 拉一个大模型用于生成回答 ollama pull qwen2.5:7b # 拉一个嵌入模型用于把文档转成向量 ollama pull bge-m3然后安装 Python 依赖pip install langchain langchain-community chromadb接着用一个简单的 Python 脚本完成“建知识库 问答”全流程from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.llms import Ollama from langchain.chains import RetrievalQA from langchain_community.document_loaders import DirectoryLoader # 1. 加载文档 loader DirectoryLoader(./docs, glob**/*.md) documents loader.load() # 2. 分块 splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50, ) chunks splitter.split_documents(documents) # 3. 向量化并存入 Chroma embeddings OllamaEmbeddings(modelbge-m3) vectordb Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) # 4. 构建检索问答 qa RetrievalQA.from_chain_type( llmOllama(modelqwen2.5:7b), retrievervectordb.as_retriever(search_kwargs{k: 4}), ) # 5. 提问 answer qa.invoke(如何配置设备的网络参数) print(answer[result])这套流程跑通后你就拥有了一个完整的本地 RAG 雏形。注意.invoke()返回的结果包含“检索到的文档片段 生成答案”两部分一定要养成查看检索片段source chunks的习惯因为答案质量好坏80% 在检索这一步就已经定型了。3.3 调好这些参数命中率hit rate才会上去RAG 领域有个词叫 hit rate命中率衡量的是“真实相关的文档片段有多大比例被检索出来了”。很多项目上线后效果不好第一件事不是换模型而是看 hit rate 有没有达标。提升 hit rate 主要有五个抓手chunk_size 和 chunk_overlap太小丢上下文太大引噪声按上一节建议起步再根据你的文档类型微调。检索的 top_k通常 4 到 10 之间。太小可能漏掉正确答案太大则会在生成时混入大量无关信息。相似度阈值如果检索出来的 top_k 片段的相似度分数都在及格线以下说明知识库里可能根本没有相关内容这时宁可让模型说“我不确定”也不要强答。查询改写query rewrite用户口语化的问题往往和文档里的术语不一致。先让大模型把问题改写成几个与文档风格匹配的子问题再分别检索能明显提高召回质量。重排rerank向量检索的初排结果不一定准确加一个重排模型对 top_k 候选重新打分效果立竿见影但会增加延迟和计算量。还有一个常被忽略的细节你的问题示例要和嵌入模型的能力匹配。如果嵌入模型是中文优化的而你的文档大量使用英文缩写和专业术语最好先做术语表归一化否则“Wi-Fi”和“wifi”“无线网络”会被当成完全不相干的向量。4. 热度很高但容易被误用的三个进阶方向网上搜 RAG 相关热词Agentic RAG、GraphRAG、Ontology RAG 这三个词出现频率极高。它们确实代表了 RAG 从“一把梭”走向精细化的发展方向但很多人还没搞清它们的适用边界就直接上结果项目成本暴涨、收益寥寥。4.1 Agentic RAG从单向问答变成多轮决策普通 RAG 是“提问一次、检索一次、生成一次”的固定流程。Agentic RAG 则把大模型变成一个智能体Agent它可以根据当前答案是否充分决定是继续检索、改写问题再去检索还是直接调用某个工具比如查数据库、执行代码来补充信息。典型的应用场景是用户问“公司过去三个月出货量下降的原因是什么”这既需要检索销售分析文档又可能需要从数据库里拉实时数据还可能要看历史对比报告。单个 RAG 流程很难在一次检索里全部覆盖但 Agent 可以自己规划“先查实时数据再检索分析文档提到的原因最后组织回答。”这种灵活性是传统 RAG 给不了的。但我要提醒一点Agentic RAG 意味着更多的模型调用次数和更长的耗时也就意味着更高的失败点和成本。如果你的场景只是固定知识库问答不需要多步推理和工具调用千万不要为了追热点硬上 Agent 架构。4.2 GraphRAG擅长回答那些“打通整个库”的问题GraphRAG 的思路是先对文档做实体和关系抽取构建一张知识图谱回答问题时先在图谱上做多跳检索比如“A 公司的供应商 BB 的子公司 C 又供应了 D 产品”再把图上的相关子图喂给大模型。普通 RAG 擅长回答“这个设备怎么配置”GraphRAG 更擅长回答“整个系统里哪些环节会互相影响”。微软的 GraphRAG 开源项目带火了这个方向但代价是索引阶段的计算量非常大而且实体抽取质量直接影响后续所有检索效果。我的建议是只在你的知识库确实需要多跳关系推理时再用 GraphRAG比如技术架构分析、业务流程梳理、知识图谱问答。纯文档问答用传统 RAG 就好。4.3 Ontology RAG用结构化本体把提问约束在专业语境里Ontology RAG 是在知识库之上再加一层“本体”——一套明确定义的概念、属性和关系体系。比如做设备维修知识库本体里定义了“设备型号”“故障现象”“维修步骤”“备件信息”以及它们之间的关系。用户提问“设备无故重启怎么办”系统不会满库乱搜而是先映射到“设备型号”和“故障现象”两个本体概念再定向检索相关维修记录。这是我很看好的一个方向尤其适合垂直领域。它解决的是 RAG 的一大隐患自然语言提问太发散导致检索结果不可控。有了本体约束检索范围被规范到领域语义空间里hit rate 会稳定很多。但它的建设成本也最高因为本体本身需要领域专家梳理维护起来比普通 Wiki 文档费劲得多。这三个方向不是替代关系而是递进关系普通 RAG 能解决了 80% 的问题剩下的 20% 才需要根据具体瓶颈选择 Agentic、Graph 或 Ontology。5. Wiki 内容怎么组织RAG 效果才会好前面我说“Wiki 长知识”是 RAG 的地基这里展开讲怎么让这个地基真的撑得住检索。很多人把 Wiki 当成了一个简单的文档存储空间这样接 RAG 效果自然有限。真正的 Wiki 式内容组织应该直接服务于检索策略。5.1 文档结构段落、标题、双向链接都是检索线索Wiki 的页面结构对 RAG 检索质量的影响比大多数人想象中更大。我建议每个知识页面遵循一个固定模板开头是 3 到 5 句话的摘要正文按“背景 / 操作步骤 / 注意事项 / 常见问题”分节结尾统一添加相关术语链接。这样做的好处是摘要部分本身就是一个高质量的“可检索摘要”用户问题与摘要的语义匹配度远高于正文里的长段落分节后的内容天然适合做分块边界每块的语义都相对完整链接则是隐式的关系线索你甚至可以把 Wiki 里的 [[互链]] 当成本体关系后面接 GraphRAG 时能省不少抽取工作。标题也要注意。别写“配置说明”“问题记录”这种模糊标题改成“如何配置静态 IP 地址”“设备重启后无法连接网络的排查记录”。因为检索时标题往往会被加权一个语义明确的标题能在不增加 token 的情况下显著提升命中率。5.2 图文混排内容的处理OCR、描述与附件知识库里总有大量图文混排的内容比如软件截图、流程图、表格。处理这些内容有一套固定打法Markdown 文档里保留原始表格图片统一存到同目录的 assets 文件夹正文中用相对路径引用另在文本说明中写清图片内容的关键信息。表格是最容易在 RAG 里翻车的类型。切块时如果表格被拆成多段文本模型根本看不懂行列关系。我的做法是小表格整个放一个块里大表格拆分成“表头 若干行组”并用描述性文字包裹让模型知道这是一张表格。图片的处理我在第 2.3 节说过OCR 或描述文本入库原图作为附件挂载。这些准备工作做足了用户提问“看下这张截图里的告警信息”时系统才有机会把图片和对应文本一起拿出来。5.3 用游戏 Wiki 和开源项目 Wiki 找灵感Wiki RAG 不仅适用于企业知识库很多现成的优秀案例反而来自游戏和开源社区。比如英灵神殿Valheim的 Wiki把每种材料、装备合成路径、BOSS 掉落整理成了结构化页面有人拿这套 Wiki 配合 RAG 做游戏问答助手问“做个铁斧需要什么材料”能直接给出一串合成步骤。这说明什么说明 Wiki 内容质量够高的时候RAG 只是最后一步的“外挂”。开源项目里像 ESP32 摄像头二维码识别项目、ChameleonUltra 这类硬件项目也都在用 Wiki 沉淀编译步骤、硬件配置和排错指南。对这些项目的作者来说Wiki 不只是给人看的文档更是未来训练 AI 问答机器人的语料库。玩 RAG 的人不妨多逛逛这些开源 Wiki研究别人怎么组织技术文档比埋头调参数更能提升你对“知识库质量”的敏感度。6. 实测中踩过的坑与排查手册最后这部分我把自己在真实项目中反复踩过的坑整理出来。如果你也遇到过“检索不到”“答非所问”“越跑越慢”这类问题可以直接对着排查。6.1 问不到东西多半不是模型笨是召回有问题最常见的故障是用户问了一个问题系统答“不知道”但你明明把相关文档灌进去了。这时候第一件事不是怀疑大模型而是去看检索阶段到底召回了什么。把召回的 chunk 打印出来逐条看相似度分数。如果分数都很低说明问题出在向量化或分块上可能是嵌入模型不支持特定术语的语义可能是文档格式比如扫描件没被正确解析也可能是分块把关键信息切碎了一块里既有“功能描述”又有“故障排查”检索时哪个都匹配不上。另一个隐蔽原因是查询改写没做好。用户问“这东西老断连怎么办”文档里写的是“Wi-Fi 连接不稳定的处理方法”两者措辞差距太大向量检索容易失配。我通常会在检索前加一个便宜的改写步骤让模型把用户问题改写成 3 个不同的表述再分别检索合并去重命中率提升非常明显。6.2 答非所问上下文噪声和截断在捣乱检索到了相关内容但答案还是满天飞这时候要看生成阶段。常见的原因有三类一是top_k 设得太大。5 个 chunk 里只有 1 个相关剩下 4 个全是噪声模型再聪明也会被带偏。解决方案是减小 top_k必要时加相似度阈值过滤低相关度内容。二是上下文顺序不对。把最相关的 chunk 放在提示词最前面能显著提高模型对重点信息的利用。很多框架默认按原始文档顺序拼接这并不利于生成。三是上下文被截断。长文档检索回来的 chunk 总 token 数超过模型上下文窗口框架就会从头截断很可能把最关键的内容裁掉。遇到这种情况优先减少 chunk 数量或缩短单块长度而不是硬塞进窗口。6.3 性能退化文档多了以后必须做的三件事本地 RAG 项目最容易遇到的问题就是文档量涨上去之后检索越来越慢、回答越来越飘。做三件事可以明显缓解第一给向量库建索引并定期清理重复内容。同一份文档被反复灌入或者第一次灌入后修改过又重新灌入会导致向量库里出现大量重复向量既拖慢检索又污染结果。我给团队定的规范是文档只从 Wiki 的指定目录同步有版本变更时先删旧再灌新。第二做集合/命名空间隔离。不同业务线的知识分开存储用户提问时先路由到对应集合而不是全库检索。这既提高命中率又降低检索耗时。第三给高频问题做缓存。把热门问答对直接缓存命中缓存时不再走 RAG 链路。在这个场景里RAG 的价值是“生成”缓存的价值是“复用”两者互补能够让高并发下的响应速度稳定下来。6.4 高频问题排查速查表现象可能原因排查方向检索相关片段分数始终很低嵌入模型不适配、文档解析出错换嵌入模型检查原始文档格式答案与文档矛盾上下文截断、噪声过多减小 top_k、控制 chunk 总长度包含图片/表格的问题答不准图文内容未处理OCR 描述文本入库表格整块保留文档更新后回答没变旧数据未清理删除对应集合重新灌入特定术语问题命中率低术语表缺失、查询改写不到位做术语归一化加查询改写响应越来越慢向量库膨胀、未分区清理重复向量、按业务隔离集合表格是速查不是万能药。实际排查时我的通用步骤永远是先打印检索结果再判断问题属于准备期、检索期还是生成期最后针对性改一个变量、跑一批样例验证。一次只改一个变量否则你永远不知道是哪个改动起的效果。我个人做了一年多 RAG 之后最大的体会是不要被“RAG 能解决一切知识问答”的错觉骗了。RAG 只是把“找答案”这件事从人的手里交给了算法而“长知识”这件事始终需要人用 Wiki 式的结构、规范和持续维护来保证质量。如果你正在搭自己的知识库问答系统我建议先把文档结构理清楚用 Wiki 的思路去写每一篇内容再动手建向量库调参数。顺序反了后面的一切努力都会被低质量的知识源拖垮。 RAG与Wiki：本地知识库问答的搭建、实战与进阶方向
“RAG 找答案Wiki 长知识”——这句话我在本地知识库项目里泡了快两年之后越来越觉得它是对整个领域最简洁也最准确的概括。今年我陆续搭了好几套基于 Ollama 的本地 RAG 问答系统也帮团队把几十份产品文档、技术资料和 SOP 搬进了 Wiki再用 RAG 把这些内容变成能回答问题的机器人。真正跑起来才发现很多人把 RAG 和 Wiki 当成同一种东西以为“只要有个知识库大模型就能答好”结果折腾几个星期答案不是凭空编造就是翻遍文档也找不着出处。这篇文章我不打算讲那种泛泛的概念介绍而是把“RAG 找答案”和“Wiki 长知识”这两件事掰开揉碎先搞清楚它们各管哪一环再给一套零基础能落地的本地 RAG 搭建流程接着聊聊 Agentic RAG、GraphRAG、Ontology RAG 这些热度一路走高的进阶玩法最后把我实测中踩过的坑和排查方法整理出来。不管你是在做企业知识库、个人笔记问答还是给开源项目做智能文档助手这篇内容应该都能让你少走不少弯路。1. 先把概念掰开RAG 管“找答案”Wiki 管“长知识”很多人一上来就想做“知识库问答”但“知识库”这三个字其实包含了两套完全不同的系统。一套是内容的生产与组织系统负责把零散信息变成结构化的、可追溯的、持续更新的知识资产典型形态就是 Wiki另一套是检索与生成系统负责在用户提问时快速找到相关片段并组织成有依据的回答典型形态就是 RAG。这两套系统互相依赖但绝不能混为一谈。1.1 RAG 是什么不是替代大模型是给大模型配一个资料库RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它解决的底层问题是大模型的知识是“练出来的”训练完成那一刻知识就冻结了既不知道你公司内部的新 SOP也不知道你最近更新的产品参数更不知道那些只存在于少数专家脑子里的经验。RAG 的思路非常朴素——既然模型不知道那就别让它硬答先从一个外部知识库里把相关资料“搜”出来再让模型基于这些资料作答。打个比方这就像一场开卷考试。大模型本身是那个记忆力不错、但课本版本过时的考生RAG 是那个负责翻资料找答案的助手Wiki 则是考场里允许你翻阅的参考书。没有参考书的开卷考试是伪开卷没有 RAG 的知识库也只是一堆躺在角落里没人看的文档。反过来如果参考书本身内容混乱、缺章少页助手再勤快也翻不出有用的东西。所以 RAG 的定位从来不是“替代大模型”而是“给大模型配一个可以实时翻看的资料库”。它的效果上限很大程度不取决于模型多聪明而取决于你喂给它的资料是什么、怎么组织、怎么检索。1.2 Wiki 是什么知识仓库不是答题器Wiki 的核心价值在于知识的结构化沉淀。一个合格的 Wiki 不只是几十个 Markdown 文件堆在一起它应该具备清晰的目录层级、稳定的命名规范、页面之间的交叉引用以及持续维护的版本记录。像很多开源项目用 Wiki 管理开发文档、硬件项目用 Wiki 记录编译烧录步骤本质上都是在做同一件事让知识从个人脑子里流动到团队层面并且随时能被找到、被更新、被校验。我见过不少团队做知识库的时候第一个动作就是把一堆 Word、PDF 拖进某个“AI 问答工具”里结果检索质量惨不忍睹。原因很简单那些原始文档很多是给“人读”而不是给“机器检索”写的结构混乱、术语不统一、重复内容遍地都是。Wiki 做的是另一件事——它先把这些内容重新组织成一个体系让每一条知识都有明确的归属、出处和上下文。做好了这些后面无论接 RAG 还是接别的什么检索方式效果都不会差。1.3 为什么说这两个能力必须分开建设把 RAG 和 Wiki 分开建设不是因为它们不能整合而是因为它们的维护节奏和评价标准完全不同。Wiki 是一个“慢系统”。它的内容是积累出来的需要人来写、来审、来更新。评价一个 Wiki 做得好不好看的是知识是否齐全、是否最新、导航是否顺畅。RAG 则是一个“快系统”。它要在用户提问的几百毫秒内完成检索和生成。评价一个 RAG 系统好不好看的是命中率hit rate、回答的准确性和引用的可溯源性。如果你把这两件事混在一起比如直接在聊天工具里让团队成员往某个数据库里扔文档然后指望 AI 自动整理成一个好 Wiki大概率会得到一个“既不像知识库、也答不准问题”的四不像。正确做法是先用 Wiki 把知识结构立起来再基于这个结构做 RAGRAG 回答得不好时回头去改 Wiki 的内容质量而不是盲目换模型、调参数。2. 一条 RAG 问答链路是怎么跑通的想把 RAG 玩明白必须先完整理解一条问答链路上每个环节在做什么。很多人在检索结果不理想时上来就调 embedding 模型、调相似度算法其实问题往往出在最前面的文档处理阶段。2.1 三个阶段准备期、检索期、生成期一条完整的 RAG 链路可以分成三个阶段。准备期是把知识文档切分为小块chunk、计算向量embedding、存入向量数据库的过程。这个阶段决定了系统“知道什么”。检索期是用户提问后把问题转成向量、在向量库里做相似度检索、取出最相关的若干文档片段的过程。这个阶段决定了系统“能想起什么”。生成期是把检回来的片段和用户问题一起拼进提示词交给大模型生成回答的过程。这个阶段决定了系统“怎么说”。这三个阶段环环相扣但经常被忽略的是每个阶段都有自己的成功标准。准备期看的是“切块是否合理、向量能否表达语义”检索期看的是“相关片段有没有被召回”生成期看的是“回答是否忠实于检索内容”。排查问题时先定位是哪一段坏了比盲目重试有用得多。2.2 分块和嵌入是质量地基分块chunking是整个 RAG 里最不起眼、但影响最大的环节。块切得太小比如一句话一个块检索时可能会切断上下文模型拿到的片段语义不完整块切得太大比如一整页一个块检索时噪声会很多还会快速撑爆上下文窗口导致答案被无关细节淹没。我的实践经验是中文场景下chunk_size 通常取 200 到 400 个 tokenoverlap 取 10% 到 20%。overlap 的作用是让相邻块之间保留重叠信息避免一个完整段落恰好被从中间切开的尴尬。英文文档可以适当放大到 400 到 500 token因为英文的语义边界更清晰。但这只是起点不同文档类型差异很大——代码类文档要把函数定义和注释放在同一块表格类文档则要尽量整表保留。嵌入embedding模型的选择同样关键。本地场景中我比较常用的是 bge-m3、m3e 这类开源中文嵌入模型对中文语义的支持比通用英文模型好不少。判断一个嵌入模型合不合适不要只看某个公开榜单最好拿你自己的真实文档跑一批样例问题看看召回的片段是不是你真的需要的。换嵌入模型比换大模型对 RAG 效果的提升通常更明显这个我实测过很多次。2.3 RAG 能存图片吗多模态知识库的现状很多人问我“RAG 知识库能不能直接存图片”包括网上搜这个问题的人也非常多。直接回答传统 RAG 不能因为标准 RAG 链路处理的是文本和向量图片本身无法直接参与相似度检索。但这不意味着知识库里的图片只能被丢弃。目前比较务实的做法有三条路径。第一OCR 把图片里的文字抽出来图片转成文本块参与向量化原始图片作为附件挂在该文本块的上下文里用户提问时模型可以看到图片路径甚至被引用的图片。第二生成图片的文字描述用多模态模型给每张图片写一段说明文字描述入库图片本身存附件。第三直接上多模态 embedding 模型比如 CLIP 类模型图片和文本都映射到同一个向量空间可以做到“以图搜图、以文搜图、以图搜文”但本地部署成本高对硬件要求也高。我的建议是除非你的知识库中有大量“看图才能懂”的内容否则先走 OCR 文字描述入库最划算。把 attention 花在核心问答质量上不要让多模态炫技拖慢整个项目。3. 零基础也能复制的本地 RAG 搭建方案网上搜“rag 实战”“rag 教程”能搜到一大堆方案但很多一上来就上 LangChain OpenAI API要么付费、要么依赖在线服务。这里我分享一套完全本地跑的方案用的全是开源工具零基础也能照着复现。热词里那篇“Ollama 简易本地 RAG 知识库【零基础可复制教程】”走的也是同一个方向。3.1 工具选型Ollama、嵌入模型、向量库、编排框架怎么挑完整的本地 RAG 栈通常有四层模型层用 Ollama 跑本地大模型和嵌入模型。大模型推荐 qwen2.5 系列或 llama3.1 系列嵌入模型推荐 bge-m3。嵌入与向量层负责把文本变成向量、存进向量库。入门用 ChromaDB 最省心数据量大了换 Qdrant再大换 Milvus。编排层负责把“检索 拼提示词 生成”串起来。Python 生态用 LangChain 或 LlamaIndexJava 生态用 LangChain4j热词里的“langchain4j easy rag”就是这个方向不想写代码的可以用 Dify 或 FastGPT。知识源层就是你要灌进去的文档最好先整理成 Wiki 形态。选型逻辑很简单先看你想花多少精力维护再看你要处理多少文档。一个人做个人知识库ChromaDB LangChain 就够用几十个人协作的企业知识库建议上 Qdrant 和正式的 Wiki 系统如果用户提问模式高度固定、不需要复杂 Agent 能力甚至可以不用 LangChain手写一个 50 行的 Python 脚本也能跑通 RAG。3.2 从安装到跑通第一个问答以最简方案为例假设你已经装了 Ollama。第一步先拉模型# 拉一个大模型用于生成回答 ollama pull qwen2.5:7b # 拉一个嵌入模型用于把文档转成向量 ollama pull bge-m3然后安装 Python 依赖pip install langchain langchain-community chromadb接着用一个简单的 Python 脚本完成“建知识库 问答”全流程from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.llms import Ollama from langchain.chains import RetrievalQA from langchain_community.document_loaders import DirectoryLoader # 1. 加载文档 loader DirectoryLoader(./docs, glob**/*.md) documents loader.load() # 2. 分块 splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50, ) chunks splitter.split_documents(documents) # 3. 向量化并存入 Chroma embeddings OllamaEmbeddings(modelbge-m3) vectordb Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) # 4. 构建检索问答 qa RetrievalQA.from_chain_type( llmOllama(modelqwen2.5:7b), retrievervectordb.as_retriever(search_kwargs{k: 4}), ) # 5. 提问 answer qa.invoke(如何配置设备的网络参数) print(answer[result])这套流程跑通后你就拥有了一个完整的本地 RAG 雏形。注意.invoke()返回的结果包含“检索到的文档片段 生成答案”两部分一定要养成查看检索片段source chunks的习惯因为答案质量好坏80% 在检索这一步就已经定型了。3.3 调好这些参数命中率hit rate才会上去RAG 领域有个词叫 hit rate命中率衡量的是“真实相关的文档片段有多大比例被检索出来了”。很多项目上线后效果不好第一件事不是换模型而是看 hit rate 有没有达标。提升 hit rate 主要有五个抓手chunk_size 和 chunk_overlap太小丢上下文太大引噪声按上一节建议起步再根据你的文档类型微调。检索的 top_k通常 4 到 10 之间。太小可能漏掉正确答案太大则会在生成时混入大量无关信息。相似度阈值如果检索出来的 top_k 片段的相似度分数都在及格线以下说明知识库里可能根本没有相关内容这时宁可让模型说“我不确定”也不要强答。查询改写query rewrite用户口语化的问题往往和文档里的术语不一致。先让大模型把问题改写成几个与文档风格匹配的子问题再分别检索能明显提高召回质量。重排rerank向量检索的初排结果不一定准确加一个重排模型对 top_k 候选重新打分效果立竿见影但会增加延迟和计算量。还有一个常被忽略的细节你的问题示例要和嵌入模型的能力匹配。如果嵌入模型是中文优化的而你的文档大量使用英文缩写和专业术语最好先做术语表归一化否则“Wi-Fi”和“wifi”“无线网络”会被当成完全不相干的向量。4. 热度很高但容易被误用的三个进阶方向网上搜 RAG 相关热词Agentic RAG、GraphRAG、Ontology RAG 这三个词出现频率极高。它们确实代表了 RAG 从“一把梭”走向精细化的发展方向但很多人还没搞清它们的适用边界就直接上结果项目成本暴涨、收益寥寥。4.1 Agentic RAG从单向问答变成多轮决策普通 RAG 是“提问一次、检索一次、生成一次”的固定流程。Agentic RAG 则把大模型变成一个智能体Agent它可以根据当前答案是否充分决定是继续检索、改写问题再去检索还是直接调用某个工具比如查数据库、执行代码来补充信息。典型的应用场景是用户问“公司过去三个月出货量下降的原因是什么”这既需要检索销售分析文档又可能需要从数据库里拉实时数据还可能要看历史对比报告。单个 RAG 流程很难在一次检索里全部覆盖但 Agent 可以自己规划“先查实时数据再检索分析文档提到的原因最后组织回答。”这种灵活性是传统 RAG 给不了的。但我要提醒一点Agentic RAG 意味着更多的模型调用次数和更长的耗时也就意味着更高的失败点和成本。如果你的场景只是固定知识库问答不需要多步推理和工具调用千万不要为了追热点硬上 Agent 架构。4.2 GraphRAG擅长回答那些“打通整个库”的问题GraphRAG 的思路是先对文档做实体和关系抽取构建一张知识图谱回答问题时先在图谱上做多跳检索比如“A 公司的供应商 BB 的子公司 C 又供应了 D 产品”再把图上的相关子图喂给大模型。普通 RAG 擅长回答“这个设备怎么配置”GraphRAG 更擅长回答“整个系统里哪些环节会互相影响”。微软的 GraphRAG 开源项目带火了这个方向但代价是索引阶段的计算量非常大而且实体抽取质量直接影响后续所有检索效果。我的建议是只在你的知识库确实需要多跳关系推理时再用 GraphRAG比如技术架构分析、业务流程梳理、知识图谱问答。纯文档问答用传统 RAG 就好。4.3 Ontology RAG用结构化本体把提问约束在专业语境里Ontology RAG 是在知识库之上再加一层“本体”——一套明确定义的概念、属性和关系体系。比如做设备维修知识库本体里定义了“设备型号”“故障现象”“维修步骤”“备件信息”以及它们之间的关系。用户提问“设备无故重启怎么办”系统不会满库乱搜而是先映射到“设备型号”和“故障现象”两个本体概念再定向检索相关维修记录。这是我很看好的一个方向尤其适合垂直领域。它解决的是 RAG 的一大隐患自然语言提问太发散导致检索结果不可控。有了本体约束检索范围被规范到领域语义空间里hit rate 会稳定很多。但它的建设成本也最高因为本体本身需要领域专家梳理维护起来比普通 Wiki 文档费劲得多。这三个方向不是替代关系而是递进关系普通 RAG 能解决了 80% 的问题剩下的 20% 才需要根据具体瓶颈选择 Agentic、Graph 或 Ontology。5. Wiki 内容怎么组织RAG 效果才会好前面我说“Wiki 长知识”是 RAG 的地基这里展开讲怎么让这个地基真的撑得住检索。很多人把 Wiki 当成了一个简单的文档存储空间这样接 RAG 效果自然有限。真正的 Wiki 式内容组织应该直接服务于检索策略。5.1 文档结构段落、标题、双向链接都是检索线索Wiki 的页面结构对 RAG 检索质量的影响比大多数人想象中更大。我建议每个知识页面遵循一个固定模板开头是 3 到 5 句话的摘要正文按“背景 / 操作步骤 / 注意事项 / 常见问题”分节结尾统一添加相关术语链接。这样做的好处是摘要部分本身就是一个高质量的“可检索摘要”用户问题与摘要的语义匹配度远高于正文里的长段落分节后的内容天然适合做分块边界每块的语义都相对完整链接则是隐式的关系线索你甚至可以把 Wiki 里的 [[互链]] 当成本体关系后面接 GraphRAG 时能省不少抽取工作。标题也要注意。别写“配置说明”“问题记录”这种模糊标题改成“如何配置静态 IP 地址”“设备重启后无法连接网络的排查记录”。因为检索时标题往往会被加权一个语义明确的标题能在不增加 token 的情况下显著提升命中率。5.2 图文混排内容的处理OCR、描述与附件知识库里总有大量图文混排的内容比如软件截图、流程图、表格。处理这些内容有一套固定打法Markdown 文档里保留原始表格图片统一存到同目录的 assets 文件夹正文中用相对路径引用另在文本说明中写清图片内容的关键信息。表格是最容易在 RAG 里翻车的类型。切块时如果表格被拆成多段文本模型根本看不懂行列关系。我的做法是小表格整个放一个块里大表格拆分成“表头 若干行组”并用描述性文字包裹让模型知道这是一张表格。图片的处理我在第 2.3 节说过OCR 或描述文本入库原图作为附件挂载。这些准备工作做足了用户提问“看下这张截图里的告警信息”时系统才有机会把图片和对应文本一起拿出来。5.3 用游戏 Wiki 和开源项目 Wiki 找灵感Wiki RAG 不仅适用于企业知识库很多现成的优秀案例反而来自游戏和开源社区。比如英灵神殿Valheim的 Wiki把每种材料、装备合成路径、BOSS 掉落整理成了结构化页面有人拿这套 Wiki 配合 RAG 做游戏问答助手问“做个铁斧需要什么材料”能直接给出一串合成步骤。这说明什么说明 Wiki 内容质量够高的时候RAG 只是最后一步的“外挂”。开源项目里像 ESP32 摄像头二维码识别项目、ChameleonUltra 这类硬件项目也都在用 Wiki 沉淀编译步骤、硬件配置和排错指南。对这些项目的作者来说Wiki 不只是给人看的文档更是未来训练 AI 问答机器人的语料库。玩 RAG 的人不妨多逛逛这些开源 Wiki研究别人怎么组织技术文档比埋头调参数更能提升你对“知识库质量”的敏感度。6. 实测中踩过的坑与排查手册最后这部分我把自己在真实项目中反复踩过的坑整理出来。如果你也遇到过“检索不到”“答非所问”“越跑越慢”这类问题可以直接对着排查。6.1 问不到东西多半不是模型笨是召回有问题最常见的故障是用户问了一个问题系统答“不知道”但你明明把相关文档灌进去了。这时候第一件事不是怀疑大模型而是去看检索阶段到底召回了什么。把召回的 chunk 打印出来逐条看相似度分数。如果分数都很低说明问题出在向量化或分块上可能是嵌入模型不支持特定术语的语义可能是文档格式比如扫描件没被正确解析也可能是分块把关键信息切碎了一块里既有“功能描述”又有“故障排查”检索时哪个都匹配不上。另一个隐蔽原因是查询改写没做好。用户问“这东西老断连怎么办”文档里写的是“Wi-Fi 连接不稳定的处理方法”两者措辞差距太大向量检索容易失配。我通常会在检索前加一个便宜的改写步骤让模型把用户问题改写成 3 个不同的表述再分别检索合并去重命中率提升非常明显。6.2 答非所问上下文噪声和截断在捣乱检索到了相关内容但答案还是满天飞这时候要看生成阶段。常见的原因有三类一是top_k 设得太大。5 个 chunk 里只有 1 个相关剩下 4 个全是噪声模型再聪明也会被带偏。解决方案是减小 top_k必要时加相似度阈值过滤低相关度内容。二是上下文顺序不对。把最相关的 chunk 放在提示词最前面能显著提高模型对重点信息的利用。很多框架默认按原始文档顺序拼接这并不利于生成。三是上下文被截断。长文档检索回来的 chunk 总 token 数超过模型上下文窗口框架就会从头截断很可能把最关键的内容裁掉。遇到这种情况优先减少 chunk 数量或缩短单块长度而不是硬塞进窗口。6.3 性能退化文档多了以后必须做的三件事本地 RAG 项目最容易遇到的问题就是文档量涨上去之后检索越来越慢、回答越来越飘。做三件事可以明显缓解第一给向量库建索引并定期清理重复内容。同一份文档被反复灌入或者第一次灌入后修改过又重新灌入会导致向量库里出现大量重复向量既拖慢检索又污染结果。我给团队定的规范是文档只从 Wiki 的指定目录同步有版本变更时先删旧再灌新。第二做集合/命名空间隔离。不同业务线的知识分开存储用户提问时先路由到对应集合而不是全库检索。这既提高命中率又降低检索耗时。第三给高频问题做缓存。把热门问答对直接缓存命中缓存时不再走 RAG 链路。在这个场景里RAG 的价值是“生成”缓存的价值是“复用”两者互补能够让高并发下的响应速度稳定下来。6.4 高频问题排查速查表现象可能原因排查方向检索相关片段分数始终很低嵌入模型不适配、文档解析出错换嵌入模型检查原始文档格式答案与文档矛盾上下文截断、噪声过多减小 top_k、控制 chunk 总长度包含图片/表格的问题答不准图文内容未处理OCR 描述文本入库表格整块保留文档更新后回答没变旧数据未清理删除对应集合重新灌入特定术语问题命中率低术语表缺失、查询改写不到位做术语归一化加查询改写响应越来越慢向量库膨胀、未分区清理重复向量、按业务隔离集合表格是速查不是万能药。实际排查时我的通用步骤永远是先打印检索结果再判断问题属于准备期、检索期还是生成期最后针对性改一个变量、跑一批样例验证。一次只改一个变量否则你永远不知道是哪个改动起的效果。我个人做了一年多 RAG 之后最大的体会是不要被“RAG 能解决一切知识问答”的错觉骗了。RAG 只是把“找答案”这件事从人的手里交给了算法而“长知识”这件事始终需要人用 Wiki 式的结构、规范和持续维护来保证质量。如果你正在搭自己的知识库问答系统我建议先把文档结构理清楚用 Wiki 的思路去写每一篇内容再动手建向量库调参数。顺序反了后面的一切努力都会被低质量的知识源拖垮。