Ich sehe immer wieder Beiträge, die semantische Suche als die Lösung für Retrieval anpreisen. Das ist sie nicht — sie ist nur die halbe Lösung.
Hier ist der Fehlerfall, den niemand in diesen Beiträgen zeigt: Ein Bi-Encoder bildet Bedeutung ab, nicht exakte Token. Bittet man ihn, den „Fehlercode E-4471" zu finden, liefert er bereitwillig Dokumente über „Fehlercodes" und „Hardwarefehler" — semantisch nah, aber nutzlos für den Ingenieur, der genau das eine Dokument mit dieser exakten Zeichenfolge braucht. Produkt-SKUs, Abkürzungen, Teilenummern, Fehlercodes — überall dort, wo exakte Übereinstimmung zählt, beginnt die reine Vektorsuche still zu versagen. Nicht laut. Still. Sie liefert etwas plausibel Aussehendes — genau das macht sie in der Produktion gefährlich.
BM25 hat dieses Problem nicht. Es ist jahrzehntealt, unglamourös, keyword-basiert — und findet „E-4471" jedes Mal. Aber BM25 allein ist blind für Umschreibungen: Fragt man nach „das System sicher herunterfahren", während das Dokument „geordnetes Beendigungsverfahren" sagt, geht der Treffer komplett verloren.
Keines von beiden ist falsch. Sie irren sich nur an unterschiedlichen Stellen. Das ist das eigentliche Argument für Hybrid Search — nicht „mehr ist besser", sondern „diese beiden Fehlermuster überschneiden sich nicht".
Der Teil, der schwieriger korrekt umzusetzen ist, als man annimmt: BM25- und Bi-Encoder-Scores liegen auf unterschiedlichen Skalen. Man kann sie nicht einfach addieren. Reciprocal Rank Fusion umgeht das Skalierungsproblem vollständig — die Fusion erfolgt auf Basis der Rangposition in jeder Liste, nicht des Rohwerts, was die Kombination zweier strukturell unterschiedlicher Retrieval-Methoden tatsächlich fundiert macht statt nur ein Hack zu sein.
Ich habe diese Pipeline vollständig gegen einen festen Korpus und einen festen Query-Satz aufgebaut, gezielt um den Fehlerfall zu messen, statt ihn nur zu behaupten: naives Bi-Encoder-Retrieval versagt bei Exact-Match-Queries, BM25 fängt sie auf, RRF-Fusion kombiniert beide, ohne dass eine die andere dominiert, und ein Cross-Encoder reranked die fusionierten Kandidaten für die Queries, bei denen die Rangfolge tatsächlich zählte.
Nichts davon ist exotisch. Es ist auch nichts, das man durch die Wahl einer Vektordatenbank mit hübscher Oberfläche abkürzen kann. Wenn Ihr RAG-System nur einen Bi-Encoder enthält, haben Sie bereits einen blinden Fleck — Sie sind nur noch nicht auf die Query gestoßen, die ihn offenlegt.