L'API Rerank n'est pas sur le chemin de génération, mais elle détermine directement si les premiers résultats de recherche sont corrects. Elle envoie « une requête + un lot de documents candidats » au modèle de reranking et renvoie un ordre trié par pertinence. Comme l'appel se produit pendant l'attente de l'utilisateur, le vrai problème pour une équipe en Chine n'est pas « l'appel passe-t-il », mais la stabilité du réseau, la possibilité de rembourser la facture, la maîtrise de la latence et l'existence d'une dégradation en cas d'incident.
Cet article compare trois voies — direct, relais et passerelle unifiée — et fournit une checklist de vérification avant mise en production. Modèles, chemins d'interface et prix exacts : documentation de chaque fournisseur et tarifs des modèles.
Remarque : Cohere, Jina AI et les autres noms cités sont des marques de leurs détenteurs respectifs. Cet article n'implique aucune affiliation avec les fournisseurs concernés. Aucun prix unitaire n'est figé ; avant achat, référez-vous à l'offre et au contrat en vigueur.
1. Pourquoi Rerank API est un problème d'accès à part
Trois différences avec une API de chat. Premièrement, c'est une requête synchrone courte : un appel peut durer de quelques dizaines à quelques centaines de millisecondes, mais l'utilisateur attend ce résultat. Deuxièmement, elle ne fait pas partie du standard OpenAI Chat Completions ; champs et chemins sont définis par chaque fournisseur, par exemple /v2/rerank chez Cohere et /v1/rerank chez Jina ; une migration ne se limite donc pas à changer l'URL de base. Troisièmement, l'unité de facturation peut être la requête, le document, le token ou la search unit, une structure plus complexe que « tokens d'entrée/sortie ».
Une solution d'accès depuis la Chine doit donc satisfaire quatre conditions : connectivité réseau durable, paiement et facturation compatibles avec les process entreprise, latence dans le budget de recherche, et plan de limitation et de bascule. Vérifier seulement que « l'appel renvoie un résultat » est très insuffisant.
2. Direct, relais ou passerelle unifiée
Les chemins courants se classent en quatre catégories. Le direct chez un fournisseur étranger convient aux équipes disposant d'un réseau international et d'un moyen de paiement en devise ; le direct chez un fournisseur local simplifie réseau et facture, mais impose d'adapter modèles et protocoles ; le relais commercial package réseau et paiement ; la passerelle unifiée met en avant le regroupement multi-fournisseurs, la gestion des clés et une facture unique.
| Chemin | Réseau | Paiement et facture | Maîtrise de la latence | Limitation et bascule | Public visé |
|---|---|---|---|---|---|
| Direct fournisseur étranger | Dépend de la liaison internationale, variable aux heures de pointe | Carte en devise souvent requise, délai de facturation | Région choisissable, mais RTT transfrontalier élevé | 429 et retries à gérer soi-même | Entité étrangère avec capacité d'exploitation |
| Direct fournisseur local | Accès local généralement stable | Règlement en yuan, facture simple | Région choisissable, liaison courte | Contraint par les quotas du fournisseur | Service principalement local |
| Relais commercial | Lignes optimisées par le prestataire | Recharge en yuan, facture à vérifier | Dépend du routage du relais | Le prestataire assure la continuité, périmètre à clarifier | Petite équipe voulant démarrer vite |
| Passerelle unifiée | Multi-lignes côté passerelle | Facture consolidée, achat simplifié | Dépend de la région de déploiement | Multi-amont et dégradation configurables | Multi-modèles, multi-projets |
Ne comparez pas seulement le prix unitaire. Inscrivez dans la grille d'évaluation « qui diagnostique en cas d'incident », « quelle entité émet la facture », « peut-on obtenir la durée et le détail de facturation de chaque appel » ; c'est souvent plus important que quelques points de pourcentage économisés. Pour tester un accès unifié, consultez la liste des interfaces et modèles via l'inscription avant de décider de l'intégrer en production.
3. Réseau et latence : commencer par le budget de recherche
Le reranking se situe généralement « après le rappel, avant la génération ». Un budget utilisable est approximativement : rappel 20 à 80 ms, reranking avec P95 sous 300 ms, génération 1 à 3 secondes. Pour une recherche à affichage instantané, le reranking doit parfois passer en asynchrone ou ne servir que pour la seconde page de résultats.
La latence dépend principalement de trois variables : nombre de documents candidats, longueur de chaque document, total de tokens requête + documents. La documentation de Jina donne comme référence environ 150 ms pour 100 documents d'environ 256 tokens avec une requête de 64 tokens ; un document unique de 4096 tokens peut monter à plusieurs secondes. Cohere recommande de ne pas dépasser 1000 documents par requête, avec une troncature par défaut à 4096 tokens par document. Ces chiffres varient avec le modèle et la charge, mais la règle est constante : réduire d'abord les candidats, tronquer ensuite, et seulement en dernier envisager un modèle plus rapide.
Quatre priorités d'ingénierie : réduire top_n aux seuls résultats réellement utilisés ; découper ou tronquer les documents longs ; appeler au plus près de la région métier ; réutiliser les connexions pour éviter une poignée de main à chaque requête. Mesurez P95 et P99, pas seulement la moyenne.
4. Paiement, factures et contrat
Le direct étranger pose souvent la question du moyen de paiement et du remboursement. Carte en devise, taux de change, facture d'une entité étrangère, règles de remboursement du solde prépayé influencent le processus financier. Les fournisseurs locaux et la plupart des passerelles permettent un règlement en yuan, mais il faut confirmer le type de facture, la date d'émission, la facturation de la recharge et le retour du remboursement par le canal d'origine.
Avant contrat ou commande, faites confirmer par écrit cinq points : l'unité de facturation, la facturation des requêtes échouées, l'existence d'un minimum de consommation, la notification des hausses de prix, la conservation des données et la politique de logs. Pour le reranking, la requête transporte des extraits de documents métier, potentiellement des données clients ou internes ; les clauses de traitement ne peuvent pas être présumées « identiques à celles de l'interface de chat ».
5. Limitation, timeouts et bascule
La limitation Rerank se calcule généralement en RPM et TPM. Comme le coût croît avec « nombre de documents × longueur », un lot volumineux déclenche facilement le quota aux heures de pointe. Le client doit fixer un timeout explicite, par exemple 800 ms à 1,5 s ; après échec, un seul retry au maximum, avec jitter, pour éviter une tempête.
Le plus important est le chemin de dégradation. En cas d'échec du reranking, le système doit pouvoir revenir à l'ordre initial du rappel ou basculer vers un autre fournisseur, sans faire échouer toute la recherche. Voici un exemple d'appel avec timeout ; adaptez les noms de champs à la documentation du fournisseur :
curl -sS --max-time 1.5 https://<your-endpoint>/v1/rerank \
-H "Authorization: Bearer $RERANK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "<selon la documentation du fournisseur>",
"query": "Quels documents faut-il pour créer une société en Russie",
"documents": ["Extrait un", "Extrait deux", "Extrait trois"],
"top_n": 5,
"return_documents": false
}'
Attention : chemins et champs ne sont pas unifiés selon les fournisseurs ; return_documents, la plage de scores et la prise en charge des documents structurés doivent être vérifiés un par un. Ne supposez pas qu'il suffit de remplacer l'URL de base d'une interface de chat pour appeler le reranking.
6. Checklist de vérification avant mise en production
- Vérifier le protocole : chemin, champs obligatoires, plage de scores et nombre maximal de documents.
- Comparer hors ligne avec de vraies requêtes et 50 à 100 candidats, en notant l'évolution de la qualité du classement.
- Tester la charge dans la région cible et relever P50, P95, P99 et taux d'erreur.
- Provoquer un 429 pour vérifier que la stratégie de backoff fonctionne.
- Simuler timeout et 5xx pour confirmer le retour à l'ordre initial ou au fournisseur de secours.
- Rapprocher avec une charge fixe : comparer logs d'appel et facture réelle.
- Confirmer l'entité contractuelle, le type de facture, les règles de remboursement et les clauses de données.
- Déployer en progressif sur faible trafic, en observant le taux de clic de recherche et la latence.
L'objectif de cette checklist n'est pas de « tester une fois », mais de conserver des enregistrements reproductibles. Qualité et latence du reranking dépendent fortement du corpus métier ; les benchmarks d'autres équipes ne sont qu'indicatifs.
7. Questions fréquentes
Quelle différence entre Rerank API et Embedding API ?
Embedding transforme le texte en vecteurs pour le rappel grossier ; Rerank score directement les paires « requête—document » pour le classement fin. Les deux s'enchaînent généralement et ne se remplacent pas.
Un modèle Rerank local peut-il remplacer directement un modèle étranger ?
Interface et distribution des scores peuvent différer. Après remplacement, recalibrez les seuils et comparez le classement sur le même lot de requêtes ; ne vous contentez pas de vérifier que l'interface renvoie 200.
Faut-il une ligne dédiée pour appeler directement une API étrangère ?
Pas nécessairement. Mesurez d'abord la perte de paquets, le P95 et le taux de timeout aux heures visées. Si l'activité est sensible à la latence, évaluez ensuite ligne dédiée, passerelle régionale ou relais, sans commencer par la solution la plus lourde.
Combien de temps le reranking ralentit-il la recherche ?
Cela dépend du nombre de candidats et de la longueur des documents. En limitant les candidats à quelques dizaines et en tronquant chaque document, on maintient généralement le surcoût dans quelques centaines de millisecondes ; documents longs et gros lots ralentissent nettement plus.
Une passerelle unifiée prend-elle forcément en charge Rerank ?
Non. Rerank ne fait pas partie du standard OpenAI de chat ; vérifiez la liste d'interfaces de la passerelle. Confirmez d'abord la compatibilité de protocole, puis discutez prix et quotas ; la liste des capacités actuelles est visible après inscription.
