Reranking definition
Reranking is the second stage of a two-stage retrieval pipeline: after a fast first-stage retriever returns a candidate set of documents, a slower and more accurate model rescores each query and document pair together and reorders the candidates so the most relevant ones end up at the top. It improves the precision of the final result set without requiring the first-stage retriever to be more accurate.
Reranking in search is the pass that happens after retrieval: a model looks at the query and each candidate document together, scores the pair, and reorders the shortlist so the best answers sit at the top. In Sanity, that rescoring stage lives in the GROQ query itself, where `score()` combines a BM25 `match` score, a `text::semanticSimilarity()` score, and weighted `boost()` signals into one `_score` over documents a structured filter already narrowed.
Reranking works as the second of two passes. The first pass, retrieval, runs a fast method over the whole corpus (keyword matching, vector similarity, or both) and returns a candidate set, commonly on the order of tens to a few hundred documents. The second pass, reranking, runs a slower and more accurate model over just those candidates and produces a new ordering, usually followed by a cut to the top few.
The split exists because the accurate model is too expensive to run over everything. A cross-encoder reranker takes the raw query text and the raw document text in a single forward pass at query time, which is what makes it accurate and also what makes it slow. Retrieval uses a bi-encoder instead, where each document is turned into a single fixed vector (typically 768 or 1536 dimensions) before the query exists, so the vector has to average over every possible meaning the document might have. Pinecone's write-up on two-stage retrieval describes that compression as the source of the information loss a reranker recovers.
The modern neural form of reranking dates to Nogueira and Cho's 2019 paper Passage Re-ranking with BERT, which established the BERT cross-encoder recipe. Reranking as an idea in information retrieval is much older; 2019 is when transformer cross-encoders became the default way to do it.
Retrieval decides which documents are candidates. Reranking decides what order those candidates go in. That is the whole distinction, and it carries one caveat worth stating plainly: reranking improves precision, not recall. A reranker only ever sees the candidate set the retriever handed it, so if the right document was never retrieved, no reranker will surface it.
The practical consequence is that the two stages are tuned in opposite directions. You widen retrieval to make sure the answer is somewhere in the candidate set, then you rerank to make sure it reaches the top. Fixing bad results by swapping in a better reranker will not help if the failure was in the first stage; fixing it by retrieving more documents will not help if nothing reorders them afterward.
Reranking is also distinct from filtering. A filter is a boolean that removes documents failing a predicate, before or during retrieval. A rerank is a score applied to documents that already passed. In most pipelines they run in sequence: filter to narrow, then rank what survives.
Reranking matters for retrieval-augmented generation because a language model cannot reliably use a long, badly ordered context. In Lost in the Middle (TACL, 2024), Liu et al. found that model performance is highest when the relevant information sits at the beginning or end of the input context and degrades significantly when the model has to use information buried in the middle of a long one.
That result rules out the obvious shortcut. You can raise the number of retrieved documents to improve retrieval recall, but you cannot then hand all of them to the model and expect it to find the good one. Reranking is how a RAG system retrieves widely and still passes few documents, in an order the model can actually use: maximize retrieval recall by pulling plenty of candidates, then minimize how many of them reach the model.
Because reranking almost always ends with a cut to the top n, it functions as a filter in practice as well as an ordering. The documents that do not make the cut never enter the prompt at all, which is usually the point.
Reranking runs a model over document content; hybrid search fusion does not. Reciprocal Rank Fusion (RRF) merges two or more already-ranked lists, typically one from keyword search and one from vector search, by combining rank positions rather than scores, independent of the original score scales. It never reads the documents again. A reranker does.
The two are complementary and commonly stacked. Azure AI Search applies its semantic ranker as a secondary pass on top of a result set that has already been scored by BM25 or RRF, and calls that stage L2 ranking. The same documentation shows how bounded the reranking stage is in production: even when a query returns more than 50 results, only the top 50 progress to semantic ranking, and as of November 2024 each generated summary string passed to the ranker is capped at 2,048 tokens.
Terminology varies more than the concept does. Reranking, re-ranking, semantic ranking, secondary ranking, and L2 ranking all describe the same stage of the pipeline.
In Sanity, the reranking stage is expressed in the query language rather than called as a separate service. A GROQ query separates the two stages explicitly: `*[ ... ]` filters to produce the candidate set, and `| score( ... )` rescores those candidates and exposes a `_score` you can order by.
What makes that a genuine rescoring pass rather than a sort is what can go inside `score()`. The `match` operator produces a BM25 keyword relevance score there, `text::semanticSimilarity()` produces a semantic score, and `boost(expression, weight)` reweights any signal, including non-textual ones such as recency or an editorial flag. A documented production pattern combines all three in one pass, scoring a title keyword match, a semantic similarity score, and a recency condition, then applying `| order(_score desc)`. Note that `_score` is an opaque, unitless value for ranking results relative to each other within a single query; it is not a relevance percentage and should not be compared across queries.
One detail is load-bearing: `text::semanticSimilarity()` is only valid inside `score()`. Semantic similarity in Sanity ranks, it does not narrow. The retrieve-then-rescore split is enforced by the language. That is also where structure earns its keep. Sanity is the Content Operating System for the AI era, and because content is modeled as fields rather than stored as an undifferentiated blob of text, the scoring stage has real signals to weight: a title, a category, a publish date, a status flag. Dataset embeddings are available on all plans, generation and updates are included at no additional cost, and recomputation after a document update is normally under a minute, though it can take longer depending on dataset size and update frequency.
Explore Sanity Today
Understanding reranking is just the beginning. Take the next step and discover how Sanity can enhance your content management and delivery.
Last updated: