Bonnes pratiques d'ingénierie de ML
Martin Zinkevich
L'objectif de ce document est d'aider les personnes ayant des connaissances de base en machine learning à profiter des bonnes pratiques de Google en matière de machine learning. Il présente un style de machine learning, semblable au guide de style Google C++ et à d'autres guides populaires de programmation pratique. Si vous avez suivi une formation en machine learning, ou créé ou travaillé sur un modèle de machine learning, vous disposez des connaissances nécessaires pour lire ce document.
Terminologie
Les termes suivants reviennent fréquemment dans notre discussion sur le machine learning efficace:
- 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 "à propos des 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'entraînement. Par exemple, l'étiquette d'une page Web peut être "à propos de chats".
- Caractéristique : propriété d'une instance utilisée dans une tâche de prédiction. Par exemple, une page Web peut comporter une 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. Une colonne de caractéristiques peut contenir un ou plusieurs éléments. La "colonne de caractéristiques" est une terminologie spécifique à Google. Une colonne de caractéristiques 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înerez un modèle sur des exemples, puis vous l'utiliserez pour réaliser des prédictions.
- Métrique : nombre qui vous intéresse. Peut ou non être optimisé directement.
- Objectif: métrique que votre algorithme essaie d'optimiser.
- Pipeline : infrastructure entourant un algorithme de machine learning. Il s'agit de collecter les données du frontal, de les placer dans des fichiers de données d'entraînement, d'entraîner un ou plusieurs modèles et de les exporter 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é:
faites du machine learning comme le grand ingénieur que vous êtes, et non comme le grand expert en machine learning que vous n'êtes pas.
La plupart des problèmes que vous rencontrerez sont, en réalité, des problèmes d'ingénierie. Même avec toutes les ressources d'un grand expert en machine learning, la plupart des gains proviennent d'excellentes fonctionnalités, et non d'excellents algorithmes de machine learning. L'approche de base est la suivante:
- Assurez-vous que votre pipeline est robuste de bout en bout.
- Commencez avec un objectif raisonnable.
- Ajoutez des fonctionnalités de bon sens de manière simple.
- Assurez-vous que votre pipeline reste solide.
Cette approche fonctionne bien sur une longue période. Ne vous écartez de cette approche que s'il n'existe plus d'astuces simples pour aller plus loin. L'ajout de complexité ralentit les futures versions.
Une fois que vous aurez épuisé toutes les astuces, le machine learning de pointe sera peut-être votre avenir. Consultez la section sur les projets de phase III de machine learning.
Ce document est organisé comme suit:
- La première partie devrait vous aider à déterminer si le moment est venu de créer un système de machine learning.
- La deuxième partie concerne le déploiement de votre premier pipeline.
- La troisième partie concerne le lancement et l'itération en parallèle à l'ajout de caractéristiques à votre pipeline, l'évaluation des modèles et le décalage entraînement/inférence.
- La dernière partie explique ce qu'il faut faire lorsque vous atteignez un plateau.
- Enfin, vous trouverez la liste des travaux connexes et une annexe avec des informations générales 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 pratique, mais nécessite des données. Théoriquement, vous pouvez prendre des données à partir d'un autre problème, puis ajuster le modèle pour un nouveau produit, mais les performances seront probablement moins bonnes en termes de heuristiques de base. Si vous pensez que le machine learning va booster vos performances à 100 %, une méthode heuristique vous permettra de faire 50 % du chemin.
Par exemple, si vous classez les applications sur une place de marché d'applications, vous pouvez utiliser le taux d'installation ou le nombre d'installations comme méthode heuristique. Si vous identifiez du spam, filtrez les éditeurs qui ont déjà envoyé du spam. N'ayez pas peur de l'édition humaine. Si vous devez classer les contacts, classer les derniers par ordre de priorité (ou 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 les métriques
Avant de structurer votre système de machine learning, suivez autant que possible votre système actuel. Procédez comme suit:
- Il est plus facile d'obtenir l'autorisation des utilisateurs du système auparavant.
- Si vous pensez que quelque chose pourrait poser problème à l'avenir, il est préférable d'obtenir les données historiques maintenant.
- Si vous concevez votre système en gardant à l'esprit l'instrumentation de métriques, les choses seront plus simples par la suite. Plus précisément, vous ne voulez pas vous retrouver à chercher des chaînes dans les journaux pour instrumenter vos métriques !
- Vous remarquerez 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 majeures de l'expérience utilisateur ne modifient pas de manière visible cette métrique.
L'équipe Google Plus mesure le nombre d'expansions par lecture, de partages par lecture, de lectures supplémentaires, de commentaires/lecture, de commentaires par utilisateur, de partages par utilisateur, etc., pour calculer les avantages d'un post lors de la diffusion Notez également qu'un framework de test vous permet de regrouper des utilisateurs dans des buckets et d'agréger des statistiques par test. Reportez-vous à la règle n° 12.
En libérant davantage de métriques, vous bénéficiez d'une vue d'ensemble de votre système. Un problème ? Ajoutez une métrique pour la suivre. Vous avez hâte de faire des changements quantitatifs dans la dernière version ? Ajoutez une métrique pour la suivre.
Règle n° 3: optez pour le machine learning plutôt que pour une méthode heuristique complexe
Une méthode heuristique simple peut faire sortir votre produit. Une heuristique complexe est impossible à gérer. Une fois que vous disposez de données et d'une idée générale de ce que vous essayez d'effectuer, passez au machine learning. Comme dans la plupart des tâches de génie logiciel, vous devrez constamment mettre à jour votre approche, qu'il s'agisse d'un modèle heuristique ou d'un modèle de machine learning. 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
Concentrez-vous sur l'infrastructure système de votre premier pipeline. Même s'il est amusant d'envisager toutes les tâches de machine learning que vous allez imaginer, il sera difficile de comprendre ce qui se passe si vous ne faites pas confiance à votre pipeline.
Règle n° 4: optez pour le premier modèle et faites en sorte que l'infrastructure soit correcte
Le premier modèle offre l'impact le plus important sur votre produit. Il n'a donc pas besoin d'être sophistiqué. Toutefois, vous rencontrerez bien plus de problèmes d'infrastructure que prévu. Avant que quiconque puisse utiliser votre nouveau système de machine learning sophistiqué, vous devez déterminer:
- Obtenir des exemples pour votre algorithme d'apprentissage
- Tout d'abord, déterminez ce que signifient "bon" et "mauvais" système.
- Intégrer votre modèle dans 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éclasser les pages Web et stocker les résultats dans une table, mais vous pouvez vouloir classer les messages de chat en direct.
En choisissant des fonctionnalités simples, vous vous assurez que:
- Les caractéristiques atteignent correctement votre algorithme d'apprentissage.
- Le modèle apprend des pondérations raisonnables.
- Les caractéristiques atteignent correctement votre modèle sur le serveur.
Une fois que vous avez 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 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 un premier lancement qui donne explicitement la priorité aux gains de machine learning, pour éviter toute distraction.
Règle n° 5: testez l'infrastructure indépendamment du machine learning
Assurez-vous que l'infrastructure est vérifiable et que les parties d'apprentissage du système sont encapsulées afin que vous puissiez tester tout ce qui l'entoure. Notamment :
- Tester l'intégration des données dans l'algorithme Vérifiez que les colonnes de caractéristiques à renseigner le sont aussi. Lorsque la confidentialité le permet, inspectez manuellement l'entrée de votre algorithme d'entraînement. Si possible, comparez les statistiques de votre pipeline avec celles des autres données traitées ailleurs.
- Tester l'extraction de modèles depuis l'algorithme d'entraînement Assurez-vous que le score qu'obtient votre modèle dans l'environnement d'entraînement est le même que celui qu'il obtient dans l'environnement d'inférence (voir la règle n° 37).
Le machine learning contient un élément imprévisible. Vous devez donc vous assurer que vous disposez de tests pour le code permettant de créer des exemples d'entraînement et d'inférence, et que vous pouvez charger et utiliser un modèle fixe pendant l'inférence. Il est également important de comprendre vos données. Consultez la section Conseils pratiques pour l'analyse d'ensembles de données volumineux et complexes.
Règle n° 6: faites attention lorsque vous supprimez des données lorsque vous copiez des pipelines
Souvent, nous créons un pipeline en copiant un pipeline existant (c'est-à-dire, culte du cargo), et l'ancien pipeline supprime les données dont nous avons besoin pour le nouveau. Par exemple, le pipeline pour "À découvrir" de Google Plus supprime les anciens posts (car il tente de classer les nouveaux posts). Ce pipeline a été copié pour être utilisé avec le flux de Google Plus, dans lequel les posts plus anciens présentent un intérêt. Toutefois, le pipeline abandonnait 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 souhaitons modéliser pour quelle raison 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'élaboration de la page d'accueil des applications Play, nous avons créé un pipeline qui contenait également des exemples issus de la page de destination de Play Jeux, sans aucune fonctionnalité permettant de distinguer l'origine de chaque exemple.
Règle n° 7: transformez des méthodes heuristiques en caractéristiques ou gérez-les en externe
Généralement, les problèmes que le machine learning tente de résoudre ne sont pas complètement nouveaux. Il existe déjà un système de classement ou de classification, ou de tout autre problème que vous essayez de résoudre. Cela signifie qu'il existe un grand nombre de règles et d'heuristiques. La même heuristique peut vous aider à améliorer vos performances si vous utilisez le machine learning. Vous devez extraire vos heuristiques des informations dont ils disposent, et ce pour deux raisons. Tout d'abord, la transition vers un système de machine learning sera plus fluide. Ensuite, ces règles contiennent généralement une bonne dose d'intuition sur le système que vous ne souhaitez pas rejeter. Vous pouvez utiliser une heuristique existante de quatre manières:
- Procédez au prétraitement à l'aide de la méthode heuristique. Si la fonctionnalité est incroyable, cette option est tout à fait envisageable. 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". Bloquer le message Cette approche est particulièrement bien adaptée aux 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 très pratique. Par exemple, si vous utilisez une heuristique pour calculer un score de pertinence pour un résultat de requête, vous pouvez inclure le score en tant que valeur d'une caractéristique. Par la suite, vous pourrez 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.
- Exploitez les entrées brutes de l'heuristique. S'il existe une méthode heuristique pour les applications qui combine le nombre d'installations, le nombre de caractères dans le texte et le jour de la semaine, envisagez de séparer ces éléments, puis d'alimenter ces entrées séparément dans l'apprentissage. Certaines techniques qui s'appliquent aux ensembles s'appliquent ici (voir la règle n° 40).
- Modifiez le libellé. C'est une option lorsque vous pensez que la méthode heuristique capture des informations qui ne sont actuellement pas contenues 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 l'étiquette par le nombre moyen d'étoiles que l'application a reçues. Il y a beaucoup de marge de manœuvre ici. Consultez 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 faciliter la transition, mais demandez-vous s'il existe un moyen plus simple d'obtenir le même effet.
Surveillance
En règle générale, appliquez de bonnes pratiques d'alerte. Par exemple, vous pouvez rendre les alertes exploitables et disposer d'une page de tableau de bord.
Règle n° 8: déterminez la configuration système requise pour votre système
Dans quelle mesure les performances d'un modèle datant d'un jour se dégradent-elles ? Une semaine ? Un quart ? Ces informations peuvent vous aider à comprendre les priorités de votre surveillance. Si le modèle n'est pas mis à jour pendant une journée, la qualité du produit sera significative. Il est donc logique qu'un ingénieur le surveille en continu. La plupart des systèmes de diffusion d'annonces ont de nouvelles publicités à gérer tous les jours et doivent être mis à jour quotidiennement. Par exemple, si le modèle de machine learning 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 "Populaire sur Google Plus" sont dépourvus d'identifiants de post. Ces modèles sont donc rarement exportés. D'autres modèles dotés d'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 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 dans laquelle vous exportez le modèle vers l'inférence. Un problème lié à un modèle exporté est lié à l'utilisateur.
Effectuez des vérifications d'intégrité juste avant d'exporter le modèle. Plus précisément, assurez-vous que les performances du modèle sont raisonnables pour les données exclues. Si vous avez des inquiétudes concernant les données, n'exportez pas le 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 sur un modèle visible par l'utilisateur peuvent nécessiter l'envoi d'une page. Il vaut donc mieux attendre et être sûr avant d'avoir un impact sur les utilisateurs.
Règle n° 10: surveillez les échecs silencieux
Ce problème survient davantage pour les systèmes de machine learning que pour d'autres types de systèmes. Supposons qu'une table en cours de jointure ne soit plus mise à jour. Le système de machine learning s'ajuste, et le comportement continue d'être raisonnablement bon, en se dégradant progressivement. Parfois, certaines tables 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 caractéristique peut changer en raison de modifications de la mise en œuvre. Par exemple, une colonne de caractéristiques peut être renseignée dans 90% des exemples et chute soudainement à 60% des exemples. Play a eu une table non actualisée pendant six mois, et l'actualisation de la table à elle seule a permis d'augmenter le taux d'installation de 2 %. Si vous suivez les statistiques des données et que vous inspectez manuellement les données de temps en temps, vous pouvez réduire ce type d'échec.
Règle n° 11: ajoutez des propriétaires et des documents aux colonnes de caractéristiques
Si le système est volumineux et qu'il comporte de nombreuses colonnes de caractéristiques, sachez qui en crée ou en gère une. Si vous constatez que la personne qui comprend une colonne de caractéristiques la quitte, assurez-vous qu'elle dispose des informations nécessaires. Bien que de nombreuses colonnes de caractéristiques portent des noms descriptifs, nous vous conseillons de fournir une description plus détaillée de leur nature, de leur origine et de leur utilité.
Votre premier objectif
Vous avez un grand nombre de métriques ou de mesures concernant le système qui vous intéresse, mais votre algorithme de machine learning ne requiert souvent qu'un seul objectif, un nombre que votre algorithme "essaie" d'optimiser. Je distingue ici les objectifs et les métriques: une métrique est un nombre que votre système signale, qui peut être important ou non. Consultez également la Règle 2.
Règle n° 12: ne tenez pas compte de l'objectif que vous choisissez d'optimiser directement
Vous voulez gagner de l'argent, satisfaire vos utilisateurs et améliorer le monde. Un grand nombre de métriques vous intéressent, et vous devriez toutes les mesurer (voir la règle n° 2). Cependant, au début du processus de machine learning, vous constaterez qu'elles augmentent toutes, même celles que vous n'optimisez pas directement. Par exemple, supposons que vous vous intéressiez au nombre de clics et au temps passé sur le site. Si vous optimisez pour le nombre de clics, vous constaterez probablement une augmentation du temps passé.
Privilégiez la simplicité et ne cherchez pas à équilibrer différentes métriques lorsque vous pouvez toujours augmenter facilement toutes les métriques. Mais ne poussez pas cette règle à l'extrême. Ne confondez pas votre objectif avec l'état de santé final du système (voir la Règle 39). Par ailleurs, si vous constatez que vous augmentez la métrique directement optimisée, mais que vous décidez de ne pas la 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 le pensez, mais en regardant 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 voulez modifier l'objectif. En outre, les différents membres de l'équipe ne parviennent souvent pas à se mettre d'accord sur le véritable objectif. L'objectif du ML doit être facile à mesurer et servir de proxy pour l'objectif réel. En réalité, il n'y a souvent pas de "vrai" objectif (voir la règle n° 39). Entraînez-vous donc sur l'objectif de ML simple et envisagez d'utiliser une "couche de stratégie" qui vous permettra d'ajouter une logique supplémentaire (qui, nous l'espérons, très simple) nous permettra de procéder au classement final.
Le modèle le plus simple est un comportement utilisateur directement observé et imputable à 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é/réalisé/envoyé par e-mail ?
- Cet objet classé a-t-il été évalué ?
- Cet objet a-t-il été marqué comme spam/pornographie/choquant ?
Éviter d'abord les effets indirects:
- L'utilisateur a-t-il visité le site le lendemain ?
- Combien de temps l'utilisateur a-t-il visité le site ?
- Quel était le nombre d'utilisateurs actifs par jour ?
Les effets indirects font d'excellentes métriques et peuvent être utilisés pendant les tests A/B et pendant les décisions de lancement.
Enfin, n'essayez pas d'utiliser le machine learning pour déterminer:
- L'utilisateur est-il satisfait de ce 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 ?
- Quelles seront les conséquences sur la santé globale de l'entreprise ?
Tous ces paramètres sont importants, mais ils sont extrêmement difficiles à mesurer. Utilisez plutôt des proxys: si l'utilisateur est satisfait, il reste 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: commencez à utiliser un modèle interprétable pour faciliter 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 donc plus faciles à déboguer que les modèles qui utilisent des objectifs (perte nulle, diverses marges à charnière, etc.) qui tentent d'optimiser directement la précision de la classification ou les performances du classement. Par exemple, si les probabilités d'entraînement diffèrent des probabilités prédites côte à côte ou en inspectant le système de production, cet écart 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 dans lesquels l'espérance prédite moyenne est égale à l'étiquette moyenne (calibrée sur un moment, ou simplement calibrée). Cela est vrai s'il n'y a pas de régularisation, que votre algorithme a convergé et qu'il est vrai à peu près vrai en général. Si vous avez une caractéristique égale à 1 ou à 0 pour chaque exemple, l'ensemble de trois exemples où cette caractéristique est égale à 1 est calibré. De plus, si vous avez une caractéristique de 1 pour chaque exemple, l'ensemble de tous les exemples est calibré.
Avec les modèles simples, il est plus facile de gérer les boucles de rétroaction (voir la règle n° 36). Ces prédictions probabilistes nous aident souvent à prendre une décision: par exemple, classer les posts par ordre décroissant de valeur attendue (par exemple, probabilité de clic/téléchargement/etc.). Toutefois, lorsque vous devez choisir le modèle à utiliser, la décision est plus importante que la probabilité des données selon le modèle (voir la règle n° 27).
Règle n° 15: séparez le filtrage anti-spam et le classement dans un niveau de qualité
Le classement de la qualité est un art, mais le filtrage antispam est une guerre. Les utilisateurs de votre système verront alors clairement les signaux que vous utilisez pour déterminer les posts de haute qualité et modifieront leurs posts pour qu'ils disposent de ces propriétés. Votre classement doit donc être axé sur le classement du contenu publié en toute bonne foi. Vous ne devez pas prendre en compte l'apprenant du classement qualité pour le classement élevé du spam. De même, le contenu doit être traité séparément du classement de la qualité. Le filtrage antispam est différent. Vous devez vous attendre à ce que les caractéristiques que vous devez générer changent constamment. Souvent, des règles évidentes s'appliquent au système (si un post comporte plus de trois votes pour spam, ne le récupérez pas, etc.). Tout modèle entraîné devra être mis à jour quotidiennement, voire plus rapidement. La réputation du créateur du contenu jouera un rôle important.
À un certain niveau, le résultat de ces deux systèmes devra être intégré. Gardez à l'esprit que le filtrage du spam dans les résultats de recherche devrait être plus agressif que le filtrage du spam dans les e-mails. Cela est vrai s'il n'y a pas de régularisation et que votre algorithme a convergé. En général, c'est à peu près vrai. En outre, une pratique standard consiste à 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 les plus importants sont l'intégration des données d'entraînement dans le système d'apprentissage, la mise en place d'un instrument de métriques d'intérêt et la création d'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 des tests système instrumentés, la phase II commence.
Dans la deuxième phase, il y a beaucoup de fruits simples. Plusieurs fonctionnalités évidentes peuvent être intégrées au système. Ainsi, la deuxième phase du machine learning implique l'intégration d'autant de caractéristiques que possible et la combinaison intuitive. Au cours de cette phase, toutes les métriques devraient continuer d'augmenter. Il y aura beaucoup de lancements, et c'est le moment idéal pour rassembler un grand nombre d'ingénieurs capables de regrouper toutes les données dont vous avez besoin pour créer un système d'apprentissage vraiment efficace.
Règle n° 16: planifiez le lancement et itérez
Ne vous attendez pas à ce que le modèle sur lequel vous travaillez soit le dernier que vous allez lancer, ou même à arrêter le lancement d'un modèle. Déterminez si la complexité que vous ajoutez avec ce lancement ralentira les futurs lancements. De nombreuses équipes ont lancé un modèle tous les trimestres ou plus pendant des années. Trois raisons principales expliquent le lancement de nouveaux modèles:
- Vous proposez de nouvelles fonctionnalités.
- Vous ajustez la régularisation et combinez d'anciennes caractéristiques de manière inédite.
- Vous ajustez l'objectif.
Quoi qu'il en soit, donner un peu d'amour à un modèle: examiner les données qui alimentent l'exemple peut aider à trouver de nouveaux signaux, mais aussi d'anciens signaux non fonctionnels. Ainsi, lorsque vous créez votre modèle, réfléchissez à la facilité d'ajout, de suppression ou de combinaison des caractéristiques. Pensez à la facilité avec laquelle vous pouvez créer une copie récente du pipeline et vérifier son exactitude. Déterminez s'il est possible d'exécuter deux ou trois copies en parallèle. Enfin, ne vous inquiétez pas si la fonctionnalité 16 sur 35 est intégrée à cette version du pipeline. Vous le recevrez le trimestre prochain.
Règle n° 17: commencez avec des caractéristiques directement observées et signalées plutôt que des caractéristiques apprises
Il s'agit d'un point controversé, mais il permet d'éviter de nombreux pièges. Commençons par décrire ce qu'est une caractéristique apprise. Une caractéristique apprise est une caractéristique générée par un système externe (tel qu'un système de clustering non supervisé) ou par l'apprenant lui-même (par exemple, via un modèle factorisé ou de deep learning). Ces deux outils peuvent être utiles, mais ils peuvent poser 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 caractéristique, n'oubliez pas que celui-ci a son propre objectif. L'objectif du système externe n'est peut-être que faiblement corrélé à votre objectif actuel. Si vous prenez un instantané du système externe, celui-ci peut devenir obsolète. Si vous mettez à jour les caractéristiques depuis le système externe, les significations peuvent changer. Si vous utilisez un système externe pour fournir une caractéristique, sachez que cette approche nécessite beaucoup de soin.
Le principal problème avec les modèles factorisés et profonds est qu'ils ne sont pas convexes. Il n'y a donc aucune garantie qu'une solution optimale puisse être estimée ou trouvée, et les minimums locaux trouvés à chaque itération peuvent être différents. 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 atteinte, vous pouvez essayer des approches plus ésotériques.
Règle n° 18: explorez le contenu avec des caractéristiques qui peuvent être généralisées dans différents contextes
Les systèmes de machine learning ne représentent souvent qu'une petite partie de la situation. Par exemple, si vous estimez qu'un post peut être utilisé dans "Populaire sur Google+", de nombreuses personnes attribueront un +1, le partageront ou le commenteront avant même qu'il ne s'affiche dans "Quoi ?". Si vous fournissez ces statistiques à l'apprenant, celui-ci peut promouvoir de nouveaux posts pour lesquels il ne possède aucune donnée dans le contexte de l'optimisation. La fonctionnalité "Vidéos à regarder ensuite" de YouTube peut utiliser le nombre de vues ou de covisionnages (nombre de fois où une vidéo a été regardée après le visionnage d'une autre) depuis la recherche YouTube. Vous pouvez également utiliser des notes explicites des utilisateurs. Enfin, si vous utilisez une action utilisateur comme libellé, cette action dans le contexte du document peut s'avérer très utile. Toutes ces fonctionnalités vous permettent de replacer de nouveaux contenus dans leur contexte. Notez qu'il ne s'agit pas de personnalisation: déterminez d'abord si un utilisateur apprécie le contenu dans ce contexte, puis déterminez qui l'aime plus ou moins.
Règle n° 19: utilisez dans la mesure du possible des caractéristiques très spécifiques
Avec une multitude de données, il est plus facile d'apprendre des millions de caractéristiques simples qu'une poignée de caractéristiques complexes. Les identifiants des documents récupérés et les requêtes canoniques n'offrent pas beaucoup de généralisation, mais permettent d'aligner votre classement sur vos étiquettes sur les requêtes principales. N'ayez donc pas peur d'avoir des groupes de caractéristiques où 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 intelligibles
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 les "discrétisations" et les "croisements".
La discrétisation consiste à utiliser une caractéristique continue et à en créer de nombreuses caractéristiques discrètes. Envisagez d'utiliser une caractéristique continue, telle que l'âge. Vous pouvez créer une caractéristique égale à 1 lorsque l'âge est inférieur à 18, une autre à 1 lorsque l'âge est compris entre 18 et 35 ans, etc. Ne négligez pas les limites de ces histogrammes: les quantiles de base vous permettront de tirer le meilleur parti de leur impact.
Les croisements associent au moins deux colonnes de caractéristiques. Dans la terminologie 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, par exemple, {male, female} × {US,Canada, Mexico}. Cette nouvelle colonne contiendra la caractéristique (homme, Canada). Si vous utilisez TensorFlow et que vous lui demandez de créer ce croisement pour vous, cette caractéristique (homme, Canada) sera présente dans les exemples représentant des hommes canadiens. Notez qu'il faut d'énormes quantités de données pour apprendre des modèles avec des croisements de trois, quatre ou plusieurs colonnes de caractéristiques de base.
Le croisement peut donner lieu à un surapprentissage. Par exemple, imaginons que vous effectuiez une recherche et que vous ayez une colonne de caractéristiques contenant des mots dans la requête, et une colonne de caractéristiques contenant des mots dans le document. Vous pouvez les combiner avec un croisement, mais vous obtiendrez au bout d'un grand nombre de caractéristiques (voir la règle n° 21).
Deux options s'offrent à vous lorsque vous travaillez avec du texte. Le produit le plus draconien est un point. 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 alors être discrétisée. Une autre approche est une intersection: une caractéristique sera donc présente si et seulement si le mot "poney" figurera à la fois dans le document et dans la requête, et une autre caractéristique sera présente si le mot "" se trouve à la fois dans le document et dans la requête.
Règle n° 21: le nombre de pondérations de caractéristiques dans un modèle linéaire est approximativement proportionnel à la quantité de données dont vous disposez.
Il existe des résultats de théorie théorique sur l'apprentissage statistique concernant le niveau de complexité d'un modèle, mais cette règle est tout ce que vous avez besoin de savoir. J'ai eu des conversations dans lesquelles les gens pensaient que rien ne pouvait être appris à partir d'un millier d'exemples, ou que vous auriez besoin de plus d'un million d'exemples, car ils sont coincés dans une certaine méthode d'apprentissage. La clé consiste à adapter votre apprentissage à la taille de vos données:
- Si vous travaillez sur un système de classement des résultats de recherche contenant des millions de mots différents dans les documents et la requête, et que vous avez 1 000 exemples étiquetés, vous devez utiliser un produit par point entre les caractéristiques de document et de requête, TF-IDF et une demi-douzaine d'autres caractéristiques hautement humaines. 1 000 exemples, une douzaine de caractéristiques.
- 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 ainsi des millions de caractéristiques, mais avec la régularisation, vous en aurez moins. Dix millions d'exemples, peut-être une centaine de milliers de caractéristiques.
- 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 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 fournit d'excellents conseils pour commencer.
Au final, déterminez les fonctionnalités à utiliser à l'aide de la règle n° 28.
Règle n° 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 sa combinaison avec d'autres ne fonctionne pas, supprimez-la de votre infrastructure. Vous devez vous assurer que votre infrastructure reste propre afin que les fonctionnalités les plus prometteuses puissent être testées le plus rapidement possible. Si nécessaire, il est toujours possible de réactiver votre fonctionnalité.
Tenez compte de la couverture lorsque vous envisagez d'ajouter ou de conserver des fonctionnalités. Combien d'exemples sont couverts par la fonctionnalité ? Par exemple, si vous disposez de certaines fonctionnalités de personnalisation, mais que seuls 8% de vos utilisateurs disposent de fonctionnalités de personnalisation, cela ne sera pas très efficace.
Parallèlement, certaines caractéristiques peuvent dépasser leur poids. Par exemple, si vous disposez d'une caractéristique qui ne couvre que 1% des données, mais que 90% des exemples qui la composent sont positifs, vous pouvez l'ajouter très efficacement.
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 aucune classe de machine learning: comment examiner un modèle existant et l'améliorer. Bien qu'il s'agisse plus d'un art qu'une science, il existe plusieurs antimodèles à éviter.
Règle n° 23: vous n'êtes pas un utilisateur type
C'est peut-être le moyen le plus simple pour une équipe de s'enliser. Bien qu'il existe de nombreux avantages à utiliser la version fishfood (en utilisant un prototype au sein de votre équipe) et à la version dogfood (à l'aide d'un prototype au sein de votre entreprise), les employés doivent vérifier si les performances sont correctes. Bien qu'il ne soit évidemment pas nécessaire d'appliquer un changement qui ne semble manifestement pas approprié, il convient de tester davantage tout aspect qui semble raisonnablement proche de la production, que ce soit en payant des profanes pour répondre aux questions sur une plate-forme de crowdsourcing ou via un test en direct sur de vrais utilisateurs.
et ce pour deux raisons. 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 émotionnellement impliqué (par exemple, un biais de confirmation). Deuxièmement, votre temps est trop précieux. Réfléchissez au coût de neuf ingénieurs qui participent à une réunion d'une heure et réfléchissez au nombre d'étiquettes humaines sous contrat qui achètent sur une plate-forme de crowdsourcing.
Si vous souhaitez vraiment avoir des commentaires d'utilisateurs, utilisez des méthodologies d'expérience utilisateur. Créez des personas utilisateur (une description figure dans l'article Sketching User Experiences de Bill Buxton) au début du processus et testez la facilité d'utilisation (voir la page Don't Make Me Think de Steve Krug) pour en savoir plus. Les personas impliquent la création d'un utilisateur hypothétique. Par exemple, si votre équipe est composée d'hommes, il peut être utile de créer un persona féminin de 35 ans (avec les fonctionnalités utilisateur) et d'examiner les résultats qu'il génère plutôt que les 10 résultats pour les hommes de 25 à 40 ans. Faire entrer des personnes réelles pour qu'elles regardent leur réaction à votre site (localement ou à distance) pendant les 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 faciles, voire les plus utiles, que vous puissiez effectuer avant que les utilisateurs n'aient examiné votre nouveau modèle consiste à calculer la différence entre les nouveaux résultats et 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 et examinez la différence symétrique des résultats (pondérée par position de classement). Si la différence est très faible, vous pouvez indiquer que le changement sera minime sans exécuter de test. Si la différence est très importante, assurez-vous que la modification est correcte. Examiner les requêtes pour lesquelles la différence symétrique est élevée peut vous aider à comprendre de manière qualitative la modification. Assurez-vous toutefois que le système est stable. Assurez-vous que le modèle dispose d'une différence symétrique faible (idéalement nulle) par rapport à lui-même.
Règle n° 25: quand vous choisissez des modèles, les performances utilitaires l'emportent sur la puissance prédictive
Votre modèle peut tenter de prédire le taux de clics. Cependant, à la fin, la question essentielle est ce que vous faites avec cette prédiction. Si vous l'utilisez pour classer des documents, la qualité du classement final a plus d'importance que la prédiction elle-même. Si vous prévoyez la probabilité qu'un document soit du spam, puis que vous limitez la liste des éléments bloqués, la précision de ce qui est autorisé par ce filtre importe plus. La plupart du temps, ces deux éléments devraient être d'accord: s'ils ne sont pas d'accord, le gain sera probablement minime. Ainsi, si un changement améliore la perte de journaux, mais dégrade les performances du système, recherchez une autre caractéristique. Lorsque cela se produit plus souvent, il est temps de revoir l'objectif de votre modèle.
Règle n° 26: identifiez les tendances dans les erreurs mesurées et créez des caractéristiques
Supposons que vous constatiez un exemple d'entraînement qui a été "mauvais". 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 positif était classé moins bien qu'un négatif. Le plus important, c'est qu'il s'agit d'un exemple de problème que le système de machine learning connaît, et qu'il souhaite corriger s'il en a l'occasion. Si vous attribuez au modèle une caractéristique qui lui permet de corriger l'erreur, il essaiera de l'utiliser.
En revanche, si vous essayez de créer une caractéristique à partir d'exemples que le système ne considère pas comme des erreurs, elle sera ignorée. Par exemple, supposons que quelqu'un recherche "jeux offerts" dans la recherche d'applications 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 offerts, la fonctionnalité d'"applications gag" n'aura pas l'effet escompté.
Une fois que vous disposez d'exemples erronés, recherchez des tendances en dehors de votre ensemble de caractéristiques actuel. Par exemple, si le système semble rétrograder les articles plus longs, ajoutez la longueur des articles. Ne soyez pas trop précis quant aux fonctionnalités que vous ajoutez. Si vous ajoutez la longueur du post, n'essayez pas de deviner ce qui signifie "long". Ajoutez simplement une dizaine de caractéristiques, et laissez le modèle décider de ce qu'il doit en faire (voir la règle n° 21). C'est le moyen le plus simple d'obtenir ce que vous souhaitez.
Règle n° 27: essayez de quantifier le comportement indésirable observé
Certains membres de votre équipe commenceront à être contrariés par les propriétés du système qu'ils n'apprécient pas et qui ne sont pas capturées par la fonction de perte existante. À ce stade, il doit faire tout son possible pour transformer ses grips en chiffres solides. Par exemple, s'ils pensent que trop d'"applications gag" sont affichées dans la recherche Play, ils pourraient demander à des évaluateurs humains d'identifier des applications gag. (Dans ce cas, vous pouvez utiliser des données étiquetées manuellement, car une fraction relativement petite des requêtes représente une grande partie du trafic.) Si vos problèmes sont mesurables, vous pouvez commencer à les utiliser comme caractéristiques, objectifs ou métriques. La règle générale consiste à mesurer d'abord, optimiser ensuite.
Règle n° 28: sachez qu'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 constatez que son comportement est presque identique à celui de votre système actuel, tant sur le plan côte à côte que lors des tests A/B. Par conséquent, étant donné sa simplicité, vous le lancez. Cependant, vous remarquez qu'aucune nouvelle application n'est affichée. Pourquoi ? Étant donné que votre système n'affiche qu'un document basé sur 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 à long terme d'un tel système est de ne l'entraîner que sur les données acquises lorsque le modèle était actif. C'est très difficile.
Décalage entraînement/inférence
Le décalage entraînement/inférence correspond à la différence entre les performances pendant l'entraînement et pendant la diffusion. Ce décalage peut s'expliquer par:
- Il existe une différence entre la manière dont vous gérez les données dans les pipelines d'entraînement et d'inférence.
- Modification des données entre le moment de l'entraînement et le moment de l'inférence.
- Une 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 du système et des données n'introduisent pas de décalage inaperçu.
Règle n° 29: la meilleure façon de vous assurer que vous effectuez l'entraînement est d'enregistrer l'ensemble de caractéristiques utilisé au moment de l'inférence, puis de transférer ces caractéristiques dans 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 d'entre eux, 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é surpris 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 permet d'améliorer considérablement la qualité et de réduire la complexité du code. De plus, de nombreuses équipes changent d'infrastructure au fur et à mesure.
Règle n° 30: ne pondérez pas arbitrairement les données d'importance pondérée
Lorsque vous avez trop de données, vous pouvez être tenté de traiter 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 par importance est préférable pour le reste. Si vous décidez que vous allez échantillonner l'exemple X avec une probabilité de 30 %, donnez-lui une pondération de 10/3. Avec la pondération selon l'importance, toutes les propriétés de calibration décrites dans la règle n° 14 restent valables.
Règle n° 31: n'oubliez pas que si vous joignez les 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 joigniez des ID de document avec une table contenant des fonctionnalités pour ces documents (par exemple, le nombre de commentaires ou de clics). Les caractéristiques de la table peuvent être modifiées entre l'entraînement et l'inférence. 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 est de consigner les caractéristiques au moment de l'inférence (voir la règle n° 32). Si la table ne change que lentement, vous pouvez également prendre un instantané de la table toutes les heures ou tous les jours pour obtenir des données raisonnablement proches. Notez que cela ne résout pas complètement le problème.
Règle n° 32: si possible, réutilisez du 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 à 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 la diffusion, vous effectuez le traitement en ligne, tandis que l'entraînement est une tâche de traitement par lot. Vous pouvez toutefois réutiliser le 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 collecté toutes les informations, pendant l'inférence ou l'entraînement, vous exécutez une méthode courante pour relier 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 tant que corollaire, essayez d'utiliser deux langages de programmation différents pour l'entraînement et l'inférence. Cette décision vous empêchera presque de partager du code.
Règle n° 33: si vous produisez un modèle basé sur les données jusqu'au 5 janvier, testez-le sur les données à partir du 6 janvier
En général, 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 ce que votre système fera 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 des nouvelles données ne soient pas aussi bonnes, mais pas beaucoup moins bonnes. Étant donné qu'il peut y avoir des effets quotidiens, vous ne pourrez peut-être pas prédire le taux de clics moyen ni le taux de conversion. Toutefois, l'aire sous la courbe, qui représente la probabilité de donner à l'exemple positif un score supérieur à un exemple négatif, doit être relativement proche.
Règle n° 34: dans la classification binaire pour le filtrage (comme la détection du spam ou l'identification des e-mails intéressants), faites de petits sacrifices à court terme dans les performances pour des données très propres.
Dans une tâche de filtrage, l'utilisateur ne voit pas les exemples à exclure. 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 laisse passer, vous pouvez en tenir compte.
Toutefois, cette approche introduit un biais d'échantillonnage. Vous pouvez collecter des données plus propres si, au lieu de cela, vous libérez 1% de l'ensemble du trafic comme "exclu" et envoyez tous les exemples bloqués à l'utilisateur. Votre filtre bloque maintenant 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. Malgré tout, 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: faites attention au décalage inhérent aux problèmes de classement
Lorsque vous modifiez votre algorithme de classement de manière suffisamment radicale pour afficher différents résultats, vous avez efficacement modifié les données que votre algorithme verra à l'avenir. Ce type de décalage s'affiche, et vous devez concevoir votre modèle en conséquence. Il existe plusieurs approches. Ces approches permettent toutes de favoriser les données que votre modèle a déjà vues.
- Régularisez davantage les caractéristiques qui couvrent davantage de requêtes que celles qui ne le sont que pour une seule requête. De cette manière, le modèle privilégiera les caractéristiques propres à une ou plusieurs requêtes par rapport aux caractéristiques qui sont généralisées à toutes les requêtes. Cette approche permet d'éviter la fuite de résultats très populaires vers des requêtes non pertinentes. Notez que cette approche est contraire au conseil plus conventionnel selon lequel vous devez appliquer plus de régularisation sur des colonnes de caractéristiques ayant des valeurs uniques.
- N'autoriser que les caractéristiques à avoir des pondérations positives. Ainsi, toute bonne caractéristique est préférable à une caractéristique "inconnue".
- vous n'avez pas accès aux fonctionnalités de document uniquement. Ceci est une version extrême du 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 souhaitez pas qu'elle soit diffusée partout. Le fait de ne pas avoir de caractéristiques de document uniquement simplifie les choses. La raison pour laquelle vous ne voulez pas afficher une application populaire partout est liée à l'importance de rendre toutes les applications souhaitées accessibles. Par exemple, si un internaute recherche une application d'observation des oiseaux, il peut se retrouver en train de télécharger le terme "oiseaux en colère", mais cela n'était pas son intention. 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 affecte considérablement la probabilité qu'un utilisateur interagit avec lui. Si vous placez une application en première position, l'utilisateur cliquera plus souvent sur celle-ci, et vous serez convaincu qu'il s'agira plus probablement d'un clic. Pour résoudre ce problème, vous pouvez ajouter des caractéristiques de position, c'est-à-dire des caractéristiques sur la position du contenu dans la page. Vous entraînez votre modèle avec des caractéristiques de position, et il apprend à pondérer, par exemple, la caractéristique "1stposition" en masse. Votre modèle donne donc moins de poids aux autres facteurs pour les exemples avec "1stposition=true". Ensuite, lors de l'inférence, vous n'attribuez pas la caractéristique de position à des instances ou vous leur attribuez 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 que les caractéristiques de position soient quelque peu séparées 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 du reste des caractéristiques est idéal. Par exemple, ne croisez pas les caractéristiques de position avec des caractéristiques de document.
Règle n° 37: mesurez le décalage entre entraînement et inférence
Plusieurs éléments peuvent causer un décalage au sens le plus général. De plus, vous pouvez le diviser en plusieurs parties:
- Différence entre les performances des données d'entraînement et des données exclues. En général, cela existe toujours, et ce n'est pas toujours une mauvaise chose.
- Différence entre les performances des données exclues et les données du jour suivant. Cette information existe 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 des données du jour suivant et celles des 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). Ainsi, un écart ici est probablement dû à une erreur d'ingénierie.
Phase III du ML: Croissance ralentie, 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 vont diminuer. Vous allez commencer à trouver des compromis entre les métriques: vous constaterez une augmentation et d'autres, des tests. C'est là qu'il devient intéressant. Étant donné que les gains sont plus difficiles à obtenir, le machine learning doit devenir plus sophistiqué. Attention: Cette section comporte plus de règles bleues que les sections précédentes. Nous avons vu de nombreuses équipes traverser les bons moments du machine learning de la phase I et de la phase II. Une fois la phase III atteinte, les équipes doivent trouver leur propre voie.
Règle n° 38: ne perdez pas de temps avec de nouvelles caractéristiques si des objectifs non alignés sont devenus un problème
Au fur et à mesure que vos mesures stagnent, votre équipe commence à examiner les problèmes qui n'entrent pas dans le 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 les objectifs de votre produit. Par exemple, vous pouvez optimiser les clics, les +1 ou les téléchargements, mais prendre des décisions de lancement basées en partie sur des évaluateurs humains.
Règle n° 39: les décisions de lancement sont un indicateur des objectifs à long terme du produit
Alice a une idée pour réduire la perte logistique liée à la prédiction des installations. Elle ajoute une caractéristique. La perte logistique chute. Lorsqu'elle réalise un test en direct, elle constate une augmentation du taux d'installation. Cependant, lors d'une réunion d'examen du lancement, quelqu'un indique que le nombre d'utilisateurs actifs par jour baisse de 5%. L'équipe décide de ne pas lancer le modèle. Alice est déçue, mais réalise que les décisions de lancement dépendent de plusieurs critères, dont certains ne peuvent être optimisés directement à l'aide du ML.
La vérité est que le monde réel n'est pas des donjons et des dragons: il n'y a pas de "points d'accès" pour identifier la santé de votre produit. L'équipe doit utiliser les statistiques recueillies pour essayer de prédire efficacement la qualité du système à l'avenir. Ils doivent se soucier de l'engagement, du nombre d'utilisateurs actifs sur une journée, de 30 UAJ, des revenus et du retour sur investissement de l'annonceur. Ces métriques, qui sont uniquement mesurables dans les tests A/B, ne sont qu'un proxy pour les objectifs à plus long terme: satisfaire les utilisateurs, augmenter les utilisateurs, satisfaire les partenaires et les bénéfices. Vous pouvez même envisager d'utiliser des proxys pour proposer un produit utile et de haute qualité et une entreprise florissante d'ici cinq ans.
Les seules décisions de lancement simples 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 méthode heuristique simple, si cette dernière est plus performante 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étrique possibles. Voici deux scénarios possibles:
Test | 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 défini sur A, il est peu probable que l'équipe bascule vers le système B. Si le système actuel est B, l'équipe ne passera probablement pas à A. Cela semble entrer en conflit avec un comportement rationnel. Cependant, les prédictions de modification des métriques peuvent ou non être panoramiques, ce qui augmente les risques. Chaque métrique couvre un certain risque.
De plus, aucune métrique ne permet de répondre aux inquiétudes de l'équipe. & "Où se situera mon produit dans 5 ans ?"
Les individus, quant à eux, privilégient un objectif qu'ils peuvent optimiser directement. La plupart des outils de machine learning favorisent un tel environnement. Un ingénieur qui déploie de nouvelles fonctionnalités peut recevoir un flux constant de lancements dans un tel environnement. Un type de machine learning, l'apprentissage multi-objectif, commence à résoudre ce problème. Par exemple, il est possible de formuler un problème de satisfaction contraignant qui présente des limites 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 sont pas facilement encadrées comme des objectifs de machine learning: si un utilisateur clique sur un document ou installe une application, c'est parce que le contenu a été affiché. Mais il est beaucoup plus difficile de comprendre pourquoi un utilisateur visite votre site. Pour prédire la réussite future d'un site dans son ensemble, l'approche IA-complete est aussi complexe que la vision par ordinateur ou le traitement du langage naturel.
Règle n° 40: optez pour des ensembles simples
Les modèles unifiés qui exploitent 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 correspondre soit à un ensemble qui n'accepte que les entrées d'autres modèles, soit à un modèle de base acceptant de nombreuses caractéristiques, mais pas les deux. Si vous superposez des modèles entraînés séparément, leur combinaison peut entraîner un comportement insatisfaisant.
Utilisez un modèle simple pour assembler qui n'accepte que les résultats de vos modèles de "base". Vous souhaitez également appliquer des propriétés sur ces modèles d'ensemble. Par exemple, une augmentation du score produit par un modèle de base ne devrait 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. De plus, assurez-vous que l'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 stagnent, cherchez des sources d'informations qualitativement nouvelles à 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 figurant dans le document. Vous avez terminé l'exploration des modèles et ajusté la régularisation. Vous n'avez constaté aucun lancement avec une amélioration de plus de 1% de vos métriques clés depuis quelques trimestres. Et après ?
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 un élément interne à votre entreprise (comme le Knowledge Graph de Google). Utilisez le deep learning. Commencez à ajuster vos attentes sur le retour sur investissement que vous attendez, et étendez vos efforts en conséquence. Comme dans tout projet d'ingénierie, vous devez évaluer l'avantage d'ajouter de nouvelles caractéristiques par rapport au coût de la complexité accrue.
Règle n° 42: ne vous attendez pas à ce que la diversité, la personnalisation ou la pertinence soient aussi corrélées avec la popularité que vous pensez.
La diversité d'un ensemble de contenus peut avoir de nombreuses significations, 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 signifie que les résultats d'une requête particulière sont plus adaptés qu'à n'importe quelle autre. Ces trois propriétés sont donc définies comme étant différentes de la norme.
Le problème est que le quotidien est généralement 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 la personnalisation, ils ajoutent des caractéristiques qui permettront au système de personnaliser (certaines caractéristiques représentant l'intérêt de l'utilisateur) ou de se diversifier (caractéristiques indiquant si ce document a des caractéristiques communes avec d'autres documents renvoyés, comme l'auteur ou le contenu) et constatent qu'elles sont moins lourdes (ou parfois un signe différent) qu'elles ne le devraient.
Cela ne signifie pas que la diversité, la personnalisation ou la pertinence ne sont pas intéressantes. Comme indiqué dans la règle précédente, vous pouvez procéder au post-traitement pour améliorer la diversité ou la pertinence. Si vous constatez que vos objectifs à plus long terme sont plus élevés, vous pouvez déclarer que la diversité ou la pertinence sont utiles, indépendamment 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 n° 43: vos amis ont tendance à être identiques sur différents produits Vos centres d'intérêt ont tendance à ne pas l'être.
Les équipes Google ont eu beaucoup de succès en utilisant un modèle prédisant la proximité d'une connexion pour un produit et en l'utilisant correctement pour un autre. Vos amis sont ce qu'ils sont. D'un autre côté, j'ai vu plusieurs équipes rencontrer des difficultés avec les fonctionnalités de personnalisation pour la division des produits. Oui, cela semble fonctionner. Pour l'instant, il semble que ce ne soit pas le cas. Ce qui fonctionnait parfois, c'est d'utiliser les données brutes d'une propriété pour prédire le comportement d'une autre propriété. De plus, n'oubliez pas que le fait de savoir qu'un utilisateur a un historique sur une autre propriété peut aider. Par exemple, la présence de l'activité des utilisateurs sur deux produits peut être en soi révélatrice.
Travail associé
Il existe de nombreux documents sur le machine learning chez Google et en externe.
- Cours d'initiation au machine learning, une introduction au machine learning appliqué
- Machine Learning: A Probabilistic Approach, par Kevin Murphy, pour mieux comprendre l'univers du machine learning
- Practical Advice for the Analysis of Large, Complex Data Sets, une approche des ensembles de données basée sur la science des données
- Deep Learning, par Ian Goodfellow et al., pour en savoir plus sur les modèles non linéaires
- Article de Google sur la dette technique (en anglais), qui contient de nombreux conseils généraux
- Documentation TensorFlow
Remerciements
15 Merci aussi à Kristen Lefevre, Suddha Basu et Chris Berg, qui nous ont aidés à créer une version antérieure. Toutes les erreurs, omissions ou (oups !) les opinions impopulaires sont les miennes.
Annexe
Ce document fait référence à divers produits Google. Pour plus de contexte, voici 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 YouTube" s'appuient sur des modèles de ML pour classer les recommandations de vidéos. "Vidéos à regarder ensuite" recommande des vidéos à regarder après celle en cours de lecture, tandis que la page d'accueil recommande des vidéos aux utilisateurs qui parcourent la page d'accueil.
Présentation de Google Play
Google Play propose de nombreux modèles pour résoudre divers problèmes. La recherche Play, les recommandations personnalisées de la page d'accueil Play et les applications "Les utilisateurs ont également installé" font tous appel au machine learning.
Présentation de Google Plus
Google Plus s'est appuyé sur le machine learning pour classer les posts dans le "flux" d'articles consultés par l'utilisateur, pour classer les posts "Populaire sur Google+" (posts très populaires actuellement), pour classer les 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.