Cómo Light & Wonder construyó una solución de mantenimiento predictivo para máquinas de juego en AWS.

How Light & Wonder built a predictive maintenance solution for gaming machines on AWS.

Este artículo está escrito en colaboración con Aruna Abeyakoon y Denisse Colin de Light and Wonder (L&W).

Con sede en Las Vegas, Light & Wonder, Inc. es la empresa global líder en juegos de azar multiplataforma que ofrece productos y servicios de juego. Trabajando con AWS, Light & Wonder desarrolló recientemente una solución segura pionera en la industria, Light & Wonder Connect (LnW Connect), para transmitir telemetría y datos de salud de la máquina desde aproximadamente medio millón de máquinas de juego electrónicas distribuidas en su base de clientes de casinos en todo el mundo cuando LnW Connect alcance su máximo potencial. Se monitorean más de 500 eventos de máquinas en tiempo casi real para obtener una imagen completa de las condiciones de las máquinas y sus entornos de operación. Utilizando los datos transmitidos a través de LnW Connect, L&W tiene como objetivo crear una mejor experiencia de juego para sus usuarios finales y brindar más valor a sus clientes de casinos.

Light & Wonder se asoció con el Amazon ML Solutions Lab para utilizar los datos de eventos transmitidos desde LnW Connect para habilitar el mantenimiento predictivo impulsado por aprendizaje automático (ML) para las máquinas tragamonedas. El mantenimiento predictivo es un caso de uso ML común para empresas con equipos físicos o activos de maquinaria. Con el mantenimiento predictivo, L&W puede recibir una advertencia avanzada de fallas de la máquina y enviar proactivamente un equipo de servicio para inspeccionar el problema. Esto reducirá el tiempo de inactividad de la máquina y evitará una pérdida significativa de ingresos para los casinos. Sin un sistema de diagnóstico remoto en su lugar, la resolución de problemas por parte del equipo de servicio de Light & Wonder en el piso del casino puede ser costosa e ineficiente, y degradar gravemente la experiencia de juego del cliente.

La naturaleza del proyecto es altamente exploratoria, esta es la primera vez que se realiza mantenimiento predictivo en la industria del juego. El Amazon ML Solutions Lab y el equipo de L&W emprendieron un viaje de principio a fin desde la formulación del problema de ML y la definición de las métricas de evaluación, hasta la entrega de una solución de alta calidad. El modelo de ML final combina CNN y Transformer, que son las arquitecturas de red neuronal de vanguardia para modelar datos secuenciales de registro de máquinas. El artículo presenta una descripción detallada de este viaje, ¡y esperamos que lo disfrutes tanto como nosotros!

• Revolucionando el descubrimiento de medicamentos modelo de aprendizaje automático identifica compuestos potenciales antienvejecimiento y allana el camino para futuros tratamientos de enfermedades complejas.
• De Sonido a Vista Conoce AudioToken para la Síntesis de Audio a Imagen.
• Red Cat y Athena AI crean drones militares inteligentes con visión nocturna.

En este artículo, discutimos lo siguiente:

• Cómo formulamos el problema de mantenimiento predictivo como un problema de ML con un conjunto de métricas apropiadas para la evaluación.
• Cómo preparamos los datos para el entrenamiento y la prueba.
• Técnicas de preprocesamiento de datos y de ingeniería de características que utilizamos para obtener modelos de alto rendimiento.
• Realización de un paso de ajuste de hiperparámetros con Amazon SageMaker Automatic Model Tuning.
• Comparaciones entre el modelo base y el modelo final CNN+Transformer.
• Técnicas adicionales que utilizamos para mejorar el rendimiento del modelo, como el ensamblaje.

Antecedentes

En esta sección, discutimos los problemas que hicieron necesaria esta solución.

Conjunto de datos

Los entornos de máquinas tragamonedas están altamente regulados y se implementan en un entorno sin conexión. En LnW Connect, se diseñó un proceso de cifrado para proporcionar un mecanismo seguro y confiable para que los datos se incorporen en un lago de datos de AWS para el modelado predictivo. Los archivos agregados están cifrados y la clave de descifrado solo está disponible en AWS Key Management Service (AWS KMS). Se establece una red privada basada en celular hacia AWS a través de la cual se cargaron los archivos en Amazon Simple Storage Service (Amazon S3).

LnW Connect transmite una amplia gama de eventos de máquinas, como el inicio del juego, el final del juego y más. El sistema recopila más de 500 tipos diferentes de eventos. Como se muestra en el siguiente, cada evento se registra junto con una marca de tiempo de cuándo ocurrió y la ID de la máquina que registra el evento. LnW Connect también registra cuando una máquina entra en un estado no jugable, y se marcará como una falla o avería de la máquina si no se recupera a un estado jugable dentro de un lapso de tiempo suficientemente corto.

ID de la máquina	ID del tipo de evento	Marca de tiempo
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

Además de los eventos dinámicos de la máquina, también se dispone de metadatos estáticos sobre cada máquina. Esto incluye información como el identificador único de la máquina, el tipo de armario, la ubicación, el sistema operativo, la versión del software, el tema del juego y más, como se muestra en la siguiente tabla. (Todos los nombres de la tabla se han anonimizado para proteger la información del cliente.)

ID de la máquina	Tipo de armario	SO	Ubicación	Tema del juego
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

Definición del problema

Tratamos el problema de mantenimiento predictivo para máquinas tragamonedas como un problema de clasificación binaria. El modelo de aprendizaje automático toma la secuencia histórica de eventos de la máquina y otros metadatos y predice si una máquina encontrará una falla en una ventana de tiempo futuro de 6 horas. Si una máquina se romperá dentro de las próximas 6 horas, se considera una máquina de alta prioridad para el mantenimiento. De lo contrario, es de baja prioridad. La siguiente figura muestra ejemplos de muestras de baja prioridad (arriba) y alta prioridad (abajo). Usamos una ventana de tiempo de longitud fija para recopilar datos de eventos históricos de la máquina para la predicción. Los experimentos muestran que las ventanas de tiempo de mayor longitud mejoran significativamente el rendimiento del modelo (más detalles más adelante en esta publicación).

Desafíos de modelado

Enfrentamos un par de desafíos al resolver este problema:

• Tenemos una gran cantidad de registros de eventos que contienen alrededor de 50 millones de eventos al mes (de aproximadamente 1,000 muestras de juego). Se necesita una optimización cuidadosa en la etapa de extracción y preprocesamiento de datos.
• El modelado de secuencias de eventos fue un desafío debido a la distribución extremadamente desigual de los eventos en el tiempo. Una ventana de 3 horas puede contener desde decenas hasta miles de eventos.
• Las máquinas están en buen estado la mayor parte del tiempo y el mantenimiento de alta prioridad es una clase rara, lo que introdujo un problema de desequilibrio de clases.
• Se agregan continuamente nuevas máquinas al sistema, por lo que tuvimos que asegurarnos de que nuestro modelo pueda manejar la predicción en nuevas máquinas que nunca se han visto en el entrenamiento.

Preprocesamiento de datos e ingeniería de características

En esta sección, discutimos nuestros métodos para la preparación de datos y la ingeniería de características.

Ingeniería de características

Los feeds de máquinas tragamonedas son flujos de eventos de series de tiempo desiguales en el tiempo; por ejemplo, el número de eventos en una ventana de 3 horas puede variar desde decenas hasta miles. Para manejar este desequilibrio, utilizamos frecuencias de eventos en lugar de los datos de secuencia sin procesar. Un enfoque sencillo es agregar la frecuencia de eventos para toda la ventana de observación y alimentarla al modelo. Sin embargo, al usar esta representación, se pierde la información temporal y no se preserva el orden de los eventos. En su lugar, utilizamos el particionamiento temporal dividiendo la ventana de tiempo en N subventanas iguales y calculando las frecuencias de eventos en cada una. Las características finales de una ventana de tiempo son la concatenación de todas sus características de subventana. Aumentar el número de particiones preserva más información temporal. La siguiente figura ilustra el particionamiento temporal en una ventana de muestra.

En primer lugar, la ventana de tiempo de muestra se divide en dos subventanas iguales (bins); aquí se usaron solo dos bins para simplificar la ilustración. Luego, se calculan las cuentas de los eventos E1, E2, E3 y E4 en cada bin. Por último, se concatenan y se utilizan como características.

Junto con las características basadas en la frecuencia de eventos, utilizamos características específicas de la máquina, como la versión del software, el tipo de gabinete, el tema del juego y la versión del juego. Además, agregamos características relacionadas con las marcas de tiempo para capturar la estacionalidad, como la hora del día y el día de la semana.

Preparación de datos

Para extraer datos de forma eficiente para el entrenamiento y la prueba, utilizamos Amazon Athena y el catálogo de datos AWS Glue. Los datos de los eventos se almacenan en Amazon S3 en formato Parquet y se dividen en días/meses/horas. Esto facilita la extracción eficiente de muestras de datos dentro de una ventana de tiempo especificada. Utilizamos los datos de todas las máquinas del último mes para la prueba y el resto de los datos para el entrenamiento, lo que ayuda a evitar posibles fugas de datos.

Metodología de ML y entrenamiento de modelos

En esta sección, discutimos nuestro modelo base con AutoGluon y cómo construimos una red neuronal personalizada con el ajuste automático de modelos de SageMaker.

Construir un modelo base con AutoGluon

Con cualquier caso de uso de ML, es importante establecer un modelo base que se pueda utilizar para comparar e iterar. Utilizamos AutoGluon para explorar varios algoritmos clásicos de ML. AutoGluon es una herramienta fácil de usar de AutoML que utiliza procesamiento automático de datos, ajuste de hiperparámetros y conjunto de modelos. El mejor modelo base se logró con un conjunto ponderado de modelos de árboles de decisión impulsados por gradientes. La facilidad de uso de AutoGluon nos ayudó en la etapa de descubrimiento para navegar rápidamente y de manera eficiente a través de una amplia gama de posibles direcciones de modelado de datos y ML.

Construcción y ajuste de un modelo de red neuronal personalizado con el ajuste automático de modelos de SageMaker

Después de experimentar con diferentes arquitecturas de redes neuronales, construimos un modelo de aprendizaje profundo personalizado para el mantenimiento predictivo. Nuestro modelo superó el modelo base de AutoGluon en un 121% en recall a un 80% de precisión. El modelo final ingiere datos de secuencias de eventos de máquinas históricas, características temporales como la hora del día y metadatos estáticos de la máquina. Utilizamos trabajos automáticos de ajuste de modelos de SageMaker para buscar los mejores hiperparámetros y arquitecturas de modelos.

La siguiente figura muestra la arquitectura del modelo. Primero normalizamos los datos de secuencia de eventos en bins promedio de cada evento en el conjunto de entrenamiento para eliminar el efecto abrumador de los eventos de alta frecuencia (inicio del juego, fin del juego, etc.). Los embeddings para eventos individuales son aprendibles, mientras que los embeddings de características temporales (día de la semana, hora del día) se extraen utilizando el paquete GluonTS. Luego, concatenamos los datos de secuencia de eventos con los embeddings de características temporales como entrada al modelo. El modelo consta de las siguientes capas:

• Capas convolucionales (CNN) – Cada capa CNN consta de dos operaciones convolucionales unidimensionales con conexiones residuales. La salida de cada capa CNN tiene la misma longitud de secuencia que la entrada para permitir una fácil combinación con otros módulos. El número total de capas CNN es un hiperparámetro ajustable.
• Capas de codificador de transformador (TRANS) – La salida de las capas CNN se alimenta junto con la codificación posicional a una estructura de auto-atención de varias cabezas. Utilizamos TRANS para capturar directamente las dependencias temporales en lugar de utilizar redes neuronales recurrentes. Aquí, la división de los datos de secuencia en bins (reducción de la longitud de miles a cientos) ayuda a aliviar los cuellos de botella de memoria de GPU, manteniendo la información cronológica hasta cierto punto (el número de bins es un hiperparámetro ajustable).
• Capas de agregación (AGG) – La capa final combina la información de metadatos (tipo de tema de juego, tipo de gabinete, ubicaciones) para producir la predicción de probabilidad del nivel de prioridad. Consiste en varias capas de agrupamiento y capas completamente conectadas para la reducción incremental de la dimensión. Los embeddings multi-hot de metadatos también son aprendibles y no pasan por las capas CNN y TRANS porque no contienen información secuencial.

Usamos la pérdida de entropía cruzada con pesos de clase como hiperparámetros ajustables para resolver el problema de desequilibrio de clases. Además, los números de capas CNN y TRANS son hiperparámetros cruciales con valores posibles de 0, lo que significa que ciertas capas no siempre existen en la arquitectura del modelo. De esta manera, tenemos un marco unificado donde se buscan las arquitecturas de los modelos junto con otros hiperparámetros habituales.

Utilizamos la sintonización automática de modelos de SageMaker, también conocida como optimización de hiperparámetros (HPO), para explorar eficientemente las variaciones del modelo y el amplio espacio de búsqueda de todos los hiperparámetros. La sintonización automática de modelos recibe el algoritmo personalizado, los datos de entrenamiento y la configuración del espacio de búsqueda de hiperparámetros, y busca los mejores hiperparámetros utilizando diferentes estrategias como Bayesian, Hyperband y más con múltiples instancias de GPU en paralelo. Después de evaluar en un conjunto de validación retenido, obtuvimos la mejor arquitectura del modelo con dos capas de CNN, una capa de TRANS con cuatro cabezas y una capa AGG.

Utilizamos los siguientes rangos de hiperparámetros para buscar la mejor arquitectura del modelo:

hyperparameter_ranges = {
# Learning Rate
"learning_rate": ContinuousParameter(5e-4, 1e-3, scaling_type="Logarithmic"),
# Class weights
"loss_weight": ContinuousParameter(0.1, 0.9),
# Number of input bins
"num_bins": CategoricalParameter([10, 40, 60, 120, 240]),
# Dropout rate
"dropout_rate": CategoricalParameter([0.1, 0.2, 0.3, 0.4, 0.5]),
# Model embedding dimension
"dim_model": CategoricalParameter([160,320,480,640]),
# Number of CNN layers
"num_cnn_layers": IntegerParameter(0,10),
# CNN kernel size
"cnn_kernel": CategoricalParameter([3,5,7,9]),
# Number of tranformer layers
"num_transformer_layers": IntegerParameter(0,4),
# Number of transformer attention heads
"num_heads": CategoricalParameter([4,8]),
#Number of RNN layers
"num_rnn_layers": IntegerParameter(0,10), # optional
# RNN input dimension size
"dim_rnn":CategoricalParameter([128,256])
}

Para mejorar aún más la precisión del modelo y reducir la varianza del modelo, entrenamos el modelo con múltiples inicializaciones de peso aleatorio independientes y agregamos el resultado con los valores medios como la predicción final de probabilidad. Existe un equilibrio entre más recursos informáticos y un mejor rendimiento del modelo, y observamos que 5-10 debería ser un número razonable en el caso de uso actual (los resultados se muestran más adelante en esta publicación).

Resultados del rendimiento del modelo

En esta sección, presentamos las métricas y resultados de evaluación del rendimiento del modelo.

Métricas de evaluación

La precisión es muy importante para este caso de uso de mantenimiento predictivo. Una baja precisión significa informar más llamadas de mantenimiento falsas, lo que aumenta los costos a través de un mantenimiento innecesario. Debido a que la precisión promedio (AP) no se alinea completamente con el objetivo de alta precisión, introdujimos una nueva métrica llamada recall promedio en altas precisiones (ARHP). ARHP es igual al promedio de los recuerdos en los puntos de precisión del 60%, 70% y 80%. También utilizamos la precisión en el K% superior (K=1, 10), AUPR y AUROC como métricas adicionales.

Resultados

La siguiente tabla resume los resultados utilizando los modelos de red neuronal base y personalizados, con el 7/1/2022 como punto de división de entrenamiento/prueba. Los experimentos muestran que el aumento de la longitud de la ventana y el tamaño de los datos de muestra mejoran el rendimiento del modelo, ya que contienen más información histórica para ayudar con la predicción. Independientemente de la configuración de los datos, el modelo de red neuronal supera a AutoGluon en todas las métricas. Por ejemplo, el recall con una precisión fija del 80% aumenta en un 121%, lo que le permite identificar rápidamente más máquinas con mal funcionamiento si se utiliza el modelo de red neuronal.

Modelo	Longitud de ventana/Tamaño de datos	AUROC	AUPR	ARHP	[email protected]	[email protected]	[email protected]	Prec@top1%	Prec@top10%
AutoGluon base	12H/500k	66.5	36.1	9.5	12.7	9.3	6.5	85	42
Red Neuronal	12H/500k	74.7	46.5	18.5	25	18.1	12.3	89	55
AutoGluon base	48H/1mm	70.2	44.9	18.8	26.5	18.4	11.5	92	55
Red Neuronal	48H/1mm	75.2	53.1	32.4	39.3	32.6	25.4	94	65

Las siguientes figuras ilustran el efecto de utilizar conjuntos para mejorar el rendimiento del modelo de red neuronal. Todas las métricas de evaluación mostradas en el eje x se mejoran, con una media más alta (más precisa) y una varianza más baja (más estable). Cada diagrama de caja es resultado de 12 experimentos repetidos, desde ningún conjunto hasta 10 modelos en conjuntos (eje x). Las tendencias similares persisten en todas las métricas, a excepción de Prec@top1% y Recall@Prec80% que se muestran.

Después de tener en cuenta el costo computacional, observamos que utilizar de 5 a 10 modelos en conjuntos es adecuado para los conjuntos de datos de Light & Wonder.

Conclusión

Nuestra colaboración ha resultado en la creación de una solución revolucionaria de mantenimiento predictivo para la industria del juego, así como en un marco reutilizable que podría utilizarse en una variedad de escenarios de mantenimiento predictivo. La adopción de tecnologías de AWS como la sintonización automática de modelos de SageMaker facilita a Light & Wonder explorar nuevas oportunidades utilizando flujos de datos casi en tiempo real. Light & Wonder está comenzando la implementación en AWS.

Si desea ayuda para acelerar el uso de ML en sus productos y servicios, comuníquese con el programa Amazon ML Solutions Lab.

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