What does a reranker actually add?
A cross-encoder reads the query and a candidate document together and judges relevance jointly (Nogueira & Cho, 2019), catching interactions that independently computed embeddings miss. First-stage retrieval optimizes recall: get the relevant documents somewhere into the candidate set. The reranker optimizes precision: get the best ones to the very top. It runs second because a model pass over the whole corpus would be far too slow.
Corpus
millions of documents
First stage
optimizes recall, top-100
Cross-encoder rerank
joint query-doc scoring
Top-5
precision where it counts
What does it cost?
Reranking costs one model forward pass per candidate, at query time, in series with retrieval. Reranking 200 candidates means 200 model calls of latency budget: acceptable for some search products, disqualifying for agent loops that fire dozens of queries in parallel.
When does multi-vector make it redundant?
The ColBERT paper introduced late interaction precisely as an efficient alternative to cross-encoder reranking: MaxSim does token-level matching in the retrieval stage itself, from precomputed embeddings. If your first stage is multi-vector, much of what a reranker would recover is already in the ranking.
The honest caveat: cross-encoders still hold the accuracy ceiling. If top-5 precision is everything and latency is nothing, rerank anyway, but the gap over a multi-vector first stage is far smaller than over a single-vector one, so benchmark before paying for both.
The decision in one line
If you run a single-vector first stage and hear quality complaints, add a reranker. If you run a multi-vector first stage, measure the reranker's lift before you ship it.
TopK's multi-vector retrieval and custom ranking run in a single query, which often removes the separate reranking hop entirely. It is worth testing against your current two-stage stack.