Hybrid Search vs. Vector Search bei RAG: Was wann besser funktioniert

Viele RAG-Systeme starten mit Vektorsuche, weil sie technisch naheliegend ist. In Unternehmensdaten tauchen aber genau jene Dinge auf, die reine semantische Suche schwächen können: Produktnummern, Kürzel, Eigennamen, exakte Fehlermeldungen, Artikelcodes, Versionsstände und seltene Fachbegriffe.

Hybrid Search kombiniert deshalb Vector Search mit klassischer lexikalischer Suche. Die zentrale Architekturfrage lautet nicht „Was ist moderner?“, sondern: Welche Retrieval-Strategie bringt bei den realen Fragen die richtige Evidenz zuverlässig nach oben?

Für die Gesamtarchitektur siehe RAG-System entwickeln & richtig aufbauen. Für reproduzierbare Qualitätsmessung siehe RAG Evaluation: Metriken, Golden Dataset & Regression Tests.

Die Kurzfassung

| Verfahren | Stärke | Typische Schwäche | Gute Einsatzfälle | | --- | --- | --- | --- | | Keyword / BM25 | exakte Begriffe, seltene Tokens, IDs | versteht Synonyme und Bedeutung nur begrenzt | Produktcodes, Namen, technische Begriffe | | Vector Search | semantische Ähnlichkeit, Paraphrasen | exakte seltene Begriffe können untergehen | natürliche Fragen, Wissenssuche | | Hybrid Search | kombiniert lexical + semantic | mehr Tuning und Infrastruktur | gemischte Enterprise-Daten | | Hybrid + Reranking | feinere Sortierung der Kandidaten | höhere Latenz und Kosten | anspruchsvolle Retrieval-Qualität |

Meine Default-Empfehlung für heterogene Unternehmensdaten ist: nicht blind Vector-only bauen. Starten Sie mit einer klaren Baseline und testen Sie mindestens lexical, vector und hybrid gegen dieselben realen Fragen.

Was Vector Search tatsächlich macht

Bei Vector Search wird eine Anfrage in ein Embedding übersetzt. Dokumente oder Chunks liegen ebenfalls als Vektoren vor. Die Suche findet jene Vektoren, die im gewählten Ähnlichkeitsraum nahe an der Anfrage liegen.

Das ist stark bei Fragen wie:

„Wie kann ein Mitarbeiter einen bereits freigegebenen Reisekostenantrag korrigieren?“

Die relevante Dokumentation kann völlig andere Wörter verwenden und trotzdem semantisch ähnlich sein.

Problematisch wird es bei:

• ERR-4921,
• SKU-A17-44,
• exakten Vertragsklauseln,
• Versionsnummern,
• Personennamen,
• internen Abkürzungen,
• sehr seltenen Fachbegriffen.

Dort kann ein lexical signal deutlich präziser sein.

Was Hybrid Search ergänzt

Hybrid Search führt typischerweise mindestens zwei Retrieval-Wege aus:

1. lexikalische Suche – etwa BM25,
2. semantische Suche – über Embeddings.

Anschließend werden die Ergebnislisten fusioniert.

Microsoft beschreibt Azure AI Search Hybrid Search als parallele Volltext- und Vektorsuche, deren Resultate über Reciprocal Rank Fusion (RRF) zusammengeführt werden. Quelle: Microsoft Learn – Hybrid Search Overview.

Elastic empfiehlt ebenfalls RRF als Ansatz, um Volltext- und Vektorergebnisse zu einem Ranking zu kombinieren. Quelle: Elastic Docs – Hybrid Search.

Warum Enterprise-RAG von Hybrid Search profitiert

Unternehmenswissen ist selten ein sauberer, homogener Textkorpus.

Typisch sind gleichzeitig:

• SharePoint-Seiten,
• technische Handbücher,
• Tickets,
• PDFs,
• Produktdaten,
• CRM-Notizen,
• Wikis,
• Richtlinien,
• Tabellen,
• strukturierte IDs.

Damit entstehen zwei Suchwelten:

Bedeutung:
„Wie läuft die Freigabe bei Sonderfällen?“

Exaktheit:
„Was bedeutet Fehlercode FZ-1138?“

Ein Retrieval-System muss mit beiden umgehen können.

Entscheidungsmatrix: Vector, Hybrid oder Keyword?

| Datensituation | Empfehlung | | --- | --- | | natürliche Fragen, wenig exakte Begriffe | Vector Search als Baseline | | viele IDs, Codes, Namen, Fachbegriffe | Hybrid Search früh testen | | stark strukturierte Suchbegriffe | Keyword/BM25 als starke Baseline | | heterogene Enterprise-Wissensbasis | Hybrid Search meist sinnvoll zu evaluieren | | sehr kleiner, homogener Korpus | Komplexität niedrig halten; Vector-only kann reichen | | hohe Qualitätsanforderung vor Go-Live | Hybrid + optional Reranking gegen Eval-Set testen |

„Meist sinnvoll zu evaluieren“ ist absichtlich nicht „immer besser“. Jede zusätzliche Retrieval-Stufe muss ihren Nutzen auf dem eigenen Datensatz beweisen.

RRF: Rankings kombinieren statt Scores vergleichen

BM25- und Vector-Scores liegen nicht automatisch auf derselben Skala. Ein naives Addieren ist deshalb problematisch.

RRF umgeht das, indem nicht die Rohscores, sondern die Positionen in mehreren Ergebnislisten zusammengeführt werden.

Das hat zwei praktische Vorteile:

• lexical und semantic search müssen nicht dieselbe Score-Skala haben,
• Treffer, die in mehreren Listen weit oben liegen, werden bevorzugt.

Microsoft dokumentiert RRF explizit für Hybrid Search und mehrere parallele Vektorabfragen. Quelle: Microsoft Learn – Hybrid Search Ranking.

Hybrid Search ist noch kein Reranking

Hybrid Search beantwortet: Welche Kandidaten sollen in die gemeinsame Top-Liste?

Ein Reranker beantwortet danach: Welche dieser Kandidaten sind für genau diese Anfrage am relevantesten?

Typischer Ablauf:

1. BM25 liefert Kandidaten.
2. Vector Search liefert Kandidaten.
3. Rank Fusion erzeugt eine gemeinsame Liste.
4. Optional bewertet ein semantischer Reranker die besten Kandidaten neu.
5. Die finalen Chunks gehen an das LLM.

Elastic beschreibt Reranking genau als teurere zweite Stufe nach einer ersten Kandidatensuche. Quelle: Elastic Docs – Ranking and Reranking.

Wann Reranking sinnvoll wird

Reranking lohnt sich eher, wenn:

• viele Kandidaten semantisch ähnlich sind,
• Top-k häufig die richtige Quelle enthält, aber zu weit hinten,
• eine hochwertige Reihenfolge wichtiger als minimale Latenz ist,
• mehrere Retrieval-Signale zusammenkommen.

Reranking löst dagegen kein Problem, wenn die relevante Passage überhaupt nicht im Kandidatenset liegt.

Dann müssen Sie früher in der Pipeline ansetzen: Query, Filter, Index, Chunking oder Datenaufbereitung.

Filter und Berechtigungen nicht mit Ranking verwechseln

Bei Enterprise-RAG reicht „relevant“ nicht.

Ein Dokument kann hoch relevant und trotzdem nicht zugriffsberechtigt sein.

Security Trimming muss daher Teil der Retrieval-Architektur bleiben. Je nach Suchtechnologie werden Berechtigungsfilter vor oder innerhalb der Suche angewendet. Danach wird nur im zulässigen Ergebnisraum gerankt.

Mehr dazu: RAG-Berechtigungen & Security Trimming.

So testen Sie Hybrid Search sinnvoll

Nehmen Sie dasselbe Golden Dataset und vergleichen Sie Konfigurationen reproduzierbar.

Beispiel:

| Test | Retrieval | | --- | --- | | A | BM25 only | | B | Vector only | | C | Hybrid | | D | Hybrid + Reranker |

Messen Sie mindestens:

• ob die richtige Evidenz in Top-k liegt,
• Rangposition relevanter Treffer,
• irrelevante Treffer,
• End-to-End-Antwortqualität,
• Latenz,
• Kosten.

Die Evaluationsmethodik ist hier beschrieben: RAG Evaluation.

Anti-Patterns

„Vector Search ist moderner, also reicht sie“

Technologiealter sagt nichts über Relevanz für Produktcodes, Namen oder seltene Tokens aus.

„Hybrid Search ist automatisch besser“

Mehr Komponenten erzeugen auch mehr Parameter, Fehlerquellen und Betriebsaufwand.

„Reranking repariert schlechtes Retrieval“

Ein Reranker kann nur Kandidaten neu sortieren, die vorher gefunden wurden.

„Wir optimieren auf fünf Demo-Fragen“

Damit messen Sie vor allem, wie gut Sie fünf Fragen manuell getunt haben.

Architektur-Empfehlung

Für typische Unternehmensdaten würde ich den Retrieval-Layer modular halten:

Query → Berechtigungsfilter → lexical/vector retrieval → fusion → optional reranking → context assembly → LLM

Damit können Sie Suchverfahren austauschen, ohne die gesamte Anwendung neu zu bauen.

Das passt auch zu einer API-first Architektur: Retrieval wird als klarer Dienst mit messbaren Inputs und Outputs behandelt, nicht als unsichtbare Magie in einem Framework.

Nächster Schritt

Wenn Sie ein RAG-System neu aufbauen oder bestehende Enterprise-Datenquellen 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.