Hybride Suche: Wann BM25 mit Vektoren kombinieren

Ein Unternehmen implementiert einen RAG-Assistenten auf Basis von Produktdokumentationen und entdeckt nach einer Woche Pilotbetrieb ein Problem: Abfragen mit SKU-Codes, Ersatzteilnummern oder internen Systemnamen (z. B. „Modul INTAKE-3B“) liefern semantisch ähnliche, aber nicht die richtigen Dokumente. Die Vektorsuche „versteht die Intention“, verliert jedoch die Identifikatoren. Kunden des Service erhalten die Beschreibung eines ähnlichen Produkts statt des technischen Datenblatts des konkreten. Das ist einer der häufigsten Gründe, warum RAG in der Demo gut funktioniert, in der Produktion jedoch schlechter abschneidet.

Semantische Suche funktioniert nach dem Prinzip der Bedeutungsgeometrie: Das Embedding-Modell wandelt Text in einen Vektor um und sucht nach Dokumenten mit ähnlicher Repräsentation. Die Stärke dieser Methode ist zugleich ihre Schwäche: Das Modell mittelt die Bedeutung, komprimiert die Information und verliert lexikalische Präzision.

Drei konkrete Abfrageklassen, bei denen Semantik regelmäßig versagt:

Codes und Identifikatoren. SKU-4521, P/N 7742-A, Bestellnummer ZAM-2024-08811 – das sind Zeichenfolgen ohne semantischen Kontext. Embedding behandelt sie als Rauschen und weist ihnen Vektoren nahe Dokumenten mit allgemeiner Produktthematik zu, statt das Dokument mit exaktem Match zurückzugeben.

Branchenakronyme und Abkürzungen. „IFRS 17“, „KSeF“, „CMMS“ – das Modell hat möglicherweise keinen guten Kontext für seltene, insbesondere polnische, Fachabkürzungen. Es liefert Dokumente zu Finanzen oder Instandhaltungssystemen, aber nicht den konkreten Standard.

Eigennamen und Versionen. „Comarch ERP XL 2024.2.1“ vs. „Comarch ERP Optima“ – für Embedding sind das nahe Nachbarn. Für den Nutzer sind es unterschiedliche Produkte. Die Verwechslung von Versionen in der Antwort erzeugt reale operative Fehler.

BM25 (Best Match 25) löst diese Fälle anders: Es zählt die Häufigkeit des Terms im Dokument, normalisiert sie in Bezug auf die Dokumentlänge und fördert Ergebnisse, in denen die abgefragten Token wörtlich vorkommen. Für den Code SKU-4521 gibt BM25 das Dokument mit dieser Zeichenfolge an erster Stelle zurück. Für eine allgemeine Frage wie „Wie konfiguriere ich die Integration?“ schneidet Semantik besser ab, weil der Nutzer die Intention beschreibt, nicht einen Identifikator.

Reciprocal Rank Fusion ist ein Algorithmus zur Zusammenführung von Rankings aus unabhängigen Suchmaschinen. Die Formel für das Ergebnis eines Dokuments d ist einfach:

RRF(d) = Σ 1 / (k + rank_i(d))

wobei k eine Glättungskonstante (Standardwert 60) ist und rank_i(d) die Position des Dokuments im i-ten Ranking darstellt. Ein Dokument auf Position 1 in beiden Engines erhält den Wert 1/(60+1) + 1/(60+1) ≈ 0,033. Ein Dokument auf Position 1 in BM25, aber 50 in der Semantik, erhält 1/61 + 1/110 ≈ 0,025. Die Fusion belohnt Konsistenz: Wenn beide Engines übereinstimmen, dass ein Dokument relevant ist, landet es weit oben. Wenn nur eine es anzeigt, hat es trotzdem eine Chance, allerdings mit niedrigerem Ergebnis.

Der Vorteil von RRF gegenüber einer gewichteten Punktsumme: Es müssen keine Ergebnisse von BM25 (ganze Zahlen, abhängig vom Korpus) und von Cosine Similarity (Zahlen im Bereich [-1, 1]) normalisiert werden. RRF arbeitet ausschließlich mit Positionen, daher spielen Skalen keine Rolle. Das ist besonders wichtig bei dynamischen Korpora, bei denen sich die Ergebnisbereiche von BM25 mit dem Wachstum der Dokumentenbasis ändern.

Nach der RRF-Fusion lohnt es sich, eine Reranking-Stufe hinzuzufügen: Ein Cross-Encoder-Modell bewertet jeden Kandidaten im Kontext der gesamten Abfrage. Der Reranker verbessert die Präzision bei komplexen, mehrteiligen Fragen. Mehr zur Reranking-Architektur im Artikel über Suchqualität in RAG.

Die Implementierung der hybriden Suche in einem bestehenden RAG-Stack erfordert einige präzise Schritte. Wir gehen von Qdrant als Vektordatenbank und Elasticsearch oder PostgreSQL mit pg_trgm / tsvector als BM25-Engine aus.

Schritt 1: Korpus doppelt indizieren. Derselbe Text wird in die Vektordatenbank (Embeddings BGE-M3 oder ein anderes Modell) und in den Volltextindex aufgenommen. Beide Indizes müssen dieselben Dokumenten-IDs verwenden, damit die Fusion die Ergebnisse nach Schlüssel zusammenführen kann.

Schritt 2: Beide Abfragen parallel ausführen. Für jede Nutzerabfrage sende sie gleichzeitig an den semantischen Engine (top-k=50-100 Kandidaten) und an BM25 (top-k=50-100). Begrenze die Anzahl der Kandidaten, da der Reranker in der nächsten Stufe ein begrenztes Token-Budget hat.

Schritt 3: RRF-Fusion. Führe die beiden Kandidatenlisten durch RRF zusammen. Beginne mit k=60 (Standardwert). Wenn die Abfragen in Ihrem System hauptsächlich lexikalisch sind (viele Codes und SKUs), senke k auf 20-30, um den Einfluss eines starken Leaders in einem Ranking zu verstärken. Experimentiere mit einem Golden Set von mindestens 100 Abfragen mit erwarteten Antworten.

Schritt 4: Reranker (optional, aber empfohlen). Übergebe die Top-20 aus RRF an ein Cross-Encoder-Modell (z. B. bge-reranker-v2-m3 lokal). Der Reranker bewertet jedes Paar (Abfrage, Fragment) und liefert ein präzises Ergebnis. Die Latenz steigt um 100-300 ms, aber die Präzision bei komplexen Abfragen verbessert sich um 10-20 MAP-Punkte.

Die Konfiguration des optimalen Technologie-Stacks lohnt sich mit dem Stack-Auswahl-Tool, das die Korpusgröße, Latenzanforderungen und Hosting-Umgebung berücksichtigt.

Hybrid ist nicht kostenlos. Zwei Abfragen statt einer, Fusion, optionaler Reranker: Die Gesamtlatenz des Systems steigt um 80-200 ms (Schätzung abhängig von Hardware und Kandidatengröße). In Systemen, die Antworten unter 200 ms End-to-End erfordern (z. B. Live-Chat mit Kunden), kann das zu viel sein.

Setzen Sie keine Hybridlösung ein, wenn:

• Der Korpus homogen und beschreibend ist (z. B. nur FAQ in Umgangssprache) – reine Semantik reicht aus.
• Alle Abfragen konzeptionell sind und die Datenbank keine Identifikatoren enthält.
• Sie weniger als 1000 Dokumente haben und reine Semantik einen Recall über 0,9 auf dem Golden Set liefert.
• Die Latenz eine harte Anforderung ist und keine Möglichkeit zum Caching der Ergebnisse besteht.

Eine gute Praxis ist die Messung von recall@5 und recall@10 separat für BM25, für Semantik und für Hybrid auf einem repräsentativen Golden Set vor der Entscheidung. Mehr zum Aufbau eines Golden Sets und zur Qualitätsmessung im Artikel über Evaluierung der RAG-Antwortqualität.

Nicht unbedingt. Wenn Sie bereits PostgreSQL verwenden, können Sie BM25 über die integrierten tsvector und ts_rank aktivieren – ohne zusätzliche Infrastruktur. Elasticsearch oder OpenSearch bieten mehr Tuning-Optionen (Field Boosting, Custom Tokenizer für Produktcodes), aber für kleine und mittlere Korpora (bis zu einigen hunderttausend Dokumenten) reicht PostgreSQL BM25 völlig aus. Qdrant ab Version 1.10 unterstützt Sparse Vector Search (SPLADE), das funktional an BM25 heranreicht.

Mit RRF können Sie die „Gewichtung“ nicht direkt anpassen – der Algorithmus arbeitet mit Positionen. Sie können jedoch die Anzahl der Kandidaten aus jeder Engine (top-k) regulieren oder eine gewichtete Fusion mit normalisierten Ergebnissen (lineare Interpolation) verwenden, wobei der Parameter alpha den Anteil der Semantik bestimmt. Beginnen Sie mit alpha=0,5 (gleicher Anteil) und experimentieren Sie mit dem Golden Set. Typische Erkenntnisse aus Implementierungen: Bei vielen Codes und SKUs verbessert alpha=0,3 (stärkeres BM25) die Ergebnisse, bei beschreibenden Texten schneidet alpha=0,7 mit Semantik besser ab.

Ja, vorausgesetzt, Sie verwenden ein mehrsprachiges Embedding-Modell (BGE-M3 unterstützt über 100 Sprachen) und einen BM25-Tokenizer, der die Morphologie der jeweiligen Sprache unterstützt. Im Polnischen ist Lemmatisierung vor der BM25-Indizierung wichtig (z. B. durch Morfologik oder Stemmers), da „zamówień“, „zamówieniu“, „zamówienie“ nach der Lemmatisierung dasselbe Token sind. Ohne Lemmatisierung sinkt der BM25-Recall bei polnischen Abfragen um 20-40 %.

Ein Reranker ist besonders wertvoll bei mehrteiligen Abfragen und Fragen, die das Verständnis des gesamten Kontexts erfordern (z. B. „Wie ist das Rückgabeverfahren für im Dezember 2024 im Angebot gekaufte Ware für B2B-Kunden?“). RRF fusioniert das Ranking-Signal, versteht aber die Abfrage nicht ganzheitlich. Ein Cross-Encoder bewertet jedes Paar (Abfrage, Fragment) unabhängig und erkennt subtile Übereinstimmungen. Die Architektur der semantischen Suche im Unternehmen beschreibt detailliert, wann ein Reranker im Pipeline sinnvoll ist.

Erstellen Sie ein Golden Set: mindestens 100 Abfragen mit erwarteten Dokumenten (Sie können mit 50 beginnen und erweitern). Messen Sie recall@5 (ob das richtige Dokument in den Top 5 ist) und MRR (Mean Reciprocal Rank, wie hoch der erste relevante Treffer erscheint). Vergleichen Sie drei Varianten: BM25 solo, Semantik solo, Hybrid RRF. In Systemen mit gemischtem Fachvokabular verbessert Hybrid recall@5 um 15-35 % gegenüber reiner Semantik. Wenn die Verbesserung unter 5 % liegt, prüfen Sie zunächst die Qualität des Chunkings – oft liegt das Problem dort. Ein guter Einstieg ist ein Website- und Systemaudit, das Engpässe vor der Implementierung aufzeigt.