混合检索调优:用失败样本决定召回与重排策略 @ Lin | 2026-04-08T10:00:00+08:00 | 3 分钟阅读 | 更新于 2026-09-12T10:00:00+08:00

区分召回失败和排序失败,用对照实验判断关键词、向量和重排分别带来什么。

本文于 2026-09-12 补充整理,按 2026-04 专题归档。示例为方案设计,参数用于说明方法,不代表已上线项目或实测成果。

先找出答案在哪里丢失

用户询问“发布时出现 E1042 怎么处理”,关键词检索可能擅长定位错误码;用户换成“镜像拉取失败且凭据过期”,语义检索可能更容易找到相关段落。两者互补的前提是知道各自解决了哪些失败。

先把失败划为三类:正确文档根本没召回;文档已召回但排序太靠后;证据进入上下文后答案仍然错误。第三类不是增加 Top-K 就能解决的。

建立可解释的混合基线

候选方案是关键词与向量各召回一组结果,按切片 ID 合并,再用倒数排名融合形成统一候选集。应用层的融合公式可以写为:

score(d) = Σ 1 / (k + rank_i(d))

rank_i 从 1 开始,某一路没有召回该文档则该路不贡献分数。k 是平滑参数,必须记录在实验配置中。它的用途是减少不同检索器分数尺度不可直接比较的问题,并不保证排序必然优于单路检索。

假设采用 k=60,文档 A 在两路分别排第 1 和第 8,得分约为 0.0311;文档 B 只在一路排第 2,得分约为 0.0161。这个算例只是解释排序机制,不能作为效果数据。

重排解决另一层问题

融合后可把前 20 条候选交给重排器,最终选 5 条供回答使用。这些数值仅是对照实验配置,不是固定建议。重排器只能调整已有候选,无法凭空找回没有召回的证据。

重排超时时,可以退回融合排序,但要记录发生降级。若任务要求高精度证据,例如解释生产环境操作限制,降级后也可能需要返回部分结果或请求人工确认。

对同一文档的多个相邻切片,应限制重复占用上下文。否则排名前五可能只是同一段文字的五个近似版本,看似相关却缺少另一份关键规范。

评测要同时覆盖质量和耗时

对照组 需要回答的问题
关键词 错误码、版本号能否找到
向量 同义改写是否改善
混合 两类能力是否互补
混合加重排 排序收益是否值得新增成本

Recall@K 可以定义为前 K 个候选中命中的标注相关文档数,占全部标注相关文档数的比例。若每个问题只有一个必要证据,命中率更直观。标注不完整时,不能把未标注但正确的文档直接当作错误。

固定同一知识快照和用户权限,保存每一步的候选 ID、排名与耗时。不宜在同一实验里同时更换 embedding 模型、切分方式和重排策略,否则不知道收益来自哪里。

不要忽略权限过滤的影响

权限约束应在候选产生和进入模型前保持有效,不能先全库召回再把越权内容发给外部重排服务。近似向量索引下,过滤还可能影响可返回结果数量;具体行为需要结合所用引擎和执行计划确认。pgvector 的过滤说明可作为其中一种实现的参考。

检索效果应分别观察大租户、小租户、权限很窄的用户。全库 Recall 很高,而小权限集下几乎找不到结果,仍然是系统失败。

最终值得写进复盘的是“某类查询在固定实验条件下如何变化”,而不是未经实验就宣称混合检索提升了百分之多少。


查看系列导读与阅读路线

© 2019 - 2026 Lin 的博客

Powered by Hugo with theme Dream.

avatar
关于我

Lin 的 ❤️ 博客

技术专题:Java Agent 工程化:从知识库问答到可靠业务执行。围绕 RAG、工具治理、任务恢复与 Java 平台架构整理设计思路和验证方法。

记录一些 🌈 生活上,技术上的事

  • 🛠️ 技术阵地: 深耕 Java 开发 ,目前向 AI 应用领域探索与拓展。这里主要记录我从后端架构到 AI 赋能的进阶之路、技术思考以及日常的 debug 血泪史。始终致力于写出优雅且没有 bug 的代码(尽量)。
  • 🌈 生活侧写: 偶尔脱下极客的外衣,我也会在这里分享生活中的灵光一现。不管是好用的效率工具,还是周末的一场骑行,都是构成我真实生活的一部分。