Un moteur de recherche moderne ne classe pas les pages une fois. Il les classe deux fois. Le premier classement ramène quelques centaines de candidats vite et mal ; le second en reclasse quelques dizaines lentement et bien. Ce second passage s’appelle le reranking, ou second classement, et c’est lui qui décide de la page citée dans la réponse.
Pourquoi deux étages ? Parce que le premier est structurellement incapable de faire le travail. Les mesures de cet article le montrent de la façon la plus brutale possible : sur des vecteurs moyennés, « l’image compressée réduit le temps de chargement » et « le temps de chargement réduit l’image compressée » obtiennent exactement le même score, à la douzième décimale. Écart : 0,00. Pire, une phrase qui affirme l’inverse de la réponse peut scorer plus haut que la réponse elle-même.
Ce qui est documenté et ce qui ne l’est pas, dit tout de suite plutôt qu’en fin d’article. Le mécanisme du second classement, ses coûts et ses limites sont documentés en détail — mais par les fournisseurs d’infrastructure : Elastic, Cohere, Google Cloud, OpenAI côté API. L’existence d’un étage de reranking dans AI Overviews, AI Mode ou ChatGPT grand public n’est écrite nulle part : elle est déduite. Et le nombre de candidats que ces produits reclassent n’est connu de personne hors de chez eux. Un tableau à six statuts, en fin d’article, trie chaque affirmation.
Le protocole, le script complet et les jeux de phrases sont publiés. Cet article suppose acquis le fonctionnement des embeddings, du query fan-out et de la fusion RRF.
Le reranking en une phrase
Le reranking prend une liste de candidats déjà classée et la reclasse, avec un modèle plus lent et plus précis que celui qui l’a produite.
La documentation d’Elastic en donne la définition la plus nette : « Re-rankers improve the relevance of results from earlier-stage retrieval mechanisms. Semantic re-rankers use machine learning models to reorder search results based on their semantic similarity to a query. » — les rerankers améliorent la pertinence des résultats issus des mécanismes de récupération antérieurs ; les rerankers sémantiques réordonnent les résultats selon leur similarité de sens avec la requête.
Google, de son côté, décrit son API de classement en opposant explicitement les deux étages : « Compared to embeddings, which look only at the semantic similarity of a document and a query, the ranking API can give you precise scores for how well a document answers a given query. » — là où les embeddings ne regardent que la similarité de sens, l’API de classement donne un score précis de la façon dont un document répond à la question.
La distinction tient dans deux verbes. Le premier étage — l’étage de rappel, du nom que l’informatique donne à l’opération consistant à aller chercher un lot de candidats dans un index — mesure si un document parle du sujet. L’étage de reranking mesure s’il répond à la question. Ce ne sont pas les mêmes opérations, et la suite explique pourquoi la première ne peut pas produire la seconde.
Ce que le premier étage ne peut pas voir, mesuré
Les tests ci-dessous tournent sur fr_core_news_md, un modèle spaCy français de 20 000 vecteurs à 300 dimensions, hors ligne. Deux protocoles sont donnés partout où ils diffèrent : protocole A, moyenne des vecteurs hors mots vides — les mots trop fréquents pour porter du sens, comme « le », « de », « ne », que les chaînes de traitement suppriment par habitude ; protocole B, mots vides conservés.
Avertissement de méthode, à lire avant les chiffres : ce modèle contient 20 000 vecteurs uniques pour 500 000 clés — la plupart des mots partagent leur ligne avec d’autres. Les résultats ne valent donc que comme écarts entre variantes d’un même texte, jamais comme niveaux absolus.
Test 1 — inverser les rôles ne change rien
Question : « comment réduire le temps de chargement d’une page web ». Les deux couples testés par le script sont donnés, pas seulement le plus favorable.
| Passage | Protocole A | Protocole B |
|---|---|---|
| l’image compressée réduit le temps de chargement de la page | 0,839085280895 | 0,866787433624 |
| le temps de chargement de la page réduit l’image compressée | 0,839085280895 | 0,866787433624 |
| Écart | 0,00 × 10⁰ | 0,00 × 10⁰ |
| le cache du navigateur accélère l’affichage du script | 0,668504476547 | 0,591655790806 |
| le script accélère l’affichage du cache du navigateur | 0,668504476547 | 0,591655731201 |
| Écart | 0,00 × 10⁰ | 5,96 × 10⁻⁸ |
Dans chaque couple, les deux phrases contiennent les mêmes mots dans un ordre différent. L’une est vraie, l’autre n’a aucun sens. Elles obtiennent le même score — non pas « proche », mais identique, à l’exception d’un écart de 6 centièmes de milliardième sur le dernier couple, qui n’est pas sémantique : c’est l’ordre d’addition des nombres à virgule flottante qui change.
Ce n’est pas un défaut du modèle français, c’est une propriété arithmétique. Une moyenne ne dépend pas de l’ordre des termes qu’on additionne. Tout score construit sur un vecteur moyen est donc aveugle à l’ordre des mots, par construction.
Corroboration, pour ceux qui préfèrent l’expérience à la démonstration : sur mille permutations aléatoires des mots d’un même passage, le script relève trois valeurs distinctes à 10⁻¹⁰ près, séparées de moins de 1,2 × 10⁻⁷. Même bruit flottant, même conclusion.
Test 2 — la négation coûte zéro point, sous un protocole courant
| Phrase | Protocole A | Protocole B |
|---|---|---|
| compresser les images réduit le temps de chargement | 0,730763 | 0,792265 |
| compresser les images ne réduit pas le temps de chargement | 0,730763 | 0,687685 |
| compresser les images augmente le temps de chargement | 0,732614 | 0,787599 |
Deux résultats à séparer, parce qu’ils ne disent pas la même chose.
Sous le protocole A, la négation est strictement gratuite : « ne » et « pas » sont des mots vides, la chaîne de traitement les jette, et la phrase qui nie la réponse obtient le score de la phrase qui la donne. À six décimales, la même valeur.
Et l’antonyme passe devant. Toujours sous le protocole A : « augmente le temps de chargement » — l’inverse exact de ce que demande la question — score plus haut que « réduit le temps de chargement ». 0,732614 contre 0,730763. Un antonyme apparaît dans les mêmes contextes que son contraire, donc son vecteur en est voisin.
Sous le protocole B, les deux effets s’inversent : la négation coûte enfin quelque chose (0,792 → 0,688) et l’antonyme repasse derrière (0,788 contre 0,792). Cette inversion est le résultat le plus utile des deux tableaux, et elle ne va pas dans le sens de la thèse : le sens d’une phrase peut tenir entièrement dans les mots que la chaîne de traitement supprime. Argument sérieux contre le filtrage des mots vides, et raison de publier les deux colonnes plutôt que la plus frappante.
fr_core_news_md. Sur mille permutations aléatoires du même passage, le script relève trois valeurs distinctes à 10⁻¹⁰ près, séparées de moins de 1,2 × 10⁻⁷ — soit l’ordre d’addition des nombres à virgule flottante, pas une différence de sens.Ce que ces tests établissent : ordre des mots et rôles grammaticaux échappent au premier étage dans tous les cas ; négation et polarité du verbe lui échappent sous un protocole de traitement pourtant répandu. Aucun de ces points n’est une imprécision qu’un meilleur modèle d’embedding corrigerait. C’est la conséquence de comparer deux textes qui ne se sont jamais rencontrés.
Ce que le reranker fait différemment
La différence n’est pas la taille du modèle. C’est quand la question et le document se rencontrent.
Elastic documente les deux architectures :
Bi-encodeur — « A bi-encoder model takes as input either document or query text. Documents and query embeddings are computed separately, so they aren’t aware of each other. » Documents et requête sont encodés séparément, donc chacun ignore l’autre.
Cross-encodeur — « A cross-encoder model can be thought of as a more powerful, all-in-one solution, because it generates query-aware document representations. It takes the query and document texts as a single, concatenated input. » Il produit des représentations du document conscientes de la question, en prenant les deux textes comme une seule entrée concaténée.
Trois mots portent tout : query-aware. Le cross-encodeur lit la question et le passage dans la même fenêtre, en une seule passe. Ses couches d’attention peuvent donc relier le « réduire » de la question au « augmente » du passage, et pénaliser. Le bi-encodeur, structurellement, ne peut pas : quand il encode le passage, la question n’existe pas encore.
| Bi-encodeur (rappel) | Cross-encodeur (reranking) | |
|---|---|---|
| Ce qu’il encode | la question ou le document, séparément | la question et le document, concaténés |
| Calcul possible à l’avance | oui, tout l’index | non, rien |
| Coût par requête | un vecteur, puis une recherche d’index | une passe de modèle par candidat |
| Sensible à l’ordre des mots | non (mesuré ci-dessus) | oui |
| Nombre de documents traitables | des milliards | quelques dizaines |
La ligne « calcul possible à l’avance » explique tout le reste. Les vecteurs d’un bi-encodeur se calculent une fois, à l’indexation. Un score de cross-encodeur dépend de la question : il ne peut se calculer qu’au moment où quelqu’un la pose. D’où la contrainte de temps.
Pourquoi quelques dizaines de candidats, et pas mille
Elastic est explicite sur la conséquence : « Cross-encoder models are generally larger and more computationally intensive, resulting in higher latencies and increased computational costs », et pour son propre modèle : « we would recommend shallow reranking for CPU inference: no more than top-30 results. » — reranking peu profond en inférence sur processeur classique, pas plus de 30 résultats.
L’ordre de grandeur se retrouve par un calcul. Sentence-BERT (Reimers & Gurevych, 2019) publie le repère de référence : « Finding the most similar pair in a collection of 10,000 sentences requires about 50 million inference computations (~65 hours) with BERT. » Le papier précise le matériel dans son introduction : « On a modern V100 GPU, this requires about 65 hours. » Soit 65 heures pour environ 50 millions de paires, donc 4,68 ms par paire.
| Candidats reclassés | Paires à calculer | Temps déduit |
|---|---|---|
| 10 | 10 | 47 ms |
| 30 | 30 | 140 ms |
| 50 | 50 | 234 ms |
| 100 | 100 | 468 ms |
| 200 | 200 | 936 ms |
| 1 000 | 1 000 | 4,7 s |
| 10 000 | 10 000 | 46,8 s |
Extrapolation descendante d’un repère de 2019, mesuré sur un GPU V100 avec un modèle de taille BERT-base. Ordre de grandeur, pas un benchmark — et un ordre de grandeur GPU, à ne pas confondre avec la recommandation d’Elastic, qui porte sur l’inférence processeur, donc bien plus lente.
Le seuil apparaît de lui-même : à 30 candidats, 140 ms, invisible dans une recherche ; à 1 000 candidats, 4,7 secondes, rédhibitoire. Ce n’est pas un choix éditorial, c’est une contrainte de latence — et elle explique pourquoi les limites publiées par les éditeurs se ressemblent autant.
| Fournisseur | Limite publiée | Longueur par document |
|---|---|---|
| Elastic Rerank | « no more than top-30 results » en inférence processeur | — |
| Google Cloud, API de classement | « You can include up to 1000 records per request » | 512 tokens jusqu’à 003, 1 024 pour 004 |
| Cohere Rerank v3.5 | erreur au-delà de 10 000 documents | blocs de 4 093 tokens ; requête tronquée à 2 048 |
| Cohere Rerank v4.0 | idem | blocs de 32 764 tokens ; requête tronquée à 16 384 |
Un token est l’unité de découpage du texte que manipulent ces modèles : environ quatre caractères, soit à peu près trois quarts de mot en anglais.
Jusqu’où reclasser : la mesure d’Elastic, et ce qu’elle ne dit pas
Elastic a mesuré où le gain sature : « on average we could achieve 90 % of maximum possible nDCG@10 gain re-ranking only 1/3 the number of results », ce qui donnait « an average re-ranking around the top 100 documents when using BM25 as a retriever ». Le nDCG@10 est une mesure de qualité de classement sur les dix premiers résultats, entre 0 et 1 ; BM25 est l’algorithme de classement par mots-clés utilisé par défaut depuis les années 1990, ici en rôle de premier étage.
L’éditeur relève lui-même la tension avec sa propre recommandation : « This is fairly deep reranking and not something we would necessarily recommend for inference on CPU. » Le benchmark reclasse 100 candidats ; la fiche du modèle conseille de ne pas dépasser 30 sur processeur. Les deux chiffres cohabitent parce qu’ils répondent à deux questions différentes — qualité maximale d’un côté, budget de calcul de l’autre.
Trois motifs de courbe se dégagent, et le troisième est celui que le secteur ne cite jamais :
| Motif | Part des cas testés | Ce qui se passe |
|---|---|---|
| « Fast increase followed by saturation » | 72,6 % | Le gain arrive vite, puis plafonne |
| « Fast increase to a maximum then decay » | 20,2 % | Le gain arrive, puis se dégrade si on reclasse plus profond |
| « Steady decay with any amount of re-ranking » | 7,1 % | Le reranking n’apporte jamais rien |
Le troisième motif est défini sans ambiguïté : « This category comprises all cases where the application of a re-ranker does not bring a performance benefit at any depth compared to BM25. On the contrary, we observe a continuous degradation as we re-rank more documents. » Dans un cas sur quatorze, ajouter un reranker dégrade le résultat par rapport au simple classement par mots-clés.
Et une nuance qui va contre l’intuition : la profondeur utile dépend du modèle, et les meilleurs rerankers gagnent à aller plus profond, pas moins. « More effective models such as Elastic Rerank and bge-reranker-v2-gemma reach a peak performance at larger depths, taking advantage of more of the available positives, while less effective models « saturate » faster », et « unsurprisingly the overall strongest re-rankers, such as Elastic Rerank, display the most consistent improvements with re-ranking depth. »
La conclusion pratique n’est donc pas « reclasser plus profond ne sert à rien » — c’est l’inverse chez les bons modèles. Elle est plus simple, et elle tient quel que soit le motif : un reranker ne voit que la liste qu’on lui donne. Une page absente du lot de candidats n’est jamais rattrapée.
L’entre-deux : l’interaction tardive
Entre le bi-encodeur aveugle et le cross-encodeur hors de prix, il existe une troisième voie : l’interaction tardive, ainsi nommée parce que la comparaison entre question et document est repoussée au dernier moment. ColBERT (Khattab & Zaharia, 27 avril 2020) encode question et document séparément — donc précalculable — mais garde un vecteur par mot au lieu d’un vecteur par passage, et compare les mots entre eux à la fin.
Le papier chiffre le compromis : « ColBERT’s effectiveness is competitive with existing BERT-based models (and outperforms every non-BERT baseline), while executing two orders-of-magnitude faster and requiring four orders-of-magnitude fewer FLOPs per query. » Cent fois plus rapide, dix mille fois moins d’opérations de calcul par requête, pour une qualité comparable.
Ce mécanisme est reproductible à petite échelle. Le script publié calcule un MaxSim — pour chaque mot de la question, le cosinus maximal avec un mot du passage, puis la moyenne — sur les mêmes vecteurs statiques que les tests précédents. Test : on rallonge le même passage avec des phrases de remplissage hors sujet, sans jamais toucher à la réponse. Les neuf lignes du script sont données.
| Phrases de remplissage | Mots de contenu | Cosinus (protocole A) | MaxSim | BM25 |
|---|---|---|---|---|
| 0 | 13 | 0,6945 | 0,5721 | 0,0724 |
| 1 | 20 | 0,5775 | 0,5801 | 0,0647 |
| 2 | 26 | 0,6078 | 0,5801 | 0,0592 |
| 3 | 32 | 0,6018 | 0,5818 | 0,0546 |
| 4 | 38 | 0,6045 | 0,5818 | 0,0507 |
| 5 | 43 | 0,5895 | 0,5818 | 0,0478 |
| 6 | 48 | 0,5905 | 0,5937 | 0,0452 |
| 7 | 54 | 0,6069 | 0,5937 | 0,0425 |
| 8 | 59 | 0,6017 | 0,5937 | 0,0405 |
| Variation | ×4,5 | −13,4 %, non monotone | +3,8 %, monotone | −44,1 %, monotone |
Trois comportements, trois enseignements.
BM25 s’effondre : −44,1 %, sans exception à aucune ligne. Le classement par mots-clés normalise par la longueur du document ; noyer une réponse dans du texte hors sujet est la façon la plus efficace de lui faire perdre son rang. C’est le résultat le plus net du tableau.
Le cosinus du vecteur moyen perd 13,4 %, mais irrégulièrement : le minimum est atteint dès la première phrase de remplissage (0,5775), puis le score remonte légèrement. L’écart premier-dernier est donc un indicateur grossier ; sur un échantillon de cette taille, seul le sens de variation est interprétable.
Le MaxSim, lui, gagne 3,8 %, de façon monotone. Un score construit mot par mot ne se dilue pas : le mot qui répond reste présent quelle que soit la longueur du texte autour. C’est exactement l’intérêt de l’interaction tardive.
Deux pièges rencontrés en produisant ce tableau, à énoncer plutôt qu’à cacher. Le premier concerne BM25 : calculé sur un corpus d’un seul document, comme dans la première version du script, son score est constant par construction — la longueur du document égale la longueur moyenne du corpus, le terme de normalisation vaut 1, et il ne reste que 0,287682, soit log(4/3). BM25 ne se compare qu’à l’intérieur d’un corpus commun ; le script publié affiche désormais les deux colonnes, dont l’artefact, pour que l’erreur soit visible. Le second concerne le MaxSim : sur vecteurs statiques, ce n’est pas un ColBERT entraîné. Sans contextualisation, il se comporte comme un appariement de mots-clés tolérant et sature à 1,0000 dès qu’un passage contient littéralement les mots de la question. C’est précisément la contextualisation, absente ici, qui fait la valeur du vrai ColBERT.
Combien le reranking rapporte, d’après les benchmarks publiés
Nogueira & Cho (13 janvier 2019) reclassent avec BERT les 1 000 meilleurs passages ramenés par BM25 sur MS MARCO, un jeu de données public de questions réelles posées à Bing. Résultats du tableau 1, en MRR@10 — une mesure de la position du premier bon résultat dans les dix premiers, entre 0 et 100 :
| Système | Dev | Eval |
|---|---|---|
| BM25 (Lucene, sans réglage) | 16,7 | 16,5 |
| IRNet (meilleur système précédent) | 27,8 | 28,1 |
| BERT base | 34,7 | — |
| BERT large | 36,5 | 35,8 |
L’abstract annonce « outperforming the previous state of the art by 27 % (relative) in MRR@10 » — soit 35,8 contre 28,1. Comparé à BM25 seul, le calcul donne 16,5 → 35,8, c’est-à-dire +117 % en relatif. La distinction compte : les 27 % se mesurent contre le meilleur système de l’époque, pas contre BM25.
Elastic Rerank, six ans plus tard, publie sur BEIR — une suite de jeux de données servant à tester un modèle sur des domaines qu’il n’a pas vus à l’entraînement — une moyenne nDCG@10 de 0,426 pour BM25 seul contre 0,565 en reclassant les 100 premiers résultats BM25, soit « an average improvement of 39 % across the full suite ». Le modèle repose sur DeBERTa v3 et pèse 184 millions de paramètres (86 millions de corps, 98 millions de couche d’embedding).
Deux autres lignées situent l’état de l’art, et chacune dit quelque chose d’utile :
- monoT5 — Nogueira, Jiang & Lin, 14 mars 2020 : le classement traité comme une génération de texte. Le modèle produit un mot cible (« true » ou « false »), et c’est la confiance qu’il accorde à ce mot qui sert de score. Conséquence pratique : le reranking n’a pas besoin d’une architecture dédiée, un modèle génératif suffit.
- LLM comme reranker — Sun et al., 19 avril 2023 : « properly instructed LLMs can deliver competitive, even superior results to state-of-the-art supervised methods on popular IR benchmarks », et surtout « a distilled 440M model outperforms a 3B supervised model on the BEIR benchmark ». Conséquence pratique : un reranker n’a pas besoin d’être gros. Un modèle de 440 millions de paramètres battait un modèle sept fois plus lourd.
L’ordre final compte aussi
Le reranking ne se contente pas de sélectionner : il ordonne. Et cet ordre a un effet mesuré sur la réponse produite.
Lost in the Middle (Liu et al., 6 juillet 2023) montre que la performance d’un modèle de langue « is often highest when relevant information occurs at the beginning or end » et « significantly degrades when models must access relevant information in the middle of long contexts » — meilleure quand l’information utile est au début ou à la fin, nettement dégradée quand il faut aller la chercher au milieu.
Conséquence pratique, à prendre pour ce qu’elle est — une extrapolation, le papier ne testant pas un dispositif de reranking : survivre au reranking ne suffit pas encore. Une page classée au milieu du lot retenu atterrit dans la zone du contexte que le modèle exploite le moins bien.
Quand le reranking ne sert à rien
Un article sur le reranking qui n’énoncerait que ses gains serait une brochure. Trois cas où l’étage ne sert pas, ou nuit :
- Un cas sur quatorze dans le benchmark d’Elastic : le reranker dégrade le résultat par rapport à BM25 seul, à toute profondeur (motif 3, 7,1 %).
- Un cas sur cinq : le gain existe mais se retourne si on reclasse trop profond (motif 2, 20,2 %).
- Quand la page n’est pas dans les candidats : aucun reranker ne va la chercher. C’est la limite qui compte le plus pour un éditeur de site.
Documenté, déduit, convention, observé, faux
C’est le tableau qui compte le plus, et le seul que peu de publications acceptent d’écrire.
| Affirmation | Statut | Base |
|---|---|---|
| Un cross-encodeur lit question et document concaténés et produit des représentations « query-aware » | Documenté | Documentation Elastic, phrase citée plus haut |
| L’API de classement de Google note « how well a document answers a given query », par opposition aux embeddings | Documenté | Documentation Google Cloud |
OpenAI expose un ranker configurable sur file_search, avec score_threshold et une fusion RRF paramétrable (embedding_weight / text_weight) |
Documenté | Documentation API OpenAI, Assistants file search |
| Reclasser un tiers des résultats capte 90 % du gain maximal en nDCG@10 | Documenté | Mesure publiée par Elastic sur BEIR |
| Dans 7,1 % des cas testés, le reranking dégrade le résultat à toute profondeur ; dans 20,2 %, il se retourne au-delà d’un pic | Documenté | Elastic Search Labs, partie 3, phrases citées |
| Les rerankers les plus performants gagnent à reclasser plus profond, pas moins | Documenté | Elastic Search Labs, partie 3 |
| Le reranking des 100 premiers résultats BM25 fait passer BEIR de 0,426 à 0,565 nDCG@10 | Documenté | Elastic Search Labs, benchmark publié |
| Un reranker de second étage peut consommer des signaux non textuels (prix produit, nombre de mots de la requête) | Documenté | Elastic, Learning To Rank : « Document features […] Example: product price in an eCommerce store » |
| Un score bâti sur un vecteur moyen est insensible à l’ordre des mots | Documenté et mesuré ici | Propriété de la moyenne ; écart de 0,00 sur les deux couples et 1 000 permutations, script publié |
| Google utilise FastSearch pour ancrer Gemini ; il repose sur des signaux RankEmbed, récupère moins de documents et produit des résultats web « abbreviated, ranked » de qualité inférieure à ceux de Search | Documenté | US v. Google, décision Mehta, 2 septembre 2025, § 44 |
| AI Overviews et AI Mode emploient un query fan-out, puis des « advanced models » identifient les pages de support | Documenté | Google Search Central, AI features |
ChatGPT charge un paramètre reranker_model: "ret-rr-skysight-v3", lisible dans le code source d’une conversation |
Observé, non documenté par l’éditeur | Relevé publié le 20 août 2025 par l’analyste SEO Metehan Yesilyurt, à partir du code source d’une conversation, et repris depuis par plusieurs publications spécialisées — toutes traçables à cette même inspection. Reproductible par n’importe qui, mais jamais confirmé par OpenAI, et sans aucune indication de profondeur |
| AI Overviews et AI Mode comportent un étage de reranking distinct de l’étage de rappel | Déduit | Aucune documentation Google ne l’écrit. Déduit de FastSearch (§ 44), de l’existence de l’API de classement de Google Cloud, et de l’impossibilité de calculer un score contextuel sur tout l’index |
| Le nombre de candidats reclassés par AI Mode ou ChatGPT | Non documenté | Aucune source publique trouvée. Les repères 30 / 100 / 1 000 / 10 000 viennent d’Elastic, Google Cloud et Cohere, pas des produits grand public. Le § 44 dit seulement que FastSearch « retrieves fewer documents », sans quantifier |
| « Optimiser pour le reranking » demande des techniques distinctes du SEO | Convention | Position courante du secteur GEO. Google écrit l’inverse : « There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary » — phrase encadrée, dans la source, par « The best practices for SEO remain relevant » et « That said, it’s always good to review the fundamental SEO best practices » |
| Un score de similarité au-delà d’un seuil garantit une citation | Faux | Le reranking recalcule tout à partir de la paire question-document. Le score de rappel ne survit pas à l’étage suivant |
| Le reranking peut rattraper une page absente des candidats | Faux | Un reranker ne voit que la liste qu’on lui donne |
Ce que ça change pour une page
Quatre conséquences se déduisent des mesures et des documents ci-dessus. Ce ne sont pas des « techniques GEO » : ce sont les mêmes fondamentaux, avec une raison mécanique de les appliquer.
1. Deux échecs différents, deux remèdes différents. Une page peut échouer au rappel (elle n’entre pas dans les candidats) ou au reranking (elle y entre et perd). Le premier échec se joue sur la couverture du sujet et l’indexation ; le second sur la présence d’une réponse explicite. Confondre les deux fait travailler sur le mauvais levier.
2. Le passage qui répond doit exister comme passage. Le cross-encodeur note une paire question-passage sur une fenêtre bornée : 512 tokens jusqu’à semantic-ranker-default-003, 1 024 pour 004, 4 093 pour Cohere v3.5, 32 764 pour v4.0. Les fenêtres s’élargissent, mais le principe ne change pas : ce qui est noté, c’est un extrait. Une réponse répartie sur toute une page n’est jamais notée en entier ; une réponse contenue dans un paragraphe, oui.
3. Le remplissage se paie deux fois, et d’abord au premier étage. Le test de dilution le chiffre : allonger un texte sans ajouter de réponse fait perdre 44 % à son score BM25 et 13 % à son vecteur moyen. Or ce sont ces deux scores qui décident si la page atteint l’étage suivant. Le paragraphe de mise en contexte placé avant la réponse coûte au rappel avant même d’exister pour le reranker.
4. Répéter les mots de la question fait entrer, mais ne fait plus gagner. Le premier étage récompense le vocabulaire partagé — au point de classer un antonyme au-dessus de la bonne réponse, comme le montre le test 2. Le second lit la relation. Une page qui reprend le vocabulaire et répond passe les deux étages. Une page qui ne fait que reprendre le vocabulaire passe le premier et tombe au second.
Sur la manière de faire remonter les bons passages entre vos propres pages, voir le guide du maillage interne.
À retenir
- Un moteur classe deux fois : rappel large et rapide, puis reranking étroit et précis.
- Le premier étage compare deux textes qui ne se sont jamais rencontrés. Mesuré : il donne à deux phrases de sens opposé un score identique à la douzième décimale, et note un antonyme au-dessus de la bonne réponse sous un protocole de traitement courant.
- Le second étage lit la question et le passage ensemble. C’est ce qui lui permet de voir la relation — et ce qui le rend coûteux : environ 4,68 ms par candidat sur le matériel du repère de 2019, donc quelques dizaines de candidats en pratique.
- Reclasser un tiers des candidats capte 90 % du gain. Mais dans 7,1 % des cas testés par Elastic, le reranking dégrade le résultat, et les meilleurs modèles gagnent au contraire à aller plus profond.
- Une page absente des candidats n’est jamais rattrapée.
- Ni Google ni OpenAI ne documentent l’étage de reranking de leurs produits grand public. Tous les chiffres de cet article viennent d’Elastic, de Google Cloud, de Cohere, de la documentation API d’OpenAI et de la littérature académique.
Questions fréquentes
Le reranking, c’est la même chose que la fusion RRF ?
Non, et les deux se suivent — la documentation d’OpenAI les expose même côte à côte sur file_search. La fusion RRF combine plusieurs listes classées en une seule en n’utilisant que les rangs : elle ne relit aucun texte. Le reranking relit le texte de chaque candidat face à la question. RRF réconcilie des classements ; le reranker en produit un nouveau.
Un meilleur modèle d’embedding rendrait-il le reranking inutile ? Non, pour une raison structurelle et non de qualité. Tant que la question et le document sont encodés séparément, aucun modèle ne peut faire dépendre la représentation du document d’une question qui n’est pas encore posée. Les tests 1 et 2 mesurent cette limite, pas la médiocrité d’un modèle particulier.
Combien de candidats un moteur IA reclasse-t-il réellement ? Aucune source publique ne le dit pour AI Mode ni pour ChatGPT. Les seuls chiffres publiés sont ceux des briques d’infrastructure : 30 recommandés par Elastic en inférence processeur, 100 dans son benchmark, 1 000 records maximum par requête pour l’API de classement de Google Cloud, 10 000 documents maximum chez Cohere.
Faut-il écrire des paragraphes courts « pour le reranker » ? Le levier n’est pas la longueur mais la complétude : le passage doit contenir la réponse en entier, dans une fenêtre allant de 512 à 32 764 tokens selon le modèle. Un paragraphe complet de dix lignes vaut mieux que trois paragraphes de deux lignes dont aucun ne suffit.
Le reranking utilise-t-il des signaux de comportement, comme le dwell time ? Oui, il peut — c’est même documenté. Les rerankers neuronaux présentés dans cet article (Elastic Rerank, Cohere, l’API de Google Cloud) ne notent que le texte de la paire question-document. Mais Elastic documente sous le nom de Learning To Rank un autre type de reranker de second étage, qui consomme explicitement des signaux non textuels : « Document features: These features are derived directly from document properties. Example: product price in an eCommerce store. » Rien n’interdit techniquement d’y placer un signal comportemental. Ce que Google Search fait en propre avec ses signaux de comportement reste, en revanche, non documenté à ce niveau de détail.
Sources
Documentation des fournisseurs
- elastic.co — Semantic reranking : définitions bi-encodeur / cross-encodeur, coût comparé
- elastic.co — Learning To Rank : reranker de second étage, features document / requête / question-document
- elastic.co — Elastic Rerank : DeBERTa v3, 184 M de paramètres, « no more than top-30 results »
- elastic.co — Elastic Rerank, partie 2 : BEIR 0,426 → 0,565 nDCG@10, +39 %, et la réserve sur l’inférence processeur
- elastic.co — Profondeur de reranking, partie 3 : les trois motifs (72,6 / 20,2 / 7,1 %), 90 % du gain sur un tiers des résultats, dépendance au modèle
- docs.cloud.google.com — Ranking API : 1 000 records par requête, 512 / 1 024 tokens, modèles
semantic-ranker-* - docs.cloud.google.com — RAG Engine, retrieval and ranking : reranker sémantique et reranker LLM
- docs.cohere.com — Best practices for Rerank : 10 000 documents max, blocs de 4 093 / 32 764 tokens
- developers.openai.com — Assistants file search :
ranker,score_threshold, pondération RRF - developers.google.com — AI features : query fan-out, absence d’exigences supplémentaires
Littérature
- arxiv.org/abs/1901.04085 — Nogueira & Cho, Passage Re-ranking with BERT, 13/01/2019
- arxiv.org/abs/2004.12832 — Khattab & Zaharia, ColBERT, 27/04/2020
- arxiv.org/abs/2003.06713 — Nogueira, Jiang & Lin, Document Ranking with a Pretrained Sequence-to-Sequence Model (monoT5), 14/03/2020
- arxiv.org/abs/2304.09542 — Sun et al., Is ChatGPT Good at Search?, 19/04/2023
- arxiv.org/abs/2307.03172 — Liu et al., Lost in the Middle, 06/07/2023
- arxiv.org/abs/1908.10084 — Reimers & Gurevych, Sentence-BERT, 27/08/2019
Pièce judiciaire
- caselaw.findlaw.com — US v. Google LLC, n° 20-cv-3010 (APM), 02/09/2025, conclusions de fait § 44
