怎么考「Rerank 是什么？有了向量检索为什么还要重排？」
谁在问：一二面；是 RAG 优化题里最常被问「你做了哪些优化」时的标准答案之一
开场怎么问
你们做了 rerank 吗？加它是为了解决什么问题？
换个问法
- 向量检索已经按相似度排好序了，为什么还要再排一次？
- rerank 带来了多少提升？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
为什么不干脆把 top-k 调大，多塞几条给模型？
- 期望
- 上下文预算有限；噪音增多会稀释注意力、诱发 context rot（长输入下准确率非线性下跌）；成本随 token 线性上升。「多送」解决不了「排错」。
- 信号
- 认为「反正模型能读长文，多塞就行」的，没意识到长上下文的效果代价。
cross-encoder 精度更高，为什么不直接用它检索全库？
- 期望
- 见 Q2-12。核心是无法离线预计算——分数依赖 query-doc 这一「对」，query 来了才能算，全库跑一遍在延迟和成本上不可行。所以必须两阶段。
- 信号
- 这题答不上来，说明只知道「加个 rerank」而不懂为什么架构必须是两段。
候选取多少？50 还是 100？依据是什么？
- 期望
- 取决于第一阶段的 recall 曲线和延迟预算——用评测集测 recall@50、recall@100，看拐点在哪；再拿延迟预算反算重排能承受的候选数。答一个数字不给依据的扣分。
- 信号
- 能说出「用 recall 曲线定候选数、用延迟预算封顶」的，是量化决策。
重排模型怎么选？
- 期望
- 通用默认可选 bge-reranker-v2-m3 这类（Apache 2.0、多语言、生态广）；追求中文高精度可上更大参数的模型；不想维护 GPU 可用托管 API。两个坑：许可证（部分高分模型是 CC-BY-NC，商用即侵权）和别盲目追大参数（4B 模型部署成本可能是小模型数倍，通用中文场景小模型往往够用）。还有个细节：多数 cross-encoder 非对称，query 必须放前面。
- 信号
- 提到许可证或 query 顺序的，是真部署过。
加了 rerank 之后 P95 延迟从 800ms 涨到 1.6s，产品说不能接受，怎么办？
- 期望
- 按代价排序给方案——① 减候选数（100→30，先用评测确认 recall 损失可接受）；② 换更轻量的重排模型或量化版本；③ 用 listwise 重排（一次给多篇打分，批量更友好）；④ 流式输出把首字延迟提前，掩盖部分感知延迟；⑤ 分级策略——高频简单 query 跳过 rerank，复杂 query 才走。必须同时给出「每种方案损失多少精度」的量化对比，而不是只报手段。
- 信号
- 直接说「那就去掉 rerank」的，缺乏权衡；能给分级策略的，是有产品意识的工程判断。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 说清两阶段分工：召回求全、精排求准
- 指出「相似度 ≠ 相关性」这个根本原因
- 能描述典型失败形态（正确答案排名靠后被截断）
- 知道 cross-encoder 与双塔的机制差异
- 给出标准配置（召回 50
100 → 重排 510） - 知道只重排候选、不重排全库
- 加分：能给出评测方法和延迟代价，而非只说「效果更好」
- 加分：知道模型选型的许可证坑与 query 顺序细节
参考答案与考察意图面试中途别看这一段
考察意图
三层：① 你知不知道「相似度 ≠ 相关性」——这是重排存在的根本理由；② 你能不能说出「召回求全、精排求准」的分工；③ 你测过提升吗——最后这一问是分水岭，说「加了效果更好」但给不出任何数字或评测方法的，基本判定为照抄最佳实践。
参考答案
60 分答案（及格线）
Rerank 是检索的第二阶段。第一阶段用向量/混合检索从全库快速捞出 50–100 个候选，目标是不漏（recall）；第二阶段用交叉编码器对这几十个候选精细打分，选出最相关的 5–10 条，目标是不排错（precision）。
需要它的原因是：向量检索的相似度是把 query 和 doc 各自压缩成向量后算出来的近似值，相似 ≠ 能回答这个问题。经常出现正确答案确实被召回了、但排在第 14 位，而 prompt 只塞前 5 条——答案就在候选里却被自己扔掉了。
90 分答案（有生产经验的回答）
补四层：
给一个具体的失败形态：用户问「售后维修返厂需要垫付运费吗」，日志显示正确答案排在第 14 位。加大 top-k 到 20 行不行？上下文塞爆了，而且塞进一堆噪音会让模型失焦（context rot）。所以问题不是「多送几条」，而是「在有限名额里排得准」。
说清机制差异：向量检索用的是双塔（bi-encoder），query 和 doc 各自独立编码，doc 向量可离线预算好，所以快；但两者在编码时从未见过对方，判断不了细粒度对应关系。重排用交叉编码器（cross-encoder），把 query 和 doc 拼在一起过模型，注意力充分交互，能识别「问题里的『垫付』和文档里的『先行支付』是一回事」。精度显著更高，代价是无法预计算。
给标准配置和铁律：混合检索召回 top 50~100 → Rerank → top 5~10 → 组装 prompt。铁律是只对 top-k 候选重排，绝不对全库重排——候选数超过一千，纯 cross-encoder 的延迟会急剧恶化。
主动给出评测和代价：rerank 通常是 RAG 里投入产出比最高的单项升级，但收益幅度高度依赖语料，必须用自己的评测集测 NDCG@10 / Recall@5 的提升，别照搬博客数字。延迟代价是重排 50 条增加几十到几百毫秒，对话式产品要评估用户能否接受。