MLOps para la inferencia por lotes con monitoreo y reentrenamiento del modelo utilizando Amazon SageMaker, HashiCorp Terraform y GitLab CI/CD

MLOps con SageMaker, Terraform y GitLab CI/CD para inferencia por lotes.

Mantener flujos de trabajo de aprendizaje automático (ML) en producción es una tarea desafiante porque requiere crear canalizaciones de integración continua y entrega continua (CI/CD) para el código y los modelos de ML, versionado de modelos, monitoreo de cambios en los datos y en el concepto, reentrenamiento del modelo y un proceso de aprobación manual para garantizar que las nuevas versiones del modelo cumplan con los requisitos de rendimiento y cumplimiento.

En esta publicación, describimos cómo crear un flujo de trabajo de MLOps para inferencia por lotes que automatiza la programación de trabajos, el monitoreo de modelos, el reentrenamiento y el registro, así como el manejo de errores y las notificaciones utilizando Amazon SageMaker, Amazon EventBridge, AWS Lambda, Amazon Simple Notification Service (Amazon SNS), HashiCorp Terraform y GitLab CI/CD. El flujo de trabajo de MLOps presentado proporciona una plantilla reutilizable para gestionar el ciclo de vida de ML a través de la automatización, el monitoreo, la auditabilidad y la escalabilidad, reduciendo así las complejidades y los costos de mantener cargas de trabajo de inferencia por lotes en producción.

Descripción general de la solución

La siguiente figura muestra la arquitectura de MLOps propuesta para la inferencia por lotes empresarial para organizaciones que utilizan GitLab CI/CD y Terraform como infraestructura como código (IaC) en conjunto con herramientas y servicios de AWS. GitLab CI/CD actúa como el macro-orquestador, orquestando las canalizaciones de construcción del modelo y implementación del modelo, que incluyen la obtención, construcción y aprovisionamiento de las canalizaciones de Amazon SageMaker y los recursos de soporte utilizando el SDK de Python de SageMaker y Terraform. El SDK de Python de SageMaker se utiliza para crear o actualizar las canalizaciones de SageMaker para entrenamiento, entrenamiento con optimización de hiperparámetros (HPO) e inferencia por lotes. Terraform se utiliza para crear recursos adicionales como reglas de EventBridge, funciones de Lambda y temas de SNS para monitorear las canalizaciones de SageMaker y enviar notificaciones (por ejemplo, cuando un paso de la canalización falla o tiene éxito). Las canalizaciones de SageMaker actúan como el orquestador para los flujos de trabajo de entrenamiento e inferencia de modelos de ML.

Este diseño de arquitectura representa una estrategia de múltiples cuentas donde los modelos de ML se construyen, entrenan y registran en un registro de modelos central dentro de una cuenta de desarrollo de ciencia de datos (que tiene más controles que una cuenta típica de desarrollo de aplicaciones). Luego, las canalizaciones de inferencia se implementan en cuentas de preparación y producción utilizando la automatización de herramientas de DevOps como GitLab CI/CD. El registro de modelos central también se puede ubicar en una cuenta de servicios compartidos. Consulte el modelo operativo para obtener las mejores prácticas con respecto a una estrategia de múltiples cuentas para ML.

• Framework Permite a los Robots Realizar Tareas Interactivas en Orden Secuencial
• Estos ingeniosos drones pueden unirse en el aire para formar un robot más grande y fuerte
• Guía para principiantes sobre el ajuste fino de modelos de lenguaje grandes (LLMs)

En las siguientes subsecciones, se discuten diferentes aspectos del diseño de la arquitectura en detalle.

Infraestructura como código

La IaC ofrece una forma de gestionar la infraestructura de TI a través de archivos legibles por máquina, lo que garantiza un control eficiente de versiones. En esta publicación y en el ejemplo de código adjunto, demostramos cómo usar HashiCorp Terraform con GitLab CI/CD para administrar los recursos de AWS de manera efectiva. Este enfoque subraya el beneficio clave de la IaC, ofreciendo un proceso transparente y repetible en la gestión de la infraestructura de TI.

Entrenamiento y reentrenamiento del modelo

En este diseño, la canalización de entrenamiento de SageMaker se ejecuta según un horario (a través de EventBridge) o en función de un desencadenador de evento de Amazon Simple Storage Service (Amazon S3) (por ejemplo, cuando se coloca un archivo de desencadenador o nuevos datos de entrenamiento, en caso de un solo objeto de datos de entrenamiento, en Amazon S3) para recalibrar regularmente el modelo con nuevos datos. Esta canalización no introduce cambios estructurales o materiales en el modelo porque utiliza hiperparámetros fijos que han sido aprobados durante el proceso de revisión del modelo empresarial.

La canalización de entrenamiento registra la nueva versión del modelo entrenado en el Registro de modelos de Amazon SageMaker si el modelo supera un umbral de rendimiento de modelo predefinido (por ejemplo, RMSE para regresión y puntuación F1 para clasificación). Cuando se registra una nueva versión del modelo en el registro de modelos, se envía una notificación al científico de datos responsable a través de Amazon SNS. El científico de datos luego debe revisar y aprobar manualmente la última versión del modelo en la interfaz de usuario de Amazon SageMaker Studio o a través de una llamada a la API utilizando la Interfaz de línea de comandos de AWS (AWS CLI) o el SDK de AWS para Python (Boto3) antes de que la nueva versión del modelo pueda utilizarse para inferencia.

La canalización de entrenamiento de SageMaker y sus recursos de soporte son creados por la canalización de construcción del modelo de GitLab, ya sea mediante una ejecución manual de la canalización de GitLab o automáticamente cuando se fusiona el código en la rama main del repositorio de Git construcción del modelo.

Inferencia por lotes

El pipeline de inferencia por lotes de SageMaker se ejecuta según un horario (a través de EventBridge) o en función de un disparador de evento de S3. El pipeline de inferencia por lotes extrae automáticamente la última versión aprobada del modelo del registro de modelos y la utiliza para la inferencia. El pipeline de inferencia por lotes incluye pasos para verificar la calidad de los datos en comparación con una línea de base creada por el pipeline de entrenamiento, así como la calidad del modelo (rendimiento del modelo) si hay etiquetas de verdad fundamentales disponibles.

Si el pipeline de inferencia por lotes descubre problemas de calidad de datos, notificará al científico de datos responsable a través de Amazon SNS. Si descubre problemas de calidad del modelo (por ejemplo, el RMSE es mayor que un umbral preespecificado), el paso del pipeline para la verificación de la calidad del modelo fallará, lo que a su vez activará un evento de EventBridge para iniciar el entrenamiento con el pipeline HPO.

El pipeline de inferencia por lotes de SageMaker y sus recursos de soporte son creados por el pipeline de implementación de modelos de GitLab, ya sea mediante una ejecución manual del pipeline de GitLab o automáticamente cuando se fusiona el código en la rama principal del repositorio Git de implementación de modelos.

Ajuste y retuning del modelo

El pipeline de entrenamiento con HPO de SageMaker se activa cuando falla el paso de verificación de calidad del modelo del pipeline de inferencia por lotes. La verificación de calidad del modelo se realiza mediante la comparación de las predicciones del modelo con las etiquetas de verdad fundamentales reales. Si la métrica de calidad del modelo (por ejemplo, RMSE para regresión y puntuación F1 para clasificación) no cumple con un criterio preespecificado, se marca el paso de verificación de calidad del modelo como fallido. El pipeline de entrenamiento con HPO de SageMaker también se puede activar manualmente (en la interfaz de usuario de SageMaker Studio o mediante una llamada a la API utilizando AWS CLI o SageMaker Python SDK) por el científico de datos responsable, si es necesario. Debido a que los hiperparámetros del modelo están cambiando, el científico de datos responsable debe obtener la aprobación del comité de revisión de modelos de la empresa antes de que se pueda aprobar la nueva versión del modelo en el registro de modelos.

El pipeline de entrenamiento con HPO de SageMaker y sus recursos de soporte son creados por el pipeline de construcción de modelos de GitLab, ya sea mediante una ejecución manual del pipeline de GitLab o automáticamente cuando se fusiona el código en la rama principal del repositorio Git de construcción de modelos.

Monitoreo del modelo

Se generan líneas de base de estadísticas y restricciones de datos como parte de los pipelines de entrenamiento y entrenamiento con HPO. Se guardan en Amazon S3 y también se registran con el modelo entrenado en el registro de modelos si el modelo pasa la evaluación. La arquitectura propuesta para el pipeline de inferencia por lotes utiliza el Monitor de modelos de Amazon SageMaker para verificaciones de calidad de datos, mientras que utiliza pasos de procesamiento personalizados de Amazon SageMaker para la verificación de calidad del modelo. Este diseño desacopla las verificaciones de calidad de datos y modelo, lo que a su vez le permite enviar solo una notificación de advertencia cuando se detecta un desvío de datos; y activar el pipeline de entrenamiento con HPO cuando se detecta una violación de calidad del modelo.

Aprobación del modelo

Después de que se registra un modelo recién entrenado en el registro de modelos, el científico de datos responsable recibe una notificación. Si el modelo ha sido entrenado por el pipeline de entrenamiento (recalibración con nuevos datos de entrenamiento mientras se mantienen los hiperparámetros fijos), no es necesario obtener la aprobación del comité de revisión de modelos de la empresa. El científico de datos puede revisar y aprobar la nueva versión del modelo de forma independiente. Por otro lado, si el modelo ha sido entrenado por el pipeline de entrenamiento con HPO (retuning cambiando los hiperparámetros), la nueva versión del modelo debe pasar por el proceso de revisión de la empresa antes de poder utilizarse para inferencia en producción. Cuando se complete el proceso de revisión, el científico de datos puede proceder y aprobar la nueva versión del modelo en el registro de modelos. Cambiar el estado del paquete de modelos a Aprobado activará una función de Lambda a través de EventBridge, que a su vez activará el pipeline de implementación de modelos de GitLab mediante una llamada a la API. Esto actualizará automáticamente el pipeline de inferencia por lotes de SageMaker para utilizar la última versión aprobada del modelo para la inferencia.

Hay dos formas principales de aprobar o rechazar una nueva versión del modelo en el registro de modelos: utilizando el SDK de AWS para Python (Boto3) o desde la interfaz de usuario de SageMaker Studio. De forma predeterminada, tanto el pipeline de entrenamiento como el pipeline de entrenamiento con HPO establecen ModelApprovalStatus en PendingManualApproval. El científico de datos responsable puede actualizar el estado de aprobación del modelo llamando a la API update_model_package desde Boto3. Consulte Actualizar el estado de aprobación de un modelo para obtener detalles sobre cómo actualizar el estado de aprobación de un modelo a través de la interfaz de usuario de SageMaker Studio.

Diseño de E/S de datos

SageMaker interactúa directamente con Amazon S3 para leer las entradas y almacenar las salidas de los pasos individuales en los pipelines de entrenamiento e inferencia. El siguiente diagrama ilustra cómo se pueden organizar diferentes scripts de Python, datos de entrenamiento en bruto y procesados, datos de inferencia en bruto y procesados, resultados de inferencia y etiquetas de verdad fundamentales (si están disponibles para el monitoreo de calidad del modelo), artefactos del modelo, métricas de evaluación de entrenamiento e inferencia (monitoreo de calidad del modelo), así como las líneas de base de calidad de datos y los informes de violación (para el monitoreo de calidad de datos) dentro de un bucket de S3. La dirección de las flechas en el diagrama indica qué archivos son entradas o salidas de sus respectivos pasos en los pipelines de SageMaker. Las flechas están codificadas por colores según el tipo de paso del pipeline para facilitar su lectura. El pipeline cargará automáticamente los scripts de Python desde el repositorio de GitLab y almacenará los archivos de salida o artefactos del modelo de cada paso en la ruta de S3 correspondiente.

El ingeniero de datos es responsable de lo siguiente:

• Cargar datos de entrenamiento etiquetados en la ruta adecuada en Amazon S3. Esto incluye agregar datos de entrenamiento nuevos regularmente para asegurar que la canalización de entrenamiento y la canalización de entrenamiento con HPO tengan acceso a datos de entrenamiento recientes para el reentrenamiento y la reajustación del modelo, respectivamente.
• Cargar datos de entrada para la inferencia en la ruta adecuada en el bucket de S3 antes de ejecutar planificadamente la canalización de inferencia.
• Cargar etiquetas de referencia en la ruta adecuada de S3 para el monitoreo de calidad del modelo.

El científico de datos es responsable de lo siguiente:

• Preparar etiquetas de referencia y proporcionarlas al equipo de ingeniería de datos para cargarlas en Amazon S3.
• Llevar las versiones del modelo entrenadas por la canalización de entrenamiento con HPO a través del proceso de revisión empresarial y obtener las aprobaciones necesarias.
• Aprobar o rechazar manualmente las versiones del modelo recién entrenadas en el registro de modelos.
• Aprobar la puerta de producción para la canalización de inferencia y los recursos de soporte para ser promovidos a producción.

Código de muestra

En esta sección, presentamos un código de muestra para operaciones de inferencia por lotes con una configuración de una sola cuenta como se muestra en el siguiente diagrama de arquitectura. El código de muestra se puede encontrar en el repositorio de GitHub y puede servir como punto de partida para la inferencia por lotes con monitoreo de modelos y reentrenamiento automático utilizando puertas de calidad que a menudo se requieren para empresas. El código de muestra difiere de la arquitectura objetivo de las siguientes formas:

• Utiliza una sola cuenta de AWS para construir e implementar el modelo de ML y los recursos de soporte. Consulte Organización de su entorno de AWS utilizando varias cuentas para obtener orientación sobre la configuración de varias cuentas en AWS.
• Utiliza un solo pipeline de GitLab CI/CD para construir e implementar el modelo de ML y los recursos de soporte.
• Cuando se entrena y aprueba una nueva versión del modelo, el pipeline de GitLab CI/CD no se activa automáticamente y debe ejecutarse manualmente por el científico de datos responsable para actualizar la canalización de inferencia de SageMaker con la última versión aprobada del modelo.
• Solo admite disparadores basados en eventos de S3 para ejecutar las canalizaciones de entrenamiento e inferencia de SageMaker.

Requisitos previos

Debe tener los siguientes requisitos previos antes de implementar esta solución:

• Una cuenta de AWS
• SageMaker Studio
• Un rol de ejecución de SageMaker con permisos de lectura/escritura en Amazon S3 y permisos de cifrado/descifrado de AWS Key Management Service (AWS KMS)
• Un bucket de S3 para almacenar datos, scripts y artefactos de modelo
• Versión de Terraform 0.13.5 o superior
• GitLab con un runner de Docker en funcionamiento para ejecutar los pipelines
• La CLI de AWS
• jq
• unzip
• Python3 (Python 3.7 o superior) y los siguientes paquetes de Python:
  • boto3
  • sagemaker
  • pandas
  • pyyaml

Estructura del repositorio

El repositorio de GitHub contiene los siguientes directorios y archivos:

• /code/lambda_function/ – Este directorio contiene el archivo Python para una función de Lambda que prepara y envía mensajes de notificación (a través de Amazon SNS) sobre los cambios de estado de los pasos de las canalizaciones de SageMaker
• /data/ – Este directorio incluye los archivos de datos sin procesar (datos de entrenamiento, inferencia y datos de referencia)
• /env_files/ – Este directorio contiene el archivo de variables de entrada de Terraform
• /pipeline_scripts/ – Este directorio contiene tres scripts de Python para crear y actualizar las canalizaciones de entrenamiento, inferencia y entrenamiento con HPO de SageMaker, así como archivos de configuración para especificar los parámetros de cada canalización
• /scripts/ – Este directorio contiene scripts de Python adicionales (como preprocesamiento y evaluación) que son referenciados por las canalizaciones de entrenamiento, inferencia y entrenamiento con HPO
• .gitlab-ci.yml – Este archivo especifica la configuración de la canalización de GitLab CI/CD
• /events.tf – Este archivo define los recursos de EventBridge
• /lambda.tf – Este archivo define la función de notificación de Lambda y los recursos asociados de AWS Identity and Access Management (IAM)
• /main.tf – Este archivo define las fuentes de datos y las variables locales de Terraform
• /sns.tf – Este archivo define los recursos de Amazon SNS
• /tags.json – Este archivo JSON le permite declarar pares clave-valor de etiquetas personalizadas y adjuntarlos a sus recursos de Terraform utilizando una variable local
• /variables.tf – Este archivo declara todas las variables de Terraform

Variables y configuración

La siguiente tabla muestra las variables que se utilizan para parametrizar esta solución. Consulte el archivo ./env_files/dev_env.tfvars para obtener más detalles.

****Nombre****	****Descripción****
bucket_name	Nombre del bucket de S3 que se utiliza para almacenar datos, scripts y artefactos de modelos
bucket_prefix	Prefijo de S3 para el proyecto de ML
bucket_train_prefix	Prefijo de S3 para los datos de entrenamiento
bucket_inf_prefix	Prefijo de S3 para los datos de inferencia
notification_function_name	Nombre de la función de Lambda que prepara y envía mensajes de notificación sobre los cambios de estado de los pasos de las canalizaciones de SageMaker
custom_notification_config	La configuración para personalizar el mensaje de notificación para pasos específicos de la canalización de SageMaker cuando se detecta un estado de ejecución de canalización específico
email_recipient	La lista de direcciones de correo electrónico para recibir las notificaciones de cambio de estado de los pasos de las canalizaciones de SageMaker
pipeline_inf	Nombre de la canalización de inferencia de SageMaker
pipeline_train	Nombre de la canalización de entrenamiento de SageMaker
pipeline_trainwhpo	Nombre de la canalización de entrenamiento con HPO de SageMaker
recreate_pipelines	Si se establece en true, las tres canalizaciones existentes de SageMaker (entrenamiento, inferencia, entrenamiento con HPO) se eliminarán y se crearán nuevas cuando se ejecute GitLab CI/CD
model_package_group_name	Nombre del grupo de paquetes de modelos
accuracy_mse_threshold	Valor máximo de MSE antes de requerir una actualización del modelo
role_arn	ARN del rol IAM del rol de ejecución de canalización de SageMaker
kms_key	ARN de la clave KMS para el cifrado de Amazon S3 y SageMaker
subnet_id	ID de la subred para la configuración de red de SageMaker
sg_id	ID del grupo de seguridad para la configuración de red de SageMaker
upload_training_data	Si se establece en true, los datos de entrenamiento se cargarán en Amazon S3 y esta operación de carga desencadenará la ejecución de la canalización de entrenamiento
upload_inference_data	Si se establece en true, los datos de inferencia se cargarán en Amazon S3 y esta operación de carga desencadenará la ejecución de la canalización de inferencia
user_id	El ID del empleado de SageMaker que se agrega como etiqueta a los recursos de SageMaker

Implementar la solución

Completa los siguientes pasos para implementar la solución en tu cuenta de AWS:

1. Clona el repositorio de GitHub en tu directorio de trabajo.
2. Revisa y modifica la configuración de la tubería de CI/CD de GitLab para adaptarla a tu entorno. La configuración se especifica en el archivo ./gitlab-ci.yml.
3. Consulta el archivo README para actualizar las variables generales de la solución en el archivo ./env_files/dev_env.tfvars. Este archivo contiene variables tanto para los scripts de Python como para la automatización de Terraform.
   1. Verifica los parámetros adicionales de SageMaker Pipelines que se definen en los archivos YAML en ./batch_scoring_pipeline/pipeline_scripts/. Revisa y actualiza los parámetros si es necesario.
4. Revisa los scripts de creación de la tubería de SageMaker en ./pipeline_scripts/ y los scripts a los que hacen referencia en la carpeta ./scripts/. Los scripts de ejemplo proporcionados en el repositorio de GitHub se basan en el conjunto de datos de Abalone. Si vas a utilizar un conjunto de datos diferente, asegúrate de actualizar los scripts para adaptarlos a tu problema específico.
5. Coloca tus archivos de datos en la carpeta ./data/ utilizando la siguiente convención de nombres. Si estás utilizando el conjunto de datos de Abalone junto con los scripts de ejemplo proporcionados, asegúrate de que los archivos de datos no tengan encabezados, que los datos de entrenamiento incluyan variables independientes y variables objetivo con el orden original de las columnas preservado, que los datos de inferencia solo incluyan variables independientes y que el archivo de verdad fundamental solo incluya la variable objetivo.
   1. training-data.csv
   2. inference-data.csv
   3. ground-truth.csv
6. Realiza un commit y un push del código al repositorio para iniciar la ejecución de la tubería de CI/CD de GitLab (primera ejecución). Ten en cuenta que la primera ejecución de la tubería fallará en la etapa pipeline porque aún no hay una versión de modelo aprobada para que el script de la tubería de inferencia la utilice. Revisa el registro de pasos y verifica que se haya creado correctamente una nueva tubería de SageMaker llamada TrainingPipeline.

• 1. Abre la interfaz de usuario de SageMaker Studio, luego revisa y ejecuta la tubería de entrenamiento.
  2. Después de la ejecución exitosa de la tubería de entrenamiento, aprueba la versión del modelo registrado en el registro de modelos y luego vuelve a ejecutar toda la tubería de CI/CD de GitLab.

1. Revisa la salida del plan de Terraform en la etapa build. Aprueba la etapa manual apply en la tubería de CI/CD de GitLab para reanudar la ejecución de la tubería y autorizar a Terraform a crear los recursos de monitoreo y notificación en tu cuenta de AWS.
2. Finalmente, revisa el estado y la salida de las ejecuciones de las tuberías de SageMaker en la interfaz de usuario de SageMaker Studio y revisa tu correo electrónico para ver los mensajes de notificación, como se muestra en la siguiente captura de pantalla. El cuerpo del mensaje predeterminado está en formato JSON.

Tuberías de SageMaker

En esta sección, describimos las tres tuberías de SageMaker dentro del flujo de trabajo MLOps.

Tubería de entrenamiento

La tubería de entrenamiento está compuesta por los siguientes pasos:

• Paso de preprocesamiento, que incluye transformación de características y codificación
• Paso de verificación de calidad de datos para generar estadísticas de datos y límites de restricciones utilizando los datos de entrenamiento
• Paso de entrenamiento
• Paso de evaluación del entrenamiento
• Paso de condición para verificar si el modelo entrenado cumple con un umbral de rendimiento preespecificado
• Paso de registro de modelo para registrar el modelo entrenado recién en el registro de modelos si el modelo entrenado cumple con el umbral de rendimiento requerido

Tanto los parámetros skip_check_data_quality como register_new_baseline_data_quality se establecen en True en la tubería de entrenamiento. Estos parámetros indican a la tubería que omita la verificación de calidad de datos y simplemente cree y registre nuevas estadísticas de datos o límites de restricciones utilizando los datos de entrenamiento. La siguiente figura muestra una ejecución exitosa de la tubería de entrenamiento.

Pipeline de inferencia por lotes

El pipeline de inferencia por lotes está compuesto por los siguientes pasos:

• Creación de un modelo a partir de la última versión aprobada en el registro de modelos
• Paso de preprocesamiento, incluyendo transformación y codificación de características
• Paso de inferencia por lotes
• Paso de preprocesamiento de control de calidad de datos, que crea un nuevo archivo CSV que contiene tanto los datos de entrada como las predicciones del modelo para su uso en la verificación de calidad de datos
• Paso de verificación de calidad de datos, que verifica los datos de entrada con respecto a las estadísticas de referencia y las restricciones asociadas con el modelo registrado
• Paso de condición para verificar si existen datos de referencia. Si existen datos de referencia, se realizará el paso de verificación de calidad del modelo
• Paso de cálculo de calidad del modelo, que calcula el rendimiento del modelo en función de las etiquetas de referencia

Tanto los parámetros skip_check_data_quality como register_new_baseline_data_quality están establecidos en False en el pipeline de inferencia. Estos parámetros indican al pipeline que realice una verificación de calidad de datos utilizando las estadísticas de datos o restricciones de referencia asociadas con el modelo registrado (supplied_baseline_statistics_data_quality y supplied_baseline_constraints_data_quality) y que omita la creación o registro de nuevas estadísticas de datos y restricciones de referencia durante la inferencia. La siguiente figura ilustra una ejecución del pipeline de inferencia por lotes donde el paso de verificación de calidad de datos ha fallado debido al bajo rendimiento del modelo en los datos de inferencia. En este caso particular, se activará automáticamente el pipeline de entrenamiento con HPO para ajustar el modelo.

Pipeline de entrenamiento con HPO

El pipeline de entrenamiento con HPO está compuesto por los siguientes pasos:

• Paso de preprocesamiento (transformación y codificación de características)
• Paso de verificación de calidad de datos para generar estadísticas de datos y restricciones de referencia utilizando los datos de entrenamiento
• Paso de ajuste de hiperparámetros
• Paso de evaluación del entrenamiento
• Paso de condición para verificar si el modelo entrenado cumple con un umbral de precisión preespecificado
• Paso de registro del modelo si el mejor modelo entrenado cumple con el umbral de precisión requerido

Tanto los parámetros skip_check_data_quality como register_new_baseline_data_quality están establecidos en True en el pipeline de entrenamiento con HPO. La siguiente figura muestra una ejecución exitosa del pipeline de entrenamiento con HPO.

Limpieza

Realiza los siguientes pasos para limpiar tus recursos:

1. Utiliza la etapa destroy en el pipeline de GitLab CI/CD para eliminar todos los recursos provisionados por Terraform.
2. Utiliza AWS CLI para enumerar y eliminar cualquier otro pipeline que haya sido creado por los scripts de Python.
3. Opcionalmente, elimina otros recursos de AWS como el bucket de S3 o el rol de IAM que se hayan creado fuera del pipeline de CI/CD.

Conclusión

En esta publicación, hemos demostrado cómo las empresas pueden crear flujos de trabajo de MLOps para sus trabajos de inferencia por lotes utilizando Amazon SageMaker, Amazon EventBridge, AWS Lambda, Amazon SNS, HashiCorp Terraform y GitLab CI/CD. El flujo de trabajo presentado automatiza el monitoreo de datos y modelos, el reentrenamiento de modelos, así como la ejecución de trabajos por lotes, la versión de código y la provisión de infraestructura. Esto puede llevar a reducciones significativas en la complejidad y los costos de mantener trabajos de inferencia por lotes en producción. Para obtener más información sobre los detalles de implementación, revisa el repositorio de GitHub.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!