rag reranking cross-encoder retrieval embeddings

Suchen und Beurteilen für RAG: Warum die Recherche eine separate Reranking-Phase benötigt.

RAG benötigt Such- und Bewertungsfunktionen: Embeddings finden Kandidaten, können aber die Relevanz nicht beurteilen. Ein zweistufiges Design mit RRF, Cross-Encodern, ColBERT und LLM-Rerankern.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202611 Min. Lesezeit2552 Wörter

Quellen: RAG Is More Than Retrieval — It’s Search & Judge

Viele Teams stoßen bei der retrieval-augmented Generation an dieselben Grenzen. An einer Tafel sieht das System ordentlich aus: Die Abfrage wird eingebettet, Vektoren werden abgeglichen, die besten Ergebnisse werden an das Modell weitergeleitet, und es erhält eine Antwort. In der Produktion tauchen jedoch schnell Probleme auf. Relevante Dokumente werden übersehen, irrelevante Teile dringen ein, eine leicht umformulierte Frage ändert die Antwort, und Halluzinationen bleiben bestehen, selbst wenn die Suche scheinbar funktioniert hat.

Die übliche Reaktion besteht darin, ein besseres Embedding-Modell einzusetzen, die Dimension der Vektoren zu erhöhen oder sich mit Parametern wie top-k und Chunk-Größe zu beschäftigen. Solche Maßnahmen sind sinnvoll, doch sie beheben den falschen Problembereich. Das tiefere Problem ist architektonischer Natur. Ein herkömmlicher Ablauf lässt ein und denselben Mechanismus, die Ähnlichkeitsberechnung durch Embeddings, zwei völlig unterschiedliche Aufgaben erledigen: Kandidaten finden und entscheiden, welche Kandidaten wichtig sind.

Die Lösung besteht darin, die Aufgaben aufzuteilen. Man nutzt eine zweistufige Vorgehensweise: Die Erstellung von Kandidaten und die Bewertung der Relevanz sind getrennte Ingenieurprobleme, für die jeweils eigene Werkzeuge verwendet werden.

Warum Ähnlichkeit allein nicht ausreicht

Naives RAG wandelt die Abfrage in ein Embedding um, holt die K-K-ähnlichsten Abschnitte aus der Wissensdatenbank, fügt sie neben die Frage ein und lässt das Modell antworten. Die stillschweigende Annahme ist, dass Nähe gleichbedeutend mit Relevanz ist, weshalb die Liste der K-K-Elemente ohne jegliche Überprüfung akzeptiert wird. Dabei gehen vier Dinge schief.

Ahnlich bedeutet nicht dasselbe wie relevant. Die Einbettungsdistanz ist ein grober Indikator für thematische Nähe. Zwei Abschnitte können nebeneinander liegen, ohne dass einer die von dem anderen gestellte Frage beantwortet. Ein Text zu Behandlungsrichtlinien bei Bluthochdruck und ein Text zur Methodik kardiovaskulärer Medikamente können Seite an Seite erscheinen, doch nur der erste hilft dabei, zu entscheiden, wie ein Patient behandelt werden soll.

Die Sortierung ist unzuverlässig. Die Vektordistanz ist eine heuristische Methode und keine Rangfunktion, bei der die Position die Relevanz widerspiegelt. Die Lücke zwischen Platz drei und Platz sieben in einer Kosinus-Rangliste ist oft nur Rauschen.

Der Kontext wird fragmentiert. Das Aufteilen in Blöcke unterbricht Beziehungen, Hierarchien sowie Ursache und Wirkung. Ein Blöck mit Dosierungsangaben kann getrennt vom Blöck mit Kontraindikationen liegen, und keiner der beiden ist für sich allein vollständig.

Die Ergebnisse sind instabil. Kleine Wortänderungen können die Top-K-Liste verändern. Die Anfrage nach Nebenwirkungen von Metformin im Vergleich zu unerwünschten Reaktionen auf Metformin kann unterschiedliche Kandidaten liefern, wodurch sich die endgültige Antwort ändern kann. Das ist ein Zuverlässigkeitsmangel und kein Feinabstimmungsdetail.

Kurz gesagt: Die Suche liefert Kandidaten – sie garantiert jedoch keine Korrektheit.

Das zweistufige Design

Anstatt ein einziges System zum Finden und Bewerten zu verwenden, werden zwei Stufen erstellt, wobei jede für ihr eigenes Ziel optimiert ist.

Erste Stufe: Suche, wirft absichtlich ein breites Netz aus. Es werden etwa 50 bis 200 Kandidaten herangezogen – weitaus mehr, als dem Modell jemals gezeigt werden würden – denn das Ziel hier ist die Vollständigkeit. Die richtigen Dokumente müssen lediglich irgendwo in dieser Menge vorhanden sein, auch wenn diese Menge unvollständig ist.

Die zweite Phase, Richter, verwendet einen weitaus strengeren Test. Dabei handelt es sich in der Regel um einen Cross-Encoder-Reranker, der die Abfrage zusammen mit jedem Kandidattext liest und einen echten Relevanzwert berechnet. Dadurch wird die Auswahl auf fünf bis zehn besonders zuverlässige Abschnitte eingegrenzt. Erst danach gelangt der zusammengestellte Kontext an das Sprachmodell.

Was Embeddings tatsächlich beitragen

Die Fehlinterpretation der Rolle von Embeddings ist der Grund, warum Teams zu sehr auf sie angewiesen sind. Stellen Sie sich einen Bibliothekar vor, der nicht jedes Buch liest, sondern jedes mit einigen Schlüsselthemen kennzeichnet. Wenn eine Frage eintrifft, wandelt der Bibliothekar sie in ähnliche Tags um und holt die Bücher heraus, deren Tags am besten passen. Das ist schnell und findet in der Regel etwas Nützliches, basiert jedoch auf oberflächlichen Themen statt auf einem tiefen Verständnis, wodurch einige Bücher zwar verwandt sind, aber nicht das Richtige für die Anfrage darstellen.

Die Folge: Ihr Embedding-Modell bestimmt Ihr Suchverhalten. Es entscheidet darüber, was gefunden wird und was übersehen bleibt. Es entscheidet jedoch nicht darüber, was richtig ist – das ist die Aufgabe der Bewertungsstufe.

Daher ist die Wahl eines Embedding-Modells eine Entscheidung hinsichtlich der Vollständigkeit der Ergebnisse. Sie wählen das Verfahren, durch das die erste Stufe das Korpus betrachtet. Abwägen Sie Bewertungskriterien wie MTEB und BEIR, die Sprachabdeckung, die Größe des Modells im Verhältnis zu Ihrer Hardware, die Vektordimension, die maximale Eingabellänge sowie die Inferenzgeschwindigkeit. All diese Faktoren betreffen die Vollständigkeit der Ergebnisse.

Optionen für die Bewertungsstufe und wann welche geeignet ist

Die Bewertungsstufe ist eine Rolle in der Architektur. Mehrere Implementierungen können diese Rolle übernehmen, wobei es unterschiedliche Kompromisse in Bezug auf Genauigkeit, Latenz, Komplexität und Kosten gibt.

Reciprocal Rank Fusion

RRF bewertet die Relevanz überhaupt nicht. Es fügt die gerankten Listen mehrerer Quellen – beispielsweise eine Schlüsselwortsuche und eine semantische Suche – zu einer einzigen Sortierung zusammen. Für jedes Dokument addiert es den Wert 1 / (k + Rang) aus allen Listen, wobei k eine Konstante ist, meist 60, die die Dominanz der ganz oberen Ränge abmildert. Dokumente, die in mehreren Listen gut gerankt sind, steigen in der Rangliste auf.

Es ist schnell, deterministisch, erfordert keine Modellinferenz und verursacht fast keine Verzögerung. Da es Rangpositionen und nicht Rohwerte verwendet, umgeht es die Diskrepanz zwischen BM25-Werten und Kosinusähnlichkeiten, wodurch keine Normalisierung notwendig ist.

Seine Grenze besteht darin, dass er nur Übereinstimmungen kennt. Wenn mehrere Suchmaschinen ein Dokument für wichtig halten, geht RRF davon aus, dass es wahrscheinlich wichtig ist. Das ist eine sinnvolle Heuristik, bleibt aber dennoch eine Heuristik. Er kann kein relevantes Dokument retten, das alle Suchmaschinen übersehen haben, und er kann auch kein thematisch benachbartes Dokument von einem unterscheiden, das die Frage beantwortet.

Verwenden Sie ihn für hybride Suchverfahren, wenn Sie eine einfache Methode zum Zusammenführen von Listen benötigen. Er gehört zur Suchphase, um die Kandidaten zu verbessern, ersetzt aber nicht den Entscheider.

Cross-Encoders

Ein Cross-Encoder gibt die Abfrage und einen Kandidaten als zusammengefügte Sequenz in das Modell ein und gibt einen Relevanzwert zurück. Bi-Encoder embedden Abfrage und Dokument voneinander getrennt, während hier jedes Token der Frage auf jedes Token des Textabschnitts zugreifen kann. Das Modell kann daher darüber nachdenken, wie spezifische Phrasen in der Frage mit spezifischen Phrasen im Text in Beziehung stehen. Typische Beispiele sind Sentence-Transformer-Modelle wie cross-encoder/ms-marco-MiniLM-L-12-v2, gehostete Reranking-Dienste sowie Cross-Encoder, die auf medizinischen, rechtlichen oder wissenschaftlichen Daten feinabgestimmt wurden.

Ihre Stärke liegt in der Genauigkeit. In Ranking-Benchmarks schneiden sie in der Regel besser ab als andere Ansätze, weil sie feinere Interaktionen erfassen können, die eine reine Embedding-Similarity nicht leisten kann. Das ist das Äquivalent dazu, zu prüfen, ob ein Dokument tatsächlich die Frage beantwortet, ohne eine vollständige LLM-Aufrufung durchzuführen.

Die Kosten entstehen durch einen separaten Vorlaufprozess für jedes Abfragen- und Kandidatenpaar. Ein Pool mit 100 Dokumenten bedeutet 100 Modellaufrufe pro Abfrage, wodurch die Latenz linear mit der Größe des Pools zunimmt – größere Modelle verschlimmern die Situation noch weiter.

Sie sind der Standardwert, wenn die Qualität der Antworten an erster Stelle steht: im Gesundheitswesen, im Rechtswesen, bei Compliance-Anforderungen, in der Finanzanalyse – überall, wo falsche Ergebnisse Folgen haben können. Wenn das Latenzbudget etwa 50 bis 200 Millisekunden für eine erneute Sortierung zulässt, was die meisten nicht-echtzeitbasierten Systeme leisten können, sollte man hier beginnen.

ColBERT und späte Interaktion

ColBERT, abgekürzt für contextualized late interaction over BERT, befindet sich zwischen Bi-Encodern und Cross-Encodern. Er kodiert Abfragen und Dokumente unabhängig voneinander in Token-basierte Vektoren und bewertet sie anschließend, indem er Abfragen-Token mit Dokumenten-Token abgleicht. Da die Dokumentenvektoren im Voraus berechnet werden können, ist er zur Abfragezeit viel günstiger als ein Cross-Encoder, behält aber mehr Details als ein einziger zusammengeführter Vektor. Der Nachteil ist ein größeres Index, da jedem Token ein eigener Vektor zugeordnet wird. Er eignet sich für Systeme, die eine bessere Rangliste als einfache Embeddings benötigen und eine höhere Durchsatzrate als Cross-Encodern bieten.

Ein LLM als Richter

Ein allgemeines Sprachmodell kann Kandidaten direkt bewerten. Es kann fein abgestimmte, mehrstufige Relevanzbeziehungen erkennen – beispielsweise, dass ein Dokument über Arzneimittelwechselwirkungen eine Frage zur Behandlungssicherheit betrifft, obwohl die Vokabulare nicht übereinstimmen. Zudem kann es explizite Relevanzkriterien aus der Anfrage befolgen, was es anpassungsfähig gegenüber domain-spezifischen Bedeutungen von Relevanz macht.

Es ist außerdem mit Abstand die teuerste Option. Ein Reranking-Vorgang kann eine bis fünf Sekunden dauern und zehn bis hundertmal teurer sein als ein Cross-Encoder-Vorgang. Die Bewertungen können von Durchlauf zu Durchlauf variieren, und die Modelle weisen Positionenbias auf, indem sie Dokumente bevorzugen, die früher in der Anfrage angegeben sind. Hostete Modelle führen zudem zu einer externen Abhängigkeit.

Es macht Sinn in zwei Situationen: im Offline-Modus oder bei Batch-Aufgaben, bei denen die Latenz unerheblich ist, wie zum Beispiel beim Aufbau von kuratierten Wissensbasen, bei der Bewertung der Suchleistung während der Entwicklung oder bei der Erstellung von Trainingsdaten für einen speziellen Neubewertungsmechanismus; sowie bei hochriskanten, geringvolumigen Tools, bei denen der Wert einer korrekten Antwort die Kosten pro Abfrage rechtfertigt, wie beispielsweise bei fachlich anspruchsvollen medizinischen oder juristischen Recherchen.

Modellwahl für jede Phase

Das Muster zu verstehen ist eine Sache, Modelle auszuwählen eine andere. Die Architektur erfordert zwei Auswahlentscheidungen, die jeweils von der Aufgabe bestimmt werden.

Beginnen Sie mit der Aufgabe

Klinische Fragebeantwortung, Dokumentenerkundung und regulatorische Konformität erfordern unterschiedliche Ansätze. Bei der Qualitätskontrolle ist hohe Präzision bei geringer Anzahl von Ergebnissen entscheidend. Bei der Dokumentenerkundung zählen Breite und Vielfalt. Für die Konformität ist eine deterministische, überprüfbare Suche mit möglichst wenigen falsch negativen Ergebnissen notwendig. Das Aufgabenszenario prägt jede spätere Entscheidung.

Das Embedding-Modell bestimmt die Grenze der Erinnerungsfähigkeit

Es legt fest, was das System vor dem Eingreifen des Bewerters finden kann. Ein relevantes Dokument, das nie in die Ergebnisliste gelangt, kann von keinem Nachrangierungsalgorithmus wiederhergestellt werden. Vergleichen Sie die Kandidaten anhand folgender Kriterien:

Referenzwerte. Schauen Sie sich die MTEB- und BEIR-Ergebnisse für den Aufgabentyp an, der Ihrem am nächsten kommt – beispielsweise Textsuche oder Fragebeantwortung – und nicht nur die Gesamtpunktzahl.
Sprachen und Anwendungsbereich. Mehrsprachige Modelle opfern etwas an präziser EinzelSprachverarbeitung zugunsten größerer Vielfalt, während auf den jeweiligen Anwendungsbereich abgestimmte Modelle das Gegenteil tun. Überprüfen Sie die Abdeckung Ihrer Fachbegriffe.
Größe und Infrastruktur. Größere Modelle liefern in der Regel bessere Ergebnisse, sind aber in großem Maßstab teurer. Berücksichtigen Sie das Indexierungsvolumen, die Abfragenzahl sowie den Einsatz von GPU gegenüber CPU. Ein Modell, das in einem Benchmark drei Prozent besser abschneidet, benötigt jedoch doppelt so viel Rechenleistung – das kann ein schlechter Tausch sein.
Vektordimension. Mehr Dimensionen ermöglichen die Erfassung größerer Nuancen, erhöhen aber gleichzeitig Speicherbedarf und Latenz. Viele Modelle sind in verschiedenen Größen erhältlich; prüfen Sie daher, ob 768 gegenüber 1536 Dimensionen die zusätzlichen Kosten rechtfertigen.
Maximale Eingabellänge. Dies begrenzt die Aufteilung der Eingabe in Teile. Eine Obergrenze von 512 Token zwingt zu kleineren Teilen und mehr Fragmentierung, während 2048 oder 8192 Token mehr Kontext pro Teil beibehalten.
Geschwindigkeit. Die Einbettungslatenz ist sowohl zum Zeitpunkt der Indizierung als auch bei Abfragen von Bedeutung. Kleinere, verfeinerte Modelle können bei strengen SLAs eine gute Trefferquote bei deutlich geringerer Latenz liefern.

Das Prinzip: Passen Sie das Einbettungsmodell an Bedeckung und Geschwindigkeit an – nicht an Präzision. Die Präzision ist Aufgabe des Bewerters.

Der Reranker bestimmt die endgültige Korrektheit

Er ist das letzte Filter vor dem LLM, wodurch seine Qualität direkt die Genauigkeit der Antworten beeinflusst. Beurteilen Sie ihn anhand von:

Ranggenauigkeit. Die wichtigste Kennzahl. Überprüfen Sie nDCG, MRR und MAP an Benchmarks, die Ihrem Bereich nahekommen. Kleine Verbesserungen hier können Halluzinationen in den nachfolgenden Schritten deutlich verringern.
Latenz. Der Reranker wird einmal pro Kandidat ausgeführt, sodass 100 Kandidaten 100 Durchläufe bedeuten. Die Zeit pro Durchlauf sowie die Gesamtzeit stellen wichtige Grenzwerte in der Produktion dar.
Domain-Anpassung. Allgemeine Reranker leisten sich gut bei der breiten Informationsbeschaffung, doch kritische Domänen profitieren oft von Rerankern, die auf Daten zur Relevanz der jeweiligen Domäne trainiert wurden. Ein auf medizinischer Literatur trainierter Reranker bewertet klinische Abfragen besser als ein allgemeiner Reranker – auch wenn dieser bei generischen Benchmarks höhere Ergebnisse erzielt.
Durchsatz. Bei hohem Traffic kann der Reranker zum Engpass werden. Überlegen Sie sich das Batching, den Modellparallelismus sowie die Möglichkeit, eine leichtere Alternative wie einen verfeinerten Cross-Encoder oder ein Modell mit später Interaktion zu verwenden, das bei deutlich höherem Durchsatz eine akzeptable Genauigkeit bietet.

Investieren Sie in beides

Die leistungsstärksten Pipeline-Systeme wählen nicht zwischen einem guten Embedder und einem guten Reranker, da die beiden unabhängige Aufgaben erledigen. Ein leistungsstarker Embedder in Kombination mit einem schwachen Reranker liefert eine hohe Trefferquote, aber störende Endergebnisse. Ein schwacher Embedder in Kombination mit einem starken Reranker ermöglicht eine präzise Sortierung, allerdings nur aus einem unvollständigen Ergebnispool. Keines dieser Ansätze reicht allein aus.

Das Rezept besteht aus einer schnellen Suche mit hoher Trefferquote sowie einer starken, präzisen Bewertung. Passen Sie den Embedder an Ihre Anforderungen hinsichtlich der Trefferquote an und den Reranker an Ihre Anforderungen hinsichtlich der Präzision, und justieren Sie anschließend die Größe des Kandidatenpools zwischen den Schritten, um einen Kompromiss zwischen Abdeckung und Latenz beim Neuranking zu finden.

Ein konkretes Beispiel

Stellen Sie sich vor, ein klinischer Assistent wird gefragt, ob ein Patient, der ein bestimmtes Diabetes-Medikament einnimmt, sicherlich ein zweites Medikament einnehmen kann. In der Suchphase werden eine Schlüsselwortabfrage und eine Vektorabfrage parallel durchgeführt, miteinander über RRF kombiniert und 100 Kandidaten ausgewählt. Dazu gehören die Monografie zu jedem Medikament, ein Paper zur Studiendesign-Methodik, ein allgemeines Ernährungshandbuch sowie mehrere Interaktionstabellen. Allein aufgrund der Ähnlichkeit könnten das Studiopaper und das Handbuch vor den Interaktionstabellen rangiert werden, da ihr Wortschatz der Frage näher kommt.

Die Richterstufe liest die Frage neben jedem der hundert Abschnitte und bewertet, ob der Abschnitt tatsächlich die kombinierte Verwendung behandelt. Die Interaktions-Tabelle sowie der entsprechende Kontraindikationsabschnitt rücken an die Spitze, der Flyer fällt zurück, und das Modell erhält sechs Abschnitte anstelle der störenden zehn. Dasselbe Korpus, dieselben Embeddings – unterschiedliches Ergebnis, weil ein zweiter Komponente eine Entscheidung traf, für die die erste ursprünglich nie konzipiert war.

Anpassung des Übergangs zwischen den Stufen

Die Größe des Kandidatenpools ist der entscheidende Faktor. Ist sie zu klein, sieht der Bewertungsmechanismus niemals den richtigen Abschnitt, was die Erinnerungsrate für das gesamte System begrenzt. Ist sie zu groß, steigen die Verzögerung und der Aufwand beim Neuranking nur geringfügig. Eine praktische Methode, sie einzustellen, besteht darin, auf einem beschrifteten Beispiel die Rangstufe zu notieren, an der der richtige Abschnitt in der ersten Phase erscheint, und anschließend einen Pool zu wählen, der fast alle dieser Abschnitte abdeckt. Wenn der richtige Abschnitt regelmäßig über Rang 150 liegt, liegt das Problem wahrscheinlich in der Suchphase – mit einem besseren Embedder, einer hybriden Suchmethode oder einer verbesserten Aufteilung in Blöcke – und nicht in einem leistungsstärkeren Neuranker.

Auch andere Gewohnheiten helfen:

Bewerten Sie die beiden Phasen getrennt voneinander. Messen Sie die Erinnerungsrate des Pools vor der Bewertung sowie die Genauigkeit der endgültigen Liste nach der Bewertung, damit eine Verschlechterung auf die richtige Phase zurückgeführt werden kann.
Speichern Sie bei langsam verändernden Korpora die Ergebnisse des Neurankings für häufige Abfragen im Cache.
Halten Sie den Endkontext klein. Der Einsatz von fünf starken Abschnitten ist in der Regel besser als der von zwanzig gemischten, da zusätzliches Material um die Aufmerksamkeit konkurriert.
Überprüfen Sie die Einstellungen erneut, wenn sich das Muster des Korpus oder der Abfrage ändert, denn ein auf einem bestimmten Bereich optimierter Neurangier kann in einem anderen Bereich an Leistung verlieren.

Betrachten Sie dies als Hypothese, die Sie an Ihren eigenen Daten testen sollten, und nicht als Garantie – schließlich unterscheiden sich die Ergebnisse je nach Bereich sowie je nach Stärke der Ausgangslösung.

Die Schlussfolgerung

Eine zuverlässige RAG-Lösung entsteht nicht durch das Finden einer besseren Embedding-Methode. Sie resultiert aus der Trennung von Suche und Bewertung, wobei eine Phase die maximale Abdeckung und die andere die maximale Genauigkeit anstrebt.

Der Wandel ist zunächst konzeptionell und erst danach technisch. Behandeln Sie „Top-K“ nicht mehr als endgültige Antwort, sondern als Menge potenzieller Ergebnisse. Betrachten Sie Ähnlichkeit nicht als Wahrheit, sondern als Hypothese, die überprüft werden muss. Suchen Sie weit, beurteilen Sie anschließend präzise.