Reranking: bounded candidate scoring with calibrated fallback

A reranker changes the order of candidates supplied by a first-stage retriever. Cross-encoders and LLM judges can model richer interactions, but their benefit, bias, latency, and failure modes depend on data and deployment.

Mental model

• BERT passage reranking scores query-passage pairs jointly and reports dataset-specific ranking gains. Explain cross-encoder interaction without promising a universal lift or latency.
• ColBERT uses late interaction to trade encoding and query-time computation differently. Present architecture choices as measured alternatives.
• BEIR demonstrates that retrieval and reranking generalization varies across heterogeneous datasets. Require domain and slice evaluations instead of one benchmark score.
• LLM judges exhibit position, verbosity, self-enhancement, and reasoning limitations. Red-team listwise rerankers and retain human plus deterministic calibration.

Guarantees and boundaries

• Only IDs present in the first-stage candidate set can be returned.
• A fallback order is explicit and versioned.
• Authorization is reapplied after model scoring.

Diagram scenarios

▶Walkthrough: cross-encoder-rerank (not found)

Two-stage cross-encoder reranking. A first stage supplies recall candidates; a cross-encoder rescores the bounded set.

▶Walkthrough: llm-listwise-evaluation (not found)

LLM listwise candidate evaluation. Listwise ranking can use richer context but inherits model variability, bias, injection, and budget limits.

▶Walkthrough: timeout-fallback (not found)

Timeout and overload fallback. Reranking failure must not turn into an unbounded retry storm or an empty implicit success.

▶Walkthrough: adversarial-candidate (not found)

Adversarial candidate content. A passage can manipulate an LLM reranker or exploit verbosity and position bias.

Architecture decision

Freeze first-stage candidates for comparison, measure ranking metrics and downstream answer quality, and keep a deterministic fallback ordering. Apply authorization before and after ranking, bound candidate and token budgets, and never interpret a model score as a probability without calibration.

Failure modes

• Reranker timeout or overload can consume the whole request budget.
• Candidate text can inject instructions into an LLM-based reranker.
• A model or prompt update can change ordering without a schema error.

Operational checklist

• Freeze candidates when comparing rerankers.
• Measure ranking, downstream answer quality, latency, cost, and bias slices.
• Randomize order and validate returned IDs.
• Document high-risk cases that require human review or fail-closed behavior.

Related concept

[CONCEPT]rag-architecture

Primary sources

1. https://arxiv.org/abs/1901.04085
2. https://arxiv.org/abs/2004.12832
3. https://arxiv.org/abs/2104.08663
4. https://arxiv.org/abs/2306.05685