Hybride Suche (Dense + Sparse Search)

1. Überblick über das Konzept und das Systemproblem

Zu Beginn der Entwicklung von RAG-Systemen verlassen sich Ingenieure häufig ausschließlich auf Vektordatenbanken: Text wird in Chunks unterteilt, durch ein Embedding-Modell geleitet und in einen HNSW-Index geschrieben.

Im Produktionsumfeld stößt dieser Ansatz unvermeidlich auf die sogenannte „Vektorblindheit“:

1. Versagen bei exakten Identifikatoren: Wenn ein Ingenieur nach dem Statuscode ERR_CONNECTION_REFUSED sucht, liefert die Vektorsuche allgemeine Artikel über Netzwerke, übersieht aber die exakte Zeile im Log.
2. Versagen bei seltenen Eigennamen: Neue Framework-Namen, einzigartige Nachnamen oder spezifische Projekt-Konstanten haben keine dichte Repräsentation in den Gewichten des Embedding-Modells.
3. Einschränkungen der klassischen Volltextsuche (BM25): Die klassische Suche ist im Gegenzug nicht in der Lage, abstrakte Konzepte, Synonyme oder Umschreibungen zu verstehen.

Hybrid Search synthetisiert das Beste aus beiden Welten: Er sucht parallel nach Dokumenten anhand exakter Schlüsselwörter (Sparse/BM25) sowie nach semantischem Inhalt (Dense/Vectors), um die Ergebnisse anschließend zu einer ausgewogenen Ausgabe zusammenzuführen.

2. Architektonische Taxonomie und mentales Modell

Ein hybrides Suchsystem besteht aus drei wesentlichen Architekturblöcken:

• 1. Layer für Sparse Retrieval (Lexikalische Suche): Der Algorithmus BM25 oder TF-IDF auf einem invertierten Index. Er berechnet die exakte Termfrequenz unter Berücksichtigung der Dokumentlänge. Dies garantiert das Auffinden exakter Wortübereinstimmungen, Artikel, Variablen und Fehlercodes.
• 2. Layer für Dense Retrieval (Semantische Suche): Vektorsuche basierend auf euklidischer oder Kosinus-Distanz (HNSW/IVF). Dieser Layer ist dafür verantwortlich, Dokumente mit ähnlichem Inhalt zu extrahieren, selbst wenn Query und Text kein einziges gemeinsames Wort teilen.
• 3. Fusion Layer (Rang-Zusammenführung):
  • Reciprocal Rank Fusion (RRF): Unabhängig von Score-Skalen, operiert rein mit Positionen (Rängen) in jeder Liste. Dies ist der stabilste Standard.
  • Linear Weighted Fusion (Alpha-Fusion): Normalisierung der Scores und gewichtete Addition: $\text{Score} = \alpha \cdot S_{\text{dense}} + (1 - \alpha) \cdot S_{\text{sparse}}$.
• 4. Learned Sparse Models (SPLADE): Ein moderner Ansatz, der neuronale Netzwerkanalyse mit der Struktur eines invertierten Index kombiniert und dabei die Query eigenständig um wichtige Schlüsselwörter erweitert.

3. Technischer Pipeline und interne Mechanik

Der Lebenszyklus einer Hybrid-Query innerhalb der Suchmaschine:

1. Dual Query Dispatch (Paralleles Senden): Die eingehende Benutzer-Query wird gleichzeitig in einen Vektor (über die Embedding API) und in eine textuelle Query für den Volltextparser (FTS query) transformiert.
2. Concurrent Index Lookup (Parallele Suche):
   • Branch A: Die Vektorsuchmaschine scannt den HNSW-Graphen und gibt die Top-50-Kandidaten basierend auf Kosinus-Ähnlichkeit zurück.
   • Branch B: Der invertierte Index findet die Top-50-Kandidaten gemäß der BM25-Formel.
3. Score Normalization & RRF Aggregation (Zusammenführung): Die Kandidatenlisten werden anhand der Dokument-ID dedupliziert. Jedem Kandidaten wird ein integrierter RRF-Score basierend auf seiner Position in beiden Ausgaben zugewiesen.
4. Final Cutoff & Re-ranking (Finale Auswahl): Die Top-$K$ am höchsten gerankten Dokumente werden an die finale Phase des Cross-Encoder-Re-Rankings (Re-ranker) übergeben oder direkt in den LLM-Kontext eingespeist.

4. Praktische Engineering-Szenarien im Produktionsbetrieb

01. Intelligente Suche in Code-Repositories

Ein Entwickler schreibt: „Wo ist das Redis-Session-Caching implementiert?“.

• BM25 findet sofort Dateien, in denen die Konstante 'REDIS_SESSION_KEY' erwähnt wird.
• Die Dense-Suche zieht das Authentifizierungsmodul hinzu, in dem die Strategie zur Session-Invalidation beschrieben ist, ohne dass das Wort „Caching“ explizit vorkommt.
• RRF hebt die Datei auth/session-cache.ts, die in beiden Ergebnismengen vorhanden ist, auf den ersten Platz.

02. E-Commerce-Suche mit Mischung aus Merkmalen und Namen

Ein Benutzer sucht nach: „leiser kabelloser Staubsauger v15“. BM25 findet das exakte Modell Dyson V15, während die Dense-Suche Varianten anhand der Semantik „niedriger Geräuschpegel“ filtert, was eine ideale Conversion-Genauigkeit gewährleistet.

03. Medizinische und pharmazeutische Referenzen

Suche nach Symptomen („Druckgefühl im rechten Oberbauch“) in Kombination mit der exakten lateinischen Bezeichnung des Wirkstoffs eines Präparats oder dem medizinischen Diagnosecode gemäß ICD-10.

5. Fallstricke, typische Fehler und Sicherheit

• Inkompatibilität der Rohscore-Skalen (Score Incommensurability): Der gröbste Fehler ist die direkte Addition der Kosinus-Ähnlichkeit (von 0 bis 1) zum BM25-Score (der Werte von 25 und mehr erreichen kann). Dies nivelliert die vektorielle Komponente vollständig. Verwenden Sie immer RRF oder Min-Max-Normalisierung.
• Doppelte Infrastrukturlast (Latency Overhead): Die sequenzielle Ausführung erst von BM25 und dann der Vektorsuche verdoppelt die Latenz. Beide Queries müssen strikt asynchron über Promise.all() oder parallele DB-Threads ausgeführt werden.
• Verzerrung des Gewichts $\alpha$ in extreme Werte: Eine Fixierung des Gewichts $\alpha = 0.9$ verwandelt die Hybrid-Suche in eine reine Vektorsuche und macht die Kosten für die Wartung des invertierten Index zunichte.