Evaluating Rerankers with NDCG, Recall, and Latency Gates

A reranker should earn its place by improving the order of evidence that already exists in the candidate set, without violating the response-time budget. If candidate generation, corpus contents, or judgment coverage changes at the same time, a higher NDCG value cannot be attributed to reranking. If only successful low-load calls are timed, the latency result is equally misleading.

The evaluation contract must isolate stages. Measure candidate recall before reranking, top-rank quality after reranking, and complete request latency under normal and degraded conditions. Then apply a gate that refuses to trade a critical retrieval regression for an unrelated average gain.

Define the reranking stage contract

Document what enters and leaves the stage. Inputs normally include a query, an ordered candidate list, candidate text, metadata, and perhaps first-stage scores. Outputs may be a full reordering, a shortened list, or scores used by another fusion rule. State maximum candidates, text truncation, score direction, tie handling, deduplication, and timeout behavior.

The distinction between reordering and filtering matters. If a score threshold removes documents, the stage can reduce recall even when ordering improves. If the reranker receives only a truncated prefix, it cannot rescue a relevant item below that prefix. If it can request new candidates, it is no longer a pure reranker and needs a broader end-to-end evaluation.

Assign separate version IDs to the first-stage retriever, corpus snapshot, candidate text builder, reranker configuration, and final selection policy. The LangChain retrieval documentation describes retrieval pipelines as composed components; preserving those boundaries in telemetry lets a regression be assigned to candidate generation, scoring, or selection.

Measure the candidate recall ceiling

Before reranking, calculate recall at the candidate depth N. For each query, ask whether every required evidence item appears anywhere in those N candidates. This is the ceiling imposed on a pure reranker. When candidate recall is zero, post-rerank NDCG cannot diagnose the absent source.

Report candidate recall by query slice and by first-stage rank band. A relevant item that usually enters between ranks 80 and 100 creates a different engineering choice from one that never appears. The first may justify a deeper reranker input if latency permits; the second requires indexing, filtering, query, or retriever work.

Keep candidate sets identical for the baseline and candidate reranker comparison. Persist ordered IDs and content hashes, then replay them. A live index can change between calls, and that drift would contaminate the attribution. Run a separate full-pipeline test after the controlled replay passes.

Build graded and complete-enough judgments

Use relevance grades that match the product question. A passage that fully answers, partially supports, is merely topical, or contradicts the applicable policy should not necessarily receive equal gain. Define the gain mapping before test results are visible. Preserve unknown and abstained labels instead of coercing them to zero.

Construct judgment pools from the first-stage rankings, baseline order, candidate order, and independent retrieval variants. Assessors should be blind to system and rank. Report judgment coverage at candidate depth and final context depth because a new reranker may promote previously unjudged documents.

The Ragas metrics documentation separates context-focused evaluation from response-focused evaluation. Apply rank metrics to evidence first. Answer groundedness and correctness can be a downstream validation, but they should not replace direct diagnosis of the retrieval stage.

Protect query, document, and tuning splits

Group paraphrases, conversations, generated variants, entities, and source families before splitting. A reranker trained on one chunk and tested on a nearly identical neighboring chunk can appear to generalize while recognizing source-specific wording. Keep generated query seeds and their variants in the same partition.

Use development data for candidate depth, maximum text length, score threshold, batching, fusion weight, and any calibration. Freeze those choices before opening test judgments. If test failures are used to revise the reranker, roll them into the next development version and create a new sealed test panel.

Corpus versions also require separation. When a source changes, its old and new chunks should not straddle partitions in a way that exposes the expected distinction. Temporal and supersession tests need explicit as-of labels rather than random assignment.

Use NDCG, recall, and reciprocal rank deliberately

NDCG at k is suitable when relevance is graded and earlier positions matter. Specify the gain assigned to each grade, discount formula, cutoff, and treatment of queries with no known relevant items. An implementation should be tested against hand-calculated examples, including all-zero relevance and tied scores.

Recall at final k shows whether relevant evidence survived selection. Compare it with candidate recall at N to quantify loss introduced by reranking or thresholding. Reciprocal rank emphasizes the position of the first relevant item and can be useful when one source is sufficient, but it ignores additional evidence required by multi-hop questions.

Report all metrics per query before aggregation. Macro averaging gives each query equal weight; traffic weighting estimates a declared query distribution; neither should silently replace the other. Show critical slices, win-loss-tie counts, and the number of scoreable cases.

from math import log2

def dcg(grades, cutoff):
    return sum(
        (2 ** grade - 1) / log2(rank + 1)
        for rank, grade in enumerate(grades[:cutoff], start=1)
    )

def ndcg(grades, cutoff):
    ideal = dcg(sorted(grades, reverse=True), cutoff)
    return 0.0 if ideal == 0 else dcg(grades, cutoff) / ideal

This illustrative implementation assumes nonnegative numeric grades and one candidate per evidence identity. Production analysis should validate inputs, apply the declared duplicate policy, and test the exact gain and discount definitions used by the release report.

Design a representative latency protocol

Measure the whole reranking stage: candidate serialization, network transfer, queueing, model or service execution, parsing, sorting, and fallback. Also record total retrieval latency. Tag each sample with candidate count, text length, batch size, concurrency, cache condition, region, and outcome so changes in workload mix do not masquerade as performance changes.

Run cold and warm scenarios if both occur in service. Include short and long documents, maximum permitted candidate sets, concurrent load, service errors, and timeout boundaries. Do not remove timed-out calls from latency percentiles and then score their fallback output as if it came from the reranker.

Quality must be measured under the same timeout policy used in production. A slower configuration may be accurate when it completes but produce more baseline fallbacks. Report completed-reranker quality, fallback quality, timeout frequency, and overall observed quality separately.

Compare controlled baselines and ablations

Replay identical candidates through the original first-stage order, current production reranker, proposed reranker, and simple deterministic alternatives. If first-stage scores are available, a score-only ordering can reveal whether a complex reranker adds value. Keep final k and duplicate handling constant.

Ablate candidate depth, text fields, truncation, metadata features, query rewriting, and score thresholds one at a time on development data. For each ablation, record NDCG, final recall, candidate recall, and latency. A quality gain caused by feeding more candidates should not be attributed solely to a model change.

Test score ties and malformed outputs. Sorting must be deterministic, and fallback must preserve authorization filters and evidence identity. A reranker service should never be allowed to introduce IDs outside the eligible candidate set.

Calibrate semantic judgments and uncertainty

If human or model judgments create relevance grades, retain raw labels, adjudications, rubric version, and grader configuration. Calibrate model-assisted judgments against a blinded human set and inspect errors by slice. Reranker text can contain instructions or persuasive language that influence a model judge, so the judge input needs strict delimitation and adversarial cases.

Use paired inference because baseline and candidate order the same queries. A paired bootstrap over independent query groups is practical for metric differences. Resample conversations or source families when they generate multiple cases. Publish intervals and the number of independent groups, not just a point estimate.

Uncertainty also comes from incomplete judgments. Repeat the comparison after expanding high-ranked unknowns, and show decision sensitivity to reasonable label treatments. If the preferred system changes, the gate needs more assessment rather than a more favorable assumption.

Combine quality and latency in one gate

A release policy should require all essential conditions. The following values are illustrative only and must be replaced by thresholds calibrated to product risk and service objectives:

{
  "illustrativeOnly": true,
  "quality": {
    "minimumNdcgDeltaLowerBound": 0.0,
    "maximumFinalRecallRegression": 0.01,
    "criticalSliceRule": "no-new-severe-losses"
  },
  "latency": {
    "maximumStageP95Milliseconds": 180,
    "maximumTimeoutRate": 0.005
  },
  "evidence": {
    "minimumJudgedCoverageAtK": 0.95,
    "inconclusiveDisposition": "retain-baseline"
  }
}

Do not average a failed recall condition with a favorable NDCG gain. Likewise, a fast median cannot compensate for unacceptable tail behavior if the product objective is defined at a tail percentile. Record exceptions with owner, affected slices, rationale, and expiry.

Execute a release-ready reranker plan

1. Freeze the stage contract, corpus, candidate builder, evidence identity, final context depth, and relevance gains.
2. Persist identical first-stage candidate lists and measure their recall ceiling before reranking.
3. Expand blind judgment pools until promoted candidates have adequate coverage, with unknowns kept explicit.
4. Tune depth, thresholds, text limits, and batching only on development data; lock the held-out run.
5. Replay baseline and candidate rerankers, calculate paired rank metrics and critical slices, and run stage ablations.
6. Load-test the exact timeout and fallback policy while scoring the output users would receive.
7. Release only when quality, judgment coverage, uncertainty, authorization, and latency conditions all pass; otherwise keep the baseline and assign the failing stage.

A reranker evaluation is convincing when it explains both the gain and the cost. Candidate recall establishes what was possible, NDCG and final recall show what ordering changed, ablations identify why, and the latency gate confirms that the improvement survives the system's real operating boundary.