1. 从“大模型胡说八道”说起RAG到底在解决什么问题如果你用过任何一款大语言模型大概率遇到过这种场景问它一个公司内部才有的业务规则它一本正经地编出一套看似合理但完全错误的答案或者问它某个产品的具体参数它给出的数字和官方文档对不上。这不是模型“笨”而是它的知识边界问题——模型的知识全部来自训练时喂进去的数据训练完成之后发生的事情、你私有的文档、你数据库里的记录它一概不知道。RAGRetrieval-Augmented Generation检索增强生成就是冲着这个痛点来的。它的核心思路非常朴素既然模型不知道那就在它回答问题之前先去外部知识库里把相关内容找出来塞进提示词里让模型“看着材料答题”。这就像开卷考试和闭卷考试的区别——闭卷考试靠记忆记错了就答错开卷考试允许你翻书翻到相关章节再组织答案准确率自然高出一截。我最初接触RAG是在一个内部知识问答的场景里。当时团队积累了几百份技术文档和会议纪要大家查资料全靠关键词搜索加人工翻找效率极低。尝试直接让模型回答结果它把几个不同项目的配置参数混在一起差点导致一次线上事故。从那以后我就意识到在严肃场景下纯生成式模型不可靠必须给它接上“事实来源”。RAG就是那个事实来源的接入管道。这篇文章适合谁看如果你是刚听说RAG想搞明白它到底怎么运转的开发者或者已经跑过Demo但效果不理想、想搞清楚哪里出了问题的实践者再或者你是技术负责人需要评估RAG方案是否适合当前业务下面的内容都会覆盖到。我会从架构拆解讲到每个环节的实操细节把踩过的坑和验证过的方案都摊开来说。2. RAG的完整链路拆解每个环节都在决定最终效果很多人以为RAG就是“向量数据库大模型”两件事实际上从用户输入问题到拿到答案中间至少经过六个环节每个环节都有各自的坑。下面这张表是我在实际项目中总结的链路全景先建立一个整体认知。环节核心任务常见问题影响程度文档加载把各种格式的原始资料读进来格式解析错误、表格丢失中文本切分把长文档切成合适大小的块切得太碎丢上下文切太大引入噪声高向量化把文本块转成向量存起来模型选型不当、维度不匹配高检索根据问题找出最相关的块召回不准、漏掉关键信息极高重排序对检索结果做二次筛选排序不合理导致噪声进上下文中高生成把检索结果和问题一起给模型提示词设计差、模型忽略材料高2.1 文档加载别小看“读文件”这件事文档加载看起来最简单实际上是最容易被低估的环节。你的知识库可能包含PDF、Word、Markdown、HTML、Excel甚至扫描件不同格式的解析质量天差地别。我踩过最典型的一个坑是一份产品规格书是PDF里面关键参数放在表格里用常规的PDF文本提取工具读出来之后表格结构完全丢失所有数字挤成一团后续检索根本没法用。针对这个问题我的经验是分类型处理。纯文本类的Markdown和TXT直接读没问题PDF如果包含复杂表格要么用支持版面分析的工具提取要么在入库前人工把关键表格转成结构化文本扫描件必须先做OCR而且OCR之后要人工抽检确认关键数字没有识别错误。这一步偷懒后面所有环节都是白费。还有一个细节元数据一定要保留。每份文档的来源、标题、创建时间、所属分类这些信息在检索时可以作为过滤条件。比如用户问“最新的部署流程”你可以先按时间过滤掉过期的文档再在有效文档里做语义检索准确率会明显提升。2.2 文本切分切得好不好直接决定检索质量文本切分是RAG里最需要“手感”的环节。切得太碎每个块只有一两句话检索时可能命中但缺乏上下文模型拿到手也不知道前因后果切得太大一个块里混了好几个主题检索时引入大量无关噪声模型容易被带偏。我试过几种策略最终稳定下来的是递归字符切分配合重叠窗口。具体做法是优先按段落切段落太长再按句子切句子还长就按字符数硬切。每个块的大小控制在300到500个中文字符块与块之间保留50到80字的overlap。这个overlap很关键它保证了一个完整意思被切断时前后两块都包含过渡信息检索时不会因为边界问题漏掉关键内容。注意切分参数没有万能值。技术文档适合按章节结构切对话记录适合按轮次切法律合同适合按条款切。一定要根据你的文档类型做针对性调整不要一套参数打天下。另外我强烈建议在切分时给每个块加上上下文前缀。比如一个块讲的是“配置超时时间”但原文里这个块前面有“在数据库连接池设置中”这个限定如果切分时丢掉了检索“连接池超时”就可能匹配不上。我的做法是在每个块开头拼接它所属的章节标题或上级标题相当于给块加了一个“地址标签”。2.3 向量化与存储模型选型不是越贵越好向量化就是把文本块转成高维向量让语义相近的文本在向量空间里距离更近。这里涉及两个选择用什么嵌入模型以及用什么向量数据库。嵌入模型方面我的实测经验是中文场景下专门针对中文优化的模型明显优于通用多语言模型。早期我用一个通用模型做中文技术文档检索发现“接口超时”和“请求延迟”这种语义相近的词向量距离居然比较远导致召回率不理想。换成中文优化模型后这类问题大幅减少。选型时不要只看榜单分数一定要用你自己的业务数据做小规模测试看实际召回效果。向量数据库的选择取决于数据规模和部署条件。数据量在十万条以内用本地文件型方案就够部署简单、零运维百万级以上考虑服务型数据库支持分布式和水平扩展。我个人的建议是初期不要过度设计先用最简单的方案跑通全流程等数据量真的上来了再迁移迁移成本远低于一开始就搭复杂架构的维护成本。2.4 检索策略单一向量检索远远不够这是我想重点讲的部分因为大部分RAG效果不好的根源都在检索环节。纯向量检索有一个天然缺陷它擅长语义匹配但对精确关键词不敏感。比如用户问“错误码E5021怎么解决”向量检索可能返回一堆讲“常见错误处理”的文档但就是漏掉了那个专门讲E5021的块因为“E5021”这个精确字符串在向量空间里没有特殊优势。我的解决方案是混合检索向量检索和关键词检索同时跑然后合并结果。关键词检索用BM25这类经典算法对精确匹配非常有效。两路结果合并时可以用加权分数或者倒数排名融合RRF来排序。实测下来混合检索比单一向量检索的召回率提升非常明显尤其是在包含专有名词、错误码、产品型号的场景里。还有一个技巧是查询改写。用户的问题往往口语化、信息不完整直接拿去检索效果不好。可以在检索前让模型把问题改写成更适合检索的形式或者生成多个相关查询一起检索。比如用户问“那个登录报错怎么回事”改写成“登录失败 错误原因 排查方法”之后检索命中率会高很多。2.5 重排序把最相关的材料放到最前面检索回来一堆块之后它们的排序未必合理。向量相似度高不代表对回答这个问题最有价值。重排序环节就是用一个专门的模型对候选块做精细打分把真正相关的排到前面。我通常的做法是检索阶段召回20到30个候选块重排序后只取前3到5个塞进上下文。为什么不全塞进去因为模型的上下文窗口虽然大但塞得越多模型注意力越分散反而容易忽略关键信息。而且无关内容会干扰模型判断增加胡编乱造的概率。宁可少而精不要多而杂。2.6 生成环节提示词设计决定最终输出质量到了生成这一步核心工作就是设计提示词。我的提示词模板通常包含几个关键部分角色设定、任务说明、参考资料、回答要求、兜底策略。角色设定让模型知道自己是“基于给定材料回答问题的助手”任务说明讲清楚要做什么参考资料就是检索回来的文本块每个块标注来源编号回答要求包括“只基于参考资料回答”“如果资料中没有相关信息就明确说不知道”“引用时标注来源编号”兜底策略是防止模型在资料不足时强行编造。提示词里一定要明确写“如果参考资料不足以回答问题请直接说‘根据现有资料无法回答’不要编造”。这句话能挡掉大部分幻觉。3. 检索质量上不去的五个真实原因与排查路径RAG系统跑起来容易跑好难。下面这五个问题是我在实际项目中反复遇到的每一个都花了大量时间定位和修复。我把排查思路完整写出来你可以对照自己的系统逐项检查。3.1 召回为空或极少先查切分再查嵌入用户问了一个知识库里明明有的问题但检索结果为空或者只有一两条不相关的。这种情况我一般按以下顺序排查第一步确认知识库里确实有相关内容。听起来像废话但我真的遇到过团队以为某文档已经入库、实际上加载环节因为格式问题静默失败了的情况。先手动在数据库里搜一下关键词确认数据在不在。第二步检查切分粒度。如果相关内容被切得太碎分散在多个块里每个块都不完整检索时可能每个块的相似度都不高。解决办法是调整切分参数或者对这类文档做特殊处理。第三步检查嵌入模型是否适合当前语言和领域。用几句典型问题手动算一下向量相似度看看语义相近的文本对得分是否合理。如果明显不合理考虑换模型。第四步检查检索的相似度阈值。有些实现会设置一个最低相似度门槛低于这个值就不返回。如果阈值设得太高可能把一些相关但表达方式不同的块过滤掉了。适当降低阈值试试。3.2 召回了相关内容但模型没用上这种情况更隐蔽检索结果里明明有正确答案但模型生成时忽略它自己编了一套。原因通常有两个一是检索结果排序太靠后模型注意力被前面的无关内容带偏了二是提示词没有强调“必须基于参考资料”模型习惯性地用自己的知识回答。针对第一个原因加强重排序确保最相关的块排在最前面。针对第二个原因在提示词里用更强的约束语句比如“你的回答必须完全基于以下参考资料不得使用参考资料之外的知识”。还可以在参考资料前后加分隔标记让模型清楚知道哪部分是材料、哪部分是问题。3.3 答案正确但引用来源对不上用户看到答案后想核实来源点开引用的文档却发现内容对不上。这通常是块编号和来源映射出了问题。检索时每个块要携带完整的来源信息文档名、页码、块序号生成时模型标注的编号要和这个映射一致。我建议在拼接参考资料时每个块前面加上明确的编号标记比如[1] 来源xxx文档 第3页模型引用时直接写[1]前端再根据编号跳转。3.4 多轮对话中检索“跑偏”单轮问答效果不错但连续对话时用户第二个问题往往省略了主语比如先问“A产品的部署流程”接着问“那B产品呢”。如果直接把“那B产品呢”拿去检索肯定什么都找不到。解决办法是在检索前做查询改写把对话历史考虑进去把省略的信息补全改写成“B产品的部署流程”再检索。3.5 响应速度慢到无法接受RAG链路长每个环节都有耗时。优化时按耗时占比排序嵌入模型推理通常是大头可以考虑用更轻量的模型或者做批量处理向量检索本身很快但如果数据量大且没有建好索引也会拖慢重排序模型如果太大可以换成轻量版或者减少候选数量生成环节的耗时取决于模型和输出长度可以通过限制输出长度来优化。我的经验是先保证效果再优化速度。效果都没达标就去抠毫秒级延迟属于本末倒置。等效果稳定了再逐个环节做性能剖析找到真正的瓶颈。4. 从零搭建一个可用的RAG系统我的实操步骤下面这套流程是我在多个项目中沉淀下来的以中文技术文档问答为场景你可以根据自己的业务调整。整体思路是先用最小可行方案跑通再逐步优化。4.1 环境准备与依赖选择基础环境需要Python运行环境核心依赖包括文档解析库处理PDF、Word等格式、文本切分工具、嵌入模型推理库、向量数据库客户端、以及大模型调用接口。我的建议是先用本地能跑的小模型做嵌入生成环节调用API这样初期不需要GPU也能跑起来。向量数据库我初期用的是本地文件型方案数据存成文件检索时加载到内存。优点是零部署、零运维缺点是数据量大时内存吃紧。十万条以内的块完全够用。4.2 文档入库的完整流程入库流程分四步加载、切分、向量化、存储。加载环节我写了一个统一入口根据文件扩展名分发给不同的解析器。PDF用版面分析工具提取文本和表格Word用文档解析库读段落Markdown直接按标题层级解析。每个文档解析后保留元数据文件名、路径、修改时间、文档类型。切分环节我用的策略是先按Markdown标题或段落切如果单个段落超过500字再按句号、问号、感叹号切分仍然超长就按字符数硬切。每个块保留50字的重叠。切分后给每个块拼接它所属的章节标题作为前缀。向量化环节批量调用嵌入模型每批处理32到64个块避免单次请求过大。向量存入库时同时存入块文本、元数据、向量三个字段。存储环节建立向量索引加速检索。如果数据库支持同时建立关键词索引用于混合检索。4.3 检索与生成的代码骨架检索部分的核心逻辑是接收用户问题先做查询改写可选然后并行执行向量检索和关键词检索合并结果后做重排序取前N个块。# 伪代码示意展示检索主流程 def retrieve(query, top_k5): # 查询改写可选 rewritten rewrite_query(query) # 并行检索 vector_results vector_search(rewritten, top_k20) keyword_results keyword_search(rewritten, top_k20) # 合并去重 merged merge_and_dedup(vector_results, keyword_results) # 重排序 reranked rerank(query, merged) # 取前top_k个 return reranked[:top_k]生成部分的提示词模板我通常这样组织你是一个基于给定资料回答问题的助手。请严格根据以下参考资料回答用户问题。 参考资料 [1] 来源{doc_name} 第{page}页 {chunk_text} [2] 来源{doc_name} 第{page}页 {chunk_text} 用户问题{query} 回答要求 1. 只使用参考资料中的信息不要使用你自己的知识 2. 如果参考资料不足以回答问题请直接说“根据现有资料无法回答” 3. 引用信息时标注来源编号如[1] 4. 回答要简洁准确不要编造4.4 效果验证怎么判断系统“能用”了搭建完成后需要一套评估方法来判断效果。我的做法是准备一个测试集包含50到100个典型问题每个问题标注标准答案和应该命中的文档块。然后看两个指标检索命中率正确答案所在的块是否被检索到和回答准确率生成的答案是否与标准答案一致。检索命中率低于80%说明检索环节有问题优先优化切分和检索策略。检索命中率达标但回答准确率低说明生成环节的提示词需要调整。这个评估过程要反复做每次改动后重新跑一遍确保优化方向正确。5. 进阶优化让RAG从“能用”到“好用”基础版RAG跑通之后如果还想进一步提升效果下面这几个方向是我验证过确实有效的。5.1 父子块检索兼顾精确匹配和上下文完整前面提到切分粒度是个两难问题。父子块方案巧妙地绕开了这个矛盾检索时用小块子块来匹配因为小块语义集中、匹配精度高但返回给模型时用大块父块因为大块包含完整上下文。具体做法是切分时同时生成小块和大块建立子块到父块的映射。检索命中子块后根据映射找到对应的父块把父块内容给模型。这个方案在我做的技术文档问答里效果提升明显。用户问一个具体参数小块能精确匹配到那个参数所在的句子但返回的父块包含了整个参数说明段落模型能给出更完整的回答。5.2 多路召回融合不把鸡蛋放在一个篮子里除了向量检索和关键词检索还可以加入其他召回路径。比如对于有明确分类体系的文档可以先做分类过滤再检索对于有时间属性的内容可以按时间范围过滤。多路召回的结果用加权融合权重可以根据实际效果调整。我通常会给向量检索和关键词检索各分配一个基础权重然后根据查询类型动态调整。如果查询里包含明显的专有名词或数字提高关键词检索权重如果是自然语言描述的问题提高向量检索权重。5.3 上下文压缩给模型减负检索回来的块里往往包含大量与问题无关的内容。上下文压缩就是在把块送给模型之前先做一轮筛选或摘要只保留与问题相关的部分。可以用模型来做这件事也可以用规则方法比如只保留包含查询关键词的句子及其前后句。这个优化对生成质量提升明显因为模型接收到的信息更聚焦不容易被无关内容干扰。代价是增加了一次模型调用延迟会上升。适合对准确率要求高、对延迟容忍度也较高的场景。5.4 缓存机制重复问题不必重复计算实际使用中很多问题是重复或高度相似的。可以加一层缓存用户问题先查缓存命中则直接返回之前的结果未命中再走完整流程。缓存可以用问题向量做相似度匹配相似度超过阈值就认为命中。这个优化对响应速度提升巨大尤其是热门问题。需要注意的是缓存要有过期策略知识库更新后旧缓存要失效否则会返回过时信息。6. 几个让我印象深刻的踩坑记录最后分享几个我在实际项目中踩过的坑都是文档里不会写、但实际会遇到的。第一个坑PDF里的表格是图片。一份规格书里的参数表是截图贴进去的文本提取完全拿不到内容。后来加了OCR环节才解决。教训是入库前一定要抽样检查解析结果不能假设解析工具能处理所有情况。第二个坑嵌入模型换了但没重新入库。中途换了一个效果更好的嵌入模型但忘了把已有数据重新向量化导致新旧向量混在一起检索结果乱七八糟。教训是嵌入模型一旦确定就不要轻易换要换就必须全量重新入库。第三个坑提示词里的参考资料太长导致模型“失忆”。有一次检索回来十个块每个块都很长加起来超过模型的上下文窗口模型直接截断了前面的内容导致关键信息丢失。后来严格控制送入的块数量和总长度问题解决。第四个坑多轮对话没做查询改写。用户连续问了好几个问题后面的问题越来越短检索完全跑偏。加上查询改写后把对话历史考虑进去问题才解决。第五个坑没有兜底策略导致模型硬编。知识库里没有的问题模型也强行回答编得有模有样。后来在提示词里加了明确的兜底语句并且在前端也做了处理如果检索结果相似度全部低于阈值直接提示用户“知识库中未找到相关内容”不调用生成模型。这些坑的共同点是它们都不是算法问题而是工程细节问题。RAG的门槛不在理论而在把这些细节一个个磨到位。我见过太多团队Demo跑得很漂亮一上真实数据就各种问题根源都在这些不起眼的地方。如果你正在搭建RAG系统我的建议是先用小规模真实数据跑通全流程把每个环节的输入输出都打印出来人工检查确认没问题再扩大规模。不要一上来就追求大而全先把一个场景做深做透效果稳定了再横向扩展。