Neubewertung in RAG: Das enge Fenster, in dem Cross-Encoder tatsächlich helfen

Ein Cross-Encoder unterstützt einen RAG-Pipeline nur innerhalb eines engen Bereichs: Die Rückrufrate in der ersten Stufe muss hoch genug sein, und die Anzahl der übergebenen Kandidaten muss ausreichend gering bleiben. Außerhalb dieses Bereichs hat der Reranker entweder nichts zu korrigieren oder beginnt Schaden zu verursachen. Im Folgenden wird das Mechanismus, ein Fehlermodus namens Phantom Hits sowie eine Methode zur Messung all dessen anhand eigener Daten erläutert.

Stellen Sie sich ein RAG-System vor, das die richtige Antwort gefunden hat. Es gab keinen Fehler und kein verlorenes Dokument. Die Antwort befindet sich einfach an Position 37 in der Ergebnisliste, während das LLM nur die ersten fünf betrachtet, sodass sie aus praktischen Gründen nicht existiert. Es wird keine Warnung ausgelöst, da nach allen Überwachungskriterien die Anfrage erfolgreich war.

Das ist kein Problem einer bestimmten Implementierung. Es ergibt sich aus der Art und Weise, wie die Architektur aufgebaut ist. Die Vektorsuche ist so konzipiert, dass die richtige Antwort irgendwo unter den ersten 50 bis 200 Ergebnissen erscheint – nicht unbedingt ganz oben –, wodurch die Qualität der Antwort bei einem Prozess, der bei der Auswertung endet, dem Zufall überlassen wird.

Die übliche Reaktion besteht darin, einen Neurangier zu hinzufügen. Das bedeutet einen Cross-Encoder, etwa zwölf Zeilen Code, eine leichte Verbesserung des nDCG-Werts, und die Angelegenheit ist erledigt. Diese Reaktion ist nicht falsch, weil das Neurangieren versagt – sie ist falsch, weil das Neurangieren nur innerhalb eines engen Betriebsfensters funktioniert, das kaum jemand misst. Im Folgenden sehen Sie, wie diese teurere zweite Stufe funktioniert, wo sich jeder Rand dieses Fensters befindet, und wie man an einem Nachmittag herausfinden kann, auf welcher Seite jedes Randes das eigene System liegt.

Neurangieren ist keine bessere Vektorsuche

Ein Reranker ist eine andere Architektur, die erst nach der Suche aktiviert wird und auf eine kleine Gruppe von Kandidaten angewendet wird.

Der Bi-Encoder hinter Ihrer bestehenden Vektorsuche kodiert die Abfrage sowie jedes Dokument unabhängig voneinander, im Voraus und offline. Dadurch ist die Verarbeitung schnell und es lässt sich auf Millionen von Dokumenten skalieren. Der Nachteil ist, dass er die Abfrage und das Dokument niemals gemeinsam betrachtet.

Der Cross-Encoder macht das Gegenteil. Er liest beide gleichzeitig, Token für Token, wodurch er Negationen, numerische Widersprüche sowie Feinheiten erkennen kann, die ein Bi-Encoder nicht sieht. Dafür muss er diese Arbeit bei jeder Abfrage einzeln für jeden Kandidaten wiederholen.

Das ergibt das bekannte zweistufige Verfahren. Die Suche reduziert kostengünstig das Feld auf 50 bis 200 Kandidaten und zielt auf die Vollständigkeit ab: Das richtige Antwort muss nicht übersehen werden. Die erneute Sortierung ordnet anschließend diese kleine Auswahl mit höherem Aufwand und zielt auf die Genauigkeit ab: Von den verbleibenden Kandidaten wird der wirklich beste ausgewählt.

Auch die zweite Ebene ist keine kostenlose Erweiterung. Ab einer bestimmten Anzahl an Kandidaten beginnt der Cross-Encoder Störungen als Signal zu werten, wodurch die Qualität tatsächlich abnimmt. Ob eine erneute Sortierung hinzugefügt werden soll, ist eine ingenieurtechnische Berechnung anhand Ihrer Daten – keine spontane Entscheidung.

Warum die Suche nicht der letzte Schritt sein kann

Ein Symptom, das bei der Nutzung von RAG in der Produktion ständig auftritt, lautet: „Das Modell erzeugt Halluzinationen, obwohl die Informationen in unserer Datenbank vorhanden sind.“ In den meisten Fällen stellt sich heraus, dass das Modell nichts eigenständig erfunden hat. Das richtige Dokument befand sich zwar unter den fünfzig besten Ergebnissen, aber nicht unter den fünf besten, die dem Generator angezeigt wurden.

Die Ursache liegt in der Architektur. Der Bi-Encoder berechnet zum Zeitpunkt der Indizierung, noch bevor eine Frage gestellt wird, eine Embedding-Vertretung des Dokuments. Beim Suchen vergleicht er anschließend zwei komprimierte Zusammenfassungen statt des eigentlichen Textes der Anfrage mit dem eigentlichen Text des Dokuments.

Ein klassisches Beispiel dafür, was verloren geht: Die Abfrage lautet „günstig“ und das Dokument besagt „500 Dollar pro Nacht“. Für die Vektoren beziehen sich beide auf den Preis eines Hotelzimmers, weshalb sie in der Nähe voneinander landen. Der Widerspruch wird erst sichtbar, wenn jemand die beiden nebeneinander liest – ein Bi-Encoder tut dies aus Designgründen niemals.

Ein besseres Embedding-Modell wird dieses Problem nicht lösen, denn es handelt sich dabei um einen bewussten Kompromiss. Die Dokumentensuche maximiert die Trefferquote, also die Wahrscheinlichkeit, dass das richtige Dokument in der zurückgegebenen Liste zu finden ist, und zwar kostengünstig bei Millionen von Dokumenten. Das richtige Dokument ganz nach oben zu bringen, gehört einfach nicht zu ihren Aufgaben.

Recall@50 und Precision@5 messen unterschiedliche Aspekte und beantworten unterschiedliche Fragen. Wenn man sie verwechselt, enden Teams damit, für eine zusätzliche Schicht zu zahlen, um etwas zu lösen, was diese Schicht gar nicht bewältigen kann.

Die Schwäche besteht darin, dass der bi-Encoder das Paar niemals gemeinsam betrachtet, also schauen wir uns an, welchen Vorteil ein Modell hat, das das Paar tatsächlich berücksichtigt.

Der bi-Encoder katalogisiert, der cross-Encoder liest

Stellen Sie sich die Einstellung neuer Mitarbeiter vor. Der bi-Encoder spielt den Personalvermittler, der tausend Lebensläufe bereits vor der Existenz einer Stellenausschreibung in Ordnern sortiert: schnell, oberflächlich und früh abgeschlossen. Der cross-Encoder hingegen verkörpert den Personalmanager mit zehn Finalisten, der jeden Lebenslauf zusammen mit der Stellenausschreibung Zeile für Zeile liest. Erst dann treten die Unstimmigkeiten zutage, die der Personalvermittler nicht erkennen konnte.

Mechanisch gesehen ist der Unterschied offensichtlich. Ein cross-Encoder verbindet Abfrage und Dokument zu einer einzigen Sequenz im kanonischen Format [CLS] Abfrage [SEP] Dokument [SEP] und leitet sie durch einen einzigen Transformer.

Darinnen übernimmt die Kreuzaufmerksamkeit die Arbeit: Jedes Abfraged Token kann direkt auf jedes Dokumenttoken und umgekehrt achten. Das Ergebnis ist kein Vektor zum Vergleichen, sondern ein einzelner Logit-Wert, eine rohe, unnormalisierte Zahl, die angibt, wie zuversichtlich das Modell ist, dass dieses spezielle Paar relevant ist.

Der bi-Encoder liefert also eine Repräsentation, während der Kreuzencoder ein Urteil abgibt. Das ist ein Unterschied darin, was das Modell überhaupt wahrnehmen kann, nicht ein Unterschied in Grad.

Daraus folgt sofort eine Konsequenz: Ein Kreuzencoder-Score kann nicht im Voraus berechnet und indiziert werden, da er von dem spezifischen Abfrage- und Dokumentpaar abhängt und nicht nur vom Dokument selbst. Jede Abfrage erfordert einen vollständigen Vorwärtslauf für jeden Kandidaten, was pro Paar zehn bis hundert Mal teurer ist als ein Vektorvergleich.

Die Darstellung, die das zweistufige Design begründet, macht das Maßstabverhältnis klar. Laut dem 2019 veröffentlichten Paper „Sentence-BERT“ von Reimers und Gurevych erfordert das Finden des am ähnlichstenen Paares unter 10.000 Sätzen etwa 50 Millionen Vergleiche, was bei einem vollständigen BERT-Modell rund 65 Stunden und bei einer SBERT-ähnlichen Architektur etwa 5 Sekunden entspricht.

Merken Sie sich diese genaue Angabe, denn es kursieren runde Varianten wie „10 Millionen Dokumente und 50 Stunden“. Der Unterschied ist qualitativ: Das Engpassproblem liegt darin, wie viele Paare bewertet werden müssen, nicht darin, wie groß das Korpus ist.

Deshalb dient ein Cross-Encoder niemals als erste Stufe. Er ist nicht schlechter, lediglich zu aufwendig zum Verarbeiten eines gesamten Korpus. Da seine Kosten pro Paar hoch sind, hängt alles davon ab, wie viele Paare er bearbeiten muss und an welcher Stelle in der Pipeline er eingesetzt wird.

Zwei Stufen, zwei Budgets

Ein Reranker kommt nach der Suche und vor dem LLM. Die Suche liefert die top-k Kandidaten, wobei k die Anzahl der Dokumente ist, die eine Stufe an die nächste weiterleitet – in der Regel zwischen 50 und 200. Der Reranker mischt anschließend diese Liste um und leitet die Ergebnisse an den Generator an einer Position zwischen 3 und 20 weiter.

Diese Kaskadenstruktur entstand nicht mit den LLMs, was auf deren Reife hindeutet. Das Prinzip „billiger Filter, teurer Entscheider“ stammt aus der Learning-to-Rank-Ära, als die zweite Stufe aus einem Ensemble von Entscheidungsbäumen auf Basis handgegenerierter Merkmale bestand und kein Transformer verwendet wurde. Der Motor hat sich geändert, die Architektur nicht.

Neurales Neuranking hat ein bestimmtes Entstehungsdatum. Im Jahr 2019 legte der Artikel „Passage Re-ranking with BERT“ fest, dass BERT als binärer Klassifikator für Abfragen und Passagenpaare eingesetzt werden kann, und verbesserte den MRR@10 um 27 Prozent im Vergleich zum besten damals verfügbaren Ergebnis. Damals hörte die zweite Phase auf, eine Optimierung zu sein, und wurde zu einer eigenständigen Schicht.

Die bekannteste kommerzielle Implementierung heute ist Coheres Flaggschiff-Neuranker. Über die verschiedenen Versionen hinweg änderte sich am meisten eine Einstellung: Das Eingabefenster wuchs von einigen hundert Token auf über 32.000 an, wobei bei den Versionen v3 und v3.5 eine Obergrenze von 4.096 Token gilt. Dies stellt einen echten Designwandel dar, da dadurch die Größe der ohne Trunkierung bewertbaren Abschnitte erhöht wird, wodurch das Aufteilen in Abschnitte weniger aggressiv erfolgen kann und weniger Kontext verloren geht.

Die Anbieter sprechen weniger darüber, was als Nächstes kommt. Die für dasselbe Modell angegebenen Preise variieren bei externen Quellen um das Zehnfache oder mehr – von einem Bruchteil eines Cent bis zu zweieinhalb Dollar pro tausend Suchanfragen, je nachdem, wer die Zählung vornimmt und was er unter einer „Suche“ versteht.

Es gilt eine einfache Regel: Wenn Sie die Berechnungen des Anbieters mit Ihrem eigenen Traffic nicht nachvollziehen können, handelt es sich nicht um eine Berechnung, sondern um eine Schätzung. Es gibt außerdem eine Abrechnungsfalle: Dokumente, die die Grenze überschreiten, werden in Teile aufgeteilt, wobei jeder Teil separat abgerechnet wird – sodass eine logische Neubewertung in mehrere abgerechnete Vorgänge umschlagen kann.

Die Formel, die man sich merken sollte, lautet: Günstig in großem Umfang abrufen, teuer eine Neubewertung in einem begrenzten Pool durchführen und dem LLM nur das zeigen, was beide Schritte übersteht. Das klingt nach einer sicheren Standardlösung, doch es gibt einen Schwellenwert, jenseits dessen sie nicht mehr funktioniert – und zwar in eine Richtung, die kaum jemand erwartet.

Phantom-Hits und der Punkt, an dem die Neubewertung schadet

Die gängige Ansicht besagt, je mehr Kandidaten man dem Neubewertungsalgorithmus zur Verfügung stellt, desto sicherer ist man. Das Modell sei genauer als die Vektorabfrage, sodass bei 500 oder 1.000 Kandidaten es sicherlich nicht fehlschlagen könne. Diese Intuition ist falsch, und es gibt dokumentierte Belege dagegen.

Der 2024 veröffentlichte Artikel „Drowning in Documents“ (Jacob und Kollegen) berichtete, dass mit zunehmendem Wert von K die Qualität des Neurankers ansteigt, einen Höhepunkt erreicht und anschließend deutlich abnimmt. Bei blinden Scans der gesamten Sammlung konnte der einfache BM25-Algorithmus einen als bestmöglich geltenden Cross-Encoder übertreffen. Es gibt jedoch eine Einschränkung zu beachten: Dieses Ergebnis stammt von blinden Scans an akademischen und Unternehmensdatensätzen und sagt wenig über einen typischen Workflow aus, bei dem K höchstens einige hundert beträgt.

Dieses Problem hat einen Namen – Phantom Hits. Der Neuranker weist zuverlässig seinerseits die höchste Bewertung einem Dokument zu, das weder lexikalisch noch semantisch mit der Abfrage in Verbindung steht.

Die Autoren schlagen eine mögliche Ursache vor und betonen ausdrücklich, dass es sich dabei um eine Hypothese und nicht um eine bestätigte Ursache handelt. Sie weisen auf die Trainingsmethode hin, die sie als Expositionsverzerrung bezeichnen. Die Reranker werden kontrastiv an schwierigen Negativen trainiert – Dokumenten, die äußerlich wie die richtige Antwort aussehen, aber inhaltlich falsch sind – wodurch das Modell zu einem Experten für mikroskopische Unterschiede wird.

In der Praxis führt dieses Wissen jedoch zu negativen Folgen. Wenn dem Modell ein einfaches Negativ vorgelegt wird – reiner Lärm, den es während des Trainings kaum kennengelernt hat – hat es keinen Bezugspunkt mehr und beginnt zu raten. Ein Modell, das darauf trainiert wurde, Zwillinge voneinander zu unterscheiden, ist hilflos, wenn ein Fremder hereinkommt.

Die gegenüberliegende Grenze ist genauso real und heilt die erste nicht auf. Einige unabhängige Analysen legen den unteren Break-Even-Punkt für das Neuranking bei recall@50 = 0,85 fest. Unter dieser Zahl gibt es nichts, das es wert ist, sortiert zu werden, denn das richtige Dokument hat nie in die Auswahlmöglichkeiten eingereicht. Genaue Schwellenwerte unterscheiden sich je nach Quelle, da die Korpora unterschiedlich sind, und ihre Herkunft spielt eine Rolle: Blogs und praktische Erfahrungen statt Peer-Review. Nutzen Sie sie als Hypothese, um sie an Ihren eigenen Daten zu testen, und niemals als etablierte Tatsache.

Die beiden Erkenntnisse stehen nicht im Widerspruch zueinander. Sie bilden die beiden Grenzen eines Betriebsfensters. Unterhalb der Recall-Schwellenwert hat das Neuranking nichts, womit es arbeiten kann. Überhalb der K-Schwellenwert beginnt es Schäden zu verursachen. Das Neuranking ist keine monoton steigende Verbesserung, und davon auszugehen, dass mehr immer sicherer ist, wiederholt den Fehler, blind einem Hersteller-Referenzwert zu vertrauen, denn beide ersetzen Messungen durch Aberglauben.

Da zu viele Neuanordnungen schaden können und zu wenige möglicherweise nicht ausreichen, benötigen wir eine klare Vorstellung davon, was diese Ebene eigentlich beheben kann.

Die Obergrenze der Wiedererkennung – und was die 67 Prozent wirklich bedeuten

Ein Neuanordner ist ein Redakteur, kein Reporter. Er kann Material, das bereits gesammelt wurde, umordnen, aber er kann nicht das hervorbringen, was niemand eingereicht hat.

Dieses Prinzip, die Obergrenze der Wiedererkennung, klingt banal – bis es auf die auffälligsten Statistiken der Branche stößt. Anthropic beschrieb in seinem Artikel zur kontextuellen Suche einen Prozess aus dem Jahr 2024, bei dem die Fehlerrate bei den besten 20 Ergebnissen von 5,7 auf 1,9 Prozent sank, was einer Reduzierung von 67 Prozent entspricht.

Diese Zahl wird oft als Beleg für Neuanordnungen herangezogen. Wenn man sie nach den einzelnen Phasen aufteilt, erzählt sie eine andere Geschichte – allerdings nicht, weil sie falsch wäre.

Der Ablauf verlief wie folgt: Kontextuelle Embeddings senkten den Wert auf 3,7 Prozent, die Hinzufügung von BM25 brachte ihn auf 2,9 Prozent, und erst danach erreichte das Reranking einen Wert von 1,9 Prozent. Das Reranking allein deckt somit den letzten Abschnitt ab, von 2,9 auf 1,9 Prozent. Beide Werte sind gültig, da sie unterschiedliche Bereiche messen: Die 67 Prozent sind das Ergebnis der gesamten Kombination und nicht eines einzelnen Schritts.

Diese Unterscheidung hat tatsächlich große praktische Bedeutung. Bevor Sie bei einer Architekturbesprechung von „67 Prozent“ sprechen, sollten Sie wissen, dass Sie damit die Wirkung von vier Änderungen zusammen versprechen – wobei drei dieser Änderungen früher in der Kette stattfinden als das Reranking und den größten Teil des Vorteils liefern.

Die Autoren weisen selbst auf die Einschränkung hin: Die Angaben beziehen sich auf Durchschnitte aus verschiedenen Bereichen, wobei die Schwankungen zwischen ihnen groß sind. Ein weiterer Hinweis aus den verfügbaren Erkenntnissen: Jede Qualitätswertangabe für kommerzielle Neubewertungstools wird von den Anbietern auf ihren eigenen Datensätzen und mit ihrer eigenen ersten Suchmethode bereitgestellt. Es gibt keine unabhängige, marktweite Bewertung.

Kein externer Vergleichswert kann Ihnen verraten, wie sich die Neubewertung in Ihrem System verhält, daher müssen Sie es selbst testen.

Eine Berechnung, die Sie am Montagmorgen durchführen können

Die gesamte Komplexität dieses Themas lässt sich auf ein wiederholbares Verfahren reduzieren. Gerade weil Teams dieses Verfahren nur selten anwenden, bleibt die Frage „Hilft die Neubewertung?“ weiterhin bestehen.

Schritt eins: Messen Sie Recall@50 und Precision@5 an etwa hundert beschrifteten Produktionsabfragen. Verwenden Sie Ihre eigenen Protokolle sowie Ihre eigene Mischung aus Begriffen und Intenten – nicht einen öffentlichen Benchmark. Wenn Recall@50 deutlich unter 0,85 liegt, beheben Sie zunächst das Problem bei der Datenerfassung, beispielsweise durch Chunking, hybride Suche oder Embeddings, anstatt eine weitere Schicht daraufzusetzen.

Schritt zwei: Suchen Sie nach dem charakteristischen Muster. Ein hoher Recall@50 in Kombination mit niedriger Precision@5 ist genau das Profil, für das Reranking-Methoden bestimmt sind. Das richtige Dokument befindet sich zwar im Pool, steht aber zu weit unten.

Schritt drei: Wählen Sie das Modell bewusst aus. Eine gehostete API bedeutet eine schnelle Inbetriebnahme und keine Betriebskosten, doch Ihre Daten verlassen Ihre Infrastruktur. Ein selbst gehosteter Reranker bietet Kontrolle über Kosten und Privatsphäre, erfordert jedoch die Bereitstellung von GPUs und Wartungsaufwand. Es handelt sich dabei eher um eine Entscheidung hinsichtlich Compliance und Budget als um eine Frage der Modellqualität.

Ausprobieren ist ebenfalls günstig. Die lokale Neubewertung passt in etwa ein Dutzend Zeilen:

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-large", max_length=512)

def rerank(query, docs):
    pairs = [(query, d.page_content) for d in docs]   # pair: query + candidate
    scores = reranker.predict(pairs)                  # one logit per pair
    return sorted(zip(docs, scores), key=lambda x: x[1], reverse=True)

Drei Fehler treten am häufigsten auf. Einer besteht darin, K „nur zur Sicherheit“ aufzublähen. Ein anderer ist das Neuranking nach Trunkierung des Kontexts, wodurch das Modell einen Präfix statt des gesamten Dokuments bewertet. Der dritte Fehler besteht darin, die Scores des Cross-Encoders als absolute Schwellenwerte zu betrachten, die zwischen verschiedenen Abfragen verglichen werden – was besonders problematisch ist, da es in einer Demo funktioniert, in der Produktion jedoch versagt.

Es gibt auch einen weniger offensichtlichen Fehler: Der Satz „der Neuranker hilft nicht“ kann manchmal auf einen numerischen Fehler zurückzuführen sein und nicht auf eine architektonische Entscheidung. In einem im Migration Guide für Sentence-Transformers dokumentierten Fall führte eine in bfloat16 berechnete Sigmoid-Funktion zur Sättigung, wodurch die höchsten Scores zusammenrückten und ihre Reihenfolge faktisch zufällig wurde. Sobald float32 vor der Aktivierung verwendet wurde, kehrte die Rangfolge von nahezu zufällig zu normal zurück.

Alles hier erfordert lediglich Messungen, keine Änderungen an der Architektur.

Was das für den Architekten bedeutet

Zurück zu Position 37. Das dort steckengebliebene Dokument war niemals ein Problem des Erstellungsmodells – es handelte sich um ein Problem der Sortierung.

• Ein Cross-Encoder ist keine bessere Embedding-Methode. Es handelt sich um eine separate Architektur, die nach der Suche aktiviert wird, die Abfrage und das Dokument gemeinsam verarbeitet und anstelle einer Repräsentation ein Urteil zurückgibt. Eine Verbesserung der Embedding-Qualität bringt nicht das, was das Seite-an-Seite-Vergleichen der Paare bewirkt.
• Reranking gehört an einen bestimmten Platz. Die Suche bleibt kostengünstig und umfassend, Reranking hingegen teuer und eingeschränkt – genau diese Kostengestruktur dieser Kaskade ist die ganze Idee.
• Mehr Kandidaten sind keine sichere Standardlösung. Ab einem bestimmten Wert K sinkt die Qualität tatsächlich, und die Erklärung liegt darin, wie diese Modelle trainiert werden.
• Die Obergrenze ist festgelegt. Was in der ersten Phase nicht zurückgegeben werden konnte, kann auch durch ein Neuranking nicht wiederhergestellt werden – egal, was die Angebote der Anbieter behaupten.
• Ihre Daten bilden den Maßstab. Ein Nachmittag, der damit verbracht wird, Recall@50 und Precision@5 für hundert beschriftete Abfragen zu berechnen, beendet eine Debatte, die sonst wochenlang andauern könnte.

Viele Teams betrachten Neuranking als selbstverständliches Element, das wie ein Cache zu jedem RAG-System hinzugefügt wird. Das ist eine falsche Gewohnheit. Das richtige Bild zeigt sich, wenn man beide Schwellenwerte zusammen betrachtet: ein Untergrenzwert, unterhalb dessen die Schicht nichts zu reparieren hat, und eine Obergrenze, oberhalb der sie die Ergebnisse zu stark beeinträchtigt. Kurz gesagt: Neuranking ist bedingt – niemals automatisch.

Eine Lücke bleibt bestehen. In den hier untersuchten Materialien wurden keine speziellen Benchmarks für Polnisch im Rahmen von Reranking-Verfahren aufgeführt, und jede multilinguale Zahl stellt eine Aggregation aus Dutzenden von Sprachen dar. Für ein polnischsprachiges Korpus oder jede kleinere Sprache ist es nicht nur ratsam, mit eigenen Daten zu messen – es ist die einzige Möglichkeit.