BM25 und Vektorsuche: Hybride Suche richtig aufbauen

Dokumentation geprüft am 24. Oktober 2026. Die folgenden Umsetzungshinweise stützen sich auf die aktuelle Dokumentation von Elasticsearch, Weaviate und Pinecone. Die Einstellungen für die Evaluation sind ein vorgeschlagenes Ausgangsprotokoll, keine gemessenen Verbesserungen oder Herstellerbenchmarks.

Wie funktioniert hybride Suche mit BM25?

Bei der hybriden Suche bestimmen sowohl der Wortlaut als auch die Bedeutung, welche Inhalte gefunden werden. In der hier beschriebenen Architektur liefert die Stichwortsuche eine sortierte Trefferliste, die Vektorsuche eine zweite. Ein Fusionsverfahren führt beide zusammen. Die Erläuterung von Weaviate beschreibt diese beiden Suchzweige und ihre Zusammenführung.

Das lässt sich mit zwei Personen vergleichen, die dieselbe Supportfrage recherchieren. Eine sucht in einem Index nach den exakten Namen und Fehlermeldungen. Die andere achtet auf inhaltliche Zusammenhänge und findet auch anders formulierte Antworten. Anschließend werden ihre Auswahllisten zusammengeführt, statt einer Person beide Aufgaben allein zu überlassen.

BM25 ist eine lexikalische Rankingfunktion. Sie bewertet Dokumente anhand der darin enthaltenen Suchbegriffe. In die Bewertung fließen die Häufigkeit der Begriffe und die Dokumentlänge ein; das ist aussagekräftiger als das bloße Zählen übereinstimmender Wörter. Elasticsearch verwendet BM25 standardmäßig zur Bewertung der Textähnlichkeit. Die Similarity-Referenz von Elastic dokumentiert diese Einflussgrößen.

Vektorsuche vergleicht Embeddings, also numerische Repräsentationen von Inhalten, um ähnliche Bedeutungen zu finden. So kann die Anfrage „Ich werde ständig abgemeldet“ zu einem Dokument über ablaufende Sitzungen führen, obwohl der Wortlaut abweicht. Unser Leitfaden zur semantischen Suche erläutert dieses Suchverfahren.

Bei einer Beispielanfrage wie ERR_SESSION_EXPIRED after login sorgt der lexikalische Zweig dafür, dass der exakte Fehlertext in die Ergebnisse gelangen kann. Der semantische Zweig kann Anleitungen zu Authentifizierungssitzungen und deren Erneuerung beisteuern. Die Fusion bestimmt die endgültige Reihenfolge. Das Beispiel beschreibt das beabsichtigte Verhalten; es verspricht keine bestimmte Rangfolge für ein unkonfiguriertes Suchsystem.

Auch hybride Vektorsuche braucht Regeln für exakte Kennungen

Ein lexikalischer Suchzweig garantiert noch keine exakten Treffer für Kennungen. Die Textanalyse, die Zeichenfolgen in durchsuchbare Tokens zerlegt, kann verändern, was im Index landet. Der Standard-Analyzer von Elastic trennt etwa in seinem dokumentierten Beispiel einen Ausdruck mit Bindestrich auf. Deshalb muss geprüft werden, wie der konfigurierte Analyzer mit den eigenen Artikelnummern und Fehlercodes umgeht. Dokumentation zum Standard-Analyzer.

Wenn die genaue Schreibweise festlegt, welcher Eintrag gesucht wird, gehören Kennungen in ein eigenes Feld für exakte Übereinstimmungen. Elastic dokumentiert dafür den Feldtyp keyword. Eine Anfrage nach der fiktiven Artikelnummer AX-BLUE sollte nicht unbemerkt zur Empfehlung von AX-GREEN werden, nur weil sich die Beschreibungen ähneln. Referenz zum Keyword-Feld.

Entscheidungsregel: Eine erkannte, eindeutige Kennung wird direkt und exakt nachgeschlagen, wenn dies zum zugesicherten Produktverhalten gehört. Hybrides Ranking eignet sich für Fragen, die eine Kennung mit einem weitergehenden Anliegen verbinden, etwa der Suche nach einer Anleitung zur Fehlerbehebung für diesen Artikel.

RRF oder gewichtete Scores: Wie lassen sich Treffer zusammenführen?

Reciprocal Rank Fusion eignet sich als Ausgangspunkt, wenn eine Vergleichsbasis benötigt wird, ohne zunächst unterschiedliche Scoreskalen aufeinander abzustimmen. Gewichtete Scores kommen infrage, wenn Relevanzbewertungen zur Abstimmung vorliegen und die Abstände zwischen den Scores erhalten bleiben sollen.

Reciprocal Rank Fusion nutzt die Rangpositionen

Reciprocal Rank Fusion, kurz RRF, addiert für jedes Dokument einen Beitrag aus jeder Liste, in der es vorkommt:

RRF(Dokument) = Summe von 1 / (c + Rang) über die abgerufenen Listen.

Die Rangzählung beginnt bei der ersten Position. Fehlt ein Dokument in einer Liste, liefert diese keinen Beitrag. Gordon V. Cormack, Charles L. A. Clarke und Stefan Büttcher stellten RRF in ihrem SIGIR-Paper von 2009 vor. Für ihre Experimente setzten sie die Konstante auf 60. Im Paper heißt sie k; hier verwenden wir c, um sie nicht mit der Ergebnisanzahl in recall@k zu verwechseln.

RRF ist praktisch, weil ein hoher BM25-Score und ein hoher Vektorscore nicht dasselbe bedeuten müssen. Entscheidend ist allein die jeweilige Position. Die RRF-Implementierung von Pinecone legt ausdrücklich fest, dass die Rangzählung bei eins beginnt und wie fehlende Dokumente behandelt werden.

Eine Konsequenz verdient besondere Aufmerksamkeit. In einem konstruierten Beispiel steht Dokument A in der Stichwortliste an erster Stelle und fehlt in der Vektorliste. Dokument B steht in beiden Listen an zweiter Stelle. Bei c = 60 erhält A den Wert 1/61, B den Wert 2/62. B gewinnt. Das ist eine eigene Rechnung anhand der Formel, kein Suchbenchmark.

Gewichtete Scores erhalten die Bewertungsabstände

Bei der gewichteten Scorefusion werden die Relevanzwerte zusammengeführt, nachdem ihre Skalen vergleichbar gemacht wurden. Eine gängige Form lautet:

Score = alpha × normalisierter Vektorscore + (1 − alpha) × normalisierter Stichwortscore.

Das Gewicht alpha steuert das Verhältnis. Ein Ausgangswert von 0.5 ergibt gleiche Koeffizienten; er belegt weder einen gleichen Nutzen noch eine optimale Einstellung. Normalisierung und Gewichtung sollten gemeinsam dokumentiert werden, denn eine Änderung an einer der beiden kann die Rangfolge verändern.

Der Linear Retriever von Elasticsearch unterstützt eine gewichtete Summe mit Normalisierungsverfahren wie minmax. Die Relative Score Fusion von Weaviate erhält die relativen Abstände innerhalb jeder Trefferliste. Rangbasierte Fusion verwirft diese Abstände dagegen.

RRF dient als erster Vergleichsmaßstab; gewichtete Fusion sollte nur bleiben, wenn zurückgehaltene Testanfragen dafür sprechen. Rohe BM25-Scores dürfen nicht einfach zu Vektorähnlichkeitswerten addiert werden, in der Annahme, die Summe sei aussagekräftig. Auch die Anzahl der berücksichtigten Kandidaten gehört ins Protokoll: Ändert sich, welche Treffer in eine normalisierte Liste eingehen, kann sich deren Wertebereich verschieben.

Wann ist hybride Suche besser als reine Vektorsuche?

Hybride Suche hilft, wenn der lexikalische Zweig relevante Inhalte findet, die der Vektorzweig verfehlt, und die Fusion diese Inhalte weit genug oben hält, damit sie nützlich sind. Das ist eine überprüfbare Bedingung, kein allgemeines Qualitätsversprechen.

Für einen Versuch eignen sich vor allem:

• Supportsuche: Exakte Fehlermeldungen, Funktionsnamen und Begriffe rund um Benutzerkonten treffen auf Beschreibungen von Symptomen.
• Katalogsuche: Genaue Produktnamen oder Artikelnummern werden mit Anforderungen wie Kompatibilität oder Ersatzteilen verbunden.
• Suche in internem Wissen: Projektnamen und Abkürzungen werden mit natürlichsprachlichen Fragen kombiniert.

Die Übersicht zur hybriden Suche von Pinecone nennt Produktcodes, Fehlermeldungen und Namen ausdrücklich als lexikalische Signale, ergänzt durch die bedeutungsbezogene Suche mit dichten Vektoren.

Für das reine Nachschlagen von Kennungen ist zunächst eine zuverlässige Suche nach exakten Übereinstimmungen nötig. Wenn die Vektorsuche den vorhandenen Datenbestand und die Suchanfragen bereits gut abdeckt, sollte ein weiterer Suchzweig erst hinzukommen, sobald ein konkretes Problem bei der Suche nachgewiesen ist.

Die praktische Grenze ist die Abdeckung durch die Kandidatenlisten. Fusion kann nur die Vereinigungsmenge der Dokumente sortieren, die ihre Suchzweige gefunden haben. Findet keiner der beiden die relevante Passage, kann ein anderes Fusionsverfahren sie nicht zurückholen. Ist die Passage vor der Fusion vorhanden, fehlt aber in den endgültigen Ergebnissen, müssen stattdessen Ranking und Kürzung der Ergebnisliste untersucht werden.

Hybride Suche im vorhandenen System ergänzen

Das bestehende System kann bleiben, wenn es die benötigten Suchfunktionen bietet. Wer gleichzeitig die Datenbank und die Suchstrategie wechselt, kann schwerer feststellen, was die Verbesserung bewirkt hat.

Die folgende Gegenüberstellung zeigt, wo die Zusammenführung stattfindet. Sie ist keine Rangliste der Anbieter.

Hybride Suche mit Elasticsearch

Elasticsearch unterstützt als Suchmaschine sowohl Text- als auch Vektorsuche. Ein Text-Retriever vom Typ standard und ein Vektor-Retriever vom Typ knn lassen sich einem rrf-Retriever unterordnen. Die offizielle Referenz zum RRF-Retriever beschreibt diesen Aufbau und sein Kandidatenfenster.

In einem bestehenden Index sollten der durchsuchbare Text und sein Embedding unter derselben Dokument-ID liegen. Beide Suchzweige müssen dieselbe Menge zulässiger Inhalte durchsuchen, bevor die Fusion erfolgt. Einschränkungen nach Mandant, Berechtigung und Produktversion müssen in beiden Zweigen übereinstimmen.

Die folgende Anfrage lässt sich ausführen, sobald ES_URL und ES_API_KEY gesetzt sind. Sie setzt einen vorhandenen Index namens docs, ein Textfeld namens text, ein Feld für dichte Vektoren namens embedding sowie eine Datei query-vector.json mit dem tatsächlichen Embedding-Array der Suchanfrage voraus. Dieses Array muss mit demselben Modell erzeugt werden, das auch für die indexierten Dokumente verwendet wurde. Der Befehl benötigt jq und curl.

jq -n --slurpfile v query-vector.json \
  --arg q 'ERR_SESSION_EXPIRED after login' \
  '{
    size: 10,
    retriever: {
      rrf: {
        retrievers: [
          {standard: {query: {match: {text: $q}}}},
          {knn: {
            field: "embedding",
            query_vector: $v[0],
            k: 50,
            num_candidates: 100
          }}
        ],
        rank_window_size: 50,
        rank_constant: 60
      }
    }
  }' > hybrid-request.json

curl --fail-with-body "$ES_URL/docs/_search" \
  -H "Authorization: ApiKey $ES_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @hybrid-request.json

Die Einstellungen dienen als Beispiel für eine Evaluation. size legt die endgültige Trefferzahl fest; rank_window_size bestimmt, wie viele Treffer jedes untergeordneten Retrievers an der Fusion teilnehmen können. In einer Anwendung mit Zugriffsregeln darf dieses ungefilterte Beispiel erst verwendet werden, wenn die entsprechenden Einschränkungen ergänzt wurden. Elastic dokumentiert einen übergeordneten filter, der gemäß den jeweiligen Spezifikationen auf die untergeordneten Retriever angewendet wird.

Die Grenze: Ein zu kleines Kandidatenfenster kann genau den Treffer verwerfen, den die hybride Suche eigentlich zurückholen sollte. Deshalb werden zunächst die Kandidaten der Suchzweige mit den endgültigen Ergebnissen verglichen, bevor das Fusionsverfahren abgestimmt wird. Beim Wechsel zum Linear Retriever müssen Normalisierung und Gewichte gemeinsam konfiguriert werden.

Hybride Suche mit Weaviate

Weaviate bietet als Datenbank Text- und Vektorsuche an und stellt die hybride Suche über collection.query.hybrid bereit. Die lexikalische Komponente ist BM25F, also die Variante für mehrere Felder. Die Dokumentation zu hybriden Suchanfragen behandelt durchsuchbare Eigenschaften, die Auswahl des Fusionsverfahrens und Erläuterungen zu den Scores.

query_properties sollte auf Felder verweisen, die aussagekräftige lexikalische Hinweise enthalten, etwa Titel, Fehlertexte und Produktnamen. Erzeugt die Anwendung ihre Embeddings selbst, wird der Anfragevektor mitgegeben; andernfalls kann die konfigurierte Vektorisierung der Collection verwendet werden. Beim Vergleich verschiedener Fusionsverfahren wird fusion_type ausdrücklich gesetzt. explain_score hilft bei der Diagnose, warum ein Treffer seine Position verändert hat.

Auch alpha sollte ausdrücklich gesetzt werden: 0 wählt die Stichwortsuche, 1 die Vektorsuche. Die aktuelle Dokumentation weist darauf hin, dass die wirksame Gewichtung bei weggelassenem Parameter vom Client abhängt. Das Standardverfahren ist relativeScoreFusion; rankedFusion steht ebenfalls zur Verfügung. Referenz zu den Fusionsverfahren von Weaviate.

Die Grenze: Ein Gewicht kann weder ein fehlendes durchsuchbares Feld noch ein beschädigtes Kennungstoken reparieren. Bevor das Embedding-Modell infrage gestellt wird, sollte der lexikalische Beitrag untersucht werden. Die beiden Endpunkte des Gewichtsbereichs, reine Vektorsuche und reine Stichwortsuche, dienen als diagnostische Vergleichsbasis. Anschließend wird die Kombination bewertet.

Hybride Suche mit Pinecone

Die Retrieval-Datenbank Pinecone dokumentiert unterschiedliche hybride Ansätze. Vor dem Übernehmen eines Beispiels muss der Ansatz feststehen: Die serverseitige Kombination dichter und dünn besetzter Vektoren und clientseitige RRF sind unterschiedliche Implementierungen. Übersicht zur hybriden Suche von Pinecone.

Für BM25 plus Suche mit dichten Vektoren führt der Ansatz über die Documents API eine Volltextsuche und eine Suche mit dichten Vektoren aus. Ihre sortierten Dokument-IDs werden anschließend in der Anwendung per RRF zusammengeführt. Der RRF-Leitfaden von Pinecone enthält diese clientseitige Implementierung.

Für die native Kombination dichter und dünn besetzter Vektoren kann die Vectors API beide Repräsentationen pro Datensatz speichern und in einer einzigen Anfrage zusammenführen. Der Leitfaden für einen gemeinsamen Index verlangt vector_type="dense" und metric="dotproduct". Der Client skaliert die Anfragevektoren, um ihren relativen Einfluss festzulegen.

Ein dünn besetzter Vektor ist eine Repräsentation und kein Beleg dafür, dass er mit BM25 erzeugt wurde. Das lexikalische Modell beziehungsweise das Bewertungsverfahren der Volltextsuche muss in der Architekturdokumentation ausdrücklich benannt bleiben.

Die Grenze: Ein Stichwortfilter mit anschließendem Vektorranking ist etwas anderes als ein Ranking, das beide Signale berücksichtigt. Ein Filter entfernt Kandidaten; einen bereits ausgeschlossenen Synonymtreffer kann er nicht zurückholen. Filter eignen sich für zwingende Bedingungen. Fusion ist angebracht, wenn beide Suchzweige eigenständig Treffer beisteuern können sollen.

Welche Rolle spielt Hybrid Search bei RAG?

Hybride Suche verändert die Retrieval-Stufe von Retrieval-Augmented Generation, kurz RAG. Dabei stellt eine Anwendung einem Sprachmodell abgerufene Quelleninhalte bereit, bevor es antwortet. Die hybride Suche ersetzt weder die Antwortgenerierung noch belegt sie, dass die Antwort korrekt ist.

Die abgerufene Einheit muss in beiden Suchzweigen gleich behandelt werden. Liefert der lexikalische Zweig ganze Dokumente und der Vektorzweig einzelne Passagen, muss vor der Fusion geklärt sein, wie ihre IDs einander zugeordnet werden. Sonst können mehrere Passagen derselben Quelle die Auswahlliste belegen, während andere relevante Quellen verschwinden. Unser Erklärartikel zu Vektordatenbanken behandelt die Grundlagen von Speicherung und Suche.

Agentic RAG ergänzt Entscheidungen darüber, welche Suchaktion ausgeführt oder ob erneut gesucht werden soll. Ein hybrider Retriever kann eine dieser Aktionen sein. Übersieht ein Supportbot einen exakten Fehlercode, sollte zunächst dieser Retriever repariert und evaluiert werden, bevor weitere Orchestrierung hinzukommt.

Während des Vergleichs der Suchverfahren bleiben das generierende Modell und der Prompt unverändert. Verbessert sich die Gruppe der Anfragen mit exakten Begriffen, während Paraphrasen weiterhin schwach abschneiden, lassen sich mit denselben bewerteten Anfragen verschiedene Embedding-Modelle vergleichen. Wer Embedding, Aufteilung in Textabschnitte und Fusion gleichzeitig verändert, kann das Ergebnis keiner einzelnen Änderung mehr zuordnen.

Recall@k vor und nach der Umstellung messen

Ein kleiner Suchanfragensatz mit Relevanzbewertungen dient dazu, reine Stichwortsuche, reine Vektorsuche und hybride Suche anhand derselben erwarteten Treffer zu vergleichen. Eine flüssig formulierte Antwort ist keine Kennzahl für die Qualität der Suche.

Recall@k = relevante IDs unter den ersten k Treffern ÷ alle als relevant bewerteten IDs dieser Anfrage. Der Mittelwert der einzelnen Anfragewerte ergibt den Makro-Recall@k. Bei unvollständigen Bewertungen beschreibt das Ergebnis nur den Recall bezogen auf die bekannten Relevanzurteile. Es belegt nicht, welcher Anteil aller relevanten Inhalte im gesamten Datenbestand gefunden wurde.

Recall lokal auswerten

Der folgende Code wird als evaluate_recall.py gespeichert. Er verwendet ausschließlich die Standardbibliothek von Python 3. qrels.jsonl enthält pro Anfrage ein JSON-Objekt mit den Feldern qid, slice und relevant. Jede Ergebnisdatei ordnet einer Anfrage-ID die sortierte Liste der zurückgegebenen IDs zu.

Ein Bewertungsdatensatz könnte beispielsweise {"qid":"q-exact","slice":"exact","relevant":["guide-login"]} lauten. Eine Ergebnisdatei könnte {"q-exact":["guide-reset","guide-login"]} enthalten. Diese Beispiele veranschaulichen das Format; sie sind keine Suchergebnisse aus einem getesteten System. Jede bewertete Anfrage muss in jeder Ergebnisdatei enthalten sein. Hat die Suche nichts geliefert, wird eine leere Liste verwendet.

import json
import sys
from collections import defaultdict
from statistics import mean

qrels_path, bm25_path, vector_path, hybrid_path, cutoff = sys.argv[1:]
k = int(cutoff)
if k < 1:
    raise ValueError("k must be positive")

with open(qrels_path, encoding="utf-8") as f:
    labels = [json.loads(line) for line in f if line.strip()]
if not labels or len({r["qid"] for r in labels}) != len(labels):
    raise ValueError("Labels must be nonempty with unique query IDs")

runs = {}
for name, path in (("bm25", bm25_path), ("vector", vector_path),
                   ("hybrid", hybrid_path)):
    with open(path, encoding="utf-8") as f:
        runs[name] = json.load(f)
    missing = {r["qid"] for r in labels} - runs[name].keys()
    if missing:
        raise ValueError(f"{name} is missing query IDs: {sorted(missing)}")

groups = defaultdict(list)
skipped = 0
for row in labels:
    relevant = set(row["relevant"])
    if not relevant:
        skipped += 1
        continue
    scores = {}
    for name, run in runs.items():
        unique_ids = list(dict.fromkeys(run[row["qid"]]))
        scores[name] = len(relevant & set(unique_ids[:k])) / len(relevant)
    groups["overall"].append(scores)
    groups["slice:" + row["slice"]].append(scores)

if not groups:
    raise ValueError("No answerable queries to score")
for group, rows in sorted(groups.items()):
    values = {name: mean(r[name] for r in rows) for name in runs}
    delta = values["hybrid"] - values["vector"]
    report = " ".join(f"{name}={v:.3f}" for name, v in values.items())
    print(f"{group} n={len(rows)} recall@{k} {report} delta={delta:+.3f}")
print(f"Excluded no-answer queries: {skipped}")

Die Auswertung wird mit den zurückgehaltenen Bewertungen und den exportierten Ergebnissen ausgeführt:

python3 evaluate_recall.py qrels.jsonl bm25.json vector.json hybrid.json 10

Das Skript entfernt doppelte IDs, bevor es die Ergebnisliste auf die vorgegebene Anzahl begrenzt. Dieselbe Behandlung von Duplikaten muss auch in der Anwendung gelten. Die Ausgabe zeigt die Veränderung der hybriden Suche gegenüber der Vektorsuche und zusätzlich die Stichwortsuche als Vergleichsbasis. So fällt ein leistungsfähiges lexikalisches System nicht aus dem Vergleich heraus.

Die Umstellung ist bereit für den Produktiveinsatz, wenn sich die relevanten Anfragegruppen verbessern und die Rückschritte mit den Produktanforderungen vereinbar sind. Werden die Kandidaten besser, der endgültige Recall aber nicht, müssen Fusion oder Ergebnisgrenze angepasst werden. Verbessert sich der endgültige Recall, werden anschließend die Trefferreihenfolge, die Korrektheit generierter Antworten und die Gesamtlatenz separat geprüft. Keine dieser Eigenschaften wird durch Recall mitgemessen.

Was ist übertrieben, und was ist als Nächstes sinnvoll?

„Hybride Suche vereint das Beste aus beiden Welten“ verdeckt die eigentliche technische Entscheidung. Sie kann mehr relevante Inhalte erfassen, lässt aber zugleich einen weiteren Suchzweig die endgültige Liste beeinflussen. RRF kann einen exakten Treffer nach unten verschieben. Gewichtete Fusion kann ein Signal aufgrund seiner Scoreskala oder Normalisierung bevorzugen. Fehlende Quelleninhalte kann keines der Verfahren ersetzen.

Entwicklungsteams sollten jetzt handeln, wenn die Prüfung zeigt, dass relevante Dokumente mit exakten Suchbegriffen in den Vektorkandidaten fehlen. Der lexikalische Zweig wird ergänzt, Dokument-IDs und Berechtigungen werden konsistent gehalten und der Vergleich mit Relevanzbewertungen wird durchgeführt.

Für den Betrieb Verantwortliche sollten mit der Einführung warten, wenn das eigentliche Problem veraltete Inhalte, fehlende Berechtigungen oder fehlende Relevanzbewertungen sind. Zuerst werden diese Voraussetzungen geschaffen, danach die Suchstrategien verglichen.

Für Teams mit zuverlässiger Kennungssuche ändert sich zunächst nichts, solange sie keine breitere Suche benötigen. Der bewährte Weg zum exakten Treffer bleibt bestehen; hybride Suche wird für natürlichsprachliche Fragen separat evaluiert.

Der konkrete nächste Schritt für Montag: fehlgeschlagene Suchanfragen sammeln, die erwarteten Quellen als relevant markieren und den vorhandenen Vektor-Retriever neben einer Stichwortsuche als Vergleichsbasis laufen lassen. Die Fusion kommt hinzu, sobald sichtbar ist, was jeder Zweig beiträgt. Behalten wird die Konfiguration, die sich bei den zurückgehaltenen Anfragen bewährt.

Häufige Fragen

Praxisleitfäden zur Softwareentwicklung im Newsletter erhalten.