Le rerank est le second étage de tri d'une chaîne de recherche : on commence par rappeler un lot de candidats par recherche vectorielle ou par mots-clés, puis un modèle de reclassement note chaque document pour placer les plus pertinents dans le contexte du grand modèle. Il résout le problème « beaucoup de résultats rappelés, mais un mauvais ordre en tête », pas celui « aucun résultat rappelé ».

Cet article couvre le point d'accès et l'authentification, la requête et la réponse, top_n et la taille du jeu de candidats, l'intégration à la recherche vectorielle, la latence et le repli, les erreurs courantes et les indicateurs d'évaluation. Les modèles et les prix relèvent de la page Tarifs des modèles.

Note : Cohere, Jina AI, BAAI et Alibaba Cloud sont des marques de leurs titulaires ; cet article est purement technique. ZSQH AI Gateway n'a aucune affiliation avec les fournisseurs cités ; les interfaces, modèles et règles de facturation relèvent des informations du site.

1. Place du reclassement dans la chaîne de recherche

Une recherche RAG typique comporte trois étapes : rappel, reclassement, génération. Le rappel vise la rapidité et la couverture, le reclassement vise la précision, la génération n'utilise que le contexte filtré.

Étape Méthode courante Entrée Sortie Indicateur principal
Rappel recherche vectorielle, BM25, recherche hybride requête utilisateur 30 à 100 candidats Recall@k
Reclassement modèle Rerank requête + candidats 5 à 10 documents nDCG@10
Génération grand modèle de langage contexte reclassé réponse exactitude, fidélité

Le modèle de reclassement est généralement un encodeur croisé : il lit ensemble la requête et chaque document et produit un score de pertinence, plus précis qu'une similarité vectorielle mais plus lent. Il se place après le rappel, il ne le remplace pas.

2. Point d'accès, authentification et paramètres

Le point d'accès de reclassement de ZSQH AI Gateway est :

POST https://ai.zhongshangqihang.com/v1/rerank

L'authentification utilise Authorization: Bearer <key> et le corps est en JSON. La passerelle accepte aussi le chemin /rerank. La création et la sécurisation des clés sont décrites dans un autre tutoriel.

Paramètre Obligatoire Description
model oui nom du modèle de reclassement, selon la liste du site
query oui requête utilisateur, non vide
documents oui tableau de documents candidats, généralement des chaînes ; la structure objet varie selon l'amont
top_n non nombre de résultats renvoyés ; à définir explicitement plutôt qu'à laisser la valeur par défaut
return_documents non renvoyer ou non le contenu du document dans le résultat
max_chunk_per_doc non limite de découpage d'un document long, selon le support de l'amont
overlap_tokens non chevauchement en tokens entre segments, à confirmer dans la documentation amont

La plupart des implémentations acceptent un tableau de chaînes ; certaines plateformes acceptent des objets avec un champ text. Validez le format avec une requête minimale avant de migrer un lot entier.

3. Requête et réponse : Python et curl

Exemple Python, rappel puis reclassement :

import os
import requests

api_key = os.environ["RERANK_API_KEY"]
base_url = "https://ai.zhongshangqihang.com/v1"

documents = [
    "La période d'essai est de 14 jours, prolongeable sur demande avant expiration.",
    "Le virement d'entreprise et le paiement sécurisé par la plateforme sont acceptés.",
    "La facture est émise dans les 3 jours ouvrés suivant le paiement.",
]

resp = requests.post(
    f"{base_url}/rerank",
    headers={"Authorization": f"Bearer {api_key}"},
    json={
        "model": "votre-modele-de-reranking",
        "query": "Quelle est la durée de la période d'essai ?",
        "documents": documents,
        "top_n": 2,
        "return_documents": False,
    },
    timeout=20,
)
resp.raise_for_status()

for item in resp.json()["results"]:
    print(item["index"], item["relevance_score"], documents[item["index"]])

La même requête en curl :

curl "https://ai.zhongshangqihang.com/v1/rerank" \
  -H "Authorization: Bearer $RERANK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "votre-modele-de-reranking",
    "query": "Quelle est la durée de la période d’essai ?",
    "documents": ["La période d’essai est de 14 jours.", "Le virement d’entreprise est accepté."],
    "top_n": 2
  }'

Le champ results de la réponse est déjà trié par pertinence décroissante ; chaque élément contient :

  • index : position du document dans le tableau documents d'origine, pas son rang. Utilisez-la pour retrouver le texte source.
  • relevance_score : score de pertinence, généralement normalisé entre 0 et 1, mais ce n'est pas une probabilité et l'écart n'est pas linéaire.
  • document : renvoyé seulement si return_documents vaut true, avec une structure variable selon l'amont.
  • usage : consommation de tokens, utile pour le rapprochement de facture et l'analyse de coût.

Ne réutilisez pas relevance_score comme seuil tel quel. Après un changement de modèle, de langue ou de type de document, la distribution des scores change et le seuil doit être recalibré.

4. top_n et taille du jeu de candidats

top_n est le nombre de résultats renvoyés ; la taille du jeu de candidats est le nombre de documents envoyés au modèle. Les deux ne se confondent pas. L'erreur fréquente consiste à fixer un top_n élevé tout en ne rappelant qu'une dizaine de documents : le reclassement n'a alors aucune marge.

Taille des candidats Cas adapté Latence relative Attention
20–30 petite base, questions à faible latence faible plafond de rappel bas, réponses faciles à manquer
50 point de départ de la plupart des RAG moyenne évaluer avant d'augmenter ou de réduire
100 nombreux documents, requêtes variées assez élevée surveiller la longueur et la troncature
200 et plus requêtes à forte valeur, évaluation hors ligne élevée coût et latence à évaluer séparément

Recommandation pratique : commencer avec 30 à 50 candidats et un top_n de 5 à 10. Un jeu trop petit limite le plafond ; un jeu trop grand augmente latence et coût et peut introduire du bruit dans le contexte. L'amont peut imposer une limite sur le nombre de documents et leur longueur ; les documents trop longs sont tronqués, parfois juste avant la phrase clé.

Autre point : certains amonts ne renvoient qu'un seul résultat si top_n est omis. En production, transmettez toujours top_n explicitement, sans dépendre du comportement par défaut.

5. Intégration à la recherche vectorielle

Le reclassement n'est pas une étape isolée ; l'ordre d'intégration influe sur l'efficacité et le coût. Flux recommandé :

  1. Reformuler si nécessaire la requête utilisateur, en complétant les références et les ellipses.
  2. Convertir la requête en vecteur avec un modèle d'embedding.
  3. Rappeler les 30 à 50 premiers documents par recherche vectorielle, éventuellement en parallèle d'une recherche par mots-clés ou BM25.
  4. Fusionner les deux listes et dédupliquer par identifiant de document.
  5. Appliquer les filtres de droits et de métadonnées avant le reclassement, pour ne pas envoyer au modèle des documents inaccessibles.
  6. Appeler l'API Rerank avec un top_n de 5 à 10.
  7. Appliquer un seuil de score ou un plafond de documents, puis construire le contexte du modèle de génération.

Quelques points souvent négligés :

  • Filtrer avant de reclasser : droits, locataire, langue et version doivent être filtrés au rappel ou avant le reclassement, pas supprimés après la génération.
  • Conserver des identifiants stables : le reclassement renvoie des positions ; la couche métier doit les mapper vers l'identifiant, le titre et l'URL du document.
  • Reclasser par segment : un RAG reclasse généralement des segments, pas des documents entiers. Un segment trop long dilue la pertinence, un segment trop court perd le contexte.
  • Rappel hybride : les noms propres, références et numéros sont mieux traités par mots-clés, les questions sémantiques par vecteurs ; fusionner les deux avant le reclassement est souvent meilleur qu'une seule voie.

6. Latence, délais et repli

La latence du reclassement croît à peu près avec « nombre de documents × longueur des documents ». Cent documents courts sont généralement rapides ; plusieurs centaines de documents longs ralentissent nettement. Avant la mise en production, mesurez au moins trois points : P50 et P95 avec 30, 50 et 100 candidats.

Recommandations d'ingénierie :

  • définir un délai propre aux requêtes Rerank, souvent 10 à 30 secondes au départ, puis le resserrer selon les mesures ;
  • ne réessayer avec backoff qu'un nombre limité de fois sur 429 et 5xx ; ne pas réessayer 401, 403 et 422 ;
  • en cas d'expiration ou d'échec du reclassement, revenir à l'ordre du rappel vectoriel plutôt que de faire échouer toute la question-réponse ;
  • mettre en cache les requêtes fréquentes et peu changeantes, avec une clé incluant au moins la requête, les identifiants de documents et le nom du modèle ;
  • exécuter en parallèle rappel vectoriel et rappel par mots-clés, puis fusionner avant le reclassement, pour réduire l'attente séquentielle ;
  • l'interface de reclassement renvoie l'ensemble du résultat en une fois, sans streaming : ne concevez pas le front comme une interface à flux.

Si la latence reste élevée, réduisez d'abord le jeu de candidats et la longueur des documents, puis envisagez un modèle plus petit. Passer directement à un modèle plus gros n'est pas forcément rentable, surtout si la qualité du rappel est déjà faible.

7. Erreurs courantes et diagnostic

Code ou symptôme Cause courante Traitement
400 / 422 query vide, documents vide, structure JSON incorrecte vérifier les champs obligatoires et le type des tableaux
401 clé invalide, expirée ou en-tête absent vérifier Authorization et l'état de la clé
403 clé sans droit sur le modèle ou compte restreint vérifier le périmètre du modèle et l'état du compte
404 nom de modèle ou chemin de point d'accès incorrect vérifier /v1/rerank et la liste des modèles
429 limitation de concurrence ou de quota backoff, vérifier quota et limite de débit
500 / 502 / 504 anomalie ou expiration en amont tentatives limitées, puis chemin de repli

La passerelle vérifie query et documents et renvoie une erreur de paramètre s'ils sont vides. En diagnostic, lisez d'abord le champ message de la réponse, puis comparez avec le journal de requête ; ne traitez pas un 400 comme un problème réseau en réessayant.

8. Évaluation : ne pas se fier à une impression

Avant la mise en production, préparez un petit jeu annoté : 100 à 300 requêtes réelles, chacune associée à 1 à 3 documents pertinents. Sans annotation, contrôle manuellement au moins 50 requêtes et consignez les deux classements.

Indicateur Ce qu'il mesure Usage
Recall@50 la bonne réponse figure-t-elle parmi les candidats juger le plafond du rappel ; si faible, corriger d'abord le rappel
nDCG@10 qualité du classement en tête comparer avec et sans reclassement
MRR position du premier résultat pertinent adapté aux requêtes de type question-réponse
Taux de réponses correctes exactitude du résultat généré validation de bout en bout
Latence P95 lenteur des requêtes lentes dimensionner candidats et délai
Coût par requête dépense de recherche par question estimer avec la page tarifaire

Gardez les variables fixes : même lot de requêtes, même résultat de rappel, même top_n, en ne changeant que l'activation du reclassement ou le modèle. En ligne, lancez un A/B à faible trafic en observant exactitude, taux de non-réponse et latence. Si le reclassement dégrade le résultat, vérifiez d'abord si les candidats contiennent la bonne réponse, si les documents sont tronqués, si le modèle convient au français et si le seuil a été copié d'un autre scénario.

9. Questions fréquentes

Le reclassement peut-il remplacer la recherche vectorielle ?

Non. Le reclassement ne peut que réordonner des candidats déjà présents ; il ne retrouve pas un document non rappelé. Le rappel couvre l'étendue, le reclassement améliore la précision en tête.

Combien faut-il fixer de top_n ?

Pour construire le contexte d'un grand modèle, 5 à 10 est un point de départ courant ; si des règles métier filtrent ensuite, 20 à 50 peuvent convenir. L'évaluation tranche.

Un jeu de candidats plus grand est-il toujours meilleur ?

Non. Un jeu plus grand relève le plafond de rappel, mais augmente aussi latence, coût et bruit. Commencez avec 30 à 50 documents et utilisez Recall@50 et nDCG@10 pour décider d'élargir.

Pourquoi le résultat se dégrade-t-il après ajout du reclassement ?

Quatre causes fréquentes : les candidats ne contiennent pas le bon document, les segments sont trop longs ou trop fragmentés, le modèle ne correspond pas à la langue, ou le seuil a été repris d'un autre scénario. Vérifiez point par point, sans vous contenter de changer de modèle.

L'interface Rerank accepte-t-elle le streaming ?

Non. Le reclassement doit lire tout le jeu de candidats pour produire un ordre complet, et renvoie généralement le résultat en une fois. Le front doit le traiter comme une requête JSON classique, avec un délai adapté.

Lectures associées