Reranker Models

Reranker Models sind KI-Modelle, die eine bereits gefundene Trefferliste (die besten 50 bis 200 Textausschnitte aus einer vorgelagerten Suche) nach Relevanz zur Nutzerfrage neu sortieren. Sie arbeiten meist als Cross-Encoder (ein Modelltyp, der Frage und Textausschnitt gemeinsam liest) und geben für jedes Paar einen Relevanz-Wert aus.

Was sind Reranker Models?

Reranker Models sitzen als zweite Stufe in einer zweistufigen Suchpipeline (dem sogenannten Retrieval, also dem Auffinden passender Textstellen). Die erste Stufe ist eine günstige, breite Vorauswahl: eine Vektor-Datenbank (ein Suchsystem, das Texte über ihre semantische Ähnlichkeit findet), eine klassische Volltextsuche mit dem Verfahren BM25 (Best Matching 25, ein etablierter Ranking-Algorithmus für Stichworttreffer) oder eine Kombination aus beiden. Diese erste Stufe liefert typischerweise 50 bis 200 Kandidaten pro Anfrage. Die zweite Stufe reicht diese Kandidaten zusammen mit der Nutzerfrage (der Query) an das Reranker Model, das jeden Kandidaten einzeln bewertet und die Liste nach dem neu berechneten Score sortiert. Aus der Top-100 werden dann die Top-8 bis Top-20, die an das nachgelagerte Sprachmodell gehen.

Architektonisch handelt es sich fast immer um Cross-Encoder auf Transformer-Basis. Query und Dokument fließen gemeinsam als ein einziger Input in das Modell, üblicherweise verbunden durch ein Separator-Token. Das Modell verarbeitet beide Texte in derselben Attention-Rechnung und gibt am Ende einen skalaren Score aus. Dieser Aufbau erlaubt dem Modell, Token-Interaktionen zwischen Query und Dokument direkt zu bewerten. Genau diese Interaktionen fehlen einem Bi-Encoder-Embedding, weil dort Query und Dokument getrennt in separate Vektoren kodiert werden. Der Preis für die höhere Genauigkeit ist Latenz: Ein Cross-Encoder-Forward-Pass pro Kandidat kostet 10- bis 100-mal so viel Rechenzeit wie ein Embedding-Lookup, weshalb Reranker Models nur auf einer bereits reduzierten Vor-Auswahl sinnvoll sind.

Die Modell-Klasse existiert, weil reine Vektorsuche systematisch Grenzfälle produziert. Semantisch ähnliche, aber inhaltlich falsche Dokumente landen bei Bi-Encoder-Retrieval regelmäßig in den Top-Rängen, weil das Embedding nur eine gepoolte Gesamt-Semantik erfasst. Cross-Encoder holen die verlorene Fein-Interaktion nach: Sie können erkennen, ob ein Dokument die konkrete Frage beantwortet oder nur thematisch in ihrer Nähe steht. Verbreitete Modelle im aktuellen Feld sind [Cohere Rerank](https://docs.cohere.com/docs/rerank-overview) (rerank-3), der [BGE Reranker](https://huggingface.co/BAAI/bge-reranker-large) der BAAI, mxbai-rerank von Mixedbread, Jina Reranker sowie ältere Modelle wie [MonoT5](https://arxiv.org/abs/2003.06713). [ColBERTv2](https://arxiv.org/abs/2112.01488) nimmt eine Sonderrolle ein: Als Late-Interaction-Modell speichert es mehrere Vektoren pro Dokument und berechnet Ähnlichkeit auf Token-Ebene. Damit liegt es zwischen den Modell-Klassen (schneller als ein voller Cross-Encoder, präziser als ein Bi-Encoder).

Abgrenzung zu Reranking, Embedding Models, Retrieval Models und LLM-as-a-Judge

Reranker Models werden regelmäßig mit angrenzenden Bausteinen einer Retrieval-Pipeline vermischt.

Der Unterschied zu Reranking sitzt zwischen Modell-Klasse und Vorgang. Reranker Models sind die neuronalen Modelle für diesen Schritt; Reranking als Vorgang kann auch ohne solches Modell laufen, etwa regelbasiert nach Metadaten, mit klassischem Learning-to-Rank auf Feature-Signalen oder über einfache Score-Kombinationen mehrerer Retriever. Der Begriff Reranker Models bezeichnet ausdrücklich die neuronalen Cross-Encoder-Modelle.

Gegen Embedding Models ist die Abgrenzung architektonisch. Embedding Models arbeiten als Bi-Encoder: Query und Dokument werden getrennt in Vektoren kodiert, Ähnlichkeit ergibt sich aus dem geometrischen Abstand (Cosine oder Skalarprodukt). Das ist billig genug für Millionen Dokumente pro Sekunde. Reranker Models arbeiten als Cross-Encoder: Query und Dokument fließen gemeinsam durch das Modell, Ergebnis ist ein direkt gelernter Score. Beide Modell-Klassen basieren auf Transformer-Architekturen und werden meist mit ähnlichen kontrastiven Loss-Funktionen trainiert, ihre Rolle in der Pipeline ist aber komplementär und nicht austauschbar.

Retrieval Models ist der übergeordnete Begriff für den ersten Schritt der Pipeline. Ein Retrieval Model liefert das Ausgangs-Set, das der Reranker anschließend sortiert. Das kann eine reine Vektorsuche über Embeddings sein, eine BM25-Volltext-Suche, eine Hybrid-Kombination oder ein spezialisiertes Modell wie SPLADE. Reranker Models ersetzen keine dieser Optionen, sondern folgen ihnen nach.

LLM-as-a-Judge klingt wegen der gemeinsamen Bewertungs-Rolle ähnlich, hat aber eine andere Aufgabe. Ein Judge-Modell bewertet in der Regel ganze Antworten oder Antwort-Paare entlang mehrerer Dimensionen (Faktizität, Vollständigkeit, Ton, Format) und wird in der Evaluations-Stufe eingesetzt, außerhalb des Retrieval-Pfads. Reranker Models liefern einen numerischen Relevanz-Score für ein Query-Dokument-Paar und sitzen im Retrieval-Pfad. Beide können in derselben Pipeline vorkommen, an unterschiedlichen Stellen und für unterschiedliche Zwecke.

Beispiel: Reranker im RAG-Retrieval auf Databricks

Eine interne RAG-Anwendung soll technische Fragen zu einem Handbuch-Bestand beantworten. Die Wissensbasis liegt als Chunks in [Mosaic AI Vector Search](https://docs.databricks.com/aws/en/generative-ai/vector-search), indiziert über ein Embedding Model wie bge-large-en-v1.5. Zur Query-Zeit liefert der Vektor-Index zu einer Nutzerfrage die Top-100 Chunks nach Cosine-Similarity: schnell, aber grob. Unter den 100 sind sowohl treffende Chunks als auch thematisch benachbarte, die die konkrete Frage verfehlen.

Die zweite Stufe ist ein Reranker Model. Ausgeführt wird es entweder lokal als Model-Serving-Endpoint (etwa bge-reranker-large in Databricks Model Serving) oder über eine externe API (Cohere rerank-3). Der Reranker bekommt die Query und die 100 Chunks als Eingabe, verarbeitet jedes Paar einzeln und liefert 100 Scores. Aus der neu sortierten Liste werden die Top-8 an das generative Modell (Claude, GPT-4, DBRX) als Kontext übergeben.

Der Effekt ist an zwei Punkten sichtbar. Erstens landen offensichtlich passende Chunks vor semantisch ähnlichen, aber unpassenden; die Antwort-Präzision steigt messbar. Zweitens verschiebt sich das Kosten-Profil: Die Latenz pro Anfrage wächst um die Reranker-Zeit (typischerweise 200 bis 800 Millisekunden für 100 Kandidaten), die Retrieval-Kosten steigen, dafür sinkt der Kontext-Verbrauch im Sprachmodell, weil weniger Chunks pro Antwort nötig sind. In produktiven RAG-Pipelines rechtfertigt sich der Reranker typischerweise über die Präzisions-Gewinne bei fachlich engen Queries, weniger über Kosten-Einsparung.