Reranking entscheidet über RAG-Qualität: Hybrid Search, Cross-Encoder und Late Interaction

Die häufigste Fehlerdiagnose in RAG-Projekten lautet: „Das Modell ist zu schwach." In den meisten Fällen stimmt das nicht. Wenn ein RAG-System falsche oder unvollständige Antworten liefert, liegt das fast immer daran, dass die richtige Textpassage gar nicht erst im Kontextfenster gelandet ist. Ein größeres Sprachmodell repariert das nicht – es formuliert die falsche Antwort nur eloquenter.

Der Hebel liegt eine Stufe davor, im Retrieval. Und dort gibt es zwei Stellschrauben, die in dieser Reihenfolge wirken: die Kombination aus lexikalischer und semantischer Suche (Hybrid Search) und anschließendes Reranking der Kandidatenliste. Beide sind messbar, beide sind auf eigener Hardware betreibbar, und beide kosten zusammen weniger Aufwand als ein Modellwechsel.

Warum reine Vektorsuche zu wenig ist

Die verbreitete Annahme, semantische Suche habe klassische Stichwortsuche abgelöst, hält der Messung nicht stand. Die bislang gründlichste öffentliche Gegenprobe stammt aus T2-RAGBench (arXiv:2604.01733, 2. April 2026): 23.088 Fragen über 7.318 Finanz- und Tabellendokumente, ausgewertet über verschiedene Retrieval-Konfigurationen. Ergebnis: Reines BM25 schlägt dort die State-of-the-Art-Dense-Suche.

Retrieval-Konfiguration	Recall@1	Recall@5	Recall@10
Dense (text-embedding-3-large)	0,248	0,587	0,703
BM25 (rein lexikalisch)	0,293	0,644	0,735
Hybrid mit RRF	0,308	0,695	0,801
Hybrid + neuronales Reranking	0,472	0,816	0,861

Drei Dinge lassen sich daraus ablesen. Erstens: Auf faktendichten, tabellenlastigen Dokumenten verliert die reine Embedding-Suche gegen ein Verfahren aus den Neunzigerjahren – 0,587 gegen 0,644 bei Recall@5. Zweitens: Die Fusion beider Verfahren gewinnt gegen jedes Einzelverfahren, aber der Zugewinn ist moderat (0,695). Drittens, und das ist der eigentliche Befund: Der große Sprung kommt vom Reranker, nicht von der Fusion. Recall@1 steigt von 0,308 auf 0,472 – die Trefferquote auf Position 1 verdoppelt sich nahezu.

Warum sich die beiden Verfahren ergänzen

BM25 zählt Begriffe und gewichtet sie nach Seltenheit im Korpus. Genau deshalb trifft es zuverlässig, was semantische Modelle systematisch verfehlen: Teilenummern wie „SKF 6205-2RS", Normbezeichnungen wie „DIN EN ISO 9001:2015", interne Kürzel, Produktcodes, Paragraphen. Solche Tokens tauchen im Trainingskorpus eines Embedding-Modells selten bis nie auf; ihr Vektor ist dann kaum informativ, und die Kosinus-Ähnlichkeit gegen die Frage bleibt zufällig.

Die Dense-Suche kann dafür etwas, das BM25 grundsätzlich nicht kann: Sie erkennt, dass „Wie oft muss die Hydraulik gewartet werden?" und „Wartungsintervall Hydrauliksystem: 500 Betriebsstunden" dasselbe meinen, obwohl sie kein Inhaltswort teilen. Das ist bei natürlichsprachlichen, umschreibenden Fragen unersetzlich – also bei genau dem Fragetyp, den Nutzer in einem Chat-Interface stellen.

Fusion richtig gemacht: RRF und Gewichtung

Sobald zwei Suchverfahren parallel laufen, stellt sich die Frage, wie man ihre Ergebnisse zusammenführt. Der naheliegende Weg – Scores addieren oder gewichtet mitteln – ist der falsche. BM25 liefert unbeschränkte positive Scores, deren Größenordnung von Korpus, Dokumentlänge und Termstatistik abhängt; ein BM25-Score von 18,4 bedeutet in einem anderen Index etwas völlig anderes. Kosinus-Ähnlichkeit liegt dagegen fest in [-1, 1]. Diese beiden Zahlen zu addieren ist ein Kategorienfehler, den man nur durch aufwendige, korpusspezifische Normalisierung reparieren kann – und die muss man bei jeder Indexänderung nachziehen.

Reciprocal Rank Fusion umgeht das Problem, indem sie die Scores komplett wegwirft und nur mit den Rängen arbeitet. Jedes Dokument bekommt pro Ergebnisliste den Beitrag 1/(k + Rang), die Beiträge werden summiert:

• Rang statt Score: Ein Dokument auf Platz 1 der BM25-Liste und Platz 4 der Vektorliste erhält 1/61 + 1/64 ≈ 0,0320. Ein Dokument, das nur in einer Liste auf Platz 1 steht, kommt auf 1/61 ≈ 0,0164.
• Die Rangkonstante k: k = 60 ist der Produktions-Default von Elasticsearch und ein guter Startwert. Kleinere Werte im Bereich 30 bis 40 spreizen die vorderen Ränge stärker – sinnvoll, wenn Top-1-Präzision wichtiger ist als Top-10-Recall.
• Robuste Nebenwirkung: Dokumente, die in beiden Listen auftauchen, steigen automatisch – das ist genau das gewünschte Verhalten, ohne dass man eine Gewichtung von Hand tunen müsste.

Latenzbudget: wo die Millisekunden wirklich liegen

Für interaktives Frage-Antwort-Verhalten ist ein Designziel von unter 150 ms p95 für den gesamten Retrieval-Teil sinnvoll – das ist ein Engineering-Zielwert, kein gemessener Branchenstandard. Die Fusionsstufe selbst ist dabei nicht das Problem: Sie besteht aus einem Sortier- und einem Summierschritt über einige hundert Einträge und liegt im einstelligen Millisekundenbereich; Anbieter nennen typischerweise 4 bis 8 ms p50 Zusatzlatenz gegenüber einer reinen Dense-Abfrage.

Zur Einordnung: Die anschließende LLM-Inferenz kostet in der Regel 500 ms bis 2 Sekunden bis zum vollständigen Antworttext. Retrieval-Overhead im zweistelligen Millisekundenbereich ist gegenüber dieser Größenordnung zweitrangig. Wer das Latenzargument gegen Hybrid Search ins Feld führt, optimiert an der falschen Stelle.

Cross-Encoder: höchste Präzision, höchste Kosten

Ein Bi-Encoder – also das übliche Embedding-Modell – kodiert Frage und Dokument getrennt und vergleicht die beiden Vektoren erst am Ende. Das ist der Grund, warum die Vektordatenbank überhaupt funktioniert: Die Dokumentvektoren lassen sich offline berechnen und indexieren. Der Preis ist ein Informationsverlust – das Modell sieht Frage und Dokument nie gleichzeitig und kann daher nicht beurteilen, ob ein bestimmtes Frageelement in diesem konkreten Dokument tatsächlich beantwortet wird.

Ein Cross-Encoder macht genau das Gegenteil. Er bekommt Frage und Dokument als ein einziges Eingabepaar, schickt beide gemeinsam durch den Transformer und gibt einen einzelnen Relevanzwert aus. Jedes Query-Token kann auf jedes Dokument-Token attendieren. Das ist die genaueste verfügbare Form der Relevanzbewertung – und sie erklärt den Sprung von Recall@1 0,308 auf 0,472 in der Tabelle oben.

Das Kostenprofil

Der Nachteil folgt direkt aus der Architektur: Es gibt nichts vorzuberechnen. Für jedes Query-Dokument-Paar läuft ein vollständiger Transformer-Forward-Pass. Die Kosten wachsen proportional zu Kandidatenzahl mal Dokumentlänge. Bei realistischen Shortlists von 50 bis 100 Kandidaten bleibt das auf einer GPU im Millisekundenbereich und ist völlig unproblematisch – bei 500 oder 1.000 Kandidaten wird es zum dominierenden Kostenfaktor der gesamten Pipeline.

Die praktische Konsequenz: Der Cross-Encoder ist eine Verfeinerungsstufe, kein Suchverfahren. Er bewertet, was die Fusion ihm vorlegt. Eine sinnvolle Auslegung sieht so aus: Hybrid Search holt 100 Kandidaten, der Cross-Encoder rerankt sie, die besten 5 gehen an das Sprachmodell. Wer den Reranker auf 500 Kandidaten ansetzen will, braucht ein anderes Verfahren.

Late Interaction: ColBERT und ColPali

Late Interaction ist der Mittelweg zwischen beiden Extremen. Die Idee von ColBERT: Statt ein Dokument auf einen einzigen Vektor zu reduzieren, wird für jedes Token ein eigener Vektor gespeichert. Zur Query-Zeit vergleicht MaxSim jedes Query-Token gegen alle Dokument-Token, nimmt pro Query-Token das Maximum und summiert. Frage und Dokument interagieren also – aber erst spät, nach der Kodierung, und nur über ein Skalarprodukt statt über einen Transformer.

Das entscheidende Detail: Die Dokument-Token-Embeddings werden offline vorberechnet und bei jeder Anfrage wiederverwendet. Zur Query-Zeit bleiben eine Matrixmultiplikation und ein Max-Pooling. Damit gilt:

Praktisch heißt das: Kandidatenmengen, bei denen ein Cross-Encoder unwirtschaftlich wird, sind für Late Interaction weiterhin bezahlbar. Wenn Ihre Fusion 300 oder 500 plausible Kandidaten liefert und Sie diese wirklich alle bewerten wollen, ist ColBERT das passende Werkzeug.

Der Sprung ins Multimodale

Dieselbe Mechanik funktioniert für Bilddaten. ColPali überträgt Late Interaction auf Dokumentseiten als Bild – relevant überall dort, wo Layout, Tabellen und Diagramme die eigentliche Information tragen und OCR sie zerstört. In dieser Linie steht auch ColGraphRAG (arXiv:2607.16208, 2026), das Single-Vector-Ranking für graph-verknüpfte Bildknoten durch MaxSim-Multi-Vector-Scoring ersetzt, bei ansonsten unverändertem Graph-Aufbau und Text-Retrieval, evaluiert auf MultimodalQA. Einordnung mit Augenmaß: Das ist ein Einzelautor-Preprint, das Abstract berichtet verbesserte Punktschätzungen ohne konkrete Metrik-Deltas und nennt ausdrücklich gemischte Trends bei textdominierten Fragen. Als Richtungsindikator für multimodales Retrieval interessant, als Belegstelle für eine Architekturentscheidung zu dünn.

Was das an Speicher kostet

Late Interaction hat einen Preis, und der steht in der Vektordatenbank. Ein Vektor pro Chunk wird zu einem Vektor pro Token. Bei 512 Token pro Dokument sind das im Extremfall mehrere hundert Vektoren statt einem. Die Originalarbeit zu ColBERTv2 (arXiv:2112.01488) beziffert das konkret:

Variante	Byte pro Token-Vektor	Index für 9 Mio. Passagen
ColBERT (Original)	256 Byte	ca. 154 GB
ColBERTv2, 2-Bit-Residuen	ca. 36 Byte	ca. 25 GB
ColBERTv2, 1-Bit-Residuen	ca. 20 Byte	ca. 16 GB

Die Residual-Kompression von ColBERTv2 – jeder Vektor wird als Zentroid-ID plus 1- oder 2-Bit-Residuen gespeichert – bringt also eine 6- bis 10-fache Reduktion, bei einem MRR@10 von 39,7 auf MS-MARCO-Dev. Ohne diese Kompression ist Late Interaction für die meisten Mittelstandskorpora schlicht nicht sizing-fähig.

Für die eigene Planung heißt das: Rechnen Sie Storage und Arbeitsspeicher der Vektordatenbank vorab durch, nicht nachträglich. Ein Korpus von 200.000 Chunks à 300 Token ergibt bei 20 Byte pro Vektor rund 1,2 GB Index – handhabbar. Derselbe Korpus unkomprimiert liegt bei über 15 GB, und der Index will möglichst in den RAM. Der pragmatische Kompromiss für die meisten Häuser: Late Interaction ausschließlich auf der Rerank-Stufe einsetzen, die erste Suchstufe weiterhin über den klassischen Single-Vector-Index plus BM25 fahren. Dann werden Token-Vektoren nur für die Kandidaten benötigt, nicht für den gesamten Korpus.

Reranker laufen lokal

Ein häufiges Missverständnis: Reranking sei etwas, das man einkauft. Tatsächlich sind die relevanten Modelle klein – deutlich kleiner als jedes Sprachmodell, das man ohnehin schon betreibt. Das prominenteste Beispiel ist answerdotai/answerai-colbert-small-v1 mit 33 Millionen Parametern. Zum Vergleich: bge-base-en-v1.5 hat 109 Millionen, ist also 3,3-mal größer.

Die Größe schlägt nicht auf die Qualität durch:

• BEIR-Durchschnitt: 53,79 für answerai-colbert-small-v1 gegenüber 51,68 für bge-small-en und 50,02 für ColBERTv2.0.
• HotpotQA: 76,11 gegenüber 66,7 für ColBERTv2.0 – ein deutlicher Vorsprung bei mehrstufigen Fragen, die mehrere Belegstellen kombinieren müssen.
• TREC-COVID: 84,59 gegenüber 73,3 – Fachvokabular außerhalb des Trainingskorpus, also genau das Szenario technischer Unternehmensdokumentation.
• Indexierungs-Hinweis: Die empfohlene Dokumentlänge beim Indexieren liegt bei doc_maxlen=512. Wer längere Chunks indexiert, verliert Text am Ende stillschweigend.

Das Ökosystem, korrekt sortiert

Rund um ColBERT existieren drei Nutzungspfade, die im Model Card offiziell benannt sind – sie werden häufig verwechselt:

1. stanford-futuredata/ColBERT – die Referenzimplementierung aus Stanford inklusive PLAID-Engine für Indexierung und Abfrage. Der Weg für alle, die die Originalpipeline wollen.
2. RAGatouille von AnswerAI – ein Wrapper für Training und Inferenz, der die Einstiegshürde deutlich senkt. Dazu die Bibliothek rerankers, die verschiedene Reranker-Typen hinter einer einheitlichen Schnittstelle kapselt.
3. Eigenständig trainierte Modelle aus demselben Umfeld, darunter answerai-colbert-small-v1 und die japanische ColBERT-Linie JaColBERT (Benjamin Clavié / AnswerAI). Wichtig zur Klarstellung: Das sind keine Forks der ColBERTv2-Codebasis, sondern separat trainierte Modelle.

Der betriebliche Punkt dahinter ist wichtiger als jede Benchmark-Zahl: Ein Reranker sieht per Konstruktion die vollständigen Kandidatendokumente. Eine externe Rerank-API bekommt also nicht nur die Frage, sondern auch den Volltext der Passagen, die Ihr System für relevant hält – bei Vertrags-, Personal- oder Konstruktionsdaten ist das genau der Abfluss, den ein On-Premise-Setup verhindern soll. Bei 33 Millionen Parametern gibt es keinen Grund, dieses Risiko einzugehen.

Einbaureihenfolge für bestehende Systeme

Wer ein laufendes RAG-System verbessern will, sollte nicht alle drei Bausteine gleichzeitig einziehen – sonst weiß am Ende niemand, welcher gewirkt hat. Die bewährte Reihenfolge:

1. Eval-Set anlegen (vor allem anderen). 100 bis 200 reale Fragen aus dem Support-Postfach oder aus Nutzer-Logs, jeweils mit dem geprüften Zieldokument. Das ist ein bis zwei Tage Arbeit und die einzige Investition, die sich bei jedem folgenden Schritt erneut auszahlt.
2. Hybrid Search plus RRF. BM25-Index neben den bestehenden Vektorindex stellen, Ränge mit k = 60 fusionieren. Der kleinste Eingriff mit dem besten Aufwand-Nutzen-Verhältnis – in T2-RAGBench 0,644 bzw. 0,587 auf 0,695 bei Recall@5.
3. Reranking auf die Shortlist. Kandidatenzahl auf 50 bis 100 erhöhen, Cross-Encoder oder ColBERT-Reranker davorschalten, Top-5 an das Modell. Hier liegt in der Messung der größte Einzelsprung, insbesondere bei Recall@1.
4. Late Interaction ausbauen – falls nötig. Erst wenn die Shortlist erkennbar zu kurz ist, also die richtige Passage regelmäßig auf Rang 80 bis 300 liegt, lohnt der Umstieg auf ein Late-Interaction-Verfahren mit größerer Kandidatenmenge. Vorher nicht: Der Indexspeicher ist real.

Messen statt raten

Messen Sie nach jedem Schritt Recall@k und NDCG gegen dasselbe Eval-Set. Recall@k beantwortet die Frage „Ist die richtige Passage überhaupt drin?", NDCG bewertet zusätzlich, wie weit oben sie steht. Beides zusammen deckt die typischen Fehlerbilder ab.

Wovon dringend abzuraten ist: Stichproben durch Testnutzer als Entscheidungsgrundlage. Menschen bewerten flüssig formulierte Antworten systematisch besser, unabhängig davon, ob die zugrunde liegende Quelle stimmte. Genau dieser Effekt führt regelmäßig dazu, dass eine Retrieval-Verschlechterung als Verbesserung durchgewinkt wird.

Wenn Sie diese Kette einmal sauber aufgebaut haben, ist sie stabil: Ein neues Embedding-Modell, ein anderer Reranker oder ein Modellwechsel im Generator lassen sich anschließend in Stunden statt Wochen bewerten. Wie sich das in eine vollständige, autonom recherchierende Wissensbasis einfügt, zeigt unser Beitrag zu Agentic RAG im air-gapped Betrieb; die Hardware-Seite – insbesondere die Frage, wie viel VRAM lange Kontexte kosten – behandeln wir separat.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. arXiv 2604.01733v1
2. softwaredoug.com elasticsearch hybrid search strategies
3. arXiv 2112.01488
4. Hugging Face answerai colbert small v1
5. arXiv 2607.16208
6. arXiv 2504.20083
7. digitalapplied.com hybrid search bm25 vector reranking reference 2026
8. supermemory.ai hybrid search guide
9. arXiv 2210.11610

Häufig gestellte Fragen zu Reranking und Hybrid Search

Was bringt am meisten, wenn ich nur eine Sache ändern kann?

Hybrid Search mit Reciprocal Rank Fusion. Der Sprung von reiner Vektorsuche auf die Kombination aus BM25 und Dense-Suche ist in Benchmarks der größte Einzelgewinn – vor jedem Modellwechsel.

Cross-Encoder oder ColBERT?

Cross-Encoder für kleine Kandidatenmengen und maximale Präzision, ColBERT wenn Sie viele Kandidaten reranken wollen. Late Interaction ist zwar ebenfalls linear in der Kandidatenzahl, hat aber eine erheblich kleinere Konstante pro Kandidat, kostet dafür deutlich mehr Indexspeicher.

Kann ich Reranking auf eigener Hardware betreiben?

Ja, und das ist der Regelfall. Reranker liegen typischerweise bei 30 Millionen bis einer Milliarde Parametern und laufen auf moderater GPU-Ausstattung – ohne dass Ihre Dokumente eine externe API sehen.

Wie messe ich, ob es besser geworden ist?

Mit einem festen Eval-Set aus realen Fragen und geprüften Zieldokumenten. Messen Sie Recall@k und NDCG vor und nach jeder Änderung; subjektive Stichproben führen regelmäßig zu Fehlentscheidungen.