La contrainte économique qui dicte l’architecture du moteur
Des milliards de requêtes par jour près de cent mille par seconde, adressées à un index dont la taille se chiffre en centaines de milliards de pages, avec une exigence pour le temps de réponse : rendre la liste des liens bleus quelques millisecondes, que ce soit sur un ordinateur bien connecté à internet ou sur un téléphone bas de gamme connectée en 3G au fin fond du métro…
Ça, c’est la contrainte technique, et ça demande une prouesse énorme, parce que pour faire ça, le temps doit être considéré comme un budget, et Google n’a pas le temps, que ce soit de scorer chaque document de son index avec ses modèles les plus précis, ou comparer une requête à un milliard de candidats avec un transformer à dix milliards de paramètres. Il n’a, aussi, pas l’envie de brûler des dollars en pure perte pour un résultat marginalement meilleur.
C’est une contrainte essentielle qui dessine l’architecture du moteur. Et c’est ce qui explique pourquoi QBST et NavBoost sont si importants pour son fonctionnement.
Le problème : l’impossibilité physique du scoring complet
Pour comprendre l’enjeu, il faut accepter une idée que le grand public a généralement de la peine à appréhender : faire un moteur de recherche, évaluer un document, ce n’est pas gratuit. Chaque appel à un modèle de machine learning coûte du calcul, donc du temps, donc de l’argent.
Faire passer un document à travers un algorithme léger, un calcul de TF-IDF, par exemple, coûte quelques microsecondes. Le faire passer à travers un classifieur coûte des dizaines de microsecondes. Le faire passer à travers un transformer comme BERT ou MUM coûte des millisecondes, parfois des dizaines de millisecondes par document.
À l’échelle d’une requête, la différence est invisible, mais à l’échelle des cent mille requêtes par secondes sur cet index de cent milliards de pages, c’est gargantuesque. Si Google voulait appliquer son scoring le plus précis à chaque document de l’index pour chaque requête, il devrait utiliser l’équivalent de plusieurs années-machine par requête. Multiplié par cent mille requêtes par seconde, on atteint des chiffres qui n’ont aucun sens.
On en arrive à une conséquence assez logique : Google ne peut pas scorer finement tout l’index à la volée. Il doit filtrer agressivement avant d’appliquer ses signaux coûteux, c’est exactement ce que propose l’architecture en cascade.
L’architecture en cascade : trier grossier d’abord, trier fin ensuite
Le principe du cascade ranking est documenté en information retrieval depuis quelques années déjà. Wang, Lin et Metzler en ont produit des bases académiques en 2011, et tous les grands moteurs modernes disposant d’un index (Bing, Yandex, Baidu, Google) opèrent sur ce principe, adapté à leurs propres infrastructures. L’idée est simple : on enchaîne plusieurs étages de ranking, chacun plus précis que le précédent, chacun opérant sur un sous-ensemble plus restreint de documents. On filtre et on nettoie le web, pour retirer ce qui s’apparente à du spam ou du contenu sans intérêt ou sans légitimité, afin d’avoir un niveau moyen plus proche de contenus de qualité.
Concrètement, voici l’architecture telle qu’on peut la reconstituer en croisant le leak, les témoignages DOJ, et les publications de recherche Google :
Ce qui rend cette architecture viable, c’est la combinaison de deux propriétés. D’abord la réduction exponentielle du nombre de candidats à chaque étage : on passe de milliards à millions, puis à milliers, puis à centaines, puis à dix. Ensuite l’inversion du coût marginal : les étages bon marché travaillent sur beaucoup de documents, les étages chers sur peu.
C’est dans cette logique qu’il faut situer QBST et NavBoost. Pas comme des facteurs périphériques. Comme les pièces qui permettent à la cascade de tenir économiquement.
QBST : pondérer la requête avant même l’index inversé
QBST, pour Query-Based Salient Terms, injecte à la requête de l’intelligence apprise des utilisateurs, et c’est ce qui en fait l’arme économique la plus discrète du moteur. La description publique de QBST est minimaliste, mais indique quand même qu’il opère sur la requête directement, et pas sur les documents.
Le système analyse, pour chaque requête (ou chaque famille de requêtes), quels termes apparaissent de façon saillante dans les documents que les utilisateurs ont effectivement préférés au fil du temps. Il en déduit une représentation pondérée de la requête où les termes vraiment discriminants reçoivent un poids élevé, et où les termes accessoires sont rétrogradés.
La conséquence, c’est que cette pondération peut s’exercer sur l’index inversé lui-même. L’index inversé est la structure de données fondamentale du moteur : une table géante qui associe chaque requête à la liste des documents qui contiennent les termes importants (saillants) que les utilisateurs s’attendent à voir dessus. Quand une requête arrive, c’est elle qu’on consulte pour récupérer le pool initial de candidats. Quand la requête est traitée, on récupère tous les documents contenant ces termes, et on ignore ceux qui ne les contiennent pas.
Le pool initial de candidats est donc plus restreint, plus propre, plus pertinent dès la première étape. Le moteur ne perd pas son temps à charger en mémoire et à filtrer des millions de documents qui n’avaient aucune chance : ils n’entrent jamais dans la course.
C’est l’endroit du pipeline où le levier économique est le plus brutal. C’est une optimisation qui fait économiser quelques centaines d’évaluations ML coûteuses sur l’étape 3. Une optimisation à l’étage du rappel fait économiser plusieurs ordres de grandeur de documents qui n’auront pas à être traités du tout. Filtrer une fois bien en amont vaut mieux que filtrer dix fois en aval : c’est le théorème central de toute architecture en cascade, et c’est la raison pour laquelle QBST est un élément essentiel (et la raison pour laquelle Yourtext Guru n’est pas un outil d’optimisation sémantique comme les autres, puisque nous identifions les termes du QBST pour les requêtes que vous ciblez).
Petit détail, mais qui a son importance : QBST se nourrit en partie de ce que NavBoost mesure. Les termes saillants ne sont pas définis dans l’abstrait : ils émergent de l’observation des documents que les utilisateurs ont effectivement préférés. On observe une boucle : les clics informent NavBoost, NavBoost détermine les top documents, QBST extrait les termes saillants de ces documents, ces termes pondèrent l’index inversé pour les prochaines requêtes. C’est cette boucle qui transforme la récupération elle-même (et non plus seulement le classement) en signal comportemental masqué.
Pour en savoir plus sur comment montrer patte blanche pour le QBST, prenons rendez-vous ici.
Prendre rendez-vousNavBoost : l’intelligence des clics, pré-agrégée
NavBoost est mentionné plusieurs fois dans la documentation leakée du Content Warehouse, et confirmé sous serment par Pandu Nayak, VP Search chez Google, lors du procès DOJ. La double confirmation, et le mensonge passé de Google sur la mesure des clics, donnent à ce signal un statut particulier
Les attributs du module Craps (qui stocke les signaux exploités par NavBoost) sont désormais largement commentés. goodClicks pour les clics suivis d’une session significative. badClicks pour le pogo-sticking (l’utilisateur revient à la SERP en moins de quelques secondes). lastLongestClicks pour le dernier clic de la session, celui qui a fixé l’utilisateur le plus longtemps : c’est, d’après les analyses techniques, l’un des signaux les plus forts (même si techniquement, il faut surtout du clic).
Mais ce qui est intéressant pour cet article, ce n’est pas la liste des attributs, c’est la manière dont NavBoost s’inscrit dans la cascade. Le scoring comportemental ne se calcule pas à la volée pour chaque requête. Les signaux sont agrégés et stockés dans le module Craps, indexés par requête et par document, et consultés à l’inférence comme on consulte une table de hash. Le coût marginal d’un appel à NavBoost est quasiment nul comparé à un re-scoring ML complet.
C’est ça l’avantage économique de Google : en transférant l’effort de calcul en amont, dans une phase de pré-agrégation tournant en continu sur ses bases de données, pour rendre la consultation à la volée triviale. À l’inférence, NavBoost est presque gratuit, mais à l’entraînement (au sens large : à l’alimentation continue des bases), il est coûteux, mais ce coût est amorti sur des milliards de requêtes.
Cette propriété explique pourquoi NavBoost est structurellement irremplaçable. Le jour où Google voudrait abandonner le re-ranking comportemental pour revenir à un scoring purement sémantique, il devrait soit accepter une dégradation massive de la pertinence, soit faire tourner ses transformers sur plus de documents qu’aujourd’hui, ce qui est économiquement absurde.
D’ailleurs, Navboost étant alimenté par une collecte de data des utilisateurs, il n’y a qu’un pas pour comprendre quel outil est essentiel pour ses résultats : Google Chrome.
Ça explique sans doute la réticence de Google à se séparer de cet outil quand le DOJ et l’Union Européenne aimerait le forcer à vendre ou à en vendre la donnée.
Une conséquence stratégique inconfortable
L’angle développé jusqu’ici a une implication directe pour quiconque fait du SEO sérieusement :
On parle souvent des 3 piliers du SEO, c’est une image de tabouret à trois pieds vieux comme la profession, mais il faut considérer ces points légèrement différemment aujourd’hui :
- La technique : votre site doit être lisible pour un robot. Une information mal encodée, des balises mal fermées, votre site enchaîne les erreurs et au bout d’un moment on se retrouve avec des erreurs de parsing qui font que votre page est juste ignorée. Le bot est un moteur de crawl, qui est en réalité une liste d’attente, parcourue par le fetcher, lequel envoie les informations au parser, qui identifie, d’un point de vue lecture, ce qu’il peut garder. Ce que la partie fetcher veut, c’est récupérer vos pages. Ce que le parser veut, c’est lire le contenu de la page. Si vous recevez des liens depuis l’extérieur de la page, le fetcher peut s’y rendre parce que le parser, à un moment donné, sur une autre page, aura vu un lien vers votre page et l’aura (peut-être) intégré à la liste d’attente. Si le contenu de votre page est lisible pour le parser, il décidera de l’envoyer pour traitement, mais effectuera peut-être un pré traitement pour que lorsqu’il envoie une url à la liste d’attente, il évite d’envoyer une url inutile, s’il peut détecter ça en amont.
- La sémantique : après que le parser ait lu vos pages, elles sont découpées en chunks, et l’information présente dans les chunks est évaluée via de nombreux facteurs. Pour la sémantique, il s’agit de mentionner les bons mots (QBST) pour être dans le pool de pages candidates pour les requêtes visées. Il y a d’autres signaux et filtres, mais du côté sémantique c’est ça, la proximité sémantique avec un vecteur attendu pour la requête en utilisant des mots attendus, et la façon dont le contenu est adressé (EEAT).
- L’autorité : aujourd’hui, l’autorité réelle d’une page / d’un site, c’est surtout via Navboost (et donc les clics utilisateurs). Avant on pouvait se fier exclusivement à des calculs de PageRank, mais aujourd’hui, c’est moins le cas. Le PageRank normalisé ne peut réellement servir qu’à un seul endroit : dans la file d’attente du crawler pour prioriser le passage du fetcher. (Et encore, il est possible que le PageRank ne soit pas le seul signal de ce côté et que Navboost vienne lui prendre la place à terme, si ce n’est pas déjà le cas).
Il ne faudrait pas suggérer que du côté de Google, on soit dans un univers où les facteurs sont indépendants et où on pourrait, à la rigueur, négliger l’un en compensant par les autres.
L’architecture en cascade dit l’inverse :
Les différents signaux peuvent servir à différents étages, en fonction de leur coût de traitement pendant une réponse à une requête. Mais ne traitez que les premiers étages et vous êtes filtrés si on va plus loin, ne traitez que les derniers étages et vous n’apparaîtrez même pas dans la liste. La page peut être impeccable du point de vue de Mustang et passer le pre-scoring sans encombre, si elle ne génère pas les goodClicks et les lastLongestClicks attendus, elle ne montera pas.
Pire : elle redescendra, parce que NavBoost est bidirectionnel. Un mauvais signal comportemental est une rétrogradation active (ou simplement les autres pages qui ont le signal se retrouveront devant).
Ce que ça change concrètement
Si l’on prend l’architecture en cascade au sérieux, la notion des éléments essentiels en SEO se redessine un peu :
L’optimisation pour lastLongestClicks devient le cœur du métier, c’est-à-dire qu’il faut structurer la page pour que l’utilisateur trouve sa réponse complète sans avoir à repartir ailleurs : l’utilisateur doit ressortir avec son problème résolu, sans avoir à revenir à la SERP.
Il faut également soigner la cohérence entre la promesse du titre et la livraison du contenu : titlesMatchScore a un impact et vous ne voulez pas passer à côté (on en parlera plus longuement dans un autre article).
L’alignement sur les termes saillants (la logique QBST) déplace lui aussi la pratique. Travailler les variantes lexicales pour le seul plaisir d’occuper du champ sémantique perd son sens si ces variantes ne sont pas saillantes au sens où Google les mesure : mieux vaut un contenu qui couvre profondément les termes que QBST aura jugés saillants pour la requête cible qu’un contenu qui s’éparpille sur quinze synonymes peu discriminants.
C’est aussi pour cela que Yourtext Guru observe ceux qui sont présents dans la page de résultat avec attention : analyser leurs termes saillants est devenu une étape opératoire avant la rédaction. (On ne devine pas ce que QBST valorise, c’est un élément observable).
Enfin, la fameuse séparation entre « SEO on-page » et « SEO off-page » perd beaucoup de sa pertinence. La séparation utile, à l’ère de la cascade, est entre signaux d’éligibilité (qui font passer la page dans les étages amonts : contenu, liens, qualité technique) et signaux de satisfaction (qui font progresser dans les étages avals : comportement utilisateur, alignement avec les termes saillants observés).
Une dernière marche, une première marche
La contrainte du coût computationnel est ce qui dicte l’ordre des étapes, et qui définit, in fine, là où la position se joue. On en sort un peut avec une architecture en étau : QBST en amont, pour l’index inversé, et Navboost en aval, pour bénéficier d’un sacré coup de pouce au moment du reranking. Entre les deux, les étages coûteux du scoring sémantique et du scoring par Machine Learning font leur travail pour faire une première proposition de réponse via Mustang.
Sources utilisées :
Hobo Web (https://www.hobo-web.co.uk/compressedqualitysignals/) Analyse de CompressedQualitySignals et https://www.hobo-web.co.uk/evidence-based-mapping-of-google-updates-to-leaked-internal-ranking-signals/
Yourtext Guru https://central.yourtext.guru/fr/qbst-en-2024-ecrire-pour-google-cest-plus-que-jamais-utiliser-les-bons-mots/ : post de Guillaume sur QBST
