Mejora de la estabilidad y flexibilidad de las canalizaciones de ML en Amazon Packaging Innovation con Amazon SageMaker Pipelines

Para deleitar a los clientes y minimizar el desperdicio de empaques, Amazon debe seleccionar el tipo de empaque óptimo para miles de millones de paquetes enviados cada año. Si se usa muy poca protección para un artículo frágil como una taza de café, el artículo llegará dañado y Amazon arriesga la confianza de sus clientes. El uso de demasiada protección resultará en mayores costos y contenedores de reciclaje demasiado llenos. Con cientos de millones de productos disponibles, se necesita un mecanismo de decisión escalable para aprender continuamente de las pruebas de productos y los comentarios de los clientes.

Para resolver estos problemas, el equipo de innovación de empaques de Amazon desarrolló modelos de aprendizaje automático (ML) que clasifican si los productos son adecuados para los tipos de empaque de Amazon, como sobres, bolsas o cajas, o si incluso podrían enviarse sin empaque adicional. Anteriormente, el equipo desarrolló una canalización personalizada basada en Funciones de paso de AWS para realizar entrenamientos semanales y trabajos de inferencia diarios o mensuales. Sin embargo, con el tiempo, la canalización no proporcionó la flexibilidad suficiente para lanzar modelos con nuevas arquitecturas. El desarrollo de las nuevas canalizaciones presentaba una sobrecarga y requería coordinación entre los científicos de datos y los desarrolladores. Para superar estas dificultades y mejorar la velocidad de implementación de nuevos modelos y arquitecturas, el equipo optó por orquestar el entrenamiento y la inferencia de modelos con Canalizaciones de Amazon SageMaker.

En esta publicación, analizamos la arquitectura de orquestación anterior basada en Step Functions, describimos las arquitecturas de capacitación e inferencia mediante Pipelines y destacamos la flexibilidad que logró el equipo de Amazon Packaging Innovation.

Desafíos de la antigua canalización de ML en Amazon Packaging Innovation

Para incorporar comentarios continuos sobre el rendimiento de los paquetes, cada semana se entrena un nuevo modelo utilizando un número creciente de etiquetas. La inferencia para todo el inventario de productos se realiza mensualmente y se realiza una inferencia diaria para entregar predicciones justo a tiempo para el inventario recién agregado.

Para automatizar el proceso de entrenamiento de múltiples modelos y proporcionar predicciones, el equipo desarrolló una canalización personalizada basada en Step Functions para orquestar los siguientes pasos:

• Preparación de datos para trabajos de entrenamiento e inferencia y carga de predicciones a la base de datos (Desplazamiento al rojo de Amazon) con Pegamento AWS.
• Modelar el entrenamiento y la inferencia con Amazon SageMaker.
• Cálculo de métricas de rendimiento del modelo en el conjunto de validación con Lote de AWS.
• Usar Amazon DynamoDB para almacenar las configuraciones del modelo (como la relación de división de datos para el entrenamiento y la validación, la ubicación del artefacto del modelo, el tipo de modelo y la cantidad de instancias para el entrenamiento y la inferencia), las métricas de rendimiento del modelo y la última versión del modelo entrenado con éxito.
• Cálculo de las diferencias en las puntuaciones de rendimiento del modelo, cambios en la distribución de las etiquetas de entrenamiento y comparación del tamaño de los datos de entrada entre las versiones anterior y nueva del modelo con AWS Lambda funciones.
• Dada la gran cantidad de pasos, la tubería también requería un sistema de alarma confiable en cada paso para alertar a las partes interesadas sobre cualquier problema. Esto se logró a través de una combinación de Servicio de cola simple de Amazon (Amazon SQS) y Servicio de notificación simple de Amazon (red social de Amazon). Las alarmas se crearon para notificar a las partes interesadas del negocio, los científicos de datos y los desarrolladores sobre cualquier paso fallido y grandes desviaciones en el modelo y las métricas de datos.

Después de usar esta solución durante casi 2 años, el equipo se dio cuenta de que esta implementación solo funcionaba bien para un flujo de trabajo típico de ML en el que se entrenaba y calificaba un solo modelo en un conjunto de datos de validación. Sin embargo, la solución no era lo suficientemente flexible para modelos complejos y no era resistente a fallas. Por ejemplo, la arquitectura no se adaptaba fácilmente al entrenamiento de modelos secuenciales. Era difícil agregar o eliminar un paso sin duplicar toda la canalización y modificar la infraestructura. Incluso los cambios simples en los pasos de procesamiento de datos, como ajustar la proporción de división de datos o seleccionar un conjunto diferente de funciones, requerían la coordinación tanto de un científico de datos como de un desarrollador. Cuando la canalización fallaba en cualquier paso, tenía que reiniciarse desde el principio, lo que generaba ejecuciones repetidas y un aumento de los costos. Para evitar ejecuciones repetidas y tener que reiniciar desde el paso fallido, el equipo crearía una nueva copia de una máquina de estado abreviada. Esta solución de problemas condujo a una proliferación de las máquinas de estado, cada una de las cuales comenzó con los pasos que fallaban comúnmente. Finalmente, si un trabajo de capacitación encontraba una desviación en la distribución de etiquetas, la puntuación del modelo o la cantidad de etiquetas, un científico de datos tenía que revisar el modelo y sus métricas manualmente. Luego, un científico de datos accedería a una tabla de DynamoDB con las versiones del modelo y actualizaría la tabla para asegurarse de que se utilizó el modelo correcto para el siguiente trabajo de inferencia.

El mantenimiento de esta arquitectura requería al menos un recurso dedicado y un recurso adicional de tiempo completo para el desarrollo. Dadas las dificultades de expandir la canalización para adaptarse a nuevos casos de uso, los científicos de datos comenzaron a desarrollar sus propios flujos de trabajo, lo que a su vez condujo a una base de código en crecimiento, múltiples tablas de datos con esquemas de datos similares y monitoreo de modelo descentralizado. La acumulación de estos problemas había resultado en una menor productividad del equipo y un aumento de los gastos generales.

Para abordar estos desafíos, el equipo de innovación de empaques de Amazon evaluó otras soluciones existentes para MLOps, incluidas SageMaker Pipelines (Anuncio de lanzamiento de diciembre de 2020). Pipelines es una capacidad de SageMaker para crear, administrar, automatizar y escalar flujos de trabajo de aprendizaje automático de extremo a extremo. Pipelines le permite reducir la cantidad de pasos en todo el flujo de trabajo de ML y es lo suficientemente flexible como para permitir que los científicos de datos definan un flujo de trabajo de ML personalizado. Se encarga de monitorear y registrar los pasos. También viene con un registro de modelos que versiona automáticamente los nuevos modelos. El registro de modelos tiene flujos de trabajo de aprobación incorporados para seleccionar modelos para la inferencia en producción. Pipelines también permite el almacenamiento en caché de pasos llamados con los mismos argumentos. Si se encuentra una ejecución anterior, se crea una memoria caché, lo que permite reiniciar fácilmente en lugar de volver a calcular los pasos completados con éxito.

En el proceso de evaluación, Pipelines se destacó de las otras soluciones por su flexibilidad y disponibilidad de funciones para respaldar y expandir los flujos de trabajo actuales y futuros. El cambio a Pipelines liberó el tiempo de los desarrolladores del mantenimiento de la plataforma y la solución de problemas y redirigió la atención hacia la adición de nuevas funciones. En esta publicación, presentamos el diseño de flujos de trabajo de capacitación e inferencia en el equipo de innovación de empaques de Amazon utilizando Pipelines. También discutimos los beneficios y la reducción de costos que el equipo obtuvo al cambiar a Pipelines.

Tubería de formación

El equipo de innovación de empaques de Amazon entrena modelos para cada tipo de paquete utilizando un número creciente de etiquetas. El siguiente diagrama describe todo el proceso.

El flujo de trabajo comienza con la extracción de etiquetas y funciones de una base de datos de Amazon Redshift y la descarga de los datos a Servicio de almacenamiento simple de Amazon (Amazon S3) a través de un trabajo programado de extracción, transformación y carga (ETL). Junto con los datos de entrada, se coloca un objeto de archivo con el tipo de modelo y los parámetros en el depósito de S3. Este archivo sirve como disparador de canalización a través de una función Lambda.

Los próximos pasos son completamente personalizables y definidos en su totalidad por un científico de datos que utiliza SageMaker Python SDK for Pipelines. En el escenario que presentamos en esta publicación, los datos de entrada se dividen en conjuntos de entrenamiento y validación y se guardan en un depósito de S3 al iniciar un trabajo de procesamiento de SageMaker.

Cuando los datos están listos en Amazon S3, se inicia un trabajo de capacitación de SageMaker. Una vez que el modelo se entrena y crea correctamente, el paso de evaluación del modelo se realiza en los datos de validación a través de un trabajo de transformación por lotes de SageMaker. Luego, las métricas del modelo se comparan con las métricas del modelo de la semana anterior mediante un trabajo de procesamiento de SageMaker. El equipo ha definido varios criterios personalizados para evaluar las desviaciones en el rendimiento del modelo. El modelo es rechazado o aprobado en base a estos criterios. Si se rechaza el modelo, se utiliza el modelo aprobado anterior para los siguientes trabajos de inferencia. Si se aprueba el modelo, se registra su versión y ese modelo se utiliza para trabajos de inferencia. Las partes interesadas reciben una notificación sobre el resultado a través de Reloj en la nube de Amazon alarmas.

La siguiente captura de pantalla de Estudio Amazon SageMaker muestra los pasos de la tubería de entrenamiento.

Pipelines realiza un seguimiento de cada ejecución de canalización, que puede supervisar en Studio. Alternativamente, puede consultar el progreso de la ejecución usando boto3 o de Interfaz de línea de comandos de AWS (CLI de AWS). Puede visualizar las métricas del modelo en Studio y comparar diferentes versiones del modelo.

Canalización de inferencia

El equipo de Amazon Packaging Innovation actualiza mensualmente las predicciones para todo el inventario de productos. Se generan predicciones diarias para proporcionar recomendaciones de empaquetado justo a tiempo para el inventario recién agregado utilizando el modelo entrenado más reciente. Esto requiere que la canalización de inferencia se ejecute diariamente con diferentes volúmenes de datos. El siguiente diagrama ilustra este flujo de trabajo.

De manera similar a la canalización de capacitación, la inferencia comienza con la descarga de los datos de Amazon Redshift a un depósito S3. Un objeto de archivo colocado en Amazon S3 activa la función Lambda que inicia la canalización de inferencia. Las funciones se preparan para la inferencia y los datos se dividen en archivos de tamaño adecuado mediante un trabajo de procesamiento de SageMaker. A continuación, la canalización identifica el último modelo aprobado para ejecutar las predicciones y cargarlas en un depósito de S3. Finalmente, las predicciones se vuelven a cargar en Amazon Redshift mediante la API de datos boto3 dentro del trabajo de procesamiento de SageMaker.

La siguiente captura de pantalla de Studio muestra los detalles de la tubería de inferencia.

Beneficios de elegir diseñar flujos de trabajo de ML con SageMaker Pipelines

En esta sección, analizamos las ganancias que obtuvo el equipo de innovación de empaques de Amazon al cambiar a Pipelines para la inferencia y el entrenamiento de modelos.

Funciones de MLOps de nivel de producción listas para usar

Mientras comparaba diferentes soluciones internas y externas para la próxima solución de canalización de ML, un solo científico de datos pudo crear un prototipo y desarrollar una versión completa de un flujo de trabajo de ML con Pipelines en un entorno de Studio Jupyter en menos de 3 semanas. Incluso en la etapa de creación de prototipos, quedó claro que Pipelines proporcionaba todos los componentes de infraestructura necesarios para un flujo de trabajo de nivel de producción: creación de versiones de modelos, almacenamiento en caché y alarmas. La disponibilidad inmediata de estas características significaba que no se dedicaría tiempo adicional a desarrollarlas y personalizarlas. Esta fue una clara demostración de valor, que convenció al equipo de Amazon Packaging Innovation de que Pipelines era la solución adecuada.

Flexibilidad en el desarrollo de modelos ML

La mayor ganancia para los científicos de datos del equipo fue la capacidad de experimentar fácilmente e iterar a través de diferentes modelos. Independientemente del marco que prefirieran para su trabajo de ML y la cantidad de pasos y funciones que implicaba, Pipelines se adaptó a sus necesidades. Los científicos de datos estaban facultados para experimentar sin tener que esperar para entrar en el sprint de desarrollo de software para agregar una característica o paso adicional.

Costos reducidos

La capacidad Pipelines de SageMaker es gratuita,: solo paga por los recursos informáticos y el almacenamiento asociado con el entrenamiento y la inferencia. Sin embargo, al pensar en el costo, debe tener en cuenta no solo el costo de los servicios utilizados, sino también las horas de desarrollador necesarias para mantener el flujo de trabajo, depurarlo y parchearlo. Orquestar con Pipelines es más simple porque consta de menos piezas e infraestructura familiar. Anteriormente, agregar una nueva característica requería al menos dos personas (científico de datos e ingeniero de software) en el equipo de innovación de empaques de Amazon para implementarla. Con la canalización rediseñada, los esfuerzos de ingeniería ahora se dirigen hacia una infraestructura personalizada adicional alrededor de la canalización, como la creación de un repositorio único para el seguimiento del código de aprendizaje automático, la simplificación de la implementación del modelo en las cuentas de AWS, el desarrollo de trabajos ETL integrados y comunes. funciones reutilizables.

La capacidad de almacenar en caché los pasos con una entrada similar también contribuyó a la reducción del costo, ya que era menos probable que los equipos volvieran a ejecutar todo el proceso. En cambio, podrían iniciarlo fácilmente desde el punto de falla.

Conclusión

El equipo de innovación de empaques de Amazon entrena modelos de aprendizaje automático mensualmente y actualiza regularmente las predicciones para los tipos de empaques de productos recomendados. Estas recomendaciones los ayudaron a lograr múltiples objetivos para todo el equipo y la empresa al reducir el desperdicio y deleitar a los clientes con cada pedido. Las canalizaciones de entrenamiento e inferencia deben ejecutarse de manera confiable de manera regular y, al mismo tiempo, permitir la mejora constante de los modelos.

La transición a Pipelines permitió al equipo implementar cuatro nuevas arquitecturas de modelos multimodales en producción en menos de 2 meses. La implementación de un nuevo modelo con la arquitectura anterior habría requerido de 5 días (con la misma arquitectura de modelo) a 1 mes (con una nueva arquitectura de modelo). La implementación del mismo modelo mediante Pipelines permitió al equipo reducir el tiempo de desarrollo a 4 horas con la misma arquitectura de modelo ya 5 días con una nueva arquitectura de modelo. Eso equivale a un ahorro de casi el 80% de las horas de trabajo.

Recursos adicionales

Para obtener más información, consulte los siguientes recursos:

---

Acerca de los autores

Ankur Shukla es un científico de datos principal en AWS-ProServe con sede en Palo Alto. Ankur tiene más de 15 años de experiencia en consultoría trabajando directamente con el cliente y ayudándolo a resolver problemas comerciales con tecnología. Lidera múltiples iniciativas globales de ciencia aplicada y ML-Ops dentro de AWS. En su tiempo libre le gusta leer y pasar tiempo con su familia.

Akash Singla es ingeniero sénior de desarrollo de sistemas en el equipo de innovación de empaques de Amazon. Tiene más de 17 años de experiencia resolviendo problemas comerciales críticos a través de la tecnología para varias verticales de negocios. Actualmente se enfoca en actualizar la infraestructura NAWS para una variedad de aplicaciones centradas en empaques para escalarlas mejor.

Vitalina Komashko es un científico de datos con los servicios profesionales de AWS. Tiene un doctorado en farmacología y toxicología, pero hizo la transición a la ciencia de datos desde el trabajo experimental porque quería "poseer la generación de datos y la interpretación de los resultados". Al principio de su carrera, trabajó con empresas biotecnológicas y farmacéuticas. En AWS, disfruta resolviendo problemas para clientes de una variedad de industrias y aprendiendo sobre sus desafíos únicos.

Prasanth Meyappan es científico aplicado sénior en Amazon Packaging Innovation durante más de 4 años. Tiene más de 6 años de experiencia en la industria en aprendizaje automático y ha enviado productos para mejorar la experiencia del cliente de búsqueda y mejorar la experiencia de empaque del cliente. Prasanth es un apasionado de la sostenibilidad y tiene un doctorado en modelado estadístico del cambio climático.

mateo balas es un científico investigador sénior que trabaja para optimizar la selección del tipo de paquete utilizando los comentarios de los clientes y el aprendizaje automático. Antes de Amazon, Matt trabajó como posdoctorado realizando simulaciones de física de partículas en Alemania y en una vida anterior, como gerente de producción de dispositivos de implantes médicos radiactivos en una empresa emergente. Tiene un doctorado. en Física de la Universidad de Michigan.