Reclassement
Pourquoi c’est important
En profondeur
La raison d'être du reclassement, c'est que la récupération rapide et la récupération juste sont des problèmes différents. La première étape d'une chaîne de RAG ou de recherche sémantique doit passer au crible des millions de fragments en quelques millisecondes, donc elle s'appuie sur des méthodes approximatives : un modèle d'embedding bi-encodeur convertit la requête et chaque document en vecteurs indépendamment, ou BM25 note le chevauchement de mots-clés sans aucune compréhension du sens. Ces méthodes placent habituellement le bon document quelque part dans les 50 premiers, mais l'ordre à l'intérieur de ces 50 est bruité. Un reclasseur prend cet ensemble de candidats et applique un modèle qui serait bien trop lent à exécuter sur tout le corpus — typiquement un encodeur croisé qui lit la requête et un document ensemble — puis retrie la liste pour que les fragments véritablement pertinents remontent en tête. Les k meilleurs finaux, souvent seulement de 3 à 10 fragments, sont ce qui est assemblé dans le prompt.
Bi-encodeurs contre encodeurs croisés
L'écart de performance entre les deux étapes vient de l'architecture. Un bi-encodeur produit un vecteur par texte : la requête est encodée une fois, chaque document est encodé une fois (habituellement hors ligne, à l'avance), et la pertinence n'est que la similarité cosinus entre deux points. C'est extrêmement rapide avec des index de plus proches voisins approximatifs, mais le modèle ne voit jamais la requête et le document ensemble, donc il ne peut pas modéliser la façon dont des mots précis de l'un interagissent avec des mots précis de l'autre. Un encodeur croisé fait l'inverse : la requête et un seul document candidat sont concaténés et passés dans un Transformer comme une seule entrée, et le modèle produit directement un score de pertinence. Comme chaque token peut porter attention à chaque token à travers les deux textes, il capte des nuances — négation, contraintes exactes, formulations à plusieurs sauts — que la similarité d'embeddings rate régulièrement.
Le hic, c'est le coût. Noter 50 candidats veut dire 50 passes avant distinctes, et les paires ne peuvent pas être précalculées parce que la requête n'est connue qu'au moment de la demande. C'est pourquoi les encodeurs croisés ne sont jamais exécutés sur un corpus complet de millions de documents, et pourquoi la séparation en deux étapes existe en premier lieu : le travail du bi-encodeur est le rappel (faire entrer les bons documents dans l'ensemble de candidats), et celui de l'encodeur croisé est la précision (les mettre dans le bon ordre).
Les reclasseurs en pratique
Il y a deux façons courantes d'ajouter un reclasseur. Les API hébergées comme Rerank de Cohere et le point d'accès de reclassement de Voyage AI prennent une requête plus une liste de documents dans une seule demande et retournent des scores — aucune infrastructure à exploiter, mais un appel réseau de plus et une tarification par demande. Les modèles en poids ouverts, menés par la famille bge-reranker de BAAI et les reclasseurs de Jina AI, sont offerts sur Hugging Face et peuvent tourner sur un seul GPU ou même un processeur pour de petits ensembles de candidats, ce qui garde les données à l'interne et les coûts prévisibles.
Le motif d'intégration est le même dans les deux cas : récupérer un ensemble de candidats généreux (les 20 à 100 meilleurs, souvent par recherche hybride sur une base de données vectorielle plus BM25), le reclasser, garder les 3 à 10 meilleurs, et jeter le reste. Certaines équipes sautent complètement le modèle dédié et demandent à un grand modèle de langage de classer les candidats sans exemple préalable; ça fonctionne, et les reclasseurs par liste à modèle de langage peuvent être solides, mais un encodeur croisé conçu pour la tâche revient habituellement de un à deux ordres de grandeur moins cher par requête.
Il ne peut pas réparer une mauvaise récupération
Une idée fausse répandue veut qu'ajouter un reclasseur sauve une chaîne de recherche faible. C'est impossible, parce que le reclassement ne fait que réordonner ce que la première étape a déjà retourné : si le fragment pertinent n'est jamais entré dans l'ensemble de candidats, le reclasseur ne le voit jamais, et aucune quantité de notation juste ne le ramènera. La première étape impose un plafond de rappel strict à tout ce qui suit. Ça a une conséquence pratique pour le débogage : quand la qualité de récupération de bout en bout est mauvaise, mesurez les étapes séparément. Vérifiez si le bon fragment apparaît quelque part dans les 50 premiers (un problème de récupération — corrigez les embeddings, le découpage, ou ajoutez de la recherche hybride) plutôt que s'il apparaît mais se classe trop bas (un problème de reclassement). Les équipes qui sautent cette distinction passent souvent des semaines à ajuster un reclasseur pour des gains qui étaient plafonnés par la première étape depuis le début.
Le budget de latence
Le reclassement est un échange : un meilleur ordre contre de la latence et du coût en plus. Un encodeur croisé auto-hébergé qui note 50 paires requête-document ajoute typiquement de l'ordre de quelques dizaines à quelques centaines de millisecondes selon la taille du modèle et la longueur des documents; une API hébergée ajoute un aller-retour réseau par-dessus. Les boutons de réglage sont simples : reclasser moins de candidats (les 20 meilleurs au lieu des 100), tronquer les documents avant la notation, utiliser un modèle plus petit, ou mettre les scores en cache pour les requêtes répétées.
Que l'échange en vaille la peine dépend de l'application. Pour un assistant destiné aux utilisateurs où les réponses prennent déjà des secondes à générer, un supplément de 100 à 300 ms est habituellement invisible, et le gain de pertinence réduit directement l'hallucination causée par du contexte hors sujet. Pour de la recherche de type autocomplétion ou des services internes à très haut débit de requêtes, les équipes réservent souvent le reclassement aux requêtes qui semblent difficiles — longues, ambiguës, ou à faible confiance dès la première étape — et laissent passer directement les requêtes faciles. La valeur par défaut pragmatique dans les systèmes de récupération en production, c'est : reclassez toujours, sauf si vous pouvez prouver que vous ne pouvez pas vous le permettre.