Le Rerank (reranking) occupe le dernier kilomètre de la chaîne de recherche : une recherche vectorielle ou hybride rappelle d'abord quelques dizaines à quelques centaines de candidats, puis un cross-encoder calcule la pertinence de chaque paire requête-document pour placer devant les extraits réellement utiles. Il ne génère pas de texte, mais corrige nettement le cas « la réponse est à la dixième place ».

Il n'existe pas pour autant une seule bonne implémentation. API hébergée, modèle à poids ouverts, capacité intégrée à une base vectorielle : les trois voies fonctionnent, avec des écarts de qualité, de latence, de couverture linguistique, de confidentialité, de coût et d'exploitation. Cet article les décompose selon six dimensions, puis propose un tableau par cas d'usage et une checklist de migration. Modèles et prix de référence : tarifs des modèles.

Remarque : Cohere, Jina, Voyage, Qwen, BGE, Weaviate, Milvus, Elasticsearch et les autres noms cités sont des marques de leurs détenteurs respectifs ; cet article est purement technique. Capacités, quotas et conditions évoluent ; vérifiez la documentation du fournisseur avant intégration.

1. Confirmer d'abord que le goulot est le reranking

Tous les problèmes de qualité RAG ne justifient pas le reranking. Trois signaux : le bon extrait est bien rappelé mais se classe souvent après la cinquième place ; après une recherche hybride, les premiers résultats sont visiblement bruités et la correspondance par mots-clés domine la pertinence sémantique ; la réponse générée cite un mauvais passage, et remplacer manuellement ce passage par le bon suffit à corriger.

Si le bon extrait n'est pas dans l'ensemble rappelé, le reranking ne peut rien ; corrigez d'abord le découpage, l'Embedding ou le nombre de candidats. Si le jeu ne contient que trois à cinq candidats, le gain est également limité. Empiriquement, le reranking est plus rentable avec vingt à deux cents candidats ; au-delà de quelques centaines, latence et coût augmentent vite.

2. Les trois voies

API Rerank hébergée : le fournisseur encapsule modèle et inférence derrière une interface qui reçoit généralement query, documents, top_n et renvoie des index et scores triés. Avantages : intégration rapide, bonne couverture multilingue souvent, aucun GPU. Inconvénients : les données sortent du réseau, dépendance aux quotas et au format d'interface du fournisseur, coût qui croît avec le volume.

Cross-encoder à poids ouverts : le modèle est déployé sur votre GPU ou votre service d'inférence ; les choix courants incluent la série BGE reranker, Qwen3-Reranker, Jina Reranker, etc. Avantages : les données restent dans le réseau interne, possibilité de fine-tuning et de fixer la version. Inconvénients : GPU, montée en charge, mises à jour et maintenance du framework d'inférence à votre charge. Des frameworks comme vLLM et TEI exposent déjà une interface de reranking, ce qui réduit une partie du travail d'adaptation.

Reranking intégré à une base vectorielle : certaines bases proposent une capacité de reranking native ou intégrée, par exemple le module rerank de Weaviate, le rerank retriever d'Elasticsearch, la fonction rerank des versions récentes de Milvus ; d'autres produits se limitent à la recherche et délèguent le reranking à un service externe. Avantages : un saut réseau de moins, périmètre de droits et d'exploitation unifié. Inconvénients : choix de modèle limité par le produit, marge de personnalisation réduite.

Point à ne pas oublier : Rerank n'a pas de standard compatible OpenAI unifié comme Chat Completions. Les familles Jina, Cohere et Voyage n'ont pas les mêmes champs : top_n contre top_k, retour ou non du texte du document, paramètres de troncature par document, point d'entrée /v1/rerank ou /v2/rerank. Lors d'un changement de fournisseur, l'adaptation du protocole prend souvent plus de temps que le modèle lui-même.

3. Comparer selon six dimensions

Qualité : API hébergée et modèle open source sont souvent tous deux des cross-encoders ; les écarts viennent surtout des données d'entraînement, de la distribution linguistique et de la version. Ne vous fiez pas aux classements publics : évaluez sur vos requêtes métier et votre jeu de candidats. Si la capacité intégrée appelle la même famille de modèles, le résultat est souvent proche, avec moins de paramètres réglables.

Latence : elle croît approximativement avec « nombre de candidats × longueur des documents ». L'API hébergée ajoute un aller-retour sur l'Internet public, adapté aux petits jeux de candidats et à une concurrence stable ; l'auto-hébergement supprime une dépendance externe mais subit la file d'attente GPU ; la solution intégrée évite le saut réseau mais peut partager les ressources avec la recherche.

Couverture linguistique : examinez séparément le chinois, le mixte chinois-anglais et les langues rares. Beaucoup de modèles sont proches sur les classements anglais, mais l'écart s'élargit sur les documents longs en chinois et le vocabulaire métier. Préparez trois jeux d'évaluation : chinois, anglais, mixte.

Confidentialité : dès que les documents quittent votre réseau, évaluez clauses de données, chiffrement en transit, conservation des logs et chemin transfrontalier. Contrats, données clients, textes médicaux et financiers privilégient généralement l'auto-hébergement ou le déploiement privé.

Coût : l'hébergé facture à l'appel ou au token, de façon presque linéaire avec le volume ; l'auto-hébergement combine coût fixe GPU et main-d'œuvre, pas forcément moins cher à faible volume ; la solution intégrée peut être incluse dans l'offre de base de données ou facturée selon l'inférence. Intégrez retries, évaluation hors ligne et montée en charge des pics.

Exploitation : l'hébergé confie mises à jour et montée en charge au fournisseur, mais vous gérez clés, quotas et différences entre fournisseurs ; l'auto-hébergement exige une astreinte GPU et la gestion des pilotes et frameworks ; la solution intégrée fusionne deux systèmes, avec un domaine de panne plus concentré.

4. Choisir selon le cas d'usage

Cas Voie suggérée Raison Point d'attention
Validation rapide, quelques dizaines de candidats API Rerank hébergée Intégration le jour même, sans GPU Vérifier d'abord si les données peuvent sortir
Chinois principal, données sensibles Auto-hébergement open source Déploiement privé, modèle performant en chinois Prévoir GPU et main-d'œuvre
Base vectorielle déjà en place, besoin simple Reranking intégré Une intégration de moins, droits unifiés Vérifier modèles et paramètres disponibles
Forte concurrence, latence critique Auto-hébergement ou intégré même région Éviter aller-retour public et file d'attente Tester en charge, pas seulement la moyenne
Multilingue, langues rares API hébergée ou modèle open source multilingue fort Couverture linguistique plus simple Valider sur un jeu en langue rare
Très faible volume, équipe sans GPU API hébergée Coût fixe plus bas Configurer budget et alertes de quota

Ce tableau n'est qu'un point de départ. Une même équipe peut combiner : API hébergée en production pour la continuité, auto-hébergement open source pour l'évaluation hors ligne, reranking intégré réservé aux activités à faible risque.

5. Évaluer la qualité sans se fier à l'impression

Préparez au moins trois éléments : un lot de vraies requêtes, l'annotation du bon document pour chaque requête, et l'ensemble de rappel actuel. Regardez Recall@k, MRR ou nDCG, pas seulement « cela semble plus pertinent ». Exportez le même jeu de candidats avant et après reranking, faites relire les dix premiers par un humain et notez le type d'erreur : rappel manquant, découpage cassé, ou bon passage repoussé par le reranking.

Le code Python ci-dessous ne fait qu'une chose : vérifier si le bon document entre dans le top k avant et après reranking. Il ne dépend d'aucun fournisseur ; l'entrée est deux listes d'index triés.

def hit_rate(cases, k):
    hits = 0
    for gold, ranked in cases:
        if gold in ranked[:k]:
            hits += 1
    return hits / len(cases)

# cases: [(index du bon document, liste d'index après reranking), ...]
before = hit_rate(baseline_cases, 5)
after = hit_rate(reranked_cases, 5)
print(f"Recall@5 : {before:.3f} -> {after:.3f}")

Prévoyez au moins une centaine d'échantillons, couvrant différentes lignes métier et longueurs de documents. Avant mise en production, regardez aussi la latence p95 et le coût par appel ; ne masquez pas la longue traîne par la moyenne.

6. Checklist de migration

Pour passer d'une API Rerank à une autre, ou de l'hébergé à l'auto-hébergé :

  1. Figer le jeu d'évaluation et la référence actuelle : Recall@k, MRR, latence p95 et coût par appel.
  2. Vérifier le chemin, l'authentification et les champs de requête de la nouvelle solution, notamment top_n contre top_k, le retour du texte et les paramètres de troncature.
  3. Aligner la sémantique des scores : score de pertinence entre 0 et 1 ou logits non normalisés, tri croissant ou décroissant ; ne mélangez pas les seuils.
  4. Vérifier les limites de documents par appel, tokens par document, taille du corps et concurrence ; découpez côté client plutôt que d'attendre l'erreur.
  5. Écrire les retries et la dégradation pour timeout, 429 et 5xx ; en dégradation, conservez l'ordre du rappel initial pour éviter l'échec de toute la chaîne.
  6. Comparer anciens et nouveaux résultats en trafic miroir pendant au moins une semaine, en notant écarts de classement et qualité des réponses.
  7. Basculer progressivement avec un seuil de retour arrière, par exemple si le taux d'erreur ou le p95 dépasse la référence d'une certaine proportion.
  8. Mettre à jour supervision et facturation, en vérifiant que retries, cache et évaluation hors ligne sont bien comptés.

Questions fréquentes

Quelle différence entre Rerank API et Embedding API ?

Embedding transforme le texte en vecteurs pour le rappel à grande échelle ; Rerank lit la requête et chaque document, avec une précision supérieure mais plus lentement. La pratique courante consiste à rappeler quelques dizaines à quelques centaines de candidats, puis à affiner le classement des premiers.

Un modèle de reranking open source est-il toujours moins cher qu'une API hébergée ?

Non. À faible volume, le coût fixe GPU et la main-d'œuvre dépassent souvent le paiement à l'usage ; à fort volume, avec des données sensibles ou un besoin de personnalisation, l'auto-hébergement amortit mieux. Intégrez la montée en charge des pics dans le calcul.

Le reranking intégré à une base vectorielle suffit-il ?

Cela dépend du cas. Si le jeu de candidats est petit et qu'aucune exigence particulière ne porte sur le modèle, la capacité intégrée évite une intégration ; si vous avez besoin d'une langue, d'un fine-tuning métier ou d'un contrôle fin des paramètres, un service de reranking dédié est plus souple.

Comment choisir un modèle de reranking pour le chinois ?

Vérifiez d'abord que le modèle prend explicitement en charge le chinois ou le multilingue, puis évaluez sur vos requêtes et documents chinois. Ne remplacez pas l'évaluation par un classement anglais. Échantillonnez séparément le mixte chinois-anglais, les documents longs et le vocabulaire métier.

Faut-il recalibrer les seuils de score après un changement de service ?

En général oui. Les distributions diffèrent : certains modèles normalisent entre 0 et 1, d'autres renvoient des logits. Les scénarios qui filtrent sur un seuil fixe doivent être recalibrés, ou passer à un critère de position dans le classement plutôt que de score absolu.

Étapes suivantes

Pour simplement valider la chaîne, créez une clé de test sur ZSQH AI Gateway, comparez la qualité du rappel avant et après reranking sur le même lot de requêtes, puis estimez le coût d'appel avec les tarifs des modèles. Disponibilité des modèles et unités de facturation : page tarifaire.

Lectures associées :