边界与候选集

本节目标

在选模型前，定义 reranker 能看到什么、必须返回什么，以及失败时允许退回哪里。你将学会计算 candidate recall、区分四个候选预算，并建立不会因模型故障而扩大权限的输入/输出契约。

Reranker 能改什么

给定同一候选集合，它可以：

• 改善前排 query—document relevance；
• 区分同主题但答非所问、数字/否定冲突；
• 给出模型分、等级或 pair/list 顺序；
• 在相关性之后应用可审计多样性/业务策略；
• 淘汰低分候选或触发“无足够证据”。

它不能：

• 找回未进入 candidate window 的文档；
• 修复未入库、错误 Chunking 或错误权限元数据；
• 证明一篇文档事实正确、来源可信或当前有效；
• 替代生成阶段的引用和回答验证；
• 让越权文档因为“很相关”而可见。

输入契约

每次调用至少包含：

类别	字段
Query	query ID、original/rewrite、语言、as-of time、query revision
身份与过滤	tenant、授权摘要、status/effective-time 已执行证明
Candidate	稳定 ID、canonical source ID、title/body、source revision
First stage	channel、rank、score、fusion/index/model revision
Rerank	model/prompt/tokenizer revision、window、timeout、batch policy

模型输入不要包含不必要的私密元数据、凭据或完整 ACL。身份只用于服务端过滤与审计，不作为可被 prompt 改写的自然语言。

Candidate Recall 决定上限

先冻结同一数据快照、测试主体、时间与授权策略 revision。设 $R_{\mathrm{eligible}}$ 为该主体本应可访问的 qrels 正例，$C_w$ 为硬过滤后的窗口候选：

$$CandidateRecall@w=\frac{|R_{\mathrm{eligible}}\cap C_w|}{|R_{\mathrm{eligible}}|}$$

若相关文档排在 first-stage 第 80，而 window=20，任何重排模型的 top-n 都不可能包含它。若 $R_{\mathrm{eligible}}$ 为空，应转入无答案/越权不得返回的安全断言，不要把正确的空结果计作 0 candidate recall。诊断时可同时看：

• End-to-end：对所有 query 报告 final nDCG/MRR；
• Conditional：只看窗口内存在正例的 query，分析模型排序；
• Candidate recall：证明 first-stage/window 的可达上限。

只报 conditional 会隐藏上游漏召回；只报 end-to-end 又可能把上游问题误归给模型。三者同时保留。

四个预算不要都叫 top-k

First-stage retrieval window: 100
        ↓
Rerank input window: 40
        ↓
Rerank output top-n: 10
        ↓
RAG evidence/context budget: 5 passages / 4000 tokens

此外 Cross-Encoder 每个 pair 有 tokenizer 最大长度，LLM listwise 有总上下文长度。每个预算影响不同质量和成本，应单独命名、记录和实验。

硬过滤应先于窗口

正确顺序是：

1. 从可信身份生成 tenant/ACL；
2. 排除 draft、expired、deleted 与 wrong-tenant；
3. 对安全候选形成 first-stage 排名；
4. 取 rerank window；
5. 模型重排同一 ID 集；
6. 应用受控 canonical cap/业务规则。

若先全局取 20 再过滤，授权候选可能因越权候选占位而进不了窗口；模型服务、日志和缓存也可能已接触敏感正文。项目在 reranker 入口再次校验，是 defense in depth，不代表可省略上游过滤。

输出契约

正常输出必须满足：

• 每个输入 candidate ID 恰好出现一次，或明确声明允许 partial 的语义；
• 不得出现未知 ID、重复 ID 或遗漏；
• score 类型有限，不允许 NaN/Infinity/布尔伪装数值；
• features/reasons 使用 allow-list 且可序列化；
• 模型、prompt、tokenizer 和 schema revision 明确；
• 排名平局用稳定 first-rank/ID 打破；
• 输出与 request/trace ID 可关联。

模型返回空列表不应被解释为“全部不相关”，除非 API 明确定义且经过校准。更安全的默认是 invalid output → fallback。

Fallback 也是正式产品路径

常见 fallback 是“同一安全 window 的 first-stage 顺序”。它必须：

• 不重新查询未经授权的候选；
• 保留 hard filters 与有效期；
• 确定、快速且已离线评测；
• 输出 rerank_applied=false 与原因；
• 限制重试，避免 deadline 已耗尽后继续放大延迟；
• 对 timeout、5xx、rate limit、空/畸形响应分别计数。

返回空结果可能比 first-stage fallback 安全，但会显著降低可用性；选择应按业务错误成本和本地评测决定。

透明审计

每个最终候选保留：

• first-stage rank/score/channel；
• rerank input position；
• model score/label；
• final rank；
• canonical grouping/业务规则 reason；
• 是否 fallback 及原因；
• 所有相关 revision 和耗时。

不要覆盖 first-stage score。否则无法判断收益来自召回、模型还是后处理规则。

常见错误与排查

• 答案常在 window 外：先修召回或扩大可负担 window；
• 模型输出未知 ID：严格 schema + exact ID set 校验；
• fallback 又查一次全库：只用已过滤窗口；
• 条件评测很好、总体不变：检查 candidate recall；
• 模型前已截断正文：记录 token 数和截断字段；
• 第一阶段 provenance 被覆盖：三套 rank/score 分开保存；
• timeout 重试数过多：用总 deadline、单次预算和断路。

练习

给定 100 个候选、4 个 qrels 正例位于 rank 2/18/47/80：

1. 计算 window 10/20/50/100 的 candidate recall；
2. 设计输入 schema 和 exact-output-ID 校验；
3. 分别定义 rerank top-n 与 RAG evidence budget；
4. 写 timeout、空响应、重复 ID、未知 ID 的 fallback；
5. 证明 fallback 只含已授权候选；
6. 列出需要保存的三阶段 rank/score。

掌握检查

• Reranker 的能力边界与上游/下游责任清楚。
• Candidate recall、conditional 和 end-to-end 指标同时报告。
• 四个候选/上下文预算独立命名。
• 权限、状态和时间在窗口前执行。
• 输出 ID、数量、分数、版本和 tie-break 有严格契约。
• Fallback 只重用安全窗口且可观测。

下一步：Cross-Encoder 重排。

参考资料

• Nogueira & Cho, Passage Re-ranking with BERT
• Thakur et al., BEIR
• Elasticsearch: Ranking and reranking

来源获取日期：2026-07-14。返回 Reranking 目录。