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 2026)

Für DACH-Szenarien mit Souveränitätsanforderung sind die Open-Source-Optionen BGE-Reranker und der in Berlin entwickelte Jina Reranker v2 relevant, da sie sich On-Prem oder in EU-Regionen betreiben lassen. Wer eine API akzeptiert und multilinguale Qualität inklusive Deutsch braucht, greift in der Praxis zu Cohere Rerank. 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 Einzelstufe im Online-Pfad, 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: Open-Source-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 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 ursprünglich 57 Fehlern pro 1.000 Anfragen bleiben mit der vollen Pipeline nur noch 19 übrig. 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 Open-Source-Reranker (BGE, Jina) 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.