Deine Vektorsuche liefert die dringend gesuchte MFA-Anleitung zwar auf Platz 7, schiebt aber drei allgemeine Passwort-Artikel nach ganz oben. Das Embedding-Modell hat das grobe Thema „Kontozugang“ erkannt, aber die feine Nuance der Anfrage verfehlt. Wie bekommst du den besten Treffer verlässlich auf Platz 1?
Beim Reranking sortiert ein zweites, präziseres Modell die Top-Kandidaten der ersten Suche neu. Während ein Bi-Encoder Anfrage und Dokument getrennt als einzelne Vektoren vergleicht, liest ein Cross-Encoder beide Texte gemeinsam im selben Durchlauf Token für Token durch. Dadurch erkennt er feine Bedeutungsunterschiede, Bedingungen und Verneinungen deutlich schärfer – kostet pro Dokumentpaar aber so viel Rechenzeit, dass er nur auf einer kleinen Vorauswahl (meist den Top 20 bis 50 Kandidaten) eingesetzt wird.
Ein Bi-Encoder durchsucht Millionen Dokumente schnell auf Verdacht; der Cross-Encoder prüft die besten Kandidaten im Detail – kann aber nichts nach vorne sortieren, was im ersten Schritt gar nicht gefunden wurde.
Warum sieht ein Cross-Encoder mehr als die Vektorsuche?
Bei einer normalen Vektorsuche wird jedes Dokument schon beim Indexieren in einen einzigen, starren Vektor komprimiert – völlig ohne zu wissen, wonach später gefragt wird. Ein (Modellarchitektur, der Suchanfrage und Kandidatentext gleichzeitig als ein verbundenes Paar übergeben werden, sodass die volle Self-Attention zwischen allen Wörtern beider Texte wirken kann.) verzichtet auf diese Vorab-Komprimierung: Er erhält [Anfrage, Kandidatentext] als gemeinsame Eingabe und berechnet über alle Schichten hinweg direkt die Wechselwirkung zwischen jedem Wort der Frage und jedem Wort des Abschnitts.
Gerade bei eng verwandten Themen im deutschen Support-Datensatz zeigt sich der Unterschied: Wenn jemand fragt „Mein Handy mit dem Authenticator ist weg“, teilen sowohl der Passwort-Artikel als auch der MFA-Artikel Begriffe rund um Anmeldung und Kontozugriff. Der Cross-Encoder kann jedoch die konkrete Wortverbindung zwischen „Handy / Authenticator weg“ und „Wiederherstellungscode für den zweiten Faktor“ direkt gewichten.
Wie die Sentence-Transformers-Architektur zu Retrieve & Re-Rank beschreibt, entsteht daraus eine klassische Zwei-Stufen-Pipeline:
- Stufe 1 (Retriever): Schnelle Vektor- oder Hybrid-Suche holt aus dem Gesamtbestand die besten
NKandidaten (z. B. Top 30). - Stufe 2 (Reranker): Der Cross-Encoder bewertet genau diese
NPaare neu und gibt die besten 3 bis 5 Treffer für die Anzeige oder den RAG-Prompt zurück.
Wie groß sollte das Kandidatenfenster sein?
Der Reranker ist durch den Recall der ersten Stufe hart begrenzt: Liegt die richtige Anleitung nicht unter den abgerufenen N Kandidaten, kann auch der beste Cross-Encoder sie nicht herbeizaubern. Gleichzeitig skaliert die Rechenzeit des Rerankers linear mit der Anzahl und Token-Länge der Kandidaten.
| Beobachtung im Test | Wo liegt die Ursache? | Was du konkret tun solltest |
|---|---|---|
| Richtige Quelle fehlt schon in den Top-50 | Schwacher Retriever, schlechtes Chunking oder falscher Filter | Nicht am Reranker schrauben – zuerst Hybrid Search, Chunk-Grenzen oder Embedding-Modell verbessern |
| Quelle liegt auf Platz 12, fehlt aber in den Top-3 | Grobe Vektor-Ähnlichkeit überdeckt feine Details der Frage | Idealer Einsatzfall für Reranking: Top-25 abrufen und auf Top-3 neu sortieren |
| Top-3 stimmen, aber Antwort dauert 800 ms länger | Zu viele oder zu lange Chunks im Cross-Encoder-Batch | Kandidatenfenster verkleinern (z. B. Top-15 statt Top-50), kürzere Chunks nutzen oder GPU-Batching prüfen |
| Interne Quelle landet nach Reranking auf Platz 1 | Zugriffsfilter wurden erst nach der Suche oder gar nicht angewendet | Berechtigungen zwingend schon im Retriever der Stufe 1 hart filtern |
Worauf musst du bei Eingabelängen und Scores achten?
Cross-Encoder haben – genau wie Embedding-Modelle – ein festes maximales Kontextfenster (oft 512 Tokens für Anfrage plus Dokumentabschnitt zusammen). Übergibst du einen 700 Tokens langen Chunk, wird das letzte Drittel vor der Bewertung abgeschnitten. Steht die entscheidende Bedingung ganz am Ende des Abschnitts, sieht der Reranker sie schlichtweg nicht.
Viele Cross-Encoder geben unkalibrierte Logits (z. B. -4.2 bis +8.7) oder Sigmoid-transformierte Werte zwischen 0 und 1 aus. Ein Wert von 0.85 heißt nicht „85 % korrekt“. Wenn du irrelevante Treffer unterhalb einer Schwelle verwerfen willst, musst du diesen Schwellenwert auf deinen eigenen Daten mit beantwortbaren und unbeantwortbaren Fragen kalibrieren.
Achte in deiner Implementierung außerdem auf sauberes Batch-Mapping: Wenn du 20 Kandidaten parallel an einen Reranking-Endpunkt schickst, verknüpfe den zurückgegebenen Score wieder eindeutig über die document_id oder den ursprünglichen Array-Index mit dem richtigen Quelltext. Ein einziger Off-by-One-Fehler beim Sortieren reicht aus, um dem Nutzer den falschen Artikel unter dem besten Score anzuzeigen.
Wie misst du, ob sich die zweite Stufe wirklich rechnet?
Um den Effekt des Rerankers sauber vom Retriever zu isolieren, speicherst du die Kandidatenliste der ersten Stufe ab und wertest zwei Varianten auf exakt denselben Daten aus:
- Baseline ohne Reranker: Top-k-Reihenfolge direkt aus der Vektor- oder Hybrid-Suche.
- Mit Reranker: Neu sortierte Top-k-Reihenfolge derselben Kandidatenmenge.
Da sich durch das Umsortieren innerhalb derselben Menge vor allem die oberen Plätze verschieben, misst du den Qualitätsgewinn mit positionssensitiven Metriken wie (Normalized Discounted Cumulative Gain: Ranking-Metrik zwischen 0 und 1, die relevante Treffer auf den vordersten Plätzen deutlich stärker belohnt als Treffer weiter unten in der Liste.) (z. B. nDCG@3 oder nDCG@5) und MRR (Mean Reciprocal Rank). Dem stellst du die zusätzliche p95-Latenz gegenüber.
- Prüfe zuerst
Recall@Nder ersten Stufe, bevor du den Reranker über die Top-N laufen lässt. - Definiere ein enges Timeout für den Reranking-Aufruf und liefere im Fehlerfall sauber die bereits gefilterte Reihenfolge aus Stufe 1 aus.
- Halte Chunk-Länge plus Anfrage-Länge sicher unterhalb des Modell-Tokenlimits.
- 200 überlange Dokumente auf einer CPU durch einen Cross-Encoder pressen, weil der erste Suchschritt schlecht konfiguriert ist.
- Einen starren Score-Cutoff wie
score > 0.7ohne eigene Kalibrierung in Produktion setzen. - Bei einem Timeout des Rerankers die gesamte Suchanfrage mit einem 500er-Fehler abbrechen.
Checkliste für den produktiven Einsatz
- Die richtige Quelle ist bereits in der Kandidatenmenge der ersten Stufe (
Recall@N) zuverlässig enthalten. - Anfrage und Kandidatentext überschreiten zusammen nicht das maximale Token-Limit des Cross-Encoders.
- Der Gewinn bei
nDCG@3/MRRrechtfertigt die gemessene Zusatzlatenz unter realistischer Last. - Bei einem Timeout des Rerankers fällt das System kontrolliert auf die berechtigungsgeprüfte Trefferliste der ersten Stufe zurück.
Quellen und nächste Schritte
- Sentence Transformers: Retrieve & Re-Rank Pipeline – Architektur und Codebeispiele für zweistufige Suchsysteme.
- Sentence Transformers: Cross-Encoder Evaluation – Referenz zur Bewertung von Reranking-Modellen.
Wie du durch die Kombination von Keyword- und Vektorsuche dafür sorgst, dass dem Reranker in Stufe 1 kein wichtiger Kandidat entgeht, zeigt Hybrid Search. Das passende Auswertungsskript für nDCG und MRR findest du unter Retrieval-Evaluation.