Eine Rerank API liegt nicht auf dem Generierungspfad, entscheidet aber direkt darüber, ob die ersten Suchtreffer richtig sind. Sie schickt „Query + eine Gruppe Kandidatendokumente“ in ein Reranking-Modell und liefert eine nach Relevanz sortierte Reihenfolge zurück. Da der Aufruf während der Wartezeit der Nutzer erfolgt, muss ein inländisches Team nicht nur „ob es funktioniert“ lösen, sondern ob das Netz stabil ist, die Rechnung erstattet werden kann, die Latenz beherrschbar bleibt und bei Störungen ein Fallback existiert.

Dieser Beitrag vergleicht Direktverbindung, Relay und einheitliches Gateway und gibt eine Prüfliste vor dem Start. Konkrete Modelle, Endpunktpfade und Preise entnehmen Sie den Anbieterdokumentationen und unseren Modellpreisen.

Hinweis: Cohere, Jina AI und weitere genannte Namen sind Marken ihrer jeweiligen Inhaber; dieser Beitrag steht in keiner Verbindung zu den betreffenden Anbietern. Feste Stückpreise werden nicht genannt; vor dem Einkauf sind die aktuellen Angebote und Verträge der Anbieter maßgeblich.

1. Warum Rerank API ein eigenes Integrationsproblem ist

Rerank unterscheidet sich in drei Punkten von Chat-APIs. Erstens ist es eine synchrone Kurzanfrage: Ein Aufruf dauert oft nur einige Dutzend bis einige Hundert Millisekunden, aber der Nutzer wartet genau darauf. Zweitens gehört es nicht zum OpenAI-Chat-Completions-Standard; Felder und Pfade werden von jedem Anbieter festgelegt, etwa /v2/rerank bei Cohere und /v1/rerank bei Jina. Bei einer Migration reicht es nicht, nur die Base URL zu wechseln. Drittens kann die Abrechnungseinheit Anfragezahl, Dokumentanzahl, Token oder Search Unit sein; die Rechnungsstruktur ist komplexer als „Input-/Output-Token“.

Eine inländische Zugangslösung muss daher vier Dinge gleichzeitig erfüllen: dauerhaft erreichbares Netz, Zahlung und Rechnung über Unternehmensprozesse, Latenz innerhalb des Suchbudgets sowie Pläne für Rate-Limits und Störungen. „Es kommen Ergebnisse zurück“ genügt bei Weitem nicht.

2. Auswahl zwischen Direktverbindung, Relay und einheitlichem Gateway

Die üblichen Wege lassen sich in vier Kategorien fassen. Die Direktverbindung zum ausländischen Anbieter passt zu Teams mit internationalem Netz und Fremdwährungszahlung; die Direktverbindung zu einem inländischen Anbieter ist bei Netz und Rechnung einfacher, erfordert aber Anpassung von Modell und Protokoll; ein kommerzielles Relay bündelt Netz und Zahlung; ein einheitliches Gateway betont die Zusammenführung mehrerer Anbieter, Key-Verwaltung und eine gemeinsame Rechnung.

Weg Netz Zahlung und Rechnung Latenzkontrolle Rate-Limits und Failover Geeignet für
Direkt beim ausländischen Anbieter abhängig von internationalen Strecken, in Spitzenzeiten schwankend meist Fremdwährungskarte, Rechnungsprozess länger Region wählbar, aber hohe grenzüberschreitende RTT 429 und Retries selbst behandeln Teams mit ausländischer Gesellschaft und Betriebskompetenz
Direkt beim inländischen Anbieter inländischer Zugriff meist stabil Abrechnung in RMB, Rechnung einfacher Region wählbar, kurze Strecke an Anbieterkontingente gebunden überwiegend inländische Nutzer
Kommerzielles Relay Anbieter optimiert die Route Aufladung in RMB, Rechnungsfähigkeit prüfen abhängig vom Relay-Routing Anbieter fängt ab, Zuständigkeiten klären kleine Teams mit schnellem Startbedarf
Einheitliches Gateway mehrere Routen auf Gateway-Seite gemeinsame Rechnung, einfacher für Beschaffung abhängig von der Gateway-Region mehrere Upstreams und Fallback konfigurierbar mehrere Modelle und Projekte parallel

Bei der Auswahl nicht nur Stückpreise vergleichen. „Wer analysiert im Störungsfall“, „welche Gesellschaft stellt die Rechnung“ und „sind Dauer und Abrechnungsdetails pro Aufruf verfügbar“ gehören in die Bewertungstabelle – oft wichtiger als ein paar gesparte Prozentpunkte. Für einen Test der einheitlichen Anbindung kann man über das Registrierungsportal die aktuell unterstützten Schnittstellen und Modelle prüfen und dann über den Produktiveinsatz entscheiden.

3. Netz und Latenz: zuerst das Suchbudget berechnen

Reranking liegt üblicherweise nach dem Retrieval und vor der Generierung. Ein brauchbares Budget ist etwa: Retrieval 20–80 Millisekunden, Reranking-P95 unter 300 Millisekunden, Generierung 1–3 Sekunden. Bei sofort sichtbarer Suche muss das Reranking möglicherweise asynchron erfolgen oder nur für die zweite Ergebnisseite genutzt werden.

Die Latenz hängt vor allem von drei Variablen ab: Kandidatendokumente, Länge des einzelnen Dokuments und Gesamt-Token von Query und Dokumenten. Jina nennt als Referenz für 100 Dokumente mit etwa 256 Token und eine Query mit 64 Token rund 150 Millisekunden; bei 4096 Token pro Dokument steigt es auf mehrere Sekunden. Cohere empfiehlt pro Anfrage maximal 1000 Dokumente und kürzt einzelne Dokumente standardmäßig bei 4096 Token. Diese Zahlen variieren mit Modell und Last, die Regel ist aber gleich: zuerst Kandidaten reduzieren, dann kürzen und erst zuletzt ein schnelleres Modell erwägen.

Technisch sind vier Dinge vorrangig: top_n klein halten und nur die wirklich benötigten Treffer zurückgeben; lange Dokumente vorher chunken oder kürzen; in der Nähe der eigenen Region aufrufen; Verbindungen wiederverwenden, statt bei jeder Anfrage neu zu handshaken. Bei der Messung P95 und P99 betrachten, nicht nur den Mittelwert.

4. Zahlung, Rechnung und Vertrag

Bei ausländischer Direktverbindung sind Zahlungsart und Erstattungsweg häufig problematisch. Fremdwährungskarte, Wechselkurs, Rechnung einer ausländischen Gesellschaft und Erstattungsregeln für vorausbezahltes Guthaben beeinflussen die Finanzprozesse. Inländische Anbieter und die meisten Gateways rechnen in RMB ab, aber Rechnungsart, Rechnungszeitpunkt, Rechnungsfähigkeit der Aufladung und Rückzahlung auf dem ursprünglichen Weg sind zu bestätigen.

Vor Vertrag oder Bestellung sollten fünf Punkte schriftlich geklärt werden: die Abrechnungseinheit, ob fehlgeschlagene Anfragen berechnet werden, ob ein Mindestumsatz besteht, wie Preisanpassungen angekündigt werden und welche Aufbewahrungs- und Logstrategie gilt. Beim Reranking enthalten Anfragen Ausschnitte von Geschäftsdokumenten, möglicherweise Kundeninformationen oder interne Unterlagen; Datenverarbeitungsbedingungen dürfen nicht einfach „wie bei der Chat-Schnittstelle“ unterstellt werden.

5. Rate-Limits, Timeouts und Failover

Rerank-Limits werden üblicherweise gleichzeitig über RPM und TPM gemessen. Da die Kosten mit „Dokumentanzahl × Länge“ wachsen, löst ein Batch-Reranking in Spitzenzeiten leicht das Kontingent aus. Der Client braucht klare Timeouts, etwa 800 Millisekunden bis 1,5 Sekunden; nach einem Fehler höchstens einmal wiederholen und Jitter ergänzen, um einen Retry-Sturm zu vermeiden.

Noch wichtiger ist der Fallback-Pfad. Scheitert das Reranking, sollte das System auf die ursprüngliche Retrieval-Reihenfolge zurückfallen oder einen anderen Anbieter nutzen, statt die gesamte Suche fehlschlagen zu lassen. Das folgende Beispiel zeigt einen Aufruf mit Timeout; Feldnamen sind gemäß Anbieterdokumentation anzupassen:

curl -sS --max-time 1.5 https://<your-endpoint>/v1/rerank \
  -H "Authorization: Bearer $RERANK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<laut Anbieterdokumentation>",
    "query": "Welche Unterlagen braucht man für eine Firmengründung in Russland?",
    "documents": ["Ausschnitt eins", "Ausschnitt zwei", "Ausschnitt drei"],
    "top_n": 5,
    "return_documents": false
  }'

Wichtig: Pfade und Felder sind bei den Anbietern nicht einheitlich; return_documents, Score-Bereich und Unterstützung strukturierter Dokumente müssen einzeln geprüft werden. Nicht davon ausgehen, dass der Austausch der Base URL einer Chat-Schnittstelle für das Reranking ausreicht.

6. Prüfliste vor dem Produktivstart

  1. Protokoll prüfen: Anfragepfad, Pflichtfelder, Score-Bereich und maximale Dokumentanzahl bestätigen.
  2. Mit echten Queries und 50–100 Kandidaten offline vergleichen und Änderungen der Sortierqualität festhalten.
  3. In der Zielregion einen Lasttest durchführen und P50, P95, P99 sowie Fehlerrate erfassen.
  4. Gezielt 429 auslösen und prüfen, ob die Backoff-Strategie greift.
  5. Timeout und 5xx simulieren und bestätigen, dass ein Rückfall auf die ursprüngliche Sortierung oder einen Ersatzanbieter funktioniert.
  6. Mit einer festen Workload die Aufruflogs gegen die tatsächliche Rechnung abgleichen.
  7. Vertragspartner, Rechnungsart, Erstattungsregeln und Datenbedingungen bestätigen.
  8. Mit wenig Traffic schrittweise live gehen und dabei Suchklickrate und Schnittstellenlatenz beobachten.

Der Kern dieser Liste ist nicht „einmal testen“, sondern reproduzierbare Aufzeichnungen zu hinterlassen. Rerank-Qualität und -Latenz hängen stark vom eigenen Korpus ab; fremde Benchmarks sind nur eine Orientierung.

7. Häufige Fragen

Worin unterscheiden sich Rerank API und Embedding API?

Embedding wandelt Text in Vektoren um und dient dem groben Retrieval; Rerank bewertet „Query–Dokument“-Paare direkt und dient der Feinordnung. Beide werden meist hintereinander eingesetzt und können einander nicht ersetzen.

Kann Rerank eines inländischen Anbieters ausländische Modelle direkt ersetzen?

Schnittstelle und Score-Verteilung können abweichen. Nach dem Wechsel Schwellenwerte neu kalibrieren und dieselbe Query-Menge für den Sortiervergleich nutzen; ein HTTP-200 allein genügt nicht.

Braucht die Direktverbindung zu einer ausländischen API zwingend eine Standleitung?

Nicht unbedingt. Zuerst Paketverlust, P95 und Timeout-Rate im Zielzeitfenster messen. Ist der Dienst latenzempfindlich, danach Standleitung, Regional-Gateway oder Relay prüfen; nicht sofort die schwerste Lösung wählen.

Wie viel langsamer wird die Suche durch Reranking?

Das hängt von Kandidatenzahl und Dokumentlänge ab. Mit einigen Dutzend Kandidaten und gekürzten Einzeldokumenten lässt sich der Zusatzaufwand meist auf einige Hundert Millisekunden begrenzen; lange Dokumente und große Batches werden deutlich langsamer.

Unterstützt jedes einheitliche Gateway Rerank?

Nein. Rerank gehört nicht zum OpenAI-Chat-Standard; ob es unterstützt wird, steht in der Schnittstellenliste des Gateways. Bei der Auswahl zuerst die Protokollkompatibilität prüfen, dann Preis und Kontingent; über das Registrierungsportal lässt sich der aktuelle Funktionsumfang prüfen.

Weiterführende Informationen