24.05.2026 AI Engineering6 Minuten Lesezeit

Hybrid Retrieval ist die Produktions-Baseline

Reine Vektorsuche verfehlt exakte Identifier, Fehlercodes und seltene Begriffe. Die belastbare Produktions-Baseline für RAG kombiniert deshalb BM25 und Dense Embeddings per Reciprocal Rank Fusion und ordnet die Kandidaten anschließend mit einem Cross-Encoder neu. Wir prüfen Genauigkeitsgewinne, Latenzkosten und die Herkunft der 70-Prozent-Behauptung — und markieren klar die Grenzen des Ansatzes.

Warum reine Vektorsuche in Produktion scheitert

Dense Retrieval kodiert Anfragen und Dokumente als Vektoren und sortiert sie nach Ähnlichkeit. Seine Stärke und seine Schwäche haben dieselbe Ursache: Das Embedding-Modell verdichtet Bedeutung zu Geometrie. Zeichenketten ohne verteilte Bedeutung — Bestellnummern, Artikelcodes oder Fehlercodes wie ERR_CONN_RST — erhalten darin keinen stabilen Ort. Statt des Dokuments mit dem exakten Token erscheint ein semantisch benachbarter Treffer. Für einen Support-Bot oder eine Vertragssuche ist "benachbart" nicht ausreichend.

Diese Schwäche ist dokumentiert, nicht anekdotisch. Der BEIR-Benchmark (Thakur et al., 2021) zeigte, dass auf MS MARCO trainierte Dense-Retriever BM25 im Zero-Shot-Einsatz auf fremden Domänen häufig nicht schlagen. Die Schwäche bleibt zudem leicht unsichtbar: Evaluationssets entstehen meist aus Anfragen, die bereits funktionieren. Identifier-lastige Anfragen tauchen dann in Produktion als Halluzinationsbeschwerden auf, die im Eval niemand reproduzieren kann.

Zwei Retriever mit komplementären Fehlermodi

BM25 (Robertson et al., 1994) ist eine lexikalische Ranking-Funktion: Sie bewertet exakte Termübereinstimmung, gewichtet Terme über inverse Dokumentfrequenz, sättigt die Termfrequenz und normalisiert auf Dokumentlänge. BM25 findet SKU-4471 mit Sicherheit und scheitert an Paraphrasen — eine Anfrage zur "Beendigung eines Vertrags" trifft kein Dokument, das nur "Kündigung" sagt. Dense Retrieval invertiert dieses Profil: robust gegenüber Synonymen und mehrsprachiger Formulierung, blind für literale Identifier.

Entscheidend ist, dass beide Systeme bei unterschiedlichen Anfragen irren. Elastics Hybrid-Retrieval-Studie maß auf BEIR-Datensätzen eine so geringe Überlappung zwischen BM25- und semantischen Ergebnissen, dass ihre Fusion Dokumente zurückholte, die jedes Verfahren allein verpasst hatte. Nicht die isolierte Stärke eines Retrievers, sondern die Unabhängigkeit ihrer Fehlermodi begründet hybrides Retrieval.

Reciprocal Rank Fusion als Standard-Fusion

Reciprocal Rank Fusion (Cormack, Clarke und Büttcher, SIGIR 2009) fusioniert Rankinglisten allein über die Rangposition: score(d) = Σ 1/(k + rank_i(d)), mit k = 60 als Konvention. Da BM25-Scores unbeschränkt sind und Kosinus-Ähnlichkeiten in [-1, 1] liegen, ist jede direkte Score-Mischung konstruktionsbedingt falsch kalibriert. RRF liest die Scores nie — es braucht keine Normalisierung, keine gelabelten Daten und kein Nachjustieren beim Wechsel des Embedding-Modells.

Die gemessenen Zugewinne sind real, aber moderat. Elastic berichtet für RRF +1,4 % durchschnittliches NDCG@10 gegenüber dem eigenen Learned-Sparse-Modell (ELSER) allein und +18 % gegenüber BM25 allein auf BEIR-Daten. Auf dem WANDS-Produktsuche-Benchmark (Turnbull, März 2025) erzielte BM25 0,698 NDCG, Dense 0,695, reines RRF 0,707 — und ein domänenspezifisch getuntes Hybrid 0,750, ein Zugewinn von ~7,4 %. Ehrlich gelesen: Der Wert von RRF ist Robustheit über Anfragetypen hinweg, nicht ein großer Durchschnittsgewinn. Die großen Sprünge liefert die nächste Stufe.

Cross-Encoder-Reranking im Jahr 2026

Ein Cross-Encoder bewertet jedes Anfrage-Dokument-Paar in einem einzigen Forward-Pass mit voller Attention über beide Texte. Das ist genauer als jede Bi-Encoder-Ähnlichkeit — und zu langsam für ein ganzes Korpus. Er läuft deshalb nur über die 30 bis 100 besten fusionierten Kandidaten. Das Angebot 2026 ist überschaubar:

Der Zugewinn ist gegen die erste Stufe messbar: jina-reranker-v3 hebt BEIR nDCG@10 von 55,81 (eigene First-Stage-Embeddings) auf 61,85. Qwen3-Reranker-4B hebt den MTEB-Retrieval-Wert seiner 0,6B-Embedding-Stufe von 61,82 auf 69,76. Sechs bis acht nDCG-Punkte sind derzeit das, was ein guter Reranker einbringt — mehr als jedes Fusion-Tuning je liefern wird.

Gemessene Zugewinne und Latenzkosten

Anthropics Contextual-Retrieval-Evaluation (September 2024) ist die sauberste gestapelte Messung, die vorliegt. Baseline-Embeddings verfehlten den relevanten Chunk in den Top 20 bei 5,7 % der Anfragen. Kontextualisiertes BM25-Hybrid senkte das auf 2,9 % (−49 %); ein zusätzlicher Reranker auf 1,9 % — eine Reduktion der Retrieval-Fehler um 67 %. Eine Diagnostik-Studie von 2026 auf dem LoCoMo-Benchmark zeigt in dieselbe Richtung: Hybrides Retrieval mit Reranking senkte Retrieval-Fehler auf 11,4 % der Fragen — gegenüber 35,3 % mit BM25 allein und 15,8 % mit reiner Kosinus-Suche.

Die Kosten sind Latenz und Geld. Anthropics Contextual-Embeddings-Cookbook maß rund 100-200 ms Zusatzlatenz pro Anfrage für Reranking, abhängig von der Kandidatenmenge. Agentsets Benchmark vom Dezember 2025 maß Cohere Rerank 4 Fast bei ~447 ms und Rerank 4 Pro bei ~614 ms mittlerer Latenz pro Request auf dessen Harness. Der Reranker ist die teuerste Millisekunde der Pipeline — genau deshalb sieht er 50 Kandidaten und nicht 5.000.

Woher die 70-Prozent-Behauptung stammt

Die Behauptung, "rund 70 % der RAG-Fehler entstehen beim Retrieval", kursiert in Varianten mit 70, 72 und 73 % und wird meist Barnett et al. zugeschrieben: "Seven Failure Points When Engineering a RAG System" (arXiv:2401.05856, Januar 2024). Das Paper definiert sieben Fehlerpunkte — die meisten vor der Generierung —, nennt jedoch keinerlei prozentuale Verteilung. Wir konnten die Zahl auf keine Primärmessung zurückführen; sie ist Folklore im Zitatkostüm.

Die zugrunde liegende Richtung hält der Prüfung dennoch stand. In der LoCoMo-Diagnostik dominierten Retrieval-Fehler je nach Konfiguration bei 11-46 % aller Fragen; Nutzungsfehler blieben dagegen bei 4-8 %, Widersprüche zum abgerufenen Kontext unter 1,4 %. Für die Praxis genügt ein Orakel-Test: Geben Sie dem Modell den korrekten Chunk direkt. Wird die Antwort dadurch richtig, liegt der Engpass im Retrieval — unabhängig von einem vermeintlich universellen Prozentsatz.

Chunking in der Praxis

Chunking entscheidet, was ein Retriever überhaupt finden kann. Der pragmatische Standard ist rekursives Splitten: an Absatzgrenzen teilen, auf Sätze ausweichen, dann auf Zeichen, bis jeder Chunk eine Zielgröße von einigen hundert Token erreicht. Das respektiert Dokumentstruktur bei nahezu null Kosten und ist der Default der meisten Frameworks. Fixes Splitten ohne Strukturbewusstsein ist strikt schlechter; aufwendiges semantisches Chunking lohnt sich nach unserer Erfahrung selten, bevor der Rest der Pipeline steht.

Contextual Retrieval (Anthropic, September 2024) ist das eine Chunking-Upgrade mit belastbaren publizierten Zahlen: Ein LLM stellt jedem Chunk vor dem Embedding und der BM25-Indizierung eine kurze einordnende Beschreibung voran. Kontextuelle Embeddings allein senkten die Top-20-Fehlerrate um 35 % (von 5,7 % auf 3,7 %). Die Kosten fallen bei der Ingestion an, nicht zur Anfragezeit; Prompt Caching reduziert sie weiter — ein günstiger Tausch für langsam wachsende Korpora.

Wann Hybrid nicht ausreicht

Hybrides Retrieval repariert das Ranking von Evidenz, die bereits als einzelner Chunk existiert. Es erzeugt keine Evidenz und schließt nicht über Chunks hinweg. Vier Regeln markieren die Grenze: 1) Steht die Antwort nicht im Korpus — Barnett et al.s erster Fehlerpunkt — hilft kein Retriever; erkennen Sie fehlenden Inhalt, statt härter zu ranken. 2) Aggregiert die Frage ("alle Verträge mit Klausel X"), ist Top-k das falsche Primitiv; Sie brauchen eine strukturierte Abfrage über extrahierte Felder.

3) Verlangt die Antwort eine Multi-Hop-Komposition über Dokumente, die nie gemeinsam ranken, scheitert Single-Shot-Retrieval strukturell. Dann braucht es iterative, agentische oder graphgestützte Verfahren; die Traversierung typisierter Relationen zwischen Entitäten liegt oberhalb der Hybrid-Schicht und ersetzt sie nicht. 4) Passt der gesamte Korpus bequem in das Kontextfenster eines Frontier-Modells und bleibt das Anfragevolumen gering, kann die Retrieval-Maschinerie mehr kosten, als sie spart. Hybrid ist die Baseline, nicht die Obergrenze.

Ausblick: Die Stufen verschmelzen

Die dreistufige Form — zwei günstige Recall-Stufen, ein Fusionsschritt, eine präzise Ranking-Stufe — ist stabil. Die Stufen selbst verschmelzen. jina-reranker-v3 verarbeitet bereits bis zu 64 Kandidatendokumente in einem einzigen 131k-Token-Fenster und verwischt die Grenze zwischen Reranking und Lesen. Qwen3s instruktionsbewusste Reranker machen Ranking zu einem steuerbaren Schritt statt einer festen Funktion. Wir erwarten, dass Fusion und Reranking in einzelne Listwise-Modelle kollabieren — und dass Retrieval zu einer Entscheidung wird, die ein Agent pro Aufgabe mehrfach trifft statt einmal pro Anfrage.

Zwei Konstanten bleiben: Exakte Identifier benötigen lexikalisches Matching, und belastbare Evaluation benötigt eigene gelabelte Anfragen. Bauen Sie daher zuerst die hybride Baseline, messen Sie anschließend die Fehlerverteilung und ergänzen Sie nur dort weitere Mechanik, wo die Daten einen Engpass zeigen. Diese Reihenfolge prägt die Retrieval-Qualität in Produktion stärker als jede einzelne Modellwahl des Jahres 2026.

Quellen

• Anthropic: Introducing Contextual Retrieval
• Cormack, Clarke, Büttcher: Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods (SIGIR 2009)
• Elastic Search Labs: Improving Information Retrieval in the Elastic Stack — Hybrid Retrieval
• Cohere: Introducing Rerank 4
• jina-reranker-v3: Last but Not Late Interaction for Listwise Document Reranking (arXiv:2509.25085)
• Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models (arXiv:2506.05176)
• Barnett et al.: Seven Failure Points When Engineering a RAG System (arXiv:2401.05856)
• Diagnosing Retrieval vs. Utilization Bottlenecks in LLM Agent Memory (arXiv:2603.02473)