Crear una tubería de MLOps de principio a fin para la inspección de calidad visual en el borde – Parte 2

Construyendo una tubería de MLOps desde cero para la inspección de calidad visual en el borde - Parte 2

En la Parte 1 de esta serie, diseñamos una arquitectura para un pipeline de MLOps de extremo a extremo para un caso de uso de inspección de calidad visual en el borde. Está diseñado para automatizar todo el proceso de aprendizaje automático (ML), desde la etiquetación de datos hasta el entrenamiento y despliegue del modelo en el borde. El enfoque en servicios administrados y sin servidor reduce la necesidad de operar infraestructura para tu pipeline y te permite comenzar rápidamente.

En esta publicación, profundizaremos en cómo se implementan las partes de etiquetación y construcción y entrenamiento de modelos del pipeline. Si estás especialmente interesado en el aspecto de despliegue en el borde de la arquitectura, puedes saltar a la Parte 3. También proporcionamos un repositorio de GitHub acompañante si quieres implementar y probar esto tú mismo.

Visión general de la solución

El caso de uso de muestra utilizado para esta serie es una solución de inspección de calidad visual que puede detectar defectos en etiquetas metálicas, que podrían implementarse como parte de un proceso de fabricación. El siguiente diagrama muestra la arquitectura de alto nivel del pipeline de MLOps que definimos al comienzo de esta serie. Si aún no lo has leído, recomendamos echar un vistazo a la Parte 1.

• Ajuste fino rápido y rentable de LLaMA 2 con AWS Trainium
• Ajustando los LLM en los mensajes de Slack
• Procesamiento inteligente de documentos con los servicios de AI de AWS y Amazon Bedrock

Automatización de la etiquetación de datos

La etiquetación de datos es una tarea inherentemente intensiva en mano de obra que involucra a humanos (etiquetadores) para etiquetar los datos. La etiquetación para nuestro caso de uso significa inspeccionar una imagen y dibujar cajas delimitadoras para cada defecto visible. Esto puede parecer sencillo, pero debemos tener en cuenta varias cosas para automatizar esto:

• Proporcionar una herramienta para que los etiquetadores dibujen cajas delimitadoras
• Gestionar una fuerza de trabajo de etiquetadores
• Asegurar una buena calidad de etiquetas
• Gestionar y versionar nuestros datos y etiquetas
• Orquestar todo el proceso
• Integrarlo en el sistema CI/CD

Podemos hacer todo esto con los servicios de AWS. Para facilitar la etiquetación y gestionar nuestra fuerza de trabajo, utilizamos Amazon SageMaker Ground Truth, un servicio de etiquetación de datos que te permite construir y gestionar tus propios flujos de trabajo y fuerza de trabajo de etiquetación de datos. Puedes gestionar tu propia fuerza de trabajo privada de etiquetadores, o utilizar el poder de etiquetadores externos a través de Amazon Mechanical Turk u otros proveedores externos.

Además, todo el proceso se puede configurar y gestionar a través del SDK de AWS, que es lo que utilizamos para orquestar nuestro flujo de trabajo de etiquetación como parte de nuestro pipeline CI/CD.

Los trabajos de etiquetación se utilizan para gestionar los flujos de trabajo de etiquetación. SageMaker Ground Truth proporciona plantillas predefinidas para muchos tipos de tareas de etiquetación diferentes, incluida la dibujar cajas delimitadoras. Para obtener más detalles sobre cómo configurar un trabajo de etiquetación para tareas de cajas delimitadoras, revisa Simplificación de la etiquetación de datos para la detección de objetos YOLO en Amazon SageMaker Ground Truth. Para nuestro caso de uso, adaptamos la plantilla de tarea para tareas de cajas delimitadoras y utilizamos anotadores humanos proporcionados por Mechanical Turk para etiquetar nuestras imágenes por defecto. La siguiente captura de pantalla muestra lo que ve un etiquetador al trabajar en una imagen.

Hablemos ahora sobre la calidad de las etiquetas. La calidad de nuestras etiquetas afectará la calidad de nuestro modelo de ML. Cuando automatizamos la etiquetación de imágenes con una fuerza de trabajo humana externa como Mechanical Turk, es difícil asegurar una buena y consistente calidad de etiquetas debido a la falta de experiencia en el dominio. A veces se requiere una fuerza de trabajo privada de expertos en el dominio. Sin embargo, en nuestra solución de muestra, utilizamos Mechanical Turk para implementar la etiquetación automatizada de nuestras imágenes.

Existen muchas formas de asegurar una buena calidad de etiquetas. Para obtener más información sobre las mejores prácticas, consulta la charla AWS re:Invent 2019, Construye conjuntos de datos de entrenamiento precisos con Amazon SageMaker Ground Truth. Como parte de esta solución de ejemplo, hemos decidido centrarnos en lo siguiente:

• Proporcionar instrucciones significativas a los etiquetadores como parte de nuestros trabajos de etiquetado
• Agregar un paso de verificación de etiquetas después de la etiquetado inicial en nuestro flujo de trabajo

Finalmente, debemos pensar en cómo almacenar nuestras etiquetas para que puedan reutilizarse para el entrenamiento posterior y permitir la trazabilidad de los datos de entrenamiento utilizados en el modelo. La salida de un trabajo de etiquetado de SageMaker Ground Truth es un archivo en formato JSON-lines que contiene las etiquetas y metadatos adicionales. Hemos decidido utilizar el almacén sin conexión de Amazon SageMaker Feature Store para almacenar nuestras etiquetas. En comparación con simplemente almacenar las etiquetas en Amazon Simple Storage Service (Amazon S3), esto nos proporciona algunas ventajas distintas:

• Almacena un historial completo de los valores de las características, combinado con consultas en momentos específicos. Esto nos permite versionar fácilmente nuestro conjunto de datos y asegurar la trazabilidad.
• Como almacén de características centralizado, promueve la reutilización y visibilidad de nuestros datos.

Para obtener una introducción a SageMaker Feature Store, consulta Getting started with Amazon SageMaker Feature Store. SageMaker Feature Store admite el almacenamiento de características en formato tabular. En nuestro ejemplo, almacenamos las siguientes características para cada imagen etiquetada:

• La ubicación donde se almacena la imagen en Amazon S3
• Dimensiones de la imagen
• Las coordenadas del cuadro delimitador y los valores de clase
• Una bandera de estado que indica si la etiqueta ha sido aprobada para su uso en el entrenamiento
• El nombre del trabajo de etiquetado utilizado para crear la etiqueta

La siguiente captura de pantalla muestra cómo podría ser una entrada típica en el almacén de características.

Con este formato, podemos realizar consultas fácilmente en el almacén de características y trabajar con herramientas familiares como Pandas para construir un conjunto de datos que se utilizará para el entrenamiento posterior.

Orquestación del etiquetado de datos

¡Finalmente, es hora de automatizar y orquestar cada uno de los pasos de nuestro flujo de trabajo de etiquetado! Para ello, utilizamos AWS Step Functions, un servicio de flujo de trabajo sin servidor que nos proporciona integraciones de API para orquestar y visualizar rápidamente los pasos de nuestro flujo de trabajo. También utilizamos un conjunto de funciones de AWS Lambda para algunos de los pasos más complejos, en concreto los siguientes:

• Comprobar si hay nuevas imágenes que requieren etiquetado en Amazon S3
• Preparar los datos en el formato de entrada requerido e iniciar el trabajo de etiquetado
• Preparar los datos en el formato de entrada requerido e iniciar el trabajo de verificación de etiquetas
• Escribir el conjunto final de etiquetas en el almacén de características

La siguiente figura muestra cómo se ve la máquina de estados de etiquetado completa de Step Functions.

Etiquetado: Implementación de infraestructura e integración en CI/CD

El paso final es integrar el flujo de trabajo de Step Functions en nuestro sistema CI/CD y asegurarnos de implementar la infraestructura requerida. Para llevar a cabo esta tarea, utilizamos el AWS Cloud Development Kit (AWS CDK) para crear toda la infraestructura necesaria, como las funciones Lambda y el flujo de trabajo de Step Functions. Con CDK Pipelines, un módulo de AWS CDK, creamos un canalización en AWS CodePipeline que implementa cambios en nuestra infraestructura e inicia una canalización adicional para iniciar el flujo de trabajo de Step Functions. La integración de Step Functions en CodePipeline hace que esta tarea sea muy fácil. Utilizamos Amazon EventBridge y acciones de origen de CodePipeline para asegurarnos de que la canalización se active según un cronograma, así como cuando se realizan cambios en git.

El siguiente diagrama muestra cómo se ve en detalle la arquitectura CI/CD para la etiquetación.

Resumen de la automatización de la etiquetación de datos

Ahora tenemos un flujo de trabajo funcional para crear automáticamente etiquetas a partir de imágenes no etiquetadas de etiquetas metálicas usando SageMaker Ground Truth. Las imágenes se recogen de Amazon S3 y se pasan a un trabajo de etiquetado de SageMaker Ground Truth. Después de etiquetar las imágenes, hacemos una verificación de calidad utilizando un trabajo de verificación de etiquetas. Por último, las etiquetas se almacenan en un grupo de características en SageMaker Feature Store. Si quieres probar el ejemplo de trabajo tú mismo, echa un vistazo al repositorio de GitHub acompañante en repositorio de GitHub. ¡Veamos cómo automatizar la construcción del modelo a continuación!

Automatización de la construcción del modelo

Al igual que con la etiquetación, veamos en detalle nuestro flujo de trabajo para la construcción del modelo. Como mínimo, debemos orquestar los siguientes pasos:

• Obtener las últimas características del feature store
• Preparar los datos para la capacitación del modelo
• Entrenar el modelo
• Evaluar el rendimiento del modelo
• Versionar y almacenar el modelo
• Aprobar el modelo para su implementación si el rendimiento es aceptable

El proceso de construcción del modelo suele ser liderado por un científico de datos y es el resultado de un conjunto de experimentos realizados utilizando notebooks o código Python. Podemos seguir un proceso sencillo de tres pasos para convertir un experimento en un flujo de trabajo de MLOps totalmente automatizado:

1. Convertir el código existente de preprocesamiento, entrenamiento y evaluación en scripts de línea de comandos.
2. Crear una definición de flujo de trabajo de SageMaker para orquestar la construcción del modelo. Utiliza los scripts creados en el primer paso como parte de los pasos de procesamiento y entrenamiento.
3. Integrar el flujo de trabajo en tu flujo de trabajo de CI/CD.

Este proceso de tres pasos es genérico y se puede utilizar para cualquier arquitectura de modelo y framework de ML de tu elección. Síguelo y comienza con el Paso 1 para crear los siguientes scripts:

• preprocess.py – Esto recoge imágenes etiquetadas de SageMaker Feature Store, divide el conjunto de datos y lo transforma en el formato requerido para entrenar nuestro modelo, en este caso el formato de entrada para YOLOv8
• train.py – Esto entrena un modelo de detección de objetos YOLOv8 de Ultralytics utilizando PyTorch para detectar arañazos en imágenes de etiquetas metálicas

Orquestación de la construcción del modelo

En el Paso 2, empaquetamos estos scripts en trabajos de entrenamiento y procesamiento y definimos el flujo de trabajo final de SageMaker, que se ve como la siguiente figura.

Consta de los siguientes pasos:

1. Un paso de procesamiento para cargar las últimas características de SageMaker Feature Store, dividir el conjunto de datos en conjuntos de entrenamiento, validación y prueba, y almacenar los conjuntos de datos como archivos comprimidos (tarballs) para entrenamiento.
2. Un paso de entrenamiento para entrenar el modelo utilizando los conjuntos de datos de entrenamiento, validación y prueba, y exportar la métrica de Precisión Promedio Media (mAP) para el modelo.
3. Un paso de condición para evaluar si el valor de la métrica mAP del modelo entrenado está por encima de un umbral configurado. Si es así, se ejecuta un paso de Registro de Modelo que registra el modelo entrenado en el Registro de Modelos de SageMaker.

Si estás interesado en el código detallado del flujo de trabajo, echa un vistazo a la definición del flujo de trabajo en nuestro repositorio de muestra.

Entrenamiento: Implementación de Infraestructura e Integración en CI/CD

Ahora es el momento de pasar al Paso 3: integración en el flujo de trabajo CI/CD. Nuestro proceso de CI/CD sigue el mismo patrón ilustrado en la sección de etiquetado anteriormente. Utilizamos AWS CDK para implementar los pipelines necesarios desde CodePipeline. La única diferencia es que utilizamos Amazon SageMaker Pipelines en lugar de Step Functions. La definición del pipeline de SageMaker se construye y se activa como parte de una acción de CodeBuild en CodePipeline.

Conclusión

Ahora tenemos un flujo de trabajo para etiquetado y entrenamiento de modelos totalmente automatizado utilizando SageMaker. Empezamos creando scripts de línea de comandos a partir del código de experimento. Luego utilizamos SageMaker Pipelines para orquestar cada uno de los pasos del flujo de trabajo de entrenamiento de modelos. Los scripts de línea de comandos se integraron como parte de los pasos de entrenamiento y procesamiento. Al final del pipeline, el modelo entrenado se versiona y se registra en el Registro de Modelos de SageMaker.

Echa un vistazo a Parte 3 de esta serie, donde analizaremos más de cerca el paso final de nuestro flujo de trabajo MLOps. ¡Crearemos el pipeline que compila e implementa el modelo en un dispositivo de borde utilizando AWS IoT Greengrass!

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