Hybride Suche für RAG: BM25, Vektoren und die praktische Anwendung der rekursiven Rangverbindung.
Hybride Suche für RAG: Warum die rein vektorbasierte Suche genaue IDs verliert, wie Reciprocal Rank Fusion BM25 mit Embeddings verbindet und wo die hybride Methode immer noch nachsteht.
Quellen: Hybrid Search in RAG — BM25, Vectors, and Reciprocal Rank Fusion in Practice
Die Hinzufügung einer Schlüsselwortsuche zu einem rein vektorbasierten Suchsystem ist einer der kostengünstigsten Wege, die Genauigkeit in RAG zu verbessern. Anthropic hat dies an eigenen Korpora gemessen: Kontextbezogener BM25 in Kombination mit kontextbezogenen Embeddings reduzierte die Anzahl fehlerhafter Ergebnisse in der Top-20 um bis zu 49 Prozent, ohne dass das Embedding-Modell geändert werden musste.
Betrachten Sie den Grund für diese Zahl. Ein Benutzer gibt einen Fahrzeugidentifikator wie GX-V5-5N ein. Ein reines Vektorsystem liefert allgemeine Anleitungen zur Registrierung und Servicehistorien, und das richtige Dokument fehlt bereits in den ersten zehn Ergebnissen. Die Embeddings erfassen den automobilen Kontext hingegen perfekt – und genau deshalb werden solche wörtlichen Suchbegriffe ausgeblendet. Es geht hier nicht um schwache Embeddings, sondern um strukturelle Probleme, die jedes allein auf Vektoren basierende RAG-System betreffen, wie es in den meisten Standard-Tutorials dargestellt wird.
Unten: Warum die Kombination von lexikalischer und vektorbasierter Suche eine andere Mathematik erfordert als das Durchschnittnehmen von Scores, was Reciprocal Rank Fusion leistet, wo der hybride Ansatz nicht mehr hilft, und was man vor dem Einsatz messen sollte.
Die Idee in zwei Minuten
Pure vektorbasierte Suche verliert systematisch präzise Übereinstimmungen wie Fehlercodes, Produktidentifikatoren und Eigennamen. Die Embeddings sind dabei nicht schlecht – semantische Nähe und wörtliche Übereinstimmung sind einfach unterschiedliche Eigenschaften.
BM25, eine lexikalische Ranking-Funktion aus den 1990er Jahren, liefert das, was Vektoren fehlt. Sie erfasst seltene, spezifische Token nahezu kostenlos, vernachlässigt dafür jedoch Paraphrasen und Synonyme. Die beiden Methoden versagen in entgegengesetzte Richtungen – das ist der strukturelle Grund, sie zu kombinieren, und nicht nur ein vorübergehender technischer Trend.
Das Problem ist, dass ihre Ergebnisse nicht addiert werden können. Die BM25-Werte sind unbegrenzt und hängen vom Korpus ab, während die Kosinusähnlichkeit zwischen minus eins und eins liegt. Eine Summe von 15,3 und 0,82 bedeutet nichts. Deshalb fügen moderne Suchmaschinen die Werte nicht zusammen. Stattdessen verwenden sie die Methode Reciprocal Rank Fusion, um die Rangpositionen zu kombinieren.
Hybride Ansätze gewinnen jedoch nicht immer. Bei Abfragen, die auf exakten Identifikatoren basieren, kann BM25 allein die Kombinationsmethode übertreffen. Die wichtige Frage ist nicht, ob man einen hybriden Ansatz verwenden soll, sondern welcher Anteil der Abfragen ihn tatsächlich benötigt – und das lässt sich messen.
Zwei sich ergänzende Blindstellen
Stellen Sie sich zwei Junior-Mitarbeiter mit entgegengesetzten Schwächen vor.
Der Erste ist genauso wörtlich wie Ctrl+F. Wenn nach der Seite mit dem Fehlcode ERR_CONNECTION_RESET gefragt wird, findet er sie sofort. Bei Fragen zu Verbindungsproblemen überseht er das Dokument zur Sitzungsausfall, weil kein Wort der Anfrage darin vorkommt.
Der Zweite liest zwischen den Zeilen. Er weiß, dass Verbindungsprobleme und Sitzungsausfälle dasselbe beschreiben. Wenn jedoch nach einem präzisen Fehlcode gefragt wird, gibt er eine allgemeine Notiz zu Netzwerkfehlern heraus, da der seltene Ausdruck im durchschnittlichen Sinn des gesamten Satzes unterging.
Keiner von beiden reicht allein aus. Das ist die gesamte Argumentation in zwei Absätzen.
Was BM25 berücksichtigt
BM25 ist weder Magie noch veraltet. Es basiert auf einem umgekehrten Index, einer Tabelle, die jedes Wort mit den darin enthaltenen Dokumenten verknüpft, sodass der Algorithmus niemals die gesamte Sammlung durchsuchen muss. Die Rangfolge basiert auf drei Intuitionen:
- Seltene Begriffe wiegen mehr. Der Identifikator GX-V5-5N sagt weitaus mehr aus als das Wort „Fahrzeug“.
- Wiederholungen führen zur Sättigung. Die zehnte Auftretensweise eines Wortes trägt viel weniger bei als die zweite, denn die Kurve flacht nach einigen Wiederholungen ab.
- Länge wird bestraft. Lange Dokumente sollten nicht einfach deshalb gewinnen, weil sie mehr Raum für zufällige Übereinstimmungen bieten.
Ein Vektormodell basiert auf einem anderen Prinzip. Der Text wird zu einer Liste von Zahlen, die die Bedeutung kodieren, und die Rangfolge ergibt sich aus der Nähe in diesem Raum – unabhängig davon, ob Abfrage und Dokument ein Wort teilen. Ein Algorithmus misst die Zeichencoverage, ein anderer die Bedeutungscoverage.
Ein Kategorienfehler, den man vermeiden sollte
Es ist verlockend, die Vektorsuche als eine verbesserte Volltextsuche zu betrachten – neuer, intelligenter und die logische Weiterentwicklung. Das ist jedoch ein Kategorienfehler. Vektoren ersetzen die lexikalische Suche nicht. Sie lösen ein anderes Problem und verlieren dadurch eine Fähigkeit, die die lexikalische Suche kostenlos hatte.
Falls ein Korpus Codes, Identifikatoren oder Eigennamen enthält, wird allein eine Embedding-Verarbeitung diese Informationen verlieren, egal wie gut das Modell ist. Die Grenze ergibt sich daraus, was ein Vektor darstellt. Die richtige Herangehensweise besteht darin zu bestimmen, welche Abfragen welche „Stärke“ benötigen – was das Problem der Zusammenführung zweier Ergebnislisten, die in unverwandten Einheiten gemessen werden, beibehält.
Warum Scores nicht einfach addiert werden können
Der natürliche ingenieurtechnische Instinkt besteht darin, zu normalisieren, zu gewichten und zu addieren. Doch dabei stößt man auf eine Tatsache, die durch Anpassungen nicht beseitigt werden kann.
BM25 weist keine theoretische Obergrenze auf. Seine Ausgabe steigt mit der Anzahl der abgeglichenen Abfrageschlüsselwörter, ihrer Seltenheit im Korpus sowie der Länge des Dokuments – daher erhält dasselbe Dokument nach dem Eintreffen von zehntausend neuen Dateien einen anderen Wert. Die Kosinusähnlichkeit, die den Winkel zwischen zwei Vektoren vergleicht, bleibt im Bereich von minus eins bis eins.
Das Addieren von 15,3 zu 0,82 ist wie das Hinzufügen von Kilogramm zu Pfund ohne Umrechnung: arithmetisch möglich, informativ jedoch sinnlos. Man kann Min-Max- oder Z-Score-Normalisierung verwenden, doch dann müssen beide Bewertungssysteme jedes Mal neu kalibriert werden, wenn sich das Korpus, das Embedding-Modell oder die Abfragen ändern. Eine Kalibrierung, die nach jeder Neindeckung erneut durchgeführt werden muss, stellt eine verschobene Verpflichtung dar.
Abstimmung über die Position
Die rekursive Rangfusionsmethode umgeht das Problem, indem sie die Bewertungsscores ignoriert. Sie betrachtet lediglich den Rang, den jede Suchmaschine einem Dokument zugewiesen hat. Die Formel ist einfach: Die gefusionierte Bewertung eines Dokuments ist die Summe über alle Suchmaschinen von eins geteilt durch (k plus dessen Rang in der Liste dieser Suchmaschine). Ein Dokument, das in einer Liste fehlt, trägt nichts bei.
Daher schneidet ein Dokument, das in den Top drei beider Listen steht, besser ab als eines, das in einer Liste an erster Stelle steht, in der anderen aber fehlt. RRF belohnt Übereinstimmungen in der Sortierung und nicht Gewissheit, wobei die Rangposition eine Einheit ist, die jeder Ranggeber auf dieselbe Weise erzeugt.
Die Methode stammt von Cormack, Clarke und Büttcher auf der SIGIR 2009, lange vor RAG. Ihre Begründung: Hohe Ränge sollten am meisten zählen, niedrige Ränge sollten nicht völlig verschwinden, und die Konstante k mildert den Einfluss jedes einzelnen außergewöhnlichen Systems ab.
Eine Anmerkung aus den Design-Überprüfungen: Der Standardwert k von 60 entstand aus einem einzigen Pilotversuch und wurde in späteren Validierungen nicht überarbeitet. Die Autoren selbst bezeichneten dies als eine unkritische Entscheidung. Bei k=60 liegt die Punktzahl der ersten Rangstufe etwa 1,6 Prozent über der der zweiten Rangstufe, während die Punktzahl der sechzigsten Rangstufe etwa die Hälfte der Punktzahl der ersten Rangstufe beträgt.
In der Praxis handelt es sich bei k um einen feinen Regler und nicht um eine Hebelwirkung. Entscheidender ist vielmehr, wie viele Kandidaten jede Gruppe beiträgt. Liefern die Vektor-Gruppen fünfzig Kandidaten, trägt ein Dokument auf Platz fünfzig eins genau null bei.
Wie Hybrid zur Standardmethode wurde
Die klarsten Zahlen stammen von Anthropics kontextbasierten Suchexperimenten aus dem Jahr 2024 anhand eigener Datensätze, bei denen untersucht wurde, wie oft der richtige Datensatzteil nicht zu den zwanzig besten Ergebnissen gehörte. Kontextuelle Embeddings allein verringerten diese Ausfälle um 35 Prozent. Durch die Kombination mit dem kontextuellen BM25-Verfahren stieg die Reduzierung auf 49 Prozent – das bedeutet, dass der lexikalische Ansatz bereits einen großen Teil dessen leistete, was die Verbesserung durch die Embeddings bewirkte.
Man sollte einer Fehlinterpretation ausweichen: Derselbe Bericht gibt an, dass eine Reduzierung um 67 Prozent erreicht wird, wenn zusätzlich eine Neubewertung der Ergebnisse erfolgt – doch diese Neubewertung ist eine separate Phase, bei der ein anderer Modelltyp verwendet wird. Fusion und Neubewertung sind keine Synonyme, und ihre Vermischung auf derselben Präsentationsseite ist ein häufiger Fehler.
Die Konvergenz der Anbieter sagt mehr aus als jeder einzelne Benchmark. Elasticsearch, OpenSearch, Weaviate, Qdrant und Azure AI Search bieten alle RRF standardmäßig an. Die hybride Suche ist von einer fortgeschrittenen Option zur Standardeinstellung geworden.
Der Preis für einen zweiten Index
Es gibt einen Preis, der bereits vor der Entscheidung berücksichtigt werden sollte und nicht erst nach dem ersten Problem:
- mehr Speicherplatz, dessen Menge von der Konfiguration abhängt,
- einige zusätzliche Millisekunden für den Fusionsschritt,
- und, was am wichtigsten ist, ein weiterer Faktor, der aus dem Gleichgewicht geraten kann. Wenn ein Dokument aus dem Vektorindex entfernt wird, aber im lexikalischen Index erhalten bleibt, taucht es immer wieder wie ein Geist auf.
Teams, die bereits Postgres nutzen, können oft durch die Kombination von pgvector mit der integrierten Volltextsuche – ausschließlich in SQL und ohne neue Infrastruktur – eine lexikalische Lösung erhalten. Wenn ein aktuelles RAG-System ausschließlich vektorbasiert ist, stellt sich die bessere Frage, warum es BM25 fehlt – das ist eher ein Problem technischer Schulden als mangelnder Innovation.
Wo das Hybridsystem nachlässt
Die Einigkeit der Anbieter könnte darauf hindeuten, dass das Hybridmodell immer gewinnt. Direkte Tests sind jedoch differenzierter, und unerwartete Ergebnisse treten auf, wenn man die Ergebnisse nach Anfrageart statt durchschnittlich betrachtet.
In Microsofts Vergleich von Azure AI Search im Jahr 2023 übertraf das hybride Suchverfahren insgesamt das rein vektorbasierte Verfahren. Betrachtet man die Ergebnisse nach Kategorien, ist das Muster weniger eindeutig: Bei rein schlagwortbasierten Anfragen kann der einzelne lexikalische Suchmotor bessere Ergebnisse liefern als das kombinierte Verfahren. Der Durchschnitt verdeckt das, was eine Analyse nach einzelnen Segmenten offenlegt.
Ein zweiter Suchmotor fügt nicht immer Wert hinzu
Wo auch immer der lexikalische Suchmotor richtig liegt, schwächt ein zweiter Suchmotor seine Leistung. Angenommen, BM25 ordnet das richtige Dokument an erster Stelle ein, während der vektorbasierte Suchmotor es auf Platz zehn setzt. Durch die Kombination rutscht es hinter ein Dokument, das von beiden Methoden auf Platz drei eingestuft wird. Übereinstimmung hat Vorrang vor Genauigkeit – was zwar beabsichtigt ist, aber bei bestimmten Anfragearten zu Nachteilen führt.
Auch die Qualität des zweiten Schritts ist wichtig. Tests zur Erkennung in der ersten Phase an einem wissenschaftlichen Korpus zeigten, dass ein auf einem schwachen Embedding-Modell basierender Hybrid-Ansatz allein bei BM25 hinterherhinkt, während derselbe Ansatz mit einem stärkeren Modell deutlich darüber liegt. Die Fusion schafft nichts Neues; sie mischt lediglich vorhandene Hinweise zusammen, wodurch Rauschen denselben Einfluss erhält wie das Signal.
Das steht im Widerspruch zum Ausgangspunkt nicht. Die Qualität des Embeddings bestimmt, wie viel der vektorbasierte Schritt hinzufügt, doch selbst das beste Embedding kann keinen exakten Identifikator wiederherstellen, den es nicht darstellt. Das sind zwei getrennte Aspekte.
Keines der Ergebnisse spricht gegen die hybride Suche. Beide sprechen jedoch dagegen, sie ohne Messung der eigenen Abfragedistribution einzusetzen. Viele Teams wählen die hybride Suche aus Gründen der Einfachheit als Standard aus, ohne diese Distribution jemals zu berücksichtigen.
Die Messung ist kostengünstig. Teilen Sie die Abfragenachrichten in solche mit einem exakten Identifikator sowie in rein konzeptionelle Abfragen auf und berechnen Sie für jede Gruppe separat eine Metrik. Das dauert Stunden und nicht nur kurze Zeit, während eine einzige aggregierte Zahl die Regression versteckt, die später in der Produktion Probleme verursacht.
Das Konsensproblem
Die Rangfusionsmethode weist einen subtileren Fehler auf, der dann zum Vorschein kommt, wenn sich die Suchmaschinen einig sind, und nicht, wenn sie sich nicht einigen.
Nehmen wir eine Suche in technischer Dokumentation mit einer Abfrage zur Konfiguration von OAuth über Umgebungsvariablen. Der vektorbasierte Ansatz liefert einen allgemeinen Sicherheitshinweis – inhaltlich relevant, aber ohne spezifische Informationen zu OAuth. BM25 liefert eine präzise OAuth-Ergebnis, allerdings aus einem drei Jahre alten Changelog. Keines der Ergebnisse ist die beste Antwort, und die Fusion rangiert weiterhin das schwächere der beiden an erster Stelle.
Das ist eine direkte Folge der Funktionsweise von RRF. Das veraltete Changelog wurde von beiden Engines auf Mittelstufe eingestuft, wodurch die beiden gegensätzlichen Bewertungen zusammen mehr wogen als die einer frischen Seite, die nur von einem einzigen Engine gefallen hat. Zwei zurückhaltende Meinungen überwiegen eine zuversichtliche und korrekte.
Filter vor der Fusion
Die Korrektur findet sich oberhalb der mathematischen Verarbeitung. In den meisten Fällen sollten strenge Metadatenfilter wie Frische, Berechtigungen und Dokumentstatus vor der Fusion angewendet werden und nicht danach. Die Fusion sollte keine Kandidaten berücksichtigen, die von vornherein nicht in Betracht kamen. Einige Produktionsysteme führen die Filter danach durch und erzielen gute Ergebnisse, sodass es sich dabei um eine architektonische Entscheidung handelt, die man an eigenem Korpus testen muss, und nicht um ein universelles Gesetz.
Die Reihenfolge ist hier nicht rein kosmetischer Natur. Das Filtern nach der Fusion entfernt die veralteten Seiten aus dem Ergebnis, doch die frischen Seiten, die bereits Stimmen verloren haben und unter die Schwellenwertgrenze gefallen sind, bleiben weiterhin vorhanden. Das Filtern vor der Fusion verändert hingegen den Kandidatenpool, über den beide Algorithmen ursprünglich abstimmen.
In der Praxis sollten gleichzeitig drei Filter am Eingang beider Prozesse angewendet werden: Benutzerrechte, Dokumentstatus sowie ein an den jeweiligen Bereich angepasstes Frischefenster. Beide Prozesse müssen genau denselben Filter erhalten. Andernfalls füllt sich die Kandidatenliste des einen Prozesses mit Dokumenten, die der andere nie gesehen hat, und die Fusion wandelt diese Asymmetrie in einen Rankingvorteil um.
Noch ein Punkt für sprachen mit hoher morphologischer Reichtum. Starke Flexion stört die lexikalische Übereinstimmung. Ohne eine gute Lemmatisierung verliert BM25 einen großen Teil seiner Überlegenheit, denn Kasusvarianten eines Wortes, wie polnisch umowy und umowie oder deutsch Vertrags und Verträgen, erscheinen wie völlig unterschiedliche Token. Dies ist ein seltenes Fall, in dem das vektorbasierte Verfahren das lexikalische rettet und nicht umgekehrt.
Hybride Ansätze beheben daher eine Art von Fehlern, während sie gleichzeitig neue erzeugen, und nichts in einem Suchstack kann ohne Überprüfung standardmäßig als zuverlässig angesehen werden.
Was man daraus lernen kann
Der Rückgang der fehlgeschlagenen Suchvorgänge um 49 Prozent resultierte weder von einem größeren Modell noch von mehr Rechenleistung auf der GPU. Er entstand durch das Erkennen, dass eine einzige Textdarstellung nicht für zwei grundlegend unterschiedliche Suchtypen geeignet ist.
- BM25 und Vektoren versagen in entgegengesetzten Richtungen, was der strukturelle Grund dafür ist, sie zu kombinieren.
- RRF fügt Rangpositionen zusammen und nicht Scores, da die Skalierungen von BM25 und Kosinus inkompatibel sind und die Normalisierung die Kalibrierungskosten niemals endgültig beseitigt.
- Hybride Suchverfahren sind bei Infrastrukturanbietern Standard, daher stellt das Auslassen des zweiten Schritts technischen Schulden dar und keine Vorsichtsmaßnahme.
- Standard bedeutet nicht unbedingt allgemein bessere Leistung. Bei Abfragen mit exakten Identifikatoren kann BM25 allein die Kombinationstechnik übertreffen, und eine durchschnittliche Metrik wird das verbergen.
- Wenden Sie Metadatenfilter vor der Kombination an, sonst führt die Übereinstimmung zwischen den Suchmaschinen dazu, dass veraltete Dokumente vor neuen bevorzugt werden.
Für nächste Woche nehmen Sie die letzten tausend echten Abfragen, kennzeichnen Sie jede als enthaltend einen exakten Identifikator oder als rein konzeptionell und berechnen Sie das Verhältnis. Bewerten Sie anschließend die Genauigkeit getrennt für beide Gruppen und speichern Sie zwei Ergebniszeilen – nicht einen gemischten Durchschnitt. Diese Tabelle zeigt weitaus besser als jedes Hersteller-Vergleichsergebnis, ob das Hybrid-Verfahren Ihr System verbessert oder Ihnen lediglich einen weiteren Index zur Verwaltung liefert. Das Ergebnis gibt außerdem an, inwieweit Ihr Traffic von exakten Zeichenketten abhängt – etwas, was selten jemand erfasst hat.
Verwandte Artikel
- Praktische Hinweise: Die Grenzen der Vektorsuche in RAG – Kosinusähnlichkeit und mehr — Detaillierte Anleitung zu den Praktischen Hinweisen: Die Grenzen der Vektorsuche in RAG – Kosinusähnlichkeit und mehr: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.
- Apache Doris 4.1: Vektorsuche, JSON-Speicherung, OLAP und Lakehouse — Übersicht über die Neuerungen von Apache Doris 4.1: IVF-Vektorindizes, BM25-Suche(), 100 MB große JSON-Dokumente, Segment V3, Abfragespeicher, Iceberg-Schreibfunktionen, MERGE INTO sowie TIMESTAMPTZ.