Reranking

Reranking ist ein zweiter Sortierschritt in einer Suche: Ein erster, breiter Suchlauf holt eine Liste möglicher Treffer aus einem großen Bestand, ein zweites, präziseres Modell (der Reranker) liest diese Liste noch einmal und sortiert sie nach Relevanz neu. Ziel ist, dass die passendsten Ergebnisse ganz oben stehen, bevor sie an ein Sprachmodell (etwa in einer RAG-Anwendung, Retrieval-Augmented Generation) oder an eine Suchoberfläche weitergegeben werden.

Was ist Reranking?

Reranking sitzt in einer Suchstrecke zwischen dem ersten Suchschritt und dem, was mit der Trefferliste am Ende passiert (Sprachmodell, Such-UI oder ein Werkzeug in einem Agenten). Der Ablauf hat zwei Stufen. Die erste Stufe sucht breit: ein Vektorindex (Suche über semantische Ähnlichkeit), eine Volltextsuche wie BM25 (klassische Stichwortsuche mit Ranking-Formel) oder eine Kombination aus beidem (Hybridsuche) liefert typischerweise die besten 50 bis 200 Kandidaten aus einem großen Bestand. Diese Stufe ist darauf ausgelegt, möglichst viele relevante Treffer überhaupt zu finden (Recall, Trefferabdeckung), auch wenn die Reihenfolge noch grob ist. Die zweite Stufe schaut genauer hin: der Reranker liest die Suchanfrage und jeden Kandidaten gemeinsam und vergibt für jedes Paar einen Relevanz-Wert. Nach diesem Wert wird neu sortiert; nur die 3 bis 10 besten Treffer laufen weiter in den Kontext eines Sprachmodells oder in die Ergebnisanzeige.

Der wichtigste architektonische Unterschied betrifft die Modell-Klasse. Ein Bi-Encoder (klassisches Embedding-Modell wie im ersten Retrieval-Schritt) bettet Query und Dokument getrennt in einen Vektorraum ein und rechnet die Ähnlichkeit als Skalarprodukt. Diese Trennung ermöglicht Vorab-Indexierung von Milliarden Dokumenten, verliert aber Interaktionsinformationen zwischen einzelnen Query- und Dokument-Termen. Ein Cross-Encoder hingegen liest Query und Kandidat als ein gemeinsames Input in ein Transformer-Modell und liefert einen Score pro Paar. Das Verfahren ist deutlich präziser, skaliert aber nicht gegen Millionen Dokumente. Genau deshalb existiert die zweistufige Aufteilung: die schnelle erste Stufe filtert auf wenige hundert Kandidaten, die teure zweite Stufe sortiert genau diese um. Die Unterscheidung wurde von [Nogueira und Cho (2019)](https://arxiv.org/abs/1901.04085) für Passage-Reranking mit BERT und von [Reimers und Gurevych (2019)](https://arxiv.org/abs/1908.10084) für Sentence-BERT systematisch beschrieben.

Reranker nutzen unterschiedliche Signale, je nach Modell-Klasse. Klassische Cross-Encoder wie cross-encoder/ms-marco-MiniLM-L-6-v2 oder BAAI/bge-reranker-v2-m3 geben eine Relevanz-Wahrscheinlichkeit pro Query-Passage-Paar aus. Managed-Services wie [Cohere Rerank](https://docs.cohere.com/docs/rerank-overview) oder der semantic-ranker in [Azure AI Search](https://learn.microsoft.com/de-de/azure/search/semantic-search-overview) liefern denselben Score als API-Aufruf, ohne dass ein eigenes Modell betrieben werden muss. Late-Interaction-Modelle wie ColBERTv2 ([Santhanam et al. 2021](https://arxiv.org/abs/2112.01488)) speichern token-weise Embeddings und berechnen einen MaxSim-Score, der Interaktion zwischen Query-Tokens und Dokument-Tokens erlaubt, ohne den vollen Cross-Encoder-Aufwand zu tragen. LLM-basiertes Reranking wie RankGPT oder RankVicuna nutzt Sprachmodelle direkt als Sortierer über eine Kandidatenliste. Die Qualität ist hoch, Latenz und Kosten sind es ebenfalls.

Der Preis des Verfahrens ist zusätzliche Latenz und zusätzliche Kosten. API-Reranker addieren typisch 100 bis 500 Millisekunden pro Anfrage, self-hosted Cross-Encoder je nach Modellgröße und Hardware auch mehr. Der Nutzen ist eine messbar höhere Antwortqualität in RAG-Systemen, weil weniger irrelevante Chunks das Kontextfenster füllen und das Sprachmodell auf präziseren Treffern arbeitet. Die Kennzahlen sind in der Regel NDCG@10, Recall@k oder die nachgelagerte Antwort-Qualität in einer [RAG-Evaluation](/insights/glossar/rag-evaluation/).

Abgrenzung zu Retrieval, Query Rewriting, Reranker-Modellen und Score-Fusion

Der Begriff wird in der Praxis häufig mit angrenzenden Schritten oder Werkzeugen derselben Pipeline vermischt.

Der Unterschied zum ersten Retrieval-Schritt liegt in Zweck und Modell-Klasse. Retrieval optimiert Recall über einen großen Korpus mit einem skalierbaren Bi-Encoder oder invertierten Index. Reranking optimiert Precision über eine bereits gefilterte Kandidatenmenge mit einem präziseren, aber teureren Modell. Beide Schritte ersetzen sich nicht: Reranking ohne vorheriges Retrieval hat keine Kandidaten, ein Retrieval ohne Reranking liefert eine gröber sortierte Liste an das Sprachmodell.

Der Unterschied zu [Query Rewriting](/insights/glossar/query-rewriting/) ist die Position in der Pipeline. Query Rewriting arbeitet vor dem Retrieval an der Anfrage: es formuliert um, expandiert oder zerlegt sie. Reranking arbeitet nach dem Retrieval an der Ergebnisliste: es sortiert Kandidaten um. Die beiden Schritte sind orthogonal und werden häufig kombiniert (erst umformulieren, dann retrieven, dann reranken).

Der Unterschied zu Reranker-Modellen ist Vorgang gegenüber Werkzeug. Reranking bezeichnet den Ansatz und die Pipeline-Position; Reranker-Modelle sind die konkreten Modelle, die diesen Schritt ausführen (Cohere Rerank, bge-reranker-v2-m3, ms-marco-MiniLM, ColBERTv2, RankGPT). Dieser Glossareintrag erklärt den Vorgang; die Modell-Landschaft und die Auswahlkriterien gehören in einen eigenen Glossareintrag zu Reranker-Modellen.

Der Unterschied zu Score-Fusion und Reciprocal Rank Fusion (RRF) liegt darin, dass Fusion kein neues Modell einsetzt. RRF und verwandte Verfahren führen mehrere parallele Ranglisten aus unterschiedlichen Retrievern (etwa aus einer [Hybrid Search](/insights/glossar/hybrid-search/) mit BM25 und Vektor-Zweig) über eine Formel zusammen, die nur mit Rängen und Konstanten arbeitet. Es entsteht eine kombinierte Rangliste, aber kein Kandidat wird durch ein zweites Modell neu bewertet. Fusion ist ein statistischer Schritt, Reranking ein modellgestützter Schritt. In produktiven Pipelines laufen beide oft nacheinander: Hybrid Search fusioniert per RRF, ein Cross-Encoder rerankt die fusionierte Top-k.

Der Vollständigkeit halber grenzt sich RAG-Reranking auch vom Reranking in Recommendation-Systemen ab. Dort beschreibt Reranking eine zweite Stufe nach dem Candidate Retrieval, die Business-Regeln, Diversity oder personalisierte Signale einmischt. Konzeptueller Nachbar mit ähnlicher Zweistufigkeit, aber anderes Ziel als das Retrieval-Reranking in RAG.

Beispiel: Vertragsklauseln-Assistent mit Hybrid Search und Cross-Encoder

Ein interner Wissensassistent auf einer Vertragssammlung zeigt den Nutzen des Verfahrens im Alltag. Ein Sachbearbeiter fragt "Welche Klausel regelt die Haftung bei verspäteter Lieferung im Rahmenvertrag mit Lieferant X?". Der Korpus umfasst 5.000 Vertragsklauseln aus dreißig Rahmenverträgen, gechunkt in Passagen von jeweils 200 bis 400 Tokens.

Die erste Stufe ist eine Hybrid Search. Der BM25-Zweig fängt die exakten Terme "Rahmenvertrag" und "Lieferant X" ab, der Vektor-Zweig fängt semantische Umschreibungen von "Haftung bei verspäteter Lieferung" ab (Verzugshaftung, Lieferverzug, Schadensersatz bei Terminüberschreitung). Reciprocal Rank Fusion führt beide Ranglisten zu einer Top-50-Kandidatenmenge zusammen. Diese fünfzig Klauseln enthalten viele thematisch verwandte Passagen: Haftungsklauseln aus anderen Verträgen, Lieferverzugsklauseln ohne Bezug zu Lieferant X, Klauseln zu Vertragsstrafen, die dem Modell semantisch ähnlich sind.

Die zweite Stufe ist ein Cross-Encoder-Reranker (etwa Cohere Rerank oder bge-reranker-v2-m3 self-hosted). Er bekommt die Query zusammen mit jeder der fünfzig Klauseln einzeln als Input und liefert für jede einen Relevanz-Score. Die Top-5 nach diesem Score enthalten mit hoher Wahrscheinlichkeit die eine korrekte Haftungsklausel aus dem Rahmenvertrag mit Lieferant X plus vier direkt verwandte Klauseln (etwa die zugehörige Definitionsklausel, die Vertragsstrafen-Regelung und die Kündigungsklausel bei wiederholtem Verzug). Diese fünf Passagen laufen in den Kontext des Sprachmodells, das die Antwort formuliert und auf die Fundstellen verweist. Ohne Reranking würden häufig thematisch ähnliche, aber inhaltlich falsche Klauseln aus anderen Verträgen in den Kontext gelangen und die Antwort würde auf die falsche Fundstelle verweisen.

Vergleichbare Muster finden sich in Vendor-Diensten wie Databricks Mosaic AI Vector Search, Azure AI Search mit semantic-ranker, Elastic mit Learned Sparse Encoder plus Cross-Encoder-Rerank, Vespa, Weaviate und Qdrant, die Reranking als konfigurierbaren Schritt der Retrieval-Pipeline anbieten.