做RAG检索增强生成这个方向也有两年多了从最开始跑通Demo以为自己已经掌握了到后来在一个个线上问题里反复折腾才慢慢意识到RAG系统的上限根本不取决于你用了多大的模型而是取决于你索引、检索、生成这三个环节里是否做了足够的优化。这篇文章是AI学习笔记整理系列的第51篇主题就是大模型之RAG优化技术。我会用手写笔记的方式把实际踩过的坑、验证过的手段、以及背后的逻辑原原本本梳理一遍。文章会从整体优化思路讲到索引细节从检索质量讲到生成约束最后落在评测闭环和排查速查表上。不管你是刚入门RAG的新手还是已经在做落地优化的开发者这篇内容应该都能给你一些可以直接抄作业的参考。1. 整体优化思路拆解先搞清楚瓶颈在哪1.1 RAG的流程回顾索引、检索、生成三件事RAG的基本链路大家应该很熟悉但我还是要把它拆开因为很多优化的切入点就藏在这几个环节的细节里。第一阶段是索引构建。把原始文档读进来做清洗切分成一个个文本块chunk然后丢给嵌入模型做向量化再存入向量数据库。这个阶段处理的是一句话让知识库里的内容可以被搜到。第二阶段是检索。用户提问进来先对问题做向量化然后在向量库里做相似度搜索把最相关的若干个文本块捞出来。有的系统还会加一步重排序Rerank。这个阶段处理的是一句话把最相关的东西找出来。第三阶段是生成。把检索到的文本块拼进去和用户问题一起组装成提示词交给大模型让它基于这些资料生成答案。这个阶段处理的是一句话让答案长在证据上。很多初学者一提到RAG优化第一反应是调提示词或者换更强的大模型。但实际上我在实际项目里的体感是检索质量决定了答案质量的下限生成模型决定的只是上限。如果检索捞回来的是三句无关的话你就算把GPT换到天花板它也只能硬着头皮编。所以优化的第一步不是哪疼医哪而是先判断问题出在哪个阶段。1.2 RAG优化的优先级先建基线再说花活在深入细节之前我必须先分享一个最核心的心得不要在没有评测基线的情况下盲目优化。什么意思我见过很多同学看了一些技术文章上来就把什么多查询扩展、混合检索、双层重排全加上结果效果不但没变好反而因为引入太多噪声变慢了。后来我养成了一个习惯先搭一个最简单的RAG系统跑一批固定的测试问题记录当前的坏表现——比如哪些问题答错了、哪些问题答非所问、哪些问题根本搜不到。这些记录就是基线。有了基线你会非常清楚地知道瓶颈在哪里如果错误主要是搜到的内容根本不对那就去优化检索和索引。如果错误是搜到了但大模型没用好那就去优化生成和提示词。如果错误是整个链路都慢得离谱那就去优化嵌入模型和向量库。优化也讲究一个性价比排序。在我做过的项目里投入产出比从高到低大致是数据清洗和分块策略、混合检索加重排序、查询改写、提示词约束、复杂的多跳或Agent化方案。前者往往只需要小改动就能带来明显提升后者则容易变成看起来很先进实际很难落地的技术玩具。这就是为什么这篇文章会把大量篇幅放在索引和检索上——它们才是最值得你花时间的部分。2. 索引阶段优化一切检索效果的源头2.1 数据清洗与文档预处理细节里藏着魔鬼绝大多数真实落地的RAG项目面对的不是整洁的Markdown文本而是PDF、Word、扫描件、PPT。这个环节我吃亏最多所以先说几个关键点。第一PDF的表格和排版是最大的坑。很多PDF解析工具会把表格拆成错乱的文本序列本来是三列对照的规格参数解析后变成一堆串行文字向量化之后语义完全错乱。我的处理方式是如果文档里表格很多优先使用支持版面解析的工具把表格区域单独抽取出来转成Markdown表格格式再进入切分环节实在搞不定的扫描件得先过OCR而且OCR之后的错别字必须人工抽查清洗否则错别字会在检索时悄悄降低相似度分数。第二文档里的页眉页脚、目录、水印必须去掉。我们曾经遇到过一个大麻烦解析出来的文档每一页都带着第X页共Y页的页脚这些无关文本被切进多个文本块后检索时经常因为高频重复而污染相似度打分。后来我在清洗环节统一用正则把这些干扰项剃掉检索准确率肉眼可见地上升了。第三同名实体和缩写要保留上下文。比如一个知识库里同时出现RAG指代检索增强生成和某公司内部的一个项目代号如果你在清洗阶段不做处理模型检索时就会混为一谈。稳妥的做法是在清洗阶段做一个轻量级的实体替换或者至少保证相关文档在切分后仍然保留其所在章节的说明性上下文比如本项目中的RAG指……。这块工作琐碎但回报非常实在。2.2 分块策略选择embedding限制与语义完整性如何平衡分块是整个索引优化的重中之重。它决定了两件事检索的命中率能不能搜到和纯度搜到的东西有多少是有用的。先说最粗暴的固定大小切分比如把文档每512字一刀切。这种方法实现最快但效果经常很崩因为一段语义可能在正中间被切开。比如一句话的前半段在块A末尾后半段在块B开头检索时拿到了块A但块A里只有半句话大模型自然答不出来。我的默认选择是递归切分加上一定的重叠。递归切分的意思是优先按段落分隔符切段落太长再按句子分隔符切句子还太长再按固定长度兜底切。这样层级下来切的每一块在语义上大概率是完整的。至于重叠overlap我会设置128到256字的上下块重叠区域避免恰好把关键句子拦腰截断。chunk的大小怎么定这取决于你的嵌入模型和场景如果是做FAQ问答答案通常很短块可以小一点256到512字检索精确度高。如果是做深度技术文档问答答案往往需要跨段落综合块太小会导致上下文不足我一般会设成1024字左右。如果嵌入模型本身支持长文本比如某些支持2048token的模型可以适当调大块大小但要注意块越大向量化成本越高检索召回时对比的时间也越长。还有一个进阶手段叫父子分块。我最近在某个文档密集型项目里用了这个方案把大文档先切成比较大的父块比如按章节切再把父块内部切成细小的子块比如每256字一个。索引和检索时只用子块做向量匹配但命中子块后把它所属的父块内容一并作为上下文交给大模型。这样兼顾了检索的精确度和生成的上下文完整性效果相当不错。代价是存储和检索的次数上升了需要根据实际数据量权衡。2.3 嵌入模型选型与向量库不要被“榜单最高的模型”忽悠嵌入模型很大程度决定了语义检索的天花板。中文场景下我实测下来业界常用的几个开源中文嵌入模型比如BGE系列在通用领域表现都不错AP类模型在商业场景更省心。但选型时我建议不要只看那几项公开榜单的指标的微小差异而是用你自己的文档数据跑一批真实用例来做对比测试。一个很容易被忽视的点是嵌入模型的上下文长度限制。很多模型训练时只支持512token以内的文本如果你把1024字的chunk直接灌进去它会自动截断后半段内容直接被丢弃。这在检索时会造成严重的信息丢失。所以我在选型时一定会确认模型的max sequence length之后倒推chunk size。向量数据库的选型也取决于场景数据量在百万级以下直接用开源的FAISS本地跑就够了配置简单嵌入更新也方便。上了千万级或者需要高并发生产环境我建议用支持分布式和标量过滤的向量数据库比如Milvus或Qdrant它们都带成熟的相似度索引算法。如果不想引入额外组件PostgreSQL的pgvector插件也能顶一阵子适合小团队项目轻度使用。此外向量库的索引参数也需要调优。我常用的量化策略是把嵌入从FP32压缩到INT8几乎不掉精度但检索速度能提升好几倍。索引类型上HNSW是最常见的图索引参数M每个节点的最大连接数影响内存和召回率efConstruction影响建索引质量。我的习惯是从默认参数跑起用评测集一点一点调切忌直接在官网照抄一组参数就让生产系统上线。3. 检索质量提升从“搜得到”到“搜得准”3.1 混合检索让关键词和语义互为补充纯向量检索有一个先天弱点它是基于整体语义找相似但对精确关键词不敏感。举个例子如果用户问GB/T 7714 参考文献格式是怎么规定的知识库里恰好有一句话以GB/T 7714开头向量检索未必能把这句话排到前面因为嵌入模型对这种型号代码的语义区分能力比较弱。这种情况下传统的关键词检索比如BM25反而表现更好。所以我做了混合检索用户查询进来同时走两条路——一条用嵌入模型做语义向量召回另一条用BM25做词法召回把chunk文本建立倒排索引。两路各自返回Top N结果后把分数做归一化合并再取Top K进入下一阶段。这样做的好处是语义和词法互补。语义路能处理换了个说法但意思一样的查询词法路能精准锁定包含特定编号、缩写、专有名词的文档。实际效果上混合检索通常能比单路向量检索的召回命中率提升三五个百分点以上而且实现成本不高。需要注意的细节是两条路的分数分布往往不一致合并前要先做归一化不然词法分数永远压过语义分数或者反过来。3.2 查询改写与扩展让“烂问题”变成“好问题”用户提问的方式千奇百怪很多人不会用完整句子提问而是直接打几个词合同过期书面通知怎么弄。这种碎片化查询直接去检索效果通常很一般。我的做法是加一层查询改写模块先用大模型把用户的问题改写成一段更完整、更适合检索的查询语句再拿改写后的语句去做向量化检索。别小看这一步它在复杂咨询场景里能显著提升召回质量。再高阶一点的是多查询扩展multi-query。同一个问题让大模型从不同角度生成三到五个变体问法比如原始问题是退款条件和流程是什么扩展成哪些情况下可以申请退款退款需要走哪些步骤退款申请的审批流程不同渠道的退款差异然后把每一个变体都去做检索合并所有的召回结果。在信息分散在多个文档的场景下这个方法能明显提升覆盖度。代价是检索次数涨了三五倍延迟也会相应增加用不用取决于你的场景对延时的容忍度。还有一个叫HyDE的招数不问变体问题而是让大模型先基于自己已有的知识生成一个假设答案然后用这个假设答案去做向量检索因为假设答案通常比问题本身包含更多跟文档匹配的语义细节。这个方法在部分垂直场景下有效但我的实测体感是并不稳定——如果模型生成的方向偏了反而会把检索带歪。所以我的态度是HyDE可以作为备选方案但不要作为默认选项。3.3 重排序Rerank精度提升的最大功臣重排序是我在所有检索优化手段里最推荐投入的一步它对最终答案质量的影响非常直观。它的原理是上面那些不管哪种方式向量、混合、多查询得到的Top N候选都是基于便宜的相似度粗略筛出来的精度有限。重排序则是用更强的模型如交叉编码器把每个候选文本和用户原问题放在一起逐对计算真实的相关性分数再做一次精排把真正相关的Top K捞上来。交叉编码器比双塔式的嵌入模型精度高不少因为它做了问题和文档片段的深度交互但速度慢得多所以要把它放在粗筛之后只对候选集比如50条进行精排最后取5到8条进生成。我在项目中真实的经验是加不加重排序答案的准确度差距很大。一次做故障原因问答时不加重排的版本经常把原因分析和处理措施混在一起加了重排之后系统能稳定地挑出跟当前故障代码最匹配的那一段描述。重排模型选型上我用过几类产品化的重排序模型实测在中文场景下效果都不错。跑到生产环境时我会考虑两点一是重排模型的输入长度够不够有些重排模型只能处理512token以内的文档太长的chunk要截断再排二是推理延迟可以通过批处理来缓解单条请求的开销。除此之外元数据过滤也是一个容易见效的优化点。我给每一条chunk加上了来源文档、时间戳、文档类型等元数据标签检索时如果用户问题里带有明确的范围要求比如去年的政策就先用元数据过滤掉不符合的chunk再走相似度排序。这个操作能把检索的准确率往上拉一个台阶而且实现非常简单。4. 生成环节优化与评测闭环4.1 提示词约束让大模型学会“克制”检索做好了生成环节也不能放任自流。RAG的提示词设计和普通聊天不同关键在于给它立规矩基于资料回答问题不得使用资料之外的知识。我的标准做法是在系统提示词里明确写明几条请仅依据上述资料内容回答用户问题如果资料中没有相关信息直接回答资料中未找到相关内容不要自行推测。回答时引用资料片段编号比如[1][2]便于用户核对来源。若用户问题与资料无关礼貌说明并引导重新查询。不要小看这几句话。加与不加之间幻觉出现的频率差别非常明显。大模型其实很懂得察言观色你如果没约束它它会尽力表现得像个什么都懂的万事通你只要给了明确的边界它会收敛很多。如果条件允许我建议再灌几个少样本示例。比如给一个资料充足时怎么回答的示例和一个资料缺失时怎么拒绝的示例大模型的生成风格会立刻稳定下来。此外还有一个小技巧让大模型先提取资料中的核心要点再做总结输出。这个先概括再生成的两段式做法在一些长上下文场景下能显著降低遗漏信息的情况。代价是多一次大模型调用延迟增加几百毫秒适合知识问答类但不强求极低延迟的场景。4.2 RAG评测体系建设没有度量就没有优化前面说了一切优化的前提是先有基线。那么评测集怎么建我用的是离线评测加在线监控两步走。离线评测集的建设思路是这样的从知识库里抽出一批有代表性的条目为每一条人工或利用大模型生成若干对应的问答对。除了常规问题一定要故意加进去几类难点样本带有专有名词和编号的问题、需要跨文档综合的问题、知识库里没有答案的越界问题。这样评测集才能真正暴露系统的短板。评测指标我用的是开源评测框架比如RAGAS里的那几个经典指标答案忠实度faithfulness答案是否完全依据上下文有没有引入外部幻觉。答案相关性answer relevancy答案是否切题有没有答非所问。上下文相关性context relevancy检索出来的资料是否和问题真正相关。这三个指标分别对应生成质量和检索质量用起来非常直观。评测时就是跑一批问题统计这些指标的平均分改动任何一个环节后重新跑一遍对比分数变化。在线监控是另一套轻量逻辑主要是在生产环境里抽样部分真实用户问题记录检索出来的TOP N资料、用户满意度反馈等定期抽查这些记录。在线监控能发现离线评测没覆盖到的真实边界情况两者缺一不可。我的最终建议是每次优化只改一个变量。很多人喜欢一次性换掉嵌入模型、改了分块方式、加了重排然后发现效果变好了但根本说不清是哪个改动起的作用。科学的做法是一步步来每次都回看对比数据。这个过程看起来很慢实际上才是最快的路径。4.3 完整的优化流程示例从基线到回归测试给一个我实际用过的流程模板照着做基本不会出大问题第一步搭建最简RAG系统——文档清洗、固定分块、默认嵌入模型、纯向量检索、不加任何优化模块。跑评测集记录各项指标和出错明细。第二步做一次索引升级——换成递归切分加重叠、优化清洗规则重跑评测。第三步上混合检索。跑评测看召回是否提升。第四步加重排序。跑评测重点看上下文相关性和忠实度。第五步加查询改写或多查询扩展。跑评测看一下延迟和召回覆盖度是否有明显变化。第六步调整提示词约束。跑评测重点观察忠实度。每一步结束我在笔记里都会记录一个简单的结论第X步改动之后指标Y从Z变到了W错误从A类变成了B类。久了以后这套笔记就是你自己项目的优化宝典。5. 常见问题与排查技巧实录在梳理笔记的时候我把这段时间在RAG优化里遇到的高频问题整理成一个速查表。你在实际项目里碰到类似问题时可以直接照着排查。典型问题最可能的原因排查与处理建议答非所问是对的问题答案错检索到的上下文与问题不相关检查召回TOP K里有没有正确文档尝试加混合检索和重排序答案幻觉明显资料里找不到依据提示词缺少约束或检索到的上下文不足强化提示词仅依据资料回答检查上下文长度是否够用要求输出引用编号关键专有名词搜不到纯向量检索对词法不敏感加BM25关键词检索做混合检查清洗阶段是否误删了关键符号答案内容太散缺乏综合chunk切得太大或太小跨文档信息割裂尝试父子分块多查询扩展必要时先用摘要索引定位再精确检索线上延迟越来越高检索阶段召回条数太多、重排序或生成太慢压缩召回粗筛数量对嵌入做量化重排模型改批处理考虑缓存高频查询知识更新后答案还是旧的向量索引没有增量更新或更新延迟太长建立增量索引任务旧chunk必须删除否则语义相似的新旧文档会互相干扰多提一个容易被忽略的坑语料中如果有大量重复或相似度极高的文档向量检索的召回结果会被几条重复片段霸占导致上下文信息量不足。这种情况我一般会加一个去重步骤按内容相似度对chunk做聚类只保留每类中信息量最大的几条。关于检索阈值的细节再说一句有些人习惯设一个相似度阈值低于阈值的结果一律不返回。我实际用过几次后发现这个策略容易误伤——相似度分数分布在不同数据集之间差异很大固定阈值根本不可靠。我现在的做法是把阈值当成一个护栏而不是筛子设一个比较宽松的下限比如0.5左右主要靠召回数量Top K和重排序来把控精度。最后想说的话做RAG优化两年多我的核心体会是这个领域没有什么银弹真正可靠的方法就是扎扎实实把每一条链路调好。很多炫酷的前沿方案比如让大模型自主决定要不要检索、记忆反思等在真实项目里未必比得上数据清洗到位、分块合理、混合检索加上重排这基础三件套带来的提升。另外一定要养成记录和对比的习惯。技术方案效果怎么变化一定要有数据支撑而不是凭感觉说好像变好了。我写下这篇笔记也是希望以后再做类似项目时能直接翻阅这套方法论少走一些弯路。最后再分享一个小技巧如果你手头时间只够做一件事那就先做重排序Rerank——它是几乎所有RAG系统里性价比最高的优化手段。把这一步加上去你的答案质量通常会有肉眼可见的提升等你尝到甜头了自然会愿意再往索引和查询改写上花功夫。
