指标、延迟、成本与降级

本节目标

一个 reranker 只有在“候选有答案、排序变好、尾延迟和成本可接受、失败时仍安全可用”时才值得上线。本节把质量、系统、失败与端到端指标组织成发布门禁,并要求 fallback 作为常态流量路径预先评测。

质量指标分层

层指标回答的问题
First stage/windowCandidate Recall@w正例是否进入模型视野
RankingMRR@k第一条相关证据多早出现
RankingnDCG@k分级相关文档是否靠前
Output purityPrecision@ktop-k 中相关比例
Diversitycanonical/source coverage是否被同源近重复占满
Securitymust-not/越权数是否违反 tenant/ACL/status/time
Downstream有据正确、引用、任务成功排序收益是否被 RAG 真正使用

比较至少包括:

  1. First-stage 原顺序;
  2. 新 reranker;
  3. 旧 reranker(若有);
  4. 每种 fallback;
  5. 去重/业务规则前后;
  6. 关键 query 切片。

Candidate recall 低时,先修召回或 window。只在“窗口有正例”子集报告 conditional nDCG 可诊断模型,但发布仍看全 query end-to-end。

评测器不能替 first-stage 补候选

Sentence Transformers 的 CrossEncoderRerankingEvaluator 在传入 documents 时,当前默认会把所有正例补入重排序列表,即使它们原本不在传入候选中。这类结果只能诊断“正例可见时”的排序上界,不能作为端到端发布指标。发布评测必须冻结真实 first-stage candidate IDs 与 window,先报告 Candidate Recall,并确认评测配置没有补入漏召回正例;否则会把召回缺口伪装成 reranker 收益。

配对差异而非只看均值

同一 query 上比较 before/after:

  • 改善、持平、退化各多少;
  • 高风险 query 是否退化;
  • 正例从哪个 first-rank 移到哪个 final-rank;
  • 失败是否集中在语言、长度、数字/否定或某来源;
  • bootstrap/随机化估计差异不确定性。

一个总体 nDCG 提升可能由大量简单 query 获益、少数关键财务 query 严重退化造成。发布门禁应包含“不允许退化”的切片。

系统指标拆开测

端到端 rerank latency 包含:

候选准备/序列化
    + 网络/队列
    + tokenizer
    + 模型推理
    + 输出解析/校验
    + 后处理/多样性

报告 p50/p95/p99/max、timeout 和队列深度,并按:

  • candidate window;
  • query/body token 桶;
  • batch size/并发;
  • 模型/硬件/区域;
  • normal/fallback;
  • cache hit/miss;
  • 租户或优先级。

单机离线每秒 pairs 不等于多租户在线 p99。

成本模型

Cross-Encoder 本地部署主要受 pairs × tokens、硬件、常驻副本和峰值冗余影响;托管/LLM reranker 可能按请求、文档或 token 计费,并有网络与重试。至少估算:

  • 平均/峰值 query rate × window;
  • 输入 token 分布;
  • 每次调用批量上限;
  • retry/fallback 和 shadow 双跑;
  • 最小副本、灾备和预热;
  • 缓存命中与失效;
  • 日志、评测和数据保留。

价格和限额是动态产品事实,交付时记录获取日期与合同/版本;不要把教程数字写进长期容量规划。

失败矩阵

失败检测默认动作记录
总 deadline 不足剩余时间门禁不调用,直接 fallbackdeadline_exhausted
Timeout客户端/服务端超时有限重试或 fallbacktimeout
Rate limit/过载明确状态码/队列不放大重试,熔断rate_limited
5xx/模型未加载错误码/健康检查fallback,告警provider_error
空响应schema 校验invalid-output fallbackempty_output
漏/重复/未知 IDexact-set 校验invalid-output fallbackid_contract
NaN/Inf/错误类型数值校验invalid-output fallbackscore_contract
Revision 不一致response metadata拒绝并 fallbackrevision_mismatch
全候选被硬过滤safe window 为空返回安全空结果empty_safe_window

不同失败原因可统一回退同一顺序,但监控必须分开,才能判断容量、代码、供应商或数据问题。

Fallback 设计

最常见路径是安全 first-stage ranking:

  1. 硬过滤已执行;
  2. 取同一 candidate window;
  3. 保留 first-stage rank 与稳定 tie-break;
  4. 可继续执行确定性 canonical cap;
  5. 输出 rerank_applied=false、fallback_reason;
  6. 不把模型缺失伪装成正常低分。

Fallback 也要测 MRR/nDCG、端到端回答、安全、p99 和峰值容量。若模型服务故障会把全部流量压回搜索后端或另一服务,必须做容量演练。

重试、缓存与断路

  • 以总 request deadline 为准,不是每层各自完整 timeout;
  • 只对明确 transient error 重试,设置 jitter 和次数;
  • 评分请求通常无外部写副作用,但会重复费用/资源;
  • 断路器防止故障时排队雪崩;
  • 缓存 key 包含 query、候选 ID + source revision、模型/prompt/schema、规则和必要授权摘要;
  • 不跨权限复用包含敏感候选的响应;
  • 模型升级前预热,避免首批请求集中 timeout。

发布流程

  1. 离线:固定 query/qrels、first-stage snapshot 与候选文本;
  2. 回放:正常、每种失败、不同 window/长度/并发;
  3. Shadow:新模型不影响用户,比较 score/order/latency;
  4. Canary:少量真实流量,按关键切片和 fallback 监控;
  5. 逐步扩容:确认队列、成本和下游收益;
  6. 回滚:模型、prompt、规则和开关可独立恢复。

一张门禁表至少包含 candidate recall、总体/关键 nDCG、不退化切片、p95/p99、timeout/fallback 率、每 query 成本、安全零违规和端到端回答指标。具体数值来自本地 SLO,不由本文假设。

常见错误与排查

  • 只报 reranked nDCG:加 first-stage、fallback 和 candidate recall;
  • 平均延迟达标但 p99 爆炸:按 token/window/队列分桶;
  • 模型失败返回空列表:比较安全 first-stage fallback;
  • 重试放大故障:总 deadline、jitter、断路和容量保护;
  • Cache 命中旧正文:key 包含 source/model/prompt revision;
  • 离线提升、RAG 不变:检查 evidence budget 与 prompt order;
  • 关键切片退化被总体掩盖:设置硬门禁。

练习

写一张上线门禁:

  1. Candidate Recall@30 与 nDCG/MRR/Precision@8;
  2. 财务、权限、否定和长文切片不退化;
  3. p95/p99、timeout、fallback 和每 query 成本;
  4. 四类 invalid output 的 exact 校验;
  5. 断路时 fallback 容量演练;
  6. Shadow/canary 与一键回滚触发条件。

掌握检查

  • 质量指标按 window、ranking、security、downstream 分层。
  • First-stage、新模型、旧模型和所有 fallback 同场比较。
  • 延迟拆到队列/tokenizer/inference/解析/后处理。
  • 成本覆盖峰值、副本、重试、shadow 和缓存。
  • Empty/unknown/duplicate/NaN/revision mismatch 都有校验。
  • Fallback 安全、确定、可观测且完成容量/质量演练。
  • 发布门禁包含关键切片和端到端收益。

下一步:项目:可降级规则重排器。

参考资料

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