Reranking

TL;DR — Reranking is a second look. A search or AI system first grabs a big pile of maybe-relevant pages quickly and roughly, then a slower, smarter model re-scores that shortlist and puts the best ones on top — before you see the results or before an AI writes its answer. Being pulled into the shortlist isn’t enough; you also have to survive the reorder.

What reranking is

Reranking applies a second scoring stage to candidates produced by an initial retriever. Evidence for this claim A cross-encoder can score query-document pairs for reranking after an initial retrieval stage. Scope: Sentence-BERT evaluation and related retrieve-then-rerank use; cross-encoders are one reranking approach, not a universal implementation. Confidence: high · Verified: 2026-07-14 Reimers and Gurevych: Sentence-BERT Cross-encoders are one approach, not the definition of every reranker. Evidence for this claim A rerank model can reorder an existing candidate list by relevance to a query. Scope: Cohere's Rerank product behavior; inputs, limits, and scoring semantics are vendor-specific. Confidence: high · Verified: 2026-07-14 Cohere: Rerank overview

Imagine you’re hiring and 500 résumés come in. You don’t read all 500 carefully — you’d never finish. So you do a fast skim first, pull out the 20 that look promising, and then read those 20 closely to rank them. That two-step process is exactly how modern search and AI systems find relevant content.

• Step one — retrieval. The system does a fast, cheap pass over a huge index and pulls back a candidate set of pages or passages that look relevant. It casts a wide net.
• Step two — reranking. A second, slower, more careful model looks at just that shortlist and re-scores each candidate for how well it actually answers the query, then reorders them.

Only the top of that reordered list gets shown to you, or gets handed to an AI to write an answer from. So the shortlist decides who’s in the running, and the rerank decides who wins.

Why do it in two steps?

Because the careful reading is expensive. The precise model that judges “how well does this exact page answer this exact question?” is far too slow to run on every page in a billion-page index. So systems retrieve broadly with something cheap, then spend the expensive model only on the small shortlist. Fast-and-rough to narrow down, slow-and-precise to finish.

Why it matters for you

Getting retrieved into the shortlist is necessary but not sufficient. Your page can be in the index, get pulled into the candidate set, and still not make the final cut if the reranker decides other results answer the question better.

The practical takeaway is one you’ve heard before, now with a clearer reason: write passages that answer a specific question clearly, on their own. The reranker looks at your passage next to the query and scores how well the two match. A section that reads as a direct, self-contained answer scores better than one that only makes sense after you’ve read three paragraphs above it.

Want the real mechanics — bi-encoders vs cross-encoders, how Google and Bing do this, where it fits in AI search, and why it’s not the same as Reciprocal Rank Fusion? Switch to the Advanced tab.

TL;DR — Reranking is the second stage of a two-stage (or multi-stage) retrieval pipeline: a cheap, broad retrieval pass (BM25 keyword match, embedding/vector similarity, or both) pulls a candidate set, then a slower, more precise model re-scores and reorders that shortlist. The core mechanic is bi-encoder vs cross-encoder — a bi-encoder encodes query and document separately into vectors and compares them (fast, precomputable, less precise); a cross-encoder encodes them together and outputs one relevance score per pair (slower, can’t be precomputed, more accurate). You can’t run a cross-encoder over a whole corpus, so you retrieve broadly and rerank the shortlist. Google doesn’t say “reranking” publicly, but BERT and passage ranking do the job; Microsoft documents an explicit Bing-derived reranker in Azure AI Search. Reranking ≠ Reciprocal Rank Fusion (RRF). SEO upshot: rerankers score query-passage pairs jointly, so self-contained, unambiguous passages win.

The retrieve-then-rerank pattern

Two-stage retrieval trades candidate breadth against more expensive scoring. Evidence for this claim A cross-encoder can score query-document pairs for reranking after an initial retrieval stage. Scope: Sentence-BERT evaluation and related retrieve-then-rerank use; cross-encoders are one reranking approach, not a universal implementation. Confidence: high · Verified: 2026-07-14 Reimers and Gurevych: Sentence-BERT Model choice and latency-quality tradeoffs are implementation-specific. Evidence for this claim A rerank model can reorder an existing candidate list by relevance to a query. Scope: Cohere's Rerank product behavior; inputs, limits, and scoring semantics are vendor-specific. Confidence: high · Verified: 2026-07-14 Cohere: Rerank overview

Every large-scale relevance system faces the same problem: you can’t afford to run your most accurate relevance model on your entire corpus. So the standard solution is to split the work into stages. Google Cloud’s own search documentation states the logic plainly: “In short, retrieval is finding relevant documents, while ranking is ordering those retrieved documents. Ranking all the available documents can be computationally expensive. Therefore, retrieval and ranking work sequentially.” (Google Cloud, “About retrieval and ranking”)

Stage one — retrieval — casts a wide net cheaply. It uses lexical matching (BM25 over an inverted index), embedding-based vector search, or a hybrid of the two, and returns a candidate set. Stage two — reranking — takes that shortlist and re-scores every candidate with a more expensive, higher-precision model, then reorders. The one-line version everyone converges on: retrieve cheaply and broadly, rerank precisely on a small set, then serve or generate.

Bi-encoders vs cross-encoders: the core mechanic

The whole topic hinges on one architectural distinction — when the query and the document meet.

• Bi-encoder (the first-stage retriever). It encodes the query and each document separately, each into its own vector, and then compares the two vectors with something like cosine similarity. Because the document vectors don’t depend on the query, you can compute and index them ahead of time, which is what makes retrieval fast enough to run across an entire corpus. The cost: query and document never actually interact, so the model has to, in effect, compress every possible meaning of a document into a single vector — and nuance gets lost. Bi-encoders are what embeddings and vector search are built on.
• Cross-encoder (the stage-two reranker). It encodes the query and one candidate document together, as a single joint input through a transformer, and outputs a single relevance score for that pair. Because the model sees both at once, it can directly weigh how the specific words of the query relate to the specific words of the document — far more accurate. The cost: nothing can be precomputed. Every query-document pair has to be run through the model at query time, so it’s far too slow to apply to a whole index. That’s precisely why it’s reserved for the shortlist.

Google, notably, describes this exact mechanism in its own words. In the Google Cloud retrieval/ranking docs, one of the listed retrieval signals is cross-attention, defined as something that “allows a model to consider the relationship between a query and a document to assign a relevance score to the document.” That is the cross-encoder idea under a different name.

Why not just use the accurate model on everything?

Latency and cost make it infeasible at scale, and the gap is enormous, not marginal. Pinecone’s write-up on two-stage retrieval puts a concrete number on it: on a 40-million-record set, running a BERT-style cross-encoder reranker over everything on a V100 GPU would take more than 50 hours, versus under 100 milliseconds for vector search. (Pinecone, “Rerankers and Two-Stage Retrieval”) That’s the entire justification for the two-stage design — you get most of the cross-encoder’s accuracy while only paying its cost on a few dozen or few hundred candidates.

Vectara frames the same myth directly — the question of why not just score all documents with the most precise model if it’s available — and the answer is the same: you can’t, so you filter cheaply first. (Vectara, “What is reranking and why does it matter?”)

How Google does this

Google has never published an official statement using the terms “reranking,” “cross-encoder,” or “bi-encoder” about Google Search itself — worth stating plainly so we don’t overclaim. But the function is documented under other names.

Google’s own Guide to Google Search Ranking Systems names two systems that do reranking’s job:

• BERT — “an AI system Google uses that allows us to understand how combinations of words express different meanings and intent.” BERT jointly reads the words of a query in context; a BERT-based reranker scores query-document relevance the way a cross-encoder does.
• Passage ranking — “an AI system we use to identify individual sections or ‘passages’ of a web page to better understand how relevant a page is to a search.” That’s reranking at the passage level rather than the page level (see passage ranking for the deep dive).
• RankBrain — Google’s earlier system that “helps us understand how words are related to concepts,” so it can return relevant content even without exact-match words.

Google Research has also published the mechanism outright: its paper Learning-to-Rank with BERT in TF-Ranking describes encoding queries and documents with BERT and applying a learning-to-rank layer on top, and explicitly frames it as passage re-ranking — reporting the best performance on the MS MARCO passage re-ranking task as of March 30, 2020. That’s a Google Research publication rather than Search Central product guidance, so treat it as Google’s technical research, not a statement about the live Search pipeline.

One number worth hedging: the “cut down to the top 1,000 results, then reorder them” framing that circulates widely in SEO traces back to my own conference deck’s interpretation of public research and patents — not a current, verbatim Google statement about web Search. Google Cloud’s enterprise search product does document a concrete pipeline (“the model retrieves documents in the order of thousands… The ranking model then orders the retrieved documents and serves the top 400 ranked results”), but that’s the Vertex AI Search product, not Google web Search. Don’t assume either the 1,000 or the 400 applies to Google Search itself.

How Bing/Microsoft does this

Microsoft is much more explicit, and its clearest documentation is the closest thing to an official production-reranker description you’ll find. Azure AI Search’s semantic ranker is documented as “a feature that measurably improves search relevance by using Microsoft’s language understanding models to rerank search results” — and crucially, “the underlying technology is from Bing and Microsoft Research.”

The mechanics map cleanly onto the two-stage pattern:

• It “always adds secondary ranking over an initial result set that was scored using BM25 or Reciprocal Rank Fusion (RRF).” Stage one is BM25 or RRF; the semantic ranker is stage two.
• Microsoft calls that stage L2 ranking, which “uses the context or semantic meaning of a query to compute a new relevance score over preranked results.”
• It only reranks the shortlist, never the whole corpus: “What semantic ranker can’t do is rerun the query over the entire corpus… Semantic ranking reranks the existing result set, consisting of the top 50 results as scored by the default ranking algorithm.” Even if more than 50 results come back, “only the top 50 results progress to semantic ranking.”

Bing’s own May 2026 blog on the evolving role of the index doesn’t name reranking directly, but reinforces that retrieval quality is now judged by answer-support reliability: “Retrieval systems must therefore optimize not just for one-shot retrieval, but for consistent, repeatable behavior across iterative use.”

Reranking in RAG and AI search

This is where reranking touches AI Overviews, AI Mode, Copilot, ChatGPT Search, and Perplexity most directly. In a RAG pipeline, reranking is a named stage between retrieval and generation: content is chunked, each chunk is embedded and stored, the query retrieves nearby chunks by vector similarity, a reranker re-scores those candidates, and only the top survivors get handed to the LLM as context. The reranker is the gate between “your passage was retrieved” and “your passage was actually used.”

That gate can be strict. In AI-search systems, only a fraction of retrieved sources typically clear the rerank threshold into the generation stage — so being pulled into the candidate pool is the price of entry, not a guarantee of a citation. As Ahrefs’ own research on optimizing for LLM search frames the core problem: “AI companies don’t reveal how LLMs select sources, so it’s hard to know how to influence their outputs.” Reranking is a big part of that hidden selection step.

Reranking vs. Reciprocal Rank Fusion (RRF)

These get conflated constantly — including in otherwise-good SEO content — and they’re not the same mechanism.

• Reranking rescores one candidate pool by jointly evaluating each query-document pair with a single model (the cross-encoder). It asks: how relevant is this document to this query, really?
• Reciprocal Rank Fusion (RRF) merges multiple already-ranked lists — for example, the results from BM25 and the results from vector search, or the results from several fan-out sub-queries — by rewarding documents that appear consistently across lists. Ahrefs’ Query Fan-Out explainer describes it: fan-out queries are searched across indexes “using reciprocal rank fusion (RRF) — a method that scores and merges multiple lists of results by rewarding those that appear consistently across them.”

Both can live in the same pipeline — Azure’s semantic ranker literally reranks on top of a BM25- or RRF-ranked set — but RRF is a list-merging step (no model reads your content), while reranking is a content-scoring step (a model reads the query and your passage together). If you take one disambiguation away: RRF combines lists; reranking re-reads content.

A brief history: BM25 → RankBrain → BERT → LLM rerankers

Reranking isn’t new — it’s the modern name for a pattern search has used for years. The throughline, which I walk through in my Ahrefs Evolve 2025 talk GEO? AEO? LLMO? What’s With All This AI Stuff?:

• BM25 / lexical retrieval — the classic keyword-match scoring that still does first-pass narrowing.
• RankBrain (2016) — Google’s first machine-learning ranking system, understanding words as concepts.
• BERT / DeepRank (2019) — contextual, passage-level language understanding; the cross-encoder-style reranking era begins.
• Modern LLM-based rerankers (RankEmbed and RAG-era cross-encoders) — neural rerankers now sit between retrieval and generation across AI search.

The consistent shape across all of them: cheap broad retrieval first, expensive precise reordering of a shortlist second.

What this means for content and SEO

Because a cross-encoder scores the query and your passage jointly, the practical implications reinforce best practices you already know — now with a mechanism behind them:

• Write self-contained passages. A reranker scores a passage largely on its own merits against the query. A section that only makes sense in the context of the three paragraphs above it scores worse than one that reads as a complete answer. This ties directly to passage ranking and chunking.
• Answer the specific question, near the top of the section. Direct answers score better than build-up. Put the answer first, then elaborate.
• Minimize ambiguity. Pronouns and context-dependent phrasing (“as mentioned above,” “this approach”) that only resolve elsewhere on the page make a passage harder to score in isolation. Name the thing.
• Retrieval is still the prerequisite. Reranking only ever sees what retrieval hands it. A page that can’t be crawled and indexed, or that never gets retrieved, never reaches the reranker at all. Fix findability first; optimize passages second.

None of this is a knob you submit to Google. It’s the same “be clear and be found” advice, aimed at the specific stage — the second look — that decides which retrieved content actually gets used.

AI summary

A condensed take on the Advanced version:

• Reranking = stage two of a retrieval pipeline. Stage one retrieves a candidate set cheaply and broadly (BM25, vector search, or hybrid); stage two re-scores and reorders that shortlist with a slower, more precise model before results are served or fed to an LLM.
• Bi-encoder vs cross-encoder is the core mechanic. A bi-encoder encodes query and document separately into vectors and compares them — fast, precomputable, less precise; it’s the retriever. A cross-encoder encodes them together and outputs one relevance score per pair — slower, can’t be precomputed, more accurate; it’s the reranker.
• Why two stages: the accurate model is too slow to run over a whole corpus. Pinecone: a cross-encoder over 40M records ≈ 50+ hours vs under 100ms for vector search. Retrieve cheap, rerank the shortlist.
• Google doesn’t say “reranking” publicly, but BERT and passage ranking do the job, and Google Cloud’s docs list cross-attention (the cross-encoder idea). The “top 1,000 then reorder” figure traces to Patrick’s deck interpreting research / patents — not a verbatim current Google-Search statement.
• Bing/Microsoft documents an explicit reranker: Azure AI Search’s semantic ranker (L2 ranking) reranks a BM25- or RRF-ranked set, only the top ~50 results, using tech “from Bing and Microsoft Research.”
• In RAG/AI search, reranking is the gate between “retrieved” and “actually used” — only some retrieved sources clear it into generation.
• Reranking ≠ RRF. RRF merges multiple ranked lists; reranking re-scores one candidate pool by reading query + passage together. Often conflated; not the same.
• SEO upshot: because rerankers score query-passage pairs jointly, self-contained, unambiguous passages that answer a specific question directly score better. Retrieval (crawlable + indexed) remains the prerequisite.

Official documentation

Primary-source documentation on retrieval and reranking from the search and cloud providers.

Google

• About retrieval and ranking (Google Cloud / Vertex AI Search) — the clearest official Google description of the retrieval→ranking split, the cross-attention signal, and the top-400 serving figure (for the enterprise product, not web Search).
• A Guide to Google Search Ranking Systems — BERT, passage ranking, and RankBrain in Google’s own words (the systems that do reranking’s job in Search).
• Learning-to-Rank with BERT in TF-Ranking (Google Research) — Google’s own cross-encoder passage re-ranking research on MS MARCO.

Microsoft / Bing

• Semantic ranking overview — Azure AI Search — Microsoft’s most detailed public reranker documentation: L2 ranking over a BM25/RRF set, top-50 only, tech “from Bing and Microsoft Research.”
• The science behind semantic search (Microsoft Research) — the research underlying the semantic ranker (BM25 base + Transformer reranking).
• Evolving role of the index (Bing Search Blog, May 2026) — retrieval reliability for answer systems.

Vendor / RAG references

• Rerankers and Two-Stage Retrieval (Pinecone) — the bi-encoder information-loss explanation and the 50-hours-vs-100ms latency benchmark.
• Using Cross-Encoders as reranker (Weaviate) — the “fast but less accurate” vs “accurate but slow” framing and the multistage pipeline.
• What are Rerankers? (MongoDB) — definition, role in search, and RAG optimization.
• What is reranking and why does it matter? (Vectara) — the “why not just use the expensive model on everything” question.

Quotes from the source

On-the-record statements from Google and Microsoft. Each link is a deep link that jumps to the quoted passage on the source page.

Google Cloud — the retrieval-then-ranking split

• “In short, retrieval is finding relevant documents, while ranking is ordering those retrieved documents. Ranking all the available documents can be computationally expensive. Therefore, retrieval and ranking work sequentially.” — Google Cloud, “About retrieval and ranking.” Jump to quote

Google Search Central — the systems that do reranking’s job

• “Bidirectional Encoder Representations from Transformers (BERT) is an AI system Google uses…” — Google Search Central, “A Guide to Google Search Ranking Systems.” Jump to quote
• “Passage ranking is an AI system we use to identify individual sections or ‘passages’ of a web page…” — Google Search Central, same guide. Jump to quote

Microsoft — an explicit, Bing-derived reranker

• “In Azure AI Search, semantic ranker is a feature that measurably improves search relevance by using Microsoft’s language understanding models to rerank search results.” — Microsoft Learn, “Semantic ranking overview.” Jump to quote
• “What semantic ranker can’t do is rerun the query over the entire corpus to find semantically relevant results. Semantic ranking reranks the existing result set, consisting of the top 50 results as scored by the default ranking algorithm.” — Microsoft Learn, same page.

Bing — retrieval for answer systems

• “Retrieval systems must therefore optimize not just for one-shot retrieval, but for consistent, repeatable behavior across iterative use.” — Krishna Madhavan, Knut Risvik, Meenaz Merchant (Microsoft AI), Bing Search Blog, May 2026. Read the source

The mental models

1. Retrieve broad, rerank precise. Stage one casts a wide, cheap net; stage two reads the shortlist carefully. When an AI answer or search result is missing your page, ask which stage dropped it: were you never retrieved into the candidate set, or were you retrieved but reranked below the cut? They’re different problems with different fixes (findability vs. passage clarity).

2. Bi-encoder vs cross-encoder — separate vs joint. A bi-encoder encodes query and document apart and compares vectors — fast, indexable, lossy. A cross-encoder encodes them together and scores the pair — slow, exact, can’t be precomputed. Retrieval uses the first; reranking uses the second. That single “separate vs joint” distinction explains the whole speed/accuracy trade.

3. The expensive model earns its keep only on a shortlist. You can’t run a cross-encoder over a billion pages (50+ hours on 40M records). The two-stage design exists precisely so you pay the precise model’s cost on dozens or hundreds of candidates, not the whole corpus. That constraint is the reason reranking is a separate stage.

4. Reranking ≠ RRF. Reciprocal Rank Fusion merges multiple ranked lists (BM25 + vector, or fan-out sub-queries) by rewarding cross-list agreement — no model reads your content. Reranking re-scores one pool by reading query + passage together. RRF combines lists; reranking re-reads content.

5. Same function, different names. “Reranking” is vendor/ML vocabulary. Google calls its versions BERT and passage ranking; Microsoft calls its version the semantic ranker / L2 ranking. Absence of the word in Search Central docs isn’t absence of the function.

6. The content decision rule. There’s no reranker knob to submit. Ask instead: does this passage answer a specific question clearly, on its own, without depending on the rest of the page? If yes, it scores well when a cross-encoder reads it next to the query. If it needs the surrounding context to make sense, it doesn’t.

Reranking — cheat sheet

What it is in one line The second stage of retrieval: re-score and reorder a retrieved shortlist with a slower, more precise model before serving or generating.

Bi-encoder vs cross-encoder

Who does what (by name)

Reranking vs RRF

Fast facts

• Two-stage design exists because cross-encoders are too slow for a full corpus: ~50+ hours (40M records) vs <100ms for vector search (Pinecone).
• Google never publicly uses “reranking”/“cross-encoder”/“bi-encoder” for web Search itself — BERT and passage ranking are the named equivalents.
• Azure semantic ranker only reranks the top ~50 retrieved results, never the whole corpus.
• The “top 1,000 then reorder” figure is from Patrick’s deck reading public research / patents — not a verbatim Google-Search statement.

My page isn’t showing up — is it retrieval or reranking?

A quick way to locate which stage is failing before you change anything. Reranking and retrieval are different problems; fixing the wrong one wastes effort.

Start: is the page indexed at all?

• No → It’s a crawl/index problem, upstream of both. Fix crawling and indexing first — nothing reaches retrieval or reranking until the page is in the index.
• Yes → continue.

Does the page rank / get retrieved for the broad query at all (even low)?

• No, it’s nowhere → This looks like a retrieval miss: the first-stage retriever isn’t pulling you into the candidate set. Work on topical relevance, on being a genuine match for the query’s meaning (embeddings / semantic search), and on internal links and authority so you’re a candidate at all.
• Yes, you appear but low / not cited → This looks like a reranking miss: you’re in the shortlist but scored below the cut. Continue.

Does the relevant section read as a self-contained answer to the specific query?

• No — it depends on surrounding context, uses ambiguous pronouns, buries the answer → This is the highest-leverage fix. Rewrite the passage to answer the specific question directly, near the top of the section, without depending on the rest of the page (see passage ranking and chunking).
• Yes — it’s already a clean, direct answer → You’re likely losing on authority / competition, not clarity. Stronger, more authoritative competing sources are being reranked above you; the lever there is E-E-A-T and links, not more rewriting.

Rule of thumb: nowhere at all → retrieval; present but not chosen → reranking. Don’t rewrite passages to fix a page that was never retrieved, and don’t chase links to fix a passage that reads poorly in isolation.

Reranking anti-patterns

Common ways people misunderstand or misuse the concept.

Treating “retrieved” as “done.” Being pulled into the candidate set is the start, not the finish. The reranker still has to score you above the cut. Optimizing only for retrieval (getting found) and ignoring passage clarity (surviving the rerank) leaves results on the table.

Confusing reranking with Reciprocal Rank Fusion. RRF merges multiple ranked lists by cross-list agreement; reranking re-scores one pool by reading query + passage together. Content that “wins RRF” (appears across many lists) and content that “wins reranking” (reads as the best answer) aren’t the same thing. Plenty of otherwise-good SEO writing blurs these — don’t.

Assuming the “top 1,000 → reorder” number applies to Google web Search. That figure comes from my own deck’s interpretation of public research and patents. The documented “thousands retrieved, top 400 served” pipeline is Google Cloud’s enterprise search product, not Google web Search. Cite the mechanism, hedge the specific numbers.

Chopping content into tiny fragments “for the reranker.” Reranking rewards passages that read as complete, self-contained answers — not confetti. Over-fragmenting destroys the context that makes a passage scorable. Clear H2/H3 structure with a direct answer per section chunks well on its own; you don’t need to shred the page.

Believing “if Google doesn’t say ‘reranking,’ it isn’t happening.” The vocabulary differs from the function. Google’s BERT and passage ranking, and Microsoft’s semantic ranker, do exactly this job. Absence of the word isn’t absence of the mechanism.

Thinking a cross-encoder “replaces” vector search. They’re sequential, not competing. Cross-encoders are too slow to run over a whole corpus, so bi-encoder / vector retrieval is still required as stage one. You need both.

Test yourself: Reranking

Five quick questions on how reranking reorders retrieved results. Pick an answer for each, then check.

Resources worth your time

My related writing & speaking

• GEO? AEO? LLMO? What’s With All This AI Stuff? — my Ahrefs Evolve 2025 talk on the BM25 → RankBrain → BERT/DeepRank → RankEmbed lineage that reranking sits inside. (YouTube version.)
• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking, including the retrieve-then-reorder (“post-retrieval adjustments”) stage. My standing disclaimer applies: this is my understanding of these systems, not a guaranteed-complete or perfectly accurate account, and the exact candidate-set numbers are my reading of public research and patents.

My speaking (broader AI search)

• What We Actually Know About Optimizing for LLM Search — Ahrefs’ write-up using my research; frames how little AI companies reveal about how sources get selected (the step reranking is part of).

From around the industry

• Rerankers and Two-Stage Retrieval (Pinecone) — the bi-encoder information-loss explanation and the 50-hours-vs-100ms latency benchmark.
• Using Cross-Encoders as reranker in multistage vector search (Weaviate) — the clean “fast but less accurate” vs “accurate but slow” framing.
• What are Rerankers? (MongoDB) — definition, role in search, and how rerankers fit into RAG.
• What is reranking and why does it matter? (Vectara) — the “why not just use the expensive model on everything” myth-busting.
• Semantic ranking overview (Microsoft Learn) — the clearest public production-reranker documentation, explicitly built on Bing tech.
• AI Search Architecture Deep Dive (Mike King, iPullRank) — ties cross-encoder reranking to Bing Copilot’s inferred pipeline (treat the architecture specifics as informed inference, not official Microsoft statements).
• What is Query Fan-Out? (Despina Gavoyannis, Ahrefs) — covers Reciprocal Rank Fusion, the adjacent-but-distinct concept reranking is often confused with.
• Query fan-out in AI search: What is it and how does it work? (Search Engine Land) — more on RRF and fan-out synthesis, for the disambiguation.

Reranking

Reranking is the second stage of a retrieval pipeline: after a cheap, broad first pass pulls a candidate set of documents or passages, a slower, more precise model re-scores and reorders that shortlist by true relevance before the results are served or handed to an LLM.

Related: Embeddings, Vector Search, Retrieval-Augmented Generation (RAG)

Reranking

Reranking is the second stage of a two-stage (or multi-stage) retrieval pipeline. First, a cheap, broad retrieval pass pulls a candidate set of documents or passages from a large corpus — via keyword/BM25 matching, embedding/vector similarity, or both. Then a second, more computationally expensive model re-scores and reorders that smaller candidate set by true relevance before it’s shown to a user or handed to an LLM for generation (RAG, AI Overviews, AI Mode, Copilot).

The two model architectures at the center of the topic:

• Bi-encoder — encodes the query and each document separately into vectors, then compares the vectors (e.g., cosine similarity). Fast and scalable because document vectors can be precomputed and indexed, but it loses nuance since the query and document never interact. This is the first-stage retriever.
• Cross-encoder — encodes the query and a candidate document together, jointly through a transformer, producing a single relevance score per pair. More accurate because it captures the interaction between query and document, but far slower and can’t be precomputed — it must run at query time on every candidate pair. This is the stage-two reranker.

The one-line pattern: retrieve cheaply and broadly, then rerank precisely on a small candidate set, then serve or generate. Google doesn’t use the word “reranking” in its Search Central docs, but two of its named ranking systems — BERT and passage ranking — do exactly that job, and Microsoft documents an explicit reranker (Azure AI Search’s semantic ranker, adapted from Bing). Reranking is distinct from Reciprocal Rank Fusion (RRF), which merges multiple already-ranked lists rather than re-scoring a single candidate pool.

Related: Embeddings, Vector Search, Retrieval-Augmented Generation (RAG)

Changelog