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 把知识结构立起来，再基于这个结构做 RAG；RAG 回答得不好时，回头去改 Wiki 的内容质量，而不是盲目换模型、调参数。

2. 一条 RAG 问答链路是怎么跑通的

想把 RAG 玩明白，必须先完整理解一条问答链路上每个环节在做什么。很多人在检索结果不理想时上来就调 embedding 模型、调相似度算法，其实问题往往出在最前面的文档处理阶段。

2.1 三个阶段：准备期、检索期、生成期

一条完整的 RAG 链路可以分成三个阶段。

准备期是把知识文档切分为小块（chunk）、计算向量（embedding）、存入向量数据库的过程。这个阶段决定了系统“知道什么”。

检索期是用户提问后，把问题转成向量、在向量库里做相似度检索、取出最相关的若干文档片段的过程。这个阶段决定了系统“能想起什么”。

生成期是把检回来的片段和用户问题一起拼进提示词，交给大模型生成回答的过程。这个阶段决定了系统“怎么说”。

这三个阶段环环相扣，但经常被忽略的是：每个阶段都有自己的成功标准。准备期看的是“切块是否合理、向量能否表达语义”，检索期看的是“相关片段有没有被召回”，生成期看的是“回答是否忠实于检索内容”。排查问题时先定位是哪一段坏了，比盲目重试有用得多。

2.2 分块和嵌入是质量地基

分块（chunking）是整个 RAG 里最不起眼、但影响最大的环节。块切得太小，比如一句话一个块，检索时可能会切断上下文，模型拿到的片段语义不完整；块切得太大，比如一整页一个块，检索时噪声会很多，还会快速撑爆上下文窗口，导致答案被无关细节淹没。

我的实践经验是：中文场景下，chunk_size 通常取 200 到 400 个 token，overlap 取 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 或 LlamaIndex，Java 生态用 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_size=300, chunk_overlap=50, ) chunks = splitter.split_documents(documents) # 3. 向量化并存入 Chroma embeddings = OllamaEmbeddings(model="bge-m3") vectordb = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db") # 4. 构建检索问答 qa = RetrievalQA.from_chain_type( llm=Ollama(model="qwen2.5:7b"), retriever=vectordb.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 公司的供应商 B，B 的子公司 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 高频问题排查速查表

表格是速查，不是万能药。实际排查时，我的通用步骤永远是：先打印检索结果，再判断问题属于准备期、检索期还是生成期，最后针对性改一个变量、跑一批样例验证。一次只改一个变量，否则你永远不知道是哪个改动起的效果。

我个人做了一年多 RAG 之后最大的体会是：不要被“RAG 能解决一切知识问答”的错觉骗了。RAG 只是把“找答案”这件事从人的手里交给了算法，而“长知识”这件事，始终需要人用 Wiki 式的结构、规范和持续维护来保证质量。如果你正在搭自己的知识库问答系统，我建议先把文档结构理清楚，用 Wiki 的思路去写每一篇内容，再动手建向量库调参数。顺序反了，后面的一切努力都会被低质量的知识源拖垮。