A l'occasion du procès antitrust du ministère de la justice à l'encontre de Google, plusieurs nouveaux documents ont été publiés en avril et mai 2025.
Par exemple ce document résume un appel ayant eu lieu le 31 janvier 2025 concernant un litige lié à Google Search, avec la participation d'un ingénieur de Google, d'un expert et d'équipes juridiques. Voici ce qu'on peut y lire :
Il explique les concepts et la structure de la recherche Google référencés pendant l'appel :
Et dans cet autre document :
Ce document présente des éléments appris lors d'un appel du 18 février 2025 avec Hyung-Jin Kim, ingénieur chez Google, expert en recherche et inventeur sur des sujets comme Navboost, dans le cadre d'un litige.
Voici ce qu'on apprend principalement :
Quels éléments vous intéressent là-dedans ?
Par exemple ce document résume un appel ayant eu lieu le 31 janvier 2025 concernant un litige lié à Google Search, avec la participation d'un ingénieur de Google, d'un expert et d'équipes juridiques. Voici ce qu'on peut y lire :
Il explique les concepts et la structure de la recherche Google référencés pendant l'appel :
- Un "Document" désigne une page web telle que Google la voit.
- Les "Signaux" sont utilisés pour déterminer les résultats de recherche (SERP). Il existe des signaux bruts (plus de 100) et des signaux de haut niveau (agrégats). Certains sont basés sur l'apprentissage automatique (ML), d'autres sont plus traditionnels. Des exemples spécifiques abordés incluent Q* (mesure de qualité), Navboost (fréquence des clics basée sur les 13 derniers mois de données), RankEmbed (signal principal entraîné par LLM), Twiddlers (réorganisation des résultats sélectionnés) et PageRank (facteur de qualité historique).
- Les signaux sont combinés en un score unique pour classer les documents dans la liste de liens bleus. L'agrégation était une utilisation précoce du ML dans l'algorithme de recherche.
- Une interface de débogage interne permet de visualiser le processus d'expansion et de décomposition des requêtes, ainsi que le score de chaque signal de haut niveau et le score total pour les 10 premiers liens bleus. Les signaux de haut niveau sont une combinaison linéaire du log des signaux bruts, formulés pour avoir un impact monotone sur le classement.
- L'approche traditionnelle de classement était basée sur des fonctions comme Okapi BM25.
- La transition a impliqué l'utilisation croissante de modèles ML/deep learning comme RankBrain, DeepRank et RankEmbed pour générer des signaux.
- Google a constaté que combiner les signaux traditionnels et ceux "prédits" par le ML donnait de meilleurs résultats.
- Google évite de simplement "prédire les clics" car ils peuvent être manipulés et ne sont pas un bon indicateur de l'amélioration de l'expérience utilisateur.
- RankEmbed est un modèle dual encoder qui projette la requête et le document dans un espace sémantique. Le classement se fait par mesure de distance dans cet espace. Il est rapide et efficace pour les requêtes courantes, mais moins pour les requêtes rares ("tail queries"). Il a été entraîné sur un échantillon de données d'un seul mois.
- La qualité de RankEmbed est démontrée par son utilisation dans FastSearch, qui sert de mécanisme RAG (retrieval-augmented generation) pour des produits comme Vertex AI et l'application Gemini afin de fonder les réponses.
- Même une quantité limitée de données (quelques centaines de combinaisons requête/résultat) permettrait d'approximer certains signaux de Google, potentiellement utilisable par des concurrents pour recréer la recherche. Google tend à utiliser moins de données récentes pour le ML, mais utilise plus de données si cela améliore le produit pour les utilisateurs.
- Les LLM peuvent améliorer certaines parties de la recherche (interprétation des requêtes, résumé des résultats). Google réévalue actuellement l'ensemble de son architecture de recherche pour intégrer les LLM de manière plus proéminente dans des composants fondamentaux comme le classement, la récupération et l'affichage des résultats, en tenant compte du temps de calcul des LLM.
- De nombreux signaux sont influencés par les données côté utilisateur, à des degrés divers.
- Navboost est décrit comme une table de correspondance requête-document ("QD table") utilisant les fréquences d'activité des utilisateurs par document.
- Le processus de développement répond à la mission de Google de satisfaire les besoins des utilisateurs. Il implique d'identifier les problèmes, de déboguer pour comprendre les manques dans les signaux et d'intégrer de nouvelles informations.
- Des anecdotes illustrent cela : la correction d'un signal précoce biaisé par la position du lien, une innovation en cours de développement, la lutte contre les "content farms" en développant de nouveaux signaux au-delà de l'anchor, et l'innovation pour classer en priorité les résultats fiables pour des requêtes sensibles (comme l'Holocauste) tout en considérant une diversité nuancée des résultats.
- Certains signaux sont abandonnés s'ils sont peu performants, si un meilleur signal est développé, ou si leur efficacité diminue avec l'évolution d'internet.
- Google contribue à l'écosystème web en signalant aux développeurs (par exemple, l'importance de l'optimisation mobile) et en fournissant des outils (conseils SEO, optimisation des temps de chargement).
Et dans cet autre document :
Ce document présente des éléments appris lors d'un appel du 18 février 2025 avec Hyung-Jin Kim, ingénieur chez Google, expert en recherche et inventeur sur des sujets comme Navboost, dans le cadre d'un litige.
Voici ce qu'on apprend principalement :
- Conception des signaux ("Hand Crafting") : La plupart des signaux de Google, à l'exception de ceux basés sur les grands modèles linguistiques (LLM) comme RankBrain et DeepRank, sont conçus manuellement par les ingénieurs. Cela implique d'analyser les données, d'utiliser des fonctions (comme les sigmoïdes) et de définir des seuils, parfois manuellement. Pour la majorité des signaux, une régression est appliquée sur des données pertinentes (contenu, clics utilisateur, évaluations humaines). Navboost est cité comme un projet majeur pour HJ Kim, qu'il a développé pendant de nombreuses années.
- Signaux fondamentaux (ABC) et Topicalité : Les trois signaux fondamentaux (raw signals) sont les Ancres (A), le Corps (B) et les Clics (C). Ce sont des composantes clés de la Topicalité (T*), la détermination par Google de la pertinence d'un document par rapport à une requête. La Topicalité combine ces signaux de manière relativement manuelle. Le développement de la Topicalité a demandé un effort considérable pour passer d'une métrique de recherche d'information classique, impliquant la résolution de problèmes mathématiques complexes par des équipes d'ingénieurs.
- Transparence et dépannage : La raison pour laquelle la grande majorité des signaux sont conçus manuellement est la transparence. Cela permet aux ingénieurs de savoir exactement quoi réparer en cas de problème, facilitant le dépannage et l'amélioration, un avantage par rapport aux systèmes plus opaques basés uniquement sur le ML utilisés par certains concurrents comme Microsoft. Google peut ainsi ajuster les signaux pour des cas spécifiques ou en réponse à l'attention publique.
- Courbes des signaux de classement : Les ingénieurs tracent des courbes pour les signaux de classement à différents niveaux. Obtenir des informations sur les clics, les URL et les requêtes permettrait aux concurrents de facilement rétro-concevoir les grands groupes de signaux qui composent le score final utilisé pour le classement : ABC (Topicalité), Navboost et Qualité.
- Qualité (Q*) : La qualité de la page (confiance, autorité, Q*) est très importante. Elle est généralement statique pour un site donné, bien qu'elle puisse parfois intégrer des informations de la requête. Sa nature statique rendrait facile sa rétro-ingénierie si les logs étaient accessibles, donnant aux concurrents une notion de l'autorité d'un site. La qualité des pages reste un sujet majeur de plainte, et une équipe dédiée a été créée il y a environ 17 ans en réponse au problème des "content farms". L'IA est perçue comme pouvant potentiellement aggraver les problèmes de qualité.
- Autres signaux : Le document mentionne brièvement eDeepRank (un système LLM basé sur BERT essayant de rendre les signaux ML plus transparents), PageRank (utilisé comme entrée pour le score de Qualité et lié à la distance par rapport à des sources fiables) et un signal de popularité utilisant les données de Chrome.
- Index de recherche : L'index de recherche, selon HJ Kim, est principalement composé du contenu exploré (titres et corps) formant l'index inversé. Il existe des index spécialisés séparés pour d'autres sources de données. Les signaux basés sur la requête sont souvent calculés en temps réel ou stockés séparément, bien que certains soient stockés dans l'index principal pour des raisons pratiques.
- Données côté utilisateur : Cela fait référence aux données d'interaction de l'utilisateur (clics, etc.), et non au contenu créé par les utilisateurs.
- Fonctionnalités de recherche : Outre les 10 liens bleus, il existe d'autres fonctionnalités (panneaux de connaissances, etc.), chacune avec son propre classement. Tangram (anciennement Tetris) est un projet qui vise à appliquer les principes de recherche à toutes ces fonctionnalités. Son développement a été difficile, mais sa rétro-ingénierie serait facile avec l'accès aux données de clics et de requêtes.
- Knowledge Graph : Développé par une équipe séparée, il est utilisé non seulement pour les panneaux d'information mais aussi pour améliorer les résultats de la recherche traditionnelle en fournissant des informations contextuelles.
- Exemple de la boîte d'auto-assistance suicide : Un travail considérable a été investi pour afficher correctement cette fonctionnalité cruciale, mais les données de log permettraient une rétro-ingénierie facile de la logique sous-jacente.
- Rétro-ingénierie des signaux : Une fuite de documents Google a nommé certains composants du système de classement, mais sans détailler les courbes et les seuils précis.
Quels éléments vous intéressent là-dedans ?
