Hybrid Search: BM25 und Vektorsuche mit Reciprocal Rank Fusion kombinieren

1. Das Grundproblem: unvergleichbare Score-Skalen

BM25 berechnet einen Relevanz-Score auf Basis von Termhäufigkeit, inverser Dokumenthäufigkeit und Dokumentlänge, wobei der resultierende Zahlenwert theoretisch unbegrenzt nach oben ist und stark vom jeweiligen Index und der konkreten Anfrage abhängt. Ein kNN-Score aus einer Vektorsuche dagegen basiert auf einer Distanz- oder Ähnlichkeitsmetrik wie Cosine-Similarity, die typischerweise zwischen null und eins liegt. Diese beiden Zahlenwerte direkt zu addieren oder zu vergleichen ergibt keinen fachlich sinnvollen Wert.

Ein naiver Ansatz wäre, beide Scores auf eine gemeinsame Skala zu normalisieren, etwa per Min-Max-Normalisierung, bevor man sie gewichtet summiert. Dieses Verfahren reagiert jedoch empfindlich auf Ausreißer und ist von Anfrage zu Anfrage instabil, weil sich die minimalen und maximalen Score-Werte je nach Trefferzahl und Anfrageinhalt ständig ändern. Reciprocal Rank Fusion umgeht dieses Problem komplett, indem es gar nicht erst versucht, Scores zu vergleichen.

2. Wie Reciprocal Rank Fusion tatsächlich funktioniert

RRF ignoriert die absoluten Score-Werte vollständig und betrachtet stattdessen nur die Rangposition, an der ein Dokument in jedem der beteiligten Rankings erscheint. Für jedes Dokument wird pro Ranking ein Fusion-Score nach der Formel eins geteilt durch die Summe aus Rangposition und einer Konstante berechnet, und die Fusion-Scores über alle Rankings hinweg werden anschließend für jedes Dokument aufsummiert.

Ein Dokument, das in beiden Rankings weit oben erscheint, sammelt zwei hohe Fusion-Score-Beiträge und landet dadurch in der kombinierten Ergebnisliste ganz oben. Ein Dokument, das nur in einem der beiden Rankings sehr weit oben steht, im anderen aber gar nicht auftaucht, erhält trotzdem einen soliden kombinierten Score, weil bereits ein einziger sehr guter Rang ausreicht, um relevant zu erscheinen. Dieses Prinzip macht RRF robust gegenüber den unterschiedlichen Score-Verteilungen der beiden Quell-Rankings.

// RRF-Formel je Dokument und Ranking:
// score = 1 / (rank_constant + rang_in_diesem_ranking)
// Gesamt-Score = Summe der score-Werte über alle Rankings

// Beispiel mit rank_constant = 60:
// Dokument A: Rang 1 in BM25, Rang 5 in kNN
// score_A = 1/(60+1) + 1/(60+5) = 0.01639 + 0.01538 = 0.03177

// Dokument B: Rang 3 in BM25, Rang 1 in kNN
// score_B = 1/(60+3) + 1/(60+1) = 0.01587 + 0.01639 = 0.03226

3. Die Rolle der rank_constant bei der Gewichtung

Die Konstante in der RRF-Formel, in Elasticsearch als rank_constant konfigurierbar und standardmäßig auf 60 gesetzt, steuert, wie stark hohe Rangpositionen gegenüber niedrigeren bevorzugt werden. Eine kleinere Konstante verstärkt den Einfluss der obersten Ränge deutlich, weil der Nenner der Formel dann für Rang eins vergleichsweise klein ist, während eine größere Konstante die Score-Unterschiede zwischen den ersten und den nachfolgenden Rängen einebnet.

In der Praxis liefert der Standardwert von 60 für die meisten Anwendungsfälle solide Ergebnisse, und Anpassungen lohnen sich vor allem dann, wenn beobachtet wird, dass ein einzelnes Ranking systematisch zu stark oder zu schwach in die kombinierte Ergebnisliste einfließt. Eine Anpassung sollte immer anhand konkreter, dokumentierter Testanfragen validiert werden, nicht nach Bauchgefühl.

4. Praktische Konfiguration: der retriever-Block mit rrf

In modernen Elasticsearch-Versionen lässt sich RRF über den retriever-Mechanismus direkt in der Suchanfrage konfigurieren, ohne eigene Fusion-Logik in der Anwendung implementieren zu müssen. Ein rrf-Retriever nimmt eine Liste von Sub-Retrievern entgegen, typischerweise einen standard-Retriever für die klassische BM25-Anfrage und einen knn-Retriever für die Vektorsuche, und führt deren Ergebnisse automatisch nach der RRF-Formel zusammen.

Dieser eingebaute Mechanismus vereinfacht die Implementierung erheblich gegenüber früheren Elasticsearch-Versionen, in denen Teams die Fusion selbst in der Anwendungsschicht nachbauen mussten, inklusive eigener Logik für Rangberechnung und Score-Aggregation über zwei separate Suchanfragen hinweg.

GET products/_search
{
  "retriever": {
    "rrf": {
      "retrievers": [
        {
          "standard": {
            "query": {
              "match": { "description": "leiser Standmixer" }
            }
          }
        },
        {
          "knn": {
            "field": "description_embedding",
            "query_vector": [0.021, -0.153, 0.402, "..."],
            "k": 20,
            "num_candidates": 100
          }
        }
      ],
      "rank_constant": 60,
      "rank_window_size": 50
    }
  }
}

5. Wann Hybrid Search reiner Vektorsuche tatsächlich überlegen ist

Reine Vektorsuche hat eine systematische Schwäche bei exakten, seltenen Begriffen, etwa spezifischen Artikelnummern, Modellbezeichnungen oder Markennamen, weil ein Embedding-Modell solche seltenen Token oft nicht präzise genug im Vektorraum unterscheidet. BM25 hingegen ist für genau diesen Fall optimiert, da seltene Begriffe automatisch ein hohes Gewicht erhalten. Hybrid Search führt beide Stärken zusammen, indem exakte Begriffstreffer weiterhin zuverlässig oben landen, während semantisch passende, aber wörtlich abweichende Ergebnisse zusätzlich einfließen.

Besonders deutlich zeigt sich der Vorteil bei gemischten Suchanfragen, die sowohl einen konkreten Begriff als auch eine vage Umschreibung enthalten, etwa eine Suche nach Nike Laufschuh leicht und atmungsaktiv. Reine Vektorsuche könnte hier den Markennamen Nike unterschätzen, während reine Textsuche die Umschreibung leicht und atmungsaktiv kaum sinnvoll verarbeiten kann. Hybrid Search liefert in solchen Fällen typischerweise die insgesamt relevanteste Ergebnisliste.

6. rank_window_size und der Einfluss auf Ergebnisqualität

Der Parameter rank_window_size legt fest, wie viele Ergebnisse aus jedem einzelnen Sub-Retriever für die Fusion berücksichtigt werden, bevor die finale, kombinierte Trefferliste zurückgegeben wird. Ein zu kleiner Wert riskiert, dass relevante Dokumente, die in einem der beiden Rankings zwar nicht ganz oben, aber im anderen sehr weit oben stehen, gar nicht erst in die Fusion einfließen, weil sie außerhalb des betrachteten Fensters liegen.

Ein zu großer Wert erhöht dagegen den Rechenaufwand unnötig, ohne die Ergebnisqualität in der Praxis noch spürbar zu verbessern. Ein guter Ausgangspunkt ist ein Vielfaches der tatsächlich angezeigten Trefferanzahl, etwa das Fünf- bis Zehnfache, das anschließend anhand realer Suchanfragen und beobachteter Ergebnisqualität feinjustiert wird.

7. Mehr als zwei Rankings: RRF mit drei oder mehr Retrievern

Der rrf-Retriever ist nicht auf genau zwei Sub-Retriever beschränkt, sondern akzeptiert eine beliebige Liste, wodurch sich beispielsweise ein standard-Retriever für BM25, ein knn-Retriever für Dense-Vector-Suche und zusätzlich ein weiterer Retriever für eine ELSER-basierte Sparse-Vector-Suche in einer einzigen Anfrage kombinieren lassen. Jedes zusätzliche Ranking bringt eine eigene Perspektive auf Relevanz mit, ohne dass eine manuelle Gewichtung zwischen den einzelnen Rankings festgelegt werden muss.

In der Praxis lohnt sich eine Kombination aus drei Rankings vor allem dann, wenn BM25 und Dense-Vector-Suche systematisch unterschiedliche Schwächen zeigen, die sich durch ein drittes, unabhängig funktionierendes Ranking teilweise ausgleichen. Mit steigender Anzahl an Rankings wächst allerdings auch der Rechenaufwand pro Anfrage, weshalb jedes zusätzliche Ranking einen nachweisbaren, gemessenen Mehrwert liefern sollte, statt aus reiner Vorsicht ergänzt zu werden.

GET products/_search
{
  "retriever": {
    "rrf": {
      "retrievers": [
        { "standard": { "query": { "match": { "description": "leiser Standmixer" } } } },
        { "knn": { "field": "description_embedding", "query_vector": ["..."], "k": 20, "num_candidates": 100 } },
        { "standard": { "query": { "sparse_vector": { "field": "description_sparse", "inference_id": ".elser_model_2", "query": "leiser Standmixer" } } } }
      ],
      "rank_constant": 60,
      "rank_window_size": 50
    }
  }
}

8. Alternative: gewichtete lineare Kombination statt RRF

Neben RRF unterstützt Elasticsearch auch eine gewichtete lineare Kombination der normalisierten Scores beider Rankings, bei der jedem Ranking explizit ein Gewicht zugewiesen wird. Dieser Ansatz erlaubt eine feinere, expliziter steuerbare Balance zwischen BM25- und Vektor-Anteil, verlangt aber eine bewusste Entscheidung über die Normalisierungsstrategie und ist empfindlicher gegenüber Ausreißerwerten als RRF.

In der Praxis ist RRF meist der pragmatischere Einstieg, weil es ohne Normalisierungsentscheidung auskommt und robust gegenüber unterschiedlichen Score-Verteilungen ist. Eine gewichtete lineare Kombination lohnt sich dann, wenn nach ersten Erfahrungen mit RRF ein sehr spezifisches, dokumentiertes Bedarf besteht, einen der beiden Rankinganteile gezielt stärker oder schwächer zu gewichten, als es die Rangfusion allein erlaubt.

9. Testing und Monitoring: Hybrid Search messbar bewerten

Der Effekt von Hybrid Search lässt sich nicht allein durch Stichproben verlässlich beurteilen, sondern erfordert einen systematischen Vergleich anhand einer Menge realer Suchanfragen mit bekannten, als relevant markierten Ergebnissen. Metriken wie Normalized Discounted Cumulative Gain oder Mean Reciprocal Rank erlauben es, reine BM25-Suche, reine Vektorsuche und Hybrid Search mit unterschiedlichen rank_constant-Werten objektiv gegeneinander zu vergleichen, statt sich auf subjektive Einzelfallbewertung zu verlassen.

Nach der Produktivnahme lohnt sich fortlaufendes Monitoring der tatsächlichen Klickverhalten und Konversionsraten für Suchanfragen, die über Hybrid Search bedient werden, im Vergleich zu einer Kontrollgruppe mit reiner BM25-Suche, um den tatsächlichen geschäftlichen Nutzen der zusätzlichen Komplexität konkret zu belegen, statt sie rein technisch zu rechtfertigen.

10. Zusammenfassung

11. FAQ: Hybrid Search mit RRF: Das Wichtigste auf einen Blick