Le Rerank (reranking) est le poste de coût le plus souvent sous-estimé dans une chaîne RAG. Un appel isolé paraît peu cher, mais il s'exécute pour chaque question utilisateur ; dès que les documents candidats se multiplient, la facture augmente avec le nombre de requêtes et le volume de documents.

Les unités de facturation varient d'un fournisseur à l'autre : certains facturent par requête, d'autres par document, d'autres par token. Comparer directement « le prix par appel » n'a pas de sens : il faut convertir les tarifs dans votre volume de requêtes, votre jeu de candidats et la longueur de vos documents. Cet article détaille la structure de facturation, le choix du jeu de candidats, le cache et l'estimation budgétaire, sans figer de prix unitaire ; les valeurs exactes sont celles des tarifs des modèles et de la documentation des fournisseurs.

Remarque : Cohere, Jina, Voyage, BAAI et les autres noms cités sont des marques de leurs détenteurs respectifs. Cet article ne traite que de la structure technique et tarifaire. Les unités, quotas et prix peuvent évoluer ; avant tout achat, consultez les pages du fournisseur.

1. Le rôle du Rerank dans la chaîne

La recherche en deux étapes typique est la suivante :

Question utilisateur
  → rappel vectoriel ou par mots-clés : 20 à 200 candidats
  → reranking fin, conservation des 5 à 10 premiers
  → assemblage du contexte, remise au modèle de génération

L'entrée du Rerank est « une requête + un lot de documents candidats » ; la sortie est un score de pertinence et un classement, sans génération de texte. Il résout le cas où le bon extrait a bien été rappelé mais se trouve en dixième position et serait perdu par une troncature directe.

Sa place dans le coût est donc claire : un appel par recherche, parfois plusieurs ; chaque candidat passe dans le modèle. Le reranking coûte généralement moins cher que le remplacement par un modèle de génération plus gros, mais il n'est pas gratuit.

2. Trois unités de facturation courantes

Unité Base de calcul Ce qui fait croître le coût Exemples courants Point d'attention budgétaire
Par requête Une requête, avec un certain nombre de documents Nombre de requêtes ; le découpage des longs documents compte aussi Cohere Rerank La règle de découpage gonfle le nombre de documents
Par token Tokens de requête et tokens de documents Longueur de requête, nombre de candidats, longueur des documents Voyage, Jina, etc. Les tokens de requête sont multipliés par le nombre de documents
Par document ou par appel Chaque document ou chaque requête Nombre de documents, nombre d'appels Certains services hébergés Vérifier troncature et plafond par appel
Auto-hébergé Heures GPU et exploitation Concurrence, taille du modèle, taux d'utilisation Série BGE open source Coût fixe, à juger sur l'utilisation

Cohere facture en search units ; sa page tarifaire définit « une requête, jusqu'à 100 documents ». Mais les documents longs sont découpés en blocs, chacun compté comme document. « 100 documents » ne signifie donc pas « 100 documents facturés » : pour une base riche en documents longs, estimez sur le nombre de blocs après découpage.

Voyage facture au token, selon la formule : tokens de requête × nombre de documents + somme des tokens de tous les documents. Plus la requête est longue et les candidats nombreux, plus l'effet multiplicateur est marqué. Le champ usage.total_tokens de la réponse permet un rapprochement direct. L'interface accepte jusqu'à 1000 documents par appel ; les entrées très longues peuvent être tronquées par défaut, et la règle de troncature doit être vérifiée à l'avance.

Jina facture également sur le total de tokens d'entrée, requête et documents compris ; sa documentation indique que les requêtes échouées ne sont pas facturées et propose un rechargement automatique par seuil de solde. Une fois le quota gratuit épuisé, la facturation devient payante ; les modalités exactes figurent sur la page de facturation.

Un modèle de reranking open source auto-hébergé (série BGE, par exemple) n'a pas de coût à l'appel, mais implique GPU, bande passante et exploitation. Avec un trafic stable et important, l'auto-hébergement peut être plus maîtrisable ; avec un trafic faible ou irrégulier, le coût fixe du GPU dépasse souvent le paiement à l'usage.

3. Comment fixer le jeu de candidats

Le coût du Rerank croît approximativement avec le nombre de documents candidats. Reranger 200 candidats coûte généralement plusieurs fois plus que 50, et la latence augmente aussi.

Nombre de candidats Coût relatif Latence Cas adapté
20–30 Faible Faible Support client à fort volume, interfaces sensibles à la latence
Environ 50 Moyen Moyen Point de départ courant pour une base de connaissances généraliste
100 Assez élevé Assez élevée Documents longs, rappel bruité
Plus de 200 Élevé Élevée Optimiser d'abord le rappel, éviter en premier recours

Partez d'environ 50 candidats, comparez Recall@k et taux de réponses correctes sur un jeu d'évaluation, puis décidez d'augmenter ou de réduire.

Erreur fréquente : réduire top_n ne diminue que le nombre de résultats renvoyés, pas le nombre de documents facturés. L'économie se fait avant le reranking, pas après. Le filtrage par métadonnées, la déduplication approximative, les seuils de similarité et la limitation du périmètre documentaire par ligne métier sont plus efficaces qu'une troncature a posteriori.

4. Longueur des documents et découpage

Beaucoup d'interfaces de reranking imposent une limite de tokens par document ; le surplus est tronqué. Le contenu tronqué ne participe pas au score, ce qui peut couper un passage clé et dégrader le résultat.

En facturation au token, plus un document est long, plus il coûte cher ; en facturation au document, un document long peut être découpé en plusieurs documents facturés. Dans les deux cas, la stratégie de découpage influence à la fois la qualité et la facture.

  • N'envoyez au reranking que les extraits issus du rappel, pas le document entier.
  • Alignez la taille des blocs sur la limite du modèle, sans perdre le titre ni le contexte essentiel.
  • Dédupliquez avant l'indexation pour ne pas facturer plusieurs fois des blocs quasi identiques.
  • Mesurez la distribution des tokens par bloc et budgétez sur le P95, pas sur la moyenne.

5. Équilibrer latence et coût

Le Rerank ajoute de la latence, d'autant plus que les candidats sont nombreux. La bonne approche n'est pas uniforme : elle se fait par couche selon le cas d'usage.

  • Les FAQ à fort volume peuvent éviter le reranking et passer par le cache ou la recherche par mots-clés.
  • Les interfaces sensibles à la latence limitent le nombre de candidats et appliquent d'abord un filtrage par métadonnées.
  • Les tâches hors ligne sensibles à la qualité et à faible concurrence peuvent élargir le jeu de candidats.
  • Fixez un timeout client et un plafond de retries. Un retry après timeout peut facturer deux fois la même requête.
  • Évaluez la latence au P95, pas à la moyenne.

6. Cache et déduplication

Le cache Rerank se place après la recherche et avant la génération. La clé de cache doit contenir au minimum : requête normalisée, identifiant et version du document, nom du modèle, top_n. S'il manque un élément, un résultat erroné peut être réutilisé pour un autre locataire.

  • Questions fréquentes : TTL de l'ordre de l'heure à la journée.
  • Documents mis à jour souvent : TTL en minutes, ou invalidation active à la mise à jour.
  • Droits : la clé de cache doit inclure le locataire et le périmètre de permissions, sans réutilisation entre locataires.
  • Résultats en échec : ne pas les mettre en cache ; le cache négatif à TTL court doit rester prudent.
  • Tâches par lots : les mêmes documents rescored dans la même journée peuvent réutiliser directement le résultat.

Dans le support client ou les questions sur les règles internes, la proportion de questions répétées est élevée ; le gain du cache est souvent plus direct que le passage à un modèle moins cher.

7. Estimer le budget

Convertissez d'abord « chaque requête » en unités de facturation selon le fournisseur visé, puis multipliez par le volume :

Coût mensuel ≈ requêtes/jour × 30 × unités facturées par requête × prix unitaire
               + retries et marge de pic

En facturation au token :

Tokens par requête = tokens de requête × nombre de documents candidats + somme des tokens des documents

Étapes reproductibles :

  1. Relevez dans les logs le volume quotidien moyen et le volume de pic.
  2. Échantillonnez 100 à 200 requêtes réelles et calculez les P50 et P95 du nombre de candidats et des tokens par document.
  3. Convertissez chaque requête en unités de facturation selon le fournisseur.
  4. Multipliez par le volume quotidien et par 30, puis ajoutez 10 à 30 % pour les retries, la croissance et les pics.
  5. Multipliez par le prix unitaire actuel des tarifs des modèles, pas par une ancienne capture d'écran.
  6. Après la mise en production, rapprochez chaque semaine et corrigez l'estimation avec la facture réelle.
# Estimation en facturation au token : renseigner le prix depuis /pricing
QUERY_TOKENS = 60             # médiane issue de l'échantillon
DOCS_PER_QUERY = 50
AVG_DOC_TOKENS = 180
UNIT_PRICE_PER_MILLION = 0.0  # valeur d'exemple, à remplacer

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"Coût par requête : {per_query:.6f}")
print(f"Pour 10 000 requêtes/jour : {per_query * 10_000:.2f}")

Prix unitaires, quotas gratuits et remises par palier peuvent changer ; le prix du script doit être lu sur la page tarifaire actuelle, jamais codé en dur dans le dépôt.

8. Rapprochement de facture et alertes

  • Ventilez la facture par clé, projet et ligne métier ; ne mélangez pas tous les appels sous une seule clé.
  • Enregistrez séparément le nombre de requêtes, de documents candidats, de tokens, le modèle et la latence.
  • Séparez les coûts Embedding, Rerank et génération, sinon vous ne saurez pas quel segment optimiser.
  • Surveillez les retries, requêtes vides, doubles soumissions front-end et tâches de réindexation en arrière-plan, sources fréquentes de pics de facture.
  • Configurez une alerte de budget quotidien et de solde bas, avec notification au responsable.

Les champs d'usage renvoyés par le fournisseur servent au rapprochement ; leurs noms et leur définition exacte figurent dans la documentation de chacun.

Questions fréquentes

Le Rerank est-il plus rentable qu'un modèle de génération plus gros ?

Dans la plupart des cas, oui. Le reranking ne traite que quelques dizaines de candidats, son coût reste maîtrisable et il corrige directement le problème du « bon extrait classé trop loin ». Mais si le rappel n'a pas trouvé le bon passage, le reranking ne peut rien récupérer : corrigez d'abord le rappel.

Réduire top_n permet-il d'économiser ?

En général non. La facturation porte sur les documents ou tokens envoyés en entrée ; top_n ne change que le nombre d'éléments renvoyés au modèle de génération. Pour économiser, réduisez les candidats, dédupliquez et filtrez avant le reranking.

Plus de documents candidats améliorent-ils toujours le résultat ?

Pas nécessairement. Plus de candidats signifie plus de bruit, mais aussi plus de latence et de coût. Comparez Recall@k et taux de réponses correctes sur un jeu d'évaluation pour trouver le point d'inflexion ; le point de départ courant est d'environ 50.

Faut-il découper les documents longs avant l'envoi ?

Oui. La plupart des interfaces tronquent à une limite de tokens, et le surplus n'est pas scoré ; les services facturés au document peuvent en plus découper un document long en plusieurs unités facturées. Conservez le titre et le contexte pour ne pas couper la réponse.

L'auto-hébergement du Rerank est-il toujours moins cher ?

Non. Il supprime le coût à l'appel, mais ajoute GPU, déploiement, montée en charge et exploitation. Avec un trafic stable et une bonne utilisation, il est plus maîtrisable ; avec un trafic faible, irrégulier ou une équipe sans capacité d'exploitation, l'API à l'usage est plus simple.

Étapes suivantes

Commencez par mesurer le nombre de candidats et la longueur des documents sur un lot de requêtes réelles, puis déroulez la chaîne « rappel – reranking – génération » avec un petit budget sur ZSQH AI Gateway. Comparez qualité, latence et coût avec et sans reranking. La disponibilité des modèles et les prix de référence figurent dans les tarifs des modèles.

Lectures associées :