Reranking liegt auf der letzten Meile der Retrieval-Kette: Zuerst werden über Vektor- oder Hybrid-Retrieval einige Dutzend bis Hunderte Kandidaten gefunden, dann berechnet ein Cross-Encoder die Relevanz von Query und Dokument und schiebt die wirklich nützlichen Abschnitte nach vorn. Es erzeugt keinen Text, behebt aber wirksam das Problem „die Antwort steht auf Platz zehn“.

Für Reranking gibt es jedoch nicht nur eine richtige Umsetzung. Gehostete API, Open-Weight-Modell und in eine Vektordatenbank integrierte Funktion sind alle gangbar; unterschiedlich sind Qualität, Latenz, Sprachabdeckung, Datenschutz, Kosten und Betrieb. Dieser Beitrag gliedert nach sechs Dimensionen und liefert eine Szenariotabelle sowie eine Migrationscheckliste. Konkrete Modelle und Preise entnehmen Sie unseren Modellpreisen.

Hinweis: Cohere, Jina, Voyage, Qwen, BGE, Weaviate, Milvus, Elasticsearch und weitere genannte Namen sind Marken ihrer jeweiligen Inhaber; dieser Beitrag dient nur der technischen Diskussion. Produktfunktionen, Limits und Bedingungen können sich ändern; vor der Integration die Dokumentation des jeweiligen Anbieters prüfen.

1. Zuerst bestätigen, dass der Engpass im Reranking liegt

Nicht jede schlechte RAG-Qualität rechtfertigt Reranking. Drei Signale prüfen: Der richtige Abschnitt wird gefunden, liegt aber oft hinter Platz fünf; nach dem Hybrid-Retrieval sind die ersten Treffer deutlich verrauscht, und Keyword-Treffer überwiegen semantische Relevanz; die generierte Antwort zitiert falsche Abschnitte, während ein manuell eingesetzter richtiger Abschnitt die Antwort korrigiert.

Fehlt der richtige Abschnitt von vornherein in der Kandidatenmenge, kann Reranking nichts ausrichten; dann zuerst Chunking, Embedding oder Retrieval-Menge verbessern. Bei nur drei bis fünf Kandidaten ist der Nutzen ebenfalls begrenzt. Erfahrungsgemäß ist Reranking bei zwanzig bis zweihundert Kandidaten besonders effizient; oberhalb einiger hundert steigen Latenz und Kosten schnell.

2. Die drei Wege im Überblick

Gehostete Rerank API: Der Anbieter kapselt Modell und Inferenz in einer Schnittstelle, die üblicherweise query, documents und top_n entgegennimmt und Indizes sowie Scores in Relevanzreihenfolge zurückgibt. Vorteile: schnelle Integration, meist gute Mehrsprachigkeit, keine GPU nötig. Nachteile: Daten verlassen das eigene Netz, Bindung an Anbieterlimits und Schnittstellenformat, langfristig steigende Kosten mit dem Aufrufvolumen.

Open-Weight-Cross-Encoder: Das Modell läuft auf eigener GPU oder einem eigenen Inferenzdienst; verbreitete Optionen sind die BGE-Rerank-Reihe, Qwen3-Reranker, Jina Reranker und ähnliche. Vorteile: Daten bleiben im internen Netz, Feinabstimmung und Versionsfixierung möglich. Nachteile: GPU, Skalierung, Modellupgrades und Inferenz-Framework müssen selbst betrieben werden. Frameworks wie vLLM oder TEI bieten Rerank-Schnittstellen und reduzieren einen Teil des Anpassungsaufwands.

In die Vektordatenbank integriertes Reranking: Manche Vektordatenbanken bieten eingebaute oder integrierte Rerank-Funktionen, etwa das Rerank-Modul von Weaviate, den Rerank-Retriever von Elasticsearch oder die Rerank-Funktion neuerer Milvus-Versionen; andere Produkte übernehmen nur das Retrieval und lagern das Reranking an einen externen Dienst aus. Vorteile: weniger Netzwerkhop, einheitliche Rechte- und Betriebsgrenzen. Nachteile: Modellauswahl ist produktgebunden, wenig Spielraum für tiefe Anpassungen.

Besonders wichtig: Rerank hat keinen einheitlichen OpenAI-kompatiblen Standard wie Chat Completions. Die Felder von Jina, Cohere und Voyage unterscheiden sich, etwa top_n gegenüber top_k, ob Dokumenttexte zurückgegeben werden und welche Kürzungsparameter gelten; Endpunkte können /v1/rerank oder /v2/rerank sein. Bei einem Anbieterwechsel kostet die Protokollanpassung oft mehr Zeit als das Modell selbst.

3. Die sechs Vergleichsdimensionen

Bei der Qualität können sowohl gehostete APIs als auch Open-Source-Modelle Cross-Encoder sein; Unterschiede liegen eher in Trainingsdaten, Sprachverteilung und Version. Nicht nur öffentliche Ranglisten betrachten, sondern mit eigenen fachlichen Queries und Kandidatenmengen evaluieren. Nutzt eine integrierte Vektordatenbank-Funktion dieselbe Modellklasse, ist das Ergebnis meist ähnlich, die Parameter sind aber weniger fein steuerbar.

Bei der Latenz wächst der Rerank-Aufwand grob mit „Kandidatenzahl × Dokumentlänge“. Eine gehostete API hat einen zusätzlichen öffentlichen Netzwerk-Roundtrip und eignet sich für kleinere Kandidatenmengen mit stabiler Parallelität; Selbstbetrieb spart die externe Abhängigkeit, muss aber GPU-Warteschlangen bewältigen; die integrierte Variante spart den Netzwerkhop, kann jedoch dieselben Ressourcen wie das Retrieval beanspruchen.

Bei der Sprachabdeckung sind Chinesisch, gemischtes Chinesisch-Englisch und kleinere Sprachen getrennt zu betrachten. Viele Modelle liegen in englischen Ranglisten nahe beieinander; bei chinesischen Langdokumenten und Fachbegriffen wächst der Abstand. Drei Evaluationssets – Chinesisch, Englisch, gemischt – vorbereiten.

Beim Datenschutz gilt: Sobald Dokumente das eigene Netz verlassen, sind Datenbedingungen, Transportverschlüsselung, Log-Aufbewahrung und grenzüberschreitende Wege zu bewerten. Für Verträge, Kundendaten, medizinische und finanzielle Texte kommt eher Selbstbetrieb oder private Bereitstellung infrage.

Bei den Kosten rechnet eine gehostete API nach Aufrufen oder Token und wächst nahezu linear mit der Nutzung; Selbstbetrieb bedeutet fixe GPU-Kosten plus Personal und ist bei geringem Volumen nicht zwingend günstiger; die integrierte Variante kann im Datenbanktarif enthalten sein oder zusätzlich nach Inferenzvolumen abgerechnet werden. Retries, Offline-Evaluation und Spitzenkapazität mitrechnen.

Beim Betrieb übernimmt der Anbieter Modellupgrades und Skalierung, während das Team Keys, Limits und Anbieterunterschiede verwaltet; Selbstbetrieb braucht jemanden für GPU, Treiber und Framework-Upgrades; die integrierte Variante führt zwei Systeme zusammen, macht aber auch die Ausfall domäne konzentrierter.

4. Auswahl nach Szenario

Szenario Empfohlener Weg Begründung Zu beachten
Schnelle Validierung, einige Dutzend Kandidaten gehostete Rerank API am selben Tag integrierbar, keine GPU zuerst klären, ob Daten das Netz verlassen dürfen
Überwiegend Chinesisch, sensible Daten Open Source im Selbstbetrieb privat betreibbar, chinesisch starke Modelle wählbar GPU und Betriebspersonal einplanen
Bestehende Vektordatenbank, einfache Anforderungen integrierte Funktion eine Integration weniger, einheitliche Rechte prüfen, ob Modell und Parameter ausreichen
Hohe Parallelität, latenzkritisch Selbstbetrieb oder Integration in derselben Region vermeidet öffentlichen Roundtrip und Warteschlange Lasttest, nicht nur Mittelwerte
Mehrsprachig, kleinere Sprachen gehostete API oder starkes mehrsprachiges Open-Source-Modell Sprachabdeckung einfacher mit kleinem Sprach-Evaluationsset prüfen
Sehr geringes Volumen, kein GPU-Team gehostete API geringere Fixkosten Budget- und Limitwarnungen einrichten

Die Tabelle ist nur ein Ausgangspunkt. Ein Team kann kombinieren: gehostete API als Produktionsabsicherung, Open Source für Offline-Evaluation, integrierte Funktion nur für risikoarme Geschäftsbereiche.

5. Qualität bewerten, nicht nach Gefühl

Mindestens drei Dinge vorbereiten: eine Menge echter Queries, die Annotation des richtigen Dokuments pro Query und die aktuelle Retrieval-Menge. Kennzahlen sind Recall@k, MRR oder nDCG, nicht „wirkt relevanter“. Dieselben Kandidaten vor und nach dem Reranking exportieren, die ersten zehn manuell prüfen und Fehlertypen festhalten: fehlendes Retrieval, gebrochenes Chunking oder ein durch Reranking nach hinten geschobener richtiger Abschnitt.

Das folgende Python-Beispiel prüft nur eines: ob das richtige Dokument vor und nach dem Reranking unter den ersten k Treffern liegt. Es ist anbieterunabhängig; die Eingabe sind zwei sortierte Indexlisten.

def hit_rate(cases, k):
    hits = 0
    for gold, ranked in cases:
        if gold in ranked[:k]:
            hits += 1
    return hits / len(cases)

# cases: [(index des richtigen Dokuments, rerankte Indexliste), ...]
before = hit_rate(baseline_cases, 5)
after = hit_rate(reranked_cases, 5)
print(f"Recall@5: {before:.3f} -> {after:.3f}")

Die Stichprobe sollte mindestens einhundert Fälle umfassen und verschiedene Geschäftsbereiche sowie Dokumentlängen abdecken. Vor dem Start zusätzlich P95-Latenz und Kosten pro Aufruf prüfen; Mittelwerte verdecken den Long Tail.

6. Migrationscheckliste

Beim Wechsel von einer Rerank API zu einer anderen oder von gehostet zu selbst betrieben in dieser Reihenfolge vorgehen:

  1. Evaluationsset und aktuelle Baseline fixieren; Recall@k, MRR, P95-Latenz und Kosten pro Aufruf festhalten.
  2. Endpunktpfad, Authentifizierung und Anfragefelder der neuen Lösung prüfen, besonders top_n gegenüber top_k, Rückgabe des Dokumenttexts und Kürzungsparameter.
  3. Score-Semantik angleichen: normalisierter Wert zwischen null und eins oder unnormalisierte Logits, aufsteigende oder absteigende Sortierung; Schwellenwerte nicht direkt mischen.
  4. Dokumentanzahl pro Aufruf, Token pro Dokument, Request-Größe und Parallelitätslimits prüfen; bei Überschreitung clientseitig aufteilen, statt auf einen Fehler zu warten.
  5. Retry und Fallback für Timeout, 429 und 5xx implementieren; beim Fallback die ursprüngliche Retrieval-Reihenfolge behalten, damit die Kette nicht vollständig ausfällt.
  6. Mit Shadow-Traffic alte und neue Ergebnisse vergleichen, mindestens eine Woche beobachten und Sortier- sowie Antwortqualitätsänderungen festhalten.
  7. Schrittweise umstellen und Rollback-Schwellen definieren, etwa Rückfall bei Fehlerrate oder P95 über einem bestimmten Anteil der Baseline.
  8. Monitoring und Abrechnungslogik aktualisieren und sicherstellen, dass Retries, Cache und Offline-Evaluation nicht vergessen werden.

Häufige Fragen

Worin unterscheiden sich Rerank API und Embedding API?

Embedding wandelt Text in Vektoren für die großflächige Kandidatensuche; Rerank liest Query und Dokument einzeln und ist genauer, aber langsamer. Üblich ist, zunächst einige Dutzend bis Hunderte Kandidaten zu finden und dann die vorderen Treffer fein zu sortieren.

Ist ein Open-Source-Rerank-Modell immer günstiger als eine gehostete API?

Nein. Bei geringem Volumen liegen fixe GPU-Kosten und Betriebspersonal meist über der nutzungsabhängigen Abrechnung; bei großem Volumen, sensiblen Daten oder Anpassungsbedarf lassen sich die Kosten im Selbstbetrieb eher verteilen. Spitzenkapazität mitrechnen.

Reicht das eingebaute Reranking einer Vektordatenbank?

Das hängt vom Szenario ab. Bei kleiner Kandidatenmenge und ohne besondere Modellanforderungen spart die integrierte Funktion eine Integration; werden bestimmte Sprachen, domänenspezifische Feinabstimmung oder feinere Parameter benötigt, ist ein eigener Rerank-Dienst flexibler.

Wie wählt man ein Rerank-Modell für chinesische Szenarien?

Zuerst prüfen, ob das Modell Chinesisch oder Mehrsprachigkeit ausdrücklich unterstützt, dann mit eigenen chinesischen Queries und Dokumenten evaluieren. Englische Ranglisten nicht direkt übernehmen. Gemischte Sprache, lange Dokumente und Fachbegriffe separat sampeln.

Müssen Score-Schwellen nach einem Wechsel neu kalibriert werden?

Meist ja. Score-Verteilungen unterscheiden sich; manche Modelle normalisieren auf null bis eins, andere geben Logits aus. Szenarien mit fester Schwellenfilterung neu kalibrieren oder stattdessen die Rangposition statt des absoluten Scores verwenden.

Nächster Schritt

Wer zunächst nur die Kette testen möchte, kann im ZSQH AI Gateway einen Test-Key anlegen, dieselbe Query-Menge vor und nach dem Reranking vergleichen und die Kosten anhand der Modellpreise schätzen. Modellverfügbarkeit und Abrechnungslogik entnehmen Sie der Preisseite.

Weiterführende Informationen