Reranking is one of the simplest methods for dramatically improving recall performance in Retrieval Augmented Generation (RAG) or any other retrieval-based pipeline. The solution is to maximize retrieval recall by retrieving plenty of documents and then maximize LLM recall by minimizing the number of documents that make it to the LLM. To do that, we reorder retrieved documents and keep just the most relevant for our LLM — to do that, we use reranking.

A common optimization technique involves using reranking models as a second-stage process to refine the retrieved documents. Only the top results from this reranked set are kept for the final generation. Since rerankers are computationally expensive, it is important to minimize the number of candidates they process. As a broad indication, vector search should retrieve between 50 and 1,000 candidate documents, and the reranker should refine this to the top five to 20.

Initially, a set of candidate documents or passages is retrieved using traditional information retrieval methods like BM25 or vector similarity search. These candidates are then fed into an LLM that analyzes the semantic relevance between the query and each document. Re-ranking is typically used as a second stage after an initial fast retrieval step, ensuring that only the most relevant documents are presented to the user.

At query time, the manipulated query is compared against the indexed vector store to retrieve a candidate set of ‘top k’ entries via semantic (dense) or lexical (sparse) search.[7] These candidates are then passed to a re-ranking module, which refines their order by computing relevance scores.[7] Finally, the reordered results are provided to a natural language generator, which uses the selected knowledge snippets to produce a contextually relevant response (lewis2020rag; yang2024crag).[7]

Retrieval-Augmented Generation (RAG) enhances LLMs with an information-retrieval mechanism that allows models to access external data beyond their training set. Given a user query, a document retriever is first called to select the most relevant documents that will be used to augment the query. Some models incorporate extra steps to improve output, such as the **re-ranking of retrieved information, context selection, and fine-tuning**, which aim to enhance the quality of document retrieval in vector databases.

Reranking is the second step in a RAG pipeline. First, your retriever fetches a set of candidate chunks. Then, a reranker evaluates the query and each candidate and reorders them based on deeper relevance. In simple terms: Retriever gets possible matches; Reranker picks the best matches.

To address this, cross-encoders are typically employed in a two-step process (Figure 2).[8] In the first step, an embedding model is used to create a semantic representation of the query, which is then used to narrow down potential candidates from millions to a smaller subset, typically tens of passages.[8] In the second step, the cross-encoder model processes these shortlisted candidates, reranking them to produce a final, highly relevant set–often just five passages.[8]

Stage 1: Rapid, approximate retrieval. Utilize a bi-encoder or BM25 to cast a wide net and achieve high recall, identifying your top k candidates. Stage 2: Accurate reranking. Apply a cross-encoder to these candidates in a pairwise manner, resulting in a significantly improved ranking that directly assesses relevance. This two-stage method is already standard in production environments.

RAG consists of two core parts: **retrieval** (finding useful info) and **generation** (producing the final answer). Retrieval evaluation includes ranking metrics like recall@k with ground truth, or manual/LLM-judged relevance scoring of retrieved context. You can prompt an LLM with a user query and a retrieved chunk, and ask it to judge whether the chunk is relevant to the query. The LLM judge output could be a numerical relevance score, which can be used to **re-rank retrieved chunks by relevance** before passing them to the generator.

This video explains how reranking works: for example, if we wanted to return just three documents to the LLM, we might choose to fetch 10 or 15 at this initial step. In the second step, we use our reranking algorithm, so out of these initial documents, we will actually find a better ordering for them.

Re-ranking is the precision layer in modern search and RAG systems.[2] The key takeaways: 1. **Two-stage retrieval** (fast recall + accurate re-ranking) beats single-stage.[2] In the full RAG pipeline: `# Stage 1: Get candidates candidates = self.retrieve(question, top_k=retrieve_k) # Stage 2: Re-rank for precision top_docs = self.rerank(question, candidates, top_k=rerank_k)` before generating the answer.[2]

Rerankers (aka cross-encoders) take the query and each document together as input, producing a similarity score evaluating relevance much more precisely. Though computationally heavier—they run a full transformer pass per query-document pair—the reranker produces a much more accurate ordering. Because of their latency, rerankers work best in a two-stage retrieval architecture: 1. Fast vector-based retrieval to narrow down candidates. 2. Slow but precise reranking to reorder and prune results. The practical fix: Retrieve a broad list of candidates first, then rerank that shortlist to bring the truly most relevant content to the top.

A cross-encoder reranker takes the top 100 candidates from vector search, jointly attends over each query-document pair, and returns a precision-tuned top 10 for the LLM.[3] For most RAG: bi-encoder retrieve (top 100) → cross-encoder rerank (top 10) → LLM generate.[3] Standard pattern: retrieve top K with vector DB, rerank with cross-encoder… Empirical recipe: vary K from 20 to 500… For 80% of RAG: K=100 is right.[3]

Retrieval-augmented generation (RAG) is a technique that enables large language models (LLMs) to retrieve and incorporate new information from external data sources. Given a user query, a document retriever is first called to select the most relevant documents that will be used to augment the query. Some models incorporate extra steps to improve output, **such as the re-ranking of retrieved information, context selection, and fine-tuning**, which refine the ordering of candidates returned by the initial retriever before they are supplied to the LLM.

In retrieval-augmented generation (RAG), the quality of the retrieved documents directly influences the final generation output. However, the initial retrieval step often returns a set of candidate documents with mixed relevance. A reranker plays a critical role in reordering these candidates to identify the most relevant ones, enabling the model to generate more accurate and grounded responses. These rerankers, often transformer-based, significantly boost the quality of generated content by ensuring the most pertinent documents are prioritized. Another key advantage is that reranker inference operates on a document-query pair basis, evaluating one document chunk against a query at a time.

We demonstrate a technique which allows to dynamically adapt the number of documents in a top-k retriever RAG prompt using feedback from the LLM. Another approach is to **retrieve top k chunks via various methods (e.g. semantic via vecdb, lexical via keyword/BM25, fuzzy search, etc.), then apply relevance extraction: use k async/concurrent calls to the LLM to identify relevant extracts from each of these, and feed those into the context for the LLM to compose a final answer**. This effectively acts as a slower, more accurate reranking or filtering step applied to an initially retrieved set of candidates.

Production RAG has moved beyond single-pass vector similarity search into multi-stage pipelines that improve retrieval quality step by step. Production retrieval architecture typically uses five stages, each addressing a different failure mode. Stage 4 Cross-encoder reranking. Re-score retrieved chunks using models that capture nuanced query-document relationships. Research on financial RAG benchmarks showed reranking improved answer correctness from 33.5% to 49.0% across 1,500 queries, with about 120 ms average latency overhead. Here is a simple workflow for the trade-off: Start with one query and one retrieval pass. Add reranking when top-K quality, not raw recall, is the main issue.

Reranking introduces a two-stage process to get the best of both worlds.[6] Stage 1: Retrieval (Recall) → The “Candidate Set”. Here we cast a wide net… By combining Vector Search (concepts) with Keyword Search (exact matches), you maximize the chance that the correct document makes it into the top 50.[6] Stage 2: Reranking (Precision) → The “Ordering”. We use a Cross-Encoder to read the top 50 candidates and push the best ones to the top.[6] In the example, `base_retriever.top_k_results = 20` intentionally fetches more documents than needed, and the cross-encoder compressor is configured to return only the 3 best documents.[6]

Most advanced RAG systems follow a multi-stage pipeline designed to balance recall, precision, and cost: 1. Initial Retrieval – Broad candidate generation using dense, sparse, or hybrid search. 2. Reranking – Deep, query-aware relevance evaluation of retrieved candidates. 3. Generation – Answer synthesis grounded in the top-ranked evidence. At the center of this shift is reranking—the systematic re-evaluation and prioritization of retrieved candidates before they're injected into the model's context. Rather than passing raw retrieved chunks directly to the language model, modern RAG systems introduce a rerank layer that explicitly scores candidates for relevance against the query's full intent.

Choosing the right retrieval model is often the “make or break” moment for any Retrieval-Augmented Generation (RAG) system. A common architecture is to **use a fast retriever to get a larger candidate set and then apply a more expensive model to re-rank or filter those candidates**. For instance, you might take the top-k documents (with k often substantially larger than what will eventually go into the prompt) and then score them with a cross-encoder or LLM-as-a-judge to select the final context. This two-stage retrieval+reranking pipeline is widely adopted in production RAG systems.

Finally, at k=10, the recall reaches 0.90, indicating that 90% of the relevant items are retrieved within the top 10 results. Precision@k is used to measure the ratio of the relevant items in the top k recommended retrieved results. For example, if at k=3 the precision is 0.85, this means that 85% of the top 3 retrieved items are relevant; for k=10, the precision might be lower as more items are considered. These metrics are typically computed for different values of k (e.g., k=3, 5, 10) to tune how many documents are retrieved before **any reranking or context selection** in a RAG pipeline.

A reranking model — also known as a cross-encoder — is a type of model that, given a query and document pair, will output a similarity score. We use this score to re-order (rerank) documents retrieved in a first-stage retrieval step. In this notebook, we show a two-stage retrieval RAG pipeline using rerank models: first, a fast dense retriever is used to fetch top-K candidates, then a slower but more accurate rerank model scores and reorders these candidates before passing the top ones to the generator.

In our case, we utilized a cross-encoder (specifically ms-marco-MiniLM with 22 million parameters) that evaluates the query and chunk together rather than separately.[9] We conducted an ablation study with 3,750 queries across a multimodal RAG pipeline, and we found that the biggest boost came from cross-encoder reranking, which improved accuracy by 7.6 percentage points with minimal impact on latency.[9] This was applied after the initial retrieval stage, reranking the candidate set before generation.[9]

A reranking model, often referred to as a reranker or cross-encoder, is a model designed to compute a relevance score between two pieces of text.[8] This two-stage workflow (fast embedding-based retrieval to tens of candidates, followed by cross-encoder reranking to a small final set) balances efficiency and accuracy for modern information retrieval and RAG systems.[8]

Benchmarks show hybrid retrieval consistently outperforming dense-only retrieval, boosting both precision and recall. The query runs both ways in parallel: once as a vector embedding against your embedded knowledge set and again as a keyword search. It then uses a fusion algorithm to merge results based on scores from both. Another very popular method is **reciprocal rank fusion (RRF), which merges based on ranked positions from each retriever**, effectively reranking the combined candidate set from multiple fast retrievers before passing a smaller subset to the LLM.

Reranking in Retrieval-Augmented Generation (RAG) serves as a secondary filter that enhances the quality of your search outcomes. Once the initial retrieval process gathers documents through methods like vector similarity, the reranker evaluates each result with your query in mind. Consequently, the common approach is to first utilize a retriever with a broad recall (a high K value), followed by a reranker that selectively refines the results from the retrieved documents, effectively combining the advantages of both methods.