Construya un canal MLOps de extremo a extremo para la inspección visual de calidad en el borde – Parte 1 | Servicios web de Amazon

Construya un canal MLOps de extremo a extremo para la inspección visual de calidad en el borde – Parte 1 | Servicios web de Amazon

Sello de tiempo: 2 de octubre de 2023 12:31 p.m.

Una implementación exitosa de un modelo de aprendizaje automático (ML) en un entorno de producción depende en gran medida de una canalización de ML de un extremo a otro. Aunque desarrollar un canal de este tipo puede ser un desafío, se vuelve aún más complejo cuando se trata de un caso de uso de aprendizaje automático de vanguardia. El aprendizaje automático en el borde es un concepto que brinda la capacidad de ejecutar modelos de aprendizaje automático localmente en dispositivos de borde. Para implementar, monitorear y mantener estos modelos en el borde, se requiere una canalización MLOps sólida. Una canalización MLOps permite automatizar el ciclo de vida completo del aprendizaje automático, desde el etiquetado de datos hasta el entrenamiento y la implementación del modelo.

La implementación de un canal MLOps en el borde introduce complejidades adicionales que hacen que los procesos de automatización, integración y mantenimiento sean más desafiantes debido a la mayor sobrecarga operativa involucrada. Sin embargo, el uso de servicios especialmente diseñados como Amazon SageMaker y AWS IoT Greengrass le permite reducir significativamente este esfuerzo. En esta serie, lo guiaremos a través del proceso de diseño y construcción de una canalización MLOps integrada de extremo a extremo para un caso de uso de visión por computadora en el borde utilizando SageMaker, AWS IoT Greengrass y el Kit de desarrollo en la nube de AWS (CDK de AWS).

Esta publicación se centra en el diseño de la arquitectura general del canal MLOps; Parte 2 y Parte 3 de esta serie se centran en la implementación de los componentes individuales. Hemos proporcionado una implementación de muestra en el documento adjunto. Repositorio GitHub para que lo pruebes tú mismo. Si recién está comenzando con MLOps en el borde de AWS, consulte MLOps en el perímetro con Amazon SageMaker Edge Manager y AWS IoT Greengrass para obtener una descripción general y una arquitectura de referencia.

Caso de uso: inspeccionar la calidad de las etiquetas metálicas

Como ingeniero de ML, es importante comprender el caso de negocio en el que está trabajando. Entonces, antes de sumergirnos en la arquitectura de canalización de MLOps, veamos el caso de uso de muestra para esta publicación. Imagine una línea de producción de un fabricante que graba etiquetas de metal para crear etiquetas de equipaje personalizadas. El proceso de control de calidad es costoso porque las etiquetas de metal en bruto deben inspeccionarse manualmente para detectar defectos como rayones. Para que este proceso sea más eficiente, utilizamos ML para detectar etiquetas defectuosas en las primeras etapas del proceso. Esto ayuda a evitar costosos defectos en etapas posteriores del proceso de producción. El modelo debería identificar posibles defectos como rayones casi en tiempo real y marcarlos. En los entornos de producción, a menudo hay que lidiar con la falta de conectividad o con un ancho de banda limitado y una mayor latencia. Por lo tanto, queremos implementar una solución de aprendizaje automático de vanguardia para la inspección visual de calidad que pueda ejecutar inferencias localmente en el taller y disminuir los requisitos con respecto a la conectividad. Para que nuestro ejemplo sea sencillo, entrenamos un modelo que marca los rayones detectados con cuadros delimitadores. La siguiente imagen es un ejemplo de una etiqueta de nuestro conjunto de datos con tres rayas marcadas.

Etiqueta de metal con rayones

Definición de la arquitectura de la tubería

Ahora hemos obtenido claridad sobre nuestro caso de uso y el problema de ML específico que pretendemos abordar, que gira en torno a la detección de objetos en el borde. Ahora es el momento de redactar una arquitectura para nuestra canalización MLOps. En esta etapa, todavía no estamos analizando tecnologías o servicios específicos, sino más bien los componentes de alto nivel de nuestra cartera. Para volver a capacitarnos e implementar rápidamente, necesitamos automatizar todo el proceso de un extremo a otro: desde el etiquetado de datos hasta el entrenamiento y la inferencia. Sin embargo, existen algunos desafíos que hacen que la configuración de una canalización para un caso extremo sea particularmente difícil:

  • Construir diferentes partes de este proceso requiere diferentes conjuntos de habilidades. Por ejemplo, el etiquetado de datos y la capacitación tienen un fuerte enfoque en la ciencia de datos, la implementación de borde requiere un especialista en Internet de las cosas (IoT) y la automatización de todo el proceso generalmente la realiza alguien con un conjunto de habilidades en DevOps.
  • Dependiendo de su organización, todo este proceso podría incluso ser implementado por varios equipos. Para nuestro caso de uso, trabajamos bajo el supuesto de que equipos separados son responsables del etiquetado, la capacitación y la implementación.
  • Más roles y conjuntos de habilidades significan diferentes requisitos cuando se trata de herramientas y procesos. Por ejemplo, es posible que los científicos de datos quieran monitorear y trabajar con su entorno familiar de portátiles. Los ingenieros de MLOps quieren trabajar utilizando herramientas de infraestructura como código (IaC) y podrían estar más familiarizados con Consola de administración de AWS.

¿Qué significa esto para nuestra arquitectura de tuberías?

En primer lugar, es crucial definir claramente los componentes principales del sistema de un extremo a otro que permite que diferentes equipos trabajen de forma independiente. En segundo lugar, se deben definir interfaces bien definidas entre equipos para mejorar la eficiencia de la colaboración. Estas interfaces ayudan a minimizar las interrupciones entre los equipos, permitiéndoles modificar sus procesos internos según sea necesario, siempre y cuando cumplan con las interfaces definidas. El siguiente diagrama ilustra cómo podría verse esto para nuestro proceso de visión por computadora.

Garabato de canalización de MLOps

Examinemos en detalle la arquitectura general del proceso MLOps:

  1. El proceso comienza con una colección de imágenes sin procesar de etiquetas metálicas, que se capturan utilizando un dispositivo de cámara perimetral en el entorno de producción para formar un conjunto de datos de entrenamiento inicial.
  2. El siguiente paso consiste en etiquetar estas imágenes y marcar los defectos mediante cuadros delimitadores. Es esencial versionar el conjunto de datos etiquetado, garantizando la trazabilidad y la responsabilidad de los datos de entrenamiento utilizados.
  3. Una vez que tengamos un conjunto de datos etiquetado, podemos continuar con el entrenamiento, el ajuste, la evaluación y el versionado de nuestro modelo.
  4. Cuando estemos satisfechos con el rendimiento de nuestro modelo, podemos implementar el modelo en un dispositivo de borde y ejecutar inferencias en vivo en el borde.
  5. Mientras el modelo funciona en producción, el dispositivo de cámara perimetral genera valiosos datos de imágenes que contienen defectos y casos extremos nunca antes vistos. Podemos utilizar estos datos para mejorar aún más el rendimiento de nuestro modelo. Para lograr esto, guardamos imágenes para las cuales el modelo predice con poca confianza o hace predicciones erróneas. Luego, estas imágenes se agregan nuevamente a nuestro conjunto de datos sin procesar, iniciando todo el proceso nuevamente.

Es importante tener en cuenta que los datos de la imagen sin procesar, el conjunto de datos etiquetados y el modelo entrenado sirven como interfaces bien definidas entre las distintas canalizaciones. Los ingenieros y científicos de datos de MLOps tienen la flexibilidad de elegir las tecnologías dentro de sus procesos siempre que produzcan estos artefactos de manera consistente. Lo más significativo es que hemos establecido un circuito cerrado de retroalimentación. Las predicciones defectuosas o de baja confianza realizadas en producción se pueden utilizar para aumentar periódicamente nuestro conjunto de datos y volver a entrenar y mejorar automáticamente el modelo.

Arquitectura de destino

Ahora que la arquitectura de alto nivel está establecida, es hora de profundizar un nivel más y ver cómo podríamos construirla con los servicios de AWS. Tenga en cuenta que la arquitectura que se muestra en esta publicación supone que desea tomar el control total de todo el proceso de ciencia de datos. Sin embargo, si recién está comenzando con la inspección de calidad en el borde, le recomendamos Amazon Lookout para la visión. Proporciona una forma de entrenar su propio modelo de inspección de calidad sin tener que crear, mantener o comprender el código ML. Para obtener más información, consulte Amazon Lookout for Vision ahora admite la inspección visual de los defectos del producto en el perímetro.

Sin embargo, si desea tomar el control total, el siguiente diagrama muestra cómo podría verse una arquitectura.

Arquitectura de canalización de MLOps

Al igual que antes, repasemos el flujo de trabajo paso a paso e identifiquemos qué servicios de AWS se adaptan a nuestros requisitos:

  1. Servicio de almacenamiento simple de Amazon (Amazon S3) se utiliza para almacenar datos de imágenes sin procesar porque nos proporciona una solución de almacenamiento de bajo costo.
  2. El flujo de trabajo de etiquetado se organiza utilizando Funciones de paso de AWS, un motor de flujo de trabajo sin servidor que facilita la organización de los pasos del flujo de trabajo de etiquetado. Como parte de este flujo de trabajo, utilizamos Verdad fundamental de Amazon SageMaker automatizar completamente el etiquetado mediante trabajos de etiquetado y mano de obra humana gestionada. AWS Lambda se utiliza para preparar los datos, iniciar los trabajos de etiquetado y almacenar las etiquetas en Tienda de funciones de Amazon SageMaker.
  3. SageMaker Feature Store almacena las etiquetas. Nos permite administrar y compartir de forma centralizada nuestras funciones y nos proporciona capacidades integradas de control de versiones de datos, lo que hace que nuestro proceso sea más sólido.
  4. Orquestamos la construcción del modelo y el proceso de capacitación utilizando Canalizaciones de Amazon SageMaker. Se integra con las otras funciones de SageMaker necesarias mediante pasos integrados. Empleos de Capacitación de SageMaker se utilizan para automatizar el entrenamiento del modelo, y Empleos de Procesamiento de SageMaker se utilizan para preparar los datos y evaluar el rendimiento del modelo. En este ejemplo, estamos usando el Ultralíticos YOLOv8 Paquete Python y arquitectura de modelo para entrenar y exportar un modelo de detección de objetos al ONNX Formato de modelo ML para portabilidad.
  5. Si el rendimiento es aceptable, el modelo entrenado se registra en Registro de modelos de Amazon SageMaker con un número de versión incremental adjunto. Actúa como nuestra interfaz entre los pasos de capacitación del modelo y implementación de borde. También gestionamos aquí el estado de homologación de los modelos. Al igual que los demás servicios utilizados, está totalmente gestionado, por lo que no tenemos que encargarnos de gestionar nuestra propia infraestructura.
  6. El flujo de trabajo de implementación perimetral se automatiza mediante Step Functions, similar al flujo de trabajo de etiquetado. Podemos utilizar las integraciones de API de Step Functions para llamar fácilmente a las diversas API de servicios de AWS necesarias, como AWS IoT Greengrass, para crear nuevos componentes de modelo y luego implementar los componentes en el dispositivo perimetral.
  7. AWS IoT Greengrass se utiliza como entorno de ejecución del dispositivo perimetral. Gestiona el ciclo de vida de implementación de nuestro modelo y componentes de inferencia en el borde. Nos permite implementar fácilmente nuevas versiones de nuestro modelo y componentes de inferencia mediante llamadas API simples. Además, los modelos de aprendizaje automático en el perímetro no suelen ejecutarse de forma aislada; podemos utilizar los distintos AWS y vibrante e inclusiva proporcionó componentes de AWS IoT Greengrass para conectarse a otros servicios.

La arquitectura descrita se parece a nuestra arquitectura de alto nivel mostrada anteriormente. Amazon S3, SageMaker Feature Store y SageMaker Model Registry actúan como interfaces entre las diferentes canalizaciones. Para minimizar el esfuerzo de ejecutar y operar la solución, utilizamos servicios administrados y sin servidor siempre que sea posible.

Fusionarse en un sistema CI/CD robusto

Los pasos de etiquetado de datos, entrenamiento de modelos y implementación de borde son fundamentales para nuestra solución. Como tal, cualquier cambio relacionado con el código o los datos subyacentes en cualquiera de esas partes debería desencadenar una nueva ejecución de todo el proceso de orquestación. Para lograr esto, necesitamos integrar esta canalización en un sistema CI/CD que nos permita implementar automáticamente cambios de código e infraestructura desde un repositorio de código versionado a producción. Al igual que en la arquitectura anterior, la autonomía del equipo es un aspecto importante aquí. El siguiente diagrama muestra cómo podría verse esto usando los servicios de AWS.

Canalización de CI / CD

Repasemos la arquitectura CI/CD:

  1. Compromiso de código de AWS actúa como nuestro repositorio Git. En aras de la simplicidad, en el ejemplo proporcionado, separamos las distintas partes (etiquetado, entrenamiento de modelos, implementación perimetral) mediante subcarpetas en un único repositorio de git. En un escenario del mundo real, cada equipo podría utilizar repositorios diferentes para cada pieza.
  2. La implementación de la infraestructura se automatiza mediante AWS CDK y cada parte (etiquetado, capacitación y borde) obtiene su propia aplicación AWS CDK para permitir implementaciones independientes.
  3. La característica de canalización de AWS CDK utiliza AWS CodePipeline para automatizar la infraestructura y las implementaciones de código.
  4. AWS CDK implementa dos canales de código para cada paso: un canal de activos y un canal de flujo de trabajo. Separamos el flujo de trabajo de la implementación de activos para permitirnos iniciar los flujos de trabajo por separado en caso de que no haya cambios en los activos (por ejemplo, cuando hay nuevas imágenes disponibles para capacitación).
    • La canalización de código de activos implementa toda la infraestructura necesaria para que el flujo de trabajo se ejecute correctamente, como Gestión de identidades y accesos de AWS (IAM), funciones Lambda e imágenes de contenedores utilizadas durante el entrenamiento.
    • La canalización del código de flujo de trabajo ejecuta el flujo de trabajo de etiquetado, capacitación o implementación de borde real.
  5. Las canalizaciones de activos se activan automáticamente al confirmarse y cuando se completa una canalización de flujo de trabajo anterior.
  6. Todo el proceso se desencadena según un cronograma utilizando un Puente de eventos de Amazon regla para el reciclaje regular.

Con la integración CI/CD, toda la cadena de extremo a extremo ahora está completamente automatizada. La canalización se activa cada vez que cambia el código en nuestro repositorio de git, así como según un cronograma para adaptarse a los cambios de datos.

Mirando al futuro

La arquitectura de la solución descrita representa los componentes básicos para construir una canalización MLOps de extremo a extremo en el borde. Sin embargo, dependiendo de sus requisitos, podría considerar agregar funciones adicionales. Los siguientes son algunos ejemplos:

Conclusión

En esta publicación, describimos nuestra arquitectura para construir un canal MLOps de extremo a extremo para la inspección visual de la calidad en el borde utilizando los servicios de AWS. Esta arquitectura agiliza todo el proceso, que abarca el etiquetado de datos, el desarrollo de modelos y la implementación de borde, lo que nos permite entrenar e implementar nuevas versiones del modelo de manera rápida y confiable. Con servicios administrados y sin servidor, podemos centrarnos en brindar valor comercial en lugar de administrar la infraestructura.

In Parte 2 En esta serie, profundizaremos un nivel más y veremos la implementación de esta arquitectura con más detalle, específicamente el etiquetado y la construcción de modelos. Si desea ir directamente al código, puede consultar el documento adjunto Repositorio GitHub.

Sobre los autores

Michael RothMichael Roth es un arquitecto de soluciones senior en AWS que brinda soporte a los clientes de fabricación en Alemania para resolver sus desafíos comerciales a través de la tecnología de AWS. Además del trabajo y la familia, le interesan los coches deportivos y le gusta el café italiano.

Jörg WöhrleJörg Wöhrle es arquitecto de soluciones en AWS y trabaja con clientes de fabricación en Alemania. Apasionado por la automatización, Joerg trabajó como desarrollador de software, ingeniero de DevOps e ingeniero de confiabilidad del sitio en su vida anterior a AWS. Más allá de las nubes, es un corredor ambicioso y disfruta de tiempo de calidad con su familia. Entonces, si tienes un desafío de DevOps o quieres salir a correr: díselo.

Johannes LangerJohannes Langer es arquitecto senior de soluciones en AWS y trabaja con clientes empresariales en Alemania. A Johannes le apasiona aplicar el aprendizaje automático para resolver problemas empresariales reales. En su vida personal, a Johannes le gusta trabajar en proyectos de mejoras para el hogar y pasar tiempo al aire libre con su familia.

Sello de tiempo:

Mas de Aprendizaje automático de AWS