RRF : pourquoi être 3e sur trois recherches IA bat être 1er sur une seule

Douze recherches, douze classements, une seule liste

Quand vous posez une question à un moteur IA, il ne lance pas une recherche : il en lance une dizaine. Dounia Berrada, directrice senior de l’ingénierie chez Google, le formule ainsi le 5 mars 2026, dans un billet consacré à la recherche visuelle : « AI Mode fait en gros une douzaine de recherches pour vous dans le temps qu’il faut pour en faire une seule. »

Chaque recherche renvoie son propre classement. Douze recherches, douze listes de résultats différentes. Avant de rédiger sa réponse, le moteur doit transformer ces douze listes en une seule — le lot de sources dans lequel il va piocher.

La méthode standard pour faire ça s’appelle le Reciprocal Rank Fusion, ou RRF. Elle a été publiée en 2009, elle tient en une ligne de calcul, et Google l’utilise nommément dans sa propre infrastructure de recherche cloud.

Sa conséquence est contre-intuitive, et c’est tout l’intérêt du sujet : être 30e sur trois sous-requêtes rapporte deux fois plus qu’être 1er sur une seule et absent des onze autres. Les chiffres sont plus bas.

À retenir en cinq lignes

— Un moteur IA découpe votre question en plusieurs sous-requêtes et récupère plusieurs classements.

— Ces classements utilisent des scores incomparables entre eux : on ne peut pas les additionner.

— RRF résout le problème en ignorant les scores et en ne regardant que les rangs.

— Chaque liste vote, et un vote vaut 1 / (60 + votre place).

— Résultat : apparaître dans beaucoup de listes pèse plus lourd que la première place dans une seule.

Le problème que RRF résout : des scores qu’on ne peut pas additionner

Deux mécanismes multiplient les listes de résultats.

Le découpage de la question. C’est le query fan-out, l’éventail de requêtes. Le brevet Google « Search with stateful chat » (US20240289407A1, déposé le 27 février 2024, publié le 29 août 2024) le décrit : le système génère des requêtes supplémentaires, les envoie au moteur, puis « une pluralité de documents de résultats répondant à la fois à la requête et aux requêtes supplémentaires peut être sélectionnée pour inclusion dans un ensemble de documents de résultats ».

La double recherche. Dans les architectures de recherche hybride documentées — celles que Google, Microsoft et Elastic vendent à leurs clients —, chaque requête est cherchée de deux façons en parallèle :

• la recherche par mots-clés (algorithme BM25 : il compte les termes, pondère leur rareté, tient compte de la longueur du document) ;
• la recherche vectorielle, ou sémantique : le texte est transformé en coordonnées numériques, et on cherche les documents dont les coordonnées sont les plus proches de celles de la question. Elle trouve « comment réduire mes mensualités » quand la page parle de « renégocier son prêt », sans partage de vocabulaire.

Si AI Mode fonctionne sur ce modèle — c’est une déduction d’architecture, pas un fait publié —, une sous-requête produit au moins deux listes, et dix sous-requêtes en produisent vingt.

Pourquoi ne pas simplement additionner les scores de pertinence ? Parce qu’ils ne vivent pas dans la même unité. La documentation Microsoft d’Azure AI Search publie les plages : un score BM25 n’a aucune limite haute, un score de similarité cosinus est borné entre 0,333 et 1,00. Additionner les deux revient à additionner une note sur 20 et un temps au 100 mètres. Le résultat est un nombre, mais il ne veut rien dire.

D’où l’idée de RRF : jeter les scores, ne garder que les rangs. Une place est comparable d’une liste à l’autre. Un score, non.

La formule, en une ligne

Gordon Cormack, Charles Clarke et Stefan Büttcher, de l’université de Waterloo, publient RRF à la conférence SIGIR en 2009. Le principe se dit sans mathématiques : pour chaque liste où votre page apparaît, on calcule 1 / (60 + votre place), et on additionne le tout.

L’écriture exacte, pour qui veut la vérifier

RRFscore(d ∈ D) = Σ_r∈R 1 / (k + r(d))

où d est un document, R l’ensemble des classements, r(d) la place du document dans un classement donné, et k une constante fixée à 60.

Trois points suffisent à comprendre le comportement du système.

1. Chaque liste est un votant, et le vote décroît avec la place. Être 1er rapporte plus qu’être 20e, mais beaucoup moins qu’on ne le croit.

2. La constante k valait 60 dans l’article de 2009, et c’est resté la valeur par défaut de l’industrie. Les auteurs sont explicites sur sa fonction : « la constante k atténue l’impact des rangs élevés attribués par des systèmes aberrants ». Traduction : elle empêche un seul classement bizarre de propulser un document en tête à lui tout seul. Sur la valeur elle-même, ils sont modestes : « k = 60 a été fixé lors d’une investigation pilote et n’a pas été modifié pendant la validation ultérieure », et leur tableau de tests montre que k = 70 fait très légèrement mieux (MAP de 0,2147 contre 0,2145 pour k = 60). Leur conclusion : k = 60 est quasi optimal, et « le choix n’était pas critique ». Ce n’est pas un réglage fin, c’est un ordre de grandeur.

3. Aucun réglage n’est nécessaire. La documentation Elasticsearch le pose comme l’argument principal : « RRF ne demande aucun réglage, et les différents indicateurs de pertinence n’ont pas besoin d’être liés entre eux pour produire des résultats de qualité. » On peut fusionner des listes issues de méthodes qui n’ont rien en commun. C’est ce qui explique son adoption massive.

Le vrai enseignement : à l’intérieur d’une liste, la place compte peu

C’est ici que le sujet devient actionnable, et c’est la partie que la plupart des articles sur le GEO — Generative Engine Optimization, l’optimisation pour les moteurs génératifs — passent sous silence.

Avec k = 60, la première place ne vaut presque pas plus que la dixième :

Place dans une liste	Points rapportés	Par rapport à la 1re place
1re	0,01639	—
3e	0,01587	−3 %
10e	0,01429	−13 %
30e	0,01111	−32 %

Sans la constante k, la 10e place rapporterait 90 % de moins que la première. Avec k = 60, elle rapporte 13 % de moins. La constante écrase délibérément la hiérarchie du haut de chaque liste.

Conséquence directe, en additionnant plusieurs listes :

Situation d’une page	Score RRF	Rapport
8e sur cinq sous-requêtes	0,07353	×4,5
5e sur quatre sous-requêtes	0,06154	×3,8
3e sur trois sous-requêtes	0,04762	×2,9
30e sur trois sous-requêtes	0,03333	×2,0
10e sur deux sous-requêtes	0,02857	×1,7
1re sur une seule sous-requête	0,01639	×1

Calculs effectués avec k = 60, la valeur par défaut documentée chez Elastic, Microsoft et dans l’article de 2009. Chaque ligne suppose que la page est absente de toutes les autres listes : c’est l’hypothèse qui rend la comparaison lisible, pas une description de la réalité. Une page 1re sur la requête principale est en général présente dans plusieurs listes, et cumule donc elle aussi.

Lisez la quatrième ligne. Une page qui traîne en 30e position sur trois sous-requêtes double le score d’une page première sur une seule et absente des autres. Une page 8e sur cinq sous-requêtes en fait quatre fois et demie plus.

La couverture bat la position.

Dans un système qui fusionne des rangs, deux pages ne se battent pas d’abord sur « qui est le mieux classé ». Elles se battent sur « qui apparaît dans le plus de listes ». C’est un changement de métrique, pas un changement de technique.

Une précision qui évite le contresens. La couverture décide de votre candidature, pas de votre citation. Un score RRF élevé vous fait entrer dans le lot de sources potentielles ; un score nul — le cas d’une page qu’aucune sous-requête n’a récupérée — vous en exclut définitivement. Ce qui se passe ensuite est une autre étape : un reranking, c’est-à-dire un second modèle qui relit les candidats retenus et les réordonne, puis des filtres de qualité et un dédoublonnage par site. Deux étapes, deux logiques. La couverture vous met dans la pièce ; la qualité du passage décide si on vous cite.

Ce qui est documenté, et ce qui ne l’est pas

Point de rigueur, parce que beaucoup de contenus sur le GEO affirment que « les IA utilisent RRF pour choisir leurs sources » comme si Google l’avait annoncé. Ce n’est pas le cas.

Système	RRF nommé dans la documentation officielle ?	Détail
Vertex AI Vector Search (Google Cloud)	Oui	« Pour fusionner les résultats de la recherche par tokens et de la recherche sémantique, la recherche hybride utilise le Reciprocal Rank Fusion (RRF). » Un paramètre rrf_ranking_alpha permet de pondérer les deux côtés.
Elasticsearch	Oui	Formule publiée, rank_constant à 60 par défaut, toutes les listes à poids égal.
Azure AI Search (Microsoft)	Oui	« RRF est utilisé dès qu’il y a plus d’une exécution de requête. » k recommandé à 60.
LlamaIndex, RAG-Fusion	Oui	Le composant génère plusieurs requêtes à partir d’une seule, puis fusionne les classements en RRF. C’est exactement le schéma fan-out + fusion.
Google AI Mode et AI Overviews	Non	Le fan-out est confirmé (brevet + déclaration Google). La méthode de fusion n’est pas publiée. Le brevet US20240289407A1 ne nomme jamais RRF.
ChatGPT Search, Perplexity, Claude	Non	Aucune documentation publique sur la fusion des classements.

La formulation honnête est donc celle-ci : RRF est le mécanisme par défaut de l’infrastructure de recherche que ces produits utilisent, y compris celle que Google vend à ses clients. C’est une hypothèse d’architecture solide. Ce n’est pas une confirmation sur AI Mode.

Trois limites que RRF ne franchit pas

Il ignore l’ampleur de l’écart. RRF ne voit que des places. Un document premier avec un score écrasant et un document premier de justesse rapportent exactement la même chose. C’est une perte d’information assumée : on échange de la précision contre la capacité à fusionner n’importe quoi avec n’importe quoi.

Le gain mesuré est réel, modeste, et pas universel. L’article de 2009 conclut que « les expériences pilote et TREC indiquent que RRF surpasse Condorcet, CombMNZ et le meilleur système de 4 à 5 % en moyenne » — RRF y bat Condorcet 7 fois sur 7. Mais sur le jeu de données LETOR 3, le tableau de l’article donne une MAP (mean average precision, la précision moyenne du classement) de 0,6051 pour RRF, contre 0,5917 pour Condorcet, et 0,6107 pour CombMNZ, qui fait donc mieux que RRF — écart non significatif (p ≈ 0,2), mais qui mérite d’être dit. Côté applications récentes, le dépôt public RAG-Fusion d’Adrian Raudaschl mesure sur le corpus médical NFCorpus un gain de 0,057 point de NDCG@10 — un autre indicateur de qualité de classement — pour sa variante combinant BM25, recherche vectorielle et reformulations par IA. Des points, pas une révolution.

Une source absente de toutes les listes a un score de zéro. RRF trie ; il ne repêche rien. Une page qu’aucune sous-requête ne récupère n’entre pas dans le calcul. Le combat se joue d’abord à l’étape de récupération, et seulement ensuite à celle de la fusion.

Ce que ça change dans votre travail

1. Viser la constellation de sous-questions, pas la requête principale. Si votre page ne répond bien qu’à la formulation exacte de la requête tête, elle n’apparaît que dans une liste sur douze. Une page qui traite aussi les variantes — prix, délais, conditions, cas particuliers, comparaisons — apparaît dans plusieurs listes et cumule.

2. Un passage identifiable par sous-question. Google documente un « système de classement des passages », décrit ainsi : « une IA que nous utilisons pour identifier des sections individuelles, ou « passages », d’une page web, afin de mieux comprendre la pertinence de cette page pour une recherche ». Le classement reste au niveau de la page, mais l’unité que la machine lit est le passage. Concrètement : un sous-titre qui annonce une information précise, suivi d’une réponse autonome de quelques phrases, est identifiable. Un paragraphe qui aborde trois sujets à la fois ne l’est pour aucun des trois.

3. Écrire dans les deux vocabulaires. Deux listes coexistent sur chaque sous-requête. Le terme technique exact sert la recherche par mots-clés. La formulation naturelle, celle que le lecteur emploierait, sert la recherche vectorielle. Choisir un seul des deux registres, c’est renoncer à une des deux listes.

4. Changer d’indicateur. Le rang moyen sur une requête ne dit plus rien d’utile. L’indicateur pertinent est le taux de présence : sur l’ensemble des sous-questions plausibles autour de votre sujet, dans combien de classements apparaissez-vous ? Une simulation de fan-out suffit à établir la liste des sous-questions ; l’ordre de grandeur d’une douzaine vient de Google.

5. Ne pas survendre RRF en interne. C’est une hypothèse d’architecture appuyée sur la documentation de Google Cloud, d’Elastic et de Microsoft, pas une déclaration de Google sur AI Mode. La différence compte le jour où quelqu’un vous demande votre source.

Questions fréquentes

Combien de sous-requêtes sont générées pour ma requête ? Le nombre n’est pas public et varie selon la question. Le seul ordre de grandeur venant de Google est celui de la déclaration de mars 2026 : « une douzaine ». Une question simple en produit probablement moins, une question composée davantage. Toute promesse d’un nombre exact par un outil tiers est une estimation, pas une mesure.

Comment mesurer mon taux de présence ? Il faut une liste de sous-questions plausibles autour de votre sujet — produite à la main ou par un simulateur de fan-out —, puis un relevé, pour chacune, des dix à vingt premiers résultats. Le taux de présence est la part des sous-questions où votre page apparaît. C’est un relevé manuel ou scripté ; aucun outil grand public ne le publie aujourd’hui comme métrique standard.

Peut-on donner plus de poids à une méthode de recherche qu’à une autre ? Oui, avec des variantes pondérées. Google Cloud expose un paramètre rrf_ranking_alpha : à 1, seule la recherche dense compte ; à 0, seule la recherche par mots-clés ; entre les deux, les deux sont mélangées selon le poids indiqué. Elastic a également publié une version pondérée sur son blog Search Labs, alors que sa page de référence, elle, traite toutes les listes à égalité. Le RRF de base ne pondère rien.

Est-ce que ça veut dire que le classement Google classique ne compte plus ? Il compte autrement. Il détermine votre place dans chacune des listes. Mais avec k = 60, l’écart de points entre la 1re et la 10e place à l’intérieur d’une même liste est de 13 %, alors que passer d’une liste à trois listes multiplie votre score par trois. L’effort marginal se déplace de la position vers la couverture.

AI Mode est-il disponible en France ? Oui. Google a déployé les Aperçus IA et le Mode IA en France le 22 juillet 2026, après un retard lié au dossier des droits voisins. Les mécanismes décrits ici s’appliquent donc au marché français.

Méthode et sources

Les scores de ce document ont été recalculés à partir de la formule de l’article de 2009 avec k = 60. Ils sont reproductibles en trois lignes de code : pour chaque page, additionner 1 / (60 + rang) sur chacune des listes où elle apparaît.

Les affirmations sur le fonctionnement d’AI Mode se limitent à ce que Google a publié : le fan-out et son ordre de grandeur. La méthode de fusion employée par AI Mode n’est pas documentée, et rien ici ne prétend le contraire.

• Cormack, Clarke, Büttcher, « Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods », SIGIR 2009 — PDF
• Google Cloud, « À propos de la recherche hybride », documentation Vector Search — lien
• Elastic, « Reciprocal rank fusion », référence Elasticsearch — lien
• Elastic Search Labs, « Weighted reciprocal rank fusion » — lien
• Microsoft, « Hybrid search scoring (RRF) », Azure AI Search — lien
• Google, brevet US20240289407A1 « Search with stateful chat », déposé le 27/02/2024 — lien
• Google, « How Google AI visual search works », 5 mars 2026 — lien
• Google Search Central, « Guide to Google Search ranking systems » (système de classement des passages) — lien
• LlamaIndex, « Reciprocal Rerank Fusion Retriever » — lien
• Adrian Raudaschl, dépôt RAG-Fusion — lien