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. Lassen Sie Ihre bestehende RAG-Pipeline darauf prüfen, ob die richtigen Chunks tatsächlich vorne ankommen.