RAG检索重排序与召回质量优化落地

日期:2026-08-26

一、项目背景

我们做 RAG 问答时,检索召回一直靠向量相似度硬排,top-k 里常混着相关但次要的文档,真正该用的那篇被挤到后面。精排模型没接,答案经常被噪声带偏,用户问售后政策,结果召回了一堆营销软文,答非所问。我们查了一批 badcase,发现超过三成的回答偏差能追到召回阶段,检索把不相关的文档给了生成,后面再怎么写都救不回来。团队一开始以为问题在生成侧,调提示词调了半天没用,后来才定位到是召回质量,这一课学得有点晚。更现实的是,随着知识库从几千篇涨到几万篇,向量召回的命中率不升反降,长尾问题越来越容易答偏,业务方开始质疑这套系统的可用性,我们再不解决召回,前面的生成优化全白费。

二、落地场景

我们在向量召回之后加了一道重排序。向量库先粗召回 top-100,再用 cross-encoder 做精细打分,把真正相关的文档往前推,噪声往后挪,最后取 rerank 后的 top-k 喂给生成。评测侧我们建了一套召回质量集,人工标注哪些文档该进上下文,用来算 top-k 命中率和答案相关率,每次改召回策略都跑一遍。badcase 归因也接进来了,哪些问题答偏了,反查是不是召回没拿到对的文档,形成改进闭环。我们还加了重排阈值,分数太低的文档直接不进上下文,宁缺毋滥,避免噪声污染。此外,重排结果也回了检索侧,哪些文档经常被排到前面但人工标注不该进,反过来修向量索引的 Embedding,形成检排互相喂的闭环,知识库越大这套越值钱。

三、关键技术挑战与解决思路

重排序的开销是个矛盾。cross-encoder 比向量快不了多少,对 top-100 全量重排,首字延迟直接翻倍,用户等不及。我们试过只重排 top-20,成本和质量平衡得最好,粗召回的百篇里真正有竞争力的也就前二十,后面重排也是浪费。召回噪声的另一头是切片粒度,文档切太碎,相关片段被拆散,重排也拼不回来,我们回头调了切片策略,长文档按语义边界切,保留上下文。评测集的维护最容易被忽视,标注完了就不动,语料一更新评测就失真,我们改成每周补标注,让评测集跟着业务走。阈值调优踩过坑,一开始阈值定太高,把 borderline 的相关文档也砍了,答案变干瘪,后来放宽到中等分数都保留才自然。Embedding 回流也踩过坑,早期直接拿重排结果覆盖向量召回,结果把一些长尾但正确的文档排没了,后来改成只在评测集上验证再灰度,才没伤到线上。

案例片段(已脱敏): 重排序管道与评测配置(示意): recall.topk_raw: 100 rerank.model: cross_encoder rerank.topk: 20 rerank.threshold: medium eval.weekly_refresh: true 某问答场景接入 rerank 后答案相关率从约 67% 升到 89%,badcase 下降约四成,首字延迟仅增加约 80ms,长尾问题命中率提升约一成五。

四、效果数据

我们主要看答案相关率、badcase 下降、重排时延和 top-k 命中率。相关率从不到七成涨到近九成,答非所问明显少了;badcase 降了四成,用户投诉跟着下来。重排时延控制在百毫秒内,因为只排前二十,用户体验几乎无感。top-k 命中率提升说明对的文档更容易进上下文,生成侧的压力也小了。文中数据为项目复盘口径,已做脱敏。我们后来把 rerank 的打分接到了反馈闭环,用户点了没帮助的问题自动进 badcase 库,评测集自己长大,召回质量越跑越稳。知识库涨到几万篇之后,这套重排加回流的机制成了刚需,没有它长尾问题基本答不准,业务方反而更依赖系统了。

五、可复用经验总结

RAG 的答案质量七成在检索,不在生成,我们就是一开始搞反了,在提示词上折腾半天是走弯路,先把召回做对最划算。重排别贪多,对 top-20 做就够,全量重排纯属烧延迟,用户感知不到那点质量差。切片粒度是重排的前置条件,文档切碎了重排也拼不回语义,长文按边界切比按字数切聪明。评测集必须持续养,语料在变评测也得跟着变,否则优化都是盲调,我们靠每周补标注才稳住。我现在的判断是,召回质量得有评测集托底,检排互相喂比单点优化走得更远,但回流要灰度验证,别拿线上当试验田,那次覆盖向量召回的事故够我们记很久。

我们也试过用重排打分做检索侧的负反馈,把经常被排到前面但人工判不相关的文档降权,向量索引慢慢自我修正,长尾问题越跑越准。知识库运营那边终于有了抓手,不像以前只管往里灌文档。

重排模型本身我们也换过几版,从双塔到 cross-encoder,延迟和质量的平衡点一直在调,后来固定到中等规模的中文精排模型,效果和开销都合适。我们给重排加了缓存,同样 query 的 rerank 结果短时复用,热点问题不重复算,成本又降了一截。

重排的上线我们也做了灰度,先放百分之十的流量验证相关率确实涨了再全量,没敢一次性切。

这套机制跑了一个季度,相关率稳定在九成上下,没再掉回去。