Reranking in RAG: Cross-Encoders, Trade-offs and Practical Design
Understand when reranking improves retrieval, how candidate sizes affect latency, and how to evaluate the extra stage.
What reranking adds
Initial retrieval is optimized for speed and broad recall. A reranker can examine the query and candidate passage together and make a more precise relevance judgment. This is especially useful when the first-stage retriever returns several semantically similar but not actually useful chunks.
Candidate size is the main trade-off
Reranking every document is expensive, so retrieve a manageable candidate set first. Increasing the candidate pool can improve recall, but it increases reranker latency. Measure the point at which additional candidates stop producing meaningful gains.
Cross-encoder versus embedding similarity
Bi-encoders create independent embeddings and are efficient for large-scale retrieval. Cross-encoders jointly inspect query and document and are generally more expressive for ranking, but require more computation per candidate. The two stages complement each other.
Where reranking can hurt
If the candidate set has poor recall, a reranker cannot recover missing evidence. Reranking can also add latency and may over-prefer verbose passages if the evaluation set is not representative. Always compare against a simpler baseline.
Evaluation workflow
Compare lexical-only, vector-only, hybrid, and hybrid-plus-reranking systems on the same queries. Measure recall, ranking metrics, end-to-end answer quality, p50/p95 latency, and cost.
Keep learning
Apply the concepts in a small project, measure the result, document the trade-offs, and explore related TechStudio resources.
Explore Resources