Reranking

Reranking is a second, sharper pass that reorders search results before they reach your model. Fast retrieval pulls a wide shortlist; a slower, more accurate model then rescores those candidates so the truly relevant ones rise to the top. It's the heart of two-stage retrieval.

Where you meet it

RAG pipelines — sharpening the chunks before they go into the prompt.
Search and recommendation — a cheap recall stage followed by a precise ranking stage.
Question answering over large corpora, where the right passage is often buried below #1.

What it does

It takes a (query, document) pair and outputs a single relevance score, then sorts the shortlist by that score and keeps the top-k. Unlike the first stage, it judges each candidate against the query directly instead of comparing two precomputed vectors.

The reranker can only reorder what retrieval handed it — first-stage recall is the ceiling on everything that follows.

How it works

Stage 1 — retrieve (bi-encoder). A bi-encoder embeds the query and every document separately into vectors, so document embeddings can be computed offline and searched in milliseconds. Cosine similarity over those vectors returns a generous shortlist — say the top 50 or 100. The goal here is recall: don't lose the right answer, even if it lands at rank 30.

Stage 2 — rerank (cross-encoder). A cross-encoder takes query + document together through one transformer pass, letting every query token attend to every document token. That joint attention yields a far more precise relevance score (Nogueira & Cho's BERT reranker beat the prior state of the art on MS MARCO by 27% relative MRR@10). It rescores only the shortlist and reorders it — the best passage that retrieval ranked #6 can jump to #1.

# stage 1: fast bi-encoder retrieval (high recall)
hits = store.search(query, k=50)

# stage 2: precise cross-encoder rerank
scores = reranker.score(query, hits)
top = sorted(hits, key=scores, reverse=True)[:k]

Why two stages? A cross-encoder must run a full forward pass per (query, document) pair — scoring millions of documents this way takes hours, while vector search returns in under 100 ms. So you let cheap retrieval shrink millions down to dozens, then spend the expensive model only where it counts.

Watch out

The reranker can only see what stage 1 returns. If the right document never makes the shortlist, no rescoring will recover it — first-stage recall caps the whole system's quality.
Latency and cost. Every reranked candidate is a transformer inference. The shortlist size is a direct knob on both speed and spend.
Choose the shortlist (top-N) deliberately. Too small and you starve the reranker of good candidates; too large and you pay for documents that were never going to win.
Cross-encoders don't scale to the full collection. They are a reordering tool for a small set — never a replacement for the vector index.

Go deeper

Reranking ist ein zweiter, schärferer Durchgang, der Suchergebnisse neu ordnet, bevor sie dein Modell erreichen. Schnelles Retrieval holt eine breite Shortlist; ein langsameres, genaueres Modell bewertet diese Kandidaten dann neu, sodass die wirklich relevanten nach oben steigen. Das ist der Kern des zweistufigen Retrievals (two-stage retrieval).

Wo es vorkommt

RAG-Pipelines — die Chunks schärfen, bevor sie in den Prompt gehen.
Suche und Empfehlung — eine billige Recall-Stufe, gefolgt von einer präzisen Ranking-Stufe.
Question Answering über große Korpora, wo die richtige Passage oft unter #1 vergraben liegt.

Was es tut

Es nimmt ein (Query, Dokument)-Paar und gibt einen einzelnen Relevanz-Score aus, sortiert die Shortlist danach und behält die top-k. Anders als die erste Stufe beurteilt es jeden Kandidaten direkt gegen die Query, statt zwei vorberechnete Vektoren zu vergleichen.

Der Reranker kann nur umordnen, was das Retrieval geliefert hat — der Recall der ersten Stufe deckelt alles, was danach kommt.

Wie es funktioniert

Stufe 1 — Retrieval (Bi-Encoder). Ein Bi-Encoder bettet Query und jedes Dokument getrennt in Vektoren ein, sodass Dokument-Embeddings offline berechnet und in Millisekunden durchsucht werden können. Kosinus-Ähnlichkeit über diese Vektoren liefert eine großzügige Shortlist — etwa die Top 50 oder 100. Das Ziel hier ist Recall: die richtige Antwort nicht verlieren, selbst wenn sie auf Rang 30 landet.

Stufe 2 — Rerank (Cross-Encoder). Ein Cross-Encoder schickt Query + Dokument zusammen durch einen Transformer-Durchlauf, sodass jedes Query-Token auf jedes Dokument-Token attenden kann. Diese gemeinsame Attention ergibt einen weit präziseren Relevanz-Score (Nogueira & Chos BERT-Reranker schlug den vorigen State of the Art auf MS MARCO um 27% relativ in MRR@10). Er bewertet nur die Shortlist neu und ordnet sie um — die beste Passage, die das Retrieval auf #6 setzte, kann auf #1 springen.

# Stufe 1: schnelles Bi-Encoder-Retrieval (hoher Recall)
hits = store.search(query, k=50)

# Stufe 2: präziser Cross-Encoder-Rerank
scores = reranker.score(query, hits)
top = sorted(hits, key=scores, reverse=True)[:k]

Warum zweistufig? Ein Cross-Encoder braucht pro (Query, Dokument)-Paar einen vollen Forward-Pass — Millionen Dokumente so zu scoren dauert Stunden, während Vektorsuche unter 100 ms zurückkommt. Also lässt du billiges Retrieval Millionen auf Dutzende schrumpfen und setzt das teure Modell nur dort ein, wo es zählt.

Worauf achten

Der Reranker sieht nur, was Stufe 1 liefert. Schafft es das richtige Dokument nie in die Shortlist, kann kein Rescoring es zurückholen — der Recall der ersten Stufe deckelt die Qualität des ganzen Systems.
Latenz und Kosten. Jeder gerankte Kandidat ist eine Transformer-Inferenz. Die Shortlist-Größe ist ein direkter Regler für Tempo und Ausgaben.
Wähle die Shortlist (top-N) bewusst. Zu klein, und du hungerst den Reranker an guten Kandidaten aus; zu groß, und du zahlst für Dokumente, die ohnehin nie gewonnen hätten.
Cross-Encoder skalieren nicht auf die ganze Sammlung. Sie sind ein Umordnungs-Werkzeug für eine kleine Menge — nie ein Ersatz für den Vektor-Index.