Los modelos predictivos son aquellos que analizan el histórico de datos disponibles e identifican patrones, realizando pronósticos y predicciones que ayuden a tomar mejores decisiones. Pueden utilizarse por ejemplo para predecir la demanda, identificar actividades fraudulentas, detectar averías de equipos antes de que ocurran, o adelantarte a posibles riesgos. Capacidades que aportan un gran valor de negocio a las compañías en el contexto de incertidumbre y competitividad actual.
Para poder encontrar patrones significativos y aportar un valor diferencial, estos modelos necesitan analizar un gran volumen de datos históricos. Normalmente esos datos provienen de diferentes fuentes, están en diferentes formatos y tienen diferentes pesos, por eso es importante en primer lugar contar con una buena infraestructura y proceso de ingesta de datos (importación de archivos de datos de múltiples fuentes a un único sistema de almacenamiento).
Los modelos predictivos deben ser entrenados con datos previamente para poder realizar las predicciones. Para ello se necesita un entorno de entrenamiento y registro de modelos ágil y capaz de reentrenar los modelos con frecuencia de una manera rápida. Una vez que tenemos los modelos debemos evaluar su calidad antes de subirlos a producción.
Después de subirlos a producción los modelos se ejecutan y guardan las predicciones obtenidas. Estas predicciones se pueden explotar en herramientas de Business Intelligence en las que el cliente puede visualizar la información de manera sencilla a través de dashboards.
Teniendo en cuenta que en este tipo de proyectos (creación, entrenamiento e implementación de modelos predictivos) suelen trabajar varios perfiles por la parte del cliente, equipos de operaciones IT y de desarrollo, contar con una arquitectura cloud puede resultar muy beneficioso. Utilizar herramientas en la nube o máquinas virtuales mejora la agilidad de trabajo independientemente de la metodología de proyecto de desarrollo software que se utilice (Agile, Scrum, DevOps…), y además ofrece opciones de integración con otros servicios.
A continuación, se explica una posible arquitectura de explotación de modelos de previsión en la nube. Se parte de un diagrama de arquitectura lógica y se aportan algunas opciones técnicas para su implementación.
Ejemplo de arquitectura de explotación de modelos de previsión en la nube
Veamos una arquitectura de explotación de modelos de previsión en un entorno cloud más a fondo:
Como podemos ver en la imagen, en una primera fase de ‘Ingesta y preparación de datos’ se extraerían los datos de las fuentes de datos de origen y se copiarían en el Data Lake. Como ya se ha comentado previamente, las fuentes de datos pueden ser diversas: bases de datos SQL, no SQL, ficheros, en on-premises, en cloud, etc.
Las soluciones para hacer más fácil la ingesta de datos pasan por herramientas ETL/ELT de diversa índole, tipo Azure DataFactory/Databricks, Apache Airflow, AWS Glue, Oracle Data Integrator y otras muchas. Es importante destacar que en estos procesos de ingesta y tratamiento de datos, como se suele decir, el demonio está en los detalles. Normalmente suelen ser detalles relativos a el o los modelos de datos subyacentes a las fuentes de datos origen.
En la siguiente etapa de ‘Entrenamiento de modelos’ se extraerían los datos del Data Lake y se realizaría el preprocesado necesario de éstos para el correcto entrenamiento y explotación del modelo. Una vez preprocesados los datos se almacenarían y agruparían en conjuntos de datos a la espera de ser utilizados para el entrenamiento de los modelos. Esto es importante, sobre todo si se van a definir distintos modelos en función del particionamiento y naturaleza de los datos de entrada. Por ejemplo, si vamos a realizar la previsión de ventas de las distintas tiendas de una marca, es posible que queramos definir distintos modelos en función de la localización geográfica de las mismas u otros factores.
Cuando se vaya a realizar el entrenamiento de estos modelos para todos los conjuntos de datos es muy recomendable disponer de la tecnología suficiente para que se puedan entrenar en paralelo. Además, para su posterior evaluación, también se precisa registrar/persistir dichos modelos entrenados junto con las métricas de prueba. Para la implementación de este tipo de soluciones se dispone de herramientas como Azure Machine Learning, AWS SageMaker, Google Colab y otras.
En una tercera fase de ‘Evaluación y subida a producción’ se evaluarían los modelos entrenados antes de pasarlos a producción. Se aplicaría la lógica necesaria para determinar si un modelo cumple los criterios de despliegue, comprobando que la bondad de ajuste del modelo está alineada con las expectativas del negocio. Después se registrarían los modelos que cumplen los requisitos establecidos y se realizaría la subida al entorno de producción.
Para medir dicha bondad hay que evaluar la precisión de los modelos, determinando uno o varios umbrales a partir de los cuales realizar la criba, por decirlo de alguna manera. Aquellos modelos que pasen este filtro serán los que se ejecutarán en producción. Por tanto es preciso guardarlos de forma segura, antes de dicha ejecución. Esto se puede realizar en el propio espacio de trabajo de la herramienta elegida o también, en un registro de contenedores en el que guardemos las imágenes de los ejecutables que nos interesen para el entorno de producción. Esta última opción es particularmente interesante cuando estamos utilizando modelos que pueden ser ejecutados tanto en modo batch (de forma desatendida), como en modo online. Es decir, modelos cuya ejecución debe ser rápida y que por tanto se pueden desplegar como microservicios en un cluster de Kubernetes o similar. Un ejemplo de este último tipo de modelos podrían ser recomendadores de compra online, pues se pueden ejecutar de forma desatendida varias veces al día, o bajo demanda a criterio de los usuarios.
La implementación de este proceso de evaluación y filtrado de modelos se puede realizar mediante herramientas tipo Azure DevOps&Azure Machine Learning, AWS StepFunctions&SageMaker y otros. Como registro de contenedores los hay en todas las distribuciones de Cloud, a saber: ACR (Azure) , ECR (AWS), Container Registry (GCP), etc. También se pueden instalar en on-premises, si así se precisa.
Una vez los modelos están en el entorno de producción se entraría en la última etapa de ‘Ejecución del modelo’. En esta fase, ya sea de manera programada o a petición del cliente, el modelo se ejecutaría empleando los últimos datos disponibles. Después las salidas del modelo (las predicciones) serían almacenadas en el Data Lake. Posteriormente estas predicciones, como comentábamos más arriba, podrían volcarse y ser explotadas por herramientas de Business Intelligence, en las que el cliente visualizaría la información a través de dashboards.
Para la ejecución programada de los modelos que promocionaron a producción, evidentemente existen una gran variedad de herramientas dentro del Cloud, tales como el propio Azure Machine Learning, Amazon CloudWatch&SageMaker Inference, etc. Para la ejecución bajo demanda, como hemos comentado antes, sería recomendable disponer de un entorno de ejecución que lo permita: un cluster de Kubernetes sería un entorno ideal, junto con registro de contenedores del que sacar las imágenes que se van a desplegar en el clúster como microservicios. A estas alturas sobra decir que los clústeres de Kubernetes los encuentras en todas las soluciones cloud y on-premises que uno se plantee montar: AKS (Azure), EKS y Fargate (AWS), GKE y Cloud Run (GCP), etc.
Consideraciones Finales
No contar con arquitecturas software que permitan la agilidad a la hora de gestionar y cargar los datos, hará que los modelos tarden más tiempo del necesario e incluso no funcionen de la manera que deberían.
A continuación algunas consideraciones finales (sin entrar a valorar herramientas) para completar la visión de este tipo de procesos:
- Siempre que se ejecutan modelos de Machine Learning (ML), ya sea en modo desatendido o en modo online, es preciso monitorizar dicha ejecución. Tanto a nivel de rendimiento, como a nivel de precisión de los mismos. De tal manera que en el momento que se detecte (en producción) que un modelo de ML ha bajado su precisión, se notifique la correspondiente alerta o incluso se lance de forma automatizada un proceso de reentrenamiento del modelo en cuestión.
- Para facilitar la ingesta y organización de los datos que se usan durante los procesos de entrenamiento, es mejor disponer de un datalake que te permita organizar los datos en diferentes capas (datos en crudo, datos limpios, datos transformados, etc), de tal manera que luego sea fácil y directo disponer de aquellos datos (y su formato) que más interesen en cada caso.
- Si se exponen modelos de ML como microservicios, de tal modo que sea posible ejecutarlos bajo demanda, como ya se ha comentado, una buena solución es desplegar las imágenes contenerizadas sobre un clúster de Kubernetes. Pero además sería adecuado exponer dichas invocaciones al modelo mediante un API REST convenientemente securizado y auditado, de tal modo que se puedan realizar las invocaciones correspondientes desde cualquier aplicación que lo necesite. Para llevar a cabo esta exposición controlada y securizada de las APIs de invocación on-line a los modelos, se recomienda hacer uso de algún tipo de Sistema de Gestión de APIs.
Una puntualización final relativa al ciclo de desarrollo. En los pipelines de entrenamiento e inferencia, es importante diseñar un buen flujo que, de algún modo, aísle los algoritmos de ML con respecto a los procesos técnicos que se ejecutan antes y después de éstos. En muchas ocasiones, no siempre, estos desarrollos se llevan a cabo en equipos distintos, con diferentes perfiles tecnológicos. Por tanto, parece muy aconsejable tener bien definidos los roles de cada perfil cuando interactúen entre ellos.
En decide4AI como expertos en el desarrollo e implementación de modelos predictivos y arquitecturas software flexibles en la nube, podemos asesorarte sobre: qué piezas o tipos de arquitecturas son más beneficiosas para tu compañía, qué técnicas o modelos serán más adecuados para la problemática específica, qué otras tecnologías podrían ayudarte a mejorar tus resultados, etc.
¿Te interesa saber más sobre arquitecturas software?
Si quieres saber más sobre decide4AI, y mantenerte al tanto de futuros webinar o acciones, síguenos en las redes sociales (Linkedin, Twitter, Youtube).
