Arquitectura del ciclo de vida de un modelo de Machine Learning en AWS: una demo completa

Por Ali Arsanjani, Tech Sector AI/ML Leader y Principal Architect

En este tutorial recorreremos el ciclo de vida de un proyecto de Machine Learning (ML) y mostraremos cómo construir un caso de uso de punta a punta utilizando Amazon SageMaker. SageMaker ofrece un conjunto amplio de capacidades para permitir a científicos de datos e ingenieros construir, entrenar y desplegar modelos de la forma más sencilla posible. Para este artículo, elegimos un caso de detección de fraude en reclamos de seguros automovilísticos.

Primero, mostraremos una revisión de la arquitectura de las distintas partes del ciclo de ML y luego describiremos brevemente el código que construye cada una de las secciones.

Para comenzar, los científicos de datos utilizan un proceso experimental para explorar varias tareas de preparación de datos, en algunos casos también ingeniería de features y eventualmente desarrollan una forma estandarizada de implementar este proceso. Luego, comienza un proceso más repetitivo y escalable de automatizar cada una de estas etapas hasta que el modelo demuestra tener el nivel necesario de performance, en términos por ejemplo de accuracy, f1 score o precisión. Luego productizan este proceso en un pipeline de ML repetible, automatizado y escalable.

El siguiente diagrama ilustra la investigación y la operativización de workflows:

Nuevas tareas requieren nuevas capacidades en ciclo de vida de ML

El ciclo de vida de un proyecto de ML se puede ilustrar de la siguiente forma:

Las tres fases generales son la preparación de datos, entrenamiento y tunning, deploy y monitoreo. En el proceso de inferencia es cuando realmente servimos el modelo para realizar predicciones o transformaciones.

A medida que el ML evoluciona y madura en la industria, vemos una creciente necesidad de que permitan escalar el proceso, estandarizar los artefactos del modelo y hacerlos más accesibles y transparentes y por lo tanto gobernables.

En esta vista detallada del ciclo de vida de ML, las cajas rojas representan conceptos comparativamente más nuevos y tareas que recién ahora se considera importante incluir en un ambiente escalable operativo y orientado a producción.

Entre estas nuevas tareas y sus correspondientes features en Amazon SageMaker se incluyen las siguientes:

Data wrangling – Utilizamos SageMaker Data Wrangler para limpieza, normalización, transformación y encoding de datos. Y también para realizar uniones (joins) de conjuntos de datos. El output de SageMaker Data Wrangler es un código para la transformación de datos que funciona con SageMaker Processing, SageMaker Pipelines, SageMaker Feature Store, o con Pandas en un script de Python tradicional. Con SageMaker Data Wrangler el feature engineering es más rápido y fácil, con una interfaz amigable y la posibilidad de integrar el resultado con las siguientes fases del ciclo de vida de ML.
Detección de sesgo – Con SageMaker Clarify, podemos detectar sesgo, ya sea en la etapa anterior al entrenamiento (data bias) como en la etapa posterior (model bias). En la etapa de inferencia, SageMaker Clarify tiene la capacidad de proveer interpretación y explicación de las predicciones ofreciendo insights sobre cuáles de los factores fueron los más influyentes en cada caso a la hora de arribar a la predicción.
Feature Store (offline) – Luego de terminar el proceso de feature engineering, encoding y transformaciones podemos estandarizar los features que no se consuman en tiempo real en la SageMaker Feature Store offline para ser usados como inputs para el entrenamiento de modelos.

SageMaker Feature Store permite crear grupos de features que almacenan todos los datos históricos y pueden ser utilizados para entrenamiento de modelos.

Noten que los features pueden venir de un pipeline de procesamiento hacia la online feature store y luego serán replicados en la offline feature store. Ésta puede ser utilizada también para correr procesos de inferencia batch. Por lo tanto, la online feature store también puede ser utilizada como input para el entrenamiento.

Artifact lineage: Podemos utilizar SageMaker ML Lineage Tracking para asociar todos los artefactos (como datos, modelos y parámetros) con un modelo entrenado para producir metadatos que se almacenan en un model registry. Además, llevar un registro de las acciones realizadas por las personas en los casos de aprobación manual de modelos o deployments facilitando así la governanza de modelos.
Model Registry: El registro de modelos de SageMaker almacena metadatos acerca de todos los artefactos incluidos en el proceso de creación de modelos junto con los pesos de los mismos en un registro de modelos. Luego, podemos utilizar aprobación humana para determinar que el modelo está listo para producción. Esto alimenta la siguiente fase de deploy y monitoreo.
Inferencia y Feature Store (online): SageMaker Feature Store provee baja latencia (hasta menos de 10 milisegundos) y alto throughput de lectura para servir el modelo sobre nuevos datos que van llegando.
Pipelines: Luego de experimentar y decidir entre las varias opciones en este ciclo de vida (como qué transformaciones aplicar a nuestros features, determinar si existe sesgo o desbalanceo, qué algoritmos elegir para entrenar o qué conjunto de hiper parámetros provee la mejor performance), podemos automatizar muchas de las tareas a lo largo del ciclo de ML utilizando SageMaker Pipelines.

Esto nos permite ordenar un proceso que de otra forma sería manual y complejo. Para construir un pipeline, vamos a preparar un conjunto de datos (clientes y reclamos) ingestando los mismos en SageMaker Data Wrangler y a aplicar varias transformaciones dentro de SageMaker Studio. SageMaker Data Wrangler genera archivos con la extensión .flow. Utilizaremos estas definiciones de transformaciones como punto de partida para un pipeline automatizado que incluya todo en el camino hasta el deploy de un endpoint de inferencia. Noten que otros casos de uso podrían requerir múltiples pipelines como los siguientes:

Un pipeline para todos los pasos de preprocesamiento de datos
Un pipeline para training, tuning, linage y depositar el modelo en el registro (este es el que mostramos en el código asociado a este artículo)
Posiblemente otro pipeline para escenarios específicos de inferencia como real time vs batch.
Un pipeline para desencadenar el re-entrenamiento utilizando SageMaker Model Monitor para detectar drift en el modelo o en los datos y disparar el re-entrenamiento utilizando por ejemplo AWS Lambda

Caso de uso: detección de fraude para reclamos de seguros de automóviles

En este artículo, utilizamos un caso de uso para demostrar cómo se puede utilizar Amazon SageMaker para predecir cuáles reclamos de seguros son de origen fraudulento.

Describimos los detalles de implementación en estas seis notebooks, donde mostramos cómo mejorar la efectividad del trabajo del científico de datos y el ingeniero de ML utilizando los nuevos servicios y features de Amazon SageMaker (en rojo en el gráfico anterior) para resolver cada uno de los problemas de cada etapa del ciclo de vida de ML.

Resumen de la solución técnica

Veamos los pasos uno por uno. Cada sección viene acompañada de una notebook en Github que pueden seguir para acompañar la lectura y explicaciones de este artículo.

Wrangling y preprocesamiento del conjunto de datos

Utilizaremos dos conjuntos de datos sintéticos que consisten en clientes y reclamos, generados a través de simulaciones. Utilizaremos SageMaker Data Wrangler para ingestar, analizar, preparar y transformar cada conjunto. Esto se puede hacer a través de la interfaz gráfica disponible en SageMaker Studio.

En segundo lugar, utilizaremos SageMaker Data Wrangler para exportar los datos transformados como dos archivos CSV que pueden ser almacenados en Amazon Simple Storage Service (Amazon S3) y accedidos de SageMaker Processing para realizar tareas de preparación y preprocesamiento a escala.

Almacenando los features

Luego de que SageMaker Processing aplica las transformaciones definidas en SageMaker Data Wrangler almacenamos los features normalizados en una offline feature store para que los mismos puedan ser compartidos y reutilizados consistentemente a lo largo de una organización con muchos científicos de datos.

Esta estandarización es clave para crear un conjunto normalizado y reutilizable de características o features que sirvan de input a los modelos de ML.

Evaluando y mitigando el sesgo, entrenamiento y optimización

Las discusiones relacionadas al monitoreo de sesgo y la justicia en el marco de la IA (Inteligencia Artificial) están cobrando mayor importancia. El sesgo que está presente en los datos muchas veces se traslada inadvertidamente al modelo en el proceso de etiquetado y recolección de datos. SageMaker Clarify es un conjunto de herramientas totalmente manejado para identificar sesgo potencial en el conjunto de entrenamiento, explicar los resultados de la inferencia a nivel individual, presentar explicaciones a nivel agregado para todo el dataset o modelo que se puede integrar con capacidades de monitoreo para evaluar la performance en producción.

SageMaker Clarify permite evaluar varios tipos de sesgo. Por ejemplo, el sesgo de pre-entrenamiento (datos) puede enfocarse en determinar si el desbalance de la clase u otros factores se encuentran más allá de cierto umbral y pueden estar sesgando el modelo.

Cuando se detecta sesgo en el conjunto de datos de entrenamiento, lo que se puede hacer es poner en marcha una estrategia de mitigación. Luego generalmente se elige un algoritmo y se optimiza hasta obtener una métrica de performance aceptable en términos por ejemplo de F1, AUC o accuracy. En este artículo utilizaremos XGBoost para entrenar el modelo utilizando los datos del feature store y evaluaremos con la métrica f1.

También podemos verificar el sesgo post-entrenamiento del modelo y una vez satisfechos los requerimientos de balance y transparencia se puede optimizar los hiperparámetros del modelo para obtener la mejor performance posible.

Podemos rastrear el linaje de estos experimentos utilizando Lineage Tracking para dar seguimiento a varios aspectos de la evolución, incluyendo los siguientes:

Datos – ¿Qué conjunto de datos se utilizó?
Preparación – ¿Cómo limpiamos y preparamos los datos?
Entrenamiento – ¿Qué modelo se entrenó y con qué configuración?
Tuning – ¿Qué hiperparámetros se utilizaron?

Durante la experimentación, podremos haber entrenado muchos modelos, con diferentes conjuntos de datos y preparado diferentes transformaciones cada una con sus propias métricas de sesgo y performance. Si nos sentimos conformes con un resultado, podemos observar el linaje de los artefactos asociados para poder luego reproducirlos y mejorarlos.

Capturando el linaje de los artefactos durante los experimentos

Como ya mencionamos, no sólo queremos almacenar nuestros modelos entrenados en sí, si no también nuestros conjuntos de datos, mecanismos de preprocesamiento, algoritmos, hiperparámetros y configuraciones. Entonces, podemos almacenar metadatos que permitan rastrear el experimento y linaje del modelo con una referencia a los datos y a la ubicación del modelo en el SageMaker Model Registry.

Desplegando el modelo en un endpoint

Luego de decidir qué modelos deben ser aprobados para su deploy, podemos hacer el despliegue en un SageMaker hosted endpoint, donde quedarán listos para entregar predicciones.

Predecir con el modelo utilizando la online feature store

Una forma de utilizar los modelos para inferencia es invocando los endpoints de forma directa. Los endpoints de Amazon SageMaker se encuentran detrás de balanceadores de carga que permitirán recibir peticiones de forma eficiente.

Otro patrón de diseño común a la hora de realizar predicciones es lo que se denomina ML Gateway Pattern donde el endpoint de inferencia se invoca utilizando Amazon API Gateway. Este patrón tiene el beneficio adicional de integrarse con una arquitectura orientada a servicios al exponer los modelos como RESTful endpoints. El uso de una caché, el balanceo de carga y el monitoreo se pueden hacer a través de API Gateway que a su vez se integra con una función de AWS Lambda que hace el llamado al endpoint de SageMaker.

En este artículo, haremos la inferencia de manera directa en tiempo real utilizando los datos que se ingestan al online feature store. Los reclamos que ingresan se clasifican como fraude o no fraude utilizando el modelo XGBoost entrenado y optimizado.

Explicando las predicciones del modelo

Podemos inspeccionar por qué cada predicción utilizando shap values para explicar las predicciones tanto a nivel individual como a nivel agregado. Para esta tarea, utilizamos las explainability features de SageMaker Clarify.

Arquitectura de la solución

Profundicemos ahora en la arquitectura para cada uno de los cuatro workflows: data prep, entrenamiento y optimización, deploy y finalmente el pipeline que une todas de forma automatizada y almacena el modelo en el model registry.

Workflow manual

Antes de automatizar un proceso concreto de ML, generalmente realizamos una etapa de investigación. Esto generalmente sucede en las etapas de análisis exploratorio y visualización donde utilizamos SageMaker Data Wrangler para determinar qué queremos hacer con nuestros datos (visualización, inspección, limpieza, transformación, features) como preparación para el entrenamiento. El siguiente diagrama muestra el procesamiento de ambos conjuntos de datos en SageMaker Data Wrangler.

Uno de los posibles outputs para seleccionar en SageMaker Data Wrangler es una notebook de Python que organiza estas actividades en un conjunto de funciones. El output es un archivo .flow contiene un conjunto de instrucciones para indicar a SageMaker Processing cómo aplicar las transformaciones sobre los features. El siguiente screenshot muestra las opciones de exportación desde SageMaker Data Wrangler.

Cuando enviamos este código a SageMaker Processing estaremos creando un “preprocessing job” que prepara nuestros datos para ingresar en el modelo de forma reproducible y escalable.

Data prep

El siguiente diagrama ilustra la arquitectura para la preparación de datos. El código está disponible en la notebook 1-data-prep-e2e.ipynb.

En la notebook adjunta para la etapa de preparación de datos, asumimos que todo el preprocesamiento fue desarrollado en SageMaker Data Wrangler y que el output se encuentra disponible en la carpeta /data del código de ejemplo, para poder seguir el flujo de la notebook. Se puede consultar, explorar y visualizar features utilizando SageMaker Data Wrangler desde SageMaker Studio.

Los resultados del trabajo de SageMaker Data Wrangler se encuentran en un bucket S3 y se componen de dos archivos, claims.csv y customer.csv. Si queremos seguir adelante y asumir que la preparación de datos fue realizada, podemos acceder a los datos preprocesados en la carpeta /data que contiene los archivos claims_preprocessed.csv (31 features) y customers_preprocessed.csv (19 features). Las columnas de de policy_id y event_time en el archivo customers_preprocessed.csv son necesarias cuando se crea una feature store ya que esta requiere un identificador único para cada registro y timestamp.

Distribución y descripción de los features

El código para explorar los datos se encuentra en la notebook 0-AutoClaimFraudDetection.ipynb.

Aquí algunos gráficos de ejemplo que señalan la naturaleza sesgada de los datos y aqué features podría estar correlacionado el fraude.

El conjunto de datos puede estar fuertemente sesgado hacia los hombres.

El fraude se correlaciona positivamente con el hecho de haber tenido un mayor número de aseguradoras en los últimos 5 años.

Cargamos los datos sin procesar de un bucket S3 y creamos 10 transformaciones para los reclamos y 6 para los clientes.

Transformaciones y featurizaciones

Para reclamos, trabajamos sobre el formato de algunos string y el encoding de variables categóricas.

Preprocesamiento

Los datos se exportan de SageMaker Data Wrangler a un bucket S3. Luego se pre procesan utilizando SageMaker Processing. Suponemos que el output de este trabajo de preprocesamiento fue depositado en el bucket de S3 que luego se va a proveer. Se puede encontrar en la carpeta /data.

Ingestando los datos preprocesados en SageMaker Feature Store

Como comentamos anteriormente, SageMaker Feature Store es un repositorio centralizado para features y sus correspondientes metadatos para que puedan ser compartidos y reutilizadas a lo largo de la organización. Existe la opción de crear un feature store offline (almacenado en S3) o bien un feature store online almacenado en un storage de baja latencia o bien ambos. Los datos se almacenan en S3 utilizando un esquema de prefijos (prefixes) basado en la fecha y hora del evento. El offline feature store es de sólo escritura, lo cual permite mantener un registro histórico de los valores de los features. Los datos se almacenan en formato Parquet para optimizar el storage y el acceso de lectura y se pueden combinar para producir conjuntos de entrenamiento, validación y prueba, y también extraer datos de distintos momentos del tiempo.

Una vez que SageMaker Processing termine, tendremos nuestros dos archivos CSV para claims y customers listos. Para almacenar los features, necesitamos primero definir un feature group, una agrupación lógica de features, donde quedarán asociados los mismos y sus respectivos metadatos. En cada grupo de features, se debe especificar un identificador de registro y configuraciones para el store online y offline.

La parte online es opcional, pero muy útil si necesitamos disponibilizar los datos para inferencia en tiempo real. En esta sección crearemos dos feature groups, uno para reclamos y uno para clientes. Luego de insertar los reclamos y clientes en sus respectivos grupos, será necesario consultar el store online con Amazon Athena para construir el set de entrenamiento.

Los datos se pueden ingestar online y batch. En este caso utilizaremos el modo batch para subir cada archivo CSV a un feature group.

Cuando el feature store offline está listo, un crawler va a catalogarlo y colocarlo en una tabla de Athena. Para construir los conjuntos de entrenamiento y test, utilizaremos una query SQL que realice el join entre las tablas creadas para reclamos y clientes.

Entrenamiento y optimización

El código de esta sección se encuentra en las siguientes notebooks:

2-lineage-train-assess-bias-tune-registry-e2e.ipynb y 3-mitigate-bias-train-model2-registry-e2e.ipynb.

El siguiente diagrama ilustra el workflow para el monitoreo de sesgo, entrenamiento, tuning, linage y almacenamiento en el model registry.

Escribiremos las particiones de train y test a nuestro bucket de S3 designado para tal fin y crearemos un estimador de XGBoost para entrenar nuestro modelo de clasificación de fraude/no fraude con un target de tipo logístico. Antes de comenzar el trabajo de entrenamiento de SageMaker, utilizando el algoritmo XGBoost, configuraremos los hiperparámetros. Se puede encontrar más información sobre los mismos en XGBoost’s Learning Task Parameters, Tree Booster Parameters.

Para poder hacer un seguimiento de los artefactos y las entidades involucradas con el training job, podemos utilizar el módulo lineage de la librería sagemaker.

Dentro del módulo lineage importamos los siguientes componentes:

from sagemaker.lineage import context, artifact, association, action.

Lineage Tracking nos da la visibilidad sobre el código, datos de entrenamiento y artefactos del modelo entrenado.

También evaluamos el grado de sesgo en el pre-entrenamiento y post-entrenamiento utilizando SageMaker Clarify. Las métricas de pre-entrenamiento muestran variedad de posibles sesgos pre-existentes en nuestro conjunto de datos. Las métricas de post-entrenamiento muestran el sesgo en las predicciones resultantes del modelo. Utilizamos el archivo analysis_config.json para especificar sobre qué grupos (en base a sus características) queremos controlar el sesgo y qué métricas queremos mostrar.

Evaluamos dos métricas: la diferencia en la proporción de predicciones positivas (DPPL) y si existe desbalance de la clase. Para nuestro caso de uso, vamos a evaluar esto en el feature género (masculino o femenino). Los resultados indican un ligero sesgo en nuestro modelo medido con DPPL.

Desplegar y servir el modelo

El código para esta sección se encuentra en la notebook 4-deploy-run-inference-e2e.ipynb.

El siguiente diagrama muestra las etapas de despliegue e inferencia para predicción en tiempo real.

Elegimos el modelo que performa mejor en nuestra métrica objetivo y lo desplegamos creando un endpoint de SageMaker. Una vez desplegado utilizamos el online feature store para correr la inferencia.

Interpretando los resultados

El siguiente gráfico muestra los features y su impacto relativo en la predicción utilizando SHAP values. Estos resultados nos permiten determinar qué características tienen mayor impacto a la hora de realizar predicciones.

Crear un workflow automatizado utilizando SageMaker Pipelines

El código de esta sección se encuentra en la notebook 5-pipeline-e2e.ipynb.

Luego de completar algunas iteraciones de exploración manual, y estamos conformes con los resultados de nuestras limpiezas, transformaciones y featurizaciones podemos crear un workflow automatizado con SageMaker Pipelines para poder escalar y no volver a pasar por este proceso manual cada vez que sea el momento de re-entrenar.

El siguiente diagrama ilustra de punta a punta el pipeline de MLOps que consta de los siguientes pasos:

Preprocesar los reclamos con SageMaker Data Wrangler.
Preprocesar los clientes con SageMaker Data Wrangler.
Crear un dataset y el train/test split.
Entrenar el algoritmo XGBoost.
Crear el modelo.
Evaluar las métricas de sesgo con SageMaker Clarify.
Registrar el modelo.
Desplegar el modelo.

Conclusión

En diciembre de 2020 AWS anunció muchos nuevos features y servicios para AI y ML. En este artículo, discutimos cómo construir un modelo de punta a punta utilizando la mayoría de estas nuevas capacidades, incluyendo: SageMaker Data Wrangler para transformación de datos, SageMaker Processing para pre-procesamiento, SageMaker Feature Store (offline) para estandarización y almacenamiento de features, SageMaker Clarify para detección de sesgos de pre y post entrenamiento así como para interpretar los resultados, ML Lineage Tracking para ayudar a la gobernanza de los artefactos del modelo, SageMaker Model Registry para almacenar el modelo y metadatos asociados, y SageMaker Pipelines para automatizar el flujo de punta a punta. Pueden encontrar más información sobre cada uno de estos productos en los siguientes links.

Este artículo fue traducido del Blog de AWS en Inglés

Sobre el autor

El Dr. Ali Arsanjani es Tech Sector AI/ML Leader y Principal Architect para AI/ML Specialist Solution Architects en AWS donde ayuda a los clientes a utilizar la plataforma de manera óptima para proyectos de ML. También es profesor adjunto en la San Jose State University, enseñando y supervisando estudiantes en el programa de masters en Data Science.

Traductora

María es arquitecta de soluciones en AWS desde hace más de dos años. En su rol, ayuda a los clientes tanto a determinar la mejor arquitectura para sus distintas aplicaciones como a encontrar los mejores algoritmos para resolver problemas de AI y ML.

Antes de AWS, trabajó como desarrolladora de modelos de deep learning en un startup enfocado en NLP y chatbots y también como profesora en una coding school a cargo de un curso de data science.

Blog de Amazon Web Services (AWS)