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 disposant de connaissances de base en machine learning à profiter des bonnes pratiques de Google en la matière. Son style est semblable à celui du guide de style C++ de Google et d'autres guides populaires de programmation pratique. Si vous avez suivi un cours de machine learning, ou 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 seront utilisés à plusieurs reprises dans notre discussion sur l'efficacité du machine learning:

  • Instance: ce sur quoi vous souhaitez effectuer une prédiction. Par exemple, il peut s'agir d'une page Web que vous souhaitez classer comme "sur les chats" ou "pas sur les chats".
  • Étiquette: la réponse d'une tâche de prédiction. soit la réponse produite par un système de machine learning, soit la bonne réponse fournie dans les données d'entraînement. 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 associées, par exemple l'ensemble de tous les pays possibles dans lesquels les utilisateurs peuvent résider. Un exemple peut présenter une ou plusieurs caractéristiques dans une colonne de caractéristiques. Le terme "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 sur des exemples, puis vous l'utilisez 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 essaie d'optimiser.
  • Pipeline: infrastructure sur laquelle repose un algorithme de machine learning. Inclut la collecte des données depuis l'interface, leur intégration dans des fichiers de données d'entraînement, 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é:

faire du machine learning comme un excellent ingénieur, et non comme un excellent 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 découlent des caractéristiques et des algorithmes de machine learning performants. Donc, l'approche de base est la suivante:

  1. Assurez-vous que votre pipeline est robuste de bout en bout.
  2. Commencez par un objectif raisonnable.
  3. Ajoutez facilement des fonctionnalités basées sur le bon sens.
  4. Assurez-vous que votre pipeline reste solide.

Cette approche fonctionnera bien pendant une longue période. Ne vous écartez de cette approche que lorsqu'il n'existe plus d'astuces simples pour aller plus loin. La complexité croissante ralentit les versions futures.

Une fois que vous avez passé en revue les astuces simples, vous pouvez certes utiliser une technologie de machine learning de pointe dans votre avenir. Reportez-vous à la section sur la phase III des projets de machine learning.

Ce document est organisé comme suit:

  1. La première partie devrait vous aider à déterminer si le moment est opportun pour créer un système de machine learning.
  2. La deuxième partie traite du déploiement de votre premier pipeline.
  3. La troisième partie traite du lancement et des itérations lors de l'ajout de nouvelles caractéristiques à votre pipeline, et traite de l'évaluation des modèles et du décalage entraînement/inférence.
  4. La dernière partie explique ce qu'il faut faire lorsque vous atteignez un plateau.
  5. Vous trouverez ensuite la liste des travaux connexes et une annexe avec des 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, c'est cool, mais il a besoin de données. En théorie, vous pouvez prendre les données d'un autre problème, puis modifier le modèle pour un nouveau produit, mais les performances seront probablement inférieures aux heuristics de base. Si vous pensez que le machine learning peut améliorer vos performances de 100 %, une méthode heuristique vous permettra d'atteindre cet objectif.

Par exemple, si vous classez des applications sur une place de marché d'applications, vous pouvez utiliser le taux ou le nombre d'installations comme heuristique. Si vous détectez du spam, filtrez les éditeurs qui ont déjà envoyé du spam. N'hésitez pas non plus à faire appel à des modifications humaines. Si vous avez besoin de classer les contacts, classez les plus récemment utilisés en premier (ou même classez-les par ordre alphabétique). Si le machine learning n'est pas absolument nécessaire pour votre produit, ne l'utilisez pas tant que vous n'avez pas de données.

Règle n° 2: commencez par concevoir et implémenter des métriques

Avant de formaliser ce que fera votre système de machine learning, suivez autant que possible votre système actuel. Cette opération peut s'expliquer par les raisons suivantes:

  1. Il est plus facile d'obtenir l'autorisation des utilisateurs du système plus tôt.
  2. Si vous pensez que quelque chose pourrait être un problème à l'avenir, il est préférable d'obtenir des données historiques maintenant.
  3. Si vous concevez votre système en pensant à l'instrumentation des métriques, les choses se passeront mieux à l'avenir. Plus précisément, vous ne devez pas vous retrouver à fouiller les journaux à la recherche de chaînes pour instrumenter vos métriques.
  4. Vous verrez ce qui change et ce qui ne change pas. Par exemple, supposons que vous souhaitiez optimiser directement les utilisateurs actifs sur une journée. Toutefois, lors de vos premières manipulations du système, vous remarquerez peut-être que des modifications importantes de l'expérience utilisateur ne modifient pas sensiblement cette métrique.

L'équipe Google Plus mesure l'élargissement par lecture, les partages par lecture, plus un par lecture, les commentaires/lecture, les commentaires par utilisateur, les partages par utilisateur, etc. qu'elle utilise pour calculer la qualité d'un post au moment de la diffusion. Notez également qu'il est important de disposer d'un framework de test, dans lequel vous pouvez regrouper les utilisateurs dans des buckets et agréger des statistiques par test. Reportez-vous à la règle n° 12.

En adoptant une approche plus flexible concernant la collecte de métriques, vous pouvez obtenir une image plus large de votre système. Vous remarquez un problème ? Ajoutez une métrique pour en effectuer le suivi. Enthousiasmé par des changements quantitatifs sur la dernière version ? Ajoutez une métrique pour en effectuer le suivi.

Règle n° 3: privilégiez le machine learning à une méthode heuristique complexe

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

Phase I du ML: votre premier pipeline

Pour votre premier pipeline, concentrez-vous sur l'infrastructure de votre système. Même s'il est amusant d'envisager tout le machine learning imaginatif que vous allez réaliser, il sera difficile de comprendre ce qui se passe si vous ne faites pas d'abord confiance à votre pipeline.

Règle n° 4: optez pour un premier modèle simple et utilisez une infrastructure adaptée

Le premier modèle améliore le plus votre produit. Il n'est donc pas nécessaire d'être sophistiqué. Mais vous rencontrerez beaucoup plus de problèmes d'infrastructure que prévu. Avant de pouvoir utiliser votre nouveau système de machine learning sophistiqué, vous devez déterminer:

  • Comment obtenir des exemples pour votre algorithme d'apprentissage.
  • Une première définition de ce que "bon" et "mauvais" signifient pour votre système.
  • Comment intégrer le modèle à votre application. Vous pouvez appliquer le modèle en direct, ou précalculer le modèle sur des exemples hors connexion et stocker les résultats dans une table. Par exemple, vous pouvez préclassifier des pages Web et stocker les résultats dans une table, mais vous pouvez également classer les messages de chat en direct.

Choisissez des fonctionnalités simples pour vous 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 sur le serveur correctement.

Une fois que vous disposez d'un système qui effectue ces trois opérations de manière fiable, vous avez effectué la majeure partie du travail. Votre modèle simple vous fournit des métriques 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" : un premier lancement qui dépriorise explicitement les gains de machine learning pour éviter d'être distraits.

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 dédiées à l'apprentissage sont encapsulées afin que vous puissiez tester tout ce qui l'entoure. Notamment :

  1. Testez la transmission des données à l'algorithme. Vérifiez que les colonnes de caractéristiques qui doivent être renseignées sont bien renseignées. Si la confidentialité le permet, inspectez manuellement l'entrée de votre algorithme d'entraînement. Si possible, comparez les statistiques dans votre pipeline aux statistiques pour les mêmes données traitées ailleurs.
  2. Tester l'extraction de modèles de l'algorithme d'entraînement Assurez-vous que le score obtenu par le modèle dans votre environnement d'entraînement est le même que celui qu'il obtient dans votre environnement d'inférence (voir la règle n° 37).

Le machine learning comporte un élément d'imprévisibilité. Assurez-vous donc d'avoir des tests pour le code permettant de créer des exemples lors de l'entraînement et de l'inférence, et que vous pouvez charger et utiliser un modèle fixe lors de l'inférence. Il est également important de comprendre vos données: consultez nos conseils pratiques pour l'analyse d'ensembles de données volumineux et complexes.

Règle n° 6: faites attention aux données supprimées lors de la copie des pipelines

Souvent, nous créons un pipeline en copiant un pipeline existant (c'est-à-dire, la programme culte du cargo), et l'ancien pipeline perd les données dont nous avons besoin pour le nouveau pipeline. Par exemple, le pipeline pour "Populaire sur Google Plus" supprime les anciens posts (car il tente de classer les posts récents). Ce pipeline a été copié pour être utilisé avec le flux Google Plus, dans lequel 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. Ces données ne sont donc pas utiles si nous voulons modéliser la raison pour laquelle 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. Lors de l'utilisation de la page d'accueil des applications Play, un nouveau pipeline a été créé. Il contenait également des exemples issus de la page de destination de Play Jeux, sans aucune fonctionnalité permettant de déterminer la provenance de chaque exemple.

Règle n° 7: transformez des méthodes heuristiques en caractéristiques 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 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 un grand nombre de règles et d'heuristiques. Ces mêmes méthodes heuristiques peuvent vous améliorer si vous les ajustez avec le machine learning. Vos heuristiques doivent être extraites pour toutes sortes d'informations, et ce pour deux raisons. Tout d'abord, la transition vers un système de machine learning sera plus fluide. Deuxièmement, ces règles contiennent généralement une grande partie de l'intuition du système dont vous ne voulez pas vous débarrasser. Vous pouvez utiliser une méthode heuristique existante de quatre façons:

  • Effectuez un pré-traitement à l'aide de la méthode heuristique. Si la fonctionnalité est incroyablement géniale, alors c'est une option. Par exemple, si, dans un filtre antispam, 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 la plus logique pour les tâches de classification binaire.
  • Créez un élément géographique. Créer directement une caractéristique à partir de la méthode heuristique est un atout majeur. Par exemple, si vous utilisez une méthode heuristique pour calculer le score de pertinence d'un résultat de requête, vous pouvez inclure ce score en tant que valeur d'une caractéristique. Par la suite, vous souhaiterez peut-être utiliser des techniques de machine learning pour masser la valeur (par exemple, la convertir en un ensemble fini de valeurs discrètes ou la combiner avec d'autres caractéristiques), mais commencer par utiliser la valeur brute produite par la méthode heuristique.
  • Extrayez les entrées brutes de la méthode heuristique. S'il existe une heuristique pour les applications qui combine le nombre d'installations, le nombre de caractères du texte et le jour de la semaine, envisagez de séparer ces éléments et d'alimenter l'apprentissage séparément. Certaines techniques qui s'appliquent aux ensembles s'appliquent ici (voir la règle n° 40).
  • Modifiez le libellé. Cette option est utile lorsque vous pensez que l'heuristique capture des informations qui ne figurent pas actuellement dans l'étiquette. 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 le libellé par le nombre moyen d'étoiles reçues par l'application. La marge de manœuvre est ici considérable. Consultez la section Votre premier objectif.

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

Monitoring

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

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

À quel point les performances se dégradent-elles si l'un de vos modèles date d'une journée ? Une semaine ? Un quart d'âge ? Ces informations peuvent vous aider à comprendre les priorités de votre surveillance. Si vous perdez une qualité de produit significative si le modèle n'est pas mis à jour pendant une journée, il est logique qu'un ingénieur le surveille en permanence. La plupart des systèmes de diffusion d'annonces ont de nouvelles annonces à gérer chaque jour et doivent être mis à jour quotidiennement. Par exemple, si le modèle de ML pour la recherche sur Google Play n'est pas mis à jour, cela peut avoir un impact négatif en moins d'un mois. Certains modèles pour "Populaire sur Google Plus" ne comportent pas d'identifiant de post. Ils sont donc rarement exportés. Les autres modèles dotés d'identifiants de posts sont mis à jour beaucoup 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 permettant d'exporter le modèle pour l'inférence. En cas de problème avec un modèle exporté, il s'agit d'un problème visible par l'utilisateur.

Effectuez des contrôles d'intégrité juste 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. Si vous avez des inquiétudes concernant les données, n'exportez pas de modèle. De nombreuses équipes qui déploient en continu des modèles vérifient l'aire sous la courbe ROC (ou AUC) avant de procéder à 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 ceux concernant un modèle visible par l'utilisateur peuvent nécessiter une page. Il est donc préférable d'attendre et d'être sûr avant d'avoir un impact sur 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èmes. Supposons qu'une table jointe particulière ne soit plus mise à jour. Le système de machine learning s'adapte, et le comportement continue d'être raisonnablement bon et se dégrade progressivement. Il peut arriver que des tables soient obsolètes depuis plusieurs mois. Une simple actualisation améliore les performances plus que n'importe quel autre lancement de ce trimestre. La couverture d'une caractéristique peut changer en raison de modifications apportées à sa mise en œuvre. Par exemple, une colonne de caractéristiques peut être remplie dans 90% des exemples, puis chuter soudainement dans 60% des exemples. Un jour, Play a eu une table obsolète pendant six mois, et le simple fait d'actualiser la table a permis d'augmenter le taux d'installation de 2 %. Si vous suivez les statistiques des données et que vous inspectez parfois manuellement les données, vous pouvez réduire ce type d'échec.

Règle n° 11: attribuez des propriétaires pour les colonnes de caractéristiques et de la documentation

Si le système est volumineux et qu'il existe de nombreuses colonnes de caractéristiques, sachez qui a créé chaque colonne de caractéristiques ou en assure la maintenance. Si vous constatez que la personne qui comprend une colonne de caractéristiques quitte l'entreprise, assurez-vous que quelqu'un dispose de ces informations. Bien que de nombreuses colonnes de caractéristiques aient des noms descriptifs, il est bon d'avoir une description plus détaillée de la fonctionnalité, de sa provenance et de son utilité.

Votre premier objectif

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

Règle n° 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. Un grand nombre de métriques vous intéressent, et vous devez toutes les mesurer (voir la règle n° 2). Cependant, au début du processus de machine learning, vous remarquerez toutes une augmentation, même celles que vous n'optimisez pas directement. Par exemple, supposons que vous vous souciez du nombre de clics et du temps passé sur le site. Si vous optimisez votre campagne pour le nombre de clics, vous constaterez probablement une augmentation du temps passé.

Par conséquent, restez simple et ne réfléchissez pas trop à l'équilibre entre différentes métriques, alors que vous pouvez toujours augmenter facilement toutes les métriques. Ne poussez pas cette règle à l'extrême: ne confondez pas votre objectif avec la santé ultime du système (voir la règle n° 39). Par ailleurs, si vous augmentez la métrique directement optimisée, mais que vous décidez de ne pas le lancer, une révision de l'objectif peut être nécessaire.

Règle n° 13: choisissez une métrique simple, observable et attribuable pour votre premier objectif

Souvent, vous ne savez pas quel est le véritable objectif. Vous pensez que c'est le cas, mais alors que vous regardez les données et l'analyse côte à côte de votre ancien système et de votre nouveau système de ML, vous vous rendez compte que vous souhaitez ajuster l'objectif. De plus, les différents membres de l'équipe ne sont souvent pas d'accord sur le véritable objectif. L'objectif de ML doit être facile à mesurer et être un indicateur du "véritable" objectif. En fait, il n'y a souvent pas de "vrai" objectif (voir la règle n° 39). Effectuez donc l'entraînement sur l'objectif de ML simple et envisagez de disposer d'une "couche de règle" en plus qui vous permet d'ajouter une logique supplémentaire (en principe une logique très simple) pour effectuer le classement final.

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

  • Avez-vous cliqué sur ce lien classé ?
  • Cet objet classé a-t-il été téléchargé ?
  • Cet objet classé a-t-il été transféré/envoyé ou envoyé par e-mail ?
  • Cet objet classé a-t-il été évalué ?
  • L'objet affiché a-t-il été marqué comme spam, pornographique ou choquant ?

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

  • L'utilisateur est-il venu le jour suivant ?
  • Combien de temps l'utilisateur a-t-il visité le site ?
  • Quels étaient les utilisateurs actifs par jour ?

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

Enfin, n'essayez pas de faire appel au machine learning pour déterminer:

  • 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 cela affectera-t-il la santé globale de l'entreprise ?

Tous ces éléments sont importants, mais ils sont aussi incroyablement 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, 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

Les régressions linéaires, logistiques et 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. Cela les rend plus faciles à déboguer que les modèles qui utilisent des objectifs (perte nulle, différentes pertes limites, etc.) qui tentent d'optimiser directement la précision ou les performances de classement. Par exemple, si des probabilités d'entraînement s'écartent de probabilités prédites côte à côte ou lors de l'inspection du système de production, cet écart peut révéler un problème.

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

Les modèles simples facilitent la gestion des boucles de rétroaction (voir la règle n° 36). Nous utilisons souvent ces prédictions probabilistes pour prendre une décision, par exemple pour classer les posts par ordre décroissant de valeur attendue (c'est-à-dire la probabilité de clic/téléchargement, etc.). Cependant, n'oubliez pas que lorsque vous devez 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 antispam et le classement qualitatif dans une couche de règles

Le classement de la qualité est un art, mais le filtrage antispam est une guerre. Les utilisateurs de votre système comprendront clairement les signaux que vous utilisez pour déterminer les posts de haute qualité. Ils modifieront leurs publications pour disposer de ces propriétés. Votre classement doit donc être axé sur le classement des contenus publiés de bonne foi. Vous ne devez pas négliger l'apprenant de classement en fonction de la qualité pour un classement élevé du spam. De même, le contenu pour adultes doit être traité séparément du classement qualitatif. Le filtrage antispam est une approche différente. Attendez-vous à ce que les caractéristiques que vous devez générer changent constamment. Souvent, vous appliquez des règles évidentes au système (si un post a plus de trois votes "spam", ne le récupérez pas, etc.). Tout modèle appris devra être mis à jour quotidiennement, si ce n'est plus rapidement. La réputation du créateur du contenu jouera un grand rôle.

À un certain niveau, la sortie de ces deux systèmes devra être intégrée. N'oubliez pas que le filtrage du spam dans les résultats de recherche devrait probablement être plus agressif que le filtrage du spam dans les e-mails. En outre, il est courant de supprimer le spam des données d'entraînement pour le classificateur de qualité.

Phase II du ML: Extraction de caractéristiques

Au cours de la première phase du cycle de vie d'un système de machine learning, les problèmes importants consistent à transférer les données d'entraînement dans le système d'apprentissage, à instrumenter les métriques qui vous intéressent et à créer une infrastructure d'inférence. 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.

La deuxième phase comporte de nombreux fruits faciles à prendre en main. Différentes fonctionnalités évidentes peuvent être intégrées au système. La deuxième phase du machine learning implique donc d'intégrer autant de caractéristiques que possible et de les combiner de manière intuitive. Au cours de cette phase, toutes les métriques devraient continuer à augmenter. De nombreux lancements seront prévus, et c'est le moment idéal pour réunir de nombreux ingénieurs qui pourront regrouper toutes les données dont vous avez besoin pour créer un système d'apprentissage vraiment génial.

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

Ne vous attendez pas à ce que le modèle sur lequel vous travaillez actuellement soit le dernier que vous lancerez, ni même que vous arrêteriez un jour de le faire. Déterminez donc si la complexité que vous ajoutez avec ce lancement ralentira les futurs lancements. De nombreuses équipes ont lancé un modèle au moins une fois par trimestre depuis des années. Il existe trois raisons fondamentales de lancer de nouveaux modèles:

  • Vous découvrez de nouvelles fonctionnalités.
  • Vous réglez la régularisation et combinez d'anciennes caractéristiques de façon nouvelle.
  • Vous ajustez l'objectif.

Quoi qu'il en soit, donner un peu d'amour à un modèle peut être une bonne chose: examiner les données qui alimentent l'exemple peut aider à identifier de nouveaux signaux et d'anciens signaux cassés. Lorsque vous créez votre modèle, réfléchissez à la facilité avec laquelle vous pouvez ajouter, supprimer ou recombiner des caractéristiques. 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'avoir deux ou trois copies exécutées en parallèle. Enfin, ne vous demandez pas si la fonctionnalité 16 sur 35 entre dans cette version du pipeline. Elle le sera au trimestre prochain.

Règle n° 17: commencez avec des caractéristiques directement observées et signalées, et non des caractéristiques apprises

Ce point peut être controversé, mais cela évite de nombreux pièges. Tout d'abord, voyons 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, à l'aide d'un modèle factorisé ou de deep learning). Ces deux méthodes peuvent être utiles, mais elles peuvent présenter de nombreux problèmes. Elles ne doivent donc pas se trouver dans le premier modèle.

Si vous utilisez un système externe pour créer une caractéristique, n'oubliez pas qu'il a son propre objectif. L'objectif du système externe peut n'être que faiblement corrélé à 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, la signification peut changer. Si vous utilisez un système externe pour fournir une fonctionnalité, sachez que cette approche demande beaucoup de soin.

Le principal problème avec les modèles factorisés et profonds est qu'ils ne sont pas convexes. Ainsi, rien ne garantit qu'une solution optimale pourra être approchée ou trouvée, et les minimums locaux trouvés à chaque itération peuvent être différents. Avec cette variation, il est difficile de déterminer si l'impact d'une modification de votre système est significatif ou aléatoire. En créant un modèle sans caractéristiques profondes, vous pouvez obtenir d'excellentes performances de référence. Une fois cette référence obtenue, vous pouvez essayer des approches plus ésotériques.

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

Souvent, un système de machine learning ne représente qu'une petite partie d'une vue bien plus globale. Par exemple, imaginons qu'un post puisse être utilisé dans "Populaire sur Google+". De nombreux internautes lui attribueront le +1, le partageront ou le commenteront avant même qu'il n'y apparaisse. Si vous fournissez ces statistiques au apprenant, celui-ci peut promouvoir de nouveaux posts pour lesquels il ne dispose d'aucune donnée dans le contexte qu'il optimise. La fonctionnalité "Ma sélection" de YouTube peut utiliser le nombre de visionnages, ou co-visionnages (nombre de fois où une vidéo a été regardée après une autre) dans la recherche YouTube. Vous pouvez également utiliser des notes explicites des utilisateurs. Enfin, si vous utilisez une action utilisateur comme étiquette, voir cette action sur le document dans un contexte différent peut être une excellente fonctionnalité. Toutes ces fonctionnalités vous permettent d'intégrer du nouveau contenu dans le contexte. Notez qu'il ne s'agit pas d'une question de personnalisation. Vous devez d'abord déterminer si un utilisateur aime le contenu dans ce contexte, puis déterminer qui l'aime plus ou moins.

Règle n° 19: utilisez des caractéristiques très spécifiques lorsque vous le pouvez

Avec des tonnes de données, il est plus simple d'apprendre des millions de caractéristiques simples que quelques caractéristiques complexes. Les identifiants des documents récupérés et les requêtes canoniques n'offrent pas une grande généralisation, mais alignent votre classement sur vos étiquettes pour les requêtes principales. Par conséquent, n'ayez pas peur des groupes de caractéristiques dont chaque caractéristique 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 s'appliquent à trop peu d'exemples.

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

Il existe plusieurs 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 à prendre une caractéristique continue et à en créer de nombreuses caractéristiques discrètes. Pensez à utiliser une caractéristique continue comme l'âge. Vous pouvez créer une caractéristique égale à 1 lorsque l'âge est inférieur à 18 ans, une autre caractéristique égale à 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 fourniront la majeure partie de l'impact.

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, {homme, femme}, {États-Unis, Canada, Mexique}, etc.). Un croisement est une nouvelle colonne de caractéristiques comportant, par exemple, {homme, femme} × {États-Unis,Canada, Mexique}. Cette nouvelle colonne de caractéristiques 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 des exemples représentant des hommes au Canada. Notez que d'énormes quantités de données sont nécessaires 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 un surapprentissage. Par exemple, imaginez que vous effectuez une recherche, que vous disposez d'une colonne de caractéristiques contenant des mots dans la requête et d'une colonne de caractéristiques contenant des mots du document. Vous pouvez les combiner avec un croisement, mais vous vous retrouverez avec de nombreuses caractéristiques (voir la règle n° 21).

Lorsque vous travaillez avec du texte, il existe deux alternatives. 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 est une intersection: une caractéristique est donc 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 des 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 en termes de théorie de l'apprentissage statistique concernant le niveau de complexité approprié d'un modèle, mais cette règle est essentiellement tout ce que vous devez savoir. J'ai eu des conversations au cours desquelles les gens doutaient que tout puisse être appris à partir de mille exemples, ou que vous auriez besoin de plus d'un million d'exemples, car ils se retrouvent coincés dans une certaine méthode d'apprentissage. L'essentiel est d'adapter votre apprentissage au volume de vos données:

  1. Si vous travaillez sur un système de classement de recherche, que les documents et la requête contiennent des millions de mots différents 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, TF-IDF et une demi-douzaine d'autres caractéristiques hautement conçues par l'humain. 1 000 exemples, une douzaine de fonctionnalités.
  2. Si vous disposez d'un million d'exemples, croisez les colonnes de caractéristiques du document et de la requête, en utilisant la régularisation et éventuellement la sélection de caractéristiques. Vous obtiendrez ainsi des millions de caractéristiques, mais vous en aurez moins avec 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 jetons de document et de requête, en utilisant la sélection et la régularisation 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 donne d'excellents conseils pour commencer.

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

Règle n° 22: nettoyez les caractéristiques que vous n'utilisez plus

Les caractéristiques inutilisées génèrent une dette technique. Si vous constatez que vous n'utilisez pas une caractéristique et que sa combinaison avec d'autres caractéristiques ne fonctionne pas, retirez-la de votre infrastructure. Vous souhaitez que votre infrastructure reste propre afin que les fonctionnalités les plus prometteuses puissent être testées le plus rapidement possible. Si nécessaire, quelqu'un peut toujours ajouter de nouveau votre fonctionnalité.

Tenez compte de votre couverture lorsque vous réfléchissez aux fonctionnalités à ajouter ou à conserver. Combien d'exemples sont couverts par cette fonctionnalité ? Par exemple, si vous disposez de quelques fonctionnalités de personnalisation, mais que seulement 8% de vos utilisateurs en disposent, ce ne sera pas très efficace.

Parallèlement, certaines caractéristiques peuvent dépasser leur poids. Par exemple, si l'une de vos caractéristiques ne couvre que 1% des données, mais que 90% des exemples qui présentent cette caractéristique sont positifs, vous pouvez l'ajouter.

Analyse humaine du système

Avant de passer à la troisième phase du machine learning, il est important de se concentrer sur une notion qui n'est enseignée dans aucun cours de machine learning: comment examiner un modèle existant et l'améliorer. C'est plus un art qu'une science, et pourtant, il existe plusieurs antimodèles qu'il est utile d'éviter.

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

C'est peut-être le moyen le plus simple 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 vérifier si les performances sont correctes. Bien qu'un changement qui est manifestement mauvais ne doive pas être utilisé, tout ce qui semble raisonnablement proche 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 par le biais d'un test en direct sur des utilisateurs réels.

Il y a deux raisons à cela. Premièrement, vous êtes trop proche du code. Vous recherchez peut-être un aspect particulier des publications, ou vous êtes simplement trop impliqué émotionnellement (par exemple, biais de confirmation). La seconde est que votre temps est trop précieux. Considérez le coût de neuf ingénieurs réunissant une heure de réunion et réfléchissez au nombre d'étiquettes humaines sous contrat qui sont achetées sur une plate-forme de crowdsourcing.

Si vous souhaitez vraiment connaître les commentaires des utilisateurs, utilisez des méthodologies d'expérience utilisateur. Créez des personnages d'utilisateurs (vous trouverez une description dans le document Sketching User Experiences de Bill Buxton) au début du processus et testez la facilité d'utilisation (l'une des descriptions est dans Don't Make Me Think de Steve Krug) ultérieurement. Les personnages utilisateurs impliquent la création d'un utilisateur hypothétique. Par exemple, si votre équipe est entièrement masculine, il peut être utile de concevoir un personnage de femme de 35 ans (avec les caractéristiques utilisateur) et d'examiner les résultats qu'il génère plutôt que 10 résultats pour des hommes de 25 à 40 ans. Le fait d'inviter des personnes réelles à observer leur réaction face à votre site (localement ou à distance) lors des tests d'usabilité peut également vous offrir une nouvelle perspective.

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 effectuer avant que les utilisateurs ne regardent votre nouveau modèle consiste à calculer la différence entre les nouveaux résultats et la production. Par exemple, en cas de problème de classement, exécutez les deux modèles sur un échantillon de requêtes sur l'ensemble du système et examinez l'ampleur de la différence symétrique des résultats (pondérée par la position dans le classement). Si la différence est très faible, vous pouvez savoir sans réaliser de test que les modifications seront minimes. Si la différence est très 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. Assurez-vous qu'un modèle présente une différence symétrique faible (idéalement nulle) par rapport à lui-même.

Règle n° 25: lors du choix des modèles, les performances utilitaires l'emportent sur les performances prédictives

Votre modèle peut tenter de prédire le taux de clics. Cependant, la question clé est de savoir ce que vous en faites. 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évoyez la probabilité qu'un document soit du spam et que vous avez défini une limite pour ce qui est bloqué, la précision de ce qui est autorisé est plus importante. La plupart du temps, ces deux éléments devraient être en accord: s'ils ne sont pas d'accord, le gain sera probablement faible. Ainsi, si des modifications améliorent la perte logistique, mais dégradent les performances du système, recherchez une autre caractéristique. Lorsque cela se produira le plus souvent, il est temps de revoir l'objectif de votre modèle.

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

Supposons que vous voyiez un exemple d'entraînement dans lequel le modèle s'est trompé. 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 a été classé à un niveau inférieur à celui d'un négatif. Le point le plus important est qu'il s'agit d'un exemple dont le système de machine learning a conscience qu'il s'agit d'une erreur et qu'il souhaite corriger s'il en a l'occasion. Si vous donnez au modèle une fonctionnalité qui lui permet 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, la fonctionnalité sera ignorée. Par exemple, supposons qu'un utilisateur recherche "jeux sans frais" dans la recherche d'applications sur Google Play. Supposons que l'un des meilleurs résultats soit une application gag moins pertinente. Vous allez donc créer une fonctionnalité pour les "applications gag". Toutefois, si vous maximisez le nombre d'installations et que les utilisateurs installent une application gag lorsqu'ils recherchent des jeux sans frais, la fonctionnalité "applications gag" n'aura pas l'effet escompté.

Une fois que vous avez des exemples d'erreurs du modèle, recherchez des tendances qui sortent de votre ensemble de caractéristiques actuel. Par exemple, si le système semble rétrograder les articles plus longs, ajoutez leur longueur. Ne soyez pas trop précis sur les caractéristiques que vous ajoutez. Si vous ajoutez la longueur des articles, 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 n° 21). C'est le moyen le 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 à être 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 qu'il faut pour transformer leurs aléas en chiffres solides. Par exemple, s'il pense que trop d'applications gag sont affichées dans la recherche Play, ils peuvent demander à des évaluateurs manuels d'identifier ces applications. Dans ce cas, vous pouvez tout à fait utiliser des données étiquetées manuellement, car une part relativement petite des requêtes représente une part importante du trafic. Si vos problèmes sont mesurables, vous pouvez commencer à les utiliser comme caractéristiques, objectifs ou métriques. La règle générale est "mesurer d'abord, optimiser ensuite".

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

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 constaterez que son comportement est presque identique à celui de votre système actuel, tant pour les tests A/B et les tests A/B. En raison de sa simplicité, vous allez donc le lancer. Cependant, vous remarquez qu'aucune nouvelle application ne s'affiche. Pourquoi ? Étant donné que votre système n'affiche qu'un document en fonction de son propre historique avec cette requête, il n'existe aucun moyen d'apprendre qu'un nouveau document doit être affiché.

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

Décalage entraînement/inférence

Le décalage entraînement/inférence est une différence entre les performances pendant l'entraînement et les performances pendant l'inférence. Voici les causes possibles de ce décalage:

  • Écart entre la manière dont vous gérez les données dans les pipelines d'entraînement et d'inférence.
  • Il s'agit d'un changement dans les données entre le moment de l'entraînement et le moment de l'inférence.
  • Boucle de rétroaction entre votre modèle et votre algorithme.

Nous avons constaté que les systèmes de machine learning de production de Google présentent un décalage entraînement/inférence qui a un impact négatif sur les performances. La meilleure solution consiste à le surveiller explicitement afin que les modifications apportées au système et aux données n'introduisent pas de décalage inaperçu.

Règle n° 29: le meilleur moyen de vous assurer que l'entraînement est semblable à l'inférence consiste à enregistrer l'ensemble de caractéristiques utilisé au moment de l'inférence, puis à diriger ces caractéristiques vers un journal pour les utiliser lors 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 l'inférence et l'entraînement (voir la règle n° 37). Les équipes qui ont effectué cette mesure chez Google ont parfois été surprises des résultats. La page d'accueil de YouTube est passée à la journalisation des caractéristiques au moment de l'inférence, avec des améliorations significatives de la qualité et une réduction de la complexité du code. De nombreuses équipes changent donc d'infrastructure à ce moment-là.

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

Lorsque vous avez trop de données, vous êtes 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, la pondération de l'importance est préférable pour le reste. Avec la pondération d'importance, si vous décidez d'échantillonner l'exemple X avec une probabilité de 30 %, vous devez lui attribuer une pondération de 10/3. Avec la pondération selon l'importance, toutes les propriétés de calibrage décrites dans la règle n° 14 restent valables.

Règle n° 31: n'oubliez pas que si vous joignez des données d'une table au moment de l'entraînement et de l'inférence, les données de la table peuvent changer.

Supposons que vous rejoigniez les identifiants de documents avec une table contenant les caractéristiques de ces documents (telles que le nombre de commentaires ou de clics). Entre l'entraînement et l'inférence, les caractéristiques de la table peuvent être modifiées. La prédiction de votre modèle pour le même document peut alors différer entre l'entraînement et l'inférence. Le moyen le plus simple d'éviter ce type de problème consiste à consigner les caractéristiques au moment de la diffusion (voir la règle n° 32). Si la table ne change que lentement, vous pouvez également créer 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 toujours pas complètement le problème.

Règle n° 32: dans la mesure du possible, réutilisez le code entre votre pipeline d'entraînement et votre pipeline d'inférence

Le traitement par lot est différent du traitement en ligne. Dans le traitement en ligne, vous devez gérer chaque requête à son arrivée (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, créer une jointure). Au moment de l'inférence, vous effectuez un traitement en ligne, tandis que l'entraînement est un traitement par lot. Vous pouvez toutefois le réutiliser. Par exemple, vous pouvez créer un objet propre à votre système, dans lequel le résultat des requêtes ou des jointures peut être stocké de manière très lisible par l'humain, et les erreurs peuvent être testées facilement. Ensuite, une fois que vous avez rassemblé toutes les informations, lors de l'inférence ou de l'entraînement, vous exécutez une méthode courante pour faire le lien entre l'objet lisible propre à votre système et le format attendu par le système de machine learning. Cela élimine une source de décalage entraînement/inférence. En conséquence, essayez de ne pas utiliser deux langages de programmation différents entre l'entraînement et l'inférence. Si vous prenez cette décision, il vous sera presque impossible de partager votre 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 les données collectées après celles sur lesquelles vous l'avez entraîné, car cela reflète mieux le comportement 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. Vous vous attendez à ce que les performances ne soient pas aussi bonnes sur les nouvelles données, mais elles ne devraient pas être radicalement pires. Étant donné que des effets quotidiens peuvent se produire, vous ne pourrez peut-être pas prédire le taux de clics ou de conversion moyen, mais l'aire sous la courbe, qui représente la probabilité d'attribuer à l'exemple positif un score supérieur à celui d'un exemple négatif, devrait être raisonnablement proche.

Règle n° 34: dans la classification binaire pour le filtrage (par exemple, pour détecter un spam ou identifier les e-mails intéressants), faites de petits sacrifices à court terme en termes de performances pour des données très propres.

Dans une tâche de filtrage, les exemples marqués comme négatifs ne sont pas visibles par l'utilisateur. Supposons que vous ayez un filtre qui bloque 75% des exemples négatifs lors de la diffusion. Vous pourriez être tenté de tirer 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.

Mais cette approche introduit un biais d’échantillonnage. Vous pouvez collecter des données plus propres si, lors de la diffusion, vous étiquetez 1% de l'ensemble du trafic comme "exclus" et envoyez tous les exemples bloqués à l'utilisateur. Votre filtre bloque désormais au moins 74% des exemples négatifs. Ces exemples exclus peuvent devenir vos données d'entraînement.

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 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 de manière assez précise.

Règle n° 35: méfiez-vous du décalage inhérent aux problèmes de classement

Lorsque vous modifiez votre algorithme de classement de façon suffisamment radicale pour qu'il affiche des résultats différents, cela signifie que vous avez modifié les données que votre algorithme va voir à l'avenir. Ce type de décalage s'affiche, et vous devez concevoir votre modèle autour d'eux. Il existe plusieurs approches différentes. Ces approches sont toutes des façons de favoriser les données que votre modèle a déjà vues.

  1. Régularisez davantage les caractéristiques qui couvrent un plus grand nombre de requêtes plutôt que celles qui ne concernent qu'une seule requête. De cette façon, le modèle privilégie les caractéristiques propres à une ou plusieurs requêtes par rapport à celles qui sont généralisées à toutes les requêtes. Cette approche peut aider à éviter la fuite de résultats très populaires dans des requêtes non pertinentes. Notez que cette approche est contraire à l'avis plus conventionnel suivant : il faut davantage de régularisation sur les colonnes de caractéristiques comportant un plus grand nombre de valeurs uniques.
  2. N'autoriser que les caractéristiques à avoir des pondérations positives. Ainsi, toute bonne caractéristique sera meilleure qu'une caractéristique "inconnue".
  3. ne disposent pas de fonctionnalités liées aux documents uniquement ; Il s'agit d'une version extrême de la n° 1. Par exemple, même si une application donnée est un téléchargement populaire, quelle que soit la requête, vous ne voulez pas l'afficher partout. L'absence de fonctionnalités de document uniquement simplifie les choses. La raison pour laquelle vous ne voulez pas afficher une application populaire spécifique partout est liée à l'importance de rendre toutes les applications souhaitées accessibles. Par exemple, si une personne recherche une "application d'observation des oiseaux", elle peut télécharger "angry birds", mais ce n'était certainement pas son intention. Présenter une telle application peut 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 lui. Si vous placez une application en première position, les utilisateurs cliqueront plus souvent dessus, et vous serez convaincu que les utilisateurs auront plus tendance à cliquer dessus. Pour résoudre ce problème, vous pouvez ajouter des caractéristiques de position, c'est-à-dire des caractéristiques relatives à la position du contenu sur la page. Vous entraînez votre modèle avec des caractéristiques de position et il apprend à pondérer de manière intensive (la "1re position" par exemple). Ainsi, votre modèle donne moins de poids aux autres facteurs pour les exemples avec "1stposition=true". Ensuite, lors de l'inférence, vous ne donnez à aucune instance la caractéristique de position ou vous donnez à toutes la même caractéristique 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 quelque peu les caractéristiques de position du reste du modèle en raison de cette asymétrie entre l'entraînement et les tests. Le fait que le modèle soit la somme d'une fonction des caractéristiques de position et d'une fonction des autres caractéristiques est idéal. Par exemple, ne croisez pas les caractéristiques de position avec une caractéristique de document.

Règle n° 37: mesurez le décalage de l'entraînement/de l'inférence

Au sens le plus général, un décalage peut être dû à plusieurs facteurs. Vous pouvez également le diviser en plusieurs parties:

  • Différence entre les performances sur les données d'entraînement et sur les données exclues. En général, cela existe toujours, et ce n'est pas toujours une mauvaise chose.
  • Différence entre les performances sur les données exclues et les données du jour suivant. Encore une fois, cela existera toujours. Vous devez ajuster votre régularisation pour maximiser les performances du jour suivant. Toutefois, une baisse importante 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 "le 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'inférence, vous devriez obtenir exactement le même résultat (voir la règle n° 5). Une telle différence est donc probablement due à 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 commencent à diminuer. Vous commencerez alors à faire des compromis entre les métriques: vous constaterez une hausse et d'autres une diminution d'autres dans certains tests. C'est là que ça devient intéressant. Comme les gains sont plus difficiles à obtenir, le machine learning doit devenir plus sophistiqué. Attention: Cette section comporte plus de règles "bleu" que les sections précédentes. De nombreuses équipes passent par les phases I et II du machine learning. Une fois la phase III atteinte, les équipes doivent trouver leur propre voie.

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

Lorsque vos mesures stagnent, votre équipe commence à examiner les problèmes qui sortent du champ d'application 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 votre objectif ou celui de votre produit. Par exemple, vous pouvez optimiser les clics, les +1 ou les téléchargements, mais prendre des décisions de lancement en partie en vous appuyant 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 fonctionnalité. La perte logistique chute. Lorsqu'elle effectue un test en direct, elle constate que le taux d'installation augmente. Toutefois, lorsqu'elle se rend à une réunion d'examen de lancement, quelqu'un souligne 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 elle réalise maintenant que les décisions de lancement dépendent de plusieurs critères, dont seuls certains peuvent être directement optimisés à l'aide du ML.

En fait, le monde réel n'est pas des donjons ni des dragons: il n'y a pas de "points de vie" permettant d'identifier l'état de santé de votre produit. L'équipe doit utiliser les statistiques collectées pour essayer de prédire efficacement la qualité du système à l'avenir. Ils doivent se soucier de l'engagement, des utilisateurs actifs sur 1 jour, de 30 UAJ, des revenus et du retour sur investissement de l'annonceur. Ces métriques, qui sont mesurées en elles-mêmes dans les tests A/B, ne constituent qu'un indicateur d'objectifs à plus long terme: satisfaire les utilisateurs, augmenter le nombre d'utilisateurs, satisfaire les partenaires et les bénéfices. Même dans ce cas, vous pouvez envisager des proxys pour avoir un produit utile et de haute qualité et une entreprise florissante dans cinq ans.

Les seules décisions de lancement faciles sont celles où toutes les métriques s'améliorent (ou du moins ne s'aggravent pas). Si l'équipe a le choix entre un algorithme de machine learning sophistiqué et une heuristique simple, et que cette méthode fonctionne mieux pour toutes ces métriques, elle doit opter pour la méthode heuristique. De plus, il n'existe pas de classement explicite de toutes les valeurs de métriques possibles. Plus précisément, considérez les deux scénarios suivants:

Expérimentation Nombre d'utilisateurs actifs par jour Revenu/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 au B. Si le système actuel est B, il est peu probable que l'équipe passe à l'état A. Cela semble être en conflit avec le comportement rationnel. Cependant, les prédictions d'une modification des métriques peuvent ou non se réaliser, et chaque modification présente un risque important. Chaque métrique couvre un risque dont l'équipe est préoccupée.

De plus, aucune métrique ne couvre la préoccupation ultime de l'équipe : "où sera mon produit dans cinq ans ?"

Au contraire, les individus ont tendance à privilégier un objectif qu'ils peuvent optimiser directement. La plupart des outils de machine learning favorisent un tel environnement. Un ingénieur qui introduit de nouvelles caractéristiques peut obtenir un flux constant de lancements dans un tel environnement. Il existe un type de ML, l'apprentissage multi-objectif, qui commence à régler ce problème. Par exemple, on peut formuler un problème de satisfaction associé à des contraintes dont les limites sont inférieures pour chaque métrique et qui optimise une combinaison linéaire de métriques. Cependant, même dans ce cas, toutes les métriques ne peuvent pas être facilement définies comme des objectifs de machine learning: si l'utilisateur clique sur un document ou si une application est installée, c'est parce que le contenu a été affiché. Mais il est beaucoup plus difficile de comprendre pourquoi un utilisateur visite votre site. La manière de prédire le succès futur d'un site dans son ensemble est une approche IA complète, 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. Toutefois, un ensemble de modèles (un "modèle" qui combine les scores d'autres modèles) peut mieux fonctionner. Pour simplifier les choses, chaque modèle doit soit être un ensemble n'acceptant que les entrées d'autres modèles, soit un modèle de base acceptant de nombreuses caractéristiques, mais pas les deux. Si certains de vos modèles sont entraînés séparément, leur combinaison peut entraîner un comportement insatisfaisant.

Utilisez un modèle simple pour l'assemblage, qui n'accepte que la sortie de vos modèles "de base" comme entrées. Vous souhaitez également appliquer des propriétés à ces modèles d'ensemble. Par exemple, l'augmentation du score produit par un modèle de base ne doit pas diminuer le score de l'ensemble. En outre, il est préférable que les modèles entrants soient interprétables sémantiquement (par exemple, calibrés) afin que les modifications apportées aux 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 de nouvelles sources d'informations qualitatives à ajouter au lieu 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 exploré les modèles et ajusté la régularisation. Vous n'avez pas constaté de lancement avec une amélioration de plus de 1% de vos métriques clés depuis quelques trimestres. Il est temps d'agir !

Il est temps de commencer à créer l'infrastructure pour des caractéristiques radicalement différentes, telles que l'historique des documents auxquels cet utilisateur a accédé le jour, la semaine ou l'année précédents, ou les données d'une autre propriété. Utilisez des entités wikidata ou des éléments internes à votre entreprise (comme le Knowledge Graph de Google). Utilisez le deep learning. Commencez à ajuster vos attentes quant au retour sur investissement attendu, puis 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 d'une complexité accrue.

Règle n° 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 contenu peut signifier plusieurs choses, la diversité de la source du contenu étant l'une des plus courantes. La personnalisation implique que chaque utilisateur obtienne 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. Ces trois propriétés sont donc définies comme étant différentes de l'ordinaire.

Le problème, c'est que la routine a tendance à être difficile à battre.

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'apprendre un modèle personnel avec de la diversité. Pour personnaliser, ils ajoutent des fonctionnalités qui permettent au système de personnaliser (certaines caractéristiques représentant l'intérêt de l'utilisateur) ou de se diversifier (des caractéristiques indiquant si ce document a des caractéristiques en commun avec d'autres documents renvoyés, tels que l'auteur ou le contenu), et constater que ces caractéristiques ont moins de poids (ou parfois un signe différent) que prévu.

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 les objectifs à plus long terme augmentent, vous pouvez affirmer que la diversité/la pertinence est précieuse, en dehors de la popularité. Vous pouvez ensuite continuer à utiliser votre post-traitement ou modifier directement l'objectif en fonction de sa diversité ou de sa pertinence.

Règle n° 43: vos amis ont tendance à être les mêmes pour différents produits Vos centres d'intérêt ont tendance à ne pas l'être.

Les équipes Google ont beaucoup tiré parti du fait qu'un modèle prédise la proximité d'une connexion dans un produit et qu'il fonctionne bien sur 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 pour toutes les divisions de produits. Oui, cela devrait fonctionner. Pour l'instant, il semble que ce n'est pas le cas. Ce qui a parfois fonctionné, c'est utiliser les 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 comme en externe.

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 Andke Merci également à Kristen Lefevre, Suddha Basu et Chris Berg pour leur aide sur une version antérieure. Les erreurs, les omissions ou, (oulah !), les opinions impopulaires sont les miennes.

Annexe

Ce document fait référence à différentes références aux produits Google. Pour vous donner plus de contexte, 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 ML pour classer les recommandations de vidéos. "Ma sélection" 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 dispose de nombreux modèles permettant de résoudre différents problèmes. Les applications Recherche Play, Recommandations personnalisées sur la page d'accueil Play et "Les utilisateurs ont également installé" reposent toutes sur le machine learning.

Présentation de Google Plus

Google Plus a utilisé le machine learning dans différentes situations: classement des posts dans le "flux" des posts consultés par l'utilisateur, classement des posts "Populaire sur Google+" (posts actuellement très populaires), classement des personnes que vous connaissez, etc. Google Plus a clôturé tous les comptes personnels en 2019 et a été remplacé par Google Currents pour les comptes professionnels le 6 juillet 2020.