Reranking ist in einer RAG-Kette einer der am häufigsten unterschätzten Kostenfaktoren. Ein einzelner Aufruf wirkt günstig, doch jede Nutzerfrage durchläuft ihn; mit vielen Kandidatendokumenten wächst die Rechnung über Query- und Dokumentmenge.

Die Abrechnungseinheiten unterscheiden sich je Anbieter: mal pro Query, mal pro Dokument, mal pro Token. Ein direkter Vergleich „Preis pro Aufruf“ ist wenig sinnvoll; entscheidend ist die Umrechnung auf die eigene Query-Menge, Kandidatenmenge und Dokumentlänge. Dieser Beitrag erläutert Abrechnungsstruktur, Kandidatenmenge, Caching und Budgetrechnung, ohne feste Stückpreise zu nennen; maßgeblich sind unsere Modellpreise und die Dokumentation der Anbieter.

Hinweis: Cohere, Jina, Voyage, BAAI und weitere genannte Namen sind Marken ihrer jeweiligen Inhaber; dieser Beitrag dient nur der technischen und abrechnungsbezogenen Einordnung. Abrechnungseinheiten, Limits und Preise können sich ändern; vor dem Einkauf ist die offizielle Seite des Anbieters maßgeblich.

1. Welche Aufgabe Reranking in der Kette hat

Ein typisches zweistufiges Retrieval sieht so aus:

Nutzerfrage
  → Vektor-/Keyword-Retrieval, 20–200 Kandidaten
  → Reranking, Auswahl der Top 5–10
  → Kontext zusammenbauen, an das Generierungsmodell übergeben

Der Input für das Reranking besteht aus „einer Query + einer Menge Kandidatendokumente“; die Ausgabe sind Relevanzscores und eine Rangfolge, kein generierter Text. Es löst das Problem, dass ein richtiger Abschnitt zwar gefunden, aber an zehnter Stelle einsortiert und beim Abschneiden verworfen wird.

Die Kostenposition ist damit klar: ein Aufruf pro Retrieval, manchmal mehrere; jedes Kandidatendokument durchläuft das Modell. Reranking ist meist günstiger als der Wechsel auf ein größeres Generierungsmodell, aber nicht kostenlos.

2. Drei verbreitete Abrechnungsmodelle

Abrechnungsmodell Abrechnungseinheit Womit die Kosten wachsen Typische Vertreter Worauf beim Budget achten
Pro Query eine Query mit einer bestimmten Dokumentmenge Query-Anzahl; lange Dokumente werden in Chunks zerlegt und zählen mit Cohere Rerank Chunking-Regeln erhöhen die Dokumentzahl
Pro Token Query-Token und Dokument-Token Query-Länge, Kandidatenzahl, Dokumentlänge Voyage, Jina u. a. Query-Token werden mit der Dokumentzahl multipliziert
Pro Dokument oder pro Aufruf je Dokument oder je Anfrage Dokumentanzahl, Anfragenzahl einige Managed Services Kürzung und Obergrenzen pro Aufruf prüfen
Selbstbetrieb GPU-Stunden und Betrieb Parallelität, Modellgröße, Auslastung Open-Source-BGE-Reihe Fixkosten, Auslastung entscheidend

Cohere rechnet nach Search Units; die Preisseite definiert diese als „eine Query mit maximal 100 Dokumenten“. Lange Dokumente werden jedoch in Chunks zerlegt, die einzeln als Dokumente zählen. „100 Dokumente“ sind also nicht automatisch „100 abgerechnete Dokumente“; bei Wissensdatenbanken mit vielen langen Dokumenten sollte nach der Chunk-Anzahl geschätzt werden.

Voyage rechnet nach Token. Die Formel lautet: Query-Token × Dokumentanzahl + Summe aller Dokument-Token. Je länger die Query und je größer die Kandidatenmenge, desto stärker wirkt der Multiplikator. Das Feld usage.total_tokens in der Antwort lässt sich direkt für den Abgleich nutzen. Die Schnittstelle akzeptiert pro Aufruf bis zu 1000 Dokumente; überlange Eingaben können standardmäßig gekürzt werden, die Kürzungsregeln sind vorab zu klären.

Jina rechnet ebenfalls nach gesamten Eingabe-Token, Query und Dokumente eingeschlossen; laut offizieller Beschreibung werden fehlgeschlagene Anfragen nicht berechnet, und es gibt eine automatische Aufladung bei unterschrittenem Guthaben-Schwellenwert. Nach Verbrauch des Freikontingents wird kostenpflichtig abgerechnet; maßgeblich ist die Abrechnungsseite.

Ein selbst betriebenes Open-Source-Rerank-Modell (etwa aus der BGE-Reihe) hat keine Gebühr pro Aufruf, aber GPU-, Bandbreiten- und Betriebskosten. Bei stabilem, großem Volumen kann Selbstbetrieb besser kontrollierbar sein; bei kleinem oder stark schwankendem Volumen liegen die fixen GPU-Kosten oft über einer nutzungsabhängigen Abrechnung.

3. Wie die Kandidatenmenge festgelegt wird

Die Rerank-Kosten wachsen grob mit der Zahl der Kandidatendokumente. Werden alle 200 gefundenen Dokumente neu sortiert, kostet das meist ein Mehrfaches von 50 Kandidaten, und die Latenz steigt ebenfalls.

Kandidatenzahl Relativer Aufwand Latenz Einsatzszenario
20–30 niedrig niedrig häufige Support-Anfragen, latenzkritische Schnittstellen
etwa 50 mittel mittel üblicher Ausgangspunkt für allgemeine Wissensdatenbanken
100 höher höher lange Dokumente, verrauschtes Retrieval
über 200 hoch hoch zuerst Retrieval optimieren, nicht direkt einsetzen

Empfohlen ist ein Start bei etwa 50 Kandidaten; mit einem Evaluationsset Recall@k und Antwortrichtigkeit vergleichen und dann erhöhen oder senken.

Ein verbreiteter Irrtum: Ein kleineres top_n reduziert nur die zurückgegebene Anzahl, meist nicht die abgerechneten Dokumente. Gespart wird „vor dem Reranking“, nicht danach. Metadatenfilter, Near-Duplicate-Entfernung, Ähnlichkeitsschwellen und die Eingrenzung nach Geschäftsbereich sind wirksamer als nachträgliches Abschneiden.

4. Dokumentlänge und Chunking

Viele Rerank-Schnittstellen haben eine Token-Obergrenze pro Dokument; überlange Teile werden gekürzt. Gekürzte Inhalte fließen nicht in die Bewertung ein, wodurch wichtige Abschnitte verloren gehen und das Ergebnis schlechter werden kann.

Bei Token-Abrechnung steigen die Kosten mit der Dokumentlänge; bei Dokument-Abrechnung können lange Dokumente in mehrere abgerechnete Dokumente zerlegt werden. In beiden Modellen beeinflusst die Chunking-Strategie also Qualität und Rechnung zugleich.

  • Nur die vom Retrieval gefundenen Abschnitte zum Reranking senden, nicht ganze Dokumente.
  • Chunk-Größe an die Modellobergrenze anpassen; Titel und wichtiger Kontext dürfen nicht verloren gehen.
  • Vor dem Einlesen deduplizieren, damit nahezu identische Chunks nicht mehrfach berechnet werden.
  • Die Token-Verteilung pro Chunk erfassen und das Budget am P95 statt am Mittelwert ausrichten.

5. Latenz und Kosten ausbalancieren

Reranking erhöht die Latenz, mit mehr Kandidaten stärker. Der Ausgleich erfolgt nicht pauschal, sondern nach Szenario:

  • Häufige FAQ können das Reranking überspringen und direkt aus Cache oder Keyword-Suche bedient werden.
  • Latenzkritische Schnittstellen begrenzen die Kandidatenzahl und filtern zuerst über Metadaten.
  • Qualitätskritische Offline-Aufgaben mit geringer Parallelität dürfen mehr Kandidaten verarbeiten.
  • Client-Timeouts und Retry-Obergrenzen setzen. Ein Retry nach Timeout kann dieselbe Query doppelt berechnen.
  • Latenz am P95 statt am Mittelwert bewerten.

6. Caching und Deduplizierung

Der Rerank-Cache liegt nach dem Retrieval und vor der Generierung. Der Cache-Schlüssel sollte mindestens enthalten: normalisierte Query, Dokument-ID und -Version, Modellname und top_n. Fehlt ein Teil, können falsche Ergebnisse an andere Mandanten ausgeliefert werden.

  • Häufige Fragen: TTL von Stunden bis Tagen.
  • Schnell aktualisierte Dokumente: TTL in Minuten oder aktive Invalidierung bei Dokumentänderungen.
  • Berechtigungen: Der Cache-Schlüssel muss Mandant und Berechtigungsumfang enthalten; kein mandantenübergreifender Treffer.
  • Fehlerergebnisse: nicht cachen; auch kurze negative Caches sind mit Vorsicht zu behandeln.
  • Batch-Aufgaben: dieselben Dokumente am selben Tag nicht erneut bewerten, sondern Ergebnisse wiederverwenden.

In Support- und internen Richtlinien-Fragen ist der Anteil wiederkehrender Fragen hoch; Caching bringt dort meist direkteren Nutzen als der Wechsel auf ein günstigeres Modell.

7. Wie das Budget geschätzt wird

Zuerst „pro Query“ nach dem Abrechnungsmodell des Zielanbieters in Abrechnungseinheiten umrechnen und mit der Query-Menge multiplizieren:

Monatskosten ≈ Tages-Queries × 30 × Abrechnungseinheiten pro Query × Stückpreis
               + Retry- und Spitzenreserve

Bei Token-Abrechnung:

Token pro Query = Query-Token × Kandidatenzahl + Summe aller Kandidaten-Token

Reproduzierbare Schätzung:

  1. Durchschnittliche und Spitzen-Query-Menge aus den Logs entnehmen.
  2. 100–200 echte Queries stichprobenartig auswerten und P50/P95 für Kandidatenzahl und Dokument-Token bestimmen.
  3. Pro Query in die Abrechnungseinheit des Anbieters umrechnen.
  4. Mit Tagesmenge und 30 Tagen multiplizieren, dann 10–30 % für Retries, Wachstum und Spitzen zugeben.
  5. Mit dem aktuellen Stückpreis aus den Modellpreisen multiplizieren, nicht mit alten Screenshots.
  6. Nach dem Start wöchentlich abgleichen und die Schätzung anhand echter Rechnungen korrigieren.
# Kostenschätzung bei Token-Abrechnung: Stückpreis aus /pricing eintragen
QUERY_TOKENS = 60             # Median aus der Stichprobe
DOCS_PER_QUERY = 50
AVG_DOC_TOKENS = 180
UNIT_PRICE_PER_MILLION = 0.0  # Platzhalter, durch aktuellen Preis ersetzen

def cost_per_query(q_tokens, n_docs, doc_tokens, price):
    total_tokens = q_tokens * n_docs + n_docs * doc_tokens
    return total_tokens / 1_000_000 * price

per_query = cost_per_query(
    QUERY_TOKENS, DOCS_PER_QUERY, AVG_DOC_TOKENS, UNIT_PRICE_PER_MILLION
)
print(f"Kosten pro Query: {per_query:.6f}")
print(f"Bei 10.000 Queries pro Tag: {per_query * 10_000:.2f}")

Stückpreise, Freikontingente und Staffelrabatte können sich ändern; der Preis im Skript sollte aus der aktuellen Preisseite gelesen und nicht im Repository fest verdrahtet werden.

8. Rechnungsabgleich und Warnungen

  • Rechnungen nach Key, Projekt und Geschäftsbereich trennen, nicht alle Aufrufe in einem Key bündeln.
  • Query-Anzahl, Kandidatendokumente, Token, Modell und Latenz getrennt erfassen.
  • Die Kosten von Embedding, Reranking und Generierung getrennt ausweisen, sonst ist unklar, welcher Abschnitt optimiert werden muss.
  • Retries, leere Queries, doppelte Frontend-Übermittlungen und nächtliche Reindex-Jobs beachten – häufige Ursachen für Kostenausschläge.
  • Tagesbudget und Guthabenwarnungen einrichten und Verantwortliche bei Unterschreitung benachrichtigen.

Die vom Anbieter zurückgegebenen Nutzungsfelder lassen sich für den Abgleich verwenden; Feldnamen und Definitionen richten sich nach der jeweiligen Dokumentation.

Häufige Fragen

Ist Reranking günstiger als der Wechsel auf ein größeres Generierungsmodell?

Meist ja. Das Reranking verarbeitet nur einige Dutzend Kandidaten, bleibt kostenmäßig überschaubar und verbessert direkt das Problem „richtiger Abschnitt steht zu weit hinten“. Wurde der richtige Abschnitt beim Retrieval jedoch gar nicht gefunden, hilft auch das beste Reranking nicht; dann zuerst das Retrieval verbessern.

Spart ein kleineres top_n Kosten?

In der Regel nicht. Abgerechnet werden meist die übergebenen Kandidatendokumente oder Token; top_n beeinflusst nur, wie viele Ergebnisse an das Generierungsmodell gehen. Zum Sparen müssen Kandidaten vor dem Reranking reduziert, dedupliziert und gefiltert werden.

Sind mehr Kandidaten immer besser?

Nicht unbedingt. Mehr Kandidaten bedeuten mehr Rauschen sowie höhere Latenz und Kosten. Mit einem Evaluationsset Recall@k und Antwortrichtigkeit vergleichen und den Punkt suchen, ab dem der zusätzliche Nutzen stagniert; ein üblicher Startwert liegt bei etwa 50.

Müssen lange Dokumente vorher in Chunks zerlegt werden?

Ja. Viele Schnittstellen kürzen an der Token-Obergrenze; überlange Teile werden nicht bewertet. Dienste mit Dokument-Abrechnung können lange Dokumente zudem in mehrere abgerechnete Dokumente zerlegen. Beim Chunking Titel und Kontext erhalten, damit die Antwort nicht zerschnitten wird.

Ist selbst betriebenes Reranking immer günstiger?

Nicht unbedingt. Selbstbetrieb spart die Gebühr pro Aufruf, verursacht aber GPU-, Deployment-, Skalierungs- und Betriebskosten. Bei stabilem Volumen und hoher Auslastung ist Selbstbetrieb besser kontrollierbar; bei kleinem, schwankendem Volumen oder fehlender Betriebskompetenz ist eine nutzungsabhängige API einfacher.

Nächster Schritt

Zuerst mit einer Stichprobe echter Queries Kandidatenzahl und Dokumentlänge ermitteln, dann mit kleinem Budget im ZSQH AI Gateway die Kette „Retrieval – Reranking – Generierung“ durchlaufen und Qualität, Latenz und Kosten mit und ohne Reranking vergleichen. Modellverfügbarkeit und Preise entnehmen Sie den Modellpreisen.

Weiterführende Informationen