Reranking in RAG: moving the most useful evidence to the top

Understand two-stage retrieval, Cross-Encoder reranking and the practical trade-off between evidence quality, candidate coverage, latency and cost.

Author
Aivan Editorial Team
Published
20 October 2026
Reading time
5 minutes
Sections in this guide
  1. Different goals for two stages
  2. An editorial HR-policy example
  3. Find the actual bottleneck
  4. Accept the added stage only with evidence
  5. Separate relevance from policy validity
  6. Prepare passages that can be judged
  7. Tune the candidate budget and retain a failure ledger
  8. Use a controlled experiment instead of a score demonstration
  9. Frequently asked questions
  10. Sources

Different goals for two stages

Initial retrieval finds candidates quickly. A reranker examines the smaller list more closely and changes its order. Sentence Transformers documents a retrieve-and-rerank architecture using Cross-Encoders that assess query and passage together. This additional computation is intended for candidates rather than an exhaustive scan of the corpus.

An editorial HR-policy example

For a question about carrying over leave, initial retrieval may return the current policy, an old circular and a similar report. Reranking can improve relevance, but approval status and effective dates must come from document metadata and organizational rules. A well-written obsolete policy is still obsolete. Access checks must precede exposure to generation.

Find the actual bottleneck

A reranker cannot recover a document missing from its input. Measure candidate coverage separately from ranking quality. Preserve titles and relevant table context in chunks. Evaluate Persian and mixed-language inputs rather than relying on unrelated benchmarks. Relevance scores are not calibrated probabilities of answer correctness.

Accept the added stage only with evidence

Compare fixed question sets with and without reranking. Measure evidence position, citation accuracy, latency and cost, separating exact-code questions from ambiguous ones. Tune candidate counts gradually. Selective use or removal may be preferable if additional latency outweighs the measured gain.

Separate relevance from policy validity

In a leave-policy example, a reranker may compare highly similar old and current rules. Keep version, effective date and employee scope as explicit metadata governed by application policy. Evaluate which version actually supplies the final evidence. A higher relevance score on an obsolete rule is not a successful result.

Prepare passages that can be judged

Include enough heading and scope context to interpret short clauses. Preserve table headers, units and exceptions. Avoid indiscriminately repeating entire documents. Keep chunking fixed when comparing rerankers, and retain chunk IDs and document versions for investigation. Otherwise an apparent model improvement may really be an input-preparation change.

Tune the candidate budget and retain a failure ledger

Compare candidate counts on the same labeled queries and measure both typical and slow-request latency. Decide explicitly whether initial retrieval is an acceptable fallback during reranker failure. Classify errors into absent candidates, poor ordering, unsuitable chunks and incorrect final interpretation. Only some are ranking problems. Use held-out questions for the final comparison and report evidence ranking, answer correctness and review effort together. Do not treat the reranker's own score as independent proof of improvement.

Use a controlled experiment instead of a score demonstration

Prepare an HR question set covering ordinary leave rules, exceptions and different employee groups. Label the current applicable passage and examples where no answer should be given. Preserve the initial candidate list for each query. If the reference passage never appears there, investigate retrieval before attributing the failure to reranking. If it appears but remains below misleading passages, the ordering stage becomes the direct investigation target.

Try several candidate budgets under the same chunking and permission rules. Compare useful-evidence position and final-answer correctness with total latency and review time. Include slow queries, not only averages. Keep a held-out set for the release decision, since repeated tuning on every reference question can make the apparent improvement optimistic. Candidate counts and acceptance targets should reflect the workflow's needs rather than a universal number.

Check the outage path as part of the experiment. For some search-only workflows, showing clearly labeled initial results may be acceptable. For consequential policy answers, the agreed behavior may instead be a controlled stop. Make that choice explicit and evaluate it. Deliver a ledger of missing-candidate, ordering, chunk-context and answer-interpretation failures with owners for correction. This allows a team to improve the actual bottleneck rather than replacing models whenever a final response is wrong. A good result improves access to applicable evidence without concealing validity problems behind a larger relevance score.

Frequently asked questions

Can a reranker find missing documents?

No. It only reorders the candidates it receives.

Is its score answer confidence?

No. Relevance and factual correctness are separate measurements.

Sources

Further reading in the Liyan knowledge base

Plan your enterprise AI use case

Discuss your data, workflow and acceptance criteria with Aivan.