Hybrid-Search für RAG: BM25, Dense, RRF

TL;DR

• Recall-Lift: Hybrid-Search (BM25 + Dense + RRF) liefert in MedTech-/Engineering-RAG-Mandaten 20–40 % höheren Recall als reine Dense-Vector-Suche — entscheidend bei Artikelnummern, Norm-Referenzen und Eigennamen.
• Setup-Aufwand: 1–2 Wochen Senior-Engineering, wenn die Vector-DB schon steht — BM25-Index plus RRF-Merge ist additiv, nicht disruptiv.
• Stack-Wahl: Postgres-Setups gewinnen mit pgvector + tsvector nativ, größere Setups mit Qdrant oder Weaviate Hybrid-Mode, Volltext-lastige mit Elasticsearch.

Was Dense-Search 2026 nicht mehr lösen kann

Reine Dense-Vector-Search (HNSW, FAISS, pgvector mit cosine) ist seit 2023 der Default-Pfad jedes RAG-Builds. In semantischen Frage-Antwort-Szenarien funktioniert das gut — bis die Queries präzise werden. Drei Query-Klassen brechen die Annahme, dass Embeddings genug sind. In MedTech, Maschinenbau und Engineering sind sie die Mehrheit der produktiv gestellten Fragen, nicht die Ausnahme.

• Codes und Artikelnummern. Embeddings verallgemeinern. Eine Artikelnummer wie BTL-4470-X12 oder eine Norm-Referenz wie IEC 62304:2015 §5.1.3 wird im Vector-Space zwischen ähnlichen Token-Sequenzen abgebildet, nicht exakt verankert — die Query findet auch BTL-4470-X11 und BTL-4480-X12. BM25 als sparse Keyword-Index trifft den exakten String und sortiert die Treffer-Liste sauber.
• Eigennamen und Bauteil-IDs. Hersteller-Namen, CAD-Bauteil-IDs und Seriennummern verhalten sich wie Codes; Embeddings haben keinen ausreichenden Kontext für Bosch Rexroth EE-080-XBA-DS-12 vs. -DS-22. In einem Werkzeugbau-Mandat mit 28.000 CAD-Bauteilen brach die reine Dense-Search bei Bauteil-ID-Queries auf Recall@10 von 42 % ein; mit BM25-Hybrid: 78 %.
• Tail-Queries. Selten gestellte, hochspezifische Fragen finden im Embedding-Space keinen verlässlichen Cluster. BM25 rankt sie über Term- und Inverse-Document-Frequency — der lange Tail bleibt bedienbar.

BM25 + Dense + RRF — die Anatomie

Hybrid-Search ist kein neues Modell, sondern zwei parallele Indizes mit einem Merge-Schritt. Der dominante Standard ist Reciprocal Rank Fusion (RRF) — eine score-freie, robuste Fusion, die in fast jedem Vector-DB-Hybrid-Mode 2026 verbaut ist.

1. Query-Eingang. Identische Query geht parallel an beide Indizes.
2. BM25-Index. Top-K nach Keyword-Match (sparse).
3. Dense-Index. Top-K nach Embedding-Cosine (semantic).
4. RRF-Merge. Fusioniert beide Ranglisten nach score(d) = Σ 1 / (k + rank_i(d)) mit k=60 als Default.
5. Re-Ranking (optional). Cross-Encoder (z.B. bge-reranker-v2-m3) auf die Top-50 für maximale Präzision.

RRF mit k=60 ist in 90 % der produktiven RAG-Builds 2026 die Default-Konfiguration — nicht weil sie optimal ist, sondern weil sie ohne Score-Normalisierung funktioniert.

Stack-Vergleich

Vier Stacks decken die DACH-Mittelstands-Mandate ab. Die Wahl hängt weniger an Performance als an vorhandener Infrastruktur und Volltext-Anteil.

Rund 70 % der Mittelstands-Mandate starten mit pgvector + tsvector — die Postgres-Infrastruktur ist schon da, der Setup-Aufwand ist additiv, und der Migrations-Pfad zu Qdrant bleibt offen.

Praxis: MedTech-RAG mit 38 Pp Recall-Lift

Im Mandat eines MedTech-Mittelständlers (4.200 regulatorische Dokumente, ~12.000 Norm-Referenzen, ~8.000 CAPA-Reports) war die Ausgangslage typisch: pgvector mit OpenAI text-embedding-3-large, HNSW-Index, Top-K=20.

Die Latenz-Kosten sind in jedem Mandat sichtbar, aber überschaubar — +30–60 ms P95 ist die typische Range. Bei einer interaktiven RAG-Anwendung (Antwort-Latenz typisch 2–4 s end-to-end) ist das nicht spürbar. Der Recall-Lift kommt nicht aus dem Modell, sondern aus dem zweiten Index: Wer 2026 reines Vector deployt, lässt 30–40 % Treffer auf dem Tisch.

Tuning-Parameter

Hybrid-Search ist nicht plug-and-play. Drei Parameter entscheiden über Recall, Präzision und Latenz und müssen pro Domäne kalibriert werden.

• k1 (BM25 Term-Frequency-Saturation). Standard 1.2. Höher (1.5–2.0) bei kurzen, keyword-dichten Dokumenten (Artikel-Katalog, Stücklisten), niedriger (0.8–1.0) bei langem Fließtext.
• b (BM25 Length-Normalization). Standard 0.75. Höher (0.8–1.0) bei heterogenen Dokumentlängen, niedriger (0.3–0.5) bei homogener Korpus-Länge.
• alpha-weight (Hybrid-Gewichtung). 0.5 als Default. Höher (0.7–0.9) zugunsten BM25 bei Code-/ID-lastigen Domänen, niedriger (0.2–0.4) zugunsten Dense bei narrativen Korpora.

In der Praxis liefern 2–3 Iterationen mit einem Eval-Set (50–100 manuell annotierte Query-Pairs) den brauchbaren Tuning-Punkt. Mehr ist Over-Engineering.

Wann reine Vector reicht

Hybrid ist nicht universell die richtige Antwort. Drei Konstellationen sprechen für reine Dense-Vector-Search:

• Kleine Korpora. Unter 5.000 Dokumenten ist der Recall-Unterschied marginal (<5 Pp); der zweite Index lohnt nicht.
• Semantik-only Use-Cases. Customer-Support-FAQs, Onboarding-Wissensbasis, narrative Knowledge-Bases — wenn Queries paraphrasieren statt zitieren, schlägt Dense alleine. Die Differenz ist <5 Pp, und die Latenz spart 30–60 ms.
• Sehr saubere Embeddings. Domain-spezifische Fine-Tunes (Cohere Embed v3, BGE-M3) schließen den Code-/ID-Gap teilweise; wer ein eigenes Modell auf seinem Norm-Korpus fine-tuned hat, gewinnt weniger durch BM25.

In rund 70 % der DACH-Mittelstands-Mandate trifft keine dieser Bedingungen zu — Hybrid ist der Default. In den verbleibenden 30 % spart die Single-Index-Architektur Komplexität ohne Recall-Verlust.

Praxis-Schritt: Ein 30-Min-Eignungsgespräch klärt, ob Ihr Corpus die Hybrid-Logik trägt — und welcher Stack zu Ihrer bestehenden Infrastruktur passt. Erstgespräch anfragen → /anfrage

Stand Mai 2026. BM25-Tuning-Defaults, Vector-DB-Versionen und Embedding-Modelle ändern sich quartalsweise — diese Übersicht wird entsprechend aktualisiert.