Hybrid Search

Hybrid Search bezeichnet eine Such-Strategie, die zwei Suchverfahren gleichzeitig laufen lässt und ihre Trefferlisten zu einer gemeinsamen Rangliste zusammenführt. Kombiniert werden eine wortbasierte Suche (Volltextsuche über Wortübereinstimmung, klassisches Verfahren: BM25) und eine bedeutungsbasierte Suche (Vektorsuche über sogenannte Embeddings, also numerische Repräsentationen von Textbedeutung). Ziel ist, in einer einzigen Anfrage sowohl exakte Treffer (Produktcodes, Fehlernummern, Fachbegriffe) als auch inhaltlich ähnliche Treffer (Synonyme, Umschreibungen, Paraphrasen) zu finden.

Was ist Hybrid Search?

Hybrid Search setzt zwei parallele Sucher (Retriever) über denselben Textbestand ein. Der wortbasierte Zweig arbeitet mit einem invertierten Index (Nachschlage-Struktur, die zu jedem Wort die passenden Dokumente listet) und einer Bewertungsfunktion wie [BM25](https://www.staff.city.ac.uk/~sbrp622/papers/foundations_bm25_review.pdf), die Dokumente nach Worthäufigkeit und Seltenheit der Wörter bewertet. Der bedeutungsbasierte Zweig übersetzt Anfrage und Dokumente über ein Embedding-Modell in Zahlenvektoren und ranked nach der Nähe dieser Vektoren zueinander ([Karpukhin et al., 2020](https://arxiv.org/abs/2004.04906) beschreiben das kanonische Verfahren für Frage-Antwort-Systeme). Beide Zweige liefern eine geordnete Kandidatenliste. Ein Fusion-Schritt (Zusammenführung der beiden Listen) produziert daraus eine einzige Rangliste.

Der Standard-Fusion-Ansatz ist [Reciprocal Rank Fusion (RRF)](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf) nach Cormack, Clarke und Buettcher (2009). Für jedes Dokument summiert RRF die Werte 1 / (k + rank_i) über alle Retriever i, wobei rank_i der Rang des Dokuments im jeweiligen Retriever ist und k üblicherweise auf 60 gesetzt wird. Der Ansatz benötigt keine Score-Normalisierung, weil er nur mit Rängen rechnet. Alternative Fusion-Verfahren sind gewichtete Score-Fusion nach Min-Max- oder Z-Score-Normalisierung sowie Learning-to-Rank-Modelle, die auf gelabelten Klick- oder Relevanzdaten trainiert werden. Oft folgt auf die Fusion ein Reranker (Cross-Encoder oder LLM), der die Top-Kandidaten in einem zweiten Durchlauf umsortiert.

Der Begriff existiert, weil reine Vektorsuche bei exakten Termen strukturell schwach ist. Embeddings verwischen numerische Codes, Eigennamen und Fachbegriffe, weil diese im Trainingskorpus des Modells selten in bedeutungstragendem Kontext auftauchen. Umgekehrt scheitert reine BM25-Suche an Synonymen und Umschreibungen, weil sie nur auf Term-Übereinstimmung basiert. Hybrid Search kombiniert die komplementären Stärken und ist heute Standard-Baustein in Retrieval-Systemen wie Elasticsearch, [OpenSearch](https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/index/), [Azure AI Search](https://learn.microsoft.com/de-de/azure/search/hybrid-search-overview), Weaviate, Qdrant, Vespa, Milvus und Databricks Mosaic AI Vector Search.

Abgrenzung zu Vector Search, BM25 und Reranking

Der Begriff wird häufig mit angrenzenden Retrieval-Konzepten vermischt.

Die wichtigste Abgrenzung betrifft Vector Search. Beide Verfahren beantworten Retrieval-Anfragen über einen Textbestand. Vector Search rankt ausschließlich nach semantischer Nähe im Vektorraum. Hybrid Search enthält denselben Vektor-Retriever zusätzlich zu einem lexikalischen Retriever und einer Fusion-Stufe. Für Anfragen, die exakte Bezeichner enthalten (Vertragsnummern, SKUs, Ticket-IDs, Personennamen, technische Kürzel), liefert Hybrid Search deutlich stabilere Ergebnisse, weil der lexikalische Zweig diese Treffer sicher findet. Für rein konzeptuelle Anfragen ist der Unterschied zu reiner Vector Search klein und der Aufwand der Fusion nicht immer gerechtfertigt.

Gegen Reranking abgegrenzt: Beide Verfahren verbessern Trefferlisten, aber auf unterschiedlichen Ebenen. Hybrid Search kombiniert Ergebnisse verschiedener Retriever, ohne die Dokumente erneut zu bewerten. Reranking bewertet eine bereits abgerufene Kandidatenliste mit einem stärkeren, aber teureren Modell erneut. Beide Verfahren lassen sich hintereinander schalten: Hybrid Retrieval liefert einen Kandidatenraum von 50 bis 200 Dokumenten, ein Cross-Encoder-Reranker ordnet die Top-Kandidaten für die finale Antwort um.

Der Preis für Hybrid Search ist eine doppelte Index-Haltung (invertierter Index plus Vector-Index), höhere Query-Kosten durch zwei Retriever-Läufe und eine zusätzliche Tuning-Achse: die Gewichtung zwischen den Zweigen, die Konstante k in RRF, die optionale Reranker-Wahl.

Beispiel: Wissensassistent über Vertrags- und Ticketbestand

Ein interner Wissensassistent soll Fragen zu Wartungsverträgen und offenen Tickets beantworten. Der Dokumentenbestand liegt als Mischung aus PDF-Verträgen, Ticketexporten und internen Wiki-Seiten in einem Index. Eine Anfrage lautet: „Welche SLA gilt für den Wartungsvertrag CN-2024-773, und gibt es offene Störungen aus der letzten Woche?"

In einer reinen Vector-Search-Pipeline würden thematisch ähnliche Verträge und Tickets zurückkommen, die von SLA, Wartung und Störungen handeln. Die exakte Vertragsnummer CN-2024-773 verfehlt die Vektorsuche mit hoher Wahrscheinlichkeit, weil das Embedding-Modell numerische Kürzel schlecht unterscheidet. In einer reinen BM25-Pipeline landet die Vertragsnummer auf Rang eins, aber Dokumente, die stattdessen von „Service Level" oder „Zusicherung" statt „SLA" sprechen, fallen aus der Trefferliste.

In der Hybrid-Search-Variante laufen beide Retriever parallel. BM25 findet die exakte Vertragsnummer und die Tickets mit dem Term „SLA". Der Vektor-Retriever ergänzt Dokumente, in denen der Vertrag umschrieben ist oder die Störung in anderer Formulierung beschrieben wird. RRF fusioniert beide Ranglisten. Der Vertragskontext landet oben, umschriebene Störungsberichte werden zusätzlich abgerufen. Das Sprachmodell erhält eine belegbare Kandidatenmenge, die beide Aspekte der Anfrage abdeckt.