RAG教程：从零搭建本地知识库问答系统，告别大模型幻觉与知识过时

1.1 RAG是什么：解决大模型幻觉、知识过时与私有数据问答的核心思路

我第一次认真琢磨RAG这个东西，是因为被大模型“一本正经胡说八道”坑过好几次。问它某个内部项目的接口文档，它能编出一套看似合理实则完全不存在的方法名，还贴心地配上了示例代码。后来我才明白，大模型本质上是个概率机器，它的知识冻结在训练数据的那一刻，对于训练时没见过的东西，它只能靠“猜”。这种猜有时候很准，有时候离谱得让人哭笑不得。

RAG全称Retrieval-Augmented Generation，中文叫检索增强生成。这个词拆开看就很直白，检索加生成。思路也简单——别让模型光靠记忆回答问题，先帮它去知识库里找相关资料，再把找到的内容塞进提示词里，让它照着材料说话。我自己的体会是，这相当于给模型配了个随身图书馆，它不需要把所有知识都背下来，只需要学会怎么查、怎么用。

这套思路能同时解决三个让人头疼的问题。幻觉问题靠“有据可依”来压制，模型看到的是实际检索出来的文本，编造空间小了很多。知识过时问题靠“实时检索”来规避，资料更新了，检索结果就更新了，不用重新训练模型。私有数据问答靠“外挂知识库”来实现，公司内部的文档、数据库、工单记录，不需要喂给模型训练，检索时能找到就行。我后来做项目时深深感受到，RAG最大的价值不是让模型变聪明，而是让它变得“可靠”——知道什么该说，什么不该说。

1.2 RAG与微调、长上下文、搜索增强的对比及适用场景

刚接触RAG那会儿，我特别容易把它和微调搞混。两个都是为了解决模型知识不足的问题，路线完全不同。微调是让模型重新学习，把新知识“焊”进参数里，成本高、周期长，数据一更新就得再来一遍。RAG是让模型学会查阅资料，知识放在外部，随时可换。我个人的经验是，如果任务涉及风格迁移、格式对齐、特定领域的语言习惯，微调更合适；如果任务需要频繁更新知识、要求答案可溯源，RAG是更务实的选择。

长上下文能力这几年进步很快，有些模型能直接吞下几十万字的文档。我一开始也想过，既然模型能读这么长的内容，是不是直接把全部资料塞进去就完事了？实测下来问题不少。上下文越长，注意力越容易涣散，关键信息淹没在噪声里，模型反而抓不住重点。成本也是实打实的，每次请求都处理海量token，账单会让人清醒。RAG的检索环节本质上是在做信息筛选，把最相关的内容挑出来，让模型在有限的上下文里聚焦。

搜索增强这个词有时候会和RAG混用，我更愿意把它们看作不同层次的东西。传统搜索增强偏向关键词匹配和排序，返回的是链接列表。RAG把检索结果直接喂给生成模型，让模型消化后输出自然语言答案。这个区别决定了RAG更适合问答式交互，搜索增强更适合信息发现。我现在的判断标准很简单——用户想要一个直接答案，上RAG；用户想自己浏览筛选，传统搜索够用。

1.3 RAG标准流水线：文档加载、文本切分、向量化、存储、检索、重排与生成

把RAG拆成流水线来看，每个环节都有坑，也都有优化空间。文档加载是第一步，听起来简单，做起来琐碎。PDF里的表格、扫描件的OCR、网页的正文提取、Markdown的层级结构，每种格式都有自己的脾气。我记得处理过一批产品手册，PDF里全是双栏排版，直接抽取文字后顺序全乱，读起来像乱码。后来老老实实上了版面分析工具才解决。

文本切分是我踩坑最多的地方。切得太碎，语义不完整，检索出来的片段缺少上下文；切得太粗，噪声太多，模型容易被无关信息干扰。我试过固定长度切分，也试过按标点、按章节、按语义切分。现在的习惯是先用递归切分保底，再根据文档结构做定制化处理。代码文档按函数切，法律合同按条款切，聊天记录按对话轮次切，效果比一刀切好很多。

向量化、存储、检索这三个环节连在一起说。向量化是把文本变成一串数字，让语义相近的内容在向量空间里距离更近。Embedding模型的选择直接影响检索效果，开源的有BGE、M3E，闭源的有OpenAI的text-embedding系列。我通常先用小规模数据对比几个模型，看哪个在自己场景下召回更准。存储用向量数据库，FAISS、Chroma、Milvus、Qdrant都用过，本地测试FAISS最轻便，生产环境Milvus和Qdrant的分布式能力更省心。

重排和生成是最后两步。检索回来的Top-K结果按相似度排序，但向量相似度高不代表对回答最有帮助。重排模型用交叉编码器对候选片段重新打分，把真正相关的往前排。我做过对比实验，加上重排后答案准确率能提升一截。生成环节就是把重排后的上下文和用户问题一起塞进提示词，让模型组织语言输出答案。这一步的提示词设计很讲究，后面会单独聊。

1.4 检索质量关键：分块策略、Embedding选择、相似度度量与Top-K调优

分块策略这件事，我现在的理解是没有万能方案，只有针对场景的权衡。固定长度切分实现简单，适合快速验证。按语义切分依赖模型判断句子边界，质量高但计算开销大。滑动窗口在块之间保留重叠，缓解语义断裂问题。我常用的组合是递归字符切分加段落感知，优先在段落边界断开，段落太长再按句子切，句子还长才硬切。

Embedding选择上，我走过一段弯路。一开始迷信排行榜，哪个模型在MTEB榜单上分数高就用哪个。实际用起来发现，榜单分数和业务效果不完全对等。中文场景下，BGE系列和M3E表现稳定；多语言场景，paraphrase-multilingual系列更均衡；如果预算充足，OpenAI的text-embedding-3-large确实省心。我的做法是准备一批标注好的问答对，拿几个候选模型跑召回率，用数据说话。

相似度度量常见的有余弦相似度、点积、欧氏距离。文本Embedding通常做归一化，归一化后余弦相似度和点积等价。我习惯用余弦相似度，数值范围直观，容易设阈值。Top-K调优是个经验活，K太小召回不足，K太大引入噪声。我一般先设K=10做基线，看命中率和答案质量，再往上加。加了重排之后，可以适当放大初始检索的K，比如20到50，让重排模型有更多选择余地。

1.5 Prompt设计与上下文组织：让模型基于检索结果回答并抑制幻觉

提示词设计是我认为RAG里最像“手艺活”的部分。同样一批检索结果，提示词写得好，答案精准且有引用；写得差，模型要么忽略材料自己编，要么被无关片段带偏。我总结了几条实用原则。明确告诉模型“只根据提供的上下文回答”，这条能大幅减少幻觉。要求模型在答案里标注引用来源，比如“根据文档A第3段”，方便人工核查。

上下文组织也有讲究。检索回来的片段不能一股脑全塞进去，顺序会影响模型注意力。我通常把最相关的放最前面，次相关的放最后面，中间放补充信息。片段之间加分隔符和来源标识，比如用“---”隔开，每段前面写上文档名。如果片段太长，可以做摘要压缩，或者只保留与问题最相关的句子。我试过把检索结果按相关度分组，高相关的详细呈现，低相关的只给标题，模型反而抓重点更准。

还有个小技巧是给模型“退路”。提示词里加一句“如果上下文中没有足够信息，请直接说不知道”，比硬逼着它回答要安全得多。我在内部问答系统里加了这条之后，用户反馈“胡编乱造”的情况少了很多。模型不是万能的，让它承认无知比让它假装全知更负责任。

1.6 最小RAG实战：用Python读取本地文档并完成一次问答

理论说了一堆，跑通一个最小系统才算真正入门。我带过几个新人，发现他们卡住的地方往往不是原理，而是环境配置和代码串联。这里给一个最简版本，用Python加FAISS加OpenAI兼容接口，本地文档问答跑起来。

先准备依赖。pip install langchain langchain-community faiss-cpu openai tiktoken，这几个包够用了。文档放在一个文件夹里，支持txt和md就行。读取用TextLoader或DirectoryLoader，切分用RecursiveCharacterTextSplitter，chunk_size设500，overlap设50。Embedding用OpenAIEmbeddings或者本地的HuggingFaceEmbeddings，存进FAISS向量库。

检索器用vectorstore.as_retriever()，设search_kwargs={"k": 5}。提示词模板长这样：

根据以下上下文回答问题。如果上下文没有相关信息，请回答“我不知道”。

上下文：
{context}

问题：{question}
答案：

链式调用用RetrievalQA.from_chain_type，把LLM、retriever、prompt串起来。跑一个qa_chain.invoke({"query": "你的问题"})，就能看到基于本地文档的回答。我建议第一次跑通后，故意问一个文档里没有的问题，看模型是不是老实说“不知道”。这个测试比问对问题更能验证系统是否可靠。

代码跑通只是起点。我通常会加日志，把每次检索到的片段和最终答案都记下来。回头分析哪些片段被用了，哪些被忽略了，对调优分块和提示词特别有帮助。

1.7 从入门到实战的评估闭环：命中率、忠实度、答案相关性、延迟与成本

RAG系统不评估就是盲人摸象。我见过太多项目，demo阶段效果惊艳，上线后问题百出，就是因为没有建立评估闭环。评估指标我分四类看。检索侧看命中率，标准问题对应的文档片段有没有出现在Top-K里。生成侧看忠实度，答案里的每句话是不是都能在检索结果里找到依据。答案相关性衡量回答是否切题，有没有答非所问。工程侧看延迟和成本，响应时间用户能不能接受，每次调用的token消耗划不划算。

评估数据准备是个体力活，但值得投入。我通常从真实用户问题里采样，人工标注每个问题的标准答案和对应文档片段。数量不用多，几十到一百条就能看出趋势。跑评估时，检索命中率用程序自动算，忠实度和相关性可以用另一个LLM做裁判，也可以人工抽检。我习惯两者结合，程序跑全量，人工看bad case。

延迟和成本容易被忽视。检索加生成，端到端延迟超过3秒用户就会烦躁。优化手段包括向量索引调参、缓存高频问题、异步处理、模型蒸馏。成本方面，Embedding调用和LLM调用是大头，能本地化的尽量本地化，能缓存的绝不重复计算。我现在的习惯是每次迭代都记录这三个数字：平均延迟、每次查询成本、用户满意度。数字不会骗人，比感觉靠谱多了。

评估闭环建立起来之后，RAG系统的迭代就有了方向。分块策略改了，看命中率变化；提示词调了，看忠实度波动；换了Embedding模型，看综合指标。没有评估，调优就是碰运气。有了评估，每一步都踩在实处。