La probabilité de mise au jeu est la Ligue nationale de hockey (NHL) première statistique avancée utilisant l'apprentissage automatique (ML) et l'intelligence artificielle. Il utilise les données de suivi des joueurs et des rondelles (PPT) en temps réel pour montrer aux téléspectateurs quel joueur est susceptible de gagner une mise au jeu avant que la rondelle ne soit lâchée, et offre aux diffuseurs et aux téléspectateurs la possibilité d'approfondir l'importance des matchs de mise au jeu. et les différences dans les capacités des joueurs. Sur la base de 10 ans de données historiques, des centaines de milliers de confrontations ont été utilisées pour concevoir plus de 70 fonctionnalités introduites dans le modèle afin de fournir des probabilités en temps réel. Les diffuseurs peuvent désormais discuter de la façon dont une victoire clé d'un joueur a conduit à un but ou de la façon dont les chances de gagner une mise au jeu diminuent lorsque le spécialiste de la mise au jeu d'une équipe est écarté d'un match nul. Les fans peuvent voir des prédictions visuelles en temps réel qui leur montrent l'importance d'un élément clé du jeu.

Dans cet article, nous nous concentrons sur la façon dont le modèle ML pour Face-off Probability a été développé et les services utilisés pour mettre le modèle en production. Nous partageons également les principaux défis techniques qui ont été résolus lors de la construction du modèle de probabilité de face à face.

Comment ça marche

Imaginez le scénario suivant : C'est un match nul entre deux équipes de la LNH qui déterminera qui avancera. Nous sommes en troisième période avec 1:22 secondes à jouer. Deux joueurs d'équipes opposées s'alignent pour prendre le match nul dans la mise au jeu la plus proche de l'un des filets. Le juge de lignes remarque qu'un joueur défensif empiète sur le cercle de mise au jeu et écarte son joueur de la mise au jeu en raison de la violation. Un joueur défensif moins expérimenté entre en jeu pour le remplacer. L'équipe attaquante remporte la mise au jeu, prend possession de la rondelle et marque immédiatement pour prendre les devants. Le score tient pour la minute restante du jeu et décide qui avance. Quel joueur a été favorisé pour remporter la mise au jeu avant que le duo initial ne soit changé ? De combien la probabilité de l'équipe défensive de gagner la mise au jeu a-t-elle diminué du fait de la violation qui a forcé un autre joueur à remporter le match nul ? Face-off Probability, la dernière statistique NHL Edge IQ optimisée par AWS, peut désormais répondre à ces questions.

Lorsqu'il y a un arrêt de jeu, la probabilité de mise au jeu génère des prédictions pour savoir qui gagnera la prochaine mise au jeu en fonction des joueurs sur la glace, de l'emplacement de la mise au jeu et de la situation actuelle du jeu. Les pronostics sont générés tout au long de l'arrêt jusqu'à ce que le chronomètre de jeu recommence à tourner. Les prédictions se produisent avec une latence inférieure à la seconde et sont déclenchées chaque fois qu'il y a un changement dans les joueurs impliqués dans la mise au jeu.

Surmonter les principaux obstacles pour la probabilité de mise au jeu

La prédiction de la probabilité de mise au jeu dans les diffusions en temps réel peut être décomposée en deux sous-problèmes spécifiques :

• Modélisation de l'événement face à face en tant que problème de ML, compréhension des exigences et des limites, préparation des données, ingénierie des signaux de données, exploration des algorithmes et garantie de la fiabilité des résultats
• Détecter un événement de mise au jeu pendant le jeu à partir d'un flux d'événements PPT, collecter les paramètres nécessaires à la prédiction, appeler le modèle et soumettre les résultats aux diffuseurs

Prédire la probabilité qu'un joueur gagne une mise au jeu en temps réel sur une émission télévisée a posé plusieurs défis techniques qui ont dû être surmontés. Celles-ci comprenaient la détermination des fonctionnalités requises et des méthodes de modélisation pour prédire un événement comportant une grande incertitude, et la détermination de la manière d'utiliser les données de capteur PPT en continu pour identifier où se déroule une mise au jeu, les joueurs impliqués et la probabilité de chaque joueur. remportant la mise au jeu, le tout en quelques centaines de millisecondes.

Créer un modèle ML pour les événements difficiles à prévoir

La prédiction d'événements tels que les probabilités de gain lors d'un match en direct est une tâche complexe qui nécessite une quantité importante de données historiques de qualité et des capacités de diffusion de données. Pour identifier et comprendre les signaux importants dans un environnement de données aussi riche, le développement de modèles ML nécessite une expertise approfondie en la matière. La Laboratoire de solutions Amazon Machine Learning s'est associé à des experts du hockey et des données de la LNH pour travailler à rebours de leur objectif cible d'améliorer l'expérience de leurs fans. En écoutant en permanence l'expertise de NHL et en testant des hypothèses, les scientifiques d'AWS ont conçu plus de 100 fonctionnalités en corrélation avec l'événement de mise au jeu. En particulier, l'équipe a classé cet ensemble de fonctionnalités dans l'une des trois catégories suivantes :

• Des statistiques historiques sur les performances des joueurs telles que le nombre de confrontations qu'un joueur a prises et gagnées au cours des cinq dernières saisons, le nombre de confrontations que le joueur a prises et gagnées lors des matchs précédents, les pourcentages de victoire d'un joueur sur plusieurs fenêtres temporelles, et le pourcentage de victoires en tête-à-tête pour chaque joueur dans la mise au jeu
• Caractéristiques du joueur telles que la taille, le poids, la latéralité et les années dans la ligue
• Données situationnelles en jeu susceptibles d'affecter les performances d'un joueur, telles que le score du jeu, le temps écoulé dans le jeu jusqu'à ce point, l'emplacement de la mise au jeu, la force de chaque équipe et le joueur qui doit mettre leur bâton vers le bas pour la mise au jeu en premier

Les scientifiques ML d'AWS ont considéré le problème comme un problème de classification binaire : soit le joueur local remporte la mise au jeu, soit le joueur extérieur remporte la mise au jeu. Avec les données de plus de 200,000 XNUMX confrontations historiques, ils ont utilisé un LumièreGBM modèle pour prédire lequel des deux joueurs impliqués dans un événement de mise au jeu est susceptible de gagner.

Déterminer si une mise au jeu est sur le point de se produire et quels joueurs sont impliqués

Lorsqu'un coup de sifflet retentit et que le jeu est arrêté, la probabilité de mise au jeu commence à faire des prédictions. Cependant, la probabilité de mise au jeu doit d'abord déterminer où la mise au jeu a lieu et quel joueur de chaque équipe est impliqué dans la mise au jeu. Le flux de données indique les événements au fur et à mesure qu'ils se produisent, mais ne fournit pas d'informations sur le moment où un événement est susceptible de se produire dans le futur. Ainsi, les données des capteurs des joueurs sur la glace sont nécessaires pour déterminer si et où une mise au jeu est sur le point de se produire.

Le système PPT produit des emplacements et des vitesses en temps réel pour les joueurs sur la glace jusqu'à 60 événements par seconde. Ces emplacements et vitesses ont été utilisés pour déterminer où la mise au jeu se déroule sur la glace et si elle est susceptible de se produire bientôt. En sachant à quel point les joueurs sont proches des emplacements de mise au jeu connus et à quel point les joueurs étaient stationnaires, Face-off Probability a pu déterminer qu'une mise au jeu était susceptible de se produire et les deux joueurs qui seraient impliqués dans la mise au jeu. .

La détermination de la distance de coupure correcte pour la proximité d'un emplacement de mise au jeu et la vitesse de coupure correspondante pour les joueurs stationnaires ont été accomplies à l'aide d'un modèle d'arbre de décision. Avec les données PPT de la saison 2020-2021, nous avons construit un modèle pour prédire la probabilité qu'une mise au jeu se produise à un endroit spécifié compte tenu de la distance moyenne de chaque équipe à l'emplacement et des vitesses des joueurs. L'arbre de décision a fourni les seuils pour chaque métrique, que nous avons inclus en tant que logique basée sur des règles dans l'application de streaming.

Une fois le lieu de mise au jeu correct déterminé, le joueur de chaque équipe effectuant la mise au jeu a été calculé en prenant le joueur le plus proche de l'emplacement connu de chaque équipe. Cela a donné à l'application la flexibilité d'identifier les bons joueurs tout en étant capable de s'adapter à un nouveau joueur devant faire une mise au jeu si un joueur actuel est annulé en raison d'une infraction. Faire et mettre à jour la prédiction pour le bon joueur était un objectif clé pour l'utilisabilité en temps réel du modèle dans les diffusions, que nous décrivons plus en détail dans la section suivante.

Développement de modèles et formation

Pour développer le modèle, nous avons utilisé plus de 200,000 100 points de données de confrontation historiques, ainsi que l'ensemble de fonctionnalités personnalisées conçues en collaboration avec les experts en la matière. Nous avons examiné des fonctionnalités telles que les situations dans le jeu, les performances historiques des joueurs prenant la mise au jeu, les caractéristiques spécifiques aux joueurs et les performances en tête-à-tête des joueurs prenant la mise au jeu, à la fois dans la saison en cours et pour leur carrières. Collectivement, cela a abouti à plus de XNUMX fonctionnalités créées à l'aide d'une combinaison de techniques disponibles et dérivées.

Pour évaluer différentes caractéristiques et comment elles pourraient influencer le modèle, nous avons effectué une analyse approfondie des caractéristiques dans le cadre de la phase exploratoire. Nous avons utilisé un mélange de tests univariés et de tests multivariés. Pour les tests multivariés, pour l'interprétabilité, nous avons utilisé des techniques de visualisation d'arbre de décision. Pour évaluer la signification statistique, nous avons utilisé les tests Chi Test et KS pour tester les différences de dépendance ou de distribution.

Nous avons exploré des techniques et des modèles de classification dans l'espoir que les probabilités brutes seraient traitées comme des prédictions. Nous avons exploré les voisins les plus proches, les arbres de décision, les réseaux de neurones, ainsi que le filtrage collaboratif en termes d'algorithmes, tout en essayant différentes stratégies d'échantillonnage (filtrage, échantillonnage aléatoire, stratifié et temporel) et évalué les performances sur l'aire sous la courbe (AUC) et distribution d'étalonnage avec la perte du score Brier. À la fin, nous avons constaté que le modèle LightGBM fonctionnait mieux avec des mesures de précision bien calibrées.

Pour évaluer les performances des modèles, nous avons utilisé plusieurs techniques. Nous avons utilisé un ensemble de tests auquel le modèle formé n'a jamais été exposé. De plus, les équipes ont procédé à des évaluations manuelles approfondies des résultats, en examinant des cas extrêmes et en essayant de comprendre les nuances de l'apparence du modèle pour déterminer pourquoi un certain joueur aurait dû gagner ou perdre un événement de mise au jeu.

Avec les informations recueillies auprès des réviseurs manuels, nous ajustions les fonctionnalités si nécessaire ou exécutions des itérations sur le modèle pour voir si les performances du modèle étaient conformes aux attentes.

Déploiement de la probabilité de confrontation pour une utilisation en temps réel lors des émissions de télévision nationales

L'un des objectifs du projet n'était pas seulement de prédire le vainqueur de la confrontation, mais de jeter les bases pour résoudre un certain nombre de problèmes similaires en temps réel et de manière rentable. Cet objectif a permis de déterminer les composants à utiliser dans l'architecture finale.

Le premier élément important est Flux de données Amazon Kinesis, un service de données en streaming sans serveur qui agit comme un découpleur entre l'implémentation spécifique du fournisseur de données PPT et les applications consommatrices, protégeant ainsi ces dernières des changements perturbateurs de la première. Il a également amélioré la fonction de diffusion, qui offre la possibilité de connecter jusqu'à 20 consommateurs parallèles et de maintenir une faible latence de 70 millisecondes et le même débit de 2 Mo/s par partition entre tous simultanément.

Les événements PPT ne viennent pas pour tous les joueurs à la fois, mais arrivent discrètement pour chaque joueur ainsi que pour les autres événements du jeu. Par conséquent, pour implémenter l'algorithme de détection de mise au jeu à venir, l'application doit maintenir un état.

Le deuxième élément important de l'architecture est Analyse des données Amazon Kinesis en Apache Flink. Apache Flink est un moteur de flux de données distribué en streaming, à haut débit et à faible latence qui offre un moyen pratique et facile d'utiliser l'API Data Stream, et il prend en charge les fonctions de traitement avec état, les points de contrôle et le traitement parallèle prêt à l'emploi. Cela permet d'accélérer le développement et donne accès à des routines et des composants de bas niveau, ce qui permet une conception et une mise en œuvre flexibles des applications.

Kinesis Data Analytics fournit l'infrastructure sous-jacente pour vos applications Apache Flink. Il élimine le besoin de déployer et de configurer un cluster Flink sur Cloud de calcul élastique Amazon (Amazon EC2) ou Kubernetes, ce qui réduit la complexité et les coûts de maintenance.

Le troisième élément crucial est Amazon Sage Maker. Bien que nous ayons utilisé SageMaker pour créer un modèle, nous devions également prendre une décision dès les premières étapes du projet : la notation devait-elle être implémentée à l'intérieur de l'application de détection de face-à-face elle-même et compliquer la mise en œuvre, ou l'application de détection de face-à-face devait-elle appeler SageMaker à distance et sacrifier une certaine latence due à la communication sur le réseau ? Pour prendre une décision éclairée, nous avons effectué une série de tests pour vérifier la latence et l'évolutivité de SageMaker, et validé que la latence moyenne était inférieure à 100 millisecondes sous la charge, ce qui était conforme à nos attentes.

Une fois les principales parties de l'architecture de haut niveau décidées, nous avons commencé à travailler sur la conception interne de l'application de détection de face-à-face. Un modèle de calcul de l'application est décrit dans le diagramme suivant.

Le modèle de calcul de l'application de détection de mise au jeu peut être modélisé comme une simple machine à états finis, où chaque message entrant fait passer le système d'un état à un autre tout en effectuant des calculs avec cette transition. L'application gère plusieurs structures de données pour suivre les éléments suivants :

• Changements dans l'état du jeu – Le numéro de la période actuelle, le statut et la valeur du chronomètre de jeu, et le score
• Changements dans l'état du joueur – Si le joueur est actuellement sur la glace ou sur le banc, les coordonnées actuelles sur le terrain et la vitesse actuelle
• Changements dans les statistiques de mise au jeu personnelles du joueur – Le taux de réussite d'un joueur par rapport à un autre, etc.

L'algorithme vérifie chaque événement de mise à jour de l'emplacement d'un joueur pour décider si une prédiction de mise au jeu doit être faite et si le résultat doit être soumis aux diffuseurs. En tenant compte du fait que l'emplacement de chaque joueur est mis à jour environ toutes les 80 millisecondes et que les joueurs se déplacent beaucoup plus lentement pendant les pauses de jeu que pendant le jeu, nous pouvons conclure que la situation entre deux mises à jour ne change pas radicalement. Si l'application appelait SageMaker pour les prédictions et envoyait des prédictions aux diffuseurs chaque fois qu'un nouvel événement de mise à jour de l'emplacement était reçu et que toutes les conditions étaient remplies, SageMaker et les diffuseurs seraient submergés par un certain nombre de demandes en double.

Pour éviter tout ce bruit inutile, l'application garde une trace d'une combinaison de paramètres pour lesquels des prédictions ont déjà été faites, ainsi que le résultat de la prédiction, et les met en cache en mémoire pour éviter les requêtes en double coûteuses à SageMaker. En outre, il garde une trace des prédictions qui ont déjà été envoyées aux diffuseurs et s'assure que seules les nouvelles prédictions sont envoyées ou que celles qui ont été envoyées précédemment ne sont renvoyées que si nécessaire. Les tests ont montré que cette approche réduit la quantité de trafic sortant de plus de 100 fois.

Une autre technique d'optimisation que nous avons utilisée consistait à regrouper les requêtes vers SageMaker et à les exécuter de manière asynchrone en parallèle. Par exemple, si nous avons quatre nouvelles combinaisons de paramètres de confrontation pour lesquelles nous devons obtenir des prédictions de SageMaker, nous savons que chaque requête prendra moins de 100 millisecondes. Si nous exécutons chaque requête de manière synchrone une par une, le temps de réponse total sera inférieur à 400 millisecondes. Mais si nous regroupons les quatre requêtes, les soumettons de manière asynchrone et attendons le résultat pour l'ensemble du groupe avant d'avancer, nous parallélisons efficacement les requêtes et le temps de réponse total sera inférieur à 100 millisecondes, comme pour une seule requête.

Résumé

NHL Edge IQ, optimisé par AWS, rapproche les fans de l'action avec des analyses avancées et de nouvelles statistiques ML. Dans cet article, nous avons montré un aperçu de la construction et du déploiement du nouveau modèle de probabilité de mise au jeu, la première statistique de ML à l'antenne pour la LNH. Assurez-vous de garder un œil sur les probabilités générées par la probabilité de mise au jeu lors des prochains matchs de la LNH.

Pour trouver des exemples complets de création de tâches de formation personnalisées pour SageMaker, visitez Apportez votre propre modèle de formation avec SageMaker en créant un conteneur personnalisé. Pour des exemples d'utilisation Amazon Kinésis pour le streaming, reportez-vous à Apprendre le développement d'Amazon Kinesis.

Pour en savoir plus sur le partenariat entre AWS et la LNH, visitez La LNH innove avec les services cloud AWS. Si vous souhaitez collaborer avec des experts pour apporter des solutions de ML à votre organisation, contactez le Laboratoire de solutions Amazon ML.

À propos des auteurs

Ryan Gillespie est un scientifique principal des données chez AWS Professional Services. Il est titulaire d'une maîtrise ès sciences de l'Université Northwestern et d'un MBA de l'Université de Toronto. Il possède une expérience antérieure dans les secteurs de la vente au détail et de l'exploitation minière.

Yash Shah est directeur scientifique au Laboratoire de solutions Amazon ML. Lui et son équipe de scientifiques appliqués et d'ingénieurs en apprentissage automatique travaillent sur une gamme de cas d'utilisation de l'apprentissage automatique dans les domaines de la santé, du sport, de l'automobile et de la fabrication.

Alexandre Egorov est un architecte principal de streaming, spécialisé dans les technologies de streaming. Il aide les organisations à concevoir et à construire des plateformes de traitement et d'analyse de données de streaming en temps réel.

Miguel Romero Calvo est scientifique appliquée à la Laboratoire de solutions Amazon ML où il s'associe aux équipes internes d'AWS et aux clients stratégiques pour accélérer leur activité grâce à l'adoption du ML et du cloud.

Eric Martinez est un architecte d'applications multimédia senior avec plus de 25 ans d'expérience, avec un accent sur les médias et le divertissement. Il est expérimenté dans tous les aspects du cycle de vie du développement de systèmes, depuis la découverte, la collecte des exigences, la conception, la mise en œuvre, les tests, le déploiement et l'exploitation.