Cross-Encoder-Reranker im Vergleich: Cohere, bge, Voyage, Jina und Late Interaction (2026)

Ein Reranker liest eine Anfrage und ein Kandidatendokument gemeinsam und liefert einen Relevanzwert. Das ist genauer als der Vergleich zweier Embeddings und viel zu langsam für einen ganzen Korpus. Deshalb ist Suche zweistufig: Ein schneller Retriever findet 50 bis 250 Kandidaten, und ein Cross-Encoder ordnet sie neu, damit die besten wenigen beim Modell ankommen. Zu entscheiden ist, welcher Reranker, wie viele Kandidaten und ob der Gewinn die Latenz wert ist.

Dieser Artikel vergleicht die Bewertungsarchitekturen, die Modelle Stand Oktober 2026, gehostete Preise und Self-Hosting, Late Interaction und LLM-Reranker als Alternativen sowie eine kleine Evaluierung zur Wahl von k. Wo Reranking in der gesamten Pipeline sitzt, steht in RAG-Pipelines: Chunking, hybride Suche und Reranking.

Was ein Reranker bringt und was er kostet

Ein Reranker bringt Präzision an der Spitze der Liste und kostet Latenz proportional zu k. Warum er die Suche nicht ersetzen kann, ist Arithmetik: Das Sentence-BERT-Paper hält fest, dass das ähnlichste Paar unter 10.000 Sätzen etwa 50 Millionen BERT-Inferenzen braucht, rund 65 Stunden, was es „für semantische Ähnlichkeitssuche ungeeignet“ macht (SBERT). Die dokumentierte Produktionsform ist daher ein Bi-Encoder, der Kandidaten findet, und ein Cross-Encoder, der sie neu ordnet (Sentence Transformers).

Die zwei Zahlen, die man vorher kennen sollte, sind der Recall der ersten Stufe bei k und die zusätzliche Latenz für k Paare. Ist das richtige Dokument nicht in den Top 100, findet es kein Reranker; steht es auf Platz 30 und Sie zeigen fünf Treffer, ist ein Reranker genau die Lösung. Produktsuche mit Teilenummern und langen deutschen Komposita ist ein typischer Fall, in dem der richtige Artikel gefunden, aber zu tief eingeordnet wird, siehe semantische Produktsuche im B2B.

Die zweite Zahl ist so wichtig wie die erste. Jeder Kandidat ist für ein pointwise Modell ein weiterer Durchlauf, der Schritt von 50 auf 200 Kandidaten vervierfacht also ungefähr die Reranking-Zeit. In einem interaktiven Suchfeld merkt der Nutzer das; bei einer RAG-Antwort, die ohnehin Sekunden auf die Generierung wartet, spielt es vielleicht keine Rolle. Halten Sie das Latenzbudget fest, bevor Sie Modelle vergleichen, denn es entscheidet, welche Hälfte der Tabelle unten überhaupt infrage kommt.

Wie Reranker bewerten: Paare, Listen und Token-Vektoren

Es gibt drei Architekturen plus Fusion ohne Modell. Ein pointwise Cross-Encoder verkettet Anfrage und ein Dokument und gibt einen Relevanz-Logit aus, k Kandidaten bedeuten also k Durchläufe. Ein listwise Reranker legt Anfrage und alle Kandidaten in ein Kontextfenster und ordnet sie in einem Durchlauf. Late Interaction speichert beim Indexieren einen Vektor pro Token und gleicht Anfrage-Tokens per MaxSim dagegen ab, was den Großteil der Arbeit aus dem Anfragepfad verlagert.

Jina Reranker v3 ist das deutlichste listwise Beispiel: ein 0.6B-Modell, das Anfrage und alle Kandidaten in einem Fenster liest, von Jina als „last but not late interaction“ beschrieben. Version 3.5 vom August 2026 behält 0.6B Parameter, erweitert den Kontext auf 131K Tokens und meldet bis zu 1,56-mal schnelleres Reranking als v3 (Jina). Listwise Modelle sehen die Kandidaten im Verhältnis zueinander, was bei Beinahe-Dubletten hilft, aber die ganze Liste muss in den Kontext passen.

Die Modelle 2026

Stand Oktober 2026 sind die gehosteten Linien Cohere Rerank 4, im Dezember 2025 als rerank-v4.0-pro und rerank-v4.0-fast mit 32k Kontext erschienen, sowie Voyage rerank-3 und rerank-3-lite vom 30. September 2026, ebenfalls mit 32k. Voyage meldet für rerank-3 2,72 Prozent mehr als Cohere Rerank 4 Pro über 95 Datensätze (Voyage); das ist eine Herstellerangabe auf einer Hersteller-Testreihe, kein unabhängiges Ergebnis. Die offenen Modelle sind für kommerzielles Self-Hosting lizenziert.

BAAI/bge-reranker-v2-m3 ist der verbreitete offene Standard: ein mehrsprachiger 0.6B-Cross-Encoder auf XLM-RoBERTa-Basis, Apache-2.0, mit mehr als 15 Millionen Downloads im letzten Monat (Hugging Face). Qwen3-Reranker-8B ist die schwere offene Option aus der Qwen3-Embedding-Reihe, und mxbai-rerank-large-v2 von mixedbread liegt mit 1,54B Parametern, etwa 3,09 GB in FP16, dazwischen und deckt mehr als 100 Sprachen ab (mixedbread).

Zwei praktische Unterschiede zählen mehr als ein Punkt nDCG. Die Kontextlänge entscheidet, ob ein langes Produktdatenblatt oder eine Vertragsklausel als ein Dokument passt oder geteilt werden muss; Coheres v4-Modelle teilen Dokumente bei 32.764 Tokens und behalten den höchsten Chunk-Wert. Die Sprachabdeckung entscheidet, ob deutsche und ungarische Anfragen so gut funktionieren wie englische, weshalb die mehrsprachigen Modelle von bge, mxbai und Cohere die üblichen Kandidaten für europäische Inhalte sind.

Preise: pro Suche, pro Token oder die eigene CPU

Gehostete Reranker werden in zwei verschiedenen Einheiten abgerechnet, was den schnellen Vergleich erschwert. Cohere rechnet pro Suche ab: $2,00 pro 1.000 für Rerank 4 Fast und $2,50 für Rerank 4 Pro, wobei eine Suche eine Anfrage mit bis zu 100 Dokumenten ist und Dokumente über 500 Tokens mehrfach zählen (Cohere-Preise). Voyage rechnet pro Token ab: $0,05 pro Million für rerank-3 und $0,02 für rerank-3-lite (Voyage-Preise).

Rechnen Sie beides vor der Wahl in dieselbe Arithmetik um. Bei 100 Kandidaten mit je etwa 300 Tokens ist eine Anfrage rund 30.000 Tokens: etwa $0,0015 bei rerank-3 und $0,0025 bei Rerank 4 Pro. Bei längeren Chunks kippt das Verhältnis, weil Cohere pro Dokument und Voyage pro Token zählt. Cohere dokumentiert außerdem nützliche Grenzen: eine Obergrenze von 2.048 Tokens pro Anfrage und die Empfehlung, nicht mehr als 1.000 Dokumente pro Request zu senden (Cohere).

Beim Self-Hosting wird der Preis zu Rechenzeit. Auf der CPU ist die Größe die praktische Grenze: FastEmbeds ONNX-Reranker reichen von 0,08 GB für ms-marco-MiniLM-L-6-v2 bis 1,11 GB für jina-reranker-v2-base-multilingual, das nur für nicht-kommerzielle Nutzung lizenziert ist (FastEmbed). Einen primären Benchmark für die CPU-Latenz pro Paar habe ich nicht gefunden, messen Sie also auf eigener Hardware mit eigener Chunk-Länge, bevor Sie sich festlegen. Auf meiner eigenen Nuxt-Seite, auf der ich LLM-Funktionen betreibe, ist der günstige Weg für solche Probleme hybride Suche plus ein kleines ONNX-Modell auf dem Server, nicht ein LLM-Aufruf pro Anfrage.

Late Interaction als Alternative

Late Interaction ist ein anderer Zielkonflikt, kein besserer Cross-Encoder. ColBERTv2 hält einen Vektor pro Token, senkt den Speicherbedarf von Late-Interaction-Modellen per Residualkompression um das Sechs- bis Zehnfache und bewertet zur Anfragezeit mit günstigem MaxSim (ColBERTv2). Bezahlt wird mit Indexgröße statt Anfragelatenz, was zu großem k und hohem Anfragevolumen passt. Für Seitenbilder treibt dieselbe Idee ColPali an, beschrieben in multimodalem RAG mit ColPali. Die Bibliothek rerankers bündelt Cross-Encoder, APIs und Late-Interaction-Modelle hinter einer Schnittstelle, was den Austausch in einer Evaluierung leicht macht (rerankers).

LLM-Reranker und wann RRF allein reicht

Ein allgemeines LLM kann reranken, ist aber selten der günstigste Weg. RankGPT zeigte, dass ein gut instruiertes GPT-4 auf IR-Benchmarks mit überwachten Rerankern mithalten oder sie übertreffen kann und dass ein destilliertes 440M-Modell ein überwachtes 3B-Modell auf BEIR schlug (RankGPT). Voyages eigene Studie argumentiert dagegen und meldet spezialisierte Reranker als bis zu 60-mal günstiger und 48-mal schneller als LLMs (Voyage); beide Quellen haben ein Interesse, also testen Sie mit Ihren Daten.

Reciprocal Rank Fusion ist der günstigste Schritt und oft der erste, den man ergänzt. Sie führt Ranglisten mehrerer Retriever nur anhand ihrer Positionen zusammen; Elasticsearch implementiert sie mit rank_constant, standardmäßig 60, und rank_window_size (Elastic). RRF reicht, wenn BM25 und Vektorsuche jeweils andere gute Treffer finden und die Spitze der fusionierten Liste schon stimmt. Ergänzen Sie ein Modell, wenn das richtige Dokument regelmäßig in den fusionierten Top 50, aber nicht in den Top 5 landet.

k und Modell mit einer kleinen Evaluierung wählen

Starten Sie bei einem bekannten Standard und lassen Sie ein kleines gelabeltes Set ihn verschieben. Der semantische Ranker von Azure AI Search nimmt nur die Top 50 mit und nutzt bis zu 2.000 Tokens pro Dokument, ausgehend von einer BM25- oder RRF-Ergebnismenge (Azure). Das ist ein vernünftiges Start-k. Labeln Sie dann 50 echte Anfragen mit den Dokumenten, die sie beantworten sollten, und messen Sie Recall bei 10 vor und nach dem Reranking für k von 25, 50 und 100.

# A small reranker eval: 50 labelled queries, recall@k before and after reranking
from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

def recall_at(ranked_ids, relevant_ids, n):
    return len(set(ranked_ids[:n]) & relevant_ids) / len(relevant_ids)

for k in (25, 50, 100):
    before, after = [], []
    for q in labelled_queries:                       # [{"text": ..., "relevant": {...}}]
        hits = first_stage(q["text"], k=k)           # your hybrid search: [(id, text), ...]
        scores = reranker.predict([(q["text"], t) for _, t in hits])
        reranked = [i for (i, _), _ in sorted(zip(hits, scores), key=lambda p: -p[1])]
        before.append(recall_at([i for i, _ in hits], q["relevant"], 10))
        after.append(recall_at(reranked, q["relevant"], 10))
    print(k, sum(before) / len(before), sum(after) / len(after))

Erhöhen Sie k nicht weiter, wenn der Recall bei 10 nicht mehr steigt, und wägen Sie das gegen die gemessene Latenz ab. Führen Sie dasselbe Skript mit zwei oder drei Modellen aus und behalten Sie das günstigste, das höchstens einen Punkt unter dem besten liegt. Wiederholen Sie es nach jedem Wechsel des Embedding-Modells, denn die erste Stufe entscheidet, was der Reranker sieht. Wie man solche Evaluierungen in einen Release-Prozess einbaut, steht in LLM-Evals für Produktfunktionen.

Wann kein Reranker nötig ist, und eine Checkliste

Verzichten Sie auf den Reranker, wenn die erste Stufe die richtige Antwort schon unter die ersten Treffer bringt, wenn exakte Bezeichner die Anfragen dominieren und BM25 sie findet oder wenn das Latenzbudget k zusätzliche Durchläufe nicht verkraftet. Dann bringen besseres Chunking, Metadatenfilter oder RRF mehr für weniger. Ergänzen Sie einen, wenn die Evaluierung relevante Dokumente knapp unter der Grenze zeigt.

1. Recall der ersten Stufe bei k messen, bevor ein Reranker gewählt wird.
2. BM25- und Vektortreffer per RRF fusionieren, bevor ein Modell dazukommt.
3. Mit k = 50 beginnen und 5 bis 20 Treffer zurückgeben.
4. Gehostete Preise bei Ihrer Chunk-Länge in Kosten pro Anfrage umrechnen.
5. Vor dem Self-Hosting die Lizenz prüfen; manche Reranker sind nicht-kommerziell.
6. Zusätzliche Latenz auf eigener Hardware messen, nicht aus veröffentlichten Zahlen übernehmen.
7. Die Evaluierung mit 50 Anfragen nach jedem Modell- oder Chunking-Wechsel wiederholen.

Wenn Sie die Suche für ein RAG-System oder eine Produktsuche abstimmen und die Reranker-Entscheidung mit Zahlen belegen wollen, sehen Sie sich meine KI-Engineering-Arbeit an. Die Wahl des Vektorspeichers darunter behandelt die Qdrant-Besprechung.

Quellen

1. Sentence-BERT (arXiv 1908.10084)
2. Sentence Transformers: retrieve and re-rank
3. BAAI/bge-reranker-v2-m3 model card
4. Cohere docs: reranking best practices
5. Cohere pricing
6. Voyage AI blog: rerank-3 (30 Sep 2026)
7. Voyage AI docs: pricing
8. Jina AI: Reranker v3.5 (3 Aug 2026)
9. ColBERTv2 (arXiv 2112.01488)
10. Elasticsearch docs: reciprocal rank fusion
11. Azure AI Search: semantic ranking overview
12. RankGPT (arXiv 2304.09542)