Lorsqu'une entreprise achète une API Rerank, l'erreur la plus fréquente est de comparer uniquement « le prix par appel ». Le reranking touche à la requête et au texte des documents, le volume d'appels croît avec le nombre de candidats, et la qualité doit être validée sur vos propres données. Se focaliser sur le prix unitaire conduit souvent à retravailler les quotas, la conformité ou la recette.

Cet article propose une checklist directement utilisable en réunion : volume d'appels, quotas, factures, confidentialité, évaluation, dégradation et recette. Les prix unitaires et quotas ne sont pas figés ; les tarifs des modèles et le contrat font foi.

Remarque : Cohere, Jina, BAAI, BGE, OpenAI et les autres noms cités appartiennent à leurs détenteurs respectifs ; cet article n'implique aucun lien de subordination ni mandat avec ces organismes. Il ne constitue pas un avis juridique ; quotas, prix et clauses de traitement des données relèvent du contrat signé et des pages du fournisseur.

1. Tableau récapitulatif de l'achat

Rassemblez d'abord les éléments d'achat dans un tableau, détaillé ensuite point par point :

Élément Questions à trancher Pièces de recette
Usage et quotas Quota mensuel, QPS, candidats par requête, comportement au dépassement Description des quotas, relevés de test de charge
Facturation et factures Unité de facturation, cycle de règlement, entité émettrice, type de facture Devis, contrat, exemple de facture
Données et confidentialité Conservation, entraînement, lieu de stockage, suppression, sous-traitants Accord de traitement des données, notice de sécurité
Qualité Jeu d'évaluation, référence, indicateurs, seuils de recette Rapport d'évaluation, historique de régression
Droits et audit Sous-comptes, rotation des clés, logs d'appel Matrice des droits, exemple de logs
Dégradation et SLA Notification d'incident, canal de secours, changement de version Clauses SLA, compte rendu d'exercice
Suivi des coûts Tableau de bord d'usage, alerte budgétaire, répartition par projet Captures du tableau de bord, configuration des alertes

2. Calculer le volume avant de parler prix unitaire

Le volume de reranking n'est pas « le nombre de questions utilisateur », mais le nombre de requêtes multiplié par le nombre de documents candidats, puis par le coefficient de retry :

Volume quotidien ≈ requêtes/jour × candidats par requête × (1 + taux de retry)

Dix mille requêtes par jour avec 30 candidats représentent 300 000 scorings de documents ; en facturation par search unit ou par token, la longueur des documents amplifie encore la facture. Avant l'achat, préparez la moyenne quotidienne, le pic d'activité et la croissance attendue sur douze mois ; une estimation sur le trafic de démonstration sous-évalue généralement.

Vérifiez aussi la granularité : par requête, par document, par token, ou un forfait « par recherche ». Ces unités ne se comparent pas directement ; convertissez-les sur le même volume métier.

3. Quotas, limitation et comportement aux pics

Les clauses de quota doivent être écrites. Demandez précisément :

  • les quotas mensuels et annuels, et si l'essai et la production sont séparés ;
  • si la limitation se calcule en QPS, en requêtes par minute ou en concurrence ;
  • le nombre de candidats par appel et la longueur maximale par document ;
  • si le dépassement provoque une erreur, un passage automatique au paiement à l'usage ou un arrêt du service ;
  • si plusieurs projets peuvent partager un quota et si une clé peut avoir son propre plafond.

Le « comportement au dépassement » est le plus souvent négligé : certaines solutions renvoient une erreur, d'autres basculent en post-paiement et la facture peut augmenter sans validation. Exigez des alertes budgétaires et un plafond strict.

4. Facturation, contrat et factures

Le prix affiché sur le site n'est qu'une indication ; il faut obtenir un devis et un contrat formels. Vérifiez :

  • l'unité de facturation, les paliers, le minimum de consommation ou l'engagement de volume ;
  • le prépaiement ou le post-paiement, le cycle et le délai de règlement ;
  • l'entité contractuelle, l'entité émettrice, le type de facture et la TVA ;
  • la possibilité d'une facture avec TVA déductible, et la cohérence de son contenu avec le service ;
  • le préavis de hausse tarifaire et l'effet sur les quotas déjà achetés ;
  • les remboursements, le traitement des quotas non utilisés et l'export des données à la résiliation.

Avec une passerelle API, distinguez à qui vous payez, qui émet la facture et qui porte la responsabilité en cas d'incident. Les services transfrontaliers impliquent aussi devise, change et fiscalité ; faites intervenir la finance en amont.

5. Confidentialité et périmètre de traitement

Une requête de reranking contient à la fois la question et les documents candidats, avec une densité d'information souvent supérieure à une conversation ordinaire. Les contrats et documents de règles internes contiennent souvent des noms de clients, des prix et des données personnelles ; en cas de sortie du territoire ou de conservation prolongée, le risque se transmet à l'activité.

À l'achat, vérifiez point par point :

  • si le contenu des requêtes est conservé, pendant combien de temps et pour quel usage ;
  • s'il est utilisé pour l'entraînement ou l'amélioration du service, et si l'option peut être désactivée par écrit ;
  • les lieux de stockage et de sauvegarde, ainsi que les chemins de transfert transfrontalier ;
  • le mécanisme de suppression : suppression par lot de locataires, délai d'effet ;
  • la liste des sous-traitants et la notification de leurs changements ;
  • le chiffrement, le contrôle d'accès, la notification d'incident et l'accord de traitement des données.

Les équipes aux données très sensibles peuvent évaluer l'auto-hébergement open source : les poids tournent dans leur VPC, les données ne sortent pas du réseau interne, au prix du GPU, de l'exploitation et des mises à jour. Pour un service hébergé, faites inscrire au contrat « pas de conservation, pas d'entraînement, suppression possible ».

6. Évaluation : jeu de test et NDCG

Choisissez 100 à 300 requêtes dans les logs réels, en couvrant les formulations courantes, les fautes de frappe, le multilingue, les documents longs et les cas « la réponse n'est pas dans la base ». Pour chaque requête, prenez les 20 à 50 premiers candidats du rappel de production et annotez selon une échelle 0 (non pertinent), 1 (pertinent), 2 (réponse directe).

L'indicateur principal est NDCG@10, complété par MRR, le taux de présence dans le Top 3, la latence P95 et le coût par requête. Enregistrez aussi Recall@k du jeu de candidats : c'est le plafond de l'effet du reranking.

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

# Renseigner les niveaux de pertinence dans l'ordre après reranking : 2=réponse directe, 1=pertinent, 0=non pertinent
ranked = [2, 0, 1, 0, 0, 1, 0, 0, 0, 0]
print(round(ndcg_at_k(ranked), 4))

Ne recopiez pas les seuils de recette des classements publics et n'acceptez pas un « très bon résultat » oral. Avant le pilote, l'activité et le fournisseur doivent convenir par écrit : gain de NDCG@10 par rapport à la référence, valeur absolue minimale, plafond de latence P95 et plafond de taux d'erreur, avec des résultats reproductibles et utilisables en régression.

7. Droits, audit et gestion des clés

  • Attribuer une clé distincte par environnement et par projet, avec interdiction de partage.
  • Appliquer le moindre privilège, permettre rotation et révocation, interdire le stockage dans le front-end ou un dépôt public.
  • Si disponible, configurer une liste d'IP et un plafond de débit par clé, pour qu'un projet ne consomme pas tout le quota global.
  • Journaliser la durée de conservation, la version du modèle, la latence, le code de statut et l'usage, en anonymisant les champs de contenu selon les exigences de conformité.
  • Vérifier que la console gère les rôles et l'audit des actions, et retirer les droits des partants sans délai.

Avec une passerelle unifiée, vérifiez aussi sa politique de logs et ses capacités de sous-comptes : un relais de plus, c'est un acteur de traitement des données de plus, à couvrir par le contrat et la revue.

8. Dégradation et continuité

Le reranking est une étape d'amélioration ; il ne doit pas devenir un point de défaillance unique. Le dossier d'achat doit préciser :

  • les codes d'erreur et le mécanisme de notification en cas d'indisponibilité ;
  • l'existence d'un canal de secours multi-région ou multi-fournisseur ;
  • le budget de timeout et la logique de retour à la similarité vectorielle ou au classement par mots-clés ;
  • la file d'attente, les retries et le disjoncteur en cas de limitation, pour éviter une tempête de retries ;
  • la fenêtre de migration en cas de retrait de modèle ou de changement de version.

Côté ingénierie, encapsulez le reranking dans une interface indépendante, gardez un interrupteur « reranking désactivé » et faites des exercices réguliers. Un retour arrière en un clic est plus utile que n'importe quel engagement.

9. Recette du pilote et suivi des coûts

Avancez par étapes pour éviter de signer d'emblée un gros contrat pluriannuel :

  1. Définir le périmètre du pilote : ligne métier, types de requêtes, plafond d'appels quotidiens et critères de succès.
  2. Préparer le jeu d'évaluation et la référence : sans reranking, solution actuelle et solution candidate sur le même jeu de candidats.
  3. Brancher un faible trafic, comparer en double exécution, relever qualité, latence, taux d'erreur et usage réel.
  4. Organiser une revue humaine par échantillonnage des différences avant/après, pour vérifier que le gain n'est pas un biais d'annotation.
  5. Après la recette, signer le contrat ou étendre, avec alertes budgétaires et revue mensuelle.

Après mise en production, suivez quatre chiffres : volume quotidien, nombre moyen de candidats, taux de hits de cache et coût par ligne métier. Les leviers d'optimisation : réduire les candidats inutiles, désactiver le reranking sur les requêtes à faible valeur, mettre en cache les résultats fréquents et fixer un budget par projet. Passer de 50 à 20 candidats réduit facture et latence ; l'effet sur la qualité se confirme sur le jeu d'évaluation.

Questions fréquentes

Sur quelle base facture-t-on généralement une API Rerank ?

Les unités courantes sont l'appel, la search unit, le document et le token. Les définitions varient selon les fournisseurs ; convertissez sur le même volume métier avant de comparer, et référez-vous au contrat et aux tarifs des modèles.

Un quota d'essai peut-il servir à la mise en production ?

La plupart des quotas d'essai visent l'évaluation, peuvent interdire l'usage commercial et n'offrent pas de SLA de production. Utilisez un quota payant ou un déploiement privé, et vérifiez facture, accord de traitement des données et responsabilité en cas d'incident.

À partir de quel NDCG considère-t-on le résultat acceptable ?

Il n'existe pas de chiffre universel : cela dépend de la qualité du rappel, du barème d'annotation et de la tolérance métier. La démarche plus solide est de fixer un objectif de gain par rapport à la référence, puis de confirmer la qualité absolue par revue humaine.

Données sensibles : faut-il forcément un déploiement privé ?

Pas nécessairement. Vous pouvez évaluer un service hébergé avec absence de conservation, absence d'entraînement, suppression possible et accord de données signé ; si la conformité n'est toujours pas satisfaite, passez à l'auto-hébergement open source. Comparez le coût total des deux voies.

Une mise à jour de modèle par le fournisseur peut-elle changer le résultat ?

Oui. Comportement de classement, échelle des scores et latence peuvent évoluer. Exigez un préavis de changement de version, fixez la version autant que possible et conservez un jeu de régression à exécuter avant et après la mise à jour.

Étapes suivantes

Pour brancher la chaîne RAG existante, commencez avec un petit budget via l'inscription à ZSQH AI Gateway, gérez clés, quotas et logs d'usage de façon unifiée, puis déroulez la recette du pilote selon la checklist. Modèles et prix de référence : tarifs des modèles ; conditions d'achat : contrat et documentation du fournisseur.

Lectures associées :