Reranker 接入后如何控制检索延迟预算

Reranker 接入后最容易出现的误区，是把它当成“召回结果再调用一次模型”，却没有给这次调用单独划出延迟预算。更稳妥的做法是：向量召回先提供有限候选，Reranker 只处理候选上限内的 query-text 对；当剩余时间不足时，直接返回原始召回结果，而不是让整个请求一起超时。

先把 Reranker 放进明确的延迟预算

Cross-Encoder（常见的 Reranker 形态）会把查询和文档组成文本对后计算相关性分数。它通常比双编码器更慢，所以适合放在召回后的 top-k，而不是对全量文档逐条评分。Hugging Face 的 Text Embeddings Inference 也把重排暴露为独立的 /rerank 能力，输入就是一个查询和候选文本列表。

预算可以先按请求链路拆成四块：向量召回、Reranker、后处理、网络与排队。示例中若接口总预算是 300 ms，不要直接把 300 ms 都交给模型，而应给重排预留一个可回收的窗口，例如 120–180 ms，并把超时、序列化和下游生成留在预算表里。这个数字只是设计示例，真正阈值要由线上 p95/p99 反推。

候选数和输入长度决定重排成本

一次重排的成本，至少受候选条数、每条文本长度和批量大小影响。候选从 20 条增加到 100 条，并不是简单多了几行数据，而是多了大量 query-text 配对计算；长文档还会推高 token 化、显存占用和排队时间。因此可以先用召回分数裁剪候选，再对文档做按字段的长度上限，标题、摘要和必要片段优先于整篇正文。

参数不要只保存一组全局常量。低延迟查询可以使用较小的候选上限，复杂查询或召回置信度不足时再适度放宽。批量也要以实际服务端吞吐为准，过大的 batch 可能减少请求次数，却把单批尾延迟和显存峰值一起抬高。

用剩余预算决定重排和降级出口

不要在请求开始时无条件调用 Reranker。更实用的策略是读取 deadline，扣除已消耗的召回和网络时间，再根据剩余预算决定候选上限；剩余预算低于模型调用的安全阈值时，返回原始召回结果，并在日志中记录降级原因。

from time import monotonic

def choose_rerank_policy(deadline_ms: int, spent_ms: int, recall_count: int) -> dict:
    # 先扣除已经消耗的时间，避免把整个接口预算交给重排模型
    remaining_ms = max(0, deadline_ms - spent_ms)
    if remaining_ms 

这个策略的关键不是“80”或“8”本身，而是把策略写成可观测的决策：日志同时记录剩余预算、候选数、文本截断结果、模型耗时和是否回退。否则只看到接口变慢，却不知道是召回变慢、模型排队还是输入过长。

用尾延迟而不是平均值调参

验证时至少分开看召回耗时、Reranker 推理耗时、排队耗时和总耗时，同时记录 p50、p95、p99。平均耗时下降并不代表体验变好；如果 p99 变长，在线请求仍会频繁触发超时。建议先固定模型和数据集，只改变候选上限、最大长度或 batch size，一次只动一个变量。

如果 Reranker 超时，优先返回原始召回并标记 rerank_degraded=true。如果相关性下降，再区分是候选裁剪过早、文本片段不完整，还是模型本身不适合当前语言和领域。只有在输入边界稳定后，比较更大的模型或更复杂的推理服务才有意义。

相关问题

Reranker 应该处理多少条候选？

没有通用固定值。先从能稳定满足 p95 的小 top-k 开始，再以相关性指标评估放宽候选是否真的带来收益。

批量越大，延迟就一定越低吗？

不一定。批量可能提高吞吐，但也可能增加单批等待、显存峰值和 p99；应同时看吞吐、p95、p99 和超时率。

Reranker 超时后能否重试？

在线检索通常不建议无条件重试。一次重试会继续消耗同一个 deadline，优先返回原始召回；只有剩余预算明确足够时才考虑有限重试。