Règles du machine learning :

Bonnes pratiques pour le développement de systèmes de ML

Martin Zinkevich

L'objectif de ce document est d'aider les personnes ayant une connaissance de base du machine learning à profiter des bonnes pratiques de Google en la matière. Son style est semblable à celui du guide de style Google C++ ainsi qu'à d'autres guides populaires de programmation pratique. Si vous avez suivi un cours sur le machine learning, ou bien si vous avez créé un modèle de machine learning ou travaillé sur un tel modèle, vous avez toute l'expérience nécessaire pour lire ce document.

Terminologie

Les termes suivants apparaissent à plusieurs reprises dans notre discussion sur les caractéristiques d'un système de machine learning performant :

  • Instance : ce sur quoi vous souhaitez effectuer une prédiction. Par exemple, l'instance peut être une page Web que vous souhaitez classer comme étant "sur les chats" ou "pas sur les chats".
  • Étiquette : la réponse d'une tâche de prédiction. Plus précisément, soit la réponse produite par un système de machine learning, soit la bonne réponse fournie dans les données d'apprentissage. Par exemple, l'étiquette d'une page Web peut être "sur les chats".
  • Caractéristique : propriété d'une instance utilisée dans une tâche de prédiction. Par exemple, une page Web peut avoir la caractéristique "contient le mot 'chat'".
  • Colonne de caractéristiques : ensemble de caractéristiques liées, par exemple l'ensemble de tous les pays possibles dans lesquels les utilisateurs peuvent résider. Une colonne de caractéristiques d'un exemple peut contenir une ou plusieurs caractéristiques. L'expression "colonne de caractéristiques" est propre à Google. Elle est appelée "espace de noms" dans le système VW (chez Yahoo/Microsoft), ou champ.
  • Exemple : une instance (avec ses caractéristiques) et une étiquette.
  • Modèle : représentation statistique d'une tâche de prédiction. Vous entraînez un modèle avec des exemples, puis utilisez le modèle pour réaliser des prédictions.
  • Statistique : nombre qui vous intéresse. Peut ou non être optimisé directement.
  • Objectif : statistique que votre algorithme essaie d'optimiser.
  • Pipeline : infrastructure sur laquelle repose l'algorithme de machine learning. Inclut la collecte des données depuis le frontal, l'intégration de celles-ci dans des fichiers de données d'apprentissage, l'entraînement d'un ou plusieurs modèles, et l'exportation des modèles en production.
  • Taux de clics : pourcentage de visiteurs d'une page Web qui cliquent sur un lien dans une annonce.

Aperçu

Pour créer des produits performants, appliquez cette règle simple :

Approchez le machine learning comme l'excellent ingénieur que vous êtes, et non comme le grand expert en machine learning que vous n'êtes pas.

La plupart des problèmes auxquels vous serez confronté sont, en fait, des problèmes d'ingénierie. Même avec toutes les ressources d'un grand expert en machine learning, la plupart des gains sont dus à la qualité des caractéristiques, et non à la qualité des algorithmes de machine learning. L'approche de base est donc la suivante :

  1. Assurez-vous que votre pipeline est robuste de bout en bout.
  2. Commencez avec un objectif raisonnable.
  3. Ajoutez de façon simple des caractéristiques sensées.
  4. Assurez-vous que votre pipeline reste solide.

Cette approche fonctionnera bien pour longtemps. Ne vous écartez de cette approche que si vous avez épuisé toutes les astuces simples possibles pour avancer. Rendre le modèle plus complexe ralentit la publication des versions suivantes.

Une fois que vous avez épuisé toutes les astuces simples, vous pouvez effectivement commencer à envisager un machine learning sophistiqué. Reportez-vous à la section dans la phase III des projets de machine learning.

Ce document est organisé comme suit :

  1. La première partie devrait vous aider à comprendre si le moment est propice à la création d'un système de machine learning.
  2. La deuxième partie traite du déploiement de votre premier pipeline.
  3. La troisième partie concerne le lancement et l'itération en parallèle à l'ajout de nouvelles caractéristiques à votre pipeline, et traite de l'évaluation des modèles et du biais d'apprentissage/invocation.
  4. La dernière partie explique ce qu'il faut faire lorsque vous atteignez un plateau.
  5. Enfin, vous trouverez la liste des travaux connexes et une annexe avec quelques informations contextuelles sur les systèmes couramment utilisés comme exemples dans ce document.

Avant le machine learning

Règle n° 1 : n'ayez pas peur de lancer un produit sans machine learning

Certes, le machine learning est une technologie merveilleuse, mais il nécessite des données. Théoriquement, vous pourriez prendre les données d'un problème différent et modifier le modèle pour un nouveau produit, mais les résultats seront sans doute moins bons que ceux d'une méthode heuristique de base. Si vous pensez que le machine learning améliorera vos performances de 100 %, une méthode heuristique vous permettra déjà de faire 50 % du chemin.

Par exemple, si vous classez les applications d'une place de marché, vous pouvez utiliser le taux d'installations ou le nombre d'installations comme méthodes heuristiques. Si vous essayez de détecter le spam, filtrez les éditeurs qui en ont déjà envoyé. N'hésitez pas non plus à recourir à des personnes pour l'édition. Si vous avez besoin de classer les contacts, classer ceux les plus récemment utilisés en premier (ou même, classez-les par ordre alphabétique). Si le machine learning n'est pas indispensable à votre produit, ne l'utilisez pas tant que vous n'avez aucune donnée.

Règle n° 2 : commencez par définir et mettre en œuvre des statistiques

Avant de formaliser le fonctionnement de votre système de machine learning, suivez autant de statistiques que possible dans votre système actuel. Il y a plusieurs raisons pour cela :

  1. Il est plus facile d'obtenir l'autorisation des utilisateurs du système au début du processus.
  2. Si vous pensez qu'un élément pourrait venir à poser problème, il est préférable d'obtenir des données historiques maintenant.
  3. Si vous concevez votre système avec le suivi des statistiques à l'esprit, les choses seront plus simples par la suite. Cela vous évitera de vous retrouver à fouiller les journaux à la recherche de chaînes pour suivre vos statistiques.
  4. Vous pourrez voir quels éléments changent et lesquels ne changent pas. Supposons que vous souhaitiez optimiser directement les utilisateurs actifs en un jour. Lors de vos premières manipulations du système, vous remarquerez peut-être que des modifications majeures de l'expérience utilisateur n'affectent pas sensiblement cette statistique.

L'équipe Google Plus mesure les développements, partages, +1 et commentaires par lecture, les commentaires et partages par utilisateur, etc., puis utilise ces informations pour calculer la qualité d'un post lors de l'invocation. Notez également qu'un cadre d'expérimentation dans lequel vous pouvez regrouper des utilisateurs dans des ensembles et agréger des statistiques par test est important. Reportez-vous à la règle n° 12.

Si vous procédez à une collecte plus large de statistiques, vous pourrez obtenir une image plus complète de votre système. Vous constatez un problème ? Ajoutez une statistique pour en effectuer le suivi ! Enthousiasmé par certains changements quantitatifs sur la dernière version ? Ajoutez une statistique pour en effectuer le suivi !

Règle n° 3 : optez pour le machine learning plutôt que pour une méthode heuristique complexe

Une méthode heuristique simple peut vous permettre de sortir votre produit. Une méthode heuristique complexe est impossible à gérer. Dès que vous avez des données et une idée de base de ce que vous voulez réaliser, passez au machine learning. Comme dans la plupart des tâches de génie logiciel, vous devrez constamment modifier votre approche, qu'il s'agisse d'une méthode heuristique ou d'un modèle de machine learning, et vous pourrez constater que le modèle de machine learning est plus simple à mettre à jour et à gérer (voir la règle n° 16).

Phase I du machine learning : Votre premier pipeline

Pour votre premier pipeline, concentrez-vous sur l'infrastructure de votre système. Il est certes amusant d'imaginer tout ce que vous allez pouvoir faire avec le machine learning, mais il est difficile de savoir ce qui va se passer si vous ne pouvez pas d'abord faire confiance à votre pipeline.

Règle n° 4 : votre premier modèle doit être simple et votre infrastructure bien conçue

C'est le premier modèle qui optimise le plus votre produit ; il n'a donc pas besoin d'être sophistiqué. Mais vous rencontrerez bien plus de problèmes d'infrastructure que vous ne le pensez. Avant que quiconque puisse utiliser votre nouveau système de machine learning, vous devez effectuer les tâches suivantes :

  • Déterminer comment obtenir des exemples pour votre algorithme d'apprentissage.
  • Établir une première définition de ce qui est "bon" et "mauvais" pour votre système.
  • Déterminer comment intégrer votre modèle dans votre application. Vous pouvez soit appliquer le modèle en direct, soit précalculer le modèle sur des exemples hors ligne et stocker les résultats dans une table. Par exemple, vous pourriez préclasser des pages Web et stocker les résultats dans une table, mais classer en direct les messages de discussion.

L'utilisation de caractéristiques simples permet de s'assurer que :

  • les caractéristiques atteignent votre algorithme d'apprentissage correctement ;
  • le modèle apprend des pondérations raisonnables ;
  • les caractéristiques atteignent votre modèle dans le serveur correctement.

Une fois que votre système exécute ces trois processus de manière fiable, la plupart du travail est fait. Votre modèle simple vous fournit des statistiques et un comportement de base que vous pouvez utiliser pour tester des modèles plus complexes. Certaines équipes visent un premier lancement "neutre", qui fait explicitement passer les gains du machine learning au second plan, pour éviter toute distraction.

Règle n° 5 : testez l'infrastructure indépendamment du machine learning

Assurez-vous que l'infrastructure peut être testée, et que les parties du système consacrées à l'apprentissage sont encapsulées afin que vous puissiez tester tout ce qui les entoure. Plus particulièrement, conduisez les tests suivants :

  1. Testez l'obtention de données dans l'algorithme. Vérifiez que les colonnes de caractéristiques qui doivent être remplies le sont effectivement. Si les règles de confidentialité le permettent, inspectez manuellement l'entrée de votre algorithme d'apprentissage. Si possible, comparez les statistiques dans votre pipeline avec les statistiques pour les mêmes données traitées ailleurs.
  2. Testez l'obtention des modèles en dehors de l'algorithme d'apprentissage. Assurez-vous que le score qu'obtient votre modèle dans l'environnement d'apprentissage est le même que celui qu'il obtient dans l'environnement d'invocation (voir la règle n° 37).

Le machine learning comporte une part d'imprévisibilité. Assurez-vous donc d'avoir à votre disposition des tests pour le code permettant de créer des exemples pour l'apprentissage et l'invocation, et que vous pouvez charger et utiliser un modèle fixe pendant l'invocation. Il est également important que vous compreniez vos données (voir l'article de blog Practical Advice for Analysis of Large, Complex Data Sets, en anglais).

Règle n° 6 : attention aux données perdues lorsque vous copiez des pipelines

Un pipeline est souvent créé en copiant un pipeline existant (c'est-à-dire, culte du cargo), et l'ancien pipeline perd des données dont le nouveau pipeline a besoin. Par exemple, le pipeline pour "Populaire sur Google+" supprime les anciens posts (car il tente de classer les posts récents). Ce pipeline a été copié pour être utilisé avec le flux de Google+, dans lequel les posts plus anciens présentent un intérêt. Or le pipeline supprimait ces posts. Un autre scénario courant est l'enregistrement des données vues par l'utilisateur uniquement. Ces données sont inutiles pour modéliser les raisons pour lesquelles un post particulier n'a pas été vu par l'utilisateur, car tous les exemples négatifs ont été supprimés. Un problème similaire s'est produit dans Google Play. Alors que nous travaillions sur l'accueil du portail d'applications de Google Play, nous avons créé un nouveau pipeline qui contenait également des exemples tirés de la page de destination de Play Jeux sans aucune caractéristique permettant d'identifier d'où venait chaque exemple.

Règle n° 7 : transformez les méthodes heuristiques en caractéristiques, ou gérez-les en externe

Les problèmes que le machine learning tente de résoudre ne sont généralement pas complètement nouveaux. Il existe déjà un système pour le classement ou pour tout autre problème que vous essayez de résoudre. Cela signifie qu'il existe déjà de nombreuses règles et méthodes heuristiques. Ces mêmes méthodes heuristiques peuvent vous donner un coup de pouce si vous les modifiez avec le machine learning. Vous devriez extraire toutes les informations que vos méthodes heuristiques contiennent, et ce pour deux raisons. La première, c'est que cela facilite la transition vers un système de machine learning. La deuxième, c'est que ces règles contiennent généralement de nombreuses intuitions sur le système qu'il est utile de conserver. Vous pouvez utiliser une méthode heuristique existante de quatre façons différentes :

  • Effectuez un pré-traitement en utilisant la méthode heuristique. Si la caractéristique est particulièrement performante, cette solution est tout à fait envisageable. Si, par exemple, dans un filtre anti-spam, l'expéditeur a déjà été mis sur liste noire, n'essayez pas de réapprendre ce que signifie "mis sur liste noire". Bloquez le message. Cette approche est particulièrement bien adaptée aux tâches de classification binaire.
  • Créez une caractéristique. Créer une caractéristique à partir de la méthode heuristique est extrêmement pratique. Par exemple, si vous utilisez une méthode heuristique pour calculer un score de pertinence pour un résultat de recherche, vous pouvez inclure le score en tant que valeur d'une caractéristique. Vous pouvez par la suite utiliser des techniques de machine learning pour maquiller la valeur (par exemple, en convertissant la valeur en un ensemble fini de valeurs discrètes ou en la combinant avec d'autres caractéristiques), mais commencez par utiliser la valeur brute produite par la méthode heuristique.
  • Explorez les entrées brutes de la méthode heuristique. Si vous avez une méthode heuristique dédiée aux applications qui combine le nombre d'installations, le nombre de caractères du texte et le jour de la semaine, séparez ces informations afin de les utiliser comme entrées distinctes du système de machine learning. Certaines techniques qui s'appliquent aux ensembles s'appliquent ici (voir la règle n° 40).
  • Modifiez l'étiquette. Cette solution est possible si vous pensez que la méthode heuristique capture des informations que l'étiquette ne contient actuellement pas. Par exemple, si vous essayez de maximiser le nombre de téléchargements, mais que vous souhaitez également un contenu de qualité, la solution consiste peut-être à multiplier l'étiquette par le nombre moyen d'étoiles attribuées à l'application. La marge de manœuvre est ici considérable. Reportez-vous à la section Votre premier objectif.

Soyez conscient du surcroît de complexité lorsque vous utilisez des méthodes heuristiques dans un système de machine learning. L'utilisation d'anciennes méthodes heuristiques dans votre nouvel algorithme de machine learning peut faciliter la transition, mais demandez-vous s'il existe un moyen plus simple d'arriver au même résultat.

Surveillance

En général, appliquez les bonnes pratiques courantes en matière d'alerte, comme l'utilisation d'alertes interactives et d'une page de tableau de bord.

Règle n° 8 : déterminez les exigences de votre système en matière d'actualisation

À quel point les performances se dégradent-elles si l'âge de votre modèle est d'un jour ? D'une semaine ? D'un trimestre ? Ces informations peuvent vous aider à comprendre les priorités de votre surveillance. Si la perte de qualité au niveau du produit est significative lorsque le modèle n'est pas mis à jour pendant une journée, il est logique d'affecter un ingénieur à sa surveillance continue. La plupart des systèmes de diffusion d'annonces doivent traiter chaque jour de nouvelles annonces, et doivent être mis à jour quotidiennement. Par exemple, si le modèle de machine learning pour la recherche dans Google Play n'est pas mis à jour, cela peut avoir une incidence négative en moins d'un mois. Certains modèles pour "Populaire sur Google+" sont dépourvus d'identifiants de post. Ces modèles sont donc rarement exportés. D'autres modèles dotés d'identifiants de posts sont mis à jour bien plus fréquemment. Notez également que l'actualisation peut changer au fil du temps, en particulier lorsque des colonnes de caractéristiques sont ajoutées ou supprimées de votre modèle.

Règle n° 9 : détectez les problèmes avant d'exporter les modèles

De nombreux systèmes de machine learning comportent une étape d'exportation du modèle pour invocation. S'il y a un problème avec un modèle exporté, c'est un problème pour les utilisateurs.

Évaluez l'intégrité du modèle avant de l'exporter. Plus précisément, assurez-vous que les performances du modèle sont raisonnables sur les données exclues de l'apprentissage. Ou, si vos inquiétudes concernant les données perdurent, n'exportez pas le modèle. Nombre d'équipes déployant en continu des modèles vérifient l'aire sous la courbe ROC (ou AUC) avant d'exporter un modèle. Les problèmes concernant des modèles qui n'ont pas été exportés ne nécessitent qu'une alerte par e-mail, mais ceux qui concernent des modèles auxquels les utilisateurs ont accès peuvent nécessiter l'envoi d'un message sur un pager. Il est donc préférable d'attendre et d'être sûr qu'il n'y a pas de problème, pour éviter tout désagrément pour les utilisateurs.

Règle n° 10 : surveillez les échecs silencieux

Ce problème se pose davantage pour les systèmes de machine learning que pour les autres types de système. Supposons qu'une table jointe particulière ne soit plus mise à jour. Le système de machine learning s'ajustera, et le comportement continuera d'être raisonnablement bon, en se détériorant cependant progressivement. Parfois, certaines tables datent de plusieurs mois, et une simple mise à jour améliore les performances bien plus que toute autre mise en œuvre de correctif le même trimestre. La couverture d'une caractéristique peut changer en raison des modifications apportées à l'implémentation. Par exemple, une colonne de caractéristiques peut être remplie dans 90 % des exemples, chiffre tombant soudainement à 60 % des exemples. Il est un jour arrivé qu'une table de Google Play soit vieille de 6 mois, et qu'une simple actualisation de la table ait permis d'augmenter le taux d'installation de 2 %. Si vous effectuez le suivi des statistiques des données, et que vous inspectez manuellement les données à l'occasion, vous pouvez diminuer ces types d'échecs.

Règle n° 11 : nommez des propriétaires pour les colonnes de caractéristiques et associez une documentation à celles-ci

Si la taille du système est importante, avec de nombreuses colonnes de caractéristiques, vous devez connaître le créateur et le gestionnaire de chacune de ces colonnes. Si vous apprenez le départ de la personne qui comprend une colonne de caractéristiques, assurez-vous que ces connaissances sont transférées à quelqu'un d'autre. Bien que de nombreuses colonnes de caractéristiques portent des noms descriptifs, il est utile d'avoir une description plus détaillée de chaque caractéristique, de leur provenance et de leur utilité.

Votre premier objectif

Vous avez à votre disposition de nombreuses statistiques ou mesures concernant le système qui vous intéresse, mais votre algorithme de machine learning ne nécessite souvent qu'un seul objectif, un nombre que votre algorithme "essaie" d'optimiser. Nous distinguons ici les objectifs et les statistiques : une statistique est un nombre que votre système signale, qui peut ou peut ne pas être important. Reportez-vous également à la règle n° 2.

Règle n° 12 : ne perdez pas des heures à choisir l'objectif à optimiser directement

Vous voulez gagner de l'argent, satisfaire vos utilisateurs et améliorer le monde. Un nombre considérable de statistiques vous intéressent, et vous devriez les mesurer toutes (voir la règle n° 2). Vous constaterez toutefois qu'au début du processus de machine learning, toutes les statistiques augmentent, même celles que vous n'optimisez pas directement. Supposons que vous vous intéressiez au nombre de clics et au temps passé sur votre site. Si vous optimisez le système pour le nombre de clics, il est probable que vous constatiez que le temps passé augmente.

Faites simple et ne réfléchissez pas trop à l'équilibre entre les différentes statistiques, quand que vous pouvez facilement toutes les augmenter. Mais ne poussez pas cette règle à l'extrême. Ne confondez pas votre objectif avec la santé visée du système (voir la règle n° 39). Et, dans le cas où la statistique optimisée directement augmente, mais que vous décidez de ne pas procéder au lancement, une révision de l'objectif peut être nécessaire.

Règle n° 13 : choisissez une statistique simple, observable et imputable comme premier objectif

Souvent, vous ne savez pas quel est le véritable objectif. Vous pensez le savoir, mais si vous examinez les données et l'analyse côte à côte de votre ancien système et de votre nouveau système de machine learning, il se peut que vous décidiez de modifier l'objectif. Il est par ailleurs fréquent que les membres de l'équipe ne soient pas d'accord quant au véritable objectif. L'objectif du machine learning devrait être facile à mesurer et constituer un indicateur du "véritable" objectif. En fait, il n'y a souvent pas de "vrai" objectif (voir la règle n° 39). Réalisez donc l'apprentissage avec l'objectif ML simple, et envisagez de recourir ensuite à une "couche de règles" pour ajouter une logique supplémentaire (de préférence une logique très simple) et procéder au classement final.

Le plus simple à modéliser est un comportement utilisateur directement observé et imputable à une action du système :

  • L'utilisateur a-t-il cliqué sur ce lien classé ?
  • L'utilisateur a-t-il téléchargé cet objet classé ?
  • L'utilisateur a-t-il transmis cet objet classé, y a-t-il répondu, l'a-t-il envoyé par e-mail ?
  • L'utilisateur a-t-il évalué cet objet classé ?
  • L'utilisateur a-t-il marqué cet objet affiché comme spam, à caractère pornographique ou choquant ?

Au début, évitez de modéliser les effets indirects :

  • L'utilisateur a-t-il visité le site le lendemain ?
  • Combien de temps l'utilisateur est-il resté sur le site ?
  • Quel était le nombre d'utilisateurs actifs par jour ?

Les effets indirects constituent d'excellentes statistiques, et peuvent être utilisés lors des tests A/B et des décisions de lancement.

Enfin, n'utilisez pas le machine learning pour essayer répondre à ces questions :

  • L'utilisateur est-il satisfait du produit ?
  • L'utilisateur est-il satisfait de l'expérience ?
  • Le produit améliore-t-il le bien-être général de l'utilisateur ?
  • Comment la santé globale de l'entreprise sera-t-elle impactée ?

Toutes ces informations sont importantes, mais incroyablement difficiles à mesurer. Au lieu de cela, utilisez des indicateurs indirects : si l'utilisateur est satisfait, il va rester plus longtemps sur le site. Si l'utilisateur est satisfait, il reviendra le lendemain. En ce qui concerne le bien-être de l'utilisateur et la santé de l'entreprise, un jugement humain est nécessaire pour relier tout objectif du machine learning à la nature du produit que vous vendez et à votre business plan.

Règle n° 14 : commencer avec un modèle interprétable facilite le débogage

La régression linéaire, la régression logistique et la régression de Poisson reposent directement sur un modèle probabiliste. Chaque prédiction peut être interprétée comme une probabilité ou une valeur attendue. Ces modèles sont ainsi plus simples à déboguer que ceux qui utilisent des objectifs (perte zéro-un, marges maximales diverses, etc.) pour tenter d'optimiser directement la justesse ou les performances du classement. Par exemple, la divergence des probabilités de l'apprentissage par rapport aux probabilités prédites par des analyses côte à côte ou en inspectant le système de production peut être révélatrice d'un problème.

Par exemple, les régressions linéaire, logistique et de Poisson comportent des sous-ensembles de données dans lesquels l'espérance prédite moyenne est égale à l'étiquette moyenne (étalonnée sur un moment, ou simplement étalonnée). Cela est vrai s'il n'y a pas de régularisation et que votre algorithme a convergé, et cela est relativement vrai en général. Si la valeur de l'une de vos caractéristiques est égale à 1 ou 0 pour chaque exemple, l'ensemble de 3 exemples pour lesquels cette caractéristique est égale à 1 est étalonné. De plus, si la valeur de l'une de vos caractéristiques est égale à 1 pour chaque exemple, l'ensemble de tous les exemples est étalonné.

Les modèles simples facilitent la gestion des boucles de rétroaction (voir la règle n° 36). Ces prédictions probabilistes servent souvent à prendre une décision, et par exemple à classer des articles par ordre décroissant de valeur attendue (c'est-à-dire, par probabilité de clic, téléchargement, etc.). N'oubliez toutefois pas que, lorsque vous devrez choisir le modèle à utiliser, la décision est plus importante que la probabilité des données pour le modèle (voir la règle n° 27).

Règle n° 15 : séparez le filtrage anti-spam et le classement qualitatif dans une couche de règles

Le classement qualitatif est un art, et le filtrage anti-spam une guerre. Les utilisateurs de votre système finiront par comprendre les signaux que vous utilisez pour déterminer les posts de haute qualité, et ils modifieront leurs posts pour que ceux-ci présentent ces propriétés. Votre classement qualitatif doit de ce fait se concentrer sur le classement du contenu publié de bonne foi. Vous ne devriez pas pénaliser un modèle apprenant à classer des posts selon leur qualité pour avoir classé du spam comme un post de qualité. De même, le contenu pour adulte doit être traité séparément du classement qualitatif. Le filtrage anti-spam est une histoire encore différente. Attendez-vous à ce que les caractéristiques à générer évoluent constamment. Vous devez généralement inclure dans votre système certaines règles évidentes (ne pas récupérer un post qui a plus de trois votes "spam", etc.). Tout modèle entraîné devra être mis à jour quotidiennement, voire plus fréquemment. La réputation du créateur du contenu jouera un grand rôle.

À un certain niveau, le résultat de ces deux systèmes devra être intégré. Gardez à l'esprit que le filtrage du spam dans les résultats de recherche doit être probablement plus agressif que le filtrage du spam dans les e-mails. Cela est vrai s'il n'y a pas de régularisation et que votre algorithme a convergé. Cela est relativement vrai en général. De plus, il est courant de supprimer le spam des données d'apprentissage pour le classificateur qualitatif.

Phase II du machine learning : Extraction de caractéristiques

Dans la première phase du cycle de vie d'un système de machine learning, les problèmes majeurs sont l'intégration des données d'apprentissage dans le système, la mise en place d'instruments de mesure des statistiques d'intérêt et la création d'une infrastructure d'invocation. Une fois que vous avez un système de bout en bout opérationnel, doté d'instruments des tests unitaires et des tests système, la phase II peut commencer.

Cette deuxième phase comporte de nombreuses opportunités faciles à saisir. Quantité de caractéristiques évidentes peuvent être intégrées au système. La seconde phase du machine learning implique donc l'intégration d'autant de caractéristiques que possible et leur combinaison intuitive. Au cours de cette phase, toutes les statistiques devraient continuer à augmenter, et les lancements seront nombreux. C'est le moment idéal pour rassembler un grand nombre d'ingénieurs et collecter toutes les données nécessaires afin de créer un système d'apprentissage vraiment efficace.

Règle n° 16 : planifiez le lancement et itérez

Ne croyez pas que le modèle sur lequel vous travaillez actuellement sera le dernier que vous lancerez, ni même que vous cesserez de lancer des modèles. Demandez-vous si la complexité que vous ajoutez avec ce lancement ralentira les lancements futurs. De nombreuses équipes ont lancé un modèle au moins une fois par trimestre pendant des années. Il y a trois raisons fondamentales au lancement de nouveaux modèles :

  • Vous trouvez de nouvelles caractéristiques.
  • Vous ajustez la régularisation et combinez d'anciennes caractéristiques d'une nouvelle manière.
  • Vous ajustez l'objectif.

Quoi qu'il en soit, prendre soin d'un modèle peut être une bonne chose : l'examen des données qui alimentent l'exemple peut aider à déceler de nouveaux signaux ainsi que de vieux signaux devenus inefficaces. Lorsque vous créez votre modèle, réfléchissez à la facilité d'ajouter, de supprimer ou de recombiner des caractéristiques. Réfléchissez à la facilité de créer une nouvelle copie du pipeline et de vérifier son exactitude. Réfléchissez à la possibilité ou non d'avoir deux ou trois copies en parallèle. Enfin, ne vous inquiétez pas si la caractéristique 16 sur 35 ne peut pas être intégrée dans cette version du pipeline. Elle le sera le trimestre suivant.

Règle n° 17 : commencez avec des caractéristiques rapportées et observées directement, plutôt qu'avec des caractéristiques apprises

Il s'agit d'un point controversé, qui pourtant vous évitera de nombreux problèmes. Voyons d'abord ce qu'est une caractéristique apprise. Une caractéristique apprise est une caractéristique générée soit par un système externe (tel qu'un système de clustering non supervisé), soit par le système apprenant lui-même (par exemple, via un modèle factorisé ou de deep learning). Bien qu'utiles, ces deux méthodes posent de nombreux problèmes. Elles ne doivent donc pas être incluses dans le premier modèle.

Si vous utilisez un système externe pour créer une caractéristique, n'oubliez pas que celui-ci a son propre objectif, qui peut n'être que faiblement corrélé avec votre objectif actuel. Si vous capturez un instantané du système externe, il peut devenir obsolète. Si vous mettez à jour les caractéristiques à partir du système externe, les significations peuvent changer. Si vous utilisez un système externe pour fournir une caractéristique, sachez que cette approche nécessite beaucoup de travail.

Le principal problème des modèles factorisés et des modèles profonds est qu'ils ne sont pas convexes. Il n'y a donc aucune garantie qu'une solution optimale puisse être approchée ou trouvée, et les minimums locaux trouvés à chaque itération peuvent être différents. Cette variation ne permet pas de déterminer facilement si l'impact d'une modification de votre système est significatif ou aléatoire. La création d'un modèle sans caractéristiques profondes vous permet d'obtenir une excellente performance de base. Une fois cette référence obtenue, vous pouvez essayer des approches plus originales.

Règle n° 18 : faites des essais avec des caractéristiques de contenu généralisables à différents contextes

Un système de machine learning ne constitue souvent qu'une petite partie d'un système beaucoup plus large. Supposons un post susceptible de s'afficher dans "Populaire sur Google+". De nombreuses personnes lui attribueront +1, le partageront ou le commenteront avant même qu'il ne s'y affiche. Si vous fournissez ces statistiques au système apprenant, celui-ci peut promouvoir de nouveaux posts pour lesquels il ne possède aucune donnée dans le contexte qu'il optimise. La fonctionnalité "Vidéos à regarder ensuite" de YouTube peut utiliser un certain nombre de lectures, ou de lectures conjointes (nombre de fois où une vidéo a été visionnée après une autre) issues de la recherche YouTube. Vous pouvez également utiliser les notes des visiteurs explicites. Enfin, si vous utilisez comme étiquette une action des internautes, la présence de cette action dans le document, dans un contexte différent, peut être une excellente caractéristique. Toutes ces fonctionnalités vous permettent d'intégrer un contenu nouveau dans le contexte. Notez qu'il ne s'agit pas là de personnalisation. Vous devez d'abord déterminer si une personne aime le contenu dans ce contexte avant de déterminer qui l'aime plus ou moins.

Règle n° 19 : dans la mesure du possible, utilisez des caractéristiques très spécifiques

Lorsque l'on dispose d'une quantité considérable de données, il est plus facile d'apprendre des millions de caractéristiques simples plutôt qu'un nombre restreint de caractéristiques complexes. Les identifiants des documents récupérés et les requêtes canoniques n'offrent pas vraiment d'informations utiles à des fins de généralisation, mais alignent votre classement avec vos étiquettes sur les requêtes principales. N'hésitez donc pas à utiliser des groupes de caractéristiques où chaque caractéristique s'applique à une fraction très limitée de vos données, mais dont la couverture globale est supérieure à 90 %. Vous pouvez procéder à une régularisation pour éliminer les caractéristiques qui s'appliquent à trop peu d'exemples.

Règle n° 20 : combinez et modifiez les caractéristiques existantes pour en créer de nouvelles de manière compréhensible par l'être humain

Il existe de nombreuses façons de combiner et de modifier des caractéristiques. Les systèmes de machine learning tels que TensorFlow vous permettent de prétraiter vos données au moyen de transformations. Les deux approches les plus courantes sont la "discrétisation" et le "croisement".

La discrétisation consiste à créer de nombreuses caractéristiques discrètes à partir d'une caractéristique continue. Supposons une caractéristique continue, comme l'âge. Vous pouvez créer une caractéristique égale à 1 quand l'âge est inférieur à 18 ans, une autre caractéristique égale à 1 quand l'âge est compris entre 18 et 35 ans, etc. Ne passez pas trop de temps à réfléchir aux limites de ces histogrammes : ce sont les quantiles de base qui vous indiqueront l'essentiel de l'impact.

Le croisement consiste à combiner au moins deux colonnes de caractéristiques. Une colonne de caractéristiques, dans TensorFlow, est un ensemble de caractéristiques homogènes (par exemple {homme, femme}, {États-Unis, Canada, Mexique}, etc.). Un croisement est une nouvelle colonne de caractéristiques du type {homme, femme} × {États-Unis, Canada, Mexique}. Cette nouvelle colonne contiendra la caractéristique (homme, Canada). Si vous utilisez TensorFlow et que vous lui demandez de créer ce croisement, la caractéristique (homme, Canada) sera présente dans les exemples représentant des hommes canadiens. Notez qu'une quantité considérable de données est nécessaire pour entraîner des modèles avec des croisements de plus de trois colonnes de caractéristiques de base.

Un surapprentissage est possible si le croisement produit de très grandes colonnes de caractéristiques. Supposons que vous effectuiez une recherche et que vous ayez une colonne de caractéristiques avec des mots dans la requête, et une autre avec des mots dans le document. Si vous les croisez, vous allez vous retrouver avec un grand nombre de caractéristiques (voir la règle n° 21).

Lorsque vous travaillez avec du texte, vous avez deux possibilités. La méthode la plus draconienne consiste à appliquer un produit scalaire. Dans sa forme la plus simple, un produit scalaire compte simplement le nombre de mots en commun entre la requête et le document. Cette caractéristique peut ensuite être discrétisée. Une autre approche est le recoupement : ainsi, une caractéristique est présente si et seulement si le mot "poney" se trouve à la fois dans le document et dans la requête, et une autre caractéristique est présente si et seulement si le mot "le" se trouve à la fois dans le document et dans la requête.

Règle n° 21 : le nombre de pondérations de caractéristiques qui peuvent être apprises dans un modèle linéaire est à peu près proportionnel au volume de données

Les résultats de la théorie sur l'apprentissage statistique concernant le niveau de complexité approprié d'un modèle sont fascinants, mais cette règle constitue l'essentiel de ce que vous devez savoir. J'ai discuté avec des personnes qui doutaient qu'il soit possible d'apprendre quoi que ce soit à partir d'un millier d'exemples, ou que plus d'un million d'exemples soient nécessaires, car elles restaient bloquées sur une certaine méthode d'apprentissage. La clé consiste à adapter l'apprentissage au volume de données :

  1. Si vous travaillez sur un système de classement de recherches, qu'il existe des millions de mots différents dans les documents et la requête, et que vous disposez de 1 000 exemples étiquetés, vous devez utiliser un produit scalaire entre les caractéristiques de document et de requête, le TF-IDF et une demi-douzaine d'autres caractéristiques conçues par l'homme. Mille exemples, une douzaine de caractéristiques.
  2. Si vous disposez d'un million d'exemples, croisez les colonnes de caractéristiques de document et de requête, en utilisant la régularisation et éventuellement la sélection de caractéristiques. Vous obtiendrez alors des millions de caractéristiques, nombre qui sera réduit grâce à la régularisation. Dix millions d'exemples, peut-être une centaine de milliers de caractéristiques.
  3. Si vous disposez de milliards ou de centaines de milliards d'exemples, vous pouvez croiser les colonnes de caractéristiques avec des identifiants de document et de requête, en utilisant la régularisation et la sélection des caractéristiques. Vous aurez un milliard d'exemples, et 10 millions de caractéristiques. La théorie de l'apprentissage statistique donne rarement des limites strictes, mais offre d'excellents conseils pour commencer.

Pour terminer, suivez la règle n° 28 pour décider des caractéristiques à utiliser.

Règle n° 22 : supprimez les caractéristiques inutilisées

Les caractéristiques inutilisées créent une dette technique. Si vous constatez que vous n'utilisez pas une certaine caractéristique, et que la combiner avec d'autres caractéristiques ne fonctionne pas, supprimez-la de votre infrastructure. Vous devez vous assurer que votre infrastructure reste propre afin que les caractéristiques les plus prometteuses puissent être testées le plus rapidement possible. Si nécessaire, on peut toujours rajouter cette caractéristique.

Lorsque vous décidez des caractéristiques à ajouter ou à conserver, pensez bien à la couverture de celles-ci. Combien d'exemples couvrent-elles ? Par exemple, si vous disposez de caractéristiques de personnalisation, mais que seulement 8 % de vos utilisateurs présentent de telles caractéristiques, ce n'est pas très efficace.

Parallèlement, certaines caractéristiques peuvent être particulièrement performantes. Par exemple, si l'une de vos caractéristiques ne couvre que 1 % des données, mais que 90 % des exemples ayant cette caractéristique sont positifs, alors il est extrêmement intéressant d'ajouter cette caractéristique.

Analyse humaine du système

Avant de passer à la troisième phase du machine learning, il est important de se pencher sur quelque chose qui n'est enseigné dans aucun cours sur le machine learning : comment examiner un modèle existant et l'améliorer. Bien que ce soit davantage un art qu'une science, il y a quelques écueils à éviter.

Règle n° 23 : vous n'êtes pas un utilisateur final typique

C'est peut-être le moyen le plus sûr pour une équipe de s'enliser. Bien que le fishfooding (utilisation d'un prototype au sein de votre équipe) et le dogfooding (utilisation d'un prototype au sein de votre entreprise) présentent de nombreux avantages, les employés doivent s'assurer que les performances sont correctes. Une modification à l'évidence mauvaise ne doit bien sûr pas être utilisée. Tout ce qui s'approche raisonnablement de la production doit être davantage testé, soit en payant des non-spécialistes pour répondre aux questions sur une plate-forme de crowdsourcing, soit en expérimentant en direct avec des utilisateurs réels.

Il y a deux raisons à cela. La première est que vous êtes trop proche du code. Vous recherchez peut-être un aspect particulier des posts, ou vous êtes simplement trop impliqué émotionnellement (par exemple, biais de confirmation). La deuxième raison est que votre temps est trop précieux. Réfléchissez au nombre d'étiquettes humaines sous contrat que vous pourriez acheter sur une plate-forme de crowdsourcing pour le coût de neuf ingénieurs assistant à une réunion d'une heure.

Si vous avez vraiment besoin des commentaires des utilisateurs, utilisez des méthodologies d'expérience utilisateur. Créez des personnages (vous trouverez une description dans le livre de Bill Buxton, Sketching User Experiences, en anglais) au début du processus, et testez la facilité d'utilisation (voir le livre de Steve Krug, Don't make me think, en anglais) plus tard. La création de personnages consiste à définir des utilisateurs hypothétiques. Par exemple, si votre équipe est composée uniquement d'hommes, il peut être utile de concevoir le personnage d'une utilisatrice de 35 ans (avec les caractéristiques utilisateur adéquates), et d'examiner les résultats qu'il génère plutôt que les 10 résultats pour des hommes de 25 à 40 ans. Le recours à des personnes réelles utilisant votre site (localement ou à distance) pour observer leur réaction lorsque vous en testez la facilité d'utilisation peut également vous offrir de nouvelles perspectives.

Règle n° 24 : mesurez le delta entre les modèles

L'une des mesures les plus simples et parfois les plus utiles que vous puissiez appliquer avant que les utilisateurs ne regardent votre nouveau modèle consiste à calculer la divergence entre les nouveaux résultats et la production. Par exemple, dans le cas d'un problème de classement, exécutez les deux modèles sur un échantillon de requêtes dans le système complet, puis observez l'ampleur de la différence symétrique des résultats (pondérée en fonction de la position dans le classement). Si la différence est très faible, vous pouvez conclure, sans effectuer de tests, qu'il y aura peu de changements. Si la différence est au contraire importante, vous devez vous assurer que le changement est positif. Examiner les requêtes pour lesquelles la différence symétrique est élevée peut vous aider à comprendre le changement d'un point de vue qualitatif. Assurez-vous toutefois que le système est stable, et qu'un modèle, comparé à lui-même, présente une différence symétrique faible (idéalement nulle).

Règle n° 25 : lorsque vous choisissez des modèles, les performances utilitaires l'emportent sur la puissance prédictive

Supposons que votre modèle essaie de prédire le taux de clics. Au final, la question fondamentale est de savoir que faire de cette prédiction. Si vous l'utilisez pour classer des documents, la qualité du classement final importe plus que la prédiction elle-même. Si vous prédisez la probabilité qu'un document soit du spam et que vous avez une limite pour les éléments bloqués, alors la précision de ce qui est autorisé à passer le filtre est ce qui compte le plus. La plupart du temps, ces deux facettes doivent être en phase. Si ce n'est pas le cas, le gain sera probablement faible. Ainsi, si certains changements améliorent la perte logistique, mais dégradent les performances du système, cherchez une autre caractéristique. Si cela se produit fréquemment, il est temps de revoir l'objectif de votre modèle.

Règle n° 26 : recherchez les schémas dans les erreurs mesurées, et créez de nouvelles caractéristiques

Supposons que vous trouviez un exemple d'apprentissage dont la sortie du modèle est incorrecte. Dans une tâche de classification, cette erreur peut être un faux positif ou un faux négatif. Dans une tâche de classement, l'erreur peut être une paire dans laquelle un positif était classé à un rang inférieur à celui d'un négatif. Le plus important est que le système de machine learning sache que sa sortie est incorrecte pour l'exemple, et qu'il puisse corriger cela s'il en a l'occasion. Si vous donnez au modèle une caractéristique qui lui permet de corriger l'erreur, il essaiera de l'utiliser.

D'un autre côté, si vous essayez de créer une caractéristique basée sur des exemples que le système ne considère pas comme des erreurs, la caractéristique sera ignorée. Supposons qu'un internaute recherche des applications en saisissant les termes "jeux gratuits" dans Google Play. Supposons également que l'un des meilleurs résultats soit une application gag peu pertinente. Vous créez donc une caractéristique pour "applications gag". Toutefois, si vous optimisez le nombre d'installations et que les utilisateurs installent une application gag lorsqu'ils recherchent des jeux gratuits, la caractéristique "applications gag" n'aura pas l'effet escompté.

Une fois que vous disposez d'exemples dont les sorties du modèle sont incorrectes, vous pouvez rechercher les tendances qui ne correspondent pas à votre ensemble de caractéristiques actuel. Par exemple, si le système semble rétrograder les articles longs, ajoutez la longueur de l'article comme caractéristique. Ne soyez pas trop précis quant aux caractéristiques que vous ajoutez. Si vous ajoutez la longueur des articles comme caractéristique, n'essayez pas de deviner ce qui signifie "long". Ajoutez simplement une douzaine de caractéristiques, et laissez le modèle décider de ce qu'il doit en faire (voir la règle n° 21). C'est la façon la plus simple d'obtenir ce que vous voulez.

Règle n° 27 : essayez de quantifier le comportement indésirable observé

Certains membres de votre équipe commenceront à se sentir frustrés par les propriétés du système qu'ils n'aiment pas et qui ne sont pas capturées par la fonction de perte existante. À ce stade, ils doivent faire tout ce qui est en leur pouvoir pour transformer leurs griefs en chiffres solides. Par exemple, s'ils pensent que trop d'"applications gag" s'affichent dans la recherche Google Play, ils peuvent demander aux évaluateurs humains d'identifier ces applications. Dans ce cas, vous pouvez utiliser des données étiquetées par des humains, car une fraction relativement faible des requêtes représente une grande partie du trafic. Si vos problèmes sont mesurables, vous pouvez commencer à les utiliser comme caractéristiques, objectifs ou statistiques. La règle générale est : mesurer d'abord, optimiser ensuite.

Règle n° 28 : des comportements à court terme identiques n'impliquent pas des comportements à long terme identiques

Imaginez que vous ayez un nouveau système qui examine chaque doc_id et exact_query, puis calcule la probabilité de clic pour chaque document et pour chaque requête. Vous constatez que son comportement est pratiquement le même que celui de votre système actuel, tant au niveau du test A/B que de l'analyse côte à côte. Étant donné sa simplicité, vous décidez de le lancer. Vous remarquez toutefois qu'aucune nouvelle application ne s'affiche. Pourquoi ? Puisque votre système n'affiche un document que sur la base de son propre historique avec cette requête, il n'a aucun moyen d'apprendre qu'un nouveau document doit être affiché.

Le seul moyen de comprendre le fonctionnement à long terme d'un tel système est de ne l'entraîner que sur des données acquises lorsque le modèle était en ligne, ce qui est très difficile.

Biais d'apprentissage/invocation

Le biais d'apprentissage/invocation est la différence entre les performances pendant l'apprentissage et pendant l'invocation. Les raisons de ce biais sont multiples :

  • Une différence dans la façon dont vous gérez les données dans les pipelines d'apprentissage et d'invocation.
  • Un changement au niveau des données entre le moment de l'apprentissage et le moment de l'invocation.
  • Une boucle de rétroaction entre votre modèle et votre algorithme.

Nous avons constaté chez Google des systèmes de machine learning en production présentant un biais d'apprentissage/invocation ayant un impact négatif sur les performances. La meilleure solution consiste à surveiller explicitement ce biais, afin que les changements qui affectent le système et les données n'introduisent pas un biais qui passerait inaperçu.

Règle n° 29 : la meilleure façon de vous assurer que l'apprentissage et l'invocation se passent de la même manière consiste à sauvegarder l'ensemble de caractéristiques utilisé lors de l'invocation, puis à transférer ces caractéristiques dans un journal pour les utiliser lors de l'apprentissage

Même si vous ne pouvez pas le faire pour chaque exemple, faites-le pour une petite partie d'entre eux, afin d'être en mesure de vérifier la cohérence entre l'invocation et l'apprentissage (voir la règle n° 37). Les équipes qui ont effectué cette mesure chez Google ont parfois été surprises des résultats. Pour la page d'accueil de YouTube, nous sommes passés à la consignation des caractéristiques lors de l'invocation, et avons constaté des améliorations significatives de la qualité ainsi qu'une réduction de la complexité du code, et de nombreuses équipes basculent en ce moment leur infrastructure.

Règle n° 30 : pondérez les données échantillonnées selon leur importance ; ne les supprimez pas arbitrairement !

Si vous avez un trop grand nombre de données, vous pouvez être tenté de n'utiliser, par exemple, que les fichiers 1 à 12 et d'ignorer les fichiers 13 à 99. Mais c'est une erreur. Les données qui n'ont jamais été montrées à l'utilisateur peuvent être supprimées, mais dans tous les autres cas, la pondération selon l'importance est la meilleure approche à suivre. Par exemple, si vous décidez d'échantillonner l'exemple X avec une probabilité de 30 %, vous devez lui attribuer une pondération de 10/3. Toutes les propriétés de calibration discutées dans la règle n° 14 restent valables dans la pondération selon l'importance.

Règle n° 31 : n'oubliez pas que les données d'une table que vous joignez lors de l'apprentissage et de l'invocation peuvent changer

Supposons que vous joignez les identifiants de document d'une table contenant des caractéristiques pour ces documents (par exemple, le nombre de commentaires ou de clics). Entre l'apprentissage et l'invocation, les caractéristiques contenues dans la table peuvent changer. La prédiction de votre modèle pour le même document différera alors entre l'apprentissage et l'invocation. Le moyen le plus simple d'éviter ce genre de problème consiste à consigner les caractéristiques au moment de l'invocation (voir la règle n° 32). Si la table ne change que lentement, vous pouvez aussi prendre un instantané de la table toutes les heures ou tous les jours pour obtenir des données raisonnablement proches. Notez que cela ne résout pas complètement le problème.

Règle n° 32 : dans la mesure du possible, utilisez le même code dans vos pipelines d'apprentissage et d'invocation

Le traitement par lot est un processus différent du traitement en ligne. Dans le traitement en ligne, vous devez gérer chaque requête au moment où elle arrive (par exemple, vous devez effectuer une recherche séparée pour chaque requête), tandis que dans le traitement par lot, vous pouvez combiner les tâches (par exemple, réaliser une jointure). Lors de l'invocation, vous procédez à un traitement en ligne, tandis que l'apprentissage est un traitement par lot. Il y a cependant certaines opérations que vous pouvez réaliser afin de réutiliser le code. Vous pouvez, par exemple, créer un objet propre à votre système, dans lequel le résultat d'une requête ou d'une jointure peut être stocké de manière très lisible par l'homme et les erreurs testées facilement. Ensuite, une fois que vous avez rassemblé toutes les informations, pendant l'invocation ou l'apprentissage, vous exécutez une méthode commune pour faire le lien entre l'objet lisible propre à votre système et le format attendu par le système de machine learning. Cette méthode élimine une source de biais d'apprentissage/invocation. Cela implique de ne pas utiliser deux langages de programmation différents pour l'apprentissage et l'invocation. Faute de quoi il vous sera pratiquement impossible de partager le code.

Règle n° 33 : si vous produisez un modèle basé sur des données jusqu'au 5 janvier, testez-le sur les données à partir du 6 janvier

En règle générale, mesurez les performances d'un modèle sur des données collectées après celles sur lesquelles vous l'avez entraîné, car cela reflète mieux le fonctionnement de votre système en production. Si vous produisez un modèle basé sur des données jusqu'au 5 janvier, testez-le sur les données à partir du 6 janvier. Les performances ne devraient pas être aussi bonnes, mais pas vraiment mauvaises non plus. Des effets quotidiens étant possibles, il se peut que vous ne puissiez pas prédire le taux de clics ou le taux de conversion moyens. Toutefois, l'aire sous la courbe, qui représente la probabilité d'attribuer à l'exemple positif un score supérieur à un exemple négatif, devrait représenter une approximation raisonnable.

Règle n° 34 : dans la classification binaire à des fins de filtrage (détection de spam ou détermination d'e-mails intéressants, par exemple), acceptez des petits sacrifices à court terme au niveau des performances pour obtenir des données très propres

Dans une tâche de filtrage, les exemples marqués comme négatifs ne sont pas montrés à l'utilisateur. Supposons que vous ayez un filtre qui bloque 75 % des exemples négatifs lors de l'invocation. Vous pourriez être tenté de tirer des données d'apprentissage supplémentaires à partir des instances présentées aux utilisateurs. Par exemple, si un utilisateur marque comme spam un e-mail que votre filtre a laissé passer, vous pourriez décider d'utiliser cette information.

Toutefois, cette approche introduit un biais d'échantillonnage. Vous pouvez collecter des données plus propres si, au lieu de cela, au cours de l'invocation, vous étiquetez 1 % de tout le trafic comme "exclu" et que vous transmettez tous les exemples bloqués à l'utilisateur. Votre filtre bloque à présent au moins 74 % des exemples négatifs. Ces exemples exclus peuvent devenir vos données d'apprentissage.

Notez que si votre filtre bloque 95 % des exemples négatifs ou plus, cette approche devient moins viable. Néanmoins, si vous souhaitez mesurer les performances de l'invocation, vous pouvez prendre un échantillon encore plus petit (par exemple, 0,1 % ou 0,001 %). Dix mille exemples suffisent pour estimer les performances de manière assez précise.

Règle n° 35 : attention au biais inhérent aux problèmes de classement

Si vous modifiez votre algorithme de classement de manière suffisamment substantielle pour qu'il génère des résultats différents, vous avez dans les faits modifié les données que votre algorithme verra à l'avenir. Ce type de biais apparaîtra, et vous devriez concevoir votre modèle autour de cela. Vous pouvez suivre pour cela différentes approches, qui toutes consistent à favoriser les données que votre modèle a déjà vues.

  1. Régularisez davantage les caractéristiques qui couvrent un grand nombre de requêtes plutôt que de celles qui n'en couvrent qu'une. Le modèle privilégiera ainsi les caractéristiques propres à une ou plusieurs requêtes par rapport aux caractéristiques généralisables à toutes les requêtes. Cette approche peut aider à empêcher les résultats très populaires d'apparaître dans des requêtes non pertinentes. Notez que cette approche est contraire au conseil plus conventionnel selon lequel vous devez davantage régulariser les colonnes de caractéristiques ayant un plus grand nombre de valeurs uniques.
  2. Autorisez les caractéristiques à n'avoir que des pondérations positives. Ainsi, toute "bonne" caractéristique sera meilleure qu'une caractéristique "inconnue".
  3. N'utilisez pas de caractéristiques de document uniquement. Cette approche est une version extrême de la première approche. Par exemple, même si une application donnée est populaire et téléchargée fréquemment quelle que soit la requête, vous ne voulez pas qu'elle s'affiche partout. L'absence de caractéristiques de document uniquement simplifie les choses. La raison pour laquelle vous ne devez pas afficher une application populaire particulière partout est liée à l'importance de rendre toutes les applications souhaitées accessibles. Par exemple, si un internaute recherche une "application d'observation d'oiseaux", il peut se retrouver à télécharger "angry birds", ce qui n'était certainement pas son intention. Présenter une telle application peut certes améliorer le taux de téléchargement, mais ne répond pas aux besoins de l'utilisateur.

Règle n° 36 : évitez les boucles de rétroaction avec des caractéristiques de position

La position du contenu a une influence considérable sur la probabilité que l'utilisateur interagisse avec lui. Si vous placez une application en première position, les internautes cliqueront plus fréquemment sur celle-ci, et vous aurez la conviction que la probabilité que les internautes cliquent dessus est élevée. Pour résoudre ce problème, vous pouvez ajouter des caractéristiques de position, c'est-à-dire des caractéristiques sur la position du contenu dans la page. Vous entraînez votre modèle avec ce type de caractéristique, et il apprend à pondérer fortement, par exemple, la caractéristique "1re position". Votre modèle donne donc une importance moindre aux autres facteurs pour les exemples pour lesquels "1re position=vrai". Ensuite, lors de l'invocation, vous ne donnez la caractéristique de position à aucune instance, ou vous donnez à toutes les instances la même caractéristique par défaut, car vous notez les candidats avant de décider de l'ordre dans lequel les afficher.

Notez qu'il est important que les caractéristiques de position soient quelque peu séparées du reste du modèle, en raison de l'asymétrie entre l'apprentissage et le test. Le fait que le modèle soit la somme d'une fonction des caractéristiques de position et d'une fonction du reste des caractéristiques est parfait. Par exemple, ne croisez pas les caractéristiques de position avec une caractéristique de document.

Règle n° 37 : mesurez le biais d'apprentissage/invocation

De manière générale, plusieurs phénomènes peuvent être à l'origine de ce biais, qui peut se diviser en plusieurs parties :

  • Différence entre les performances sur les données d'apprentissage et les données exclues. Ce biais existe généralement toujours, et n'est pas forcément une mauvaise chose.
  • Différence entre les performances sur les données exclues et les données "du jour suivant". Encore une fois, ce biais existe toujours. Vous devez ajuster votre régularisation afin de maximiser les performances du jour suivant. Toutefois, une dégradation sévère des performances entre les données exclues et les données du jour suivant peut indiquer que certaines caractéristiques sont sensibles au facteur temps et dégradent les performances du modèle.
  • Différence entre les performances sur les données "du jour suivant" et les données en direct. Si vous appliquez un modèle à un exemple dans les données d'apprentissage, et au même exemple lors de l'invocation, vous devriez obtenir exactement le même résultat (voir la règle n° 5). Si ce n'est pas le cas, c'est qu'il y a probablement une erreur d'ingénierie.

Phase III du machine learning : Ralentissement de la croissance, ajustement de l'optimisation et modèles complexes

Certains signes indiquent que la deuxième phase touche à sa fin. Tout d'abord, vos gains mensuels commencent à diminuer. Vous commencez à constater des compromis entre les statistiques : certaines augmentent alors que d'autres diminuent dans certains tests. C'est là que les choses deviennent intéressantes. Puisque les gains sont plus difficiles à obtenir, le machine learning doit devenir plus sophistiqué. Attention, cependant : cette section contient davantage de règles ouvertes que les sections précédentes. De nombreuses équipes traversent sans encombre les phases I et II du machine learning. Mais une fois la phase III atteinte, elles doivent trouver leur propre voie.

Règle n° 38 : ne perdez pas de temps avec de nouvelles caractéristiques si des objectifs non alignés sont devenus un problème

Lorsque vos statistiques arrivent à un plateau, votre équipe doit commencer à examiner les problèmes qui sortent du cadre des objectifs de votre système de machine learning actuel. Comme indiqué précédemment, si les objectifs du produit ne sont pas couverts par l'objectif algorithmique existant, vous devez modifier soit votre objectif, soit les objectifs de votre produit. Vous pouvez, par exemple, optimiser les clics, les +1 ou les téléchargements, mais prendre des décisions de lancement basées en partie sur des évaluateurs humains.

Règle n° 39 : les décisions de lancement sont un indicateur des objectifs à long terme du produit

Alice a une idée pour réduire la perte logistique de la prédiction des installations. Elle ajoute une caractéristique. La perte logistique chute. Quand elle réalise un test en direct, elle constate que le taux d'installation augmente. Cependant, lorsqu'elle se rend à une réunion d'évaluation du lancement, l'un des participants signale que le nombre d'utilisateurs actifs par jour baisse de 5 %. L'équipe décide de ne pas lancer le modèle. Alice est déçue, mais réalise que les décisions de lancement dépendent de nombreux critères, dont seulement certains peuvent être optimisés directement à l'aide du machine learning.

Le monde réel n'est pas une partie de Donjons et dragons. Il n'y a pas de "points de vie" permettant de connaître l'état de santé de votre produit. L'équipe doit se servir des statistiques qu'elle recueille pour tenter de prédire de façon efficace la qualité du système à l'avenir. Elle doit prendre en compte l'engagement, les utilisateurs actifs sur 1 jour (DAU) et 30 jours, les revenus et du le retour sur investissement pour l'annonceur. Ces statistiques, qui sont mesurables dans les tests A/B, ne sont en elles-mêmes que des indicateurs des objectifs à plus long terme (satisfaction des utilisateurs, augmentation du nombre d'utilisateurs, satisfaction des partenaires, bénéfices, etc.), que vous pouvez considérer comme des indicateurs de l'utilité et de la qualité d'un produit, et de la pérennité de l'entreprise à cinq ans.

Ce n'est que lorsque toutes les statistiques s'améliorent, ou au moins ne se dégradent pas, que les décisions de lancement sont faciles à prendre. Si l'équipe a le choix entre un algorithme de machine learning sophistiqué et une méthode heuristique simple, et que cette dernière est plus performante pour toutes les statistiques, elle doit opter pour la méthode heuristique. De plus, il n'existe pas de classement explicite de toutes les valeurs possibles des statistiques. Pour mieux comprendre cela, examinons les deux scénarios suivants :

Test Nombre d'utilisateurs actifs par jour Revenus par jour
A 1 million 4 millions USD
B 2 millions 2 millions USD

Si le système actuel est le système A, il est peu probable que l'équipe opte pour le système B, et inversement. Cela semble incompatible avec un comportement rationnel. Toutefois, les prédictions suite à un changement de statistique peuvent ou non se réaliser, et un risque important est donc associé à l'un ou l'autre des changements. Chaque statistique implique un certain risque contre lequel l'équipe souhaite se prémunir.

De plus, aucune statistique ne couvre la préoccupation ultime de l'équipe, à savoir "où en sera produit dans cinq ans" ?

En revanche, les individus tendent à favoriser un objectif qu'ils sont en mesure d'optimiser directement. La plupart des outils de machine learning favorisent un tel environnement. Dans un tel environnement, un ingénieur qui introduit de nouvelles caractéristiques peut créer un flux régulier de lancements. Il existe un type de machine learning, appelé apprentissage multi-objectif, qui commence à s'attaquer à ce problème. Il est par exemple possible de formuler un problème de satisfaction de contraintes avec des limites inférieures pour chaque statistique, et qui optimise une combinaison linéaire de statistiques. Cependant, même dans ce cas, toutes les statistiques ne peuvent être facilement définies comme objectifs du machine learning : si un internaute clique sur un document ou installe une application, c'est parce que ce contenu était affiché. Il est néanmoins beaucoup plus difficile de comprendre pourquoi un utilisateur visite votre site. La question de la prédiction du succès global d'un site est IA-complet, aussi complexe que la vision par ordinateur ou le traitement du langage naturel.

Règle n° 40 : utilisez des ensembles simples

Les modèles unifiés qui intègrent des caractéristiques brutes et classent directement le contenu sont les plus faciles à déboguer et à comprendre. Mais un ensemble de modèles (un "modèle" qui combine les scores d'autres modèles) peut s'avérer plus performant. Pour que les choses restent simples, chaque modèle doit être soit un ensemble n'acceptant en entrée que les résultats d'autres modèles, soit un modèle de base acceptant de très nombreuses caractéristiques, mais pas les deux. Si vous empilez des modèles entraînés séparément, leur combinaison peut se traduire par un comportement indésirable.

Pour l'assemblage, utilisez un modèle simple qui n'accepte que les sorties de vos modèles "de base" comme entrées. Vous devez également appliquer des propriétés à ces modèles d'ensemble. Par exemple, une augmentation du score d'un modèle de base ne devrait pas diminuer le score de l'ensemble. De même, il est préférable que les modèles entrants soient interprétables sémantiquement (par exemple, étalonnés), afin que les modifications des modèles sous-jacents ne perturbent pas le modèle d'ensemble. Assurez-vous également qu'une augmentation de la probabilité prédite d'un classificateur sous-jacent ne diminue pas la probabilité prédite de l'ensemble.

Règle n° 41 : lorsque les performances atteignent un plateau, recherchez des sources d'information qualitativement nouvelles à ajouter au lieu d'affiner les signaux existants

Vous avez ajouté des données démographiques sur l'utilisateur. Vous avez ajouté des informations sur les mots du document. Vous avez exploré le modèle et ajusté la régularisation. Vous n'avez pas constaté de lancements avec une amélioration de plus de 1 % de vos statistiques clés depuis plusieurs trimestres. Que faire ?

Il est temps de commencer à construire l'infrastructure pour des caractéristiques radicalement différentes, comme l'historique des documents auxquels cet utilisateur a accédé le jour, la semaine ou l'année précédents, ou des données tirées d'une autre propriété. Utilisez des entités wikidata ou des éléments internes à votre entreprise (par exemple le Knowledge Graph de Google). Utilisez le deep learning. Commencez à adapter vos attentes au retour sur investissement que vous escomptez, et intensifiez vos efforts en conséquence. Comme dans tout projet d'ingénierie, vous devez évaluer l'avantage de l'ajout de nouvelles caractéristiques par rapport au coût de l'accroissement de la complexité.

Règle n° 42 : ne vous attendez pas à ce que la diversité, la personnalisation ou la pertinence soient aussi étroitement corrélées avec la popularité que ce que vous imaginez

Dans un ensemble de contenu, la diversité peut recouvrir de nombreux concepts, la diversité de la source du contenu étant l'une des significations les plus courantes. La personnalisation implique que chaque utilisateur obtienne ses propres résultats. La pertinence signifie que les résultats d'une requête particulière sont plus appropriés pour cette requête que pour toute autre. Ces trois propriétés sont donc définies comme étant un écart par rapport à la norme.

Le problème est qu'il est difficile de s'éloigner de la norme.

Notez que si votre système mesure les clics, le temps passé, les lectures, les +1, les partages, etc., vous mesurez la popularité du contenu. Les équipes essaient parfois d'entraîner un modèle personnel en se basant sur la diversité. Elles ajoutent, à des fins de personnalisation, des caractéristiques qui permettent au système de procéder à la personnalisation (caractéristiques représentant l'intérêt de l'utilisateur) ou à la diversification (caractéristiques indiquant si ce document a des caractéristiques en commun avec d'autres documents renvoyés, comme l'auteur ou le contenu), et concluent que la pondération de ces caractéristiques est inférieure (ou parfois d'un signe différent) à ce qu'elles prévoyaient.

Cela ne signifie pas que la diversité, la personnalisation ou la pertinence n'ont aucune valeur. Comme indiqué dans la règle précédente, vous pouvez effectuer un post-traitement pour améliorer la diversité ou la pertinence. Si vous constatez que des objectifs à plus long terme augmentent, vous pouvez affirmer que la diversité ou la pertinence sont précieuses en elles-mêmes, en dehors de la popularité. Vous pouvez ensuite continuer à utiliser votre post-traitement ou bien modifier directement l'objectif en fonction de la diversité ou de la pertinence.

Règle n° 43 : vos amis ont tendance à être les mêmes pour différents produits, contrairement à vos intérêts

Les équipes de Google ont eu beaucoup de succès en prenant un modèle prédisant la proximité d'une connexion pour un produit et en l'utilisant pour un autre. Vos amis sont ce qu'ils sont. D'un autre côté, plusieurs équipes ont bataillé avec des caractéristiques de personnalisation utilisées avec des produits différents. Cela devrait certes fonctionner, mais il semble que ce ne soit pas le cas pour l'instant. Une méthode qui fonctionne parfois consiste à utiliser des données brutes d'une propriété pour prédire le comportement d'une autre. Gardez également à l'esprit que le simple fait de savoir qu'un utilisateur a un historique sur une autre propriété peut aider. Par exemple, l'activité d'un utilisateur sur deux produits peut être en soi révélatrice.

Il existe de nombreux documents sur le machine learning, chez Google et ailleurs.

Remerciements

Merci à David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira et Hrishikesh Aradhye pour leurs nombreux exemples, corrections et suggestions utiles pour ce document. Merci également à Kristen Lefevre, Suddha Basu et Chris Berg, pour leur aide sur une version antérieure. Les erreurs, omissions ou (aïe !) les opinions impopulaires sont les miennes.

Annexe

Ce document fait plusieurs fois référence à des produits Google. Pour une meilleure contextualisation, voici une brève description des exemples les plus courants.

Présentation de YouTube

YouTube est un service de vidéo en streaming. Les équipes YouTube "Vidéos à regarder ensuite" et "Page d'accueil" utilisent des modèles de machine learning pour classer les recommandations de vidéo. La fonctionnalité "Vidéos à regarder ensuite" recommande des vidéos à regarder après celle en cours de lecture, tandis que la page d'accueil recommande des vidéos aux utilisateurs qui parcourent cette page.

Présentation de Google Play

Google Play utilise de nombreux modèles pour résoudre divers problèmes. La recherche Google Play, les recommandations personnalisées de la page d'accueil Google Play et la fonctionnalité "D'autres ont aussi installé" reposent toutes sur le machine learning.

Présentation de Google Plus

Google Plus utilise le machine learning pour classer les posts dans le flux des posts qui s'affichent pour l'utilisateur, pour classer les posts "Populaire sur Google+" (posts actuellement très populaires), pour classer les connaissances des utilisateurs, etc.