Règles du machine learning:

Bonnes pratiques d'ingénierie de ML

Martin Zinkevich

Ce document est destiné à ceux qui ont des connaissances de base bénéficient des bonnes pratiques de Google en matière de machine learning. Il présente un style pour le machine learning semblable au guide de style C++ de Google. et d'autres guides populaires de la programmation pratique. Si vous avez suivi un cours en machine learning, ou créé ou travaillé sur un modèle de machine learning, avez les informations 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 reviendront régulièrement dans notre discussion sur les machine learning:

  • Instance: ce sur quoi vous voulez créer la prédiction. Par exemple, il peut s'agir d'une page Web sur laquelle vous souhaitez classer comme "concernant les chats" ou "pas sur les chats".
  • Étiquette: la réponse d'une tâche de prédiction, soit la réponse produite par une ou la bonne réponse fournie dans les données d'entraînement. Pour 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. Pour exemple, une page Web peut comporter 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 dans lesquels les utilisateurs peuvent résider. Un exemple peut comporter une ou plusieurs caractéristiques présentes dans une colonne de caractéristiques. "Colonne de caractéristiques" est propre à Google. Une colonne de caractéristiques est appelée "espace de noms". dans le système VW (chez Yahoo/Microsoft), ou .
  • 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 utilisent le modèle 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 sur laquelle repose un algorithme de machine learning. Inclut la collecte des données en frontend et leur intégration dans les données d'entraînement les fichiers, l'entraînement d'un ou plusieurs modèles et leur exportation en production.
  • Taux de clics : pourcentage de visiteurs d'une page Web qui cliquent sur un dans une annonce.

Présentation

Pour créer des produits de qualité:

du machine learning comme un excellent ingénieur, et non comme un expert vous n'êtes pas un expert en machine learning.

La plupart des problèmes auxquels vous serez confronté sont en fait des problèmes d'ingénierie. Régulière avec toutes les ressources d'un grand expert en machine learning, la plupart des gains viennent d'excellentes caractéristiques, mais pas d'algorithmes de machine learning performants. L'option de base est la suivante:

  1. Assurez-vous que votre pipeline est fiable de bout en bout.
  2. Commencez par un objectif raisonnable.
  3. Ajoutez des caractéristiques de bon sens en toute simplicité.
  4. Assurez-vous que votre pipeline reste solide.

Cette approche est adaptée sur une longue période. Ne vous écartez de cette approche que lorsqu'il n'y en a plus des astuces simples pour aller encore plus loin. En ajoutant des complexités, vous ralentissez les prochaines versions.

Une fois que vous avez épuisé toutes les astuces, le machine learning de pointe être effectivement dans votre avenir. Consultez la section sur Phase III des projets de machine learning.

Ce document est organisé comme suit:

  1. La première partie vous aidera à comprendre si le moment est venu de créer un système de machine learning.
  2. La deuxième partie concerne le déploiement premier pipeline.
  3. La troisième partie concerne le lancement lorsque vous effectuez des itérations lors de l'ajout de caractéristiques à votre pipeline, comment évaluer des modèles et le décalage entraînement/inférence.
  4. La dernière partie sur ce qu'il faut faire quand on atteint un plateau.
  5. Vous pouvez ensuite consulter la liste des travaux connexes et une annexe avec quelques sur les systèmes communément 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 bien, mais il a besoin de données. En théorie, vous pouvez prendre des données d'un problème différent, puis d'ajuster le modèle pour un nouveau produit, seront probablement moins performantes heuristiques. Si vous pensez que le machine learning augmente de 100 %, puis une heuristique vous en obtiendra 50 %. du chemin à parcourir.

Par exemple, si vous classez les applications sur une place de marché, vous pouvez utiliser le le taux d'installations ou le nombre d'installations. Si vous détectez du spam, filtrer les éditeurs qui ont déjà envoyé du spam. N'ayez pas peur d'utiliser des compétences non plus. Si vous avez besoin de classer les contacts, classez les plus récents les plus élevés (voire les classer par ordre alphabétique). Si le machine learning n'est pas absolument requise 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 possible dans votre système actuel. Effectuez cette opération pour les raisons suivantes:

  1. Il est plus facile d'obtenir plus tôt l'autorisation des utilisateurs du système.
  2. Si vous pensez qu'un élément pourrait être préoccupant à l'avenir, il est pour obtenir des données historiques.
  3. Si vous concevez votre système en gardant à l'esprit l'instrumentation des métriques, ira mieux pour à l'avenir. Plus précisément, vous ne devez pas vous sentir perdu pour que les chaînes des journaux instrumentent vos métriques !
  4. 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 altérations importantes de l'expérience utilisateur n'ont aucun impact la métrique.

Les mesures des équipes Google+ augmentent par lecture, partages par lecture, et un +1 par lu, commentaires/lecture, commentaires par utilisateur, partages par utilisateur, etc. qu'ils utilisent pour calculer la qualité d'un post au moment de la présentation des résultats. Notez également qu'un un framework de test, dans lequel vous pouvez regrouper les utilisateurs dans des buckets et agréger par test est important. Voir Règle n° 12.

En recueillant des métriques de façon plus libérale, vous pouvez avoir une vision d'ensemble de votre système. Vous avez remarqué un problème ? Ajoutez une métrique pour en effectuer le suivi. Enthousiaste à propos de certaines sur la dernière version ? Ajoutez une métrique pour en effectuer le suivi.

Règle n° 3: choisissez le machine learning plutôt qu'une heuristique complexe

Une simple heuristique peut vous permettre de lancer votre produit. Une heuristique complexe est irréalisable. Une fois que vous avez des données et une idée de base de ce que vous essayez de d'accomplir, passez au machine learning. Comme dans la plupart des cas d'ingénierie tâches, vous devez constamment mettre à jour votre approche, qu'il s'agisse d'un heuristique ou de machine learning, et vous constaterez de machine learning est plus facile à mettre à jour et à gérer (consultez 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 à réfléchir à toutes les possibilités offertes par le machine learning, vous aurez du mal à comprendre ce qui se passe si vous ne faites pas confiance pipeline.

Règle n° 4: optez pour un premier modèle simple et optimisez l'infrastructure

Le premier modèle permet d'optimiser votre produit. Il n'a donc pas besoin d'être sophistiqué. Mais vous rencontrerez beaucoup plus de problèmes d'infrastructure que à vos attentes. Avant que quiconque puisse utiliser votre nouveau système de machine learning, pour déterminer:

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

En choisissant des fonctionnalités simples, vous vous assurez plus facilement 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 capable d'effectuer ces trois opérations de façon fiable, la plupart du travail. Votre modèle simple vous fournit des métriques de référence et une comportement de référence que vous pouvez utiliser pour tester des modèles plus complexes. Certaines équipes visent pour un modèle "neutre" Premier lancement: il s'agit d'un premier lancement qui abaisse explicitement sa priorité. le machine learning pour ne pas se laisser distraire.

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 d'apprentissage le système sont encapsulés afin que vous puissiez tester tout ce qui l'entoure. Plus spécifiquement :

  1. Testez l'obtention de données dans l'algorithme. Vérifiez que les colonnes de caractéristiques doit être renseignée. Lorsque la confidentialité le permet, inspecter l'entrée de votre algorithme d'entraînement ; Si possible, vérifiez statistiques dans votre pipeline par rapport à celles portant sur les mêmes données traités ailleurs.
  2. Testez la récupération de modèles à partir de l'algorithme d'entraînement. Vérifiez que la dans votre environnement d'entraînement donne le même score que le modèle dans votre environnement d'inférence (consultez règle n° 37).

Le machine learning étant un facteur d'imprévisibilité, assurez-vous avoir des tests pour le code afin de créer des exemples d'entraînement et d'inférence ; que vous pouvez charger et utiliser un modèle fixe pendant l'inférence. Il est également important pour comprendre vos données: consultez 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

Nous créons souvent un pipeline en copiant un pipeline existant (par exemple, programme culte ), et l'ancien pipeline supprime les données dont le nouveau pipeline a besoin. Par exemple, le pipeline "Populaire sur Google+" supprime les messages plus anciens (car il essaie de classer les messages récents). Ce pipeline était copié pour l'utiliser pour le flux Google Plus, où les posts plus anciens sont affichés restent significatives, mais le pipeline n'abandonnait pas les anciens posts. Autre communément consiste à ne consigner que les données qui ont été vues par l’utilisateur. Ainsi, ces données sont inutile si nous voulons modéliser les raisons pour lesquelles un message particulier n’a pas été vu par l’utilisateur, car tous les exemples négatifs ont été abandonnés. Un problème similaire s'est produit dans Lire. En travaillant sur la page d'accueil des applications de Play, un pipeline a été créé comportaient des exemples issus de la page de destination de Play Jeux, sans aucune fonctionnalité de faire une ambiguïté sur la provenance de chaque exemple.

Règle n° 7: transformez les 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 entièrement nouveau. Il existe un système de classement quel que soit le problème que vous essayez de résoudre. Cela signifie qu'il existe un grand nombre les règles et l'heuristique. Ces mêmes heuristiques peuvent vous donner un coup de pouce en cas d'ajustement grâce au machine learning. Vous devez exploiter vos heuristiques pour trouver des informations dont il dispose, pour deux raisons. Tout d'abord, la transition vers une machine le système appris seront plus fluides. Deuxièmement, ces règles contiennent généralement l’intuition par rapport au système que vous ne voulez pas jeter. Il y a quatre plusieurs façons d'utiliser une heuristique existante:

  • Effectuez un pré-traitement à l'aide de la méthode heuristique. Si la fonctionnalité est incroyablement géniale, c'est une option. Par exemple, si, dans un filtre antispam, l'expéditeur figure déjà sur la liste noire, n'essayez pas d'en savoir plus signifie. Bloquez le message. Cette approche est plus logique des tâches de classification.
  • Créez une caractéristique. Créer directement une caractéristique à partir d'une méthode heuristique est une bonne solution. Par exemple, si vous utilisez une heuristique pour calculer le score de pertinence d'une requête vous pouvez inclure le score en tant que valeur d'une caractéristique. Plus tard peuvent vouloir utiliser des techniques de machine learning pour manipuler la valeur (par exemple, la conversion de la valeur en un ensemble fini de ou les combiner avec d'autres caractéristiques), mais commencez par utiliser les valeurs la valeur générée par la méthode heuristique.
  • Explorez 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 dans et le jour de la semaine, puis pensez à séparer ces éléments, et en introduisant ces données séparément dans l'apprentissage. Quelques techniques qui s'appliquent aux ensembles (voir règle n° 40).
  • Modifiez le libellé. C'est une option si vous pensez que l'heuristique capture des informations qui ne figurent pas actuellement dans l'étiquette. Par exemple : si vous essayez d'optimiser le nombre de téléchargements, contenu de qualité, la solution consiste peut-être à multiplier l'étiquette par nombre moyen d'étoiles que l'application a reçues. La marge de manœuvre est ici considérable. Reportez-vous à la section Votre premier objectif.

Tenez compte de la complexité supplémentaire lorsque vous utilisez des méthodes heuristiques dans un modèle de ML. du système d'exploitation. L'utilisation d'anciennes heuristiques dans votre nouvel algorithme de machine learning peut pour faciliter la transition, mais demandez-vous plus simple pour obtenir le même effet.

Surveillance

En général, appliquez les bonnes pratiques d'alerte, par exemple en rendant les alertes exploitables et d'avoir un tableau de bord.

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

Dans quelle mesure les performances se dégradent-elles si votre modèle date d'un jour ? Une semaine âgée ? D'un quart ? Ces informations peuvent vous aider à comprendre les priorités de votre surveillance. Si vous perdez un produit important de qualité 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 annonces les systèmes de diffusion ont de nouvelles annonces à gérer chaque jour et doivent mettre à jour tous les jours. Par exemple, si le modèle de ML Recherche dans Google Play n'est pas à jour, elle peut avoir un un impact négatif en moins d'un mois. Quelques modèles pour "Populaire sur Google+" Les modèles Google+ n'ont pas d'identifiant de post. ils peuvent mais n'exportent pas souvent ces modèles. D'autres modèles avec des identifiants de post 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 d'exportation du modèle de l'inférence. En cas de problème avec un modèle exporté, il s'agit d'un modèle destiné aux utilisateurs problème.

Effectuez des contrôles d'intégrité juste avant d'exporter le modèle. Plus précisément, assurez-vous que ses performances soient raisonnables sur des données exclues. Ou, si vous avez qui posent problème avec les données, n'exportez pas le modèle. Nombreuses équipes des modèles en continu, vérifient la zone sous le Courbe ROC (ou AUC) avant l'exportation. Les problèmes liés aux modèles non exportés nécessitent alerte par e-mail, mais les problèmes sur un modèle visible par l'utilisateur peuvent nécessiter une page. Donc mieux d'attendre et d'être sûrs avant d'affecter les utilisateurs.

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

Ce problème survient plus souvent pour les systèmes de machine learning types de systèmes. Supposons qu'une table en cours de jointure n'est pas ne sont plus mis à jour. Le système de machine learning s'ajuste automatiquement seront raisonnablement bonnes, avec une dégradation progressive. Parfois, vous trouvez tables qui sont obsolètes depuis des mois, et une simple actualisation améliore les performances plus que pour tous les autres lancements de ce trimestre ! La couverture d'une une caractéristique peut changer en raison de modifications apportées à sa mise en œuvre (par exemple, une colonne de caractéristiques) peut être insérée dans 90% des exemples et chute soudainement à 60 % exemples. Une fois, Play avait une table qui est restée obsolète pendant six mois et qui était actualisée la table a permis à elle seule d'augmenter de 2% le taux d'installation. Si vous suivez des statistiques de les données, et inspectez manuellement les données de temps en temps, vous pouvez réduire ce genre de défaillances.

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

Si le système est volumineux et qu'il comporte de nombreuses colonnes de caractéristiques, vous devez savoir qui a créé ou qui conserve chaque colonne de caractéristiques. Si vous constatez que la personne qui comprend qu'une colonne de caractéristiques est abandonnée, assurez-vous que l'un d'eux des informations. Même si de nombreuses colonnes de caractéristiques ont des noms descriptifs, afin d'obtenir une description plus détaillée de la fonctionnalité et de son origine. et comment il est censé aider.

Votre premier objectif

Vous disposez de nombreuses métriques concernant le système qui vous intéresse, mais votre algorithme de machine learning ne nécessite souvent qu'un seul objectif, nombre que votre algorithme "essaie" à optimiser. Je distingue entre objectifs et métriques: une métrique est un nombre que votre système des rapports, qui peuvent être importants ou non. Voir aussi 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, satisfaire vos utilisateurs et rendre le monde meilleur. à un emplacement. Il existe un grand nombre de métriques qui vous intéressent, et vous devriez mesurer toutes les actions (voir la règle n° 2). Toutefois, au début du processus de machine learning, vous remarquerez qu'ils augmentent tous, celles que vous n'optimisez pas directement. Par exemple, supposons que vous vous souciez le nombre de clics et le temps passé sur le site. Si vous optimisez le nombre clics, vous constaterez probablement une augmentation du temps passé.

Restez simple et ne réfléchissez pas trop à l'équilibre entre différentes métriques. alors que vous pouvez facilement augmenter toutes les métriques. Ne tenez pas compte de cette règle Toutefois, ne confondez pas votre objectif et la santé ultime du (consultez la page règle n° 39). Et, si vous augmentez la valeur optimisée, mais en décidant de ne pas le lancer, une révision de l'objectif peut être requis.

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, vous examinez les données et analysez côte à côte votre ancien système et votre nouveau système de ML vous réalisez que vous voulez modifier l'objectif. En outre, différentes équipes les membres ne parviennent souvent pas à se mettre d'accord sur le véritable objectif. L'objectif du ML doit être quelque chose de facile à mesurer et qui sert de maillon de la « vraie » objectif. En fait, il n'y a souvent pas de « vrai » objectif (voir règle n° 39). Donc entraîner le modèle sur l'objectif de ML simple et envisager d'avoir une "couche de stratégie" ; en haut qui vous permet d'ajouter une logique supplémentaire (qui devrait être très simple) le classement final.

La méthode la plus simple à modéliser est un comportement utilisateur directement observé et imputable l'action du système:

  • L'utilisateur a-t-il 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épondu ou envoyé par e-mail ?
  • Cet objet classé a-t-il été évalué ?
  • Cet objet affiché a-t-il été marqué comme spam/pornographie/choquant ?

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

  • L'utilisateur est-il venu ici le lendemain ?
  • 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 et peuvent être utilisés lors des tests A/B et du lancement. décisions.

Enfin, n'essayez pas de faire en sorte que le machine learning sache:

  • 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 ?

Toutes ces informations sont importantes, mais aussi extrêmement difficiles à mesurer. Utilisez plutôt 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 est préoccupée, un jugement humain est nécessaire pour relier objectif du machine learning sur la nature du produit que vous vendez votre business plan.

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

La régression linéaire, la régression logistique et la régression de Poisson sont directement motivées par un modèle probabiliste. Chaque prédiction peut être interprétée comme une probabilité ou une valeur attendue. ce qui les rend plus faciles à déboguer que les modèles. qui utilisent des objectifs (perte zéro, diverses marges bénéficiaires, etc.) qui essaient pour optimiser directement la précision de la classification ou les performances du classement. Pour exemple : si les probabilités de l'entraînement s'écartent des probabilités prédites côte à côte ou en inspectant le système de production, révéler un problème.

Par exemple, dans la régression linéaire, logistique ou de Poisson, il existe des sous-ensembles de les données où l'attente moyenne prédite est égale à l'étiquette moyenne (1- moment calibré, ou juste calibré). Cela est vrai en supposant que vous n'avez pas et que votre algorithme a convergé. Elle est d'environ vrai en général. Si une caractéristique est égale à 1 ou à 0 pour chaque exemple, alors l'ensemble de 3 exemples où cette caractéristique est de 1 est calibré. De plus, si vous a une caractéristique qui est égale à 1 pour chaque exemple, alors l'ensemble de tous les exemples est calibrées.

Avec des modèles simples, il est plus facile de gérer les boucles de rétroaction (voir règle n° 36). Ces prédictions probabilistes sont souvent utilisées pour prendre une décision: par exemple, classement la valeur attendue diminue (probabilité de clics, de téléchargements, etc.). Gardez toutefois à l'esprit que lorsque vous devez choisir le modèle à utiliser, importe plus que la probabilité des données selon le modèle (voir 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 qualitatif est un art, mais le filtrage antispam est une guerre. Les signaux qui que vous utilisez pour identifier les posts de qualité devient évidente pour ceux et ajusteront leurs publications pour qu'elles aient ces propriétés. Ainsi, votre classement en termes de qualité doit être axé sur le classement du contenu publié la foi. Vous ne devez pas induire en erreur l'apprenant au classement de la qualité en ce qui concerne le classement des spams. fortement. De même, le terme "pour adultes" le contenu doit être traité séparément Classement. Le filtrage antispam est une autre histoire. Vous devez vous attendre à ce que que les caractéristiques à générer évoluent constamment. Souvent, il y a sont des règles évidentes que vous appliquez au système (si un message possède plus de trois votes de spam, de ne pas le récupérer, etc.). Tout modèle entraîné doivent être mis à jour quotidiennement, voire plus rapidement. La réputation du créateur du le contenu jouera un grand rôle.

À un certain niveau, les résultats de ces deux systèmes devront être intégrés. Conserver à l'esprit, le filtrage du spam dans les résultats de recherche devrait être plus strict que le filtrage du spam dans les e-mails. Par ailleurs, il est courant de supprimer des données d'entraînement pour le classificateur de qualité.

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

Lors de la première phase du cycle de vie d'un système de machine learning, les plus importantes sont d'intégrer les données d'entraînement dans le système d'apprentissage, instrumentées des métriques d'intérêt et créer une infrastructure d'inférence. Après vous disposez d'un système de bout en bout fonctionnel avec des tests unitaires et système instrumentés, La phase II commence.

La deuxième phase apporte de nombreux avantages faciles à comprendre. Il existe de nombreuses de caractéristiques évidentes qui pourraient être intégrées au système. Ainsi, la deuxième la phase du machine learning implique d'intégrer autant de caractéristiques que possible les combiner de manière intuitive. Au cours de cette phase, toutes les métriques encore en hausse. Il y aura beaucoup de lancements, et c'est le moment idéal pour faire appel à de nombreux ingénieurs qui peuvent rassembler toutes les données dont vous avez besoin pour 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 sera le dernier que vous lancerez, ou même un jour, que vous arrêterez de lancer des modèles. Ainsi, demandez-vous si la complexité que vous ajoutez avec ce lancement ralentira à l'avenir. De nombreuses équipes ont lancé un modèle par trimestre ou plus pour ans. Il existe trois raisons de base pour lancer de nouveaux modèles:

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

Quoi qu'il en soit, accorder un peu d'amour à un modèle peut être bénéfique: examiner les données alimentent l'exemple peut aider à trouver de nouveaux signaux, ainsi que d'anciens signaux uns. Quand vous créez votre modèle, réfléchissez à la facilité avec laquelle il est possible d'ajouter ou recombiner des caractéristiques. Pensez à la facilité avec laquelle il est possible de créer une nouvelle copie le pipeline et vérifier son exactitude. Demandez-vous s’il est possible de deux ou trois copies s'exécutent en parallèle. Enfin, ne vous inquiétez pas si la fonctionnalité 16 sur 35 arrive dans cette version du pipeline. Vous allez le prochain trimestre.

Règle n° 17: commencez par les caractéristiques observées et signalées directement, et non sur les caractéristiques apprises

Bien que ce point soit controversé, il permet d'éviter de nombreux pièges. Premier de expliquons ce qu'est une fonctionnalité apprise. Une fonctionnalité apprise est une fonctionnalité générés par un système externe (comme un clustering non supervisé) système) ou par l'apprenant lui-même (par exemple, via un modèle de factorisation ou de deep learning). Ces deux exemples peuvent être utiles, mais ils peuvent avoir beaucoup de problèmes, ils doivent donc ne pas figurer dans le premier modèle.

Si vous utilisez un système externe pour créer un élément, n'oubliez pas que a son propre objectif. L’objectif du système externe peut n’être que faible en corrélation avec votre objectif actuel. Si vous prenez un instantané du serveur alors il peut devenir obsolète. Si vous mettez à jour les fonctionnalités système externe, alors les significations peuvent changer. Si vous utilisez un système externe pour une fonctionnalité, sachez que cette approche nécessite un soin particulier.

Le principal problème des modèles factorisés et profonds est qu'ils non convexes. Il n'y a donc aucune garantie qu'une solution optimale puisse être approchés ou trouvés, et les minimums locaux trouvés à chaque itération peuvent être différentes. Cette variation rend difficile l'évaluation de l'impact sur votre système est significative ou aléatoire. En créant un modèle vous pouvez bénéficier d'excellentes performances de référence. Après cela de référence est atteint, vous pouvez essayer des approches plus originales.

Règle n° 18: utilisez des caractéristiques de contenu généralisables selon le contexte

Un système de machine learning ne représente souvent qu'une petite partie d'un processus beaucoup plus global. Pour Prenons l'exemple d'un post qui pourrait être utilisé dans "Populaire sur Google+". De nombreuses personnes peut attribuer +1 à un post, le partager ou le commenter avant qu'il ne s'affiche dans la section Chaud. Si vous fournissez ces statistiques au participant, celui-ci peut promouvoir de nouvelles publications pour lesquelles il n'a aucune donnée dans le contexte d'optimisation. La fonctionnalité "Vidéos à regarder ensuite" de YouTube peut être basée sur le nombre de vidéos regardées, ou sur les lectures (nombre de fois où une vidéo a été regardée après une autre regardés) à partir de la recherche YouTube. Vous pouvez aussi utiliser des mots notes attribuées par les visiteurs. Enfin, si vous utilisez une action de l'utilisateur en tant que libellé, voir que l'action effectuée sur le document dans un contexte différent peut s'avérer très utile . Toutes ces fonctionnalités vous permettent d'intégrer de nouveaux contenus dans le contexte. Notez qu'il ne s'agit pas de personnalisation: déterminez si quelqu'un aime 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 un grand volume de données, il est plus facile d'apprendre des millions de caractéristiques simples peu de fonctionnalités complexes. Identifiants des documents récupérés les requêtes canoniques n'offrent pas beaucoup de généralisation, mais alignent votre avec vos étiquettes dans les requêtes principales. Ainsi, n'ayez pas peur des groupes de où chaque caractéristique s'applique à une très petite partie de vos données, la couverture globale est supérieure à 90%. Vous pouvez utiliser la régularisation 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. Le machine learning tels que TensorFlow vous permettent de prétraiter vos données transformations. Les deux approches les plus courantes sont la "discrétisation" et "croix".

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

Les croisements combinent au moins deux colonnes de caractéristiques. Dans TensorFlow, une colonne de caractéristiques la terminologie 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 dans laquelle Exemple : {homme, femme} × {États-Unis,Canada, Mexique}. Cette nouvelle colonne de caractéristiques contiendra la caractéristique (homme, Canada). Si vous utilisez TensorFlow dites à TensorFlow de créer ce croisement pour vous, la caractéristique (homme, Canada) dans les exemples représentant des hommes canadiens. Notez qu'il faut d'énormes quantités grandes quantités de données permettant d'apprendre des modèles avec des croisements de trois, quatre ou plus de base colonnes de caractéristiques.

Les croisements produisant des colonnes de caractéristiques très volumineuses peuvent être en surapprentissage. Par exemple, Imaginons que vous fassiez une recherche et que vous ayez une colonne de caractéristiques avec les mots de la requête, et une colonne de caractéristiques contenant des mots document. Vous pouvez les combiner avec une croix, mais vous vous retrouverez avec beaucoup (voir la règle n° 21).

Lorsque vous travaillez avec du texte, deux possibilités s'offrent à vous. La stratégie la plus draconienne le produit scalaire. Dans sa forme la plus simple, un produit scalaire compte simplement le nombre mots en commun entre la requête et le document. Cette fonctionnalité peut ensuite être discrétisées. Une autre approche est l'intersection: nous avons donc une caractéristique qui est présent si et seulement si le mot "poney" se trouve à la fois dans le document requête, et une autre caractéristique qui est présente si et seulement si le mot "le" se trouve dans à la fois le document et 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

Les résultats fascinants de la théorie de l'apprentissage statistique concernant le niveau de complexité approprié pour un modèle, mais cette règle que vous devez connaître. J'ai eu des conversations au cours desquelles les gens doutaient que tout peut être appris à partir d'un millier d'exemples, ou que vous ont besoin de plus d'un million d'exemples, car ils restent bloqués dans une certaine méthode. d'apprentissage. La clé est d'adapter votre apprentissage à la taille de vos données:

  1. Si vous travaillez sur un système de classement dans les résultats de recherche et qu'il existe des millions de mots différents dans les documents et la requête, exemples étiquetés, vous devez alors utiliser un produit scalaire entre les documents et les caractéristiques de requête, TF-IDF, et une demi-douzaine d'autres systèmes caractéristiques. 1 000 exemples, une dizaine de caractéristiques.
  2. Si vous avez un million d'exemples, croisez le document et la requête des colonnes de caractéristiques, en utilisant la régularisation et éventuellement la sélection de caractéristiques. Vous obtenez des millions de caractéristiques, mais la régularisation vous permet en comporteront moins. Dix millions d'exemples, peut-être une centaine de milliers de caractéristiques.
  3. Si vous avez des milliards ou des centaines de milliards d'exemples, vous pouvez traverser les colonnes de caractéristiques avec les jetons de document et de requête, à l'aide de la sélection de caractéristiques ; et la régularisation. Vous aurez un milliard d'exemples, et 10 millions caractéristiques. La théorie de l'apprentissage statistique donne rarement des limites strictes, mais donne d’excellents conseils pour commencer.

En fin de compte, utilisez Règle n° 28 pour décider des fonctionnalités à utiliser.

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

Les caractéristiques inutilisées créent une dette technique. Si vous constatez que vous n'utilisez pas et que la combiner avec d'autres caractéristiques ne fonctionne pas, abandonnez de votre infrastructure. Vous devez garder votre infrastructure propre pour les fonctionnalités les plus prometteuses peuvent être essayées aussi vite que possible. Si si nécessaire, quelqu'un pourra toujours la rétablir.

Tenez compte de la couverture lorsque vous réfléchissez aux fonctionnalités à ajouter ou à conserver. Combien sont-ils couverts par cette fonctionnalité ? Par exemple, si vous avez de personnalisation, mais seuls 8% de vos utilisateurs bénéficient d'une personnalisation caractéristiques, il ne sera pas très efficace.

Dans le même temps, certaines caractéristiques peuvent dépasser leur poids. Par exemple, si une caractéristique ne couvre que 1% des données, mais 90% des exemples qui possèdent cette caractéristique sont positives, ce sera une excellente caractéristique à ajouter.

Analyse humaine du système

Avant de passer à la troisième phase du machine learning, se concentrer sur une activité qui n'est pas enseignée en cours de machine learning : examiner un modèle existant et l'améliorer. Il s’agit plus d’un art qu’un la science, et pourtant il existe plusieurs antimodèles qu'il permet d'éviter.

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

C'est peut-être le moyen le plus simple pour une équipe de s'enliser. Bien qu'il y ait de nombreux avantages au fishfooding (utilisation d'un prototype au sein de votre équipe) et en testant la version dogfood (utilisation d'un prototype au sein de votre entreprise), les employés doivent examiner si les performances sont correctes. Même si un changement ne doit pas être utilisé, tout élément qui semble raisonnablement proche de la production des tests approfondis, soit en payant des non-professionnels de l'éducation pour répondre à des questions sur une une plate-forme de crowdsourcing ou une expérience en direct sur de vrais utilisateurs.

Il y a deux raisons à cela. La première est que vous êtes trop proche du code source. Vous pouvez rechercher un aspect particulier des messages tout simplement trop impliqué émotionnellement (par exemple, préjugé de confirmation). Deuxièmement, votre temps est trop précieux. Considérez le coût de neuf ingénieurs assis dans un d'une heure de réunion, et pensez au nombre d'étiquettes humaines contractuels qui achètent de crowdsourcing.

Si vous voulez vraiment avoir des commentaires d'utilisateurs, exploitez l'expérience utilisateur méthodologies. Créer des personas utilisateur (une description se trouve dans le document de Crée des expériences utilisateur) au début du processus et faire des tests sur la facilité d’utilisation (une se trouve dans le document de Steve Krug Don't Make Me Think) plus tard. Personas utilisateur impliquent de créer un utilisateur hypothétique. Par exemple, si votre équipe est entièrement masculine, il peut être utile de concevoir un personnage utilisateur féminin de 35 ans (complètement avec caractéristiques), et examinez les résultats qu'elle génère au lieu de 10 résultats pour Hommes de 25 à 40 ans. Inviter des personnes réelles à regarder leur réaction à votre site (localement ou à distance) lors des tests d'utilisabilité peut également vous offrir une nouvelle du point de vue de l'utilisateur.

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

L'une des mesures les plus simples et parfois les plus utiles des utilisateurs ayant consulté votre nouveau modèle est de calculer dans quelle mesure les nouveaux résultats viennent de la production. Par exemple, si vous avez un problème de classement, exécuter les deux modèles sur un échantillon de requêtes sur l'ensemble du système, et examiner la taille de la différence symétrique des résultats (pondérée par le classement) ; moy.). Si la différence est minime, vous pouvez le constater une expérience qu'il y aura peu de changements. Si l'écart est très important alors vous devez vous assurer que le changement est bon. Regarder autour de vous pour les requêtes dont la différence symétrique est élevée peut vous aider à comprendre qualitativement comment était le changement. Assurez-vous toutefois que le système stable. Assurez-vous qu'un modèle, comparé à lui-même, présente une faible latence (idéalement (zéro) différence symétrique.

Règle n° 25: lors du choix de 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, au final, la clé est de savoir ce que vous en faites. Si vous l'utilisez pour classer , la qualité du classement final importe plus que la prédiction elle-même. Si vous prévoyez la probabilité qu'un document soit un spam puis définir une limite pour les éléments bloqués, la précision de ce qui est autorisé à travers les choses davantage. La plupart du temps, ces deux éléments doivent être accord: s'ils ne sont pas d'accord, le gain sera probablement minime. Ainsi, si certaines modifications améliorent la perte logistique, mais dégradent les performances le système, recherchez une autre fonctionnalité. Lorsque cela commence à se produire plus souvent, vous devez revoir l'objectif de votre modèle.

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

Supposons que vous voyiez un exemple d'entraînement dont le modèle est incorrect. Dans un 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é plus bas qu'une valeur négative. Le plus important, c'est qu'il s'agisse d'un exemple le système de machine learning sait qu'il s'est trompé et veut le corriger opportunité. Si vous fournissez au modèle une caractéristique qui lui permet de corriger l'erreur, le modèle essaiera de l'utiliser.

En revanche, si vous essayez de créer une caractéristique à partir d'exemples, système ne voit pas d'erreur, la fonctionnalité est ignorée. Par exemple, supposons qu'un internaute effectue une recherche sur "jeux sans frais" dans la recherche d'applications Google Play. Supposons l'un des meilleurs résultats est une application gag moins pertinente. Vous créez donc une caractéristique "applications gag". Toutefois, si vous maximisez le nombre d'installations, installent une application gag lorsqu'ils recherchent des jeux sans frais, les "applications gag" fonctionnalité n'aura pas l'effet escompté.

Une fois que vous disposez d'exemples de erreurs du modèle, recherchez les tendances en dehors de l'ensemble de caractéristiques actuel. Par exemple, si le système semble être rétrograder des articles plus longs, puis augmenter leur longueur. Ne soyez pas trop précis que vous ajoutez. Si vous ajoutez la longueur du post, n'essayez pas de deviner il suffit d'ajouter une dizaine de caractéristiques et de laisser le modèle décider (consultez la page 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 qu'ils n'aiment pas et qui ne sont pas capturés par la fonction de perte existante. À À ce stade, il doit tout faire pour l'amener à prendre de chiffres. Par exemple, s'il pense qu'il y a trop de "gag apps" sont affichées dans la recherche Google Play, ils peuvent demander à des évaluateurs manuels d'identifier les applications "gag". (Vous pouvez utiliser des données étiquetées manuellement dans ce cas, car une quantité relativement faible des requêtes représentent une grande partie du trafic.) Si votre problèmes sont mesurables, vous pouvez alors commencer à les utiliser comme fonctionnalités, objectifs, ou des métriques. La règle générale est : 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 avez 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 à la fois côte à côte et les tests A/B. Étant donné sa simplicité, vous la lancez. Cependant, vous remarquez qu'aucune nouvelle application ne s'affiche. Pourquoi ? Eh bien, puisque votre n'affiche qu'un document basé sur son propre historique pour cette requête, il n'y a pas d'apprendre qu'un nouveau document doit être présenté.

La seule façon de comprendre le fonctionnement d'un tel système sur le long terme est d'avoir l'entraînement ne repose que sur des données acquises lorsque le modèle est en ligne. C'est très difficiles.

Décalage entre entraînement et inférence

Le décalage entraînement/inférence est une différence entre les performances pendant l'inférence. Ce décalage peut être dû aux raisons suivantes:

  • Écart entre la manière dont vous traitez 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 celui de l'inférence.
  • Une boucle de rétroaction entre votre modèle et votre algorithme

Chez Google, nous avons observé des systèmes de machine learning en production avec un décalage au niveau de la diffusion ayant un impact négatif sur les performances. La meilleure solution consiste à les surveiller explicitement afin que les modifications apportées au système et aux données n'introduisent pas de décalage et passer inaperçus.

Règle n° 29: le meilleur moyen de s'assurer que l'entraînement se fait comme pour l'inférence consiste à enregistrer l'ensemble de caractéristiques utilisé lors de l'inférence, puis à transmettre ces caractéristiques dans un journal pour les utiliser lors de l'entraînement.

Même si vous ne pouvez pas le faire pour tous les exemples, faites-le pour une petite fraction, par exemple de vérifier la cohérence entre l'inférence et l'entraînement (consultez règle n° 37). Les équipes qui l'ont fait de mesure chez Google étaient parfois surpris par les résultats. Page d'accueil YouTube sont passées aux caractéristiques de journalisation au moment de l'inférence avec une qualité et une réduction de la complexité du code, et de nombreuses équipes changent de service. leur infrastructure au moment où nous parlons.

Règle n° 30: pondérez les données échantillonnées selon l'importance, ne les supprimez pas arbitrairement

Lorsque vous avez trop de données, vous pouvez être tenté de prendre les fichiers 1 à 12, et ignorer les fichiers 13 à 99. C'est une erreur. Bien que les données qui ont été ne sont jamais montrées à l'utilisateur, mais la pondération de l'importance reste. La pondération de l'importance signifie que si vous décidez exemple X avec une probabilité de 30 %, puis attribuez-lui une pondération de 10/3. Avec la pondération de l'importance, toutes les propriétés de calibration Règle n° 14 reste en place.

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 joignez les identifiants de document à une table contenant des caractéristiques pour ces documents (par exemple, le nombre de commentaires ou de clics). Entre l'entraînement et l'inférence, les caractéristiques le tableau peut être modifié. La prédiction de votre modèle pour le même document peut entre l'entraînement et l'inférence. Le moyen le plus simple d'éviter ce type de tri de problème est d'enregistrer les caractéristiques au moment de l'inférence (voir Règle n° 32 ). Si le tableau est ne changent que lentement, vous pouvez aussi prendre un instantané de la table toutes les heures ou tous les jours des données raisonnablement proches. Notez que cela ne résout pas complètement le problème.

Règle n° 32: réutilisez autant que possible 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 traiter chaque requête à mesure qu'elle arrive (par exemple, vous devez effectuer une recherche distincte pour chaque requête), tandis que le traitement par lot vous permet de combiner des tâches effectuer une jointure). Au moment de l'inférence, vous effectuez un traitement en ligne, alors que l'entraînement est une tâche de traitement par lot. Cependant, il y a certaines choses que vous pour réutiliser du code. Par exemple, vous pouvez créer un objet spécifiques à votre système, où le résultat des requêtes ou des jointures peut être stockées de manière lisible par l'humain, et les erreurs peuvent être facilement testées. Ensuite, Une fois que vous avez recueilli toutes les informations, exécuter une méthode courante pour faire le lien entre l'objet lisible propres à votre système, et quel que soit le format s'attend. Cela élimine une source de décalage entraînement/inférence. En tant que Par conséquent, essayez de ne pas utiliser deux langages de programmation différents pour l'entraînement et l'inférence. Avec cette décision, il vous sera presque impossible de partager du code source.

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 général, mesurer les performances d'un modèle sur les données recueillies après vous avez entraîné le modèle, car cela reflète mieux ce que fera votre système en production. Si vous produisez un modèle basé sur ces données jusqu'au 5 janvier, le modèle sur les données à partir du 6 janvier. Vous vous attendez à ce que les performances ne seront pas aussi bonnes avec les nouvelles données, mais elles ne devraient pas être radicalement pire. Étant donné qu'il peut y avoir des effets quotidiens, vous ne pourrez peut-être pas prédire le nombre moyen de clics ou taux de conversion, mais l'aire sous la courbe, qui représente probabilité d'attribuer à l'exemple positif un score supérieur à une valeur négative doivent être raisonnablement proches.

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

Dans une tâche de filtrage, les exemples marqués comme négatifs ne sont pas l'utilisateur. Supposons que vous ayez un filtre qui bloque 75% des exemples négatifs lors de l'inférence. Vous pourriez être tenté de tirer des données d'entraînement supplémentaires qui sont présentées aux utilisateurs. Par exemple, si un utilisateur marque un e-mail comme spam laisser passer votre filtre, vous voudrez peut-être en tirer des leçons.

Mais cette approche introduit un biais d’échantillonnage. Vous pouvez recueillir des données plus propres si Au lieu de cela, lors de la diffusion, vous attribuez le libellé "exclu" à 1% de l'ensemble du trafic a tenu des exemples à l'utilisateur. Votre filtre bloque alors au moins 74 % et d'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, devient moins viable. Malgré cela, si vous souhaitez mesurer l'inférence performances, vous pouvez créer un échantillon encore plus petit (par exemple, 0,1% ou 0,001%). Dix pour estimer les performances avec précision.

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

Lorsque vous changez l'algorithme de classement de façon suffisamment radicale pour que les résultats diffèrent s'affichent, vous avez modifié les données que votre algorithme va à l'avenir. Ce type de décalage apparaîtra, et vous devez concevoir votre et un modèle de ML qui l'entourent. Il existe plusieurs approches différentes. Ces approches sont 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 les caractéristiques qui sont activées pour une seule requête. Ainsi, le modèle privilégie spécifiques à une ou plusieurs requêtes, plutôt que des caractéristiques généraliser à toutes les requêtes. Cette approche permet d'éviter les attaques les résultats de fuite dans des requêtes non pertinentes. Notez que cette méthode est à l'opposé conseil plus conventionnel d'une régularisation plus poussée sur les colonnes de caractéristiques avec des valeurs uniques plus nombreuses.
  2. Autoriser uniquement les caractéristiques à avoir des pondérations positives. Ainsi, toute bonne caractéristique qu'une caractéristique "inconnue".
  3. ne proposent pas de fonctionnalités basées uniquement sur des documents ; Il s'agit d'une version extrême de la première approche. Pour par exemple, même si une application donnée est populaire, que vous ne voulez pas l'afficher partout. Ne pas utiliser uniquement des documents est simple. La raison pour laquelle vous ne voulez pas populaire est liée à l'importance rendant accessibles toutes les applications souhaitées. Par exemple, si un internaute recherche "application d'observation des oiseaux", ils téléchargent peut-être "angry Birds", mais cela n'était pas son intention. Afficher une telle application peut améliorer le taux de téléchargement, mais ne répondent 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é d'interaction de l'utilisateur avec lui. Si vous placez une application en première position, le nombre de clics sera plus élevé. et vous serez convaincu qu'ils ont plus de chances de générer des clics. Une façon de gérer pour ajouter des caractéristiques de position, c'est-à-dire des caractéristiques sur la position le contenu de la page. Vous entraînez votre modèle avec des caractéristiques de position, apprend à pondérer ; par exemple, la caractéristique "1re position" fortement. Votre modèle donne moins de poids à d'autres facteurs pour les exemples où "1stposition=true". Ensuite, lors de l'inférence, vous n'attribuez la caractéristique de position à aucune instance la même fonctionnalité par défaut, car vous notez les candidats ont décidé de l'ordre dans lequel les afficher.

Notez qu'il est important que les caractéristiques de position soient quelque peu séparées des du reste du modèle en raison de cette asymétrie entre l'entraînement et le test. Le modèle représente la somme d'une fonction des caractéristiques positionnelles et d'une du reste des caractéristiques est idéale. Par exemple, ne croisez pas avec n'importe quelle fonctionnalité de document.

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

De manière générale, plusieurs facteurs peuvent entraîner un décalage. Vous pouvez également le diviser en plusieurs parties:

  • Différence entre les performances sur les données d'entraînement et les données exclues données. En général, cela existera toujours, et ce n'est pas toujours mauvais.
  • Différence entre les performances sur les données exclues et les performances du jour suivant données. Encore une fois, cela existera toujours. Vous devez ajuster votre régularisation pour optimiser les performances du jour suivant. Toutefois, les baisses importantes des performances entre les données exclues et les données du jour suivant peut indiquer que certaines caractéristiques urgentes et susceptibles de dégrader les performances du modèle.
  • Différence entre les performances du "jour suivant" les données et le direct données. Si vous appliquez un modèle à un exemple dans les données d'entraînement lors de l'inférence, vous obtenez exactement le même résultat (voir Règle n° 5 ). Ainsi, un écart ici indique probablement une erreur d'ingénierie.

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

Certains signes indiquent que la deuxième phase touche à sa fin. Tout d'abord, vos gains mensuels vont commencer à diminuer. Vous commencerez à avoir des compromis entre les métriques: vous constaterez une hausse ou une baisse tests. C'est là que ça devient intéressant. Les gains étant plus difficiles à le machine learning doit devenir plus sophistiqué. Une mise en garde : comporte davantage de règles de ciel bleu que les sections précédentes. Nous avons vu de nombreuses équipes les phases I et II du machine learning. Phase unique III a été atteint, 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 un problème

Lorsque vos mesures stagnent, votre équipe commence à examiner les problèmes en dehors du champ d'application de votre système de machine learning actuel. En tant que mentionné précédemment, si les objectifs du produit ne sont pas couverts par l'algorithme existant vous devez modifier votre objectif ou les objectifs de votre produit. Pour par exemple, vous pouvez optimiser les clics, les +1 ou les téléchargements, mais n'oubliez pas des décisions 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 diminue. Quand elle réalise une expérience en direct, voit le taux d'installation augmenter. Cependant, lorsqu'elle examine le lancement réunion, 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 maintenant se rend compte que les décisions de lancement dépendent de plusieurs critères, dont seuls certains directement optimisées à l'aide du ML.

Le monde réel n'est ni des donjons, ni des dragons: il n'y a pas de "succès" points" 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, du nombre d'utilisateurs actifs par jour (UAJ) et de 30 UAJ, revenus et retour sur investissement de l'annonceur. Ces métriques mesurables dans les tests A/B ne constituent en eux-mêmes qu'un indicateur d'une stratégie à plus long terme objectifs: satisfaction des utilisateurs, augmentation du nombre d'utilisateurs, satisfaction des partenaires et bénéfices, ce qui, même dans ce cas, vous pouvez considérer que les proxies ont une fonction utile, de haute qualité et une entreprise florissante dans cinq ans.

Pour prendre des décisions de lancement faciles, il faut que toutes les métriques s'améliorent ou de ne pas empirer). Si l'équipe a le choix entre une machine sophistiquée un algorithme d'apprentissage automatique et une heuristique simple, si la méthode heuristique simple est plus efficace sur toutes ces métriques, il doit choisir la méthode heuristique. De plus, il existe n'inclut pas de classement explicite de toutes les valeurs possibles des métriques. Examinez plus précisément les deux scénarios suivants:

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

Si le système actuel est A, il est peu probable que l'équipe passe à B. Si le système actuel est B, il est peu probable que l'équipe passe à A. Ce semble en conflit avec le comportement rationnel ; Toutefois, les prédictions de changement les métriques peuvent s'inscrire ou non, ce qui implique un grand risque l'une ou l'autre de ces modifications. Chaque métrique couvre un certain risque qui préoccupe l'équipe.

De plus, aucune mesure ne couvre la préoccupation ultime de l'équipe, « où se trouve mon produit dans cinq ans » ?

Les individus, en revanche, ont tendance à favoriser un objectif qu'ils peuvent optimiser directement vos campagnes. La plupart des outils de machine learning favorisent un tel environnement. Une qui lance de nouvelles fonctionnalités peut générer un flux constant de lancements environnement. Il existe un type de machine learning, l'apprentissage multi-objectif, qui commence à résoudre ce problème. Par exemple, on peut formuler une un problème de satisfaction liée à une contrainte comportant des limites inférieures pour chaque métrique ; optimise une combinaison linéaire de métriques. Cependant, même dans ce cas, tous Les métriques sont facilement considérées comme des objectifs de machine learning: si un document est ou qu'une appli est installée, c'est parce que le contenu s'est affiché. Toutefois, il est beaucoup plus difficile de comprendre pourquoi un utilisateur visite votre site. Comment prédire la la réussite future d'un site dans son ensemble est IA-complet: aussi dur qu'un ordinateur la vision 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 (une "modèle" (qui combine les scores d'autres modèles) peut mieux fonctionner. Pour conserver les choses sont simples, chaque modèle doit être soit un ensemble qui ne prend en compte que l'entrée d'autres modèles, ou un modèle de base acceptant de nombreuses caractéristiques, mais pas les deux. Si vous avez par-dessus les autres modèles entraînés séparément, puis ils les combinent. peut entraîner un comportement insatisfaisant.

Pour l'assemblage, utilisez un modèle simple qui n'accepte que la sortie de votre "base". en entrée. Vous voulez également appliquer des propriétés à ces modèles d'ensemble. Par exemple, une augmentation du score produite par un modèle de base ne doit pas réduire le score de l'ensemble. De plus, il est préférable que les modèles entrants interprétable sémantiquement (par exemple, calibré) de sorte que les changements du les modèles sous-jacents ne perturbent pas le modèle d'ensemble. Assurez-vous également qu'un l'augmentation de la probabilité prédite d'un classificateur sous-jacent réduire la probabilité prédite de l'ensemble.

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

Vous avez ajouté des informations démographiques sur l'utilisateur. Vous en avez ajouté des informations sur les mots du document. Vous avez parcouru le modèle une exploration et un ajustement de la régularisation. Vous n'avez encore vu aucun lancement de 1% de vos métriques clés en quelques trimestres. Et maintenant ?

Il est temps de commencer à créer une infrastructure adaptée à des besoins radicalement différents. telles que l'historique des documents auxquels cet utilisateur a accédé dans du dernier jour, de la semaine ou de l'année, ou des données d'une autre propriété. Utilisez wikidata des entités ou des éléments internes à votre entreprise (comme Knowledge Graph). Utiliser le deep learning de machine learning. Commencez à ajuster vos attentes concernant le retour sur investissement. en fonction de vos attentes, et étendez vos efforts en conséquence. Comme pour toute projet d'ingénierie, vous devez évaluer les avantages de l'ajout de nouvelles caractéristiques contre le 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

Dans un ensemble de contenus, la diversité peut avoir plusieurs significations. La diversité des contenus la source du contenu étant l'une des plus courantes. La personnalisation implique l'utilisateur obtient ses propres résultats. La pertinence implique que les résultats d'une sont plus appropriées pour cette requête que toute autre. Ainsi, les trois ces propriétés sont définies comme différentes de l'ordinaire.

Le problème est qu'il est difficile de faire mieux que la situation ordinaire.

Notez que si votre système mesure les clics, le temps passé, les visionnages, les +1, (partages, etc.), vous mesurez la popularité du contenu. Équipes essaie parfois d'apprendre un modèle personnel avec de la diversité. Pour la personnaliser, ils ajoutent qui permettraient au système de personnaliser (certaines caractéristiques représentant les centres d'intérêt de l'utilisateur) ou de se diversifier (caractéristiques indiquant si ce document en commun avec d'autres documents renvoyés, comme l'auteur ou le contenu) et constater que ces caractéristiques sont moins lourdes (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 augmenter la diversité ou la pertinence. Si vous constatez une augmentation des objectifs à plus long terme, déclarer que la diversité/pertinence est précieuse, en plus de la popularité. Vous pouvez vous pouvez continuer à utiliser votre post-traitement ou modifier directement objectif en vous basant sur la diversité ou la pertinence.

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

Les équipes de Google ont obtenu beaucoup d'intérêt en adoptant un modèle prédisant le la proximité d'une connexion dans un produit et son bon fonctionnement dans un autre. Vos amis sont ce qu'ils sont. D'un autre côté, j'ai regardé plusieurs équipes ont des difficultés avec les fonctionnalités de personnalisation pour différents produits. Oui, il semble devrait fonctionner. Pour le moment, il semble que ce n'est pas le cas. Ce qui a parfois consiste à utiliser des données brutes d'une propriété pour prédire le comportement d'une autre. Par ailleurs, Même si le fait de savoir qu'un utilisateur est associé à un historique sur une autre propriété pour vous aider. Par exemple, l'activité de l'utilisateur sur deux produits peut être indicatif en soi.

Il existe de nombreux documents sur le machine learning, aussi bien chez Google qu'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 Shake, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira et Hrishikesh Aradhye pour de nombreuses corrections, suggestions et exemples utiles pour ce document. Merci également à Kristen Lefevre, Suddha Basu et Chris Berg qui ont contribué à une version précédente. N'importe quelle valeur des erreurs, des omissions ou des opinions impopulaires (désolé !) viennent de moi.

Annexe

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

Présentation de YouTube

YouTube est un service de streaming vidéo. À la fois sur YouTube à regarder ensuite et sur la page d'accueil YouTube Les équipes de pages utilisent des modèles de ML pour classer les recommandations de vidéos. Recommandations de "Ma sélection" vidéos à regarder après celle en cours de lecture, tandis que la page d'accueil recommande des vidéos aux utilisateurs parcourant la page d'accueil.

Présentation de Google Play

Google Play dispose de nombreux modèles pour résoudre différents problèmes. Recherche Play, Play Les recommandations personnalisées sur la page d'accueil et les applications "Les utilisateurs ont également installé" utilisent toutes le machine learning.

Présentation de Google Plus

Google+ a utilisé l'apprentissage automatique dans diverses situations: le classement des posts dans le "flux" nombre de posts consultés par l'utilisateur, dans le classement "Populaire sur Google+". posts (posts qui sont très populaires actuellement), 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 d'entreprise le 6 juillet 2020.