Hybrid Search vs. Vector Search bei RAG: Was wann besser funktioniert
Hybrid Search ist kein automatischer Qualitätsgewinn. Sie ist dann plausibel, wenn reale Nutzerfragen gleichzeitig semantische Ähnlichkeit und exakte Begriffe, IDs, Codes oder Eigennamen benötigen. Die richtige Retrieval-Strategie entsteht deshalb nicht aus dem Label „Enterprise“, sondern aus der Query-Verteilung und dem Evidenztyp, den eine Antwort tatsächlich braucht.
Stellen Sie sich einen typischen technischen Unternehmensbestand vor: Produktdokumentation, Handbücher, Support-Wissensbasis und dazu Artikelnummern, Fehlercodes, Produktnamen sowie alternative Formulierungen. Genau dort wird die Frage „Vector oder Hybrid?“ zu grob. Entscheidend ist, welche Fragen im System wirklich gestellt werden.
Für die Gesamtarchitektur siehe RAG-System entwickeln & richtig aufbauen. Die Messmethode dazu beschreibt RAG Evaluation: Metriken, Golden Dataset & Regression Tests.
Die Frage ist zu grob: Welche Query-Klasse liegt vor?
In einem technischen Korpus existieren mehrere Retrieval-Probleme nebeneinander. Eine Suchstrategie sollte sie nicht zu einem Durchschnittsfall glätten.
| Query-Klasse | Beispiel | Vector | Lexical | Hybrid | Typisches Risiko |
|---|---|---|---|---|---|
| Exakte Identifier | E217, AB-4711, MTR-9000 | kann passende Passagen übersehen | oft stark, besonders auf exakten Feldern | sinnvoll, wenn zusätzlich Kontext gefragt ist | der Code landet nicht in den Kandidaten |
| Semantische Frage | „Warum startet das Gerät nach dem Firmware-Update nicht mehr?“ | oft stark | scheitert eher an anderer Wortwahl | nicht zwingend nötig | relevante Erklärung verwendet andere Begriffe |
| Synonym / Paraphrase | „Ventil zum Druck ablassen“ statt „Druckentlastungsventil“ | oft stark | abhängig von Synonympflege | kann helfen, ist aber nicht automatisch besser | exakte Wortsuche findet die Fachterminologie nicht |
| Gemischte Query | „Fehler E217 nach Austausch des Drucksensors“ | versteht den Zusammenhang | sichert E217 und Fachbegriffe | häufig plausibel | ein Signal dominiert den anderen Teil der Frage |
| Eigenname / seltener Begriff | Produktname, interne Abkürzung, ungewöhnliches Bauteil | nicht verlässlich genug als einziges Signal | kann dominant sein | nur bei zusätzlichem semantischem Bedarf | seltene Tokens werden semantisch verwässert |
Diese Tabelle ist keine feste Konfiguration. Sie beschreibt Hypothesen, die sich gegen echte Fragen prüfen lassen.
Wo Vector Search stark ist
Dense Retrieval ist besonders nützlich, wenn Nutzer ihre Frage anders formulieren als die Dokumentation. Im Handbuch steht etwa „Druckentlastungsventil“, in der Support-Anfrage „Ventil zum Druck ablassen“. Oder ein Nutzer fragt, warum ein Gerät nach einem Firmware-Update nicht startet, während die relevante Passage von einem Initialisierungsfehler nach dem Update spricht.
In solchen Fällen muss Retrieval nicht nur gleiche Wörter wiederfinden, sondern ähnliche Bedeutung erkennen. Vector Search kann dafür eine gute Baseline sein, wenn Fragen überwiegend natürlichsprachlich und der Korpus sprachlich konsistent sind.
Das ist aber keine Garantie für alle Teile derselben Anfrage. Ein Modell, das „Drucksensor austauschen“ sinnvoll zuordnet, muss einen Fehlercode wie E217 nicht zuverlässig als entscheidendes Signal behandeln.
Wo lexikalische Suche stark ist
Lexikalische Suche, etwa BM25 oder eine Suche über exakte strukturierte Felder, behandelt Zeichenfolgen als wichtige Evidenz. Das ist häufig genau richtig bei Artikelnummern, Fehlercodes, Versionsständen, Eigennamen, internen Abkürzungen und seltenen Fachbegriffen.
Eine Query wie MTR-9000 ist keine unscharfe Wissensfrage. Wenn der Korpus ein Dokument mit dieser Produktkennung enthält, soll dieses Dokument nicht nur „inhaltlich ähnlich“ wirken, sondern zuverlässig erreichbar sein. Strukturierte Filter können die bessere Lösung sein, wenn Produktcode, Version oder Mandant bereits als belastbares Feld vorliegen.
Lexical Retrieval ist deshalb kein veralteter Fallback. Es ist ein eigenes Signal für Evidenz, die exakt sein muss.
Wann Hybrid Search sinnvoll wird
Hybrid Search wird sinnvoll, wenn beide Signale in realen Queries regelmäßig zusammenkommen. Das ist beispielsweise bei „Fehler E217 nach Austausch des Drucksensors“ der Fall: Der Code sollte exakt treffen, zugleich entscheidet der Zusammenhang zwischen Fehler, Bauteil und Vorgang über die passende Passage. Ähnlich bei „MTR-9000 Kalibrierung funktioniert nach Update nicht“.
Hybrid kann besonders plausibel sein, wenn:
- exakte IDs, Codes oder Eigennamen vorkommen,
- semantische Formulierungen gleichzeitig relevant sind,
- Nutzer Queries aus Fachbegriff und natürlicher Sprache mischen,
- der Korpus Fachterminologie ebenso wie erklärende Texte enthält.
Er ist nicht automatisch die richtige Wahl. Bei einem homogenen Query-Typ, bei wirksamen strukturierten Filtern oder bei messbar ausreichendem Vector-only Retrieval ist zusätzliche Komplexität schwer zu rechtfertigen.
Fusion und Gewichtung: nur Kandidatenlisten verbinden
Hybrid Retrieval erzeugt zunächst zwei Kandidatenlisten. Eine Fusion entscheidet, welche Ergebnisse gemeinsam weitergegeben werden. Reciprocal Rank Fusion (RRF) ist ein pragmatischer Ansatz: Sie kombiniert die Rangpositionen der Listen, ohne BM25- und Vector-Scores künstlich auf dieselbe Skala zwingen zu müssen.
Eine feste Gewichtung ist keine Empfehlung, sondern eine zu testende Annahme. Vor allem gilt: Zwei schlechte Kandidatenlisten werden durch Fusion nicht automatisch gut. Wenn ein Fehlercode falsch indexiert ist oder eine synonyme Formulierung gar keine relevante Passage erreicht, muss zuerst die jeweilige Retrieval-Ursache geklärt werden.
Reranking kommt nach dem Retrieval
Retrieval erzeugt Kandidaten. Reranking verbessert anschließend deren Reihenfolge für die konkrete Query. Es ist sinnvoll, wenn die richtige Evidenz bereits im Top-k liegt, aber hinter weniger passenden Passagen rangiert.
Ein Reranker kann nur Dokumente besser sortieren, die das Retrieval überhaupt gefunden hat.
Fehlt die relevante Passage vollständig, repariert ein Reranker keinen Recall. Dann liegen die möglichen Ursachen früher in der Pipeline: Query-Verarbeitung, Filter, Index, Datenqualität oder Chunking. Reranking ist damit kein Ersatz für ein funktionierendes Initial Retrieval und kein Pflichtbaustein jeder Hybrid-Lösung.
Gegen reale Query-Klassen evaluieren
Vergleichen Sie lexical, vector und hybrid mit demselben Golden Dataset. Es sollte bewusst Fragen aus allen relevanten Klassen enthalten:
- identifiers,
- semantic,
- synonym,
- mixed,
- rare terms.
Messen Sie Recall@k, wenn die Evidenz überhaupt gefunden werden muss. Ergänzen Sie MRR oder NDCG, wenn die Rangfolge wesentlich ist, sowie Evidence Coverage und die nachgelagerte Answer Correctness. Latenz und Kosten gehören ebenfalls in die Entscheidung.
Der Gesamtscore allein ist jedoch zu grob. Wichtiger ist: Welche Query-Klasse verbessert oder verschlechtert sich? Hybrid kann den Durchschnitt anheben und gleichzeitig bei seltenen Begriffen oder exakten Codes regressieren. Nur eine aufgeschlüsselte Auswertung zeigt, ob die Architektur für die reale Nutzung besser wird.
Architecture View: die Entscheidung aus der Evidenz ableiten
Ich würde Hybrid Search nicht wegen des Labels „Enterprise“ einsetzen. Zuerst würde ich die reale Query-Verteilung messen. Wenn Codes, Eigennamen und semantische Fragen regelmäßig gemeinsam auftreten, ist Hybrid Retrieval meist plausibel. Wenn ein einzelner Retrieval-Typ das Query-Set bereits zuverlässig abdeckt, ist zusätzliche Komplexität schwer zu rechtfertigen.
Die Architektur kann dabei klar bleiben:
Query → Berechtigungsfilter → initiales lexical und/oder vector retrieval → optionale Fusion → optionales Reranking → Context Assembly → LLM
Berechtigungen begrenzen dabei den zulässigen Suchraum; sie sind kein Ranking-Signal. Mehr dazu: RAG-Berechtigungen & Security Trimming.
Retrieval-Architektur sollte aus Query-Verteilung und Evidenztyp entstehen, nicht aus dem aktuellen Suchtechnologie-Trend.
Nächster Schritt
Wenn Sie ein RAG-System neu aufbauen oder bestehende Unternehmensdaten sauber integrieren wollen, ist RAG-Implementierung & KI-Integration der passende Einstieg.
Wenn bereits ein System existiert und unklar ist, ob Hybrid Search, Chunking oder Reranking die Qualität wirklich verbessert, sollte zuerst eine reproduzierbare Baseline entstehen: KI Production Readiness.