Hybrid Search und Reranking für RAG: BM25, Vektoren, Cross-Encoder

Suche, die Aktenzeichen und umschriebene Fragen gleichermaßen trifft? WZ-IT baut RAG-Systeme mit Hybrid Search, Reranking und Berechtigungen auf eigener Infrastruktur und misst die Trefferqualität mit Ihren eigenen Fragen. Der RAG-Sprint macht eine priorisierte Wissensquelle mit definierten Referenzfragen, Baseline-Messung und Quellenanzeige nutzbar. RAG-Sprint ansehen · Interne KI-Assistenten

Ein RAG-System antwortet nur so gut, wie seine Suche die passenden Textstellen findet. Reine Vektorsuche findet umschriebene Fragen, verfehlt aber regelmäßig exakte Kennungen wie Aktenzeichen, Artikelnummern oder Paragraphen. Die Antwort darauf ist eine zweistufige Suche: Hybrid Search sammelt Kandidaten aus lexikalischer und semantischer Suche, ein Reranker sortiert sie anschließend nach tatsächlicher Relevanz. Dieser Artikel erklärt die Bausteine, zeigt die Umsetzung in Qdrant, OpenSearch und PostgreSQL und ordnet Reranker für den Selbstbetrieb ein. Stand September 2026.

Inhaltsverzeichnis

• Warum Vektorsuche allein nicht reicht
• Die zwei Suchwege: BM25 und Dense Retrieval
• Ergebnisse zusammenführen: Reciprocal Rank Fusion
• BGE-M3: dense und sparse aus einem Modell
• Reranking mit Cross-Encoder
• Reranker im Vergleich
• Umsetzung in Qdrant, OpenSearch und PostgreSQL
• Deutsche Texte: Komposita und Kennungen
• Latenz und GPU-Bedarf

Warum Vektorsuche allein nicht reicht

Ein Embedding-Modell übersetzt Frage und Textabschnitt in Vektoren und misst deren Abstand (Was ist RAG?). Das funktioniert gut, wenn Frage und Dokument dasselbe mit anderen Worten sagen: Wer nach „Instandhaltung" fragt, findet den Abschnitt über „Wartung".

Die Schwäche zeigt sich bei Zeichenfolgen, deren Bedeutung in der exakten Schreibweise liegt. „Az. 4 K 1234/24" und „Az. 4 K 1243/24" liegen im Vektorraum nahe beieinander, bezeichnen aber zwei verschiedene Verfahren. Dasselbe gilt für Artikelnummern, Normbezeichnungen, Paragraphen, Versionsnummern und Fehlercodes. Anthropic beschreibt genau diesen Fall: Bei einer Frage nach „Error code TS-999" findet ein Embedding-Modell allgemeine Fehlerdokumentation, während BM25 die konkrete Zeichenfolge trifft (Anthropic, Contextual Retrieval).

Umgekehrt scheitert eine reine Stichwortsuche an Umschreibungen, Synonymen und Fragen in Alltagssprache. Keiner der beiden Wege deckt beide Fälle ab. In Unternehmensbeständen kommen beide ständig vor, oft in derselben Frage: „Was gilt laut § 35 BauGB für Nebengebäude im Außenbereich?"

Die zwei Suchwege: BM25 und Dense Retrieval

BM25 bewertet einen Abschnitt nach drei Größen: wie oft ein Suchbegriff darin vorkommt, wie selten der Begriff im gesamten Bestand ist (inverse Dokumentfrequenz, IDF) und wie lang der Abschnitt ist. Qdrant nennt als Standardparameter k1 = 1,2 und b = 0,75 (Qdrant, Full-Text Search). Seltene Begriffe wie ein Aktenzeichen erhalten dadurch viel Gewicht, häufige Wörter wie „Antrag" wenig.

Dense Retrieval nutzt ein Embedding-Modell, das Frage und Abschnitt in denselben Vektorraum abbildet. Welches Modell für deutsche Texte passt, vergleicht der Beitrag zu Embedding-Modellen für Deutsch.

Ergebnisse zusammenführen: Reciprocal Rank Fusion

Beide Suchwege liefern eine Trefferliste mit Scores, die nicht vergleichbar sind. Ein BM25-Score von 14,2 und eine Kosinus-Ähnlichkeit von 0,81 lassen sich nicht sinnvoll addieren. Es gibt zwei Wege, das Problem zu lösen.

Rangbasiert: Reciprocal Rank Fusion (RRF). RRF ignoriert die Scores und nutzt nur die Rangplätze. Jedes Dokument erhält je Liste den Wert 1 / (k + Rang), die Werte werden addiert:

RRF(d) = Σ 1 / (k + rang_r(d))    über alle Trefferlisten r

Das Verfahren stammt von Cormack, Clarke und Büttcher. In ihrer Arbeit auf der SIGIR 2009 wurde k = 60 in einem Pilotversuch festgelegt und danach nicht mehr verändert; die Konstante dämpft den Einfluss einzelner Ausreißer-Rankings (Cormack et al., Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods). Ein Dokument, das in beiden Listen weit oben steht, gewinnt; eines, das nur in einer Liste auftaucht, bleibt im Spiel.

Scorebasiert: Normalisierung. Die Scores jeder Liste werden auf eine gemeinsame Skala gebracht und gewichtet kombiniert. OpenSearch bietet dafür min_max, l2 und z_score als Normalisierung (OpenSearch, Normalization processor), Qdrant die Distribution-Based Score Fusion (DBSF), die Mittelwert und Standardabweichung je Liste nutzt (Qdrant, Hybrid Queries).

RRF ist der robuste Standard, weil nichts kalibriert werden muss. Die Voreinstellungen unterscheiden sich allerdings je System:

Quellen: Qdrant, Hybrid Queries, OpenSearch, Score ranker processor. Wer Ergebnisse zwischen Systemen vergleicht oder von einem zum anderen wechselt, setzt k deshalb explizit, statt sich auf den Standardwert zu verlassen.

BGE-M3: dense und sparse aus einem Modell

BGE-M3 von BAAI erzeugt in einem Durchlauf drei Darstellungen eines Textes: einen Dense-Vektor mit 1.024 Dimensionen, gelernte Termgewichte als Sparse-Vektor und Multi-Vektoren im ColBERT-Stil. Das Modell verarbeitet bis zu 8.192 Tokens, unterstützt mehr als 100 Sprachen und steht unter MIT-Lizenz.

Der Vorteil: Ein Modell liefert beide Suchwege, die Pipeline bleibt schlank. Die Modellkarte empfiehlt ausdrücklich, hybrid zu suchen und anschließend einen Reranker einzusetzen. Der Unterschied zu BM25: Die Sparse-Gewichte sind gelernt und beruhen auf dem Tokenizer des Modells, nicht auf ganzen Wörtern. Ob sie exakte Kennungen im eigenen Bestand so zuverlässig treffen wie ein klassischer BM25-Index mit passender Analyse, zeigt nur ein Test. Für Bestände mit vielen Nummern und Aktenzeichen ist ein zusätzlicher BM25-Index die sichere Wahl.

Reranking mit Cross-Encoder

Embedding-Modelle sind Bi-Encoder: Frage und Abschnitt werden getrennt in Vektoren übersetzt, verglichen wird erst danach. Das spart Rechenzeit, weil die Abschnitts-Vektoren einmal beim Indexieren entstehen. Es ist aber ungenau, weil das Modell Frage und Text nie gemeinsam sieht.

Ein Cross-Encoder liest Frage und Abschnitt als ein Paar und gibt direkt einen Relevanzwert aus (BAAI, bge-reranker-v2-m3). Er erkennt, ob ein Abschnitt die Frage tatsächlich beantwortet oder nur dieselben Begriffe verwendet. Der Preis: Für jedes Paar ist ein eigener Modelldurchlauf nötig, vorberechnen lässt sich nichts.

Daraus ergibt sich die übliche zweistufige Architektur:

1. Kandidaten sammeln. Hybrid Search liefert je Suchweg einige Dutzend Treffer, zusammengeführt per RRF.
2. Neu sortieren. Der Reranker bewertet diese Kandidaten und gibt die besten an das Sprachmodell weiter.
3. Schwelle setzen. Liegt auch der beste Kandidat unter einem festgelegten Wert, antwortet das System nicht, sondern meldet eine Lücke.

Zur Größenordnung: Anthropic holte in seinen Tests 150 Kandidaten, ließ sie neu sortieren und übergab die besten 20 an das Modell. Die Kombination aus kontextualisierten Embeddings, BM25 und Reranking senkte den Anteil fehlgeschlagener Abrufe in den Top 20 von 5,7 % auf 1,9 %, also um 67 %; ohne Reranking waren es 49 % (Anthropic, Contextual Retrieval). Wie die kontextualisierten Embeddings mit lokalem Modell entstehen, erklärt Contextual Retrieval.

Wichtig ist die Grenze: Ein Reranker sortiert nur, was die erste Stufe gefunden hat. Fehlt der richtige Abschnitt in den Kandidaten, bleibt er fehlend. Deshalb wird zuerst der Recall der Hybrid-Suche geprüft, dann die Reihenfolge.

Der Schwellenwert aus Schritt 3 ist zugleich ein wirksames Mittel gegen erfundene Antworten. bge-reranker-v2-m3 kann seine Werte per Sigmoid auf 0 bis 1 abbilden (Option normalize=True in FlagEmbedding), was eine feste Schwelle handhabbar macht. Den passenden Wert liefert kein Datenblatt, sondern eine Auswertung mit Fragen, zu denen der Bestand bewusst keine Antwort enthält.

Reranker im Vergleich

Selbst betreibbare Reranker mit mehrsprachiger Unterstützung, Stand September 2026:

Die Qwen3-Reranker arbeiten anders als klassische Cross-Encoder: Sie sind Sprachmodelle, die für jedes Paar die Wahrscheinlichkeit der Antworten „yes" und „no" berechnen. Eine Aufgabenbeschreibung (Instruction) verbessert die Ergebnisse laut Modellkarte meist um 1 bis 5 %.

Die Herstellerangaben auf der Modellkarte von Qwen3-Reranker-8B für die mehrsprachige Retrieval-Auswahl MMTEB-R (Top 100 Kandidaten aus Qwen3-Embedding-0.6B):

Das sind Werte des Herstellers auf öffentlichen Benchmarks, keine Aussage über deutsche Verwaltungs- oder Fachtexte. Sie zeigen die Richtung, ersetzen aber nicht den Test mit eigenen Fragen. Wie ein solcher Test aufgebaut wird, beschreibt RAG-Qualität messen.

Umsetzung in Qdrant, OpenSearch und PostgreSQL

Qdrant

Qdrant speichert Dense- und Sparse-Vektoren im selben Punkt. Die Query API führt mehrere Teilabfragen (prefetch) aus und fusioniert sie in der Hauptabfrage:

POST /collections/wissen/points/query
{
  "prefetch": [
    { "query": { "indices": [1042, 88731], "values": [0.61, 0.44] },
      "using": "sparse", "limit": 50,
      "filter": { "must": [{ "key": "acl", "match": { "any": ["grp-recht"] } }] } },
    { "query": [0.012, -0.087, 0.143],
      "using": "dense", "limit": 50,
      "filter": { "must": [{ "key": "acl", "match": { "any": ["grp-recht"] } }] } }
  ],
  "query": { "rrf": { "k": 60 } },
  "limit": 30
}

Den Sparse-Teil liefern entweder die Termgewichte von BGE-M3 oder BM25. Seit Version 1.15.2 kann Qdrant Text selbst in BM25-Sparse-Vektoren umwandeln (Modell qdrant/bm25); die IDF-Komponente berechnet Qdrant serverseitig, dafür muss am Sparse-Vektor der Modifier idf gesetzt sein (Qdrant, Sparse Retrieval). Die Standardanalyse von BM25 in Qdrant ist auf Englisch eingestellt, Sprache, Stemming und Stoppwörter sind konfigurierbar (Qdrant, Full-Text Search). Den Reranker ruft die Anwendung danach separat auf.

OpenSearch

OpenSearch bringt einen vollwertigen BM25-Index mit Sprachanalyse mit und kombiniert ihn über die hybrid-Abfrage mit einer k-NN-Suche. Die Fusion übernimmt eine Search Pipeline:

PUT /_search/pipeline/rrf-pipeline
{
  "phase_results_processors": [
    { "score-ranker-processor": { "combination": { "technique": "rrf", "rank_constant": 60 } } }
  ]
}

GET /wissen/_search?search_pipeline=rrf-pipeline
{
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "text": "Kündigungsfrist Rahmenvertrag 2024-117" } },
        { "knn": { "embedding": { "vector": [0.012, -0.087, 0.143], "k": 50 } } }
      ]
    }
  }
}

Eine hybrid-Abfrage fasst bis zu fünf Teilabfragen zusammen (OpenSearch, Hybrid query). Reranking ist direkt in der Pipeline möglich: Der rerank-Prozessor ruft seit Version 2.12 ein in OpenSearch registriertes Cross-Encoder-Modell auf (OpenSearch, Rerank processor).

PostgreSQL mit pgvector

Wer bereits PostgreSQL betreibt, kann Volltextsuche (tsvector) und pgvector in einer Abfrage kombinieren. Die pgvector-Dokumentation nennt für das Zusammenführen ausdrücklich RRF oder einen Cross-Encoder. RRF lässt sich direkt in SQL formulieren:

-- Spalte: tsv tsvector GENERATED ALWAYS AS (to_tsvector('german', text)) STORED, mit GIN-Index
WITH semantisch AS (
  SELECT id, RANK() OVER (ORDER BY embedding <=> $1) AS rang
  FROM chunks ORDER BY embedding <=> $1 LIMIT 50
),
lexikalisch AS (
  SELECT id, RANK() OVER (ORDER BY ts_rank_cd(tsv, q) DESC) AS rang
  FROM chunks, websearch_to_tsquery('german', $2) q
  WHERE tsv @@ q
  ORDER BY ts_rank_cd(tsv, q) DESC LIMIT 50
)
SELECT COALESCE(s.id, l.id) AS id,
       COALESCE(1.0 / (60 + s.rang), 0) + COALESCE(1.0 / (60 + l.rang), 0) AS rrf
FROM semantisch s
FULL OUTER JOIN lexikalisch l ON s.id = l.id
ORDER BY rrf DESC LIMIT 30;

Eine Einschränkung: ts_rank und ts_rank_cd sind kein BM25. Sie verwenden laut PostgreSQL-Dokumentation keine globalen Informationen, also keine inverse Dokumentfrequenz. Für RRF, das nur Rangplätze nutzt, reicht das häufig. Echtes BM25 liefern Erweiterungen wie pg_textsearch (PostgreSQL-Lizenz) oder pg_search von ParadeDB (AGPL-3.0). pgvector selbst unterstützt mit sparsevec auch Sparse-Vektoren mit bis zu 1.000 von null verschiedenen Einträgen, etwa für die Termgewichte von BGE-M3.

Die Grundsatzentscheidung zwischen dedizierter Vektordatenbank und Postgres-Erweiterung vertieft Qdrant vs. pgvector. Unabhängig vom System gilt: Der Rechtefilter gehört in jede Teilabfrage, nicht erst hinter die Fusion (RAG mit Berechtigungen).

Deutsche Texte: Komposita und Kennungen

Für deutsche Bestände entscheidet die Textanalyse des lexikalischen Teils über die Qualität. Drei Punkte fallen regelmäßig auf.

Komposita. „Instandhaltungsrahmenvertrag" ist für BM25 ein einziger Term. Eine Suche nach „Rahmenvertrag Instandhaltung" trifft ihn nicht. OpenSearch bietet dafür die Filter dictionary_decompounder und hyphenation_decompounder, die zusammengesetzte Wörter anhand einer Wortliste oder Silbentrennungsmustern in Bestandteile zerlegen und ausdrücklich für Sprachen wie Deutsch gedacht sind (OpenSearch, Dictionary decompounder). In PostgreSQL können Ispell-Wörterbücher Komposita zerlegen (PostgreSQL, Dictionaries), der mitgelieferte Snowball-Stemmer für german tut das nicht.

Kennungen. Standard-Tokenizer zerlegen „4 K 1234/24" oder „A-4711-03" an Schrägstrich und Bindestrich in einzelne Zahlen. Dann trifft die Suche jedes Dokument, in dem „1234" und „24" irgendwo vorkommen. Bewährt hat sich, Kennungen beim Indexieren per Muster zu erkennen und zusätzlich unverändert in einem eigenen Feld abzulegen, das exakt durchsucht oder als Filter genutzt wird.

Stemming und Stoppwörter. Ein deutscher Analysator führt „Anträge", „Antrags" und „Antrag" auf eine Stammform zurück und entfernt Füllwörter. Ohne diese Einstellung verliert BM25 im Deutschen viel Trefferquote. Wie Dokumente vor der Indexierung sinnvoll zerlegt werden, damit Abschnitte ihre Kennungen und Überschriften behalten, beschreibt Chunking für RAG.

Latenz und GPU-Bedarf

Hybrid Search selbst kostet wenig: Beide Suchwege laufen parallel auf Indizes, die Fusion ist eine Summe über Rangplätze. Die Rechenlast entsteht an zwei Stellen: beim Embedding der Frage und beim Reranking.

Der Reranker bewertet jedes Kandidatenpaar einzeln. Die Rechenzeit wächst damit linear mit der Zahl der Kandidaten und mit ihrer Länge. Stellschrauben sind die Kandidatenzahl nach der Fusion, die maximale Abschnittslänge und die Modellgröße.

Die Werte ergeben sich aus der Parameterzahl mal zwei Byte; Aktivierungen und Stapelverarbeitung kommen hinzu. Für den Betrieb gibt es zwei verbreitete Server: Text Embeddings Inference von Hugging Face unterstützt Reranker auf XLM-RoBERTa-Basis wie bge-reranker-v2-m3 und läuft auch auf CPU. vLLM stellt eine Rerank-Schnittstelle unter /rerank, /v1/rerank und /v2/rerank bereit, kompatibel zu den Rerank-APIs von Jina und Cohere (vLLM, Online Serving); die Qwen3-Reranker benötigen dort beim Start eine Architektur-Angabe über hf_overrides.

Auf einem GPU-Server teilen sich Sprachmodell, Embedding-Modell und Reranker den Grafikspeicher. Wie viel davon das Sprachmodell selbst braucht, rechnet GPU- und VRAM-Sizing für LLMs durch.

Was das für Ihr Projekt heißt

Hybrid Search ist für Unternehmensbestände der sinnvolle Standard, sobald Kennungen, Nummern oder Fachbegriffe eine Rolle spielen, und das ist fast immer der Fall. Reranking lohnt sich, wenn die richtige Stelle zwar gefunden wird, aber zu weit hinten landet. Beides lässt sich nur mit eigenen Referenzfragen beurteilen: erst messen, ob der richtige Abschnitt unter den Kandidaten ist, dann, ob er vorne steht.

Wir setzen dafür auf den Bestand, der ohnehin betrieben wird: PostgreSQL mit pgvector, wo Postgres gesetzt ist, Qdrant oder OpenSearch, wo Vektor- oder Volltextsuche im Mittelpunkt steht. Modelle laufen lokal auf dem AI Cube oder auf Managed GPU-Servern von WZ-IT mit NVIDIA RTX PRO 4000 Blackwell (24 GB) oder RTX PRO 6000 Blackwell (96 GB). Support, Beratung und Implementierung durch WZ-IT.

Wie RAG grundsätzlich funktioniert, erklärt Was ist RAG?. Die Vorstufen der Suche behandeln Chunking für RAG und Contextual Retrieval, die Messung der Ergebnisse RAG-Qualität messen. Welche Embedding-Modelle für deutsche Texte in Frage kommen, vergleicht der Beitrag Embedding-Modelle für Deutsch, und wie Rechte vor der Suche greifen, zeigt RAG mit Berechtigungen.