做RAG项目这几年下来我最大的体会是大多数人把精力全放在提示词工程和大模型调参上结果效果还是不稳定最后排查下来十有八九是召回侧出了问题。生成模型再聪明检索回来的内容不对输出照样是一本正经的胡说八道。这篇是RAG深度解析系列的第四篇我把视角从生成侧挪到检索侧好好聊聊召回和重排这两个环节它们的职责边界是什么选型逻辑怎么定具体实现怎么做以及我在生产环境里踩过的那些真正影响效果的坑。1. 召回与重排决定RAG天花板的两个环节很多刚接触RAG的人会以为把文档切好塞进向量库用户提问后用相似度搜索捞几条出来拼进上下文这就完事了。实际跑起来才发现检索质量对最终答案的影响远比想象中大。与其说RAG是大模型问答不如说它是先检索、后生成的两段式系统生成侧决定回答的下限检索侧决定回答的上限。1.1 召回决定上限生成决定下限到底怎么理解我习惯用一个图书馆找书的类比。生成模型像一个经验丰富的图书管理员他再会整理、再会综述前提是有人把正确的书放到他桌上。如果找书的人召回模块从书架上扒拉下来一堆无关的旧杂志管理员也只能硬着头皮从这些垃圾材料里编答案。提示词写得再花哨模型也没办法从它没见过、没被喂进来的信息里变出正确答案。所以在实际项目中我会先盯检索链路再谈生成侧优化。一旦发现某个知识库问答效果忽好忽坏第一反应不是换大模型而是看看top几条召回结果里到底有没有真正相关的内容。很多幻觉问题的根源其实是上下文里混进了大量不相关甚至互相矛盾的片段模型被带着跑偏了。1.2 召回和重排的职责边界一个负责广撒网一个负责精打捞召回阶段的首要目标是别漏掉。文档库动辄几万、几十万个分块要在几十毫秒内从里面捞出可能相关的候选这一阶段算法必须够快、覆盖要够广精度可以粗糙一些。召回重排的典型分工是召回阶段先从全库捞回几十到上百条候选重排阶段再对这批候选做精细打分挑出最靠前的几条送入模型。召回负责把对的东西留在大名单里重排负责把大名单里真正对的东西顶到最前面。这里有个容易误解的点很多人觉得只要向量检索够好就不需要重排。实际不是这样。向量召回本质用的是双塔编码——查询和文档各自编码成一个向量用向量距离近似相关性。这种结构为了速度牺牲了交互精度而重排用的交叉编码器让查询和文档在模型内部逐字交互精度上了一个台阶但速度慢得多。所以两阶段不是叠床架屋而是速度和精度这对矛盾的经典解法。2. 召回选型向量检索、稀疏检索与混合检索的取舍召回侧的第一个纠结就是到底用哪种检索方式。我在项目里见过三种典型方案纯向量检索、纯BM25关键词检索、向量BM25混合检索。结论先放这里如果你的文档包含大量专有名词、编号、人名或精确术语纯向量检索大概率不够混合检索是更稳妥的基线方案。2.1 纯向量检索的优势与硬伤向量检索的原理是把文本映射到高维语义空间语义相近的句子在空间里距离更近。它的强项是意会——用户问这个系统会不会卡文档里写的是高并发场景下的延迟表现两者字面不重叠但语义能搭上这种场景向量检索完胜。但纯向量检索有几个硬伤我在实际项目里反复撞到。第一它对专有名词和精确ID不敏感。用户问订单号A10087的状态向量模型很容易在空间里被语义相近的订单状态查询带偏而精确的10087这个信息反而被平均到向量里变成了噪声。第二少数派的冷门实体召回很差因为向量模型在训练时对低频词的表征本来就不够稳定。第三数字、版本号、型号这类token向量检索经常算不清相似度。2.2 BM25这种老古董为什么还死不掉BM25是经典的关键词检索算法核心思路是文档里某个词出现得越多、这个词在整个文档集里越稀有那这篇文档跟查询的相关性越高。它不理解语义只做字面匹配但恰恰是这种死板让它非常可靠用户搜订单号A10087它能精确匹配到包含这个ID的文档粒度和可解释性都一流。实际项目里BM25的最大价值是兜底和互补。向量检索漏掉的精确匹配内容往往要靠BM25捞回来。而且它不依赖GPU、没有模型部署成本库小的时候直接内存里跑速度飞快非常适合作为保底方案。很多团队把BM25当上古技术弃用我反而觉得它是整个检索链路里最稳的一根拐杖。2.3 混合检索与RRF分数融合的正确姿势混合检索就是把向量检索和BM25的结果合并。听上去简单合并细节才是关键。两家打分体系完全不一样——向量分数是余弦相似度数值范围约在-1到1之间且集中在零点附近BM25分数则取决于词频和文档长度可能是几十分甚至上百分的数。直接相加就是拿公斤和摄氏度做加法没有任何意义。我推荐用RRFReciprocal Rank Fusion融合它不看原始分数只看排名。公式很朴素对每条文档把它在多个检索结果里的排名位置换算成分数然后求和。具体做法是对文档在每个召回列表里的名次r贡献分是1 / (k r)k是平滑常数通常取60。排在越前面的文档得分越高两个列表都排前列的文档融合后总分自然最高。def rrf_fusion(ranked_lists, k60): scores {} for hits in ranked_lists: for rank, doc_id in enumerate(hits, start1): scores[doc_id] scores.get(doc_id, 0.0) 1.0 / (k rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue)RRF最大的优点是稳定、不用调权重因为排名融合天然规避了不同检索器分数量纲的问题。我一般会两头各取前50条做融合宁可召回多一点让重排去收敛。2.4 分块策略是隐形的召回杀手做过几个项目之后我越来越确定检索效果不好很多时候不是检索算法的问题而是上游分块把信息切碎了。分块太大单块包含大量无关内容向量被稀释语义向量反映的是整块的平均味道命中率自然低分块太小完整的信息被拦腰截断比如一个方案说明的前置条件和操作步骤被分到两块检索时只捞到其中一块答案就是不完整的。我的通用起点是普通技术文档按固定窗口分块块大小256512个token重叠50个token左右。重叠的意义是防止关键信息恰好落在切分边界上被截断。如果是结构化文档优先按标题和章节边界切如果是表格建议一行或一个完整记录作为独立块。分块策略没有银弹但一定要在评测集上对比验证而不是拍脑袋定数字。3. 重排阶段交叉编码器的工作原理与工程边界重排是整个检索链路里最容易被低估的一环。它做的工作可以从两个塔的结构差异来理解。3.1 双塔编码器和交叉编码器的本质区别向量检索用的双塔结构查询和文档分别过同一个编码器产出两个向量再算相似度。缺点是查询和文档在编码过程中没有交互——模型只能看到查询的语义和文档的语义却看不到这两段文本放在一起是否匹配。很多细微的匹配关系比如否定词、条件限定、除了A之外这种特殊结构在独立编码时很容易丢失。交叉编码器则直接把查询和文档拼接成一句话比如[CLS] 查询文本 [SEP] 文档文本 [SEP]一起送进模型做自注意力。模型内部每个token都能看到另一边的token能捕捉逐字的交互证据匹配精度显著提升。代价也很直观每处理一对查询-文档对都要完整过一遍模型无法像双塔那样预计算向量。所以它只能用来重排少量候选不可能在全库范围扫描。3.2 开源重排模型的选型与部署成本市面上开源的重排模型大多基于交叉编码器结构参数量从几亿到几十亿不等。实际项目中我并不一味追大模型重排环节吃的是推理延迟模型越大单个查询-文档对的延迟越高。常见的做法是召回100条候选重排阶段用中小尺寸模型参数量控制在1亿到4亿这个档位保证总延迟在几百毫秒内。部署上有两个建议。第一是批量推理把待重排的候选拼成一个batch一次过模型比一条一条跑快很多。第二是精排和粗排分层如果候选项特别多比如多路召回合并后有三四百条可以先用一个更小的重排模型粗筛到50条再用更大更准的模型精排到510条。分层重排的收益在文档量级变大后会非常明显。3.3 重排的时机什么时候必须上什么时候可以省不是所有场景都值得加重排。我的判断标准很简单候选集越大、文档越相似、对答案准确性要求越高越必须重排。三路以上召回必须重排。理由很直接——多路召回把不同语义的信号混在一起向量觉得靠前的和BM25觉得靠前的往往不是同一批文档没有重排统一打分最终进入上下文的顺序基本靠运气。反过来如果你的文档库很规整、查询类型很固定且单路向量召回就能稳定命中用评测集验证过hit rate足够高可以暂时不上重排。但我要提醒一句这种稳定在文档库规模扩大后很容易被打破重排迟早要补上。所以架构上最好预留重排接口别把代码写死成召回后直接拼上下文。4. 一条可复现的召回重排Pipeline实现细节理论讲再多不如一条能跑通的链路。下面是我在模拟项目X里用的实现思路基于一套完全虚构的运维知识库核心逻辑可以直接迁移到你的场景。4.1 从文档加载到分块入库第一步是加载文档并分块。我用的是递归字符分割的思路先按段落切段落太长再按句子结合长度控制切。分块后给每一块生成唯一ID顺便记录来源文档名和章节路径方便后面追溯答案出处。def split_document(doc_name, content, chunk_size300, overlap50): # 伪代码递归分块逻辑 paragraphs content.split(\n\n) chunks [] buf [] buf_len 0 for para in paragraphs: if buf_len len(para) chunk_size and buf: text \n.join(buf) chunks.append({doc: doc_name, text: text, chunk_id: f{doc_name}_{len(chunks)}}) # 简单重叠保留末尾一段 buf buf[-1:] buf_len len(buf[0]) buf.append(para) buf_len len(para) if buf: chunks.append({doc: doc_name, text: \n.join(buf), chunk_id: f{doc_name}_{len(chunks)}}) return chunks分块之后把每块文本向量化后写入向量库。同时维护一个BM25用的倒排索引。这里我强烈建议把两步索引建在同一套分块ID上否则后面融合时对不上号。向量ID、BM25文档ID、原始分块文本必须三处一致这是整个链路的基石。4.2 构建双路召回并做RRF融合查询进来后并行跑两路检索向量检索取top 50BM25检索取top 50然后做RRF融合。向量检索这一步有个小细节查询文本直接拿去编码效果通常一般。我更习惯先做一次轻度改写把口语化的提问翻译成更接近文档表达习惯的检索词。这个技巧后面专门讲先按下不表。融合完成后的候选列表我一般保留前100条交给重排数量太少怕漏太多则重排耗时明显上升。这一步的耗时预算大概在80150毫秒向量检索和BM25并发执行基本都能满足。4.3 接入交叉编码器重排重排阶段把RRF融合后的前100条跟原始查询拼接成查询文档对批量喂给重排模型。模型输出的相关性分数从低到高排序取前8条作为最终上下文。这里有个经验值进入大模型上下文的块数通常不要超过810条一是上下文窗口有限二是相关性排在后面的块往往是噪声喂多了反而干扰生成。def rerank(query, candidates, top_n8): pairs [[query, cand[text]] for cand in candidates] # 伪代码批量预测相关性分数 scores rerank_model.predict(pairs, batch_size16) ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return [cand for cand, score in ranked[:top_n]]重排结果要不要进行最低分过滤我在项目里是做的。如果重排模型给出的最高分都低于某个阈值说明候选集整体可能都不相关这时候与其硬塞给大模型不如触发兜底逻辑比如提示用户换个问法或者直接告知没有查到相关内容。阈值需要在评测集上标定不能拍脑袋。4.4 上下文拼装与生成重排选出的块按相关性从高到低拼进提示词同时带上来源信息让大模型在回答时引用出处的块编号。拼装时我会在两个块之间加一个明确分隔标记并且在提示词里写清楚只依据给定材料回答材料中没有的内容要明确说不知道。这一步看似和检索无关但上下文的结构清晰度直接影响模型是否忠实于材料。拼装完的上下文加问题一起发给大模型整个链路量化下来检索总延迟约250毫秒左右生成另算。我实测下来这个延迟水平在多数知识库问答场景都是可以接受的。5. 效果评测召回率、命中率与nDCG怎么算做检索优化最怕的就是感觉变好了。我在前期项目里吃过不少亏——凭肉眼翻几条召回结果看着像那么回事就上线结果用户反馈一塌糊涂。后来我老老实实搭了一套离线评测才发现很多直觉判断都是错的。5.1 先建一套带标注的评测集评测集是检索优化的地基。我从线上真实用户日志里抽样了数百个问题人工为每个问题标注出应该在知识库里哪几个文档分块里能找到答案。标注工作很枯燥但无可替代。没有标签后面所有指标都是空的。考虑到标注成本我的做法是每个问题不只标一个正确答案块而是标13个相关块允许一定的主观判断差异。更重要的是我刻意在评测集里保留了那些容易翻车的类型——专有名词查询、数字版本查询、口语化表达、同义改写每类至少几十条。这样评测结果才能暴露真正的短板而不是被简单问题掩盖。5.2 四个核心指标的理解与计算我在RAG召回评测里最常用的指标是这几个各有侧重建议配合使用指标关注点直观理解Recallk前k条是否覆盖答案正确答案有没有进入候选名单这是底线Hit Rate前k条是否包含至少一个相关块用户这次提问有没有救回来的可能MRR第一个答案出现的位置正确答案排名越靠前越好影响生成质量nDCG整个排序质量加权不仅看有没有还看排序是否合理Hit Rate和Recallk看似相似区别在于Hit Rate是二值判断——前k条里只要有任意一条相关就算命中Recallk则计算相关块被召回的覆盖率。比如一个问题标注了3个相关块前5条召回了其中1个Hit Rate是100%Recall5却只有约33%。如果文档库里同一信息存在多个等价表述召回率会偏低但Hit Rate很好这种情况实际上并不影响问答效果。5.3 评测结果怎么指导调优拿到指标后我会先看Hit Rate20和50。如果20已经接近95%以上说明召回把正确答案都捞进来了瓶颈在重排——重排的排序质量拖累了最终效果。如果50都很低那问题出在召回本身可能是分块太碎、向量模型领域不匹配、或者查询改写不够。用这种分解方式我能很快定位到该优化哪一段。nDCG这种排序质量的指标主要用于重排模型的对比评测。同一个候选集分别用不同重排模型排序算nDCG10差距一目了然。我在项目里对比过粗排模型和精排模型结论是精排模型在nDCG上的优势最终会转化为大模型引用正确文档的概率提升这个转化非常明显。6. 生产环境里的坑与调优心得最后这部分我想把实战里最常遇到的几个问题集中讲透。这些坑在教科书和官方文档里几乎不会出现但每个都会实打实影响线上效果。6.1 召回数量k和重排数量r的配合召回100条、重排取8条这个数字组合看着随意实际上需要根据文档库规模和数据形态来定。文档块总数在几万这个量级时top 100候选大体够用如果库涨到几十万块建议把召回扩到200条否则可能漏掉真正的答案。重排取多少条取决于生成侧对上下文长度的要求和场景容忍度。判断这个组合合不合理最直接的方法是看召回到重排的转化率如果重排后进入最终上下文的8条里经常只有两三条是真正相关的说明召回数量或分块粒度有问题如果前8条里五六条都高度相关说明候选质量和排序都健康。把这种分布情况记录下来比死记参数更有价值。6.2 向量模型更新后必须重建索引这个坑我踩得很惨。当时换了更强的向量模型只重新编码了新增文档老索引完全没动。结果线上检索质量断崖式下跌——新旧模型产出的向量空间根本不是一回事新文档和老文档的向量在数学上不可比相似度计算完全失真。所以替换向量模型的那一天必须全量重算所有分块的向量并且建议灰度放量先处理一部分文档对比新旧索引在同一批评测问题上的召回表现确认无异常再全量切换。同理文档更新频繁的业务最好建立增量更新机制但增量更新绝不能跨越向量模型版本。6.3 查询改写低成本高回报的隐藏技巧用户提问是口语化的自然语言文档是书面化技术描述两者之间天然有一道鸿沟。比如用户问数据库连不上咋排查文档里写的可能是数据库连接异常处理。向量模型虽然能理解一定语义但改写后的查询命中率明显更高。我的做法是用一个大模型做查询理解把原始问题改写成更适合检索的形式补全缺失的实体名、把口语换成文档常用术语、识别并保留核心专有名词。改写本身是个轻量调用延迟可控。注意一点改写后的查询只用于检索不要直接把改写结果当作用户问题展示否则体验很怪。6.4 延迟、缓存和降级兜底检索链路一旦加上重排延迟会比单路向量检索翻几倍。线上要求响应快时我对热门问题做结果缓存——相同或近似的问题直接命中缓存跳过完整检索。缓存键建议做归一化处理比如小写化、去标点命中率会高很多。兜底策略也很重要。重排服务偶发超时不能整个接口挂掉我的做法是把超时捕获后降级为召回结果直接按RRF分数排序进上下文虽然精度差一些但保证服务可用。同理向量库如果暂时不可用BM25单路召回的降级方案也必须能顶上。稳定性的优先级永远高于单次回答的完美度。做RAG项目越久我越觉得检索链路才是真正拉开效果差距的地方。模型可以换、提示词可以调但召回和重排的架构和细节决定了一个知识库问答系统能走多远。个人经验是先搭好评测集用数据驱动的方式一步步优化召回和重排这条路虽然前期辛苦但每一步的改进都能稳稳地反映到最终答案质量上。