Beim Unternehmenseinkauf einer Rerank API ist der häufigste Fehler, nur „Preis pro Aufruf“ zu vergleichen. Reranking berührt Query und Dokumenttext, das Aufrufvolumen wächst mit der Kandidatenzahl, und die Qualität muss mit eigenen Daten belegt werden. Wer nur auf den Stückpreis schaut, muss bei Kontingenten, Compliance oder Abnahme häufig nacharbeiten.

Dieser Beitrag liefert eine Checkliste, die direkt in die Besprechung mitgenommen werden kann – von Aufrufvolumen, Kontingenten und Rechnungen bis Datenschutz, Evaluation, Ausfallsicherheit und Abnahme. Feste Stückpreise und Kontingente werden nicht genannt; maßgeblich sind unsere Modellpreise und der Vertrag.

Hinweis: Cohere, Jina, BAAI, BGE, OpenAI und weitere genannte Namen gehören ihren jeweiligen Inhabern; dieser Beitrag steht in keiner Zugehörigkeits- oder Vertretungsbeziehung zu diesen Organisationen. Er dient der Beschaffungsdiskussion und ist keine Rechtsberatung; Kontingente, Preise und Datenverarbeitungsbedingungen richten sich nach dem unterzeichneten Vertrag und den offiziellen Seiten.

1. Übersicht der Beschaffungspunkte

Zuerst die Beschaffungspunkte in einer Tabelle sammeln, danach einzeln vertiefen:

Beschaffungspunkt Zu klärende Frage Abnahmebelege
Nutzung und Kontingent Monatskontingent, QPS, Kandidaten pro Anfrage, Verhalten bei Überschreitung Kontingentbeschreibung, Lasttestprotokoll
Abrechnung und Rechnung Abrechnungseinheit, Abrechnungszyklus, Rechnungssteller, Rechnungsart Angebot, Vertrag, Rechnungsbeispiel
Daten und Datenschutz Aufbewahrung, Training, Speicherort, Löschung, Unterauftragsverarbeiter Datenverarbeitungsvertrag, Sicherheitsbeschreibung
Qualität Evaluationsset, Baseline, Kennzahlen, Abnahmeschwelle Evaluationsbericht, Regressionsprotokoll
Rechte und Audit Unterkonten, Key-Rotation, Aufruflogs Rechte-Matrix, Log-Beispiel
Ausfallsicherheit und SLA Störungsmeldung, Ersatzkanal, Versionsänderungen SLA-Klauseln, Übungsprotokoll
Kostenmonitoring Nutzungsdashboard, Budgetwarnungen, Projektzuordnung Dashboard-Screenshot, Warnkonfiguration

2. Zuerst Aufrufvolumen berechnen, dann über Stückpreis sprechen

Das Rerank-Aufrufvolumen ist nicht die Zahl der Nutzerfragen, sondern Query-Anzahl × Kandidatendokumente pro Anfrage × Retry-Faktor:

Tagesvolumen ≈ Tages-Queries × Kandidaten pro Query × (1 + Retry-Rate)

Bei zehntausend Queries pro Tag und dreißig Kandidaten pro Query entstehen dreihunderttausend Dokumentbewertungen; bei Abrechnung nach Search Units oder Token erhöht die Dokumentlänge die Rechnung zusätzlich. Vor dem Einkauf Tagesdurchschnitt, Kampagnenspitzen und Wachstumserwartung für zwölf Monate vorbereiten; eine Schätzung mit Demonstrations-Traffic fällt meist zu niedrig aus.

Auch die Abrechnungsgranularität klären: pro Query, pro Dokument, pro Token oder als Pauschale „pro Suche“. Unterschiedliche Modelle lassen sich nicht direkt vergleichen; erst auf dasselbe Geschäftsvolumen umrechnen.

3. Kontingent, Rate-Limits und Verhalten in Spitzenzeiten

Kontingentbedingungen gehören schriftlich festgehalten. Besonders klären:

  • Monats- und Jahreskontingent; sind Test- und Produktionskontingent getrennt?
  • Wird die Rate über QPS, Anfragen pro Minute oder Parallelität gemessen?
  • Wie viele Kandidaten pro Anfrage und welche maximale Dokumentlänge sind erlaubt?
  • Wird bei Überschreitung ein Fehler zurückgegeben, automatisch auf nutzungsabhängige Abrechnung umgestellt oder der Dienst gestoppt?
  • Können mehrere Projekte ein Kontingent teilen, und lässt sich für einen einzelnen Key eine Obergrenze setzen?

Das „Verhalten bei Überschreitung“ wird am häufigsten übersehen: Manche Dienste melden einen Fehler, andere wechseln automatisch in Postpaid und die Rechnung steigt ohne Freigabe. Budgetwarnungen und harte Obergrenzen verlangen.

4. Abrechnung, Vertrag und Rechnung

Der Webpreis ist nur eine Orientierung; letztlich zählen offizielles Angebot und Vertrag. Zu bestätigen:

  • Abrechnungseinheit, Staffelpreise, Mindestumsatz oder Mindestabnahme.
  • Voraus- oder Nachzahlung, Abrechnungszyklus und Zahlungsziel.
  • Vertragspartner, Rechnungssteller, Rechnungsart und Steuersatz.
  • Unterstützung spezieller Umsatzsteuerrechnungen und Übereinstimmung des Rechnungsinhalts mit der Leistung.
  • Vorlaufzeit bei Preisanpassungen und ob bereits gekaufte Kontingente betroffen sind.
  • Erstattungen, Behandlung ungenutzten Kontingents und Datenexport nach Vertragsende.

Bei einem API-Gateway muss klar sein, an wen gezahlt wird, wer die Rechnung stellt und wer bei Störungen haftet. Grenzüberschreitende Dienste berühren zusätzlich Währung, Wechselkurs und Steuern; die Finanzabteilung sollte früh eingebunden werden.

5. Datenschutz und Verarbeitungsgrenzen

Rerank-Anfragen enthalten Query und Kandidatendokumente; die Informationsdichte kann höher sein als bei normalen Chats. Verträge und Richtlinien enthalten oft Kundennamen, Preise und personenbezogene Daten; bei Auslandsübermittlung oder langer Aufbewahrung entstehen Risiken bis in die Fachabteilungen.

Beim Einkauf einzeln klären:

  • Werden Anfrageinhalte gespeichert, wie lange und zu welchem Zweck?
  • Werden sie für Training oder Dienstverbesserung genutzt, und lässt sich das schriftlich abschalten?
  • Wo liegen Speicher und Backups, welche grenzüberschreitenden Wege gibt es?
  • Löschmechanismus: können Daten mandantenweise gelöscht werden, und wie schnell wirkt das?
  • Liste der Unterauftragsverarbeiter und Benachrichtigung bei Änderungen.
  • Verschlüsselung, Zugriffskontrolle, Vorfallmeldung und Datenverarbeitungsvertrag.

Für besonders sensible Daten kann Open Source im Selbstbetrieb geprüft werden: Die Gewichte laufen in der eigenen VPC, Daten verlassen das interne Netz nicht; dafür entstehen GPU-, Betriebs- und Upgrade-Kosten. Bei Managed Services sollten „keine Aufbewahrung, kein Training, Löschung möglich“ im Vertrag stehen.

6. Qualitätsbewertung: Evaluationsset und NDCG

Das Evaluationsset wird aus echten Logs mit 100–300 Queries gebildet und deckt häufige Formulierungen, Tippfehler, mehrere Sprachen, lange Dokumente und Fälle ohne Antwort in den Unterlagen ab. Zu jeder Query kommen 20–50 Kandidaten aus dem Produktions-Retrieval, bewertet mit 0 (irrelevant), 1 (relevant), 2 (direkte Antwort).

Hauptkennzahl ist NDCG@10, ergänzt um MRR, Top-3-Trefferquote, P95-Latenz und Kosten pro Query. Auch Recall@k der Kandidatenmenge erfassen; er ist die Obergrenze für die Rerank-Qualität.

import math

def dcg(rels, k):
    return sum((2 ** r - 1) / math.log2(i + 2) for i, r in enumerate(rels[:k]))

def ndcg_at_k(ranked_rels, k=10):
    ideal = sorted(ranked_rels, reverse=True)
    idcg = dcg(ideal, k)
    return dcg(ranked_rels, k) / idcg if idcg else 0.0

# Relevanzstufen in der rerankten Reihenfolge: 2=direkte Antwort, 1=relevant, 0=irrelevant
ranked = [2, 0, 1, 0, 0, 1, 0, 0, 0, 0]
print(round(ndcg_at_k(ranked), 4))

Abnahmeschwellen nicht aus öffentlichen Ranglisten übernehmen und keine mündliche Aussage „die Qualität ist gut“ akzeptieren. Fachbereich und Anbieter sollten vor dem Pilot schriftlich vereinbaren: NDCG@10-Verbesserung gegenüber der Baseline, absoluter Mindestwert, Obergrenze für P95-Latenz und Fehlerrate – reproduzierbar und regressionsfähig.

7. Rechte, Audit und Key-Verwaltung

  • Nach Umgebung und Projekt getrennte Keys vergeben; gemeinsame Nutzung verbieten.
  • Keys mit minimalen Rechten, Rotations- und Widerrufsmöglichkeit; nicht ins Frontend oder öffentliche Repository schreiben.
  • Falls unterstützt, IP-Whitelist und Rate-Obergrenze pro Key konfigurieren, damit ein Projekt nicht das globale Kontingent aufbraucht.
  • Aufruflogs mit Zeitpunkt, Modellversion, Dauer, Statuscode und Nutzung aufbewahren; Inhaltsfelder gemäß Compliance anonymisieren.
  • Rollen und Aktions-Audit in der Konsole; bei Personalabgang Rechte zeitnah entziehen.

Bei einem einheitlichen Gateway zusätzlich dessen Logstrategie und Unterkonten prüfen: Jede zusätzliche Vermittlungsstufe ist ein weiterer Datenverarbeiter, der in Vertrag und Review abgedeckt sein muss.

8. Ausfallsicherheit und Notfallbetrieb

Reranking ist eine Verbesserungsstufe und darf kein Single Point of Failure sein. Der Beschaffungsplan sollte beschreiben:

  • Fehlercodes und Benachrichtigungsmechanismus bei Nichtverfügbarkeit.
  • Ob es Ersatzkanäle über mehrere Regionen oder Anbieter gibt.
  • Timeout-Budget und die Logik, nach Timeout auf Vektorähnlichkeit oder Keyword-Sortierung zurückzufallen.
  • Queue-, Retry- und Circuit-Breaker-Strategie bei Rate-Limits, damit ein Retry-Sturm die Störung nicht verstärkt.
  • Migrationsfenster bei Modellabkündigung oder Versionswechsel.

Technisch das Reranking als eigene Schnittstelle kapseln, einen Schalter „Reranking aus“ behalten und regelmäßig üben. Ein Ein-Klick-Rollback im Ernstfall ist praktischer als jede Zusage.

9. Pilotabnahme und Kostenmonitoring

Schrittweise vorgehen und nicht sofort einen langfristigen Großvertrag unterschreiben:

  1. Pilotumfang festlegen: Geschäftsbereich, Query-Typen, Obergrenze für Tagesvolumen und Erfolgskriterien.
  2. Evaluationsset und Baseline vorbereiten: ohne Reranking, bestehende Lösung und Kandidatenlösung auf derselben Kandidatenmenge.
  3. Mit wenig Traffic anbinden, parallel vergleichen und Qualität, Latenz, Fehlerrate und tatsächliche Nutzung erfassen.
  4. Manuelle Prüfung organisieren, Unterschiede vor und nach der Sortierung stichprobenartig prüfen und bestätigen, dass die Verbesserung nicht auf Annotationsverzerrung beruht.
  5. Erst nach bestandener Abnahme Vertrag oder Ausbau beschließen und Budgetwarnungen sowie monatliche Reviews einrichten.

Nach dem Start vier Kennzahlen überwachen: Tagesvolumen, durchschnittliche Kandidatenzahl, Cache-Trefferquote und Kosten pro Geschäftsbereich. Optimierungshebel sind weniger nutzlose Kandidaten, Reranking aus bei geringwertigen Queries, Caching häufiger Ergebnisse und Budgets pro Projekt. Von 50 auf 20 Kandidaten senkt Rechnung und Latenz; die Qualität mit dem Evaluationsset bestätigen.

Häufige Fragen

Wie wird eine Rerank API üblicherweise abgerechnet?

Verbreitet sind Abrechnung nach Aufrufen, Search Units, Dokumentanzahl und Token. Die Definitionen unterscheiden sich je Anbieter; für den Vergleich auf dasselbe Geschäftsvolumen umrechnen und Vertrag sowie Modellpreise heranziehen.

Kann ein Testkontingent für den Produktivbetrieb genutzt werden?

Die meisten Testkontingente sind für Evaluierung gedacht, können kommerzielle Nutzung ausschließen und bieten keine Produktions-SLA. Für den Regelbetrieb kostenpflichtiges Kontingent oder private Bereitstellung wählen und Rechnung, Datenverarbeitungsvertrag und Störungshaftung klären.

Welcher NDCG-Wert gilt als gut?

Eine allgemeingültige Zahl gibt es nicht; sie hängt von Kandidatenqualität, Annotation und fachlicher Toleranz ab. Sinnvoller ist ein Verbesserungsziel gegenüber der Baseline, ergänzt durch manuelle Prüfung der absoluten Qualität.

Muss ich bei sensiblen Daten privat betreiben?

Nicht zwingend. Managed Services mit Vertrag über keine Aufbewahrung, kein Training und Löschung prüfen; erst wenn die Compliance-Anforderungen weiterhin nicht erfüllt sind, Open Source im Selbstbetrieb wählen. Bei beiden Wegen die Gesamtkosten berechnen.

Beeinflusst ein Modell-Upgrade des Anbieters die Qualität?

Möglich. Sortierverhalten, Score-Skala und Latenz können sich ändern. Beim Einkauf Vorabinformation bei Versionswechsel verlangen, möglichst eine Version fixieren und ein Regressionsevaluationsset vor und nach dem Upgrade laufen lassen.

Nächster Schritt

Für die Anbindung an eine bestehende RAG-Kette kann mit kleinem Budget das ZSQH AI Gateway registriert werden, um Keys, Kontingente und Nutzungslogs zentral zu verwalten und danach die Checkliste für die Pilotabnahme zu nutzen. Modelle und Preise entnehmen Sie den Modellpreisen; Beschaffungsbedingungen dem Vertrag und der offiziellen Dokumentation.

Weiterführende Informationen