The Second Pass

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Was konkret zu tun ist, wenn die Retrieval-Metriken zeigen, dass der Retriever das Problem ist.

🎚️ Soundcheck

In #004 ging es darum, RAG-Qualität in Zahlen zu fassen und dabei Retrieval und Generierung getrennt zu messen. Der häufigste Befund: Die entscheidenden Belege lagen gar nicht erst im Kontext, der Retriever hat sie nicht gefunden.

Damit ist die Diagnose gestellt, aber die Behandlung offen. Diese Ausgabe behandelt die zwei Hebel mit dem besten Verhältnis aus Aufwand und Wirkung. Beide kommen ohne zusätzliches Training aus und sind in gängigen Suchsystemen bereits eingebaut.

🎤 Main Set: Zwei Suchverfahren statt einem

Jedes Verfahren hat einen blinden Fleck

Die klassische Stichwortsuche (das Standardverfahren heißt BM25) findet exakte Zeichenfolgen zuverlässig: Fehlercodes, Artikelnummern, Konfigurations-Flags, Abkürzungen. Sie scheitert, sobald Frage und Dokument dieselbe Sache unterschiedlich benennen, etwa „Urlaubsantrag“ und „Abwesenheitsgesuch“.

Die Vektorsuche verhält sich genau umgekehrt. Sie erkennt Synonyme und Umformulierungen, verfehlt aber kurze technische Bezeichner. Für die Frage „Warum schlägt der Export mit ERR_5521 fehl?“ ist ERR_5521 das entscheidende Suchwort, doch im Vektorraum hat so ein Bezeichner keine aussagekräftige Nachbarschaft. Das Ergebnis sind dann Antworten, die plausibel klingen und das falsche Dokument zitieren.

Beide Verfahren scheitern also an unterschiedlichen Anfragen. Deshalb bringt die Kombination mehr als die Optimierung eines einzelnen Verfahrens, und genau das ist hybride Suche.

Kombinieren, aber richtig: über Ränge statt Scores

Die Scores beider Verfahren lassen sich nicht einfach verrechnen, ihre Wertebereiche passen nicht zusammen. Die etablierte Lösung heißt Reciprocal Rank Fusion (RRF) und ignoriert die Scores komplett. Sie schaut nur darauf, auf welchem Platz ein Dokument in jeder Trefferliste steht:

score(d) = Σ 1 / (k + rang(d))

Für jedes Suchverfahren bekommt das Dokument Punkte nach seiner Platzierung, Platz 1 bekommt am meisten, weiter hinten wird es schnell weniger, und die Punkte aus allen Verfahren werden addiert. Die Konstante k (Standardwert 60) sorgt dafür, dass ein einzelner Spitzenplatz nicht alles dominiert. Im Ergebnis gewinnt das Dokument, das in beiden Listen solide platziert ist, gegen das Dokument, das nur eine Liste anführt. Das Verfahren braucht weder Trainingsdaten noch Feintuning und liefert in Vergleichsmessungen konsistent bessere Ranglisten als jedes Einzelverfahren.

🥁 Track 2: Die zweite Bewertungsstufe

Die erste Suchstufe ist auf Geschwindigkeit über große Bestände ausgelegt. Dafür bewertet sie jedes Dokument isoliert und grob. Ein Reranker setzt danach an: Er nimmt die besten 50 bis 200 Kandidaten aus der ersten Stufe und bewertet jeden davon noch einmal gründlich, indem er Anfrage und Dokument gemeinsam liest (technisch: ein Cross-Encoder). Dadurch erkennt er Bezüge, die der ersten Stufe entgehen, und sortiert die Spitze der Trefferliste deutlich präziser.

Der Preis ist Rechenzeit pro Kandidat. Deshalb ist der Reranker keine Suche, sondern eine Filterstufe am Ende: grob finden, dann fein sortieren. Fertige Reranking-Modelle gibt es als API-Dienste, unter anderem von Cohere und Voyage, die sind also schnell integriert.

Daraus ergibt sich die sinnvolle Reihenfolge: zuerst hybride Suche, weil sie praktisch nichts kostet, dann Reranking, weil es die Qualität ganz oben in der Trefferliste hebt, dort, wo der Kontext fürs Modell entsteht.

🎯 Encore: Der eine Gedanke für Entscheider

Wenn die Retrieval-Metriken schwach sind, lautet die erste Frage nicht, ob ein Wissensgraph oder eine neue Plattform nötig ist, sondern ob diese beiden Standardhebel überhaupt gezogen wurden. Sie erfordern kein Training auf eigenen Daten, sind in gängigen Suchsystemen verfügbar und adressieren genau die Mischung, die Unternehmensbestände prägt: exakte Bezeichner und natürliche Sprache im selben Korpus.

Die Prüffrage für Entscheider: Nutzt unser Retrieval beide Suchverfahren mit einer definierten Fusionsstrategie und eine zweite Bewertungsstufe, und ist der Effekt jedes Schritts an unserem eigenen Testset gemessen?

💿 B-Side

Anti-Pattern: Reranking als Reparatur für ein schwaches Context Recall in der RAG-Pipeline einsetzen. Ein Reranker kann nur umsortieren, was ihm übergeben wird. Ein Dokument, was vorher schon gar nicht gefunden wurde, bleibt entsprechend im Ergebnis unsichtbar, egal wie gut der Reranker ist. Der Recall ist damit die Obergrenze des Gesamtsystems.

Praxis: Beide Stufen getrennt messen, Context Recall nach der ersten Stufe, Precision nach dem Reranking. Sonst bleibt unklar, welcher Teil der Pipeline den Fehler verursacht.

---

Das war Rag'n'Roll #011.

Weiterleiten erwünscht🤘