AI re-ranking is the second-pass scoring step that reorders a small set of retrieved pages or passages by how useful each one is for the specific question, before the system decides what goes into the answer or gets cited. It happens after a first-stage search pulls a broad set of candidates and before the model writes anything, and it is why a page can show up in a system's candidate pool and still never make it into an answer. If you report on AI visibility for clients, this is the stage where a lot of "why did we lose that one" questions actually get answered, or at least get a real explanation instead of a shrug.
This matters because retrieval and citation are not the same event. A page getting pulled into an AI engine's candidate set tells you almost nothing about whether it will end up in the answer. Re-ranking is the stage in between, and understanding it changes what you look at when a client asks why a competitor got cited and they did not.
What happens between retrieval and citation
Picture a simplified pipeline with five stages. A user asks a question. The system interprets it and may rewrite it into one or more search queries. A fast retrieval layer then pulls a broad candidate set of pages or passages, the same kind of vector similarity search covered in our piece on semantic search and embeddings. That candidate set is the boundary of what re-ranking works with. It cannot see anything outside it.
From there, a more expensive relevance model scores each candidate against the actual question and reorders them. That is re-ranking. The system then filters and builds the context it will actually hand to the language model, which may mean removing duplicates or enforcing a hard limit on how many passages get through. The model writes an answer from that narrowed context. Finally, a separate step decides which sources get attached to which claims in the answer.
No single company publishes the exact version of this pipeline they run, and the details differ by engine. Some systems rerank passages before they compress the context, others add extra checks after the answer is already drafted. What holds across the differences is the order of operations: retrieval finds candidates, re-ranking prioritizes them, context selection narrows them further, and citation logic decides which sources get connected to which sentences. Each of those is a separate decision, and a page can lose at any one of them without losing at the others.
Re-ranking can change four things about a candidate. It can move a page's order up or down. It can drop a page below whatever cutoff the system uses, so the page never continues to the next stage. It can change what makes it into the final context, since a more useful passage might bump out a repetitive one. And it can change whether a page even has a chance at citation, since a page that never enters the context has almost no path to being cited later.
There is a hard limit worth knowing before anything else: re-ranking cannot make a missing page appear. If a page never entered the candidate set in the first place, no amount of clever scoring at the re-ranking stage will bring it back. That is a retrieval problem, not a re-ranking problem, and the fix for one is not the fix for the other.
How a re-ranker actually scores candidates
First-stage retrieval is built for speed across a huge corpus, so it treats the query and each document somewhat independently to keep things fast. A re-ranker works with a much smaller set of candidates, so it can afford to look harder. The clearest version of this is cross-encoder reranking, where a model reads the question and a candidate together, as a pair, and produces a single relevance score for that pairing. Sentence Transformers documentation describes exactly this pattern: retrieve a wider set of candidates first, maybe the top 100, then score each one against the query with a cross-encoder and keep the ones that score highest.
The reason this happens in two stages and not one is cost. A cross-encoder has to process every query-candidate pair it scores, so running it against an entire corpus would be far too slow. Running it against a shortlist that a fast retriever already narrowed down is workable. This two-stage pattern, a cheap broad search followed by an expensive narrow one, is close to the standard shape for AI search re-ranking right now, though the exact numbers each system uses for its candidate set and cutoff are implementation choices, not fixed industry defaults.
Cross-encoders are not the only approach. Late-interaction models sit in between a full cross-encoder and a pure first-stage retriever. ColBERT is the well-known example: it encodes the query and the document separately, the fast way, but then compares them with a more detailed token-level calculation than a simple similarity score would give you. It is a middle path that keeps some of the precision of a cross-encoder while costing less to run.
There is also a distinction in how re-ranking models are trained that is worth knowing even though you will rarely see it named directly in a product. Some score each candidate on its own and then sort by score, which is called pointwise. Some compare candidates in pairs and learn which one should rank higher, called pairwise. Some treat the whole candidate list as one object to optimize, called listwise. None of these are visible to you as an outside observer, but they explain why "the reranker just scores every page" is only one possible design, not the only one.
Semantic search re-ranking and why a page moves
Semantic search re-ranking is what actually decides where a page lands once it has already cleared the first cut. A page that made it into the candidate set can still move a long way in either direction, and the reasons usually come down to how specifically it answers the actual question rather than how broadly it covers the topic.
A page gets dropped when it matches the general subject but not the specific question. A page about "AI search" broadly can easily get pulled into the candidate set for a question about how sources get selected after retrieval, but a narrower, more specific page can outscore it once the re-ranker looks closely. A page can also get dropped when it uses the right words without containing an answerable passage. Mentioning the right terms is not the same as having a section that actually resolves the question, and re-ranking systems tend to favor passages that look like they contain a usable answer, especially in a RAG setup where the model needs something it can work with directly.
Length can hurt too. A long page with one genuinely relevant section buried in unrelated material can lose to a page that is entirely about the narrow question, depending on how the system chunks and scores passages. And redundancy plays a role: when several candidates say close to the same thing, a system that cares about the quality of what it hands the model will often favor variety over repeating the same point five different ways, since research on diversity in retrieval-augmented generation has found that favoring a more varied set of passages can meaningfully improve how much useful information actually gets recalled.
A page can also score reasonably well and still lose, simply because the system only has room for so many passages. Being relevant is not the same as being selected.
On the other side, a page moves up when it does something the first-stage retrieval missed. It might directly answer the wording of the question rather than the general topic. It might contain the specific fact, comparison, or definition being asked for. It might resolve an ambiguous part of the query, or add something none of the other candidates already cover. None of this should be read as a signal that any particular SEO factor is driving the boost unless an engine has said so directly. "Answers the question directly" and "gives the model something usable" are the safer, more accurate explanations, and they are also the ones you can act on without guessing at a private algorithm.
RAG re-ranking and the tradeoff it exists to solve
Retrieval-augmented generation systems have a built-in tension. Retrieve too narrow a set of candidates and the answer might miss evidence that was actually available. Retrieve too wide a set and the model's context gets noisy, repetitive, and harder to use well, on top of costing more to process. RAG re-ranking is the answer to that tension: pull a broader set of candidates first, then use a second-stage model to narrow it down to a smaller set that is actually worth sending to the language model.
A typical flow looks like this. Retrieve a relatively wide candidate set. Score every candidate with a reranker. Keep the best-scoring passages. Optionally strip out duplicates or push for some variety among what is kept. Send that narrowed set to the model. Generate the answer and attach or verify citations against it. One documented example retrieves 45 chunks with a simple method and narrows that down to the five most relevant with a reranker. Azure AI Search describes a comparable idea, a second-level semantic ranker that reranks the top 50 results the first stage returned. These specific numbers describe how particular systems are configured, not a standard every system follows, but the shape, wide retrieval into narrow re-ranking, is a common one.
The tradeoff underneath all of this is latency against quality. A reranker that reads every candidate more carefully takes longer and costs more to run than the fast first-stage retriever did. So every system that does this is making a choice about candidate-set size, model size, and how many passages to keep, based on how much latency it can afford and what its corpus and query patterns look like. There is no single right answer, only tradeoffs specific to that product.
Why re-ranking still does not guarantee a citation
This is the part worth sitting with, because it is where most of the confusion in client reporting actually comes from. Re-ranking answers one question: which of the retrieved candidates look most useful for this question. It does not answer a second, separate question: which source should actually get attached to this specific claim in the generated answer, and does that source really support it. That second question is citation selection, and it is a distinct step.
A high-ranking page after re-ranking has a better shot at making it into the model's context, but making it into context is still not the same as being cited. The model might write its answer using only one or two of the sources that made it that far. A citation system might attach a source to a particular sentence based on whether it actually supports that sentence, even if a different source had scored higher overall during re-ranking. Some systems check this directly: research on grounded generation describes checking whether a passage actually supports a statement before letting it get cited, and skipping the citation if that support is not there. Other systems retrieve or match evidence only after the answer has already been written, as a separate verification pass. Claude's citations feature works this way: it splits provided documents into sentences so it can attach a citation to the specific unit of text that supports each claim.
Put together, the sequence runs like this: retrieval gives the system its candidates, re-ranking decides which of those candidates deserve attention, context selection decides what actually reaches the model, and citation logic decides which sources get connected to which claims in what the model writes. Some products blend these steps closely together. Others keep them as distinct components. Either way, the outcome for a page looks the same from the outside: being retrieved is a status in the middle of the process, not a guarantee of anything at the end of it.
Here is a plain example. Say a first-stage retriever pulls eight pages for a question about how an AI system decides which sources to cite. Four are general articles about AI search that barely touch citation. Two talk about retrieval but skip citation entirely. One explains source attribution directly. One is a product page that mentions citations only in passing. The reranker promotes the direct explanation of source attribution because it actually answers the question, demotes the general articles because their match is broad rather than specific, and may drop the product page entirely because its mention of citations is incidental. Whatever survives becomes the model's context, and the model writes its answer from that. The source-attribution page can go all the way through, retrieved, reranked highly, kept in context, and cited. A general AI-search article can be retrieved and then quietly dropped at any of the later stages. And a page can even make it into the final context and still not get cited, if it never ends up directly supporting one of the specific claims in the answer.
What agencies should actually measure
A client report that only tracks "were we cited or not" is hiding the mechanism, and it leaves you with nothing useful to say when the answer is no. Splitting the pipeline into stages gives you a much better diagnostic, and it tells your client something more specific than "the algorithm didn't like us."
| Stage | The question to ask | What losing here actually means |
|---|---|---|
| Candidate retrieval | Did the page enter the candidate set at all? | The page may be invisible to first-stage retrieval, or poorly represented for that query |
| Re-ranking | Did the page survive the second pass? | Other candidates were judged more directly relevant, more answerable, or less redundant |
| Context selection | Did the page make it into what the model actually saw? | It may have lost to a context-size limit, a diversity rule, or deduplication |
| Generation | Did the model actually use the page's information? | The model may have answered using other selected evidence instead |
| Citation or attribution | Did the page get attached to a specific claim? | The page may not have directly supported any generated statement |
For ongoing reporting, it helps to track the prompt, the engine, whatever candidate status you can observe, the final cited page, the specific passage or claim it was cited for, and which competitor pages won the same question instead. Be upfront with clients about what you cannot see: in most cases you can observe the final answer and its citation history, but not the engine's private scoring at each internal stage. That is a real limit, not a gap in your process. If you are standing this up for a new account, build these stage checks into a content pilot for a new client from the start, so the first few months produce a real answer. And across more than one account, keeping the same rigor and quality across multiple client accounts takes a system, not just a template.
This is also where a platform that watches AI answers over time earns its keep, rather than trying to reverse-engineer a private reranker. DeepSmith tracks how AI engines answer a client's tracked prompts across platforms, records which pages get cited and how often, and shows the competitor pages winning the same questions, so a strategist can point to a pattern across weeks of answers instead of guessing at why one answer went one way. It observes the outcomes of retrieval, re-ranking, and citation together, not what happens inside any engine's private ranking model.
A few things are worth keeping in mind when you read these numbers, on your own reports or anyone else's. Recall tells you whether relevant candidates were found at all, and a reranker cannot fix a recall problem, since it can only work with what retrieval handed it. Precision at a given rank tells you how many of the top results were actually relevant. Metrics like MRR, MAP, and NDCG show up in research and vendor documentation to describe how well a system orders relevant results, but none of them translate into a promise like "reranking improves citations by a fixed percentage." Results depend on the corpus, the query set, the candidate-set size, and the specific reranker and generation model involved, so treat any single benchmark as a description of that particular setup, not a universal rule.
It is also worth remembering that a relevance score from one reranker is not directly comparable to a score from a different one, and neither is a citation probability. That score reflects one system's own judgment, calibrated to its own task, not a portable measure you can apply anywhere else. And more retrieved candidates is not automatically better: a wider net can help recall, but handing all of it to the model just adds noise, which is the problem re-ranking exists to solve in the first place.
