Reranking in RAG: Cross-Encoder vs. Bi-Encoder

Reranking ist die zweite Retrieval-Stufe in einer RAG-Pipeline: Ein Cross-Encoder bewertet die vom schnellen Bi-Encoder gefundenen Top-Kandidaten erneut und sortiert sie nach echter Query-Relevanz. Laut Anthropic senkt Reranking die Retrieval-Fehlerrate gegenüber reinem Vektor-Retrieval deutlich, auf Kosten höherer Latenz. Reranking ist damit kein optionales Nice-to-have, sondern in produktiven Systemen die zuverlässigste Stellschraube zwischen "semantisch ähnlich" und "tatsächlich relevant".

• Was es macht: Reranking ordnet die vom ersten Retrieval gefundenen Kandidaten neu, bevor sie in den LLM-Prompt gelangen.
• Warum zwei Stufen: Der schnelle Bi-Encoder sorgt für Recall über Millionen Chunks, der genaue Cross-Encoder für Precision auf den finalen Top-k.
• Konkreter Effekt: Anthropic berichtet eine Reduktion der Top-20-Retrieval-Fehlerrate um bis zu 67 Prozent, wenn Contextual Retrieval mit Reranking kombiniert wird.

Warum ein einstufiges Retrieval nicht ausreicht

Klassisches Vektor-Retrieval arbeitet mit einem Bi-Encoder. Dieser kodiert jeden Dokument-Chunk vorab in einen Vektor und legt ihn in einem ANN-Index (meist HNSW) ab. Zur Anfragezeit wird die Query in denselben Vektorraum projiziert, und die Ähnlichkeit wird per Cosine-Distanz berechnet. Das ist extrem schnell und skaliert auf Millionen Einträge, aber es ist eine Näherung. Query und Dokument "sehen" sich nie gemeinsam; das Modell vergleicht nur zwei unabhängig erzeugte Verdichtungen.

Die Folge ist ein typisches Anti-Pattern: Die Top-k-Treffer sind semantisch ähnlich, aber nicht zwingend relevant für die konkrete Frage. Genau hier setzt Reranking an. Es ist eine Post-Retrieval-Stufe, die einen genaueren, aber langsameren, Mechanismus auf eine kleine Kandidatenmenge anwendet, statt auf den gesamten Korpus.

Bi-Encoder vs. Cross-Encoder: der zentrale Unterschied

Der architektonische Kern von Reranking ist der Wechsel vom Bi-Encoder zum Cross-Encoder.

Ein Bi-Encoder verarbeitet Query und Dokument getrennt. Beide werden je in einen Vektor kodiert, die Relevanz ergibt sich erst nachgelagert aus der Distanz dieser Vektoren. Weil Dokument-Embeddings vorab berechnet und indexiert werden können, ist der Bi-Encoder die einzige praktikable Wahl für das initiale Retrieval über große Korpora.

Ein Cross-Encoder verarbeitet Query und Dokument gemeinsam in einem einzigen Forward-Pass. Das Modell sieht beide Texte zusammen und kann Wort-für-Wort-Interaktionen, Negationen und feine Bedeutungsunterschiede berücksichtigen. Das Ergebnis ist eine deutlich präzisere Relevanzbewertung, allerdings muss für jedes Query-Dokument-Paar gerechnet werden. Über Millionen Chunks wäre das prohibitiv teuer; über 50 bis 100 vorgefilterte Kandidaten ist es vertretbar.

Dazwischen liegt der Late-Interaction-Ansatz (ColBERT): Er speichert Token-Level-Embeddings pro Dokument und berechnet die Relevanz über eine MaxSim-Operation zwischen Query- und Dokument-Tokens. Das bietet mehr Genauigkeit als ein klassischer Bi-Encoder bei besserer Skalierbarkeit als ein voller Cross-Encoder, kostet aber deutlich mehr Speicher für die Token-Vektoren.

Position in der Pipeline und Top-k-Strategie

Reranking ist eine fest definierte Stufe im Query-Pfad. Die kanonische Anordnung sieht so aus:

```
[Hybrid Retrieval, top_k = 50-100]
-> [Cross-Encoder Reranker (Cohere Rerank / BGE / Jina)]
-> [top_k = 5-10]
-> [Prompt + Quellen-Zitierung]
-> [LLM]
```

Der entscheidende Punkt: Der Reranker kommt erst nach dem kostengünstigen Bi-Encoder-Recall. Das initiale Hybrid Retrieval (Dense plus BM25, fusioniert via Reciprocal Rank Fusion) liefert bewusst einen großzügigen Kandidaten-Pool von 50 bis 100 Einträgen, um den Recall zu maximieren. Der Cross-Encoder reduziert diesen Pool dann auf die 5 bis 10 wirklich relevanten Chunks, die in den Prompt gelangen.

Diese Verengung ist nicht nur eine Kostenfrage. Ein zu großes Top-k an den LLM führt zum "Lost-in-the-Middle"-Effekt: Relevante Informationen in der Mitte eines langen Kontexts werden schlechter verarbeitet, und die Token-Kosten steigen. Reranking plus ein knappes Top-k von 5 bis 10 ist die Standardgegenmaßnahme, mit dem zusätzlichen Hinweis, die wichtigsten Chunks vorne im Prompt zu platzieren.

Reranking-Modelle im Überblick (Stand Oktober 2026)

Für DACH-Szenarien mit Souveränitätsanforderung ist der BGE-Reranker v2-m3 die naheliegende On-Prem-Option: Er steht unter Apache 2.0, ist multilingual und darf kommerziell im eigenen Rechenzentrum oder in einer EU-Region laufen. Der ältere bge-reranker-large (MIT-Lizenz) deckt laut Modellkarte nur Chinesisch und Englisch ab. Die Jina Reranker v2, v3 und v3.5 (veröffentlicht am 27.07.2026) haben zwar offene Gewichte, stehen aber unter CC BY-NC 4.0. Für einen kommerziellen On-Prem-Einsatz brauchst du eine Lizenz von Jina AI, sonst bleiben die Jina-API, der Elastic Inference Service oder die Angebote auf AWS, Azure und Google Cloud. Jina AI sitzt in Berlin, gehört aber seit Oktober 2025 zu Elastic.

Wer eine API akzeptiert und multilinguale Qualität inklusive Deutsch braucht, greift in der Praxis zu Cohere Rerank. Die Alternative Voyage gehört seit Februar 2025 zu MongoDB, aktuell sind die Modelle rerank-3 und rerank-3-lite. Laut Launch-Beitrag vom 30.09.2026 hat Voyage rerank-3 auf 95 Datensätzen aus 9 Domänen getestet, davon 51 mehrsprachige aus 31 Sprachen. Der LLM-as-Judge-Ansatz (etwa der LLMRanker in Haystack) ist am flexibelsten, aber pro Anfrage am teuersten und sollte nur dort eingesetzt werden, wo die Reranking-Qualität kritisch und das Latenzbudget großzügig ist.

Latenz-/Qualitäts-Tradeoff

Reranking ist die teuerste Stufe im Retrieval-Teil des Online-Pfads (vor der LLM-Generierung), weil der Cross-Encoder pro Kandidat rechnet. In produktiven Systemen liegt die Gesamtlatenz aus Hybrid Retrieval plus Reranking typischerweise bei rund 100 bis 800 Millisekunden. Diese Spanne ist direkt steuerbar:

• Größe des Eingangs-Pools: 100 Kandidaten zu reranken kostet mehr als 30. Je nach Korpus reicht oft ein kleinerer Pool.
• Modellwahl: API-Reranker wie Cohere sind durchsatzoptimiert; ein LLM-as-Judge ist deutlich langsamer.
• Hardware: Selbst gehostete Reranker profitieren stark von GPU-Inferenz; auf CPU steigt die Latenz erheblich.

Der Tradeoff lautet also nicht "Reranking ja oder nein", sondern "wie viele Kandidaten zu welchem Latenzbudget". Für die meisten Enterprise-Use-Cases ist der Präzisionsgewinn die Zusatzlatenz wert.

Numerisches Beispiel: Precision-Steigerung

Anthropic hat in der Veröffentlichung "Introducing Contextual Retrieval" (19.09.2024) konkrete Zahlen über eigene Benchmarks (Code, Fiction, ArXiv-Papers, Science) gemessen; als Reranker diente Cohere. Als Vendor-Eval mit Eigeninteresse zu lesen, aber methodisch dokumentiert:

• Basis (reines Retrieval): Top-20-Retrieval-Fehlerrate 5,7 Prozent.
• Contextual Embeddings allein: Reduktion um 35 Prozent auf 3,7 Prozent.
• Contextual Retrieval (Embeddings plus BM25): Reduktion um 49 Prozent auf 2,9 Prozent.
• Contextual Retrieval plus Reranking: Reduktion um 67 Prozent auf 1,9 Prozent.

Konkret heißt das: Von 1.000 relevanten Dokumenten fehlen anfangs 57 in den Top-20, mit der vollen Pipeline nur noch 19. Reranking allein, als Schritt von 2,9 auf 1,9 Prozent, eliminiert in diesem Setup rund ein weiteres Drittel der verbliebenen Fehler. Für ein produktives RAG-System bedeutet jeder vermiedene Retrieval-Fehler einen Chunk weniger, der das LLM zu einer falschen oder unbelegten Antwort verleitet. Genau deshalb listet die RAG-Praxis "Kein Reranking" als klares Anti-Pattern: Top-k sind dann zwar semantisch ähnlich, aber nicht relevant.

Für Agenturen und B2B-Entscheider

Wer in DACH ein produktives RAG-System aufsetzt, sollte Reranking von Anfang an als feste Pipeline-Stufe einplanen, nicht als nachgelagertes Tuning. Der Hebel ist groß, der Implementierungsaufwand überschaubar: ein zusätzlicher API-Call (Cohere) oder ein selbst gehosteter Reranker mit offener Lizenz wie BGE v2-m3 zwischen Retrieval und LLM. Für Agenturen, die Wissens-Assistenten oder interne Suchen für Kunden bauen, ist Reranking das beste Verhältnis aus Qualitätsgewinn und Aufwand, und ein messbares Argument im Pitch, weil sich die Precision-Steigerung in Evaluations-Frameworks wie RAGAS (Context Precision) belegen lässt. Blck Alpaca konzipiert solche zweistufigen Retrieval-Architekturen inklusive EU-konformer Modellwahl und Latenzbudgetierung. Lass deine bestehende RAG-Pipeline darauf prüfen, ob die richtigen Chunks tatsächlich vorne ankommen.