候选窗口、长文与多样性

本节目标

重排模型的质量不仅由权重决定,还由“哪些候选进入窗口”“每篇文本哪些 token 被看见”“同一来源可占几席”决定。本节用质量—延迟曲线选择窗口,处理长文与重复候选,并避免把多样性当作无条件优化。

Window 决定可达上限

对 window 10/20/50/100 记录:

  • Candidate Recall@window;
  • reranked nDCG/MRR/Precision@top-n;
  • pair/token 数、模型/队列 p95/p99;
  • timeout/fallback、吞吐和成本;
  • 关键 query 切片与答案原始 first-rank。

若 candidate recall 在 20 后几乎不增长,继续扩大只增加计算;若大量正例在 80 后,应先诊断 first-stage,而不是让最贵模型扫描更多噪声。

项目 fixture中 window=6 包含 4/4 正例,candidate recall=1;window=3 只包含 1/4,candidate recall=0.25。任何 rule/model 都不能在 window=3 找到 rank 4~6 的三个正例。

长文为何会“已召回却看不见”

Cross-Encoder/LLM 有 token window,输入通常包含 query + title + body + special tokens。常见失败:

  • query 或 title 占用预算后正文尾部被截断;
  • 统一从尾部截断,但答案分布不总在头部;
  • HTML/navigation 噪声占满窗口;
  • 先合并多个 chunk,再静默截断后面的候选;
  • 训练时是 passage,线上却输入整篇文档。

记录每个 pair 的原始字符/token 数、实际输入、truncated 标志和答案 span 是否保留。只记录 document ID 无法复现模型看到了什么。

三种长文策略

1. 上游形成 passage

在 Chunking策略 中产生可引用、语义完整的段落,reranker 直接判断 query—passage。最容易解释,但相邻 chunk 会重复。

2. 滑窗或结构分块

将长候选分成多个 passage 分别打分,再聚合为 document score:

  • max:保留最强局部证据,也容易被一个误匹配片段抬高;
  • mean:稳定但稀释局部答案;
  • top-m mean:折中,需要选择 m;
  • learned aggregation:表达力强,增加训练和偏差。

必须保留 winning passage/span,便于 RAG 引用和错误分析。

3. 两级重排

先用廉价模型/规则选择文档内 passage,再用强模型判断少量候选。减少 token 成本,但第一级漏掉答案后第二级无法恢复。

当前 Elasticsearch semantic reranking 文档给出长文/分块重排的产品级案例;具体 chunk_rescorer、截断和默认值属于当前产品行为,不能当通用协议。

Chunk 排名与 Document 排名

Qrels 和输出单位必须一致:

  • 若 RAG 消费 passage,评测 passage relevance;
  • 若 UI 展示 document,先定义 chunk→document 聚合;
  • 若同一 document 多段都是证据,不能只保留一个;
  • 若是近重复切片,不应让它们挤掉独立来源。

报告 candidate/chunk Recall、canonical-document Recall 和 evidence-set coverage。一个系统可能 passage nDCG 高,却只返回同一原文的五个相邻段落。

Canonical cap

按 canonical_document_id 限制每个来源最多 m 条:

model order: A-1, A-2, A-3, B-1, C-1
cap=1:       A-1, B-1, C-1
cap=2:       A-1, A-2, B-1, C-1

选择 m 取决于任务:

  • 单事实问答通常 1~2 条足够;
  • 多步骤流程可能需要同一文档多个连续段落;
  • 多跳问题可能需要多个独立来源;
  • 引用审计可能要求保留最具体 span。

Cap 后从后续排序继续补位,不应直接得到不足 top-n 的列表;每个跳过项保留 canonical_cap reason。

多样性不是“越不相似越好”

MMR 等方法在 query relevance 与候选间相似度之间权衡。过强多样化会把低相关但不同主题的文档提上来;过弱则重复。调参时同时看:

  • query relevance;
  • canonical/source coverage;
  • 必需证据组是否齐全;
  • 最终 RAG 正确性/有据性;
  • token 利用率和冲突文档数。

不要在硬权限或有效期上做“多样性放宽”。

下游位置效应

Reranker 排第一不保证 LLM 使用正确。长上下文中信息位置会影响模型使用能力;Lost in the Middle 研究展示了相关信息位置对一些长上下文模型表现的影响。工程上应:

  • 用真实 evidence budget 测端到端;
  • 保留最强证据靠前,但不要复制多次作弊;
  • 检查上下文组装是否又按 source/时间重排;
  • 记录 rerank order 与最终 prompt order;
  • 对冲突证据显式处理,而非仅靠位置压制。

稳定排序

模型分相同时用 first-stage rank,再用稳定 ID。LLM listwise 还需做候选置换:

  • top-n overlap;
  • Kendall/Spearman 等 rank correlation;
  • 关键正例位置方差;
  • 输出解析失败率。

回放必须锁定候选文本/revision、模型/prompt、batch、window、tie-break 和后处理。

常见错误与排查

  • Window 扩大但质量不升:看 candidate recall 是否已饱和;
  • 正例在窗口内仍低分:确认答案 span 未截断;
  • 同源占满上下文:引入 canonical ID 与 cap 实验;
  • Cap 后结果不足 top-n:从后续候选继续填充;
  • 多样化伤害相关性:报告 relevance 与 evidence coverage;
  • Rerank 顺序与 prompt 顺序不同:记录两阶段 order;
  • Listwise 排名不稳定:置换/重复测试并限制用途。

练习

  1. 对 window 10/30/100 设计 candidate recall、nDCG、p99 和成本表;
  2. 构造答案分别在长文头/中/尾的三条正例;
  3. 比较 max、mean、top-2 mean 聚合;
  4. 给同一文档 5 个相邻 chunk + 3 个独立来源,测试 cap=1/2/3;
  5. 定义一个必须同文档两段才能回答的例外;
  6. 比较 rerank order 与最终 prompt order 的端到端结果。

掌握检查

  • Window 由质量—延迟曲线决定,不靠直觉。
  • 截断、实际输入和命中 span 可追溯。
  • Passage/document qrels 与聚合单位一致。
  • Canonical cap 能补位并保留跳过原因。
  • 多样性同时评测 relevance 与 evidence coverage。
  • Rerank order、prompt order 和置换稳定性都有记录。

下一步:训练数据与 Hard Negatives。

参考资料

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