Hybride Suche: BM25 + vectoriel

#Warum rein vektorbasierte Suche bei manchen Fragen scheitert

Die Vektorsuche wandelt jede Textpassage in einen Vektor um, der ihren allgemeinen Sinn zusammenfasst, und gibt dann die Passagen zurück, deren Vektoren dem Vektor der Frage am nächsten liegen. Diese Kompression funktioniert sehr gut bei Paraphrasen, aber schlecht bei allem, was wortgetreu gefunden werden muss: einer Kennung, einem Fehlercode, einem Personennamen, einem internen Kürzel. Beim Embedding ähneln sich „PROD-4817“ und „PROD-4871“, sodass ein unpassendes Ticket vor dem richtigen erscheinen kann. Die hybride Suche begegnet diesem Problem: Sie ergänzt eine zweite Rangfolge, die auf dem exakten Vorkommen der Wörter beruht, und führt beide zusammen, sodass jede Methode die blinden Flecken der anderen ausgleicht.

Identifikatoren und Referenzen

Ticketnummern, Aktennummern, Vertragsnummern, SKU, Fehlercodes: Sie sind Zeichenketten, die ein Embedding nicht zuverlässig speichert und die BM25 sofort wiederfindet, sobald sie im Abschnitt vorkommen.

Seltene Fachbegriffe

Seltene medizinische, juristische oder technische Begriffe: Ein seltenes Wort hat in BM25 ein hohes Gewicht, während sein Embedding unscharf sein kann.

Sehr kurze Anfragen

Zwei Wörter wie „Rechnung 2024“ liefern wenig Material für ein Embedding; Schlüsselwörter hingegen werden unverändert miteinander verglichen.

Paraphrasen und Umformulierungen

Der umgekehrte Fall: „befristeter Arbeitsvertrag“ und „CDD“ oder „Auto“ und „Automobil“ haben kein Wort gemeinsam; nur die Vektorsuche stellt eine Verbindung zwischen ihnen her.

#BM25: Was die Stichwortsuche leistet

BM25 ist die lexikalische Rankingfunktion, die Lucene, Elasticsearch und OpenSearch verwenden und die SQLite in seinem FTS5-Modul anbietet (die Dokumentation beschreibt die Funktion bm25() als eine Funktion, die einen Wert zurückgibt, der angibt, wie gut die Zeile zur Suchanfrage passt). Sie beruht auf drei Ideen: Ein seltenes Wort hat mehr Gewicht als ein häufiges, ein wiederholtes Wort zählt ab einer bestimmten Anzahl von Vorkommen immer weniger, und eine lange Passage wird gegenüber einer kurzen leicht benachteiligt. Der Parameter k1 steuert diese Sättigung: Laut der Beschreibung von Elastic begrenzt er den Einfluss, den ein einzelner Begriff der Suchanfrage auf den Score eines Dokuments haben kann.

Stärken

Seltene Begriffe, Kennungen, kurze Suchanfragen, Fachvokabular, kein Modell, das geladen oder trainiert werden muss, kompakter Index, nachvollziehbares Ergebnis (man weiß, welches Wort den betreffenden Abschnitt in den Suchergebnissen nach oben gebracht hat).

Schwächen

Synonyme, Umformulierungen, Paraphrasen, Tippfehler; ohne Lemmatisierung sind „signé“ und „signature“ zwei verschiedene Wörter.

Voraussetzungen

Eine sorgfältige Tokenisierung: Umwandlung in Kleinbuchstaben, Entfernung von Akzenten, gegebenenfalls Stammformreduktion (Stemming). Genau hier machen die meisten selbst entwickelten Implementierungen Fehler, siehe unten.

#Hybride Suche: das Prinzip

Beide Suchen werden für dieselbe Frage ausgeführt. Jede liefert ihre Liste von Kandidaten (20 bis 50 Passagen), anschließend werden die beiden Listen zu einer einzigen Rangliste zusammengeführt. Der Vorteil ergibt sich aus einer einfachen Beobachtung: Passagen, die in beiden Listen erscheinen, sind fast immer relevant, und jede Methode liefert zusätzlich Passagen, die die andere übersehen hat. Weaviate definiert die hybride Suche so: Sie kombiniert die Ergebnisse einer Vektorsuche und einer Stichwortsuche, indem sie die beiden Ergebnismengen zusammenführt, wobei sich die Fusionsmethode und die relativen Gewichtungen konfigurieren lassen. Der messbare Vorteil hängt vom Korpus und den Fragen ab: Keine allgemeine Zahl ist verlässlich, und Sie müssen den Vorteil anhand Ihrer eigenen Dokumente messen (siehe unten).

#Ohne Normalisierung fusionieren: Reciprocal Rank Fusion

Der klassische Fehler besteht darin, die Rohwerte der Scores zu addieren. Ein BM25-Score ist eine positive Zahl ohne obere Grenze; ein Score für Vektorähnlichkeit ist eine Distanz oder ein Kosinuswert in einem begrenzten Wertebereich: Die beiden Skalen sind nicht vergleichbar, und schon die kleinste Änderung am Korpus verschiebt sie. Reciprocal Rank Fusion umgeht das Problem, indem sie ausschließlich die Rangpositionen verwendet. Die Elasticsearch-Dokumentation beschreibt sie als eine Methode, die keinerlei Abstimmung erfordert und deren Relevanzmaße nicht miteinander in Beziehung stehen müssen.

score(doc) = somme, sur chaque liste i où le doc apparaît, de 1 / (k + rang_i(doc))

k = 60 par défaut (valeur par défaut d'Elasticsearch)
rang_i = 1 pour le premier de la liste, 2 pour le deuxième, etc.
Un doc absent d'une liste n'ajoute rien pour cette liste.

Eine Textpassage, die bei BM25 auf Platz eins und bei der Vektorsuche auf Platz fünf steht, erhält 1/61 + 1/65, also etwa 0,0318; eine Textpassage auf Platz fünfzehn in beiden Listen erhält 2/75, also etwa 0,0267. Die Konstante k schwächt den Vorteil des allerersten Rangs ab: Je größer sie ist, desto stärker zählen weiter hinten liegende Ränge. Elasticsearch dokumentiert diese Konstante unter dem Namen rank_constant mit einem Standardwert von 60 sowie eine Fenstergröße (rank_window_size), die die Länge jeder Liste vor der Zusammenführung festlegt. Ein größeres Fenster verbessert die Relevanz auf Kosten der Performance, erläutert die Dokumentation.

#Und die Score-Fusion?

Einige Suchsysteme bieten eine Alternative: die Scores jeder Liste normalisieren und anschließend gewichtet zusammenführen. Weaviate dokumentiert beide Methoden, eine rangbasierte Zusammenführung und eine Zusammenführung anhand relativer Scores. Letztere ist seit Version 1.24 die Standardmethode; sie ist erforderlich, um autocut mit dem Hybridoperator zu verwenden. Qdrant bietet RRF und DBSF an. Letztere behält die Rohscores bei, normalisiert jedoch vor der Zusammenführung deren Verteilung (Mittelwert und Standardabweichung). Die rangbasierte Zusammenführung ist robuster, wenn die Verteilung der Scores unbekannt ist; die Zusammenführung anhand von Scores ermöglicht eine feinere Abstimmung, wenn Messungen möglich sind.

#Welches Tool: Suchmaschinen mit nativer Unterstützung für hybride Suche

Der grundlegende Unterschied liegt nicht in der Zusammenführung selbst, die sich mit wenigen Codezeilen umsetzen lässt, sondern im Index: Eine Suchengine mit nativer Unterstützung hält beide Indizes gemeinsam aktuell, während eine selbst gebaute Lösung den BM25-Index im Arbeitsspeicher hält und ihn bei jedem neu hinzugefügten Dokument neu aufbauen muss. Für ein Korpus mit einigen Tausend Textabschnitten, das sich selten ändert, reicht die selbst gebaute Lösung völlig aus. Bei größeren Korpora oder sobald sich die Dokumente täglich ändern, vermeidet eine Suchengine mit nativer Unterstützung Inkonsistenzen zwischen den beiden Indizes. Die Anleitung zu Weaviate stellt dieses Tool ausführlich vor.

#Eigenentwicklung: ChromaDB, rank_bm25 und RRF

Der folgende Code kombiniert die drei Bausteine. Er behebt einen häufigen Fehler in Beispielen: Die Normalisierungsfunktion muss vor dem Filtern die diakritischen Zeichen entfernen, sonst teilt jeder akzentuierte Buchstabe ein Wort in zwei Teile.

import re, unicodedata
import chromadb
from rank_bm25 import BM25Okapi

def normalize(txt):
    txt = unicodedata.normalize("NFKD", txt.lower())
    txt = "".join(c for c in txt if not unicodedata.combining(c))  # retire les accents
    return re.findall(r"[a-z0-9]+", txt)

# Indexation BM25 (en mémoire) : l'indice de la liste = l'identifiant du passage
all_docs = [d["text"] for d in load_docs()]
bm25 = BM25Okapi([normalize(d) for d in all_docs])

# ChromaDB : les ids doivent être les mêmes, sous forme de chaînes "0", "1", ...
coll = chromadb.PersistentClient("./chroma_db").get_collection("docs")

def rrf_fuse(rankings, weights=None, k=60):
    weights = weights or [1.0] * len(rankings)
    scores = {}
    for ranking, w in zip(rankings, weights):
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + w / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

def hybrid_search(question, top_k=5, n_candidates=20):
    s = bm25.get_scores(normalize(question))
    bm25_top = sorted(range(len(all_docs)), key=lambda i: -s[i])[:n_candidates]
    bm25_ranking = [str(i) for i in bm25_top]
    vec_ranking = coll.query(query_texts=[question], n_results=n_candidates)["ids"][0]
    fused = rrf_fuse([bm25_ranking, vec_ranking])
    return [all_docs[int(i)] for i in fused[:top_k]]

Zwei praktische Vorsichtsmaßnahmen. Erstens müssen die Kennungen in beiden Indizes identisch sein: Hier dient der Listenindex, in eine Zeichenkette umgewandelt, als Chroma-Kennung. Zweitens geht der BM25-Index im Arbeitsspeicher beim Beenden des Programms verloren: Bauen Sie ihn beim Start neu auf, was bei Zehntausenden von Textpassagen einige Sekunden dauert, oder speichern Sie die Dokumentenliste neben der Datenbank.

#Das Verhältnis zwischen BM25 und Vektorsuche einstellen

Standardmäßig gewichtet RRF beide Listen gleich. Wenn Ihr Korpus viele Referenzen enthält (Rechtsprechung, Tickets, Kataloge), geben Sie BM25 mehr Gewicht; wenn die Fragen dialogorientiert sind, behalten Sie die gleiche Gewichtung bei oder bevorzugen Sie die Vektorsuche. In der vorherigen Funktion genügt es, weights=[0.6, 0.4] zu übergeben, um BM25 mit 60 % zu gewichten. Qdrant ermöglicht dieselbe Einstellung: Laut Dokumentation beträgt das Gewicht jeder Abfrage standardmäßig 1, wodurch sich wieder die ursprüngliche RRF-Formel ergibt, und die Konstante k lässt sich in neueren Versionen einstellen. In Weaviate stellt man alpha ein: 1 entspricht einer reinen Vektorsuche, 0 einer reinen Schlüsselwortsuche.

#Nach der Fusion: Reranker hinzufügen

Die Fusion liefert eine vielfältigere Kandidatenmenge als jede Methode allein. Ein Reranker kann diese Menge anschließend sortieren, indem er jeden Abschnitt zusammen mit der Frage liest: Die beiden Techniken lassen sich kombinieren. Der übliche Ablauf ist die hybride Suche, dann die Fusion, dann ein Reranker für die ersten 20 bis 50 Ergebnisse und schließlich die Aufnahme der 3 bis 5 besten Abschnitte in den Prompt. Der Leitfaden zum Reranker erläutert diesen letzten Schritt im Detail, und der Leitfaden zum Chunking erklärt, warum die Länge der Abschnitte sowohl BM25 als auch die Embeddings so stark beeinflusst.

#Häufige Fragen zu hybrider Suche

• Einen Reranker in die Pipeline integrieren
• Chunking-Strategien
• Weaviate: hybride Suche und Mandantenfähigkeit
• Lokales RAG mit ChromaDB und Ollama
• Die besten Embedding-Modelle für Französisch

• Quelle: Qdrant, hybride Abfragen
• Quelle: Weaviate, hybride Suche
• Quelle: Elasticsearch, Reciprocal Rank Fusion
• Quelle: SQLite FTS5, Funktion bm25()