Fundamentos y ciclo de vida

En esta lección conocemos las metodologías estándar para construir proyectos de Minería de Datos, lo que podría constituir por sí misma una asignatura entera, dado a su relevancia en el mundo del Análisis 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 preprocesamiento de datos; es decir, suelen ser cíclicos o iterativos. Por eso es muy importante al principio explicar grosso modo el ciclo de una aplicación de Minería de Datos para aprender lo básico sobre trabajar con datos.

Existen metodologías estándar que explican este ciclo de vida de los datos como el clásico Proceso Estándar Interindustrial para la Minería de Datos (Cross-Industry Standard Process for Data Mining ó CRISP-DM) o el más moderno y enfocado al AA: Proceso de Ciencia de Datos en Equipo (Team Data Science Process ó TDSP).

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.

Para trabajar en esto a nivel profesional, como suele decirse, «el demonio está en los detalles»: lo difícil es hacer bien la recolección de datos, toda su preparación, el entrenamiento, la evaluación, el despliegue… e incluso como veremos después, la monitorización para ver cuando se vuelve obsoleto un modelo. Con mucho trabajo a día de hoy tenemos modelos que pueden correr en un teléfono móvil como algunas variantes de Gemma, Llama o Qwen.

Todo esto nos lleva hacia el futuro del desarrollo de videojuegos, que algunos dicen que será dirigido por datos (Data-Driven Game Development), es decir, hasta los cambios profundos de diseño verán evaluado su impacto 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 con la misma filosofía.

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 (es decir, usando el formato ONNX de Nvidia, via APIs REST o de alguna otra manera). No es lo mismo tener que hacer inferencia en tiempo real (interfiriendo con el framerate) a poder hacer inferencia por lotes en el servidor (incluso en diferido, cada vez que se cierra sesión).

Finalmente Unity ML-Agents se puede mencionar como 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 evidentemente juegos como Fortnite generan una enorme cantidad de telemetría en tiempo real).

Mantenimiento

Cuando hacemos Minería de Datos o 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 significativos que alteren el juego o si cambia el «metajuego»…). Esto inevitablemente va a hacer que nuestros modelos se degraden con el tiempo (model decay), lo que implica que es necesario monitorizarlos y hacer cierto «mantenimiento» al sistema.

Hay que controlar si lo que ocurre es que cambia la relación entre las variables de entrada y el objetivo o salida que buscamos (concept drift), si únicamente nos están cambiando las distribuciones de entrada (data drift), o si cambia el objetivo o etiqueta de salida (label drift) -aunque no cambie su relación con la entrada, y en este caso, hablando siempre de Aprendizaje Supervisado-. Técnicamente hay tres tipos de «deriva» o drift: de concepto, de datos o de etiqueta, y habrá que 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, tomada recientemente del juego.

Canalizaciones

Las canalizaciones (pipelines) o flujos 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.

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.

En bibliotecas como Scikit-learn existe incluso la clase Pipeline para implementar esto.

Más información

Para complementar es recomendable consultar otros documentos.

• …