Reranking: Wie ein zweiter Blick RAG-Antworten präziser macht

Ihr RAG-System findet die richtige Antwort. Es zeigt sie nur an der falschen Stelle. Der Retriever zieht fünfzig Textausschnitte aus der Wissensdatenbank, das Sprachmodell liest davon die obersten fünf – und der entscheidende Absatz steht auf Platz 23. Genau hier setzt Reranking an: eine zweite Stufe, die die Trefferliste sortiert, bevor das Modell sie zu Gesicht bekommt. Der Aufwand ist überschaubar, der Effekt oft größer als jeder weitere Feinschliff am Prompt.

Warum die erste Trefferliste selten die beste ist

Vektorsuche ist auf Geschwindigkeit getrimmt. Sie vergleicht die Anfrage mit Millionen von Textausschnitten in Millisekunden, weil sie beides vorab in Zahlenreihen übersetzt und nur noch deren Abstand misst. Dieser Trick macht sie schnell. Er macht sie auch ungenau, denn die Bedeutung eines Absatzes wird in einen einzigen Vektor gepresst, lange bevor überhaupt eine Frage gestellt wurde.

Die Folge kennt jeder, der ein Retrieval-System im Betrieb beobachtet hat. Die richtige Passage taucht meistens irgendwo in den Top 50 auf – aber eben nicht ganz oben. Oberflächlich ähnliche Ausschnitte drängeln sich davor: der Text nennt zwar dieselben Begriffe, beantwortet aber eine andere Frage. Das Sprachmodell liest nur die vordersten Treffer, und wenn dort Rauschen steht, rät es oder erfindet. Recall war da, Präzision fehlte.

Bi-Encoder gegen Cross-Encoder

Der Unterschied liegt im Zeitpunkt des Vergleichs. Die Vektorsuche arbeitet mit einem Bi-Encoder: Frage und Dokument werden getrennt kodiert, jedes für sich, und erst am Ende trifft man sich im Vektorraum. Das ist effizient, weil sich alle Dokumente einmalig vorberechnen lassen. Es ist aber auch blind für den Zusammenhang, denn beim Kodieren des Dokuments war die Frage noch gar nicht bekannt.

Ein Cross-Encoder dreht das um. Er bekommt Frage und Kandidat gemeinsam vorgelegt und liest beide in einem Durchgang. So kann er erkennen, dass ein Absatz das Stichwort zwar enthält, den Sachverhalt aber verneint – oder dass eine Passage ohne das exakte Wort trotzdem genau die gesuchte Auskunft gibt. Diese Genauigkeit kostet Rechenzeit, weshalb man einen Cross-Encoder niemals auf die gesamte Datenbank loslässt. Man setzt ihn dorthin, wo er zählt: auf die Vorauswahl des schnellen Retrievers.

Daraus ergibt sich das Muster, das sich in der Praxis durchgesetzt hat. Erst holt ein günstiger Retriever – Vektorsuche, Stichwortsuche oder beides kombiniert – großzügig fünfzig bis hundert Kandidaten. Dann bewertet der Cross-Encoder jeden davon einzeln gegen die Frage und ordnet die Liste neu. Das Sprachmodell sieht am Ende nur die drei bis fünf besten. Recall besorgt die erste Stufe, die Präzision liefert die zweite.

Was Reranking konkret bringt

Der sichtbarste Gewinn ist weniger Halluzination. Ein Modell, das saubere, wirklich einschlägige Ausschnitte vorgesetzt bekommt, muss nichts überbrücken. Es zitiert, statt zu spekulieren. In einer Kundensupport-Anwendung heißt das: Die Antwort verweist auf den richtigen Handbuchabschnitt, nicht auf ein zufällig ähnlich klingendes Kapitel drei Produkte weiter.

Der zweite Gewinn ist ein kürzerer Kontext. Wer darauf vertrauen kann, dass die Top 3 tatsächlich die relevantesten Ausschnitte sind, muss nicht zwanzig Passagen ins Prompt stopfen, in der Hoffnung, dass die richtige dabei ist. Das spart Token, senkt die Antwortzeit und hält das Modell fokussiert. Gerade bei selbst gehosteten Systemen mit begrenztem GPU-Speicher ist ein schlankes Prompt bares Geld.

Ein dritter, oft übersehener Punkt: Reranking macht die Suche robuster gegen schlecht formulierte Fragen. Sachbearbeiter tippen keine sauberen Suchanfragen, sie tippen halbe Sätze und Abkürzungen. Der erste Retriever wirft dann eine wackelige Liste aus. Der Cross-Encoder, der Frage und Antwort im Zusammenhang liest, fischt daraus überraschend zuverlässig die passenden Treffer nach oben.

Offene Modelle, die Sie selbst betreiben können

Man muss dafür keinen kommerziellen Dienst anzapfen. Die Reranker-Familie von BAAI, die BGE-Modelle, läuft lokal, deckt viele Sprachen ab und ist klein genug für bescheidene Hardware. Für deutschsprachige Bestände lohnt der Blick auf mehrsprachige Varianten, die Deutsch sauber verarbeiten – ein Detail, an dem englischlastige Modelle gern scheitern.

Wer noch näher an die Datenhoheit will, betreibt den gesamten Zweistufenprozess hinter der eigenen Firewall. Late-Interaction-Ansätze wie ColBERT gehen einen Mittelweg: Sie bewahren mehr Information pro Dokument als ein einzelner Vektor, bleiben aber schneller als ein voller Cross-Encoder. Für latenzkritische Anwendungen gibt es außerdem schlanke Bibliotheken, die ohne GPU auf der CPU rerankieren – langsamer, aber ohne zusätzliche Grafikkarte im Rack.

Der praktische Reiz dieser offenen Modelle: Sie passen in die Architektur, die viele Unternehmen ohnehin aufbauen. Wer seine Sprachmodelle bereits selbst hostet, um Daten im Haus zu halten, schiebt den Reranker einfach als weiteren Container daneben. Kein neuer Vertrag, kein Datenabfluss zu einem externen Anbieter, keine zusätzliche Rechtsprüfung.

Der Preis: Latenz und Rechenlast

Reranking ist nicht umsonst. Jeder Kandidat, den der Cross-Encoder bewertet, ist ein eigener Modelldurchlauf. Hundert Kandidaten bedeuten hundert Durchläufe, und die summieren sich zu spürbaren Millisekunden. Wer die erste Stufe zu großzügig einstellt, verschenkt genau die Geschwindigkeit, für die er die Vektorsuche gewählt hat.

Die Stellschraube heißt Kandidatenzahl. Fünfzig Treffer aus der Vorstufe reichen für die meisten Wissensdatenbanken; darüber hinaus wächst vor allem die Rechenzeit, selten die Trefferqualität. Ein Reranker auf der GPU verarbeitet solche Mengen im zweistelligen Millisekundenbereich, auf der CPU dauert es länger. Batching hilft: Bündelt man die Kandidaten eines Requests, arbeitet die Grafikkarte sie in einem Rutsch ab, statt einzeln anzulaufen.

So führen Sie Reranking sauber ein

Fangen Sie mit einer Messung an, nicht mit einem Modell. Legen Sie zwei Dutzend echte Fragen aus dem Betrieb an, notieren Sie zu jeder die tatsächlich richtige Quelle und schauen Sie nach, auf welchem Platz Ihr aktueller Retriever sie ausgibt. Diese Liste ist Ihr Ausgangswert. Ohne sie merken Sie nie, ob der Reranker wirklich hilft oder nur teurer ist.

Dann schalten Sie einen offenen Reranker zwischen Retrieval und Sprachmodell und messen dieselben Fragen erneut. Steigen die richtigen Quellen in die Top 3? Bleibt die Antwortzeit im vertretbaren Rahmen? Erst wenn beides stimmt, drehen Sie an den Details – Kandidatenzahl, Modellgröße, GPU oder CPU. Behandeln Sie den Reranker als eigene Komponente mit eigenen Kennzahlen, nicht als Anhängsel der Suche.

Wichtig bleibt die Erwartung. Reranking repariert keine leere Wissensdatenbank und keinen Retriever, der die richtige Passage gar nicht erst findet. Es holt heraus, was schon da ist. Sitzt die richtige Antwort nicht unter den fünfzig Kandidaten, kann auch der beste Cross-Encoder sie nicht nach oben sortieren. Erst die Grundlage, dann der zweite Blick.

Ein kleiner Baustein mit großer Wirkung

Von allen Hebeln, an denen sich ein RAG-System verbessern lässt, ist Reranking einer der dankbarsten. Es verlangt kein neues Datenmodell, kein aufwändiges Fine-Tuning, keine zusätzliche Cloud-Anbindung. Ein offenes Modell, ein Container, eine saubere Messung – und die Antworten werden merklich verlässlicher. Für Unternehmen, die ihre KI im eigenen Haus betreiben, ist das genau die Art von Verbesserung, die sich rechnet: klein im Aufwand, groß in der Wirkung.

Sie möchten Ihr eigenes Retrieval-System schärfen oder von Grund auf verlässlich aufbauen – im eigenen Haus, mit Ihren Daten unter Ihrer Kontrolle? Bei AI-Designers entwickeln wir selbst gehostete KI-Lösungen, die Präzision und Datenhoheit zusammenbringen. Sprechen Sie uns an, wir schauen uns Ihren Anwendungsfall konkret an.

Bilder: AI-Designed