Esta publicación está coescrita con Suhyoung Kim, gerente general de KakaoGames Data Analytics Lab.

Juegos kakao es una importante editorial y desarrolladora de videojuegos con sede en Corea del Sur. Se especializa en desarrollar y publicar juegos para PC, dispositivos móviles y realidad virtual (VR) que brindan servicios a nivel mundial. Con el fin de maximizar la experiencia de sus jugadores y mejorar la eficiencia de las operaciones y el marketing, continuamente agregan nuevos elementos en el juego y brindan promociones a sus jugadores. El resultado de estos eventos puede ser evaluado posteriormente para que tomen mejores decisiones en el futuro.

Sin embargo, este enfoque es reactivo. Si podemos pronosticar el valor de por vida (LTV), podemos adoptar un enfoque proactivo. En otras palabras, estas actividades pueden planificarse y ejecutarse en función del LTV pronosticado, que determina los valores de los jugadores a lo largo de su vida en el juego. Con este enfoque proactivo, Kakao Games puede lanzar los eventos correctos en el momento correcto. Si el LTV pronosticado para algunos jugadores está disminuyendo, esto significa que es probable que los jugadores se vayan pronto. Kakao Games puede entonces crear un evento promocional para no abandonar el juego. Esto hace que sea importante pronosticar con precisión el LTV de sus jugadores. LTV es la medida adoptada no solo por las empresas de juegos, sino también por cualquier tipo de servicio con compromiso del cliente a largo plazo. Los métodos estadísticos y los métodos de aprendizaje automático (ML) se desarrollan y adoptan activamente para maximizar el LTV.

En esta publicación, compartimos cómo Kakao Games y el Laboratorio de soluciones de aprendizaje automático de Amazon se unieron para crear una solución de predicción de LTV escalable y confiable mediante el uso de datos de AWS y servicios de aprendizaje automático como Pegamento AWS y Amazon SageMaker.

Elegimos uno de los juegos más populares de Kakao Games, ODIN, como el juego objetivo del proyecto. ODIN es un popular juego de rol multijugador masivo en línea (MMORPG) para PC y dispositivos móviles publicado y operado por Kakao Games. Se lanzó en junio de 2021 y se clasificó entre los tres primeros en ingresos en Corea.

Desafios

En esta sección, analizamos los desafíos relacionados con varias fuentes de datos, la deriva de datos causada por eventos internos o externos y la reutilización de la solución. Estos desafíos generalmente se enfrentan cuando implementamos soluciones de ML y las implementamos en un entorno de producción.

Comportamiento del jugador afectado por eventos internos y externos

Es un desafío pronosticar el LTV con precisión, porque hay muchos factores dinámicos que afectan el comportamiento del jugador. Estos incluyen promociones de juegos, elementos recién agregados, días festivos, cuentas prohibidas por abuso o juego ilegal, o eventos externos inesperados como eventos deportivos o condiciones climáticas severas. Esto significa que el modelo que funciona este mes podría no funcionar bien el próximo mes.

Podemos utilizar eventos externos como características de ML junto con los registros y datos relacionados con el juego. Por ejemplo, Pronóstico del Amazonas admite datos de series temporales relacionadas, como el tiempo, los precios, los indicadores económicos o las promociones, para reflejar eventos relacionados internos y externos. Otro enfoque es actualizar los modelos de ML regularmente cuando se observa una desviación de datos. Para nuestra solución, elegimos el último método porque los datos de eventos relacionados no estaban disponibles y no estábamos seguros de cuán confiables eran los datos existentes.

El reentrenamiento continuo del modelo de ML es un método para superar este desafío al volver a aprender de los datos más recientes. Esto requiere no solo características bien diseñadas y una arquitectura de ML, sino también preparación de datos y canalizaciones de ML que puedan automatizar el proceso de reentrenamiento. De lo contrario, la solución ML no se puede operar de manera eficiente en el entorno de producción debido a la complejidad y la escasa repetibilidad.

No es suficiente volver a entrenar el modelo con el conjunto de datos de entrenamiento más reciente. Es posible que el modelo reentrenado no brinde un resultado de pronóstico más preciso que el existente, por lo que no podemos simplemente reemplazar el modelo con el nuevo sin ninguna evaluación. Necesitamos poder volver al modelo anterior si el nuevo modelo comienza a tener un rendimiento inferior por algún motivo.

Para resolver este problema, tuvimos que diseñar una canalización de datos sólida para crear las características de ML a partir de los datos sin procesar y MLOps.

Varias fuentes de datos

ODIN es un MMORPG en el que los jugadores del juego interactúan entre sí y hay varios eventos, como subir de nivel, comprar artículos y buscar oro (dinero del juego). Produce alrededor de 300 GB de registros todos los días de sus más de 10 millones de jugadores en todo el mundo. Los registros de juego son de diferentes tipos, como el inicio de sesión del jugador, la actividad del jugador, las compras del jugador y las subidas de nivel del jugador. Estos tipos de datos son datos brutos históricos desde una perspectiva de ML. Por ejemplo, cada registro se escribe en el formato de marca de tiempo, ID de usuario e información de eventos. El intervalo de registros no es uniforme. Además, hay datos estáticos que describen a los jugadores, como su edad y fecha de registro, que no son datos históricos. El modelo de predicción de LTV requiere estos dos tipos de datos como entrada porque se complementan entre sí para representar las características y el comportamiento del jugador.

Para esta solución, decidimos definir el conjunto de datos tabulares que combina las características históricas con el número fijo de pasos agregados junto con las características del reproductor estático. Las características históricas agregadas se generan a través de múltiples pasos a partir de la cantidad de registros del juego, que se almacenan en Atenea amazónica mesas. Además del desafío de definir las funciones para el modelo de ML, es fundamental automatizar el proceso de generación de funciones para que podamos obtener funciones de ML a partir de los datos sin procesar para la inferencia de ML y el reentrenamiento del modelo.

Para resolver este problema, construimos una canalización de extracción, transformación y carga (ETL) que se puede ejecutar de forma automática y repetida para la creación de conjuntos de datos de entrenamiento e inferencia.

Escalabilidad a otros juegos

Kakao Games tiene otros juegos con compromisos de jugadores a largo plazo como ODIN. Naturalmente, la predicción de LTV también beneficia a esos juegos. Debido a que la mayoría de los juegos comparten tipos de registro similares, quieren reutilizar esta solución ML para otros juegos. Podemos cumplir con este requisito utilizando el registro y los atributos comunes entre diferentes juegos cuando diseñamos el modelo ML. Pero todavía hay un desafío de ingeniería. La canalización de ETL, la canalización de MLOps y la inferencia de ML deben reconstruirse en una cuenta de AWS diferente. La implementación manual de esta solución compleja no es escalable y la solución implementada es difícil de mantener.

Para resolver este problema, hacemos que la solución ML se implemente automáticamente con algunos cambios de configuración.

Resumen de la solución

La solución de ML para la previsión de LTV se compone de cuatro componentes: la canalización de ETL del conjunto de datos de entrenamiento, la canalización de MLOps, la canalización de ETL del conjunto de datos de inferencia y la inferencia por lotes de ML.

La canalización de ETL de entrenamiento e inferencia crea funciones de aprendizaje automático a partir de los registros del juego y los metadatos del jugador almacenados en las tablas de Athena, y almacena los datos de funciones resultantes en un Servicio de almacenamiento simple de Amazon (Amazon S3) cubeta. ETL requiere varios pasos de transformación y el flujo de trabajo se implementa mediante AWS Glue. MLOps entrena modelos ML, evalúa el modelo entrenado contra el modelo existente y luego registra el modelo entrenado en el registro de modelos si supera al modelo existente. Todos estos se implementan como una única canalización de ML mediante Canalizaciones de Amazon SageMaker, y todos los entrenamientos de ML se gestionan a través de Experimentos de Amazon SageMaker. Con SageMaker Experiments, los ingenieros de ML pueden encontrar qué conjuntos de datos de capacitación y evaluación, hiperparámetros y configuraciones se usaron para cada modelo de ML durante la capacitación o posteriormente. Los ingenieros de ML ya no necesitan administrar estos metadatos de capacitación por separado.

El último componente es la inferencia por lotes de ML, que se ejecuta regularmente para predecir el LTV para las próximas dos semanas.

La siguiente figura muestra cómo estos componentes funcionan juntos como una única solución de ML.

La arquitectura de la solución se ha implementado utilizando el Kit de desarrollo en la nube de AWS (AWS CDK) para promover la infraestructura como código (IaC), lo que facilita el control de versiones y la implementación de la solución en diferentes cuentas y regiones de AWS

En las siguientes secciones, analizamos cada componente con más detalle.

Canalización de datos para la generación de características de ML

Los registros de juegos almacenados en Athena respaldados por Amazon S3 pasan por las canalizaciones de ETL creadas como trabajos de shell de Python en AWS Glue. Permite ejecutar secuencias de comandos de Python con AWS Glue para la precisión de características a fin de generar el conjunto de datos listo para el entrenamiento. Las tablas correspondientes en cada fase se crean en Athena. Usamos AWS Glue para ejecutar la canalización de ETL debido a su arquitectura sin servidor y su flexibilidad para generar diferentes versiones del conjunto de datos pasando varias fechas de inicio y finalización. Referirse a Acceder a parámetros usando getResolvedOptions para obtener más información sobre cómo pasar los parámetros a un trabajo de AWS Glue. Con este método, el conjunto de datos se puede crear para cubrir un período de tan solo 4 semanas, lo que respalda el juego en sus primeras etapas. Por ejemplo, la fecha de inicio de entrada y la fecha de inicio de predicción para cada versión del conjunto de datos se analizan mediante el siguiente código:

import sys
from awsglue.utils import getResolvedOptions args = getResolvedOptions( sys.argv, [ 'JOB_NAME', 'db_name', 'ds_version', 'input_start_date', 'prediction_start_date', 'bucket', 'prefix', 'timestamp' ]
)

Los trabajos de AWS Glue están diseñados y divididos en diferentes etapas y se activan secuencialmente. Cada trabajo está configurado para admitir argumentos de pares posicionales y de clave-valor para ejecutar canalizaciones ETL personalizadas. Un parámetro clave es la fecha de inicio y finalización de los datos que se utilizan en el entrenamiento. Esto se debe a que la fecha de inicio y finalización de los datos probablemente abarque diferentes días festivos y sirva como un factor directo para determinar la duración del conjunto de datos. Para observar el impacto de este parámetro en el rendimiento del modelo, creamos nueve versiones diferentes de conjuntos de datos (con diferentes fechas de inicio y duración del período de entrenamiento).

Específicamente, creamos versiones de conjuntos de datos con diferentes fechas de inicio (cambiadas por 4 semanas) y diferentes períodos de entrenamiento (12 semanas, 16 semanas, 20 semanas, 24 semanas y 28 semanas) en nueve bases de datos de Athena respaldadas por Amazon S3. Cada versión del conjunto de datos contiene las características que describen las características del jugador y los datos de series temporales de actividad de compra en el juego.

Modelo ML

Seleccionamos AutoGluón para el entrenamiento de modelos implementado con canalizaciones de SageMaker. AutoGluon es un conjunto de herramientas para el aprendizaje automático automatizado (AutoML). Permite AutoML fácil de usar y fácil de ampliar con un enfoque en el ensamblaje de pilas automatizado, el aprendizaje profundo y las aplicaciones del mundo real que abarcan imágenes, texto y datos tabulares.

Puede usar AutoGluon de forma independiente para entrenar modelos ML o junto con Piloto automático Amazon SageMaker, una característica de SageMaker que proporciona un entorno completamente administrado para entrenar e implementar modelos de ML.

En general, debe usar AutoGluon con Autopilot si desea aprovechar el entorno completamente administrado que proporciona SageMaker, incluidas funciones como el escalado automático y la administración de recursos, así como la implementación sencilla de modelos entrenados. Esto puede ser especialmente útil si es nuevo en ML y desea concentrarse en entrenar y evaluar modelos sin preocuparse por la infraestructura subyacente.

También puede usar AutoGluon independiente cuando desee entrenar modelos ML de forma personalizada. En nuestro caso, usamos AutoGluon con SageMaker para realizar una predicción en dos etapas, incluida la clasificación de rotación y la regresión del valor de por vida. En este caso, se considera que los jugadores que dejaron de comprar artículos del juego se retiraron.

Hablemos sobre el enfoque de modelado para la predicción de LTV y la efectividad del reentrenamiento del modelo contra el síntoma de deriva de datos, lo que significa los eventos internos o externos que cambian el patrón de compra de un jugador.

Primero, los procesos de modelado se separaron en dos etapas, incluida una clasificación binaria (clasificar a un jugador como abandonado o no) y un modelo de regresión que se entrenó para predecir el valor de LTV para los jugadores no abandonados:

• 1 – Los valores objetivo para LTV se convierten en una etiqueta binaria, LTV = 0 y LTV > 0. AutoGluon TabularPredictor está entrenado para maximizar la puntuación F1.
• 2 – Se utiliza un modelo de regresión con AutoGluon TabularPredictor para entrenar el modelo en usuarios con LTV > 0 para la regresión LTV real.

Durante la fase de prueba del modelo, los datos de prueba pasan por los dos modelos secuencialmente:

• 1 – El modelo de clasificación binaria se ejecuta en datos de prueba para obtener la predicción binaria 0 (usuario que tiene LTV = 0, agitado) o 1 (usuario que tiene LTV > 0, no batido).
• 2 – Jugadores pronosticados con LTV > 0 pasar por el modelo de regresión para obtener el valor real de LTV predicho. Combinado con el usuario predicho que tiene LTV = 0, se genera el resultado final de predicción de LTV.

Los artefactos del modelo asociados con las configuraciones de entrenamiento para cada experimento y para cada versión del conjunto de datos se almacenan en un depósito de S3 después del entrenamiento y también se registran en SageMaker Model Registry dentro de la ejecución de SageMaker Pipelines.

Para probar si hay alguna desviación de datos debido al uso del mismo modelo entrenado en el conjunto de datos v1 (12 semanas a partir de octubre), ejecutamos la inferencia en el conjunto de datos v1, v2 (hora de inicio adelantada 4 semanas), v3 (avanzada 8 semanas), y así sucesivamente para v4 y v5. La siguiente tabla resume el rendimiento del modelo. La métrica utilizada para la comparación es la puntuación minmax, cuyo rango es 0-1. Da un número más alto cuando la predicción de LTV está más cerca del valor real de LTV.

Se observa una caída del rendimiento en los conjuntos de datos v2 y v3, lo que es consistente con el análisis realizado en varios enfoques de modelado que tienen un rendimiento decreciente en los conjuntos de datos v2 y v3. Para v4 y v5, el modelo muestra un rendimiento equivalente e incluso muestra una ligera mejora en v5 sin reentrenamiento del modelo. Sin embargo, al comparar el rendimiento del modelo v1 en el conjunto de datos v5 (0.71533) con el rendimiento del modelo v5 en el conjunto de datos v5 (0.7599), el reentrenamiento del modelo mejora significativamente el rendimiento.

Tubería de formación

SageMaker Pipelines proporciona formas sencillas de redactar, administrar y reutilizar flujos de trabajo de ML; seleccionar los mejores modelos para implementar en producción; rastrear los modelos automáticamente; e integre CI/CD en canalizaciones de ML.

En el paso de entrenamiento, se construye un SageMaker Estimator con el siguiente código. A diferencia del SageMaker Estimator normal para crear un trabajo de capacitación, pasamos una sesión de canalización de SageMaker a SageMaker_session en lugar de una sesión de SageMaker:

from sagemaker.estimator import Estimator
from sagemaker.workflow.pipeline_context import PipelineSession pipeline_session = PipelineSession() ltv_train = Estimator( image_uri=image_uri, instance_type=instance_type, instance_count=1, output_path=output_path, base_job_name=f'{base_jobname_prefix}/train', role=role, source_dir=source_dir, entry_point=entry_point, sagemaker_session=pipeline_session, hyperparameters=hyperparameters
)

La imagen base se recupera mediante el siguiente código:

image_uri = SageMaker.image_uris.retrieve( "AutoGluon", region=region, version=framework_version, py_version=py_version, image_scope="training", instance_type=instance_type,
)

El modelo entrenado pasa por el proceso de evaluación, donde la métrica objetivo es minmax. Una puntuación superior a la mejor puntuación LTV minmax actual dará lugar a un paso de registro del modelo, mientras que una puntuación LTV minmax más baja no dará lugar a la actualización de la versión actual del modelo registrado. La evaluación del modelo en el conjunto de datos de prueba de reserva se implementa como un trabajo de procesamiento de SageMaker.

El paso de evaluación se define mediante el siguiente código:

step_eval = ProcessingStep( name=f"EvaluateLTVModel-{ds_version}", processor=script_eval, inputs=[ ProcessingInput( source=step_train.properties.ModelArtifacts.S3ModelArtifacts, destination="/opt/ml/processing/model", ), ProcessingInput( source=test, input_name='test', destination="/opt/ml/processing/test", ), ], outputs=[ ProcessingOutput(output_name="evaluation", source="/opt/ml/processing/evaluation"), ], code=os.path.join(BASE_DIR, "evaluate_weekly.py"), property_files=[evaluation_report], job_arguments=["--test-fname", os.path.basename(test)], )

Cuando se completa la evaluación del modelo, debemos comparar el resultado de la evaluación (minmax) con el rendimiento del modelo existente. Definimos otro paso de tubería, step_cond.

Con todos los pasos necesarios definidos, la canalización de ML se puede construir y ejecutar con el siguiente código:

# training pipeline
training_pipeline = Pipeline( name=f'odin-ltv-{ds_version}', parameters=[ processing_instance_count, model_approval_status, dataset_version, train_data, test_data, output_path, batch_instance_types, model_metrics, best_ltv_minmax_score ], steps=[step_train, step_eval, step_cond]
) ### start execution
execution = training_pipeline.start( parameters=dict( DatasetVersion=ds_version, )
)

Todo el flujo de trabajo es rastreable y visualizado en Estudio Amazon SageMaker, como se muestra en el siguiente gráfico. SageMaker Experiment rastrea automáticamente los trabajos de entrenamiento de ML para que pueda encontrar la configuración de entrenamiento de ML, los hiperparámetros, el conjunto de datos y el modelo entrenado de cada trabajo de entrenamiento. Elija cada uno de los módulos, registros, parámetros, salida, etc. para examinarlos en detalle.

Inferencia por lotes automatizada

En el caso de la predicción de LTV, se prefiere la inferencia por lotes a la inferencia en tiempo real porque el LTV predicho se usa normalmente para las tareas posteriores fuera de línea. Al igual que la creación de funciones de ML a partir del conjunto de datos de entrenamiento a través del ETL de varios pasos, tenemos que crear las funciones de ML como entrada al modelo de predicción de LTV. Reutilizamos el mismo flujo de trabajo de AWS Glue para convertir los datos de los jugadores en las características de ML, pero no se realizan la división de datos ni la generación de etiquetas. La característica de aprendizaje automático resultante se almacena en el depósito de S3 designado, que es supervisado por un AWS Lambda desencadenar. Cuando el archivo de características de ML se coloca en el depósito de S3, la función Lambda se ejecuta automáticamente, lo que inicia el trabajo de transformación por lotes de SageMaker utilizando el modelo LTV más reciente y aprobado que se encuentra en el Registro de modelos de SageMaker. Cuando se completa la transformación por lotes, los valores LTV de salida o previstos para cada jugador se guardan en el depósito S3 para que cualquier tarea posterior pueda recoger el resultado. Esta arquitectura se describe en el siguiente diagrama.

Con esta canalización que combina la tarea de ETL y la inferencia por lotes, la predicción de LTV se realiza simplemente ejecutando el flujo de trabajo de ETL de AWS Glue con regularidad, como una vez a la semana o una vez al mes. AWS Glue y SageMaker administran sus recursos subyacentes, lo que significa que esta canalización no requiere que mantenga ningún recurso en ejecución todo el tiempo. Por lo tanto, esta arquitectura que utiliza servicios administrados es rentable para tareas por lotes.

Solución implementable con AWS CDK

La canalización de ML en sí misma se define y ejecuta mediante Pipelines, pero la canalización de datos y el código de inferencia del modelo de ML, incluida la función Lambda, están fuera del alcance de Pipelines. Para que esta solución sea implementable y podamos aplicarla a otros juegos, definimos la canalización de datos y la inferencia del modelo de aprendizaje automático mediante el CDK de AWS. De esta forma, el equipo de ingeniería y el equipo de ciencia de datos tienen la flexibilidad de administrar, actualizar y controlar toda la solución de ML sin tener que administrar la infraestructura manualmente mediante el Consola de administración de AWS.

Conclusión

En esta publicación, discutimos cómo podríamos resolver la deriva de datos y los desafíos complejos de ETL mediante la creación de una canalización de datos automatizada y una canalización de ML utilizando servicios administrados como AWS Glue y SageMaker, y cómo convertirla en una solución de ML escalable y repetible para ser adoptada por otros juegos usando el CDK de AWS.

“En esta era, los juegos son más que solo contenido. Reúnen a las personas y tienen un potencial y un valor ilimitados cuando se trata de disfrutar de nuestras vidas. En Kakao Games, soñamos con un mundo lleno de juegos que cualquiera pueda disfrutar fácilmente. Nos esforzamos por crear experiencias en las que los jugadores quieran seguir jugando y crear lazos a través de la comunidad. El equipo de MLSL nos ayudó a crear una solución de aprendizaje automático de predicción de LTV escalable con AutoGluon para AutoML, Amazon SageMaker para MLOps y AWS Glue para canalización de datos. Esta solución automatiza el reentrenamiento del modelo para cambios de datos o juegos, y se puede implementar fácilmente en otros juegos a través de AWS CDK. Esta solución nos ayuda a optimizar nuestros procesos comerciales, lo que a su vez nos ayuda a mantenernos a la vanguardia”.

– SuHyung Kim, director del laboratorio de análisis de datos, Kakao Games.

Para obtener más información sobre las características relacionadas de SageMaker y AWS CDK, consulte lo siguiente:

Laboratorio de soluciones de Amazon ML

La Laboratorio de soluciones de Amazon ML empareja a su equipo con expertos en ML para ayudarlo a identificar e implementar las oportunidades de ML de mayor valor de su organización. Si desea acelerar el uso de ML en sus productos y procesos, comuníquese con Amazon ML Solutions Lab.

Acerca de los autores

Suhyung Kim es Gerente General en KakaoGames Data Analytics Lab. Es el responsable de recopilar y analizar datos, y se preocupa especialmente por la economía de los juegos en línea.

muhyun kim es científico de datos en Amazon Machine Learning Solutions Lab. Resuelve los diversos problemas comerciales de los clientes mediante la aplicación del aprendizaje automático y el aprendizaje profundo, y también los ayuda a capacitarse.

sheldon liu es científico de datos en Amazon Machine Learning Solutions Lab. Como profesional con experiencia en aprendizaje automático y habilidad en la arquitectura de soluciones escalables y confiables, trabaja con clientes empresariales para abordar sus problemas comerciales y brindar soluciones de aprendizaje automático efectivas.

Alex Chirayath es ingeniero sénior de aprendizaje automático en Amazon ML Solutions Lab. Dirige equipos de científicos e ingenieros de datos para crear aplicaciones de inteligencia artificial para abordar las necesidades comerciales.

Luna Gonsoo, Arquitecto de soluciones especialista en IA/ML en AWS, ha trabajado con clientes para resolver sus problemas de ML mediante los servicios de IA/ML de AWS. En el pasado, tenía experiencia en el desarrollo de servicios de aprendizaje automático en la industria manufacturera, así como en el desarrollo de servicios, análisis de datos y desarrollo de sistemas a gran escala en la industria de portales y juegos. En su tiempo libre, Gonsoo sale a caminar y juega con los niños.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/machine-learning/how-kakao-games-automates-lifetime-value-prediction-from-game-data-using-amazon-sagemaker-and-aws-glue/