Reranking: Wie man die Suchqualität in RAG verbessert

Die meisten Teams bleiben bei der vektorbasierten Top-k-Suche stehen und fragen sich, warum der Assistent jedes fünfte Mal falsch liegt. Die Antwort ist fast immer dieselbe: Die Suche hat Fragmente zurückgegeben, die der Anfrage ähnlich sind, aber nicht die, die die Frage beantworten. Reranking löst genau dieses Problem – und das ohne den gesamten Pipeline umzubauen.

Ein Embedding komprimiert Text in einen Vektor und reduziert die Information auf eine Zahl pro Dimension. Das Embedding-Modell sieht nie Frage und Fragment zusammen – es bettet sie separat ein, und die Ähnlichkeit wird anschließend geometrisch gemessen. Das ist schnell und skalierbar, hat aber seinen Preis.

Ein Beispiel, das regelmäßig in der Produktion zu sehen ist: Die Wissensbasis eines Unternehmens enthält zwei Dokumente. Eines beschreibt „das Reklamationsverfahren für Privatkunden“, das andere „das Reklamationsverfahren für Geschäftskunden“. Beide haben sehr ähnliche Embeddings, da die meisten Wörter identisch sind. Die Frage „Wie reklamiere ich als Firma“ liegt vektoriell nah an beiden. Die ANN-Suche gibt beide mit ähnlichem Score zurück. Das generative Modell erhält beide Fragmente und hat die Chance, die Prozesse zu verwechseln.

Ein Cross-Encoder-Reranker sieht das Ganze anders: Er erhält gleichzeitig die Frage und jeden Kandidaten als Paar und berechnet den Relevance-Score unter Berücksichtigung des gegenseitigen Kontexts. Das Fragment zu Geschäftskunden erhält einen höheren Score. Die Treffergenauigkeit steigt, ohne den Vektorindex zu ändern.

Das ist auch der Grund, warum Hybrid Search und Reranking ein natürliches Paar sind: Die Hybride erhöht die Abdeckung der Kandidaten (BM25 + ANN), der Reranker steigert die Präzision aus diesem Pool.

Ein Cross-Encoder ist ein Transformer-Modell (meist eine BERT-Variante oder ähnliches), das auf Paaren (Frage, Fragment) mit Relevanzlabels trainiert wird. Während der Inferenz:

1. Frage und Fragment werden als ein Eingabestring mit einem speziellen Separator-Token konkateniert.
2. Das Modell verarbeitet dieses Paar durch alle Attention-Layer gleichzeitig, sodass jedes Token der Frage jedes Token des Fragments „sehen“ kann.
3. Die Ausgabe ist ein Skalar: der Relevance-Score für dieses konkrete Paar.
4. Die Pipeline berechnet den Score für jeden Kandidaten aus der Top-k-Liste, sortiert absteigend und gibt die Top-n an das generative Modell weiter.

Kosten: Inferenz des Cross-Encoders für jeden Kandidaten separat. Bei 20 Kandidaten sind das 20 Forward-Passes des Reranking-Modells statt einem. Deshalb verarbeitet der Reranker nur Kandidaten aus der Suche, nicht den gesamten Index.

Der Bi-Encoder skaliert auf Millionen von Dokumenten. Der Cross-Encoder skaliert nicht auf Millionen, da er jede Frage mit jedem Fragment vergleichen müsste. Deshalb ist das produktive Muster immer: Schnelle Kandidatensuche, dann teurer Reranker auf einem kleinen Set.

Nicht jede Pipeline braucht Reranking vom ersten Tag an. Es lohnt sich, es hinzuzufügen, wenn:

Die Wissensbasis Dokumente mit ähnlichem Wortlaut und unterschiedlichem Inhalt enthält. Verfahren für verschiedene Kundengruppen, Regelwerke in mehreren Versionen, Anleitungen für verschiedene Gerätemodelle. Embedding behandelt sie fast gleich, Reranker unterscheidet sie.

Fragen sind mehrdeutig oder vielschichtig. „Wie kündige ich das Abonnement, wenn ich im Urlaub war und die Frist verpasst habe“ hat viele Komponenten. Der Bi-Encoder vereinfacht auf einen Vektor. Der Cross-Encoder liest das Ganze.

Die Pipeline antwortet auf Englisch auf polnische Fragen oder umgekehrt. Mehrsprachige Modelle haben schlechtere Embeddings für gemischte Sprachen. Cross-Encoder, trainiert auf mehrsprachigen Paaren, kommt besser mit kontextueller Relevanz zurecht.

Du hast lange Fragmente (über 512 Token). Der Bi-Encoder komprimiert lange Fragmente auf einen Vektor und verliert Details. Der Cross-Encoder verarbeitet den gesamten Kontext des Paares.

Wenn deine Wissensbasis klein ist (bis zu einigen hundert Dokumenten), die Fragen kurz und präzise sind und die Antworten zufriedenstellend, bringt Reranking möglicherweise keine messbare Verbesserung. Teste immer die Ergebnisse auf einem Testset vor der Implementierung.

Die Wahl des Reranking-Modells beeinflusst Qualität, Latenz und ob Daten die Infrastruktur verlassen. Grundregel: Wenn die Wissensbasis sensible oder personenbezogene Daten enthält, muss der Reranker lokal laufen. Ein Dokumentenfragment, das an eine externe Reranking-API gesendet wird, bedeutet, dass Daten das Firmennetzwerk verlassen.

Wir nutzen lokal ausgeführte Reranking-Modelle. Praktische Optionen 2026:

Bei einer polnischen Wissensbasis ist bge-reranker-v2-m3 die erste Wahl: mehrsprachig, passt auf einen Standard-CPU-Server, Latenz im Bereich von einigen zehn Millisekunden pro Paar. Bei 20 Kandidaten sind das weniger als 700 ms zusätzliche Zeit, was in den meisten Szenarien eines Firmenassistenten akzeptabel ist.

Self-Hosting des Reranking-Modells hat noch eine weitere Dimension der DSGVO-Konformität: Das Dokumentenfragment verlässt die Infrastruktur nie, auch nicht temporär während der Relevanzbewertung. Das ist wichtig bei Wissensbasen, die Verfahren, Verträge oder Kundendaten enthalten.

Eine vollständige Pipeline sieht wie folgt aus. Jeder Schritt hat eine Aufgabe und erzeugt eine klar definierte Ausgabe.

Schritt 1: Indizierung. Jedes Dokument wird in Fragmente unterteilt (normalerweise 256-512 Token mit 64 Token Overlap). Jedes Fragment wird mit dem Modell BGE-M3 eingebettet und in der Vektordatenbank (Qdrant) mit Metadaten gespeichert: Kategorie, Datum, Abteilung, Dokumenttyp.

Schritt 2: Hybride Suche. Auf eine Nutzeranfrage werden parallel BM25 (Postgres FTS oder Elasticsearch) und ANN (Qdrant) ausgeführt. Die Ergebnisse werden durch Reciprocal Rank Fusion (RRF) zu einem Pool von 20-50 Kandidaten zusammengeführt. Dieser Schritt dauert normalerweise unter 100 ms.

Schritt 3: Reranking. Jeder Kandidat wird vom Cross-Encoder als Paar (Anfrage, Fragment) bewertet. Die Ergebnisse werden absteigend sortiert. An das generative Modell gehen die Top-3 bis Top-5 Fragmente.

Schritt 4: Generierung mit Kontext. Das generative Modell erhält die Frage und die ausgewählten Fragmente über einen LLM-Router. Guardrails prüfen die Ausgabe vor der Übergabe an den Nutzer. Wenn kein Fragment den Relevanzschwellenwert überschreitet, antwortet das System „Ich weiß es nicht“ und leitet an einen Menschen weiter (siehe: human-handoff).

Kritisches Detail: Der Relevanzschwellenwert beim Reranking. Wenn der höchste Score im Pool unter 0,3 (Skala 0-1) liegt, ist das Fragment nicht ausreichend mit der Frage verknüpft. Besser keine Antwort generieren als mit niedrig relevanter Kontext. Diese Logik begrenzt direkt Halluzinationen.

Reranking fügt Zeit hinzu. Ob diese Zeit akzeptabel ist, hängt vom Kontext ab.

Bei einem Firmenassistenten mit einer Antwortzeit unter 3 Sekunden nimmt Reranking bei 20 Kandidaten auf der CPU 600-800 ms in Anspruch. Das sind 20-30% der gesamten Antwortzeit. In den meisten Szenarien des Kundenservice und der internen Unterstützung ist das akzeptabel.

Wenn die Pipeline schneller sein muss, gibt es einige Optimierungen:

• Reduziere den Kandidatenpool. Top-10 statt Top-20 bedeutet halb so schnelles Reranking bei minimalem Verlust der Abdeckung.
• Cache die Reranking-Ergebnisse für sich wiederholende Fragen (mit TTL 24h). FAQ-Fragen wiederholen sich in 30-50% der Fälle in Kundenservice-Systemen.
• Nutze ein kleineres Reranking-Modell. MiniLM ist 5x schneller als bge-reranker-large bei akzeptablem Qualitätsverlust für einfachere Wissensbasen.
• Filtere mit Metadaten vor dem Reranking. Wenn die Dokumentenkategorie aus dem Kontext bekannt ist (z. B. Nutzer ist im Bereich „Produkte“), beschränke den Pool auf diese Kategorie bereits auf der ANN-Ebene.

Throughput und Latenz sind Dimensionen, die wir bei jeder Implementierung gemessen haben. Details zur Überwachung der Pipeline beschreibt der Artikel Monitoring der Qualität eines AI-Agenten.

Füge Reranking nicht ohne Testset hinzu. Ohne Messung gibt es keine Gewissheit, dass etwas verbessert wurde.

Ein minimales Evaluationsset besteht aus 50-100 Paaren (Frage, erwartetes Fragment). Man kann es aus Produktionslogs (Nutzerfragen + Feedback von Beratern) oder manuell für die wichtigsten Bereiche der Wissensbasis erstellen.

Metriken, auf die man achten sollte:

• MRR (Mean Reciprocal Rank) – wie hoch das relevante Fragment in der Liste erscheint. MRR@10 misst dies in den ersten 10 Ergebnissen.
• NDCG (Normalized Discounted Cumulative Gain) – gewichtete Metrik, bei der höher = relevanter.
• Precision@k – wie viele der Top-k-Fragmente tatsächlich relevant sind.
• Antwortzeit p50/p95 – vor und nach dem Reranking.

Ein AB-Benchmark vor/nach Reranking auf demselben Testset gibt eine konkrete Antwort. In typischen Projekten mit diverser Wissensbasis erhöht Reranking den MRR@5 um 15-30% im Vergleich zu ANN allein. Das führt zu weniger Eskalationen an Menschen und einer höheren Containment-Rate.

Der folgende Sandbox führt eine Pipeline mit Reranking auf deinem Text aus. Füge ein Dokumentenfragment ein und stelle eine Frage. Das System sucht, bewertet Kandidaten mit einem Cross-Encoder und generiert eine Antwort. PII wird vor dem Modell maskiert, keine Daten werden gespeichert.

Vektorsuche berechnet die Ähnlichkeit von Embeddings der Frage und der Fragmente separat, ohne sie gegenseitig zu vergleichen. Reranking verarbeitet jedes Paar (Frage, Fragment) gemeinsam durch ein Cross-Encoder-Modell, das den gegenseitigen Kontext versteht. Ergebnis: Vektorsuche ist schnell und skaliert gut auf Millionen von Dokumenten, der Reranker ist langsamer, bewertet aber deutlich treffsicherer, welcher Kandidat tatsächlich die Frage beantwortet.

Nein. Bei einer kleinen, homogenen Wissensbasis (bis zu einigen hundert gut strukturierten Dokumenten) und präzisen Fragen reicht oft die semantische Suche allein aus. Reranking lohnt sich, wenn die Wissensbasis groß oder heterogen ist, Fragen vielschichtig sind oder Dokumente mit ähnlichem Wortlaut, aber unterschiedlichem Inhalt vorliegen. Bevor du Reranking hinzufügst, miss MRR und Precision@k auf einem Testset ohne Reranking und vergleiche die Ergebnisse danach. Daten entscheiden, nicht Intuition.

Nur wenn du eine Reranking-API (z. B. Cohere Rerank) verwendest. Bei einem lokalen Modell (bge-reranker-v2-m3 über Ollama) werden alle Fragmente und Fragen auf dem eigenen Server verarbeitet. Für Wissensbasen mit sensiblen oder RODO-relevanten Daten wählen wir immer lokale Modelle. Die Pflichten von Unternehmen bei der Verarbeitung personenbezogener Daten in KI beschreibt der Artikel AI Act und RODO 2026.

Wenn die RAG-Pipeline bereits läuft, dauert das Hinzufügen von Reranking in der Regel Tage, nicht Wochen. Der Suchschritt wird um ein Cross-Encoder-Modell (Download und lokale Ausführung), die Sortierlogik nach dem neuen Score und optional einen Mindestrelevanzschwellenwert erweitert. Der größere Aufwand liegt im Evaluationsset und Benchmark, die bestätigen, dass die Änderung die Qualität verbessert hat. Ohne diese weiß man nicht, was wirklich gewonnen wurde.

Hier hilft Reranking, aber effektiver ist Hybrid Search als vorheriger Schritt. BM25 erfasst präzise Vertragsnummern, SKUs oder eindeutige Produktnamen, die Embeddings nicht gut abdecken. Der Reranker bewertet dann, welcher der Kandidaten (sowohl BM25 als auch ANN) tatsächlich die Frage beantwortet. Die Kombination beider Mechanismen liefert die besten Ergebnisse bei diversen Wissensbasen, wie wir im Artikel Semantische Suche und Embeddings im Unternehmen ausführlicher beschreiben.