Comment Light & Wonder a développé une solution de maintenance prédictive pour les machines de jeu sur AWS

Light & Wonder developed predictive maintenance solution for gaming machines on AWS.

Cet article est co-écrit avec Aruna Abeyakoon et Denisse Colin de Light and Wonder (L&W).

Basée à Las Vegas, Light & Wonder, Inc. est la principale entreprise de jeux vidéo multiplateforme mondiale qui fournit des produits et des services de jeu. Travaillant avec AWS, Light & Wonder a récemment développé une solution sécurisée de première industrie, Light & Wonder Connect (LnW Connect), pour diffuser en continu la télémétrie et les données de santé des machines d’environ un demi-million de machines de jeux électroniques réparties dans sa base de clients de casino dans le monde entier lorsque LnW Connect atteint son plein potentiel. Plus de 500 événements de machine sont surveillés en temps quasi-réel pour donner une image complète des conditions de la machine et de leur environnement de fonctionnement. En utilisant les données diffusées via LnW Connect, L&W vise à créer une meilleure expérience de jeu pour leurs utilisateurs finaux ainsi qu’à apporter plus de valeur à leurs clients de casino.

Light & Wonder s’est associée au Amazon ML Solutions Lab pour utiliser les données d’événements diffusées par LnW Connect pour permettre la maintenance prédictive alimentée par l’apprentissage automatique (ML) pour les machines à sous. La maintenance prédictive est un cas d’utilisation ML courant pour les entreprises avec des équipements physiques ou des actifs de machines. Avec la maintenance prédictive, L&W peut obtenir un avertissement avancé des pannes de machine et envoyer proactivement une équipe de service pour inspecter le problème. Cela réduira le temps d’arrêt de la machine et évitera une perte de revenus importante pour les casinos. Sans système de diagnostic à distance en place, la résolution des problèmes par l’équipe de service de Light & Wonder sur le sol du casino peut être coûteuse et inefficace, tout en dégradant considérablement l’expérience de jeu des clients.

La nature du projet est très exploratoire – il s’agit de la première tentative de maintenance prédictive dans l’industrie du jeu. Le Amazon ML Solutions Lab et l’équipe de L&W se sont lancés dans un voyage de bout en bout depuis la formulation du problème ML et la définition des métriques d’évaluation, jusqu’à la livraison d’une solution de haute qualité. Le modèle ML final combine CNN et Transformer, qui sont les architectures de réseau de neurones de pointe pour modéliser les données de journal séquentiel de la machine. Le poste présente une description détaillée de ce voyage, et nous espérons que vous l’apprécierez autant que nous !

• Révolutionner la découverte de médicaments un modèle d’apprentissage automatique identifie des composés potentiellement anti-âge et ouvre la voie à un traitement futur des maladies complexes.
• De la son à la vue Découvrez AudioToken pour la synthèse audio-image
• CI/CD pour les points d’extrémité multi-modèles dans AWS

Dans cet article, nous discutons des points suivants :

• Comment nous avons formulé le problème de maintenance prédictive en tant que problème ML avec un ensemble de métriques appropriées pour l’évaluation
• Comment nous avons préparé les données pour la formation et les tests
• Les techniques de prétraitement des données et d’ingénierie des caractéristiques que nous avons utilisées pour obtenir des modèles performants
• Réglage des hyperparamètres avec Amazon SageMaker Automatic Model Tuning
• Comparaisons entre le modèle de référence et le modèle final CNN+Transformer
• Les techniques supplémentaires que nous avons utilisées pour améliorer la performance du modèle, telles que l’ensemble de modèles

Contexte

Dans cette section, nous discutons des problèmes qui ont nécessité cette solution.

Ensemble de données

Les environnements de machines à sous sont fortement réglementés et sont déployés dans un environnement air-gapped. Dans LnW Connect, un processus de cryptage a été conçu pour fournir un mécanisme sécurisé et fiable pour que les données soient introduites dans un lac de données AWS pour la modélisation prédictive. Les fichiers agrégés sont chiffrés et la clé de déchiffrement n’est disponible que dans AWS Key Management Service (AWS KMS). Un réseau privé basé sur cellules vers AWS est mis en place à travers lequel les fichiers ont été téléchargés dans Amazon Simple Storage Service (Amazon S3).

LnW Connect diffuse une large gamme d’événements de machine, tels que le début de jeu, la fin de jeu, et plus encore. Le système collecte plus de 500 types d’événements différents. Comme le montre le tableau suivant, chaque événement est enregistré avec une horodatage de quand il s’est produit et l’ID de la machine enregistrant l’événement. LnW Connect enregistre également quand une machine entre dans un état non-jouable, et elle sera marquée comme une panne ou une défaillance de la machine si elle ne se rétablit pas dans un délai suffisamment court pour être jouable.

ID de la machine	ID de l’événement	Horodatage
0	E1	2022-01-01 00:17:24
0	E3	2022-01-01 00:17:29
1000	E4	2022-01-01 00:17:33
114	E234	2022-01-01 00:17:34
222	E100	2022-01-01 00:17:37

En plus des événements dynamiques de la machine, des métadonnées statiques sur chaque machine sont également disponibles. Cela inclut des informations telles que l’identifiant unique de la machine, le type de cabinet, l’emplacement, le système d’exploitation, la version du logiciel, le thème du jeu, et plus encore, comme indiqué dans le tableau suivant. (Tous les noms dans le tableau sont anonymisés pour protéger les informations des clients.)

ID de la machine	Type de Cabinet	OS	Emplacement	Thème de jeu
276	A	OS_Ver0	AA Resort & Casino	StormMaiden
167	B	OS_Ver1	BB Casino, Resort & Spa	UHMLIndia
13	C	OS_Ver0	CC Casino & Hotel	TerrificTiger
307	D	OS_Ver0	DD Casino Resort	NeptunesRealm
70	E	OS_Ver0	EE Resort & Casino	RLPMealTicket

Définition du problème

Nous considérons le problème de maintenance prédictive pour les machines à sous comme un problème de classification binaire. Le modèle de ML prend la séquence historique d’événements de la machine et d’autres métadonnées et prédit si une machine rencontrera une panne dans une fenêtre de temps future de 6 heures. Si une machine tombe en panne dans les 6 heures, elle est considérée comme une machine à haute priorité pour la maintenance. Sinon, elle est à faible priorité. La figure suivante donne des exemples d’échantillons à faible priorité (en haut) et à haute priorité (en bas). Nous utilisons une fenêtre de temps d’observation de longueur fixe pour collecter des données historiques sur les événements de la machine pour la prédiction. Les expériences montrent que des fenêtres de temps d’observation plus longues améliorent significativement les performances du modèle (plus de détails plus tard dans ce post).

Défis de modélisation

Nous avons rencontré quelques défis pour résoudre ce problème :

• Nous avons une quantité énorme de journaux d’événements qui contiennent environ 50 millions d’événements par mois (à partir d’environ 1 000 échantillons de jeux). Une optimisation minutieuse est nécessaire dans la phase d’extraction et de prétraitement des données.
• La modélisation des séquences d’événements était difficile en raison de la distribution extrêmement inégale des événements dans le temps. Une fenêtre de 3 heures peut contenir de quelques dizaines à des milliers d’événements.
• Les machines sont dans un bon état la plupart du temps et la maintenance à haute priorité est une classe rare, ce qui a introduit un problème de déséquilibre de classe.
• De nouvelles machines sont ajoutées en continu au système, nous devions donc nous assurer que notre modèle peut gérer la prédiction sur de nouvelles machines qui n’ont jamais été vues lors de l’entraînement.

Prétraitement des données et ingénierie de fonctionnalités

Dans cette section, nous discutons de nos méthodes pour la préparation des données et l’ingénierie de fonctionnalités.

Ingénierie de fonctionnalités

Les flux de machines à sous sont des événements de séries temporelles inégalement espacés ; par exemple, le nombre d’événements dans une fenêtre de 3 heures peut varier de quelques dizaines à des milliers. Pour gérer ce déséquilibre, nous avons utilisé des fréquences d’événements plutôt que les données de séquence brutes. Une approche directe est d’agréger la fréquence d’événements pour toute la fenêtre d’observation de l’historique et de la fournir au modèle. Cependant, lorsque nous utilisons cette représentation, l’information temporelle est perdue et l’ordre des événements n’est pas préservé. Nous avons plutôt utilisé un binning temporel en divisant la fenêtre de temps en N sous-fenêtres égales et en calculant les fréquences d’événements dans chacune. Les fonctionnalités finales d’une fenêtre temporelle sont la concaténation de toutes ses fonctionnalités de sous-fenêtre. L’augmentation du nombre de bacs préserve plus d’informations temporelles. La figure suivante illustre le binning temporel sur une fenêtre d’échantillon.

Tout d’abord, la fenêtre temporelle d’échantillon est divisée en deux sous-fenêtres égales (bins) ; ici, nous n’utilisons que deux bins pour des raisons de simplicité. Ensuite, les comptes des événements E1, E2, E3 et E4 sont calculés dans chaque bin. Enfin, ils sont concaténés et utilisés comme caractéristiques.

En plus des caractéristiques basées sur la fréquence des événements, nous avons utilisé des caractéristiques spécifiques à la machine telles que la version du logiciel, le type d’armoire, le thème du jeu et la version du jeu. De plus, nous avons ajouté des caractéristiques liées aux horodatages pour capturer la saisonnalité, telles que l’heure de la journée et le jour de la semaine.

Préparation des données

Pour extraire efficacement les données pour l’entraînement et les tests, nous utilisons Amazon Athena et le catalogue de données AWS Glue. Les données d’événements sont stockées dans Amazon S3 au format Parquet et partitionnées par jour/mois/heure. Cela facilite l’extraction efficace d’échantillons de données dans une fenêtre de temps spécifiée. Nous utilisons les données de toutes les machines du dernier mois pour les tests et le reste des données pour l’entraînement, ce qui aide à éviter les fuites de données potentielles.

Méthodologie ML et entraînement de modèle

Dans cette section, nous discutons de notre modèle de référence avec AutoGluon et de la façon dont nous avons construit un réseau de neurones personnalisé avec l’optimisation automatique des modèles SageMaker.

Construction d’un modèle de référence avec AutoGluon

Avec tout cas d’utilisation ML, il est important d’établir un modèle de référence à utiliser pour la comparaison et l’itération. Nous avons utilisé AutoGluon pour explorer plusieurs algorithmes classiques de ML. AutoGluon est un outil AutoML facile à utiliser qui utilise un traitement automatique des données, l’optimisation des hyperparamètres et l’ensemble des modèles. Le meilleur modèle de référence a été obtenu avec un ensemble pondéré de modèles d’arbres de décision à gradient boosté. La facilité d’utilisation d’AutoGluon nous a aidés dans la phase de découverte à naviguer rapidement et efficacement à travers une large gamme de directions de modélisation de données et de ML possibles.

Construction et optimisation d’un modèle de réseau de neurones personnalisé avec l’optimisation automatique des modèles SageMaker

Après avoir expérimenté avec différentes architectures de réseaux de neurones, nous avons construit un modèle d’apprentissage en profondeur personnalisé pour la maintenance prédictive. Notre modèle a surpassé le modèle de référence AutoGluon de 121 % en rappel à 80 % de précision. Le modèle final ingère des données d’historique de séquence d’événements de machine, ainsi que des caractéristiques de temps telles que l’heure de la journée et des métadonnées statiques de la machine. Nous utilisons des tâches d’optimisation automatique des modèles SageMaker pour rechercher les meilleurs hyperparamètres et architectures de modèle.

La figure suivante montre l’architecture du modèle. Nous normalisons d’abord les données de séquence d’événements binés en utilisant les fréquences moyennes de chaque événement dans l’ensemble d’entraînement pour éliminer l’effet écrasant des événements à haute fréquence (début de jeu, fin de jeu, etc.). Les embeddings pour les événements individuels sont apprenables, tandis que les embeddings de caractéristiques temporelles (jour de la semaine, heure de la journée) sont extraits à l’aide du package GluonTS. Ensuite, nous concaténons les données de séquence d’événements avec les embeddings de caractéristiques temporelles en tant qu’entrée du modèle. Le modèle se compose des couches suivantes :

• Couches de convolution (CNN) – Chaque couche CNN se compose de deux opérations de convolution unidimensionnelle avec des connexions résiduelles. La sortie de chaque couche CNN a la même longueur de séquence que l’entrée pour permettre un empilement facile avec d’autres modules. Le nombre total de couches CNN est un hyperparamètre réglable.
• Couches d’encodeur de transformateur (TRANS) – La sortie des couches CNN est alimentée avec l’encodage de position à une structure d’auto-attention multi-têtes. Nous utilisons TRANS pour capturer directement les dépendances temporelles au lieu d’utiliser des réseaux de neurones récurrents. Ici, le binning des données de séquence brute (réduisant la longueur de milliers à des centaines) aide à soulager les goulets d’étranglement de la mémoire GPU, tout en conservant l’information chronologique à un certain niveau (le nombre de bins est un hyperparamètre réglable).
• Couches d’agrégation (AGG) – La couche finale combine les informations de métadonnées (type de thème de jeu, type d’armoire, emplacements) pour produire la prédiction de probabilité de niveau de priorité. Elle se compose de plusieurs couches de pooling et de couches entièrement connectées pour une réduction de dimension incrémentielle. Les embeddings multi-hot de métadonnées sont également apprenables, et ne passent pas par les couches CNN et TRANS car ils ne contiennent pas d’informations séquentielles.

Nous utilisons la perte d’entropie croisée avec des poids de classe en tant qu’hyperparamètres ajustables pour résoudre le problème de déséquilibre des classes. De plus, le nombre de couches CNN et TRANS sont des hyperparamètres cruciaux avec des valeurs possibles de 0, ce qui signifie que certaines couches spécifiques peuvent ne pas toujours exister dans l’architecture du modèle. De cette manière, nous avons un cadre unifié où les architectures de modèle sont recherchées avec d’autres hyperparamètres habituels.

Nous utilisons l’optimisation d’hyperparamètres (HPO), également connue sous le nom de réglage automatique de modèle SageMaker, pour explorer efficacement les variations de modèle et l’espace de recherche de tous les hyperparamètres. L’optimisation de modèle automatique reçoit l’algorithme personnalisé, les données d’entraînement et les configurations d’espace de recherche d’hyperparamètres, et recherche les meilleurs hyperparamètres en utilisant différentes stratégies telles que Bayesian, Hyperband, et plus encore avec plusieurs instances GPU en parallèle. Après avoir évalué sur un ensemble de validation retenu, nous avons obtenu la meilleure architecture de modèle avec deux couches CNN, une couche TRANS avec quatre têtes et une couche AGG.

Nous avons utilisé les plages d’hyperparamètres suivantes pour rechercher la meilleure architecture de modèle :

hyperparameter_ranges = {
# Taux d'apprentissage
"learning_rate": ContinuousParameter(5e-4, 1e-3, scaling_type="Logarithmic"),
# Poids de classe
"loss_weight": ContinuousParameter(0.1, 0.9),
# Nombre de bacs d'entrée
"num_bins": CategoricalParameter([10, 40, 60, 120, 240]),
# Taux de baisse
"dropout_rate": CategoricalParameter([0.1, 0.2, 0.3, 0.4, 0.5]),
# Dimension d'incorporation de modèle
"dim_model": CategoricalParameter([160,320,480,640]),
# Nombre de couches CNN
"num_cnn_layers": IntegerParameter(0,10),
# Taille du noyau CNN
"cnn_kernel": CategoricalParameter([3,5,7,9]),
# Nombre de couches transformateurs
"num_transformer_layers": IntegerParameter(0,4),
# Nombre de têtes d'attention transformateur
"num_heads": CategoricalParameter([4,8]),
#Nombre de couches RNN
"num_rnn_layers": IntegerParameter(0,10), # facultatif
# Taille de la dimension d'entrée RNN
"dim_rnn":CategoricalParameter([128,256])
}

Pour améliorer encore la précision du modèle et réduire sa variance, nous avons entraîné le modèle avec plusieurs initialisations de poids aléatoires indépendantes et agrégé le résultat avec des valeurs moyennes en tant que prédiction de probabilité finale. Il y a un compromis entre les ressources informatiques supplémentaires et les performances du modèle, et nous avons observé que 5 à 10 devraient être un nombre raisonnable dans le cas d’utilisation actuel (résultats présentés plus tard dans ce post).

Résultats de performance du modèle

Dans cette section, nous présentons les métriques d’évaluation de performance du modèle et les résultats.

Métriques d’évaluation

La précision est très importante pour ce cas d’utilisation de maintenance prédictive. Une faible précision signifie signaler plus d’appels de maintenance faux, ce qui fait augmenter les coûts par une maintenance inutile. Étant donné que la précision moyenne (AP) ne correspond pas pleinement à l’objectif de haute précision, nous avons introduit une nouvelle métrique appelée rappel moyen à des précisions élevées (ARHP). ARHP est égal à la moyenne des rappels aux points de précision de 60%, 70% et 80%. Nous avons également utilisé la précision au top K% (K=1, 10), AUPR et AUROC comme métriques supplémentaires.

Résultats

Le tableau suivant résume les résultats en utilisant les modèles de réseau de neurones de base et personnalisés, avec le 7/1/2022 comme point de division d’entraînement/test. Les expériences montrent que l’augmentation de la longueur de la fenêtre et de la taille des données d’échantillonnage améliorent tous les deux les performances du modèle, car ils contiennent plus d’informations historiques pour aider à la prédiction. Indépendamment des paramètres de données, le modèle de réseau de neurones est plus performant qu’AutoGluon dans toutes les métriques. Par exemple, le rappel à la précision fixe de 80% est augmenté de 121%, ce qui vous permet d’identifier rapidement plus de machines défectueuses en utilisant le modèle de réseau de neurones.

Modèle	Longueur de la fenêtre/Taille des données	AUROC	AUPR	ARHP	[email protected]	[email protected]	[email protected]	Prec@top1%	Prec@top10%
AutoGluon de base	12H/500k	66.5	36.1	9.5	12.7	9.3	6.5	85	42
Réseau de neurones	12H/500k	74.7	46.5	18.5	25	18.1	12.3	89	55
AutoGluon de base	48H/1mm	70.2	44.9	18.8	26.5	18.4	11.5	92	55
Réseau de neurones	48H/1mm	75.2	53.1	32.4	39.3	32.6	25.4	94	65

Les figures suivantes illustrent l’effet de l’utilisation d’ensembles pour améliorer les performances du modèle de réseau de neurones. Toutes les métriques d’évaluation affichées sur l’axe des x sont améliorées, avec une moyenne plus élevée (plus précise) et une variance plus faible (plus stable). Chaque diagramme en boîte est issu de 12 expériences répétées, de zéro ensemble à 10 modèles dans les ensembles (axe des x). Des tendances similaires persistent dans toutes les métriques, sauf le Prec@top1% et le Recall@Prec80% affichés.

Après avoir pris en compte le coût informatique, nous observons que l’utilisation de 5 à 10 modèles dans les ensembles convient aux ensembles de données Light & Wonder.

Conclusion

Notre collaboration a abouti à la création d’une solution révolutionnaire de maintenance prédictive pour l’industrie du jeu, ainsi qu’à un cadre réutilisable qui pourrait être utilisé dans divers scénarios de maintenance prédictive. L’adoption des technologies AWS telles que l’optimisation automatique des modèles SageMaker facilite la navigation de Light & Wonder vers de nouvelles opportunités en utilisant des flux de données quasi en temps réel. Light & Wonder commence le déploiement sur AWS.

Si vous souhaitez obtenir de l’aide pour accélérer l’utilisation de l’apprentissage automatique dans vos produits et services, veuillez contacter le programme Amazon ML Solutions Lab.

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!