Re-ranking

See also: Machine learning terms, Ranking, Information Retrieval

What is re-ranking?

Re-ranking, also written as reranking, is the second stage of a two-stage information retrieval pipeline: a fast first-stage retriever returns a candidate set of roughly 50 to 1000 documents, then a slower but more accurate model rescores just those candidates so the most relevant items rise to the top. The fast stage is usually BM25 or a bi-encoder (two-tower model) querying a vector database; the precise stage is usually a cross-encoder that jointly reads the query and each candidate together. Re-ranking is now standard in web search, enterprise search, recommender systems, and retrieval-augmented generation (RAG), where the reordered top results are fed to a large language model for answer synthesis.^[1][2]

The core motivation is a tradeoff. Models that score every document against the query with full cross-attention are too slow to run over millions of items, but bi-encoder retrievers that compress queries and documents into independent vectors miss fine-grained interactions between the two. Two stages get the best of both: cheap recall first, expensive precision second. Reimers and Gurevych framed this split clearly in the Sentence-BERT paper, showing that finding the most similar pair in 10,000 sentences with BERT takes about 65 hours of inference, while a bi-encoder reduces it to 5 seconds at the cost of some accuracy.^[1] As the Sentence-Transformers documentation summarizes the payoff, "A re-ranker based on a Cross-Encoder can substantially improve the final results for the user."^[3]

How does the two-stage retrieval architecture work?

A modern retrieval pipeline almost always has at least these two phases. Some systems add a third stage with a LLM judge or a fusion step.

Scroll sideways for more →

This split also matches what production RAG systems do. Hybrid search recovers candidates that either of BM25 or dense retrieval would miss alone, the cross-encoder re-orders them by true semantic match, then the top three to ten chunks go into the LLM context window.^[2] The recommended recipe in the Sentence-Transformers documentation is identical: "use an efficient Bi-Encoder to retrieve the top-100 most similar sentences for a query, then use a Cross-Encoder to re-rank these 100 hits by computing the score for every (query, hit) combination."^[3]

Why use two stages instead of one?

Running a cross-encoder over a million documents would require a million transformer forward passes per query. At 10 ms per pass, that is roughly three hours per query on a single GPU. Bi-encoders sidestep this by encoding documents once, offline, into a vector index, so query time becomes a fast nearest-neighbor lookup. The cost is information loss: query and document are compressed independently, and the model never sees them together.

A cross-encoder is the inverse. The query and document are concatenated and processed together, so attention can match a question word against any token in the candidate. Quality goes up, throughput goes down. Reranking only the top-K candidates of the bi-encoder is a clean compromise: pre-computation handles the recall problem, and the K-pair cross-attention handles the precision problem. Industry write-ups generally report cross-encoders being 50 to 100 times slower than bi-encoders per pair, which is exactly why nobody runs them across the whole corpus.^[3]

How does a cross-encoder reranker work?

A cross-encoder takes both the query and the candidate document, joins them with a separator token, runs them through a single transformer, and uses a final linear head to emit one relevance score. The Sentence-Transformers documentation describes the mechanism precisely: "The query and a possible document is passed simultaneously to transformer network, which then outputs a single score between 0 and 1 indicating how relevant the document is for the given query."^[3] Because every query token can attend to every document token, the model captures word-level interactions that a bi-encoder cannot. The same docs note the structural cost: a cross-encoder "does not produce a sentence embedding," so its outputs cannot be precomputed or indexed, which is why it is only ever run over a short candidate list.^[4]

The Sentence-BERT paper formalized cross-encoder versus bi-encoder terminology in 2019 and shipped open-weight cross-encoders for MS MARCO that are still widely used in libraries like sentence-transformers.^[1] Nogueira and Cho's 2019 paper Passage Re-ranking with BERT, often called monoBERT in later work, was the first to apply BERT as a passage reranker. They fine-tuned BERT-Base and BERT-Large on the MS MARCO passage ranking task and beat the previous state of the art by 27 percent relative MRR@10, then took the top spot on the public leaderboard.^[5] The monoBERT recipe (binary classification on relevant or non-relevant query-passage pairs) became the template every subsequent encoder-based reranker followed.

What are the main types of re-rankers?

Four main families of re-rankers are in production use today.

Scroll sideways for more →

How does ColBERT late interaction differ from a cross-encoder?

ColBERT, introduced by Khattab and Zaharia at SIGIR 2020, sits between a bi-encoder and a cross-encoder.^[6] Instead of one vector per text, ColBERT keeps one vector per token. At query time, the model encodes the query into per-token vectors, then computes a MaxSim score: for each query token, take the maximum cosine similarity against any document token, then sum across query tokens. Documents are encoded offline, so the index is much larger than a bi-encoder index but the computation per candidate is much cheaper than a cross-encoder. The authors report that ColBERT matches BERT-based quality "while executing two orders-of-magnitude faster and requiring four orders-of-magnitude fewer FLOPs per query" than a comparable BERT cross-encoder.^[6] ColBERTv2 (2022) added residual compression to shrink the index. ColBERT can serve either as a first-stage retriever (with vector indexes) or as a reranker, which makes it unusual.

How do sequence-to-sequence rerankers work?

monoT5 (Nogueira et al., 2020, EMNLP Findings) treats reranking as a generation problem.^[7] The model is trained on prompts like Query: <q> Document: <d> Relevant: and is fine-tuned to produce the token true for relevant pairs and false for irrelevant ones. The relevance score is the logit of the true token relative to false. Because T5 was already a strong sequence model, monoT5 transferred well to TREC tracks and other out-of-domain corpora. The Castorini group later extended this with duoT5 (pairwise) and the Expando-Mono-Duo design pattern.

How do LLM rerankers work?

In 2023 Sun et al. published Is ChatGPT Good at Search? Investigating Large Language Models as Re-Ranking Agents, which won an EMNLP 2023 Outstanding Paper Award and introduced the now-standard listwise prompting recipe known as RankGPT.^[8] The LLM is shown a query and the top 20 candidates by ID, then asked to output the ranked list of IDs. Because the model sees all candidates at once, it can compare them against each other, which pointwise cross-encoders cannot. To rerank more candidates than the context window allows, RankGPT uses a sliding window that walks back to front, reranking the worst window first and bubbling strong candidates upward.

RankZephyr (Pradeep, Sharifymoghaddam, and Lin, 2023) distilled the RankGPT-3.5 and RankGPT-4 behavior into a 7-billion-parameter open model based on Zephyr-Beta and Mistral, closing much of the open versus closed gap on TREC Deep Learning evaluations.^[9] The RankLLM toolkit packages these models for reproducible IR research.

What is learning-to-rank?

Before neural rerankers took over, the dominant approach was learning-to-rank (LTR) over hand-engineered features such as BM25 score, click-through rate, anchor text matches, freshness, and PageRank. LambdaMART (Burges, 2010), a boosted-tree variant of LambdaRank, optimized NDCG directly and won Track 1 of the Yahoo! Learning to Rank Challenge in 2010.^[10] LambdaMART implementations in LightGBM and XGBoost are still standard in commercial search and ad ranking, often as the final stage on top of neural candidates.

Which commercial reranker APIs are available?

A cluster of vendors now sells hosted rerankers. They are convenient because no GPU operation is required on the client side, and the models are usually multilingual and continuously updated. Cohere describes the task its endpoint performs as follows: "Rerank models sort text inputs by semantic relevance to a specified query," returning each document with a relevance score normalized to the range [0, 1].^[11]

Scroll sideways for more →

Neither Anthropic nor OpenAI ships a dedicated reranker endpoint. Teams that want LLM-grade reranking from those providers prompt a chat model with a listwise template, which works well but costs more per query. The Cohere Rerank, Voyage Rerank, and Jina Reranker endpoints all return scores in roughly the same shape: a JSON list of indexes paired with relevance values, suitable for sorting client-side.

What are the latency and quality tradeoffs?

Latency depends on hardware, batch size, and candidate length. The numbers below are typical orders of magnitude for English passages of around 100 to 200 tokens.

Scroll sideways for more →

Quality gains compound through the stack. Genzeon's hybrid plus rerank pipeline reports MRR@3 jumping from 0.433 to 0.605 (a 39.7 percent relative improvement) once a cross-encoder is added on top of fused BM25 plus dense retrieval.^[2] Pinecone, Databricks, and Cohere have all published similar numbers showing 5 to 15 NDCG@10 points lifted by a cross-encoder reranker compared to the best first-stage method alone. The exact size of the lift depends on how good the first stage already is. If BM25 already returns the right answer at rank 1, the reranker has little to add. If the relevant passage is buried at rank 47 because it has weak lexical overlap, reranking is what saves the query.

How is re-ranking evaluated?

Re-ranking is evaluated with the same offline metrics as ranking in general: NDCG@k, MRR, MAP, Precision@k, and Recall@k (the last is more useful for the retrieval stage). Common public benchmarks include MS MARCO passage and document tracks, the TREC Deep Learning tracks (DL19, DL20, DL21, DL22), and BEIR, the heterogeneous zero-shot benchmark covering 18 datasets. BEIR results are reported as average NDCG@10 across the included datasets, and they are the standard reference point for both first-stage retrievers and rerankers.

For RAG-specific systems, downstream answer-quality metrics also matter. A reranker that lifts NDCG by two points but increases the share of incorrect answers because it surfaces a tempting but wrong distractor is a net loss for the application. Teams running RAG often pair retrieval metrics with end-to-end accuracy metrics on a curated answer set.

What are the classical (non-neural) re-ranking techniques?

Not every reranker is a neural model. Two non-neural approaches still appear in production.

Reciprocal rank fusion (RRF), introduced by Cormack, Clarke, and Buttcher at SIGIR 2009, is the standard way to combine multiple ranked lists into one.^[12] The RRF score for a document is the sum of 1 / (k + rank_i) across each input list, where k is a small constant (the paper uses 60). RRF throws away the underlying scores and works only with positions, which makes it robust to systems that produce scores on incompatible scales. It is the default fusion strategy in OpenSearch, Elasticsearch, Azure Cognitive Search, and most hybrid retrieval libraries.

Pseudo-relevance feedback (PRF) treats the top-K results from the first retrieval as if they were known to be relevant, then expands the query with terms drawn from those documents and runs a second retrieval. RM3 is the most common PRF method on top of BM25, and neural variants like ANCE-PRF and ColBERT-PRF apply the same idea to dense retrieval. PRF is technically a re-ranking step because the second retrieval reorders the candidate set in light of feedback, even if there is no separate scoring model.

How is re-ranking implemented in practice?

Most reranker work in 2025 is done through one of these libraries.

Scroll sideways for more →

In LangChain the wiring is short. Build a base vector retriever, instantiate CohereRerank, then wrap them with ContextualCompressionRetriever(base_compressor=cohere, base_retriever=vector). Every query first runs through the vector retriever, the candidate documents flow into the rerank API, and the wrapped retriever returns the reordered top-N. LlamaIndex follows the same pattern with a node post-processor list on a QueryEngine.^[13]

What are the limitations of re-ranking?

The cross-encoder design has structural limits. Document representations cannot be pre-computed, so cost is paid at query time and grows linearly with the candidate count. This is acceptable for K of 20 to 100 but painful for K of 1000 or more. Late-interaction models like ColBERT trade some accuracy for the ability to pre-compute, and learning-to-rank with light features stays useful when latency budgets are very tight.

Domain shift is another headache. A reranker trained on MS MARCO web passages can degrade on legal contracts, medical literature, or internal company documents. Fine-tuning on in-domain pairs (often generated synthetically from the corpus) usually fixes this, but it requires labeled or semi-labeled data and a non-trivial training step. Cohere, Voyage, Jina, and BAAI release multilingual checkpoints partly to amortize this problem across users.

LLM rerankers introduce token cost and latency. A RankGPT pass over 20 candidates with GPT-4 routinely takes several seconds and costs more than a typical chat completion. They also fail in interesting ways: outputs can be malformed, the model can refuse to rank, or it can hallucinate IDs that were not in the input list. RankZephyr and other distilled open models reduce cost but still need careful output parsing.

Finally, optimizing rerankers in isolation can hide problems with the first stage. If the first-stage retrieval misses the relevant document entirely, no reranker can save it, since the document is not in the candidate set. End-to-end recall at the retrieval stage is therefore as important as precision at the rerank stage, and tuning one without the other tends to give misleading results.

When did re-ranking develop?

Classical IR systems used multi-stage ranking long before neural networks were involved. Bing and Yahoo's web search stacks in the late 2000s ran an inverted-index recall stage, an L1 ranker (often LambdaMART) on a few thousand candidates, and an L2 ranker with richer features and click signals on the top hundred. The split was driven by the same arithmetic as today: full feature extraction over the entire web is impossible, so cheap recall comes first.

The neural era started with Nogueira and Cho's monoBERT in 2019, which showed that a transformer cross-encoder could move the MS MARCO state of the art by a large margin.^[5] Reimers and Gurevych's Sentence-BERT in the same year provided the bi-encoder counterpart that made retrieval cheap enough to feed those rerankers.^[1] ColBERT (2020) and monoT5 (2020) explored late interaction and seq2seq formulations.^[6][7] By 2023, RankGPT had shown that LLM listwise prompting could match or beat dedicated rerankers, and RankZephyr had distilled that capability into open-weight models.^[8][9] Cohere shipped its first commercial Rerank model in 2023, with rerank-v3.5 (the multilingual default) following in December 2024.^[14] Voyage launched rerank-2 in September 2024, and Jina released its multilingual reranker around the same time.^[15][16]

The direction of travel is toward longer context, more languages, and tighter integration with hybrid retrieval. Whether the future belongs to specialized cross-encoders, late-interaction models, or just very capable general LLMs remains an open question. In practice most production systems still combine all three: BM25 plus dense for recall, a fast cross-encoder for the bulk of the rerank, and an LLM (or LLM-based judge) for the final handful of candidates that go into a generated answer.

explain like I'm 5

Imagine a giant library with a million books. You ask the librarian for books about dinosaurs. The librarian quickly grabs 100 books with the word dinosaur in the title. That is fast but rough; some of those books are coloring books, some are romance novels with a dinosaur on the cover. Then a paleontologist comes over and looks through the 100 books one by one, ranking them by how useful they are for what you actually want. The paleontologist is slow but careful. That second pass is re-ranking. The librarian gives you breadth, the paleontologist gives you precision, and together they hand you the ten best books in the library without anyone having to read all million.

References

1. Reimers, N. and Gurevych, I. "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks." EMNLP-IJCNLP 2019. https://arxiv.org/abs/1908.10084 ↩
2. Genzeon. "Hybrid Retrieval and Reranking in RAG: A Dual-Stage Approach to Improve Information Recall and Precision." https://www.genzeon.com/hybrid-retrieval-deranking-in-rag-recall-precision/ ↩
3. Sentence Transformers documentation. "Retrieve & Re-Rank." https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html ↩
4. Sentence Transformers documentation. "Cross-Encoders." https://www.sbert.net/examples/cross_encoder/applications/README.html ↩
5. Nogueira, R. and Cho, K. "Passage Re-ranking with BERT." arXiv:1901.04085, 2019. https://arxiv.org/abs/1901.04085 ↩
6. Khattab, O. and Zaharia, M. "ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT." SIGIR 2020. https://arxiv.org/abs/2004.12832 ↩
7. Nogueira, R., Jiang, Z., Pradeep, R., and Lin, J. "Document Ranking with a Pretrained Sequence-to-Sequence Model." Findings of EMNLP 2020. https://arxiv.org/abs/2003.06713 ↩
8. Sun, W., Yan, L., Ma, X., Ren, P., Yin, D., and Ren, Z. "Is ChatGPT Good at Search? Investigating Large Language Models as Re-Ranking Agents." EMNLP 2023 (Outstanding Paper). https://arxiv.org/abs/2304.09542 ↩
9. Pradeep, R., Sharifymoghaddam, S., and Lin, J. "RankZephyr: Effective and Robust Zero-Shot Listwise Reranking is a Breeze!" arXiv:2312.02724, 2023. https://arxiv.org/abs/2312.02724 ↩
10. Burges, C. J. C. "From RankNet to LambdaRank to LambdaMART: An Overview." Microsoft Research Technical Report MSR-TR-2010-82, 2010. https://www.microsoft.com/en-us/research/publication/from-ranknet-to-lambdarank-to-lambdamart-an-overview/ ↩
11. Cohere documentation. "Rerank Overview." https://docs.cohere.com/docs/rerank-overview ↩
12. Cormack, G. V., Clarke, C. L. A., and Buttcher, S. "Reciprocal Rank Fusion outperforms Condorcet and Individual Rank Learning Methods." SIGIR 2009. https://cormack.uwaterloo.ca/cormacksigir09-rrf.pdf ↩
13. Cohere documentation. "Cohere Rerank on LangChain (Integration Guide)." https://docs.cohere.com/docs/rerank-on-langchain ↩
14. Cohere documentation. "Announcing Rerank-v3.5." https://docs.cohere.com/changelog/rerank-v3.5 ↩
15. Voyage AI blog. "rerank-2 and rerank-2-lite: the next generation of Voyage multilingual rerankers." September 30, 2024. https://blog.voyageai.com/2024/09/30/rerank-2/ ↩
16. Jina AI. "Jina Reranker v2 for Agentic RAG: Ultra-Fast, Multilingual, Function-Calling and Code Search." https://jina.ai/news/jina-reranker-v2-for-agentic-rag-ultra-fast-multilingual-function-calling-and-code-search/ ↩