Hybrid Search: BM25 + Vektoren + Reranking — warum reine Vector-Retrieval nicht ausreicht

Vector-Retrieval ist 2026 der De-facto-Standard für RAG-Deployments. Die meisten Teams konfigurieren ein Embedding-Modell, befüllen Qdrant oder pgvector und schieben das in die Produktion. Es funktioniert — bis eine Anfrage wie „§ 271 Abs. 2 Arbeitsgesetzbuch" oder „HMI Modell 7NF-420-C" hereinkommt. Dense Embeddings kommen damit nicht zurecht: Das Dokument wird auf einen einzigen Vektor komprimiert, und der exakte String geht in der semantischen Normierung verloren. Genau hier setzt Hybrid Search an — die Kombination aus Keyword-Retrieval (BM25) und vektorbasierter Suche, mit einem Reranker als dritter Schicht.

Dieser Artikel geht tiefer als das Thema RAG-Pipeline — 3 Einstellungen, die über Qualität entscheiden, wo wir den Reranker nur im Kontext der Pipeline erwähnt haben. Hier konzentrieren wir uns ausschließlich auf die Search-Schicht: warum Vektoren allein nicht ausreichen, wie Hybrid Search mechanisch funktioniert, was RRF Fusion ist, wann ein Reranker wirklich hilft und wie man das alles in der Praxis konfiguriert.

Warum Vektoren allein nicht ausreichen

Ein Dense-Embedding-Modell (z. B. BGE-M3 oder text-embedding-3-large) überführt Text in einen Vektor in einem Raum aus Hunderten oder Tausenden von Dimensionen. Vektoren, die nah beieinander liegen, haben ähnlichen semantischen Inhalt. Hervorragend für Fragen wie „Was sind die Voraussetzungen für eine Kündigung des Arbeitsverhältnisses", bei denen die Bedeutung zählt.

Das Problem tritt bei lexikalisch spezifischen Anfragen auf:

• Normen- und Gesetzesnummern: § 63, EN ISO 12100, EU-Verordnung 2016/679
• Produkt- und Teilecodes: SKF-6204-2RS, Siemens SIMATIC S7-1500
• Namen, Abkürzungen, Akronyme: DGUV, BaFin, FFT-Analyse
• Exakte Werte: 230 V AC, IP67, UL 508A

In diesen Fällen versagt das Embedding aus einem einzigen Grund: Das Modell wurde nicht darauf trainiert, dass „SKF-6204-2RS" und „SKF-6205-2RS" grundlegend verschiedene Artikel sind. Die Vektoren können nah beieinander liegen, weil sie den gleichen Präfix teilen. Der exakte Match geht verloren.

BM25 (Best Matching 25) hat dieses Problem nicht. Es ist eine klassische, statistische TF-IDF-Variante aus dem Jahr 1994, die das Vorkommen jedes Tokens in einem Dokument relativ zum Korpus explizit bewertet. Für exakte Strings ist BM25 nach wie vor besser als jedes Embedding — und das gilt 2026 genauso wie 2014.

Aus orientierenden Benchmark-Tests auf synthetischen Korpora:

• BM25 allein: ~58 % Präzision
• Dense Vectors allein: ~79 %
• Hybrid (BM25 + Dense): ~85–88 %
• Hybrid + Cross-Encoder-Reranker: ~88–91 %

Die tatsächliche Verbesserung hängt vom Datensatz, der Sprache und dem Anfragetyp ab. Für industrielle Dokumentationen mit Codes und Normen sehen wir in der Praxis eine Verschiebung von Hybrid vs. Dense von rund 8–12 Prozentpunkten Precision@5.

Wie BM25 funktioniert

BM25 ist ein statistisches Modell. Für jedes Dokument und jede Anfrage berechnet es einen Score als gewichtete Summe der TF-IDF (Term Frequency — Inverse Document Frequency) für jeden Token der Anfrage. Parameter:

• k1 — steuert die Sättigung der Term-Häufigkeit (typisch 1,2–2,0). Höher = lineareres Verhältnis zwischen Häufigkeit und Score.
• b — Normalisierung der Dokumentlänge (0 = keine, 1 = vollständig). Standard 0,75.

BM25 benötigt weder GPU noch spezielle Hardware — es ist deterministisch, schnell und läuft auf der CPU. Die Python-Bibliothek rank_bm25, oder native Unterstützung in Weaviate, OpenSearch, Elasticsearch und Qdrant (über Sparse Vectors).

Einschränkung: BM25 versteht keine Synonyme und keine Umformulierungen. Die Anfrage „Beendigung des Arbeitsverhältnisses" findet kein Dokument, das nur von „Kündigung" spricht. Dafür sind Vektoren zuständig.

Reciprocal Rank Fusion — zwei Ergebnislisten zusammenführen

Wenn wir zwei separate Rankings vorliegen haben (BM25 und Dense Vectors), müssen sie zu einem einzigen zusammengeführt werden. Der in 2026 am häufigsten verwendete Ansatz ist RRF (Reciprocal Rank Fusion).

Die Mechanik ist einfach. Für jedes Dokument berechnen wir:

RRF_score(d) = sum( 1 / (k + rank_i(d)) )

Dabei ist rank_i(d) die Position des Dokuments im i-ten Ranking und k ein Glättungsparameter (typisch 60). Dokumente, die in beiden Rankings weit oben stehen, erhalten den höchsten Score. Ein Dokument, das ein System nicht kennt, das andere aber auf Platz 1 rankiert, bekommt trotzdem einen ordentlichen Score.

Warum kein gewichteter Durchschnitt der Scores? BM25-Scores und Embedding-Cosine-Similarity liegen auf unterschiedlichen Skalen — eine direkte Gewichtung würde eines der beiden Systeme bevorzugen. RRF arbeitet ausschließlich mit der Reihenfolge, die Skala spielt keine Rolle.

Alternative zu RRF: DBSF (Distribution-Based Score Fusion) — normalisiert die Scores vor der Fusion, sinnvoll wenn beide Systeme kalibriert sind. In der Praxis starten die meisten Implementierungen mit RRF und probieren DBSF erst bei Problemen mit der Scoreverteilung aus.

Der Parameter alpha in manchen Frameworks (z. B. Weaviate) steuert einfach das Verhältnis BM25 vs. Dense — alpha=0 = reines BM25, alpha=1 = reines Dense, alpha=0.5 = gleicher Beitrag beider. Der Standardwert 0,5 ist ein guter Ausgangspunkt, aber für Inhalte mit hoher Dichte an Codes und Normen empfiehlt sich alpha=0,3–0,4 (stärkerer BM25-Beitrag).

Reranker — warum Retrieval nicht ausreicht

Hybrid Search verbessert den Recall erheblich — die Wahrscheinlichkeit, dass das richtige Dokument unter den Top-K-Kandidaten ist. Aber Precision@5 (wie viele der ersten 5 Ergebnisse wirklich relevant sind) hängt davon ab, wie gut die Kandidaten sortiert sind.

Hier kommt der Reranker (Cross-Encoder-Modell) ins Spiel. Mechanik:

1. 1.Hybrid Retrieval liefert Top-K-Dokumente zurück (typisch K = 20–50). Schnell.
2. 2.Der Reranker erhält jedes der K Dokumente zusammen mit der Anfrage, verarbeitet sie gemeinsam und weist einen präzisen Relevanz-Score zu. Langsamer, aber genauer.
3. 3.Die Top-N (typisch N = 5) mit dem höchsten Reranker-Score gehen in den LLM-Kontext.

Warum ist der Reranker präziser als Embeddings? Bi-Encoder-Embeddings komprimieren Dokument und Anfrage jeweils separat in einen Vektor — die Interaktion zwischen beiden wird nur über die Cosinus-Distanz bewertet. Der Cross-Encoder sieht Anfrage und Dokument gleichzeitig, was ihm ermöglicht, feine Token-Level-Interaktionen zu erfassen, die der Bi-Encoder verliert.

Typischer Anstieg von Precision@5 nach Hinzufügen eines Rerankers: 7–12 Prozentpunkte. Zusätzliche Latenz: 50–200 ms für Top-20-Reranking.

Aktuell beste Optionen:

• Cohere Rerank 3.5 — Managed API, ausgezeichnet für mehrsprachige Inhalte einschließlich Mitteleuropa, einfache Integration
• BGE-reranker-v2-m3 — Open-Weight, Self-Hosted, mehrsprachig, ausgezeichnetes Preis-Leistungs-Verhältnis
• ms-marco-MiniLM-L-6-v2 — klein, schnell, für englischsprachiges Prototyping

Für die Wahl des Embedding-Modells gilt das gleiche Prinzip: Mehrsprachige EU-Inhalte verdienen einen mehrsprachigen Reranker.

Wann Hybrid Search deutlich hilft (und wann nicht)

Hybrid Search hilft deutlich, wenn:

• Inhalte Codes, Ziffern, Abkürzungen, Normen, Produktbezeichnungen enthalten
• Nutzer präzise Anfragen stellen (Copy-Paste aus dem Dokument, Teilecode aus der Bestellung)
• Die Sprache nicht ausschließlich Englisch ist — BM25 benötigt kein Sprachmodell, funktioniert für Deutsch genauso gut
• Recall ein Problem ist — „Das relevante Dokument wurde nicht gefunden" ist eine häufige Beschwerde
• Der Korpus thematisch sehr ähnliche Dokumente enthält (z. B. 5 000 ähnlich strukturierte Datenblätter)

Hybrid Search hilft weniger, wenn:

• Anfragen rein konversationell und paraphrasenbasiert sind (FAQ-Chatbot, HR-Antworten)
• Der Korpus klein ist (unter 500 Dokumente) — zusätzliche Latenz und Komplexität lohnen sich nicht
• Latenz kritisch ist — auf jeder Seite kommt BM25-Scoring hinzu (typisch +10–30 ms) und potenziell der Reranker (+50–200 ms)
• Der Inhalt primär englisch ist und die Embeddings qualitativ hochwertig — Dense Vectors nähern sich dann den Ergebnissen des Hybrid-Retrievals an

Bei einem Kunden aus der Ersatzteilproduktion haben wir folgendes erlebt: Korpus mit 18 000 technischen Datenblättern und SKF-, NSK-, FAG-Codes. Reines Dense-Retrieval, Precision@5 = 0,63. Nach Umstieg auf Hybrid mit alpha=0,35 und BGE-reranker-v2-m3: Precision@5 = 0,84. Der Hauptgrund — exakter Match auf den Teilecode aus der Kundenanfrage.

Praktische Konfiguration — Stack 2026

Qdrant (empfohlen für B2B-Industriedeployments)

Qdrant unterstützt nativ Hybrid Search über Sparse + Dense Vectors in einer einzigen Collection. Sparse Vectors für BM25 generieren wir über BM25Encoder aus der fastembed-Bibliothek.

# Initialisierung Sparse Encoder
from fastembed import SparseTextEmbedding
sparse_model = SparseTextEmbedding("Qdrant/bm25")

# bei der Indexierung
sparse_vec = sparse_model.embed(text)
dense_vec = embedding_model.embed(text)

# Query: Hybrid Search mit RRF Fusion
results = client.query_points(
    collection_name="documents",
    prefetch=[
        Prefetch(query=sparse_vec, using="sparse", limit=20),
        Prefetch(query=dense_vec, using="dense", limit=20),
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=5
)

Collection-Konfiguration: zwei Vector-Indizes — dense (Dimension je nach Embedding-Modell, Cosine) und sparse (Sparse-Index, Dot). Qdrant verarbeitet beide in einem einzigen Durchlauf.

Weaviate

Weaviate hat Hybrid Search als erstklassige Funktion — BM25 + Dense Vectors + RRF Fusion in einem einzigen API-Aufruf. Konfiguration von alpha direkt in der Query:

results = collection.query.hybrid(
    query="§ 63 Arbeitsgesetzbuch Kündigung",
    alpha=0.4,  # stärkerer BM25-Beitrag
    limit=20
)

Anschließend Reranking über Cohere oder einen lokalen Cross-Encoder auf den Top-20-Ergebnissen.

Reranking-Schicht

Unabhängig von der Vektor-Datenbank ist der Reranker ein separater Schritt. Empfohlene Konfiguration:

• K = 20–30 Kandidaten aus dem Hybrid Retrieval
• Reranker auf K Kandidaten → N = 5 Ergebnisse für das LLM
• Self-Hosted: BGE-reranker-v2-m3 auf GPU; auf der CPU schafft es ~500 ms/Query für Top-20
• Cloud: Cohere Rerank 3.5 API, EU-Endpoint

Das Hinzufügen eines Rerankers zu einem bestehenden Hybrid Retrieval ist in der Regel 20–40 Zeilen Code. Wenn man über RAG-Pipeline-Evaluation mit RAGAS spricht, sollte genau dieser Schritt eine eigene Precision@5-Metrik vor und nach der Änderung haben.

Latenz: Was jede Schicht kostet

Typische Latenzen bei 10 M Vektoren, RTX 4090 GPU (orientierend):

• BM25-Scoring auf CPU: 10–30 ms
• Dense Vector Search (Qdrant): 5–15 ms
• RRF Fusion: unter 5 ms
• Reranker Cross-Encoder Top-20 (GPU): 80–150 ms
• Reranker Cross-Encoder Top-20 (CPU): 400–800 ms
• Cohere Rerank 3.5 API (Netzwerk): 100–200 ms

Gesamte Pipeline: Hybrid Retrieval + GPU-Reranker = typisch 200–400 ms end-to-end für die Search-Schicht. Für interaktive Chatbots ist das in der Regel akzeptabel. Für Systeme mit Anforderung unter 150 ms empfiehlt sich der Reranker nur bei niedriger Netzwerklatenz, oder man ersetzt ihn durch einfacheres Bi-Encoder-Resorting.

Einen detaillierten Vergleich der Vektordatenbanken und ihrer QPS-Parameter finden Sie im Artikel Vektordatenbanken — Qdrant, Weaviate, pgvector, Milvus.

Häufige Fragen

Muss ich das System von Anfang an mit Hybrid Retrieval entwerfen, oder kann ich BM25 später hinzufügen?

Der BM25-Index ist unabhängig vom Embedding-Index und kann einem bestehenden Korpus jederzeit hinzugefügt werden. In Qdrant genügt es, der Collection einen Sparse-Vector-Index hinzuzufügen und die Dokumente neu zu indexieren — die Dense-Indizes bleiben unberührt. Weaviate, Milvus und pgvector folgen einem ähnlichen Verfahren. Die Reindexierungszeit hängt von der Korpusgröße ab, aber für eine typische B2B-Knowledge-Base (bis 1 M Dokumente) dauert es Stunden, nicht Tage.

Was ist für deutschsprachige Inhalte besser: BM25 oder Dense Embeddings?

Es kommt auf den Anfragetyp an. BM25 funktioniert für Deutsch genauso gut wie für Englisch — es ist ein statistisches Modell ohne Sprachabhängigkeit. Für semantische Fragen (Umformulierungen, Synonyme) ist ein mehrsprachiges Dense Embedding wie BGE-M3 oder Qwen3-Embedding-8B besser. In der Praxis für deutschsprachige B2B-Korpora: Hybrid mit alpha=0,4–0,5 liefert das beste Ergebnis.

Wann hilft ein Reranker nicht?

Der Reranker sortiert nur die Dokumente um, die das Retrieval zurückgegeben hat. Wenn das richtige Dokument nicht unter den Top-K-Kandidaten ist, kann der Reranker es nicht retten. Das bedeutet: Zunächst muss der Recall verbessert werden (Hybrid Retrieval, größeres K), dann erst wird der Reranker hinzugefügt. Wenn Precision@5 auch nach dem Reranking stagniert, liegt das Problem meistens im Recall — das richtige Dokument ist schlicht nicht unter den Kandidaten.

Was ist der Unterschied zwischen Hybrid Search und Agentic RAG?

Hybrid Search ist eine Technik auf Ebene der Retrieval-Schicht — sie verbessert, welche Dokumente in den LLM-Kontext gelangen. Agentic RAG ist ein architektonisches Muster, bei dem ein Agent aktiv entscheidet, was und wie gesucht wird — iterative Anfragen, verschiedene Quellen, Sub-Queries. Hybrid Search und Agentic RAG schließen sich nicht aus: Ein guter Agent verwendet unter der Haube Hybrid Retrieval.

Lässt sich Hybrid Search On-Premises ohne Cloud-Abhängigkeiten betreiben?

Ja. Qdrant und Weaviate sind Open Source und laufen Self-Hosted. BGE-reranker-v2-m3 ist ein Open-Weight-Modell, das lokal auf der GPU läuft. BM25 benötigt keinerlei externen Dienst. Der gesamte Stack — Hybrid Retrieval + Reranker — kann vollständig On-Premises betrieben werden, was für regulierte Branchen wichtig ist. Mehr zum Thema On-Premises LLM für regulierte Branchen.

---

*Wenn Ihr RAG-System daran scheitert, exakte Codes, Normen oder Produktbezeichnungen zuverlässig zu finden, liegt das Problem fast immer in der fehlenden Keyword-Schicht. Wir helfen Unternehmen, einen Hybrid-Retrieval-Stack zu entwerfen und einzuführen — von der Auswahl der Datenbank und des Embedding-Modells bis zur Konfiguration des Rerankers und der Messung der Verbesserung.*