Règles du machine learning:

Bonnes pratiques d'ingénierie du ML

Martin Zinkevich

Ce document est destiné à aider les personnes ayant des connaissances de base sur le machine learning à profiter des bonnes pratiques de Google en la matière. Il présente un style pour le machine learning, semblable au guide de style Google C++ et à d'autres guides populaires de programmation pratique. Si vous avez suivi un cours de machine learning, ou si vous avez créé ou travaillé sur un modèle de machine learning, vous disposez des connaissances nécessaires pour lire ce document.

Martin Zinkevich présente 10 de ses règles préférées du machine learning. Lisez la suite pour découvrir les 43 règles.

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.
  • Métrique: nombre qui vous intéresse. Peut être optimisé directement ou non.
  • Objectif: métrique que votre algorithme tente d'optimiser.
  • Pipeline: infrastructure sur laquelle repose un 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.

Présentation

Pour créer des produits de qualité:

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

La plupart des problèmes que vous rencontrerez sont en fait des problèmes d'ingénierie. Même avec toutes les ressources d'un expert en machine learning, la plupart des gains proviennent de fonctionnalités de qualité, et non d'algorithmes de machine learning. L'approche de base est donc la suivante:

  1. Assurez-vous que votre pipeline est solide de bout en bout.
  2. Commencez par définir un objectif raisonnable.
  3. Ajoutez des fonctionnalités de bon sens de manière simple.
  4. Assurez-vous que votre pipeline reste solide.

Cette approche fonctionnera bien pendant une longue période. Ne vous écartez de cette approche que lorsque vous n'avez plus d'astuces simples pour aller plus loin. Rendre le modèle plus complexe ralentit la publication des versions suivantes.

Une fois que vous avez épuisé les astuces simples, le machine learning de pointe pourrait bien être votre avenir. Consultez la section sur les projets de machine learning de la phase III.

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.

Le machine learning est une technologie intéressante, mais il nécessite des données. Théoriquement, vous pouvez utiliser les données d'un autre problème, puis ajuster le modèle pour un nouveau produit. Toutefois, cela risque de sous-performer les heuristiques de base. Si vous pensez que le machine learning vous apportera un 100% de boost, une heuristique vous permettra d'atteindre 50 % de cet objectif.

Par exemple, si vous classez des applications sur une place de marché, vous pouvez utiliser le taux d'installation ou le nombre d'installations comme heuristiques. Si vous détectez du spam, filtrez les éditeurs qui en ont déjà envoyé. N'hésitez pas non plus à utiliser la révision humaine. Si vous devez classer les contacts, placez les plus récents en haut de la liste (ou même triez-les par ordre alphabétique). Si le machine learning n'est pas absolument nécessaire pour votre produit, n'utilisez-le que lorsque vous disposez de données.

Règle 2: Commencez par concevoir et implémenter des métriques.

Avant de formaliser ce que votre système de machine learning fera, suivez autant que possible votre système actuel. Pour les raisons suivantes:

  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 framework de test, dans lequel vous pouvez regrouper les utilisateurs en groupes et agréger les statistiques par test, est important. Consultez la règle 12.

En collectant plus de métriques, vous pouvez obtenir une vue d'ensemble plus large de votre système. Vous avez remarqué un problème ? Ajoutez une métrique pour le suivre. Vous êtes enthousiaste à propos d'un changement quantitatif dans la dernière version ? Ajoutez une métrique pour le suivre.

Règle 3: Choisissez le machine learning plutôt qu'une heuristique complexe.

Une heuristique simple peut vous permettre de lancer votre produit. Une heuristique complexe est impossible à gérer. Une fois que vous disposez de données et d'une idée de base de ce que vous essayez d'accomplir, passez au machine learning. Comme dans la plupart des tâches d'ingénierie logicielle, vous devrez constamment mettre à jour votre approche, qu'il s'agisse d'une heuristique ou d'un modèle d'apprentissage automatique. Vous constaterez que le modèle d'apprentissage automatique est plus facile à mettre à jour et à gérer (voir la règle 16).

Phase I du ML: votre premier pipeline

Pour votre premier pipeline, concentrez-vous sur l'infrastructure de votre système. Bien qu'il soit amusant de penser à tout le machine learning imaginatif que vous allez effectuer, il sera difficile de comprendre ce qui se passe si vous ne faites pas d'abord confiance à votre pipeline.

Règle 4: Gardez le premier modèle simple et assurez-vous que l'infrastructure est adaptée.

Le premier modèle offre le plus grand coup de pouce à votre produit. Il n'a donc pas besoin d'être sophistiqué. Mais vous rencontrerez beaucoup 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 déterminer:

  • Comment obtenir des exemples pour votre algorithme d'apprentissage
  • Une première approche de ce que signifient "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 fonctionnalités atteignent correctement votre algorithme d'apprentissage.
  • Le modèle apprend des pondérations raisonnables.
  • Les fonctionnalités atteignent correctement votre modèle sur le serveur.

Une fois que vous avez un système qui effectue ces trois tâches de manière fiable, vous avez fait la majeure partie du travail. Votre modèle simple vous fournit des métriques de référence et un comportement de référence que vous pouvez utiliser pour tester des modèles plus complexes. Certaines équipes visent un premier lancement "neutre", c'est-à-dire qui ne donne pas la priorité aux gains du machine learning pour éviter toute distraction.

Règle 5: Testez l'infrastructure indépendamment du machine learning.

Assurez-vous que l'infrastructure est testable et que les parties d'apprentissage du système sont encapsulées afin que vous puissiez tester tout ce qui l'entoure. Plus spécifiquement :

  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 de comprendre vos données: consultez les conseils pratiques pour l'analyse de grands ensembles de données complexes.

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

Nous créons souvent un pipeline en copiant un pipeline existant (programmation cargo cult), et l'ancien pipeline supprime les données dont nous avons besoin pour le nouveau pipeline. Par exemple, le pipeline de la section "À la une" de Google Plus supprime les posts plus anciens (car il tente de classer les posts récents). Ce pipeline a été copié pour être utilisé dans le flux Google Plus, où les anciens posts sont toujours pertinents, mais le pipeline supprimait toujours les anciens posts. Un autre modèle courant consiste à ne consigner que les données vues par l'utilisateur. Par conséquent, ces données sont inutiles si nous voulons modéliser pourquoi 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 Play. Lorsque nous avons travaillé sur la page d'accueil des applications Play, un nouveau pipeline a été créé, qui contenait également des exemples de la page de destination de Play Jeux sans aucune fonctionnalité permettant de déterminer l'origine de chaque exemple.

Règle 7: Transformez les heuristiques en fonctionnalités ou gérez-les en externe.

En général, les problèmes que le machine learning tente de résoudre ne sont pas complètement nouveaux. Il existe un système existant pour le classement, la classification ou tout autre problème que vous essayez de résoudre. Cela signifie qu'il existe un certain nombre de règles et d'heuristiques. Ces mêmes heuristiques peuvent vous aider à améliorer vos performances lorsque vous les ajustez avec le machine learning. Vos heuristiques doivent être exploitées pour toutes les informations qu'elles contiennent, pour deux raisons. Tout d'abord, la transition vers un système d'apprentissage automatique sera plus fluide. Deuxièmement, ces règles contiennent généralement une grande partie de l'intuition sur le système que vous ne voulez pas jeter. Vous pouvez utiliser une heuristique existante de quatre manières:

  • 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 directement à 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 l'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 le libellé. 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. Consultez Votre premier objectif.

Tenez compte de la complexité supplémentaire lorsque vous utilisez des heuristiques dans un système de ML. L'utilisation d'anciennes heuristiques dans votre nouvel algorithme de machine learning peut vous aider à créer une transition fluide, mais demandez-vous s'il existe un moyen plus simple d'obtenir le même effet.

Surveillance

En règle générale, adoptez de bonnes pratiques d'hygiène des alertes, par exemple en rendant les alertes exploitables et en disposant d'une page de tableau de bord.

Règle 8: Connaître les exigences de fraîcheur de votre système

Quelle est la dégradation des performances si vous disposez d'un modèle d'un jour ? Une semaine ? Un quart d'heure ? Ces informations peuvent vous aider à comprendre les priorités de votre surveillance. Si la qualité du produit est fortement affectée si le modèle n'est pas mis à jour pendant une journée, il est logique de confier la surveillance du modèle à un ingénieur en continu. 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 ML pour la recherche Google Play n'est pas mis à jour, cela peut avoir un impact négatif en moins d'un mois. Certains modèles pour les contenus populaires dans Google Plus ne comportent pas d'identifiant de post. Ils ne peuvent donc pas exporter ces modèles fréquemment. Les autres modèles qui comportent des identifiants de post sont mis à jour beaucoup plus fréquemment. Notez également que la fraîcheur peut changer au fil du temps, en particulier lorsque des colonnes de fonctionnalités sont ajoutées ou supprimées de votre modèle.

Règle 9: Détectez les problèmes avant d'exporter des modèles.

De nombreux systèmes de machine learning comportent une étape au cours de laquelle vous exportez le modèle pour le mettre en service. En cas de problème avec un modèle exporté, il s'agit d'un problème visible par l'utilisateur.

Effectuez des vérifications avant d'exporter le modèle. Plus précisément, assurez-vous que les performances du modèle sont raisonnables sur les données exclues de l'apprentissage. Si vous avez encore des questions concernant les données, n'exportez pas de modèle. De nombreuses équipes qui déploient des modèles en continu vérifient l'aire sous la courbe ROC (ou AUC) avant l'exportation. Les problèmes liés aux modèles qui n'ont pas été exportés nécessitent une alerte par e-mail, mais les problèmes liés à un modèle visible par l'utilisateur peuvent nécessiter une page. Il est donc préférable d'attendre et de s'assurer avant d'affecter les utilisateurs.

Règle 10: Surveillez les échecs silencieux.

Ce problème se produit plus souvent pour les systèmes de machine learning que pour d'autres types de systèmes. Supposons qu'une table particulière qui est jointe ne soit plus mise à jour. Le système de machine learning s'ajustera, et le comportement restera raisonnablement bon, diminuant progressivement. Il arrive parfois de trouver des tableaux qui sont obsolètes depuis des mois, et une simple actualisation améliore les performances plus que tout autre lancement ce trimestre. La couverture d'une fonctionnalité peut changer en raison de modifications d'implémentation: par exemple, une colonne de fonctionnalités peut être renseignée dans 90% des exemples, puis passer soudainement à 60 %. Play avait une table obsolète depuis six mois. L'actualisation de la table a permis d'augmenter le taux d'installation de 2 %. Si vous suivez les statistiques des données et que vous les inspectez manuellement de temps en temps, vous pouvez réduire ces types de défaillances.

Règle 11: Attribuez des propriétaires et une documentation aux colonnes de caractéristiques.

Si le système est volumineux et qu'il comporte de nombreuses colonnes d'éléments géographiques, sachez qui a créé ou gère chaque colonne d'éléments géographiques. Si vous constatez que la personne qui comprend une colonne de fonctionnalités quitte l'entreprise, assurez-vous que quelqu'un dispose de ces informations. Bien que de nombreuses colonnes de fonctionnalités portent des noms descriptifs, il est utile d'avoir une description plus détaillée de la fonctionnalité, de son origine et de son utilité.

Votre premier objectif

Vous disposez de nombreuses métriques ou mesures sur le système qui vous intéresse, mais votre algorithme de machine learning nécessite souvent un seul objectif, un nombre que votre algorithme "essaie" d'optimiser. Je fais ici la distinction entre les objectifs et les métriques: une métrique est un nombre que votre système indique, qui peut être important ou non. Consultez également la règle 2.

Règle 12: Ne réfléchissez pas trop à l'objectif que vous choisissez d'optimiser directement.

Vous voulez gagner de l'argent, rendre vos utilisateurs heureux et rendre le monde meilleur. De nombreuses métriques vous intéressent, et vous devez toutes les mesurer (voir la règle 2). Toutefois, au début du processus de machine learning, vous remarquerez qu'ils augmentent tous, même ceux que vous n'optimisez pas directement. Par exemple, supposons que vous soyez intéressé par le nombre de clics et le temps passé sur le site. Si vous optimisez pour le nombre de clics, le temps passé est susceptible d'augmenter.

Alors, faites simple et ne vous souciez pas trop de l'équilibre entre les différentes métriques si vous pouvez facilement les augmenter toutes. Ne poussez pas cette règle trop loin: ne confondez pas votre objectif avec la santé ultime du système (voir Règle 39). Si vous constatez que vous augmentez la métrique optimisée directement, mais que vous décidez de ne pas lancer la campagne, une révision de l'objectif peut être nécessaire.

Règle 13: Choisissez une métrique simple, observable et attribuable pour votre premier objectif.

Vous ne savez souvent pas quel est le véritable objectif. Vous pensez que vous le savez, mais lorsque vous examinez les données et l'analyse côte à côte de votre ancien système et de votre nouveau système de ML, vous réalisez que vous souhaitez modifier l'objectif. De plus, les différents membres de l'équipe ne parviennent souvent pas à s'entendre sur l'objectif réel. L'objectif de ML doit être facile à mesurer et servir de proxy pour l'objectif "réel". En fait, il n'y a souvent pas d'objectif "vrai" (voir la règle 39). Entraînez-vous sur l'objectif ML simple et envisagez d'ajouter une "couche de règles" qui vous permettra d'ajouter une logique supplémentaire (espérons qu'elle sera très simple) pour effectuer le classement final.

Le comportement utilisateur le plus facile à modéliser est celui qui est directement observé et attribuable à une action du système:

  • Ce lien a-t-il été cliqué ?
  • Cet objet classé a-t-il été téléchargé ?
  • Cet objet classé a-t-il été transféré/répondu/envoyé par e-mail ?
  • Cet objet classé a-t-il été noté ?
  • L'objet affiché a-t-il été marqué comme spam/pornographie/inapproprié ?

Évitez de modéliser les effets indirects au début:

  • L'utilisateur a-t-il effectué une visite le jour suivant ?
  • Combien de temps l'utilisateur a-t-il passé sur le site ?
  • Quel était le nombre d'utilisateurs actifs par jour ?

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

Enfin, n'essayez pas de demander au machine learning de déterminer:

  • L'utilisateur est-il satisfait de l'utilisation du produit ?
  • L'utilisateur est-il satisfait de l'expérience ?
  • Le produit améliore-t-il le bien-être global de l'utilisateur ?
  • Quel impact cela aura-t-il sur la santé globale de l'entreprise ?

Tous ces éléments sont importants, mais aussi extrêmement difficiles à mesurer. Utilisez plutôt des proxys: si l'utilisateur est satisfait, il restera plus longtemps sur le site. Si l'utilisateur est satisfait, il reviendra demain. En ce qui concerne le bien-être et la santé de l'entreprise, le jugement humain est nécessaire pour associer tout objectif d'apprentissage automatique à la nature du produit que vous vendez et à votre plan d'entreprise.

Règle 14: Commencer par un modèle interprétable facilite le débogage.

La régression linéaire, la régression logistique et la régression de Poisson sont directement motivées par un modèle probabiliste. Chaque prédiction peut être interprétée comme une probabilité ou une valeur attendue. Ils sont ainsi plus faciles à déboguer que les modèles qui utilisent des objectifs (perte zéro-un, diverses pertes en charnière, etc.) qui tentent d'optimiser directement la précision de classification ou les performances de classement. Par exemple, si les probabilités d'entraînement s'écartent des probabilités prévues dans les comparaisons côte à côte ou en inspectant le système de production, cette déviation peut révéler un problème.

Par exemple, dans la régression linéaire, logistique ou de Poisson, il existe des sous-ensembles de données pour lesquels l'espérance prédite moyenne est égale à l'étiquette moyenne (calibrée au moment 1 ou simplement calibrée). Cela est vrai en supposant que vous n'avez pas de régularisation et que votre algorithme a convergé. C'est à peu près vrai en général. Si une caractéristique est égale à 1 ou à 0 pour chaque exemple, l'ensemble de trois exemples où cette caractéristique est égale à 1 est calibré. De plus, si une caractéristique est égale à 1 pour chaque exemple, l'ensemble de tous les exemples est calibré.

Avec des modèles simples, il est plus facile de gérer les boucles de rétroaction (voir la règle 36). Nous utilisons souvent ces prédictions probabilistes pour prendre une décision: par exemple, classer les posts par valeur attendue décroissante (c'est-à-dire la probabilité de clic/téléchargement/etc.). N'oubliez pas que, lorsque vous devez choisir le modèle à utiliser, la décision est plus importante que la probabilité des données données au modèle (voir la règle 27).

Règle 15: Séparez le filtrage du spam et le classement de la qualité dans une couche de règles.

Le classement de qualité est un art, mais le filtrage du spam est une guerre. Les signaux que vous utilisez pour déterminer les posts de haute qualité deviendront évidents pour les utilisateurs de votre système, et ils ajusteront leurs posts pour qu'ils présentent ces propriétés. Par conséquent, votre classement de qualité doit se concentrer sur le classement des contenus publiés de bonne foi. Vous ne devez pas écarter l'outil d'apprentissage du classement de qualité pour qu'il classe le spam en haut de la liste. De même, les contenus "osés" doivent être traités séparément du classement de qualité. Le filtrage du spam est une autre histoire. Vous devez vous attendre à ce que les fonctionnalités que vous devez générer changent constamment. Vous allez souvent mettre en place des règles évidentes dans le système (si un post reçoit plus de trois votes de spam, ne le récupérez pas, etc.). Tout modèle appris doit être mis à jour quotidiennement, voire plus rapidement. La réputation du créateur du contenu joue un rôle important.

À un certain niveau, le résultat de ces deux systèmes devra être intégré. N'oubliez pas que le filtrage des spams dans les résultats de recherche doit probablement être plus strict que dans les e-mails. Il est également courant de supprimer le spam des données d'entraînement pour le classificateur de qualité.

Phase II du machine learning: Ingénierie des caractéristiques

Dans la première phase du cycle de vie d'un système de machine learning, les problèmes importants sont d'intégrer les données d'entraînement au système d'apprentissage, d'instrumenter les métriques d'intérêt et de créer une infrastructure de diffusion. Une fois que vous disposez d'un système de bout en bout opérationnel avec des tests unitaires et système instrumentés, la phase II commence.

Dans la deuxième phase, il y a beaucoup de fruits à portée de main. De nombreuses fonctionnalités évidentes pourraient être intégrées au système. Ainsi, la deuxième phase du machine learning consiste à extraire autant de fonctionnalités que possible et à les combiner de manière intuitive. Pendant cette phase, toutes les métriques doivent continuer à augmenter. Il y aura de nombreux lancements, et c'est le moment idéal pour recruter de nombreux ingénieurs qui pourront associer toutes les données dont vous avez besoin pour créer un système d'apprentissage vraiment génial.

Règle 16: Planifiez le lancement et les itérations.

Ne vous attendez pas à ce que le modèle sur lequel vous travaillez actuellement soit le dernier que vous lancerez, ni même à ce que vous arrêtiez de lancer des modèles. Par conséquent, réfléchissez à la complexité que vous ajoutez avec ce lancement et à son impact sur les lancements futurs. De nombreuses équipes lancent un modèle par trimestre ou plus depuis des années. Il existe trois raisons principales de lancer de nouveaux modèles:

  • Vous proposez de nouvelles fonctionnalités.
  • Vous ajustez la régularisation et combinez les anciennes fonctionnalités de manière inédite.
  • Vous affinez l'objectif.

Quoi qu'il en soit, il peut être utile de donner un peu d'attention à un modèle: examiner les données qui alimentent l'exemple peut aider à trouver de nouveaux signaux, ainsi que d'anciens signaux défectueux. Ainsi, lorsque vous créez votre modèle, réfléchissez à la facilité avec laquelle vous pouvez ajouter, supprimer ou recombiner des fonctionnalités. Réfléchissez à la facilité avec laquelle vous pouvez créer une nouvelle copie du pipeline et vérifier son exactitude. Demandez-vous s'il est possible d'exécuter deux ou trois copies en parallèle. Enfin, ne vous souciez pas de savoir si la fonctionnalité 16 sur 35 est incluse dans cette version du pipeline. Vous y arriverez le prochain trimestre.

Règle 17: Commencez par les caractéristiques directement observées et signalées plutôt que par les caractéristiques apprises.

Ce point peut être controversé, mais il évite de nombreux écueils. Tout d'abord, décrivons 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 l'apprenant lui-même (par exemple, via un modèle factorisé ou un apprentissage profond). Ces deux éléments peuvent être utiles, mais ils peuvent présenter de nombreux problèmes. Ils ne doivent donc pas figurer dans le premier modèle.

Si vous utilisez un système externe pour créer une fonctionnalité, n'oubliez pas que ce système a son propre objectif. L'objectif du système externe peut n'être que faiblement corrélé à votre objectif actuel. Si vous prenez un instantané du système externe, il peut devenir obsolète. Si vous mettez à jour les fonctionnalités à partir du système externe, les significations peuvent changer. Si vous utilisez un système externe pour fournir une fonctionnalité, sachez que cette approche nécessite beaucoup de précautions.

Le principal problème des modèles factorisés et des modèles profonds est qu'ils ne sont pas convexes. Par conséquent, il n'est pas garanti qu'une solution optimale puisse être approchée ou trouvée, et les minima locaux trouvés à chaque itération peuvent être différents. Cette variation rend difficile de juger si l'impact d'une modification de votre système est significatif ou aléatoire. En créant un modèle sans fonctionnalités avancées, vous pouvez obtenir d'excellentes performances de référence. Une fois cette référence établie, vous pouvez essayer des approches plus ésotériques.

Règle 18: Explorez les caractéristiques des contenus qui se généralisent dans différents contextes.

Un système de machine learning est souvent une petite partie d'un ensemble beaucoup plus vaste. Par exemple, si vous imaginez un post qui pourrait être utilisé dans "À la une", de nombreuses personnes l'aimeront, le partageront ou commenteront avant qu'il ne soit diffusé dans "À la une". Si vous fournissez ces statistiques à l'apprenant, il peut promouvoir de nouveaux posts pour lesquels il n'a 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 des notes explicites des utilisateurs. Enfin, si vous utilisez une action utilisateur comme libellé, il peut être intéressant de voir cette action dans le document dans un autre contexte. Toutes ces fonctionnalités vous permettent d'intégrer de nouveaux contenus dans le contexte. Notez qu'il ne s'agit pas de personnalisation: commencez par déterminer si quelqu'un aime le contenu dans ce contexte, puis identifiez les personnes qui l'aiment plus ou moins.

Règle 19: Utilisez des fonctionnalités très spécifiques lorsque cela est possible.

Avec des tonnes de données, il est plus simple d'apprendre des millions de fonctionnalités simples que quelques fonctionnalités complexes. Les identifiants des documents récupérés et les requêtes canoniques ne fournissent pas beaucoup de généralisations, mais alignent votre classement sur vos libellés pour les requêtes principales. Par conséquent, n'ayez pas peur des groupes d'éléments géographiques où chaque élément s'applique à une très petite partie de vos données, mais dont la couverture globale est supérieure à 90%. Vous pouvez utiliser la régularisation pour éliminer les caractéristiques qui ne s'appliquent qu'à trop peu d'exemples.

Règle 20: Combinez et modifiez des fonctionnalités existantes pour en créer de nouvelles de manière compréhensible pour l'utilisateur.

Il existe plusieurs façons de combiner et de modifier des éléments géographiques. Les systèmes de machine learning tels que TensorFlow vous permettent de prétraiter vos données via des transformations. Les deux approches les plus courantes sont les "discrétisations" et les "croisements".

La discrétisation consiste à prendre une caractéristique continue et à en créer de nombreuses caractéristiques discrètes. Prenons l'exemple d'une caractéristique continue telle que l'âge. Vous pouvez créer une fonctionnalité qui vaut 1 lorsque l'âge est inférieur à 18 ans, une autre qui vaut 1 lorsque l'âge est compris entre 18 et 35 ans, etc. Ne réfléchissez pas trop aux limites de ces histogrammes: les quantiles de base vous apporteront la plupart des informations.

Les croisements combinent deux colonnes de caractéristiques ou plus. Dans la terminologie de TensorFlow, une colonne de caractéristiques est un ensemble de caractéristiques homogènes (par exemple, {male, female}, {US, Canada, Mexico}, etc.). Un croisement est une nouvelle colonne de caractéristiques avec des caractéristiques dans, par exemple, {male, female} × {US,Canada, Mexico}. Cette nouvelle colonne contiendra la fonctionnalité (homme, Canada). Si vous utilisez TensorFlow et que vous lui demandez de créer cette intersection pour vous, cette caractéristique (homme, Canada) sera présente dans les exemples représentant des hommes canadiens. Notez qu'il faut de grandes quantités de données pour apprendre des modèles avec des croisements de trois, quatre ou plusieurs colonnes de caractéristiques de base.

Les croisements qui produisent de très grandes colonnes de caractéristiques peuvent entraîner une suradaptation. Par exemple, imaginons que vous effectuiez une recherche et que vous disposiez d'une colonne de caractéristiques avec des mots dans la requête et d'une colonne de caractéristiques avec des mots dans le document. Vous pouvez les combiner avec une croix, mais vous vous retrouverez avec de nombreuses fonctionnalités (voir la règle 21).

Lorsque vous travaillez avec du texte, deux options s'offrent à vous. Le plus draconien est 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 consiste à utiliser une intersection: nous aurons ainsi une fonctionnalité qui est présente si et seulement si le mot "poney" figure à la fois dans le document et dans la requête, et une autre fonctionnalité qui est présente si et seulement si le mot "le" figure à la fois dans le document et dans la requête.

Règle 21: Le nombre de pondérations de caractéristiques que vous pouvez apprendre dans un modèle linéaire est à peu près proportionnel à la quantité de données dont vous disposez.

Il existe des résultats fascinants de la théorie de l'apprentissage statistique concernant le niveau de complexité approprié pour un modèle, mais cette règle est essentiellement tout ce que vous devez savoir. J'ai eu des conversations avec des personnes qui doutaient qu'il soit possible d'apprendre quoi que ce soit à partir de mille exemples, ou qu'il soit nécessaire d'en avoir plus d'un million, car elles sont 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 recherche, et qu'il y a des millions de mots différents dans les documents et la requête, et que vous disposez de 1 000 exemples libellés, vous devez utiliser un produit scalaire entre les caractéristiques des documents et des requêtes, TF-IDF et une demi-douzaine d'autres caractéristiques hautement conçues par l'homme. 1 000 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 22: Nettoyez les fonctionnalités que vous n'utilisez plus.

Les fonctionnalités inutilisées créent une dette technique. Si vous constatez que vous n'utilisez pas une fonctionnalité et que la combiner à d'autres ne fonctionne pas, supprimez-la de votre infrastructure. Vous devez garder votre infrastructure propre afin que les fonctionnalités les plus prometteuses puissent être testées le plus rapidement possible. Si nécessaire, quelqu'un pourra toujours rajouter votre fonctionnalité.

Tenez compte de la couverture lorsque vous choisissez les fonctionnalités à ajouter ou à conserver. Combien d'exemples sont couverts par la fonctionnalité ? Par exemple, si vous proposez des fonctionnalités de personnalisation, mais que seuls 8% de vos utilisateurs en bénéficient, elles ne seront pas très efficaces.

En revanche, certaines fonctionnalités peuvent être plus utiles que prévu. Par exemple, si une caractéristique ne couvre que 1% des données, mais que 90% des exemples qui présentent cette caractéristique sont positifs, il s'agit d'une excellente caractéristique à ajouter.

Analyse humaine du système

Avant de passer à la troisième phase du machine learning, il est important de se concentrer sur un élément qui n'est enseigné dans aucun cours de machine learning: comment examiner un modèle existant et l'améliorer. Il s'agit davantage d'un art que d'une science, et pourtant, il permet d'éviter plusieurs anti-modèles.

Règle 23: Vous n'êtes pas un utilisateur final typique.

C'est peut-être le moyen le plus simple pour une équipe de s'enliser. Bien que le fishfooding (utiliser un prototype au sein de votre équipe) et le dogfooding (utiliser un prototype au sein de votre entreprise) présentent de nombreux avantages, les employés doivent vérifier si les performances sont correctes. Bien qu'un changement qui semble manifestement mauvais ne doive pas être utilisé, tout ce qui semble raisonnablement proche de la production doit être testé plus en détail, soit en payant des personnes non spécialisées pour répondre à des questions sur une plate-forme de crowdsourcing, soit en effectuant un test en direct sur de vrais utilisateurs.

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). Deuxièmement, votre temps est trop précieux. Pensez au coût de neuf ingénieurs participant à une réunion d'une heure et au nombre d'étiquettes humaines sous contrat que cela achète sur une plate-forme de crowdsourcing.

Si vous souhaitez vraiment obtenir des commentaires des utilisateurs, utilisez des méthodologies d'expérience utilisateur. Créez des personas utilisateur (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. Les personas utilisateur impliquent de créer un utilisateur hypothétique. Par exemple, si votre équipe est entièrement masculine, il peut être utile de concevoir un persona utilisateur féminin de 35 ans (avec ses caractéristiques) et d'examiner les résultats qu'il génère plutôt que 10 résultats pour les hommes de 25 à 40 ans. Faire appel à des personnes réelles pour observer leur réaction à votre site (en local ou à distance) lors de tests d'utilisabilité peut également vous donner un nouvel angle de vue.

Règle 24: Mesurez le delta entre les modèles.

L'une des mesures les plus simples et parfois les plus utiles que vous pouvez effectuer avant qu'aucun utilisateur n'ait examiné votre nouveau modèle consiste à calculer dans quelle mesure les nouveaux résultats sont différents de la production. Par exemple, si vous rencontrez un problème de classement, exécutez les deux modèles sur un échantillon de requêtes dans l'ensemble du système, puis examinez la taille de la différence symétrique des résultats (pondérée par la position de classement). Si la différence est très faible, vous pouvez déterminer sans exécuter de test qu'il y aura peu de changement. Si la différence est très importante, vous devez vous assurer que le changement est justifié. Examiner les requêtes pour lesquelles la différence symétrique est élevée peut vous aider à comprendre qualitativement en quoi le changement a consisté. Assurez-vous toutefois que le système est stable. Assurez-vous qu'un modèle, par rapport à lui-même, présente une différence symétrique faible (idéalement nulle).

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

Votre modèle peut essayer de prédire le taux de clics. Toutefois, la question clé est de savoir ce que vous faites de cette prédiction. Si vous l'utilisez pour classer des documents, la qualité du classement final est plus importante que la prédiction elle-même. Si vous prévoyez la probabilité qu'un document soit du spam, puis que vous définissez une limite pour ce qui est bloqué, la précision de ce qui est autorisé est plus importante. Dans la plupart des cas, ces deux éléments doivent être en accord: lorsqu'ils ne le sont pas, il s'agit probablement d'un petit gain. Par conséquent, si une modification améliore la perte de journaux, mais dégrade les performances du système, recherchez une autre fonctionnalité. Lorsque cela commence à se produire plus souvent, il est temps de revoir l'objectif de votre modèle.

Règle 26: Recherchez des tendances dans les erreurs mesurées et créez de nouvelles fonctionnalités.

Supposons que vous observiez un exemple d'entraînement pour lequel le modèle a "tort". 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 où un élément positif a été classé plus bas qu'un élément négatif. Le point le plus important est que cet exemple montre que le système de machine learning sait qu'il s'est trompé et qu'il aimerait corriger son erreur s'il en a l'occasion. Si vous fournissez au modèle une fonctionnalité lui permettant de corriger l'erreur, il essaiera de l'utiliser.

En revanche, si vous essayez de créer une fonctionnalité basée sur des exemples que le système ne considère pas comme des erreurs, elle sera ignorée. Par exemple, supposons qu'un utilisateur recherche "jeux sans frais" dans la recherche d'applications Play. Supposons qu'un des résultats les plus pertinents soit une application de blague moins pertinente. Vous créez donc une fonctionnalité pour les "applications de blague". Toutefois, si vous maximisez le nombre d'installations et que les utilisateurs installent une application de blague lorsqu'ils recherchent des jeux sans frais, la fonctionnalité "Applications de blague" n'aura pas l'effet souhaité.

Une fois que vous avez des exemples de cas où le modèle s'est trompé, recherchez des tendances qui ne font pas partie de votre ensemble de fonctionnalités actuel. Par exemple, si le système semble déclasser les posts plus longs, ajoutez la longueur des posts. Ne soyez pas trop précis sur les fonctionnalités que vous ajoutez. Si vous souhaitez ajouter la longueur des posts, n'essayez pas de deviner ce que signifie "long". Ajoutez simplement une douzaine de caractéristiques et laissez le modèle déterminer ce qu'il doit en faire (voir la règle 21). C'est le moyen le plus simple d'obtenir ce que vous voulez.

Règle 27: Essayez de quantifier le comportement indésirable observé.

Certains membres de votre équipe commenceront à être frustrés par les propriétés du système qu'ils n'aiment pas, qui ne sont pas capturées par la fonction de perte existante. À ce stade, il doit faire tout son possible pour transformer ses critiques en chiffres concrets. Par exemple, s'il pense que trop d'applications "canulars" sont diffusées dans la recherche Play, il peut demander à des évaluateurs humains d'identifier ces applications. (Vous pouvez utiliser des données libellées manuellement dans ce cas, 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 fonctionnalités, objectifs ou métriques. La règle générale est la suivante : mesurez d'abord, optimisez ensuite.

Règle 28: Sachez qu'un comportement identique à court terme n'implique pas un comportement identique à long terme.

Imaginez que vous disposiez d'un nouveau système qui examine chaque doc_id et chaque requête exacte, puis calcule la probabilité de clic pour chaque document et chaque requête. Vous constatez que son comportement est presque identique à celui de votre système actuel, à la fois dans les tests côte à côte et les tests A/B. Compte tenu de sa simplicité, vous le lancez. Cependant, vous constatez qu'aucune nouvelle application n'est affichée. Pourquoi ? Étant donné que votre système n'affiche un document que sur la base de son propre historique avec cette requête, il n'est pas possible de savoir si un nouveau document doit être affiché.

Le seul moyen de comprendre comment un tel système fonctionnerait à long terme est de ne l'entraîner qu'avec les données acquises lorsque le modèle était en service. C'est très difficile.

Décalage entraînement/mise en service

Le décalage entraînement/diffusion est une différence entre les performances lors de l'entraînement et les performances lors de la diffusion. Ce décalage peut être dû aux raisons suivantes:

  • Une différence entre la manière dont vous traitez les données dans les pipelines d'entraînement et de diffusion.
  • des modifications apportées aux données entre l'entraînement et la diffusion.
  • Une boucle de rétroaction entre votre modèle et votre algorithme.

Nous avons observé chez Google des systèmes de machine learning en production présentant un biais d'entraînement-diffusion qui a un impact négatif sur les performances. La meilleure solution consiste à le surveiller explicitement afin que les modifications du système et des données n'introduisent pas de biais inaperçus.

Règle 29: Le meilleur moyen de vous assurer que vous entraînez comme vous diffusez consiste à enregistrer l'ensemble des fonctionnalités utilisées au moment de la diffusion, puis à les transmettre à un journal pour les utiliser au moment de l'entraînement.

Même si vous ne pouvez pas le faire pour chaque exemple, faites-le pour une petite partie, afin de pouvoir vérifier la cohérence entre le service et l'entraînement (voir la règle 37). Les équipes qui ont effectué cette mesure chez Google ont parfois été surprises par les résultats. La page d'accueil de YouTube est passée aux fonctionnalités de journalisation au moment de la diffusion, ce qui a permis d'améliorer considérablement la qualité et de réduire la complexité du code. De nombreuses équipes sont en train de passer à cette infrastructure.

Règle 30: Pondérez les données échantillonnées en fonction de leur importance, ne les supprimez pas arbitrairement.

Lorsque vous disposez de trop de données, vous pouvez être tenté de prendre les fichiers 1 à 12 et d'ignorer les fichiers 13 à 99. Il s'agit d'une erreur. Bien que les données qui n'ont jamais été présentées à l'utilisateur puissent être supprimées, le pondération de l'importance est préférable pour le reste. La pondération de l'importance signifie que si vous décidez d'échantillonner l'exemple X avec une probabilité de 30 %, attribuez-lui une pondération de 10/3. Avec la pondération de l'importance, toutes les propriétés de calibrage abordées dans la règle 14 restent valables.

Règle 31: Si vous associez les données d'une table au moment de l'entraînement et du déploiement, les données de la table peuvent changer.

Imaginons que vous associez des ID de document à un tableau contenant des fonctionnalités pour ces documents (comme le nombre de commentaires ou de clics). Entre l'entraînement et le moment de la diffusion, les caractéristiques du tableau peuvent être modifiées. La prédiction de votre modèle pour le même document peut donc différer entre l'entraînement et la diffusion. Le moyen le plus simple d'éviter ce type de problème consiste à consigner les fonctionnalités au moment de la diffusion (voir la règle 32). Si le tableau ne change que lentement, vous pouvez également créer un instantané du tableau toutes les heures ou tous les jours pour obtenir des données suffisamment proches. Notez que cette opération ne résout pas complètement le problème.

Règle 32: Réutilisez le code entre votre pipeline d'entraînement et votre pipeline de diffusion dans la mesure du possible.

Le traitement par lot est différent du traitement en ligne. Dans le traitement en ligne, vous devez gérer chaque requête à mesure qu'elle arrive (par exemple, vous devez effectuer une recherche distincte pour chaque requête), tandis que dans le traitement par lot, vous pouvez combiner des tâches (par exemple, effectuer une jointure). Au moment de l'inférence, vous effectuez un traitement en ligne, tandis que l'entraînement est une tâche de traitement par lot. Toutefois, vous pouvez effectuer certaines actions pour réutiliser du code. Par exemple, vous pouvez créer un objet propre à votre système, dans lequel le résultat de toute requête ou jointure peut être stocké de manière très lisible et les erreurs peuvent être testées facilement. Ensuite, une fois que vous avez rassemblé toutes les informations, lors de la diffusion ou de l'entraînement, vous exécutez une méthode courante pour établir un pont entre l'objet lisible par l'homme spécifique à votre système et le format attendu par le système de machine learning. Cela élimine une source de décalage entre entraînement et diffusion. Par conséquent, essayez de ne pas utiliser deux langages de programmation différents entre l'entraînement et le traitement. Cette décision vous empêchera presque de partager du code.

Règle 33: Si vous créez un modèle basé sur les données jusqu'au 5 janvier, testez-le sur les données du 6 janvier et après.

En général, mesurez les performances d'un modèle sur les données collectées après celles sur lesquelles vous avez entraîné le modèle, car cela reflète mieux ce que votre système fera en production. Si vous créez un modèle basé sur les données jusqu'au 5 janvier, testez-le sur les données du 6 janvier. Vous vous attendez à ce que les performances ne soient pas aussi bonnes avec les nouvelles données, mais elles ne devraient pas être radicalement moins bonnes. Étant donné qu'il peut y avoir des effets quotidiens, vous ne pourrez peut-être pas prédire le taux de clics ou le taux de conversion moyen, mais l'aire sous la courbe, qui représente la probabilité d'attribuer un score supérieur à l'exemple positif qu'à l'exemple négatif, devrait être raisonnablement proche.

Règle 34: Dans le cadre d'une classification binaire pour le filtrage (comme la détection de spam ou la détermination des e-mails intéressants), acceptez de faire de petits sacrifices de performances à court terme pour obtenir des données très propres.

Dans une tâche de filtrage, les exemples marqués comme négatifs ne sont pas présentés à l'utilisateur. Supposons que vous disposiez d'un filtre qui bloque 75% des exemples négatifs lors de la diffusion. Vous pourriez être tenté d'extraire des données d'entraînement supplémentaires à partir des instances présentées aux utilisateurs. Par exemple, si un utilisateur marque un e-mail comme spam que votre filtre a laissé passer, vous pouvez en tirer des enseignements.

Toutefois, cette approche introduit un biais d'échantillonnage. Vous pouvez collecter des données plus propres si, au lieu de diffuser, vous marquez 1% de tout le trafic comme "exclu" et envoyez tous les exemples exclus à l'utilisateur. Votre filtre bloque désormais au moins 74% des exemples négatifs. Ces exemples mis de côté peuvent devenir vos données d'entraînement.

Notez que si votre filtre bloque 95% ou plus des exemples négatifs, cette approche devient moins viable. Toutefois, si vous souhaitez mesurer les performances de diffusion, vous pouvez créer un échantillon encore plus petit (par exemple, 0,1% ou 0,001%). Dix mille exemples suffisent pour estimer les performances avec une bonne précision.

Règle 35: Méfiez-vous de la distorsion inhérente aux problèmes de classement.

Lorsque vous modifiez votre algorithme de classement de manière suffisamment radicale pour que des résultats différents s'affichent, vous modifiez effectivement les données que votre algorithme verra à l'avenir. Ce type de biais apparaîtra, et vous devez concevoir votre modèle en conséquence. Plusieurs approches sont possibles. 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 un impact considérable sur la probabilité que l'utilisateur interagisse avec celui-ci. Si vous placez une application en première position, elle sera cliquée plus souvent, et vous serez convaincu qu'elle a plus de chances d'être cliquée. Pour y remédier, vous pouvez ajouter des éléments géographiques, c'est-à-dire des éléments concernant la position du contenu sur la page. Vous entraînez votre modèle avec des caractéristiques de position, et il apprend à pondérer fortement, par exemple, la caractéristique "1ère position". Votre modèle accorde donc moins d'importance aux autres facteurs pour les exemples avec "1st­position=true". Ensuite, lors de la diffusion, vous n'attribuez aucune instance à la fonctionnalité de position ou vous leur attribuez toutes la même fonctionnalité par défaut, car vous évaluez les candidats avant de décider de l'ordre dans lequel les afficher.

Notez qu'il est important de séparer les éléments de position du reste du modèle en raison de cette asymétrie entre l'entraînement et le test. Il est idéal que le modèle soit la somme d'une fonction des éléments géographiques et d'une fonction du reste des éléments. Par exemple, ne croisez pas les éléments géographiques avec une fonctionnalité de document.

Règle 37: Mesurez le décalage entraînement/mise en service.

Plusieurs facteurs peuvent entraîner un biais au sens le plus général. 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'entraînement, 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 ML: ralentissement de la croissance, affinement de l'optimisation et modèles complexes

Certains signes indiquent que la deuxième phase touche à sa fin. Tout d'abord, vos gains mensuels commenceront à diminuer. Vous allez commencer à constater des compromis entre les métriques: certaines augmenteront et d'autres diminueront dans certaines expériences. C'est là que les choses deviennent intéressantes. Étant donné que les gains sont plus difficiles à obtenir, le machine learning doit être plus sophistiqué. Attention: cette section contient plus de règles d'ordre général que les sections précédentes. Nous avons vu de nombreuses équipes passer par les moments heureux de la phase I et de la phase II du machine learning. Une fois la phase III atteinte, les équipes doivent trouver leur propre chemin.

Règle 38: Ne perdez pas de temps sur de nouvelles fonctionnalités si des objectifs non alignés sont devenus le problème.

Lorsque vos mesures atteignent un plateau, votre équipe commence à examiner les problèmes qui ne relèvent pas des objectifs de votre système de machine learning actuel. Comme indiqué précédemment, si les objectifs produit ne sont pas couverts par l'objectif algorithmique existant, vous devez modifier votre objectif ou vos objectifs produit. Par exemple, vous pouvez optimiser les clics, les "J'aime" ou les téléchargements, mais prendre des décisions de lancement en partie en fonction des évaluations humaines.

Règle 39: Les décisions de lancement sont un proxy des objectifs à long terme du produit.

Alice a une idée pour réduire les pertes logistiques liées à la prédiction des installations. Elle ajoute une fonctionnalité. La perte logistique diminue. Lorsqu'elle effectue un test en direct, elle constate une augmentation du taux d'installation. Cependant, lors d'une réunion d'examen du lancement, quelqu'un lui fait remarquer que le nombre d'utilisateurs actifs quotidiens a chuté de 5%. L'équipe décide de ne pas lancer le modèle. Alice est déçue, mais elle réalise maintenant que les décisions de lancement dépendent de plusieurs critères, dont seuls certains peuvent être optimisés directement à l'aide du ML.

La vérité est que le monde réel n'est pas un jeu de rôle: il n'existe pas de "points d'impact" permettant d'identifier l'état de santé de votre produit. L'équipe doit utiliser les statistiques qu'elle collecte pour essayer de prédire efficacement la qualité du système à l'avenir. Ils doivent se soucier de l'engagement, des utilisateurs actifs sur un jour (UAJ), des utilisateurs actifs sur 30 jours (UAJ), des revenus et du retour sur investissement des annonceurs. Ces métriques mesurables dans les tests A/B ne sont en elles-mêmes qu'un proxy pour des objectifs plus à long terme: satisfaire les utilisateurs, augmenter le nombre d'utilisateurs, satisfaire les partenaires et générer des bénéfices, que vous pouvez même considérer comme des proxys pour disposer d'un produit utile et de haute qualité et d'une entreprise prospère dans cinq ans.

Les seules décisions de lancement faciles à prendre sont celles où toutes les métriques s'améliorent (ou du moins ne se détériorent pas). Si l'équipe a le choix entre un algorithme de machine learning sophistiqué et une heuristique simple, et que l'heuristique simple est plus efficace pour toutes ces métriques, elle doit choisir l'heuristique. De plus, il n'existe pas de classement explicite de toutes les valeurs de métrique possibles. Plus précisément, examinons les deux scénarios suivants:

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

Si le système actuel est A, il est peu probable que l'équipe passe à B. Si le système actuel est B, il est peu probable que l'équipe passe à A. Cela semble aller à l'encontre d'un comportement rationnel. Toutefois, les prédictions de modification des métriques peuvent ou non se réaliser, et il existe donc un risque important associé à chaque changement. Chaque métrique couvre un risque qui préoccupe l'équipe.

De plus, aucune métrique ne couvre la préoccupation ultime de l'équipe, à savoir "Où en sera mon produit dans cinq ans ?".

En revanche, les individus ont tendance à privilégier un objectif qu'ils peuvent optimiser directement. La plupart des outils de machine learning favorisent un tel environnement. Dans un tel environnement, un ingénieur qui développe de nouvelles fonctionnalités peut lancer un flux régulier de lancements. Un type de machine learning, l'apprentissage multi-objectif, commence à résoudre ce problème. Par exemple, vous pouvez formuler un problème de satisfaction des contraintes qui a des limites inférieures pour chaque métrique et qui optimise une combinaison linéaire de métriques. Toutefois, même dans ce cas, toutes les métriques ne peuvent pas facilement être définies comme des objectifs d'apprentissage automatique: si un utilisateur clique sur un document ou installe une application, c'est parce que le contenu a été présenté. Mais il est beaucoup plus difficile de comprendre pourquoi un utilisateur consulte votre site. La prédiction du succès futur d'un site dans son ensemble est une tâche d'IA complète: aussi difficile que la vision par ordinateur ou le traitement du langage naturel.

Règle 40: Faites simple.

Les modèles unifiés qui intègrent des fonctionnalités brutes et classent directement le contenu sont les modèles les plus faciles à déboguer et à comprendre. Toutefois, un ensemble de modèles (un "modèle" qui combine les scores d'autres modèles) peut fonctionner mieux. Pour simplifier les choses, chaque modèle doit être un ensemble ne prenant en compte que les entrées d'autres modèles ou un modèle de base prenant en compte de nombreuses fonctionnalités, mais pas les deux. Si vous avez des modèles en plus d'autres modèles entraînés séparément, les combiner peut entraîner un mauvais comportement.

Utilisez un modèle simple pour l'assemblage qui ne prend en entrée que la sortie de vos modèles de base. Vous souhaitez également appliquer des propriétés à ces modèles d'ensemble. Par exemple, une augmentation du score produit par un modèle de base ne doit pas diminuer le score de l'ensemble. De plus, il est préférable que les modèles entrants soient sémantiquement interprétables (par exemple, calibrés) afin que les modifications des modèles sous-jacents ne perturbent pas le modèle d'ensemble. De plus, assurez-vous 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 41: Lorsque les performances stagnent, recherchez de nouvelles sources d'informations qualitatives à ajouter plutôt que d'affiner les signaux existants.

Vous avez ajouté des informations démographiques sur l'utilisateur. Vous avez ajouté des informations sur les mots du document. Vous avez effectué une exploration de modèles et affiné la régularisation. Vous n'avez pas constaté d'amélioration de plus de 1% de vos métriques clés depuis quelques trimestres. Et maintenant ?

Il est temps de commencer à créer l'infrastructure pour des fonctionnalités radicalement différentes, telles que l'historique des documents auxquels cet utilisateur a accédé au cours du dernier jour, de la semaine ou de l'année, ou les donné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 à ajuster vos attentes en termes de retour sur investissement et développez vos efforts en conséquence. Comme dans tout projet d'ingénierie, vous devez peser les avantages de l'ajout de nouvelles fonctionnalités contre le coût d'une complexité accrue.

Règle 42: Ne vous attendez pas à ce que la diversité, la personnalisation ou la pertinence soient aussi corrélées à la popularité que vous le pensez.

La diversité dans un ensemble de contenus peut signifier plusieurs choses, la diversité de la source du contenu étant l'une des plus courantes. La personnalisation implique que chaque utilisateur obtient ses propres résultats. La pertinence implique que les résultats d'une requête particulière sont plus appropriés pour cette requête que pour toute autre. Par conséquent, ces trois propriétés sont définies comme étant différentes de l'ordinaire.

Le problème est que l'ordinaire est difficile à battre.

Notez que si votre système mesure les clics, le temps passé, les visionnages, les "+1", les partages, etc., vous mesurez la popularité du contenu. Les équipes tentent parfois d'apprendre un modèle personnel avec de la diversité. Pour personnaliser, ils ajoutent des fonctionnalités qui permettraient au système de personnaliser (certaines fonctionnalités représentant l'intérêt de l'utilisateur) ou de diversifier (des fonctionnalités indiquant si ce document présente des caractéristiques communes avec d'autres documents renvoyés, tels que l'auteur ou le contenu). Ils constatent que ces fonctionnalités sont moins pondérées (ou parfois associées à un signe différent) que prévu.

Cela ne signifie pas que la diversité, la personnalisation ou la pertinence ne sont pas utiles. Comme indiqué dans la règle précédente, vous pouvez effectuer un post-traitement pour augmenter la diversité ou la pertinence. Si vous constatez une augmentation des objectifs à plus long terme, vous pouvez affirmer que la diversité/pertinence est importante, en plus de la popularité. Vous pouvez ensuite continuer à utiliser votre post-traitement ou modifier directement l'objectif en fonction de la diversité ou de la pertinence.

Règle 43: Vos amis ont tendance à être les mêmes d'un produit à l'autre. Vos centres d'intérêt ne le sont généralement pas.

Les équipes de Google ont beaucoup tiré parti d'un modèle qui prédit la proximité d'une connexion dans un produit et qui fonctionne bien dans un autre. Vos amis sont ce qu'ils sont. D'un autre côté, j'ai vu plusieurs équipes se débattre avec les fonctionnalités de personnalisation entre les différents produits. Oui, il semble que cela devrait fonctionner. Pour le moment, il ne semble pas que ce soit le cas. Il est parfois possible d'utiliser les données brutes d'une propriété pour prédire le comportement d'une autre. N'oubliez pas que même savoir qu'un utilisateur a un historique sur une autre propriété peut être utile. Par exemple, la présence d'une activité utilisateur sur deux produits peut être indicative en soi.

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 nombreuses corrections, suggestions et exemples utiles pour ce document. Merci également à Kristen Lefevre, Suddha Basu et Chris Berg qui nous ont aidés à créer une version antérieure. Toutes les erreurs, omissions ou (oh ! mon Dieu !) opinions impopulaires sont les miennes.

Annexe

Ce document fait référence à divers produits Google. Pour fournir plus de contexte, je vous donne ci-dessous une brève description des exemples les plus courants.

Présentation de YouTube

YouTube est un service de streaming vidéo. 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. "À 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 la consultent.

Présentation de Google Play

Google Play propose de nombreux modèles qui résolvent divers problèmes. La recherche Play, les recommandations personnalisées de la page d'accueil Play et les applications "Utilisateurs ont également installé" utilisent toutes le machine learning.

Présentation de Google Plus

Google Plus utilisait le machine learning dans diverses situations: 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. Google Plus a fermé tous les comptes personnels en 2019 et a été remplacé par Google Currents pour les comptes professionnels le 6 juillet 2020.