Cómo predecir la deserción de jugadores, con ayuda de ChatGPT.

Predict player churn with ChatGPT.

Ciencia de datos usando una plataforma de ML de bajo código | Actable AI

Análisis de datos y entrenamiento de modelos para la predicción de abandono de jugadores, utilizando una plataforma de bajo código

Introducción

En el mundo de los videojuegos, las empresas se esfuerzan no solo por atraer jugadores, sino también por retenerlos el mayor tiempo posible, especialmente en juegos gratuitos que dependen de microtransacciones dentro del juego. Estas microtransacciones a menudo implican la compra de moneda dentro del juego, permitiendo a los jugadores adquirir elementos para la progresión o personalización, y financiando el desarrollo del juego. Es crucial monitorear la tasa de abandono, que representa el número de jugadores que dejan de jugar. Esto se debe a que una tasa de abandono alta significa una pérdida significativa de ingresos, lo que a su vez conduce a mayores niveles de estrés para los desarrolladores y gerentes.

Este artículo explora el uso de un conjunto de datos del mundo real basado en datos adquiridos de una aplicación móvil, enfocándose específicamente en los niveles jugados por los usuarios. Aprovechando el aprendizaje automático, que se ha convertido en una parte esencial del panorama tecnológico y forma la base de la inteligencia artificial (IA), las empresas pueden extraer información valiosa de sus datos.

Sin embargo, la construcción de modelos de aprendizaje automático típicamente requiere experiencia en programación y ciencia de datos, lo que lo hace inaccesible para muchas personas y empresas más pequeñas que carecen de recursos para contratar científicos de datos o hardware potente para manejar algoritmos complejos.

Para abordar estos desafíos, han surgido plataformas de aprendizaje automático de bajo y sin código con el objetivo de simplificar los procesos de aprendizaje automático y ciencia de datos, mitigando así la necesidad de conocimientos extensos de programación. Ejemplos de estas plataformas incluyen Einblick, KNIME, Dataiku, Alteryx y Akkio.

Este artículo utiliza una plataforma de aprendizaje automático de bajo código para entrenar un modelo capaz de predecir si un usuario dejará de jugar a un juego. Además, profundiza en la interpretación de resultados y técnicas que se pueden utilizar para mejorar el rendimiento del modelo.

• Ajustar MPT-7B en Amazon SageMaker
• Serie de Aprendizaje No Supervisado Explorando el Clustering Jerárq...
• Las habilidades blandas que necesitas para tener éxito como científ...

El resto de este artículo se organiza de la siguiente manera:

1. La plataforma
2. El conjunto de datos
3. Análisis exploratorio de datos
4. Entrenamiento de un modelo de clasificación
5. Mejorando el rendimiento del modelo
6. Creando nuevas características
7. Entrenamiento de un nuevo modelo de clasificación (con suerte mejorado)
8. Implementación del modelo en producción
9. Conclusiones

La plataforma

Divulgación completa – Soy científico de datos en Actable AI en el momento de escribir este artículo, por lo que es la plataforma que se utilizará en este artículo. También estoy involucrado en la implementación de nuevas características en la biblioteca de aprendizaje automático y su mantenimiento, por lo que estaba interesado en ver cómo la plataforma se desempeñaría en un problema del mundo real.

La plataforma proporciona una aplicación web con varios métodos de aprendizaje automático populares para las aplicaciones tradicionales de clasificación, regresión y segmentación. También están disponibles varias herramientas menos comunes, como la predicción de series temporales, el análisis de sentimientos y la inferencia causal. Los datos faltantes también se pueden imputar y se pueden calcular estadísticas de un conjunto de datos (como la correlación entre características, análisis de varianza (ANOVA), etc.), mientras que los datos se pueden visualizar utilizando herramientas como gráficos de barras, histogramas y nubes de palabras.

También está disponible un complemento de Google Sheets, lo que permite que los análisis y el entrenamiento de modelos se realicen directamente dentro de una hoja de cálculo. Sin embargo, tenga en cuenta que las características más nuevas pueden no estar disponibles en este complemento.

La biblioteca principal es de código abierto y está disponible en GitHub, y está compuesta por varios marcos conocidos y confiables como AutoGluon y scikit-learn, que también son de código abierto y gratuitos. Esto no es diferente a otras plataformas relacionadas, que también aprovechan soluciones de código abierto existentes.

Sin embargo, esto plantea la pregunta: ¿por qué usar tales plataformas en absoluto, si la mayoría de las herramientas ya están disponibles y son gratuitas para usar?

La principal razón es que estas herramientas requieren conocimientos de lenguajes de programación como Python, por lo que cualquier persona que no esté familiarizada con la codificación en general puede encontrar difícil o imposible su uso. Por lo tanto, estas plataformas tienen como objetivo proporcionar todas las funcionalidades en forma de una Interfaz Gráfica de Usuario (GUI), en lugar de un conjunto de comandos de programación.

Profesionales más experimentados también podrían beneficiarse potencialmente al ahorrar tiempo a través de una interfaz gráfica fácil de usar y que también puede proporcionar descripciones informativas de las herramientas y técnicas disponibles. Algunas plataformas también podrían presentar herramientas con las que no estabas familiarizado, o proporcionar advertencias potencialmente útiles (como la presencia de fuga de datos, que es cuando el modelo tiene acceso a características que no estarán disponibles cuando se implemente en producción en datos no vistos) al trabajar con tus datos.

Otra razón para usar este tipo de plataformas es que se proporciona el hardware en el que se ejecutan los modelos. Por lo tanto, no es necesario comprar y mantener sus propias computadoras y componentes como Unidades de Procesamiento Gráfico (GPU).

El conjunto de datos

El conjunto de datos, proporcionado por una compañía de juegos que utiliza la plataforma, se puede ver aquí y tiene una licencia CC BY-SA-4 asociada, lo que permite compartir y adaptar siempre que se proporcione el crédito correspondiente. Tiene un total de 789,879 filas (muestras), lo que es bastante sustancial y debería ayudar a reducir los efectos como el sobreajuste del modelo.

El conjunto de datos contiene información sobre cada nivel que una persona ha jugado en una aplicación móvil. Por ejemplo, hay información sobre la cantidad de tiempo jugado, si el jugador ganó o perdió el nivel, el número de nivel, y así sucesivamente.

Los IDs de usuario también se han incluido, pero se han anonimizado para no revelar las identidades de los jugadores originales. Algunos campos también se han eliminado. Sin embargo, debería proporcionar una base sólida para ver si las herramientas proporcionadas por la plataforma de ML considerada en este artículo pueden ser útiles para intentar predecir si un jugador abandonará.

El significado de cada característica es el siguiente:

• Churn: ‘1’ si el jugador no ha jugado el juego en más de 2 semanas, ‘0’ en caso contrario
• ServerTime: la marca de tiempo de los servidores cuando se jugó el nivel
• EndType: la razón por la que finalizó el nivel (principalmente ‘Win’ si el jugador ganó el juego, y ‘Lose’ si el jugador perdió el juego)
• LevelType: tipo de nivel
• Level: número de nivel
• SubLevel: número de subnivel
• Variant: variante de nivel
• Levelversion: versión de nivel
• NextCar: sin usar (incluido para ver cómo la plataforma maneja las características que tienen solo una etiqueta, como se discute más adelante)
• AddMoves: movimientos adicionales disponibles
• DoubleMana: sin usar (incluido para ver cómo la plataforma maneja las características que tienen solo una etiqueta, como se discute más adelante)
• StartMoves: número de movimientos disponibles al comienzo del nivel
• ExtraMoves: movimientos adicionales comprados
• UsedMoves: movimientos utilizados por el jugador
• UsedChangeCar: sin usar (incluido para ver cómo la plataforma maneja las características que tienen solo una etiqueta, como se discute más adelante)
• WatchedVideo: si se vio un video, proporcionando movimientos adicionales
• BuyMoreMoves: número de veces que un jugador compró más movimientos
• PlayTime: tiempo dedicado a jugar el nivel
• Scores: puntuación lograda por el jugador
• UsedCoins: monedas totales utilizadas en el nivel
• MaxLevel: máximo nivel alcanzado por el jugador
• Platform: tipo de dispositivo
• UserID: ID del jugador
• RollingLosses: número de pérdidas sucesivas del jugador

Análisis exploratorio de datos

El primer paso antes del entrenamiento es comprender los datos a través del Análisis Exploratorio de Datos (EDA). El EDA es un enfoque de análisis de datos que implica resumir, visualizar y comprender las principales características de un conjunto de datos. El objetivo es obtener información sobre los datos e identificar cualquier patrón, tendencia, anomalía o problema (por ejemplo, valores faltantes) que puedan estar presentes, y que puedan ayudar a informar las características y modelos a utilizar.

Comencemos por revisar las principales razones por las que se finalizan los niveles:

En la imagen de arriba, podemos ver que la causa predominante del final del nivel (representada por EndType) se debe a que el jugador pierde el juego (63,6%) en comparación con un 35,2% de los jugadores que ganan el juego. También podemos ver que la columna UsedChangeCar parece ser inútil ya que contiene el mismo valor para todas las filas.

Una observación muy importante es que nuestro valor objetivo está altamente desequilibrado, con solo 63 muestras de las primeras 10.000 filas (es decir, el 0,6% de los datos) que tienen un valor de abandono de 1 (es decir, un jugador ha abandonado). Esto deberá tenerse en cuenta, ya que es probable que nuestros modelos puedan estar muy fácilmente sesgados para predecir solo un valor de 0 para Churn. La razón es que el modelo puede obtener valores muy buenos para algunas métricas, como la precisión; en este caso, si un modelo ficticio simplemente selecciona la clase más prevalente, ¡estará en lo correcto el 99,4% del tiempo! Los invito a leer más sobre esto en dos excelentes artículos de Baptiste Rocca y Jason Brownlee.

Desafortunadamente, Actable AI aún no ofrece ninguna forma de manejar datos desequilibrados, como a través de la técnica de sobremuestreo de minorías sintéticas (SMOTE), o mediante el uso de pesos de clase o diferentes estrategias de muestreo. Esto significa que debemos tener cuidado cuando se trata de la métrica elegida para la optimización. Como se mencionó anteriormente, la precisión no sería la mejor opción dado que se puede lograr una tasa alta incluso si las muestras de una clase nunca se etiquetan correctamente.

Otro tipo útil de análisis es la correlación entre características, especialmente aquellas de las características predictoras con la característica objetivo. Esto se puede hacer usando la herramienta “Análisis de correlación”, cuyos resultados se pueden ver directamente en la plataforma Actable AI aquí:

En el gráfico anterior, las barras azules indican correlación positiva de una característica con el Churn cuando el valor es igual a 1, mientras que las barras anaranjadas indican correlaciones negativas de características. Debe tenerse en cuenta que la correlación se encuentra entre -1 y 1, donde los valores positivos representan que ambas características tienden a cambiar en la misma dirección (por ejemplo, ambas aumentan o ambas disminuyen), mientras que la correlación negativa simplemente indica que cuando una de las características aumenta o disminuye, la otra hace lo contrario. Como tal, la magnitud de la correlación (ignorando el signo negativo) es quizás lo más importante a tener en cuenta.

Hay varios puntos a tener en cuenta, como que los jugadores que pierden un nivel son más susceptibles a abandonar (la barra azul más alta), y que los jugadores que ganan un nivel tienden a seguir jugando (la tercera barra anaranjada). Sin embargo, también debe tenerse en cuenta que los valores son bastante bajos, lo que indica que estas características están débilmente correlacionadas con el objetivo. Esto significa que probablemente será necesario realizar ingeniería de características, mediante la cual se utilicen las características existentes para crear otras nuevas que capturen información más relevante que permita que un modelo realice predicciones más precisas. La ingeniería de características se discutirá con más detalle más adelante en este artículo.

Sin embargo, antes de crear nuevas características, vale la pena ver qué tipo de rendimiento podemos lograr utilizando solo las características originales en nuestro conjunto de datos. El siguiente paso será probablemente más emocionante: entrenar un modelo para ver qué tipo de rendimiento se puede lograr.

Entrenamiento de un modelo de clasificación

Dado que nos gustaría predecir si un usuario dejará de jugar o no, este es un problema de clasificación donde se debe seleccionar una de varias etiquetas. En nuestro caso, el problema implica asignar una de dos etiquetas (‘1’ corresponde a ‘Churn’ y ‘0’ corresponde a ‘No Churn’), lo que lo convierte en un problema de clasificación binaria.

Este proceso se realiza principalmente a través de la biblioteca AutoGluon, que entrena automáticamente varios modelos para luego seleccionar el que obtiene el mejor rendimiento. Esto evita tener que entrenar manualmente modelos individuales y comparar su rendimiento.

Un número de parámetros deben ser establecidos en la plataforma Actable AI, con mis elecciones mostradas a continuación:

También se puede elegir la métrica a utilizar para la optimización de los modelos. Yo utilicé el Área bajo la Curva Característica de Operación del Receptor (AUC ROC), ya que es mucho menos sensible al problema del desequilibrio de clases discutido anteriormente. Los valores varían de 0 a 1 (siendo este último un resultado perfecto).

Después de algún tiempo, se generan y muestran los resultados, los cuales también se pueden visualizar aquí . Se calculan una serie de métricas diferentes, lo cual no solo es una buena práctica sino también prácticamente necesario si realmente queremos entender nuestro modelo, ya que cada métrica se enfoca en ciertos aspectos del rendimiento de un modelo.

La primera métrica que se muestra es la métrica de optimización, con un valor de 0.675:

Esto no es genial, pero recordemos que las características estaban débilmente correlacionadas con el objetivo durante nuestro AED, por lo que no es sorprendente que el rendimiento sea poco notable.

Este resultado también destaca la importancia de entender los resultados; normalmente estaríamos muy contentos con una precisión del 0,997 (es decir, el 99,7%). Sin embargo, esto se debe en gran parte a la naturaleza altamente desequilibrada del conjunto de datos, como se discutió anteriormente, por lo que no debería darse mucha importancia. Mientras tanto, puntuaciones como la precisión y la recuperación se basan en un umbral de 0,5, que puede no ser el más adecuado para nuestra aplicación.

También se muestran las curvas ROC y de precisión-recuperación, que nuevamente muestran claramente que el rendimiento es un poco pobre:

Estas curvas también son útiles para determinar qué umbral podríamos usar en nuestra aplicación final. Por ejemplo, si se desea minimizar el número de falsos positivos, entonces podemos seleccionar un umbral donde el modelo obtenga una mayor precisión y verificar cómo será la recuperación correspondiente.

También se puede ver la importancia de cada característica para el mejor modelo obtenido, lo cual es quizás uno de los resultados más interesantes. Esto se calcula utilizando la importancia de permutación a través de AutoGluon . También se muestran los valores p para determinar la confiabilidad del resultado:

Quizás no sorprendentemente, la característica más importante es EndType (mostrando lo que causó el fin del nivel, como una victoria o una derrota), seguida de MaxLevel (el nivel más alto jugado por un usuario, con números más altos indicando que un jugador está bastante comprometido y activo en el juego).

Por otro lado, UsedMoves (el número de movimientos realizados por un jugador) es prácticamente inútil, y StartMoves (el número de movimientos disponibles para un jugador) podría perjudicar el rendimiento. Esto también tiene sentido, ya que el número de movimientos utilizados y el número de movimientos disponibles para un jugador por sí solos no son muy informativos; una comparación entre ellos probablemente sería mucho más útil.

También podríamos echar un vistazo a las probabilidades estimadas de cada clase (ya sea 1 o 0 en este caso), que se utilizan para derivar la clase predicha (por defecto, se asigna como la clase predicha aquella que tiene la probabilidad más alta):

La IA Explicable es cada vez más importante para entender el comportamiento del modelo, por lo que herramientas como los valores de Shapley están aumentando en popularidad. Estos valores representan la contribución de una característica en la probabilidad de la clase predicha. Por ejemplo, en la primera fila, podemos ver que un valor de RollingLosses de 36 disminuye la probabilidad de la clase predicha (clase 0, es decir, que la persona seguirá jugando al juego) para ese jugador.

Por el contrario, esto significa que la probabilidad de la otra clase (clase 1, es decir, que el jugador abandona) aumenta. Esto tiene sentido, porque valores más altos de RollingLosses indican que el jugador ha perdido muchos niveles en sucesión y es más probable que deje de jugar al juego debido a la frustración. Por otro lado, valores bajos de RollingLosses mejoran generalmente la probabilidad de la clase negativa (es decir, que el jugador no dejará de jugar).

Como se mencionó, se entrenan y evalúan varios modelos, después de lo cual se selecciona el mejor. Es interesante ver que el mejor modelo en este caso es LightGBM, que también es uno de los más rápidos:

Mejorando el rendimiento del modelo

En este punto, podemos intentar mejorar el rendimiento del modelo. Quizás una de las formas más fáciles sea seleccionar la opción “Optimizar la calidad” y ver hasta dónde podemos llegar. Esta opción configura varios parámetros que se sabe que mejoran el rendimiento en general, a expensas de un tiempo de entrenamiento potencialmente más lento. Se obtuvieron los siguientes resultados (que también se pueden ver aquí):

Nuevamente, centrándonos en la métrica de ROC AUC, el rendimiento mejoró de 0.675 a 0.709. Esto es un aumento bastante agradable para un cambio tan simple, aunque todavía lejos de ser ideal. ¿Hay algo más que podamos hacer para mejorar el rendimiento aún más?

Creando nuevas características

Como se discutió anteriormente, podemos hacer esto utilizando la ingeniería de características. Esto implica crear nuevas características a partir de las existentes, que puedan capturar patrones más sólidos y estén más altamente correlacionadas con la variable a predecir.

En nuestro caso, las características en el conjunto de datos tienen un alcance bastante limitado ya que los valores se refieren solo a un registro (es decir, la información sobre un nivel jugado por el usuario). Por lo tanto, podría ser muy útil obtener una perspectiva más global resumiendo los registros con el tiempo. De esta manera, el modelo tendría conocimiento sobre las tendencias históricas de un usuario.

Por ejemplo, podríamos determinar cuántos movimientos extra utilizó el jugador, proporcionando así una medida de la dificultad experimentada; si se necesitaron pocos movimientos extra, entonces el nivel podría haber sido demasiado fácil; por otro lado, un número alto podría significar que el nivel fue demasiado difícil.

También sería una buena idea verificar si el usuario está inmerso y comprometido en jugar el juego, revisando el tiempo que ha pasado jugándolo en los últimos días. Si el jugador no ha jugado mucho al juego, podría significar que está perdiendo interés y puede dejar de jugar pronto.

Las características útiles varían en diferentes dominios, por lo que es importante tratar de encontrar cualquier información relacionada con la tarea en cuestión. Por ejemplo, podría encontrar y leer artículos de investigación, estudios de casos y artículos, o buscar el consejo de empresas o profesionales que hayan trabajado en el campo y, por lo tanto, sean experimentados y bien versados en las características más comunes, sus relaciones entre sí, cualquier posible problema y qué nuevas características son las más útiles. Estos enfoques ayudan a reducir la prueba y error, y aceleran el proceso de ingeniería de características.

Dado los recientes avances en Modelos de Lenguaje Grandes (LLMs) (por ejemplo, es posible que haya oído hablar de ChatGPT …), y dado que el proceso de ingeniería de características puede ser un poco intimidante para usuarios inexpertos, me ha intrigado ver si los LLMs podrían ser útiles para proporcionar ideas sobre qué características se podrían crear. Y eso es exactamente lo que hice, con la siguiente salida:

La respuesta de ChatGPT es en realidad bastante buena, y también señala una serie de características basadas en el tiempo como se discutió anteriormente. Por supuesto, tenga en cuenta que es posible que no podamos implementar todas las características sugeridas si la información requerida no está disponible. Además, es bien sabido que es propenso a la alucinación, y como tal, es posible que no proporcione respuestas totalmente precisas.

Podríamos obtener respuestas más relevantes de ChatGPT, por ejemplo, especificando las características que estamos utilizando o empleando indicaciones, pero esto está más allá del alcance de este artículo y se deja como un ejercicio para el lector. Sin embargo, los LLMs podrían considerarse como un primer paso para empezar, aunque sigue siendo muy recomendable buscar información más confiable en artículos, profesionales, y así sucesivamente.

En la plataforma Actable AI, se pueden crear nuevas características utilizando el lenguaje de programación SQL bastante conocido. Para aquellos menos familiarizados con SQL, enfoques como utilizar ChatGPT para generar consultas automáticamente pueden resultar útiles. Sin embargo, en mi experimentación limitada, la confiabilidad de este método puede ser algo inconsistente.

Para garantizar el cálculo preciso de la salida prevista, es recomendable examinar manualmente un subconjunto de los resultados para verificar que se está calculando correctamente la salida deseada. Esto se puede hacer fácilmente mediante la comprobación de la tabla que se muestra después de que se ejecute la consulta en SQL Lab, la interfaz de Actable AI para escribir y ejecutar código SQL.

Aquí está el código SQL que utilicé para generar las nuevas columnas, lo que debería ayudar a darle un buen comienzo si desea crear otras características:

SELECT     *,    SUM("PlayTime") OVER UserLevelWindow AS "time_spent_on_level",    (a."Max_Level" - a."Min_Level") AS "levels_completed_in_last_7_days",    COALESCE(CAST("total_wins_in_last_14_days" AS DECIMAL)/NULLIF("total_losses_in_last_14_days", 0), 0.0) AS "win_to_lose_ratio_in_last_14_days",    COALESCE(SUM("UsedCoins") OVER User1DayWindow, 0) AS "UsedCoins_in_last_1_days",    COALESCE(SUM("UsedCoins") OVER User7DayWindow, 0) AS "UsedCoins_in_last_7_days",    COALESCE(SUM("UsedCoins") OVER User14DayWindow, 0) AS "UsedCoins_in_last_14_days",    COALESCE(SUM("ExtraMoves") OVER User1DayWindow, 0) AS "ExtraMoves_in_last_1_days",    COALESCE(SUM("ExtraMoves") OVER User7DayWindow, 0) AS "ExtraMoves_in_last_7_days",    COALESCE(SUM("ExtraMoves") OVER User14DayWindow, 0) AS "ExtraMoves_in_last_14_days",    AVG("RollingLosses") OVER User7DayWindow AS "RollingLosses_mean_last_7_days",    AVG("MaxLevel") OVER PastWindow AS "MaxLevel_mean"FROM (    SELECT        *,        MAX("Level") OVER User7DayWindow AS "Max_Level",        MIN("Level") OVER User7DayWindow AS "Min_Level",        SUM(CASE WHEN "EndType" = 'Lose' THEN 1 ELSE 0 END) OVER User14DayWindow AS "total_losses_in_last_14_days",        SUM(CASE WHEN "EndType" = 'Win' THEN 1 ELSE 0 END) OVER User14DayWindow AS "total_wins_in_last_14_days",        SUM("PlayTime") OVER User7DayWindow AS "PlayTime_cumul_7_days",        SUM("RollingLosses") OVER User7DayWindow AS "RollingLosses_cumul_7_days",        SUM("PlayTime") OVER UserPastWindow AS "PlayTime_cumul"    FROM "game_data_levels"    WINDOW        User7DayWindow AS (            PARTITION BY "UserID"            ORDER BY "ServerTime"            RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW        ),        User14DayWindow AS (            PARTITION BY "UserID"            ORDER BY "ServerTime"            RANGE BETWEEN INTERVAL '14' DAY PRECEDING AND CURRENT ROW        ),        UserPastWindow AS (        PARTITION BY "UserID"        ORDER BY "ServerTime"        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW        )) AS aWINDOW    UserLevelWindow AS (        PARTITION BY "UserID", "Level"        ORDER BY "ServerTime"        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW    ),    PastWindow AS (        ORDER BY "ServerTime"        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW    ),    User1DayWindow AS (        PARTITION BY "UserID"         ORDER BY "ServerTime"         RANGE BETWEEN INTERVAL '1' DAY PRECEDING AND CURRENT ROW    ),    User7DayWindow AS (        PARTITION BY "UserID"        ORDER BY "ServerTime"        RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW    ),    User14DayWindow AS (        PARTITION BY "UserID"        ORDER BY "ServerTime"        RANGE BETWEEN INTERVAL '14' DAY PRECEDING AND CURRENT ROW    )ORDER BY "ServerTime";

En este código se crean ‘ventanas’ para definir el rango de tiempo a considerar, como el último día, la última semana o las últimas dos semanas. Los registros que caen dentro de ese rango se utilizarán durante los cálculos de características, que están destinados principalmente a proporcionar algún contexto histórico sobre el viaje del jugador en el juego. La lista completa de características es la siguiente:

• time_spend_on_level: tiempo que el usuario ha pasado jugando el nivel. Da una indicación de la dificultad del nivel.
• levels_completed_in_last_7_days: el número de niveles completados por el usuario en los últimos 7 días (1 semana). Da una indicación de la dificultad del nivel, perseverancia e inmersión en el juego.
• total_wins_in_last_14_days: el número total de veces que un usuario ha ganado un nivel
• total_losses_in_last_14_days: el número total de veces que un usuario ha perdido un nivel
• win_to_lose_ratio_in_last_14_days: relación entre el número de victorias y el número de derrotas (total_wins_in_last_14_days/total_losses_in_last_14_days)
• UsedCoins_in_last_1_days: el número de monedas utilizadas en el día anterior. Da una indicación de la dificultad del nivel y la voluntad de un jugador de gastar moneda del juego.
• UsedCoins_in_last_7_days: el número de monedas utilizadas en los últimos 7 días (1 semana)
• UsedCoins_in_last_14_days: el número de monedas utilizadas en los últimos 14 días (2 semanas)
• ExtraMoves_in_last_1_days: el número de movimientos extra utilizados por un usuario en el día anterior. Da una indicación de la dificultad del nivel.
• ExtraMoves_in_last_7_days: el número de movimientos extra utilizados por un usuario en los últimos 7 días (1 semana)
• ExtraMoves_in_last_14_days: el número de movimientos extra utilizados por un usuario en los últimos 14 días (2 semanas)
• RollingLosses_mean_last_7_days: el número promedio de pérdidas acumulativas por un usuario en los últimos 7 días (1 semana). Da una indicación de la dificultad del nivel.
• MaxLevel_mean: el promedio del nivel máximo alcanzado por todos los usuarios.
• Max_Level: el nivel máximo alcanzado por un jugador en los últimos 7 días (1 semana). En conjunto con MaxLevel_mean, da una indicación del progreso de un jugador con respecto a los demás jugadores.
• Min_Level: el nivel mínimo jugado por un usuario en los últimos 7 días (1 semana)
• PlayTime_cumul_7_days: el tiempo total jugado por un usuario en los últimos 7 días (1 semana). Da una indicación de la inmersión del jugador en el juego.
• PlayTime_cumul: el tiempo total jugado por un usuario (desde el primer registro disponible)
• RollingLosses_cumul_7_days: el número total de pérdidas acumulativas en los últimos 7 días (1 semana). Da una indicación del nivel de dificultad.

Es importante que solo se utilicen los registros pasados cuando se calcula el valor de una nueva característica en una fila particular. En otras palabras, se debe evitar el uso de observaciones futuras, ya que el modelo obviamente no tendrá acceso a ningún valor futuro cuando se implemente en producción.

Una vez satisfechos con las características creadas, podemos guardar la tabla como un nuevo conjunto de datos y ejecutar un nuevo modelo que debería (con suerte) obtener un mejor rendimiento.

Entrenamiento de un nuevo modelo de clasificación (con suerte mejorado)

Es hora de ver si las nuevas columnas son útiles. Podemos repetir los mismos pasos que antes, con la única diferencia de que ahora usamos el nuevo conjunto de datos que contiene las características adicionales. Se usan las mismas configuraciones para permitir una comparación justa con el modelo original, con los siguientes resultados (que también se pueden ver aquí):

El valor del ROC AUC de 0.918 ha mejorado mucho en comparación con el valor original de 0.675. ¡Es incluso mejor que el modelo optimizado para la calidad (0.709)! Esto demuestra la importancia de comprender tus datos y crear nuevas características que puedan proporcionar información más rica.

Ahora sería interesante ver cuáles de nuestras nuevas características fueron realmente las más útiles; nuevamente, podríamos revisar la tabla de importancia de características:

Parece que el número total de derrotas en las últimas dos semanas es bastante importante, lo cual tiene sentido porque cuanto más a menudo un jugador pierde un juego, es potencialmente más probable que se frustre y deje de jugar.

El nivel máximo promedio de todos los usuarios también parece ser importante, lo que nuevamente tiene sentido porque se puede utilizar para determinar qué tan lejos está un jugador de la mayoría de otros jugadores; mucho más alto que el promedio indica que un jugador está bien inmerso en el juego, mientras que los valores que están mucho más bajos que el promedio podrían indicar que el jugador aún no está bien motivado.

Estas son solo algunas características simples que podríamos haber creado. Hay otras características que podemos crear, que podrían mejorar aún más el rendimiento. Dejaré eso como un ejercicio para que el lector vea qué otras características podrían crearse.

Entrenar un modelo optimizado para la calidad con el mismo límite de tiempo que antes no mejoró el rendimiento. Sin embargo, esto es comprensible porque se está utilizando un mayor número de características, por lo que se puede necesitar más tiempo para la optimización. Como se puede observar aquí, aumentar el límite de tiempo a 6 horas mejora el rendimiento a 0.923 (en términos del AUC):

También debe tenerse en cuenta que algunas métricas, como la precisión y la recuperación, siguen siendo bastante pobres. Sin embargo, esto se debe a que se asume un umbral de clasificación del 0.5, que puede no ser óptimo. De hecho, esto es también por qué nos enfocamos en el AUC, que puede dar una imagen más completa del rendimiento si ajustamos el umbral.

El rendimiento en términos del AUC de los modelos entrenados se puede resumir de la siguiente manera:

┌─────────────────────────────────────────────────────────┬───────────┐│                         Modelo                          │ AUC (ROC) │├─────────────────────────────────────────────────────────┼───────────┤│ Características originales                              │     0.675 ││ Características originales + optim. para calidad         │     0.709 ││ Características generadas                                │     0.918 ││ Características generadas + optim. para calidad + más tiempo │     0.923 │└─────────────────────────────────────────────────────────┴───────────┘

Implementación del modelo en producción

No sirve de nada tener un buen modelo si no podemos usarlo en nuevos datos. Las plataformas de aprendizaje automático pueden ofrecer esta capacidad para generar predicciones sobre datos futuros no vistos dados un modelo entrenado. Por ejemplo, la plataforma Actable AI permite el uso de una API que permite que el modelo sea utilizado en datos fuera de la plataforma, al igual que la exportación del modelo o la inserción de valores en bruto para obtener una predicción instantánea.

Sin embargo, es crucial probar periódicamente el modelo en datos futuros, para determinar si sigue funcionando según lo esperado. De hecho, puede ser necesario volver a entrenar los modelos con los datos más nuevos. Esto se debe a que las características (por ejemplo, las distribuciones de características) pueden cambiar con el tiempo, lo que afecta la precisión del modelo.

Por ejemplo, una empresa puede introducir una nueva política que afecte los comportamientos de los clientes (ya sea positiva o negativamente), pero el modelo puede ser incapaz de tener en cuenta la nueva política si no tiene acceso a características que reflejen el cambio. Si hay cambios drásticos pero no hay características que puedan informar al modelo, podría valer la pena considerar el uso de dos modelos: uno entrenado y utilizado en los datos antiguos, y otro entrenado y utilizado con los datos más nuevos. Esto aseguraría que los modelos estén especializados en operar en datos con diferentes características que pueden ser difíciles de capturar con un solo modelo.

Conclusiones

En este artículo se utilizó un conjunto de datos del mundo real que contiene información sobre cada nivel jugado por un usuario en una aplicación móvil para entrenar un modelo de clasificación que puede predecir si un jugador dejará de jugar el juego en dos semanas.

Se consideró todo el proceso de procesamiento, desde EDA hasta el entrenamiento del modelo y la ingeniería de características. Se proporcionaron discusiones sobre la interpretación de los resultados y cómo podríamos mejorarlos, pasando de un valor de 0,675 a un valor de 0,923 (donde 1,0 es el valor máximo).

Las nuevas características que se crearon son relativamente simples y ciertamente existen muchas más características que podrían considerarse. Además, también podrían considerarse técnicas como la normalización y estandarización de características. Algunos recursos útiles se pueden encontrar aquí y aquí.

Con respecto a la plataforma Actable AI, puedo ser un poco parcial, pero creo que ayuda a simplificar algunos de los procesos más tediosos que deben realizar los científicos de datos y los expertos en aprendizaje automático, con los siguientes aspectos deseables:

• La biblioteca Core ML es de código abierto, por lo que puede verificarse que es segura de usar por cualquier persona que tenga buenos conocimientos de programación. También puede ser utilizada por cualquier persona que conozca Python
• Para aquellos que no conocen Python o no están familiarizados con la programación, la interfaz gráfica ofrece una forma de usar una serie de análisis y visualizaciones con poco esfuerzo
• No es demasiado difícil comenzar a usar la plataforma (no abruma al usuario con demasiada información técnica que puede disuadir a las personas menos conocedoras de usarla)
• El nivel gratuito permite ejecutar análisis en conjuntos de datos que están disponibles públicamente
• Se dispone de una gran cantidad de herramientas (aparte de la clasificación considerada en este artículo)

Dicho esto, hay algunas desventajas mientras que varios aspectos podrían mejorarse, como:

• El nivel gratuito no permite ejecutar modelos de aprendizaje automático en datos privados
• La interfaz de usuario parece un poco anticuada
• Algunas visualizaciones pueden ser poco claras y a veces difíciles de interpretar
• La aplicación puede ser lenta para responder en ocasiones
• No se puede utilizar un umbral distinto de 0,5 al calcular y mostrar los resultados principales
• No hay soporte para datos desequilibrados
• Sigue siendo necesaria cierta comprensión de la ciencia de datos y el aprendizaje automático para extraer el máximo provecho de la plataforma (aunque esto probablemente sea cierto para otras plataformas también)

En otros artículos futuros, consideraré el uso de otras plataformas para determinar sus fortalezas y debilidades, y por lo tanto cuáles son los casos de uso que mejor se adaptan a cada plataforma.

¡Hasta entonces, espero que este artículo haya sido una lectura interesante! ¡No dude en dejar cualquier comentario o pregunta que pueda tener!

¿Tiene alguna idea sobre este artículo? ¡No dude en publicar una nota, comentario o enviarme un mensaje directamente en LinkedIn!

Además, asegúrese de seguirme para asegurarse de recibir notificaciones sobre la publicación de futuros artículos.

El autor era un científico de datos de Actable AI en el momento de escribir este artículo.

---

• Churn
• data science
• Hands On Tutorials
• Machine Learning
• SQL