Back

Modern RAG, Part 6: Why Reranking Makes Retrieval Significantly Better

11/8/2026
Richard Vlas

The sixth part of our series about modern Retrieval-Augmented Generation systems.

In the previous post I explained hybrid search and Reciprocal Rank Fusion. The idea was to combine keyword search and vector search and merge their ranking results in a practical way.

That gives us better candidates. But candidates are not the same as final evidence. In other words: the retrieval system may have found documents that are related to the query, but not necessarily the documents that best answer the query.

This is where reranking comes in.

‍

__wf_reserved_inherit

‍

A reranker takes the top candidate documents from the retrieval phase and scores them again with a more precise model.

The first retrieval phase is optimized for recall. It is supposed to find everything that could be relevant.

The reranker is optimized for precision. It is supposed to decide which of these candidates are actually the most useful pieces of evidence.

This is important because the first retrieval phase typically has to search through a large document collection. It must be fast. That is why vector search uses pre-computed document embeddings, and keyword search uses an index.

A reranker is slower and more computationally expensive, so we do not run it over millions of documents. Instead, we only run it over the top candidates.

For example: we retrieve the top 100 documents, run reranking, keep the best 5 or 10, and send those to the LLM. This offers a good balance between speed and quality.

To understand why reranking helps, it is useful to compare bi-encoders and cross-encoders. A bi-encoder processes the query and the document separately.

‍

__wf_reserved_inherit

‍

The query is converted into a vector. The document is converted into another vector. The system then compares the vectors using cosine similarity or another similarity function. That is fast and scalable.

Document embeddings can be computed once and stored in a vector database. When a user asks a question, the system only computes the query embedding and compares it to the stored document embeddings.

That is why bi-encoders are useful for first-stage retrieval. But they have a weakness. The query and the document do not interact within the model. They are compressed separately and only then compared.

A cross-encoder works differently.

‍

__wf_reserved_inherit

‍

It processes the query and the document together.

This means the model can directly compare words, numbers, entities, negations, and relationships. That makes it slower, but generally more precise.

For example, consider this query:

And these two documents:

A bi-encoder might consider both documents similar. Both mention servo alarms, replacement, and machine behavior. But a cross-encoder can look more carefully.

It can recognize that Document A fits the repair situation. It can also recognize that Document B mentions a different alarm code and a different module.

So the reranker might score them like this:

That is why cross-encoders are often used as rerankers. They are too computationally expensive to search the entire document collection, but very useful for re-scoring the top candidates.

At this point we have a strong retrieval pipeline:

That is already significantly better than a simple top-K vector search.

In summary: Reranking makes retrieval more precise. The first retrieval step finds candidates, and the reranker decides which candidates are actually useful.

At this point the retrieval pipeline is already quite strong. But some user questions are not one question. They are several questions packed into one sentence. In the next post, I will explain query planning, decomposition, and agentic retrieval.

Richard is a member of the SABO core team, where he combines deep technical expertise with a focus on clean design and best practices. As a Senior Machine Learning Engineer and Software Architect, he works on intelligent systems such as conversational assistants and AI-driven industrial solutions. His work bridges modern software architecture with real-world machine learning applications, often involving MLOps and scalable infrastructure. In his free time, he enjoys learning new languages and exploring how they shape the way we think and communicate.

Show profile
SABO Mobile IT logo
SABO Mobile IT – Experience
SABO Mobile IT – Experience
SABO Mobile IT – Experience
SABO Mobile IT – Experience
SABO Mobile IT – Experience

SABO IT

SABO IT develops custom software for companies with complex technical processes, from the control unit through the cloud to enterprise systems, including in regulated environments. It also has its own platforms: SenseDrive for source-verified answers from your own knowledge base, and SABOT for voice control of machines. Software development since 1983, as SABO IT since 2012; the average customer relationship lasts 6.5 years.
ABOUT US

More articles

Artikelbild (Platzhalter)
Recommended for you

What does AI in the enterprise really cost? Why the price per user is the wrong number

Three reports from this year show why compute power is becoming a strategic question for European companies. According to Siemens board member Cedrik Neike, European data centers run 20 to 30 percent above US levels in operating costs, while companies, in his estimate, would pay only 5 to 10 percent more for it.
Guido Stanovski,  October 29, 2026
Read article

Book a meeting

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.