Flujo de procesamiento y ciclo de vida

En esta lección conocemos las metodologías estándar para construir proyectos de Minería de Datos.

Los procesos de Minería de Datos nunca son lineales: los hallazgos en la fase de modelado o de evaluación suelen obligar a redefinir el problema y quizá volver al preprocesado de datos.

Aún así existen metodologías estándar que explican el ciclo de vida de los datos como el Proceso Estándar Intersectorial para la Minería de Datos (CRISP-DM, Cross-Industry Standard Process for Data Mining) o el Proceso de Ciencia de Datos en Equipo (TDSP, Team Data Science Process).

Flujos de procesamiento

Las canalizaciones (pipelines) o flujos de procesamiento de datos lo que tratan es de conectar todos los pasos, para que no trabajemos con un puñado de scripts dispersos, sino que conectemos de forma automática la adquisición de datos, con la limpieza, el preprocesado, la transformación, etc. En bibliotecas como Scikit-learn existe incluso la clase Pipeline para implementar esto.

El trabajar con estos automatismos también nos evita errores como el mencionado data leakage, es decir, usar por error datos que no pertenecen a la partición de entrenamiento sino a la de validación o incluso a la de prueba final, lo que invalidaría todo nuestro trabajo.

Monitorización, degradación y mantenimiento

Especialmente cuando hacemos Aprendizaje Automático en entornos como los videojuegos, el comportamiento de los usuarios cambia con frecuencia (según salen nuevos parches o DLCs, si hay eventos en el juego o cambia el «metajuego»…). Esto inevitablemente va a hacer que nuestros modelos se degraden con el tiempo.

Hay que controlar si lo que ocurre es que cambia la relación entre las variables y el objetivo que buscamos (concept drift) o si únicamente nos están cambiando las distribuciones de entrada (data drift), para actuar según el caso.

Lo que suele hacerse es tener estrategias de «reentrenamiento continuo» para auditar el rendimiento del modelo en producción y automatizar su reentrenamiento periódico usando telemetría actualizada.

Ciencia de datos y videojuegos

Para empezar a hacer Ciencia de Datos (Data Science) en videojuegos hay que conocer el tipo de datos que se manejan habitualmente en estas tareas analíticas, tanto los de telemetría como los de las métricas llamadas KPIs (los famosos DAU, MAU, Retención, ARPU, ARPPU…). Ya no se trata sólo de recoger esa información, sino de saber analizarla y visualizarla.

Todo esto nos lleva hacia el futuro del desarrollo de videojuegos, que algunos dicen que será el Data-Driven Game Development (ej. evaluar el impacto de cambios profundos de diseño, siempre usando datos). King con su Candy Crush Saga es seguramente el ejemplo paradigmático, aunque Riot Games también lo hace con League of Legends y Ubisoft, Valve y Supercell son otros ejemplos de estudios que funcionan así.

Otras cuestiones interesantes son las relativas a DevOps (o MLOps cuando las llaman si estamos trabajando con Aprendizaje Automático). Al desplegar sistemas de Minería de Datos y Aprendizaje Automático en producción, hay que integrar los modelos con los motores del videojuego o con los servidores del backend (via APIs REST, ONNX de Nvidia o de otras maneras). No es lo mismo tener que hacer inferencia en tiempo real (interfiriendo con el framerate) a poder hacer inferencia por lotes en el servidor (en diferido, cada vez que se cierra sesión ).

Unity ML-Agents aparta un ejemplo de cómo integrar las herramientas de Aprendizaje Automático, típicas de entornos Python, en motores como Unity. En Microsoft tienen Azure ML, y Epic Games seguramente trabaje con soluciones parecidas (Unreal Engine tiene Unreal Insights y se integra con muchas plataformas, además de que es evidente que juegos como Fortnite generan una enorme cantidad de telemetría en tiempo real).

Más información

Para complementar es recomendable consultar otros documentos.

• …