BM25+向量+Cross-Encoder 怎么组合?

回答与解析

整体架构

Query
  ├─ BM25 稀疏召回
  └─ 向量稠密召回
        ↓
  去重与排名融合
        ↓
  Cross-Encoder 重排小候选集
        ↓
      Top-K

三类组件的分工

• BM25：利用词项匹配、IDF 和长度归一化，擅长专有名词、编号、短语和必须字面命中的查询；速度取决于索引、语料与部署，不能称为“零延迟”。
• 向量召回：用 embedding 表达语义相似，能补充同义改写和字面不重合的结果，但可能弱化精确实体或数值约束。
• Cross-Encoder：联合编码 query-document，通常能刻画更细的交互相关性，但每个候选都要前向计算，只适合重排有限候选。

融合策略

两路召回先各取候选并按文档 ID 去重。RRF 只使用排名，避免直接比较不同系统的分数尺度，是稳健的无监督基线；若有可靠标注，也可对归一化分数做线性融合，或训练学习排序模型。RRF 不是任何场景都优于加权融合。

重排前应保留来源、权限、时间和业务过滤条件。候选规模、RRF 参数和最终 Top-K 都应通过离线 Recall/nDCG、端到端问答质量、延迟和成本共同选择。数据变化时持续监控两路召回贡献、重排增益和失败查询，不能把任一固定组合称为所有 RAG 系统的“黄金标准”。

口语版讲法(约2分钟)

• 本质是混合检索的分层设计
• BM25和向量召回的互补边界
• RRF融合的工程优势
• Cross-Encoder精排的瓶颈与优化
• 落地风险与最终取舍

这套架构分三步：BM25 与向量检索并行召回，候选去重和排名融合，再用 Cross-Encoder 重排有限候选。

BM25 擅长专有名词、编号和必须字面命中的查询；向量召回擅长同义表达与语义近似。两路互补，但都可能漏召或误召。每路取多少候选要根据证据 Recall 曲线、语料规模和延迟预算确定，不能固定为各 Top-100，也不能宣称召回阶段绝不漏任何相关文档。

融合时，RRF 只依赖排名，避免直接比较不同系统的原始分数，是稳健基线。若有可靠标注，也可以用归一化加权或学习排序；RRF 的 k 值和候选截断同样要调优，不是固定六十。

Cross-Encoder 联合编码 query-document，能刻画更细的交互，但每个候选都要前向计算。它不保证在所有领域都最准，也没有统一的单条十到一百毫秒、Top-50 或总延迟二百毫秒标准。候选规模、batch、模型大小和硬件要通过 profile 决定。

通用模型在领域数据上可能失配，但是否微调要由验证集结果决定，不能说不微调就一定崩。训练时应覆盖真实相关样本、线上召回分布中的难负样本和适量易负样本，并防止点击位置偏置与假阴性。

工程上还要防止一条召回链路超时拖垮整体请求，并避免权限过滤在融合后遗漏。我会分别注入单路超时、空结果和重复文档，核对降级结果、去重逻辑、权限边界与各阶段耗时。

最后分别监控 BM25 和向量召回贡献、融合增益、重排增益、Recall/nDCG、端到端答案质量、延迟与成本。这是常见骨架，是否采用仍要由目标数据和端到端评测决定。

关键一句:Cross-Encoder的训练数据构造，特别是负样本采样策略，会影响模型对难分样本的判断力。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们做一个电商搜索，用户搜“苹果手机”，你既要召回精准匹配的iPhone，又要能泛化到“华为手机”这种语义相关的，但预算有限不能全上大模型。你打算怎么把BM25、向量召回和cross-encoder搭起来，既快又准？

2. 问法 2 · 层层追问

   检索系统里召回和排序你是怎么做的？……如果只用BM25，长尾查询效果差，加向量召回又会引入噪声，你怎么融合这两路结果？……Cross-encoder很慢，你会在哪个阶段用它，怎么保证整体延迟可控？

3. 问法 3 · 直球架构

   请设计一个三阶段检索架构，整合BM25、向量召回和cross-encoder重排序。说说每个组件的定位、优势，以及你具体怎么把三者的结果串起来，比如召回后怎么融合、重排序的时机和数量怎么定。