In OCR, Chunking und Vektordatenbank (Teil 4) haben wir aus deinen PDFs saubere Textstücke gemacht, jedes per Embedding-Modell in einen Vektor verwandelt und in einer Vektordatenbank abgelegt. Am Ende bekamst du zu einer Frage die inhaltlich ähnlichsten Chunks zurück – die klassische Vektorsuche. Genau hier hören die meisten Anleitungen auf – und hier scheitern die meisten Systeme. Wer nur auf Bedeutungsähnlichkeit setzt, baut einen Assistenten, der bei der ISO-Norm richtig antwortet, aber die Artikelnummer daneben legt. In diesem Teil zeige ich dir, warum das so ist und wie du mit zwei Schritten – Hybrid Search und Reranking – den größten Qualitätssprung deiner Pipeline holst.
Wo die reine Vektorsuche blind wird
Die semantische Suche arbeitet wie ein belesener Bibliothekar, der nach Bedeutung sortiert. Fragst du nach „Fristen bei einer Datenpanne“, findet sie auch „Meldepflicht innerhalb von 72 Stunden“ – obwohl kein einziges Wort übereinstimmt. Das ist ihre Stärke: Synonyme und Umschreibungen versteht sie mühelos.
Diese Stärke kippt, sobald es auf das exakte Zeichen ankommt. Eine Artikelnummer wie WGS-4711, eine Normbezeichnung wie DIN EN ISO 9001, ein Fehlercode, ein Lieferantenname – all das hat keine „Bedeutung“, die sich sinnvoll im geometrischen Raum einordnen ließe. Anthropic beschreibt das einprägsam: Fragst du nach „Error code TS-999“, findet ein Embedding-Modell zwar allerlei über Fehlercodes im Allgemeinen, verfehlt aber womöglich genau die Stelle, an der TS-999 steht. Das ist auch wissenschaftlich belegt: Sciavolino und Kollegen zeigten 2021 mit dem Datensatz EntityQuestions, dass dichte Retriever – also die embeddingbasierte Vektorsuche – bei einfachen, entitätszentrierten Fragen systematisch schlechter abschneiden als die klassische Stichwortsuche. Sie generalisieren nur auf häufige Begriffe – der seltene Eigenname aus deinem Nischenkatalog gehört nicht dazu.
Microsoft benennt in seiner Azure-Dokumentation dieselben Fälle konkret: Produktcodes, hochspezialisierter Fachjargon, Datumsangaben und Personennamen werden von der Keyword-Suche besser getroffen, weil sie exakte Übereinstimmungen erkennt. Das ist dein Alltag – in Instandhaltung, Qualitätssicherung und Vertriebsinnendienst.
BM25: die alte Stichwortsuche, mathematisch sauber
Die Antwort darauf ist keine neue Erfindung, sondern ein Klassiker: BM25. Die Abkürzung steht für „Best Matching“; die 25 ist keine geheimnisvolle Kennzahl, sondern schlicht die 25. Formelvariante aus dem Okapi-Projekt der City University London, entwickelt in den 1970er- und 1980er-Jahren unter anderem von Stephen Robertson und Karen Spärck Jones.
BM25 bewertet einen Treffer nicht nach Bedeutungsnähe, sondern nach drei nüchternen Größen: wie oft der Suchbegriff im Textstück vorkommt (Term Frequency), wie selten er im gesamten Bestand ist (Inverse Document Frequency) und wie lang das Textstück im Verhältnis zur durchschnittlichen Länge ausfällt. Ein Detail hebt es vom simplen TF-IDF ab: Die Häufigkeit geht gesättigt ein – das zehnte Vorkommen eines Worts erhöht den Score deutlich weniger als das zweite. Zwei Stellschrauben (üblich k₁ zwischen 1,2 und 2,0 sowie b = 0,75) steuern das, aber die musst du im Alltag nie anfassen.
Wichtig: BM25 ist ein reines „Bag of Words“-Verfahren. Es kennt weder Wortreihenfolge noch Bedeutung, es zählt nur Zeichenketten und deren Statistik. Genau deshalb findet es WGS-4711 zuverlässig – und aus demselben Grund ist es blind für Synonyme. Vektorsuche und BM25 sind also keine Konkurrenten, sondern zwei Werkzeuge mit spiegelbildlichen Stärken.
Hybrid Search: zwei Listen, eine Rangfolge
Hybrid Search heißt schlicht: Du lässt beide Verfahren parallel auf denselben Chunks laufen. Knifflig ist nur das Zusammenführen, denn beide rechnen auf völlig verschiedenen Skalen. Ein BM25-Score hat laut Microsoft nach oben keine Grenze, während die Cosinus-Ähnlichkeit der Vektorsuche – ein Maß dafür, wie nah zwei Vektoren im Raum liegen – in Azures normalisierter Bewertung zwischen etwa 0,33 und 1,00 liegt. Die Zahlen einfach zu addieren, wäre wie Kilometer und Kilogramm zusammenzuzählen.
Die etablierte Lösung heißt Reciprocal Rank Fusion, kurz RRF, aus einem Paper von Cormack, Clarke und Büttcher (2009). Der Trick: RRF ignoriert die Scores komplett und schaut nur auf die Rangplätze. Jeder Chunk bekommt pro Liste den Wert 1 geteilt durch (Rangposition plus eine Konstante k), diese Beiträge werden über beide Listen aufsummiert, und nach der Summe wird neu sortiert. Weil nur Ränge zählen, spielt die unvergleichbare Skala keine Rolle mehr – das ist der ganze Grund, warum RRF für Hybrid Search taugt. Die Konstante k wurde im Originalpaper einmal auf 60 gesetzt und nie wieder verändert; die Autoren zeigen selbst, dass die Wahl unkritisch ist, und Microsoft empfiehlt bis heute denselben kleinen Wert.
Der schöne Effekt ist keine Faustregel, sondern eine Eigenschaft der Summenbildung: Ein Chunk, der in beiden Listen auftaucht, sammelt zwei Reziprok-Rang-Beiträge ein, ein Chunk aus nur einer Liste nur einen. Doppelt bestätigte Relevanz setzt sich damit systematisch nach vorne – der Chunk, der zugleich inhaltlich passt und die exakte Artikelnummer enthält, wandert an die Spitze. In einer Postgres-Umgebung wie Supabase ist das buchstäblich nur eine Datenbankfunktion: Volltextsuche und pgvector, per FULL OUTER JOIN zusammengeführt und per RRF verrechnet. In Suchmaschinen wie Azure AI Search oder Elasticsearch steckt dieselbe Logik in der Engine.
Reranking: das zweite, genauere Modell sortiert nach echter Relevanz
Selbst die beste Hybrid Search liefert nur eine grobe Vorauswahl – vielleicht 20, 50 oder mehr Chunks, die passen könnten. Diese Liste direkt ans Sprachmodell zu geben, wäre verschenktes Potenzial. Hier kommt der Reranker ins Spiel: ein eigenständiges, dediziertes Modell – kein Embedding-Modell und kein Sprachmodell, sondern eine eigene Klasse mit eigener API.
Der Unterschied liegt in der Architektur. Dein Embedding-Modell ist ein Bi-Encoder: Es verarbeitet Frage und Dokument getrennt zu je einem Vektor, die dann geometrisch verglichen werden. Ein Reranker ist ein Cross-Encoder: Er bekommt Frage und Chunk gemeinsam als eine Eingabe, beide „sehen“ sich im selben Durchlauf, und heraus kommt ein einziger Relevanzwert – ganz ohne Vektoren. Das macht ihn präziser – kostet ihn aber die Vorberechenbarkeit: Er lässt sich weder vorberechnen noch indexieren. Ihm muss zwingend eine Vorauswahl vorgeschaltet sein, denn er skaliert nicht: Die Sentence-Transformers-Doku rechnet vor, dass ein Cross-Encoder, der alle 10.000 Sätze paarweise vergleicht – rund 50 Millionen Vergleiche –, dafür etwa 65 Stunden braucht, ein Bi-Encoder dagegen rund fünf Sekunden. Daher das bewährte Muster: erst günstig vorfiltern (Hybrid Search), dann teuer und genau neu sortieren. Das Reranking läuft dabei nach der RRF-Fusion, nicht an ihrer Stelle.
Wie viele Kandidaten du vor das Reranking stellst, ist kein Naturgesetz. Anthropic ruft in seiner Auswertung 150 Chunks ab und dampft per Reranker auf die besten 20 ein; die Sentence-Transformers-Doku nennt die Top 100. Nimm das als Orientierung, nicht als feste Zahl. Und die Relevanzwerte sind nicht linear lesbar: Cohere normalisiert sie auf 0 bis 1, aber ein Wert von 0,91 heißt nicht „doppelt so relevant“ wie 0,45. Verlässlich ist die Rangfolge, nicht der absolute Wert.
Warum Hybrid Search und Reranking den größten Sprung bringen
Dass Reranking kein Modetrend ist, zeigt die Geschichte: Schon 2019 wiesen Nogueira und Cho nach, dass ein Cross-Encoder auf den per BM25 abgerufenen Top-1.000-Passagen den damaligen Stand der Technik deutlich übertraf. Anthropics eigene Messung macht den Effekt beider Schritte greifbar: Die Fehlerrate beim Abruf der besten 20 Chunks sank von 5,7 Prozent auf 3,7 Prozent allein durch bessere Embeddings, auf 2,9 Prozent durch die Kombination mit BM25 – und auf 1,9 Prozent, sobald ein Reranker dazukam. Das ist eine Reduktion um rund zwei Drittel, wohlgemerkt in diesem Aufbau; eine allgemeingültige Prozentzahl gibt es nicht.
Der breit angelegte BEIR-Benchmark, der zehn Retrieval-Systeme über 18 Datensätze verglich, bestätigt beide Bausteine nüchtern: BM25 sei „ein robuster Ausgangswert“, und Reranking-Modelle erzielten im Mittel die besten Ergebnisse ohne domänenspezifisches Training – ausdrücklich aber „zu hohen Rechenkosten“. Dieser Kostenaspekt gehört ehrlich dazu. Für die drei bis vier Chunks, die am Ende in dein Sprachmodell wandern, lohnt sich die zusätzliche Latenz fast immer – für Millionen Vektoren im Index wäre sie unbezahlbar. Deshalb steht der Reranker ganz am Ende, auf einer kleinen Vorauswahl.
Selbst trainieren musst du dafür nichts. OpenRouter bündelt (Stand Juli 2026) eine Handvoll dedizierter Rerank-Modelle hinter einem Endpunkt, überwiegend von Cohere – darunter Rerank 4 mit rund 33K Kontext und das ältere v3.5, das ausdrücklich auf über 100 Sprachen inklusive Deutsch trainiert ist und damit für deutschsprachige Dokumente taugt. Wer selbst hosten will, findet Alternativen wie den BGE Reranker v2-m3, Qwen3-Reranker oder Modelle von Jina AI und Voyage AI.
Was das für deinen Praxiseinsatz heißt
Für ein produktives Wissenssystem im Mittelstand gilt: Vektorsuche allein reicht nicht, sobald exakte Bezeichner im Spiel sind – und die stecken bei dir überall. Die Kombination aus semantischer Suche, BM25 und Reranker nennt man häufig Advanced RAG (Retrieval-Augmented Generation – erst suchen, dann das Sprachmodell antworten lassen), im Gegensatz zum naiven RAG aus reiner Vektorsuche. Erprobt ist sie, aber die Details – Embedding-Modell, Kandidatenzahl, Reranker, tolerierbare Latenz – entscheiden über Qualität und Kosten. Genau daran arbeite ich mit Unternehmen in meiner KI-Beratung und beim Aufbau maßgeschneiderter Wissens-KI-Systeme.
Häufige Fragen
Was ist der Unterschied zwischen Vektorsuche und Hybrid Search?
Hybrid Search kombiniert zwei Suchverfahren: die semantische Vektorsuche, die nach Bedeutung findet, und die Stichwortsuche BM25, die exakte Zeichenketten trifft. Reine Vektorsuche versteht Synonyme, verfehlt aber Artikelnummern und Normbezeichnungen. Hybrid Search führt beide Trefferlisten zusammen und deckt so beide Fälle ab.
Kann ich BM25 weglassen, wenn mein Embedding-Modell gut genug ist?
Nein, das ist unabhängig von der Modellqualität. Ein Embedding-Modell bildet Bedeutung ab; exakte Zeichenketten wie Artikelnummern oder Normbezeichnungen haben keine sinnvolle Bedeutungsrepräsentation. Sciavolino und Kollegen haben das systematisch gezeigt: Dichte Retriever schneiden bei seltenen Eigennamen strukturell schlechter ab als BM25. Kein besseres Embedding-Modell behebt diese blinde Stelle – nur ein zweites Verfahren, das auf exakte Übereinstimmung achtet, tut es.
Was ist der Unterschied zwischen Embedding-Modell und Reranker?
Das Embedding-Modell (ein Bi-Encoder) verarbeitet Frage und Dokument getrennt zu je einem Vektor und vergleicht diese geometrisch – schnell und vorberechenbar, weshalb es den ganzen Index füllt. Der Reranker (ein Cross-Encoder) bekommt Frage und Chunk gemeinsam und liefert einen präzisen Relevanzwert, kann aber nichts vorberechnen und arbeitet nur auf einer kleinen Vorauswahl. Das eine sorgt für Reichweite, das andere für Genauigkeit.
Kann ich das Embedding-Modell nachträglich wechseln?
Nur um den Preis einer kompletten Neuberechnung. Ein Bi-Encoder bildet Frage und Dokumente in denselben Vektorraum ab, und die Ähnlichkeit wird rein geometrisch bestimmt. Vektoren aus zwei verschiedenen Modellen liegen in verschiedenen Räumen und sind nicht vergleichbar. Deshalb musst du im Retrieval dasselbe Modell nutzen wie beim Indexieren – und wenn du es wechselst, deinen kompletten Index neu berechnen.
Fazit
Die Suchphase entscheidet über die Qualität deines gesamten KI-Wissenssystems – nicht das Sprachmodell am Ende, wie schon Teil 1 dieser Serie gezeigt hat. Reine Vektorsuche versteht Bedeutung, BM25 trifft exakte Zeichenketten; Hybrid Search führt beide über Reciprocal Rank Fusion zusammen, ohne unvergleichbare Scores zu addieren, und ein Reranker sortiert die Vorauswahl nach echter Relevanz. Diese zwei Schritte heben die Trefferqualität am stärksten – belegbar, wenn auch nie mit einer allgemeingültigen Prozentzahl.
Das reicht für die allermeisten Wissenssysteme im Mittelstand aus. Es gibt aber Fragen, bei denen selbst die beste Bedeutungs- und Stichwortsuche an Grenzen stößt – solche, die über mehrere logische Sprünge zwischen verschiedenen Objekten beantwortet werden müssen: Wer war 2023 für ein Projekt bei Kunde X verantwortlich, in dem ein Vertrag mit einer bestimmten Klausel zum Einsatz kam? Dafür braucht es eine andere Architektur. Wie Knowledge Graphs und GraphRAG solche Zusammenhänge abbilden, liest du in Knowledge Graphs und GraphRAG (Teil 6). Willst du dein Wissenssystem nicht selbst bauen, sondern sauber aufgesetzt produktiv nutzen, unterstütze ich dich als KI-Berater aus Aalen dabei – nimm einfach Kontakt auf.