向量库混合检索(稠密+稀疏)与重排落地

日期:2026-08-04

一、项目背景

我们底座的向量检索在支撑一个企业知识库问答时,遇到典型的"语义和关键词打架"问题:用户搜"SO202606180023 订单号",纯向量召回回来的全是语义相近的"订单"文档,真正的那笔订单反而排不到前面;反过来搜"怎么退款",又需要语义理解而非字面匹配。单一稠密向量检索对专名、编号、产品型号这类"字面即答案"的查询很吃亏,召回质量忽高忽低。我们这个项目要做的,是把稀疏(关键词)和稠密(语义)两套召回融合起来,再用重排把结果拉正,让两种查询都能被正确处理。

二、落地场景

能力落到了我们向量数据库层与 RAG 检索流水线。在线问答时,query 同时走两条路:一路用 BM25 这类稀疏检索命中字面关键词,一路用 embedding 做稠密近邻检索;两路 top-k 合并后做去重,再送一个轻量重排模型按"相关性"统一打分,最终返回 top 结果给生成环节。对编号、型号、法规条款这类查询,字面召回被显著前置;对自然语言问题,语义召回主导。用户侧感知是:问什么都能拿到对的文档,不再出现"明明有答案却搜不到"的尴尬。

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

第一难是融合策略。简单拼接会互相污染,我们用了"倒数排名融合(RRF)"先给两路结果各算一个融合分,避免分数量纲不一致导致的偏置。RRF 只看排名不看分数,天然适合异构召回的合并。第二难是重排模型冷启。我们没有现成标注,用"用户点击与采纳"作为隐式正样本,初期用通用重排模型兜底,积累数据后再微调领域版,避免等项目等到天荒地老。第三难是专名召回精准。我们对订单号、规则号做 tokenizer 特殊处理,让稀疏检索把它们当整体词而非切碎,召回精度明显提升,这是纯稠密检索怎么调都补不回来的短板。

案例片段(已脱敏): 混合检索配置: dense_topk: 50 sparse_topk: 50 fusion: rrf, k=60 rerank_model: cross-encoder-zh-base 查询日志对比: q="R_1023 规则说明" 纯稠密 Top1: 一篇讲"风控体系"的泛文 (命中弱) 混合+Rerank Top1: 规则库条目 R_1023 原文 (命中强)

四、效果数据

脱敏评测集(含百分之三十专名类 query)上,混合检索的 Top1 命中率从纯稠密的约百分之六十八提升到约百分之八十九;专名类 query 的 Top3 命中率从约百分之五十四升至约百分之九十二;用户点击率整体提升约百分之二十三;重排引入后,无效首条(答非所问)占比从约百分之十九降至约百分之七。这组数字说明,融合与重排不是锦上添花,而是把检索从"能用"拉到"好用"的关键一跃。

五、可复用经验总结

其一,语义和关键词是互补不是替代,凡是有编号、型号、术语的场景,稀疏检索必不可少,删掉它等于主动放弃一类查询。其二,两路分数量纲不同,RRF 这类不依赖绝对值的融合比加权求和稳,少调参还更鲁棒。其三,重排是效果放大器,但冷启别等标注,用点击采纳当弱监督先跑起来,数据滚起来再迭代。其四,专名要做 tokenizer 定制,否则稀疏检索也会被切碎失效,这是隐性坑。其五,把"命中类型"埋进日志,后续能精确知道是哪一路救了场,指导后续调参和资源配置。

附:规模化落地的几点工程取舍

混合检索规模化时,第一关是资源。稠密和稀疏两路同时跑,算力开销接近翻倍,我们对稀疏路用更轻的索引、对稠密路做向量量化压缩,整体成本压回可接受区间。第二是 RRF 的 k 值,k 太小排名靠后的融合分过高、太大则区分度弱,我们在脱敏集上扫了一遍,定在六十附近最稳。第三是重排模型的部署,cross-encoder 虽准但慢,我们只在 top 五十里跑重排,更上层用双塔粗排,延迟和效果折中得最好。第四是专名 tokenizer 的维护成本,新业务线不断带来新编号规则,我们把正则做成可配置热加载,运营自助加,不必每次改代码发版。第五是反馈数据的回流,点击和采纳要能反推到具体哪一路命中,我们给每条结果打"来源标签",调参时一眼看清谁在贡献。检索系统规模化,拼的不是单点精度,而是这套"两路融合加重排加反馈"的工程闭环是否扛得住多样化的真实查询。

附二:给同行落地混合检索的一点提醒

第一,稀疏检索千万别省,凡是有编号型号术语的场景,它是稠密检索怎么调都补不回来的。第二,融合用 RRF 这类不依赖分数量纲的方法,比加权求和省心且稳。第三,重排要分层,粗排用快模型、精排用准模型,全用 cross-encoder 延迟扛不住。第四,专名 tokenizer 一定要可配置热加载,新业务线不断带来新规则,写死在代码里会拖垮迭代。第五,反馈数据要能反推到具体哪一路命中,否则你永远不知道是谁在贡献效果,调参全靠蒙。第六,重排模型冷启别等标注,用点击采纳当弱监督先跑,数据滚起来再微调。检索系统的效果不是调出来的,是这套融合重排反馈闭环跑出来的,架构对了,精度自然上来。