Cómo utiliza Yara las características de MLOps de Amazon SageMaker para escalar la optimización energética en sus plantas de amoníaco

Yara es la compañía de nutrición de cultivos líder en el mundo y un proveedor de soluciones ambientales y agrícolas. La ambición de Yara se centra en hacer crecer un futuro alimentario positivo para la naturaleza que cree valor para los clientes, los accionistas y la sociedad en general, y ofrezca una cadena de valor alimentaria más sostenible. Apoyando nuestra visión de un mundo sin hambre y un planeta respetado, Yara persigue una estrategia de crecimiento de valor sostenible, promoviendo una nutrición de cultivos respetuosa con el clima y soluciones energéticas de cero emisiones. Yara es también el mayor productor mundial de amoníaco, nitratos y NPK fertilizantes Por lo tanto, su segmento de producción es un componente integral para cumplir con su misión, con una ambición claramente declarada de convertirse en líder mundial en métricas como seguridad, huella ambiental, calidad y costos de producción. El objetivo a largo plazo de Yara es la “Planta del futuro” con cero emisiones y bajo costo.

Sobre la base de una transformación Lean, Yara aumenta su enfoque en las soluciones digitales para ayudarlos a lograr sus ambiciones. Para liderar este esfuerzo, Yara estableció una unidad global llamada Producción Digital. El éxito de la producción digital y sus soluciones es una prioridad clave para Yara, y Yara aumentó significativamente sus esfuerzos en este campo. Un área de enfoque crítica es aprovechar la gran cantidad de datos generados como parte de sus operaciones. Por lo tanto, Yara está creando productos basados ​​en datos que los ayudan a optimizar la producción, aumentar la calidad de los productos, aumentar la confiabilidad de los sitios de producción, reducir las emisiones, aumentar la seguridad y la productividad de los trabajadores, automatizar los procesos manuales y más.

La energía es un componente importante del costo de muchas plantas de producción; por lo tanto, la eficiencia energética tiene un impacto sustancial en la rentabilidad. Sin embargo, a menudo hay una falta de referencias sólidas sobre cómo se ve un buen rendimiento y cómo llegar allí. La curva de carga de energía (ELC) de Yara es una solución que utiliza el mejor desempeño histórico en el consumo de energía comparado con el desempeño actual. Si el consumo actual se desvía demasiado del mejor histórico, la herramienta da recomendaciones a los operadores para controlar el consumo de energía.

Para implementar ELC en plantas de producción y escalarlo a múltiples sitios en todo el mundo, Yara necesitaba construir una plataforma MLOps. Esto garantizaría que Yara entrenaría, implementaría y mantendría modelos de manera confiable y eficiente. Además, para escalar esto a varios sitios, Yara necesitaba automatizar los procesos de implementación y mantenimiento. En esta publicación, discutimos cómo Yara está usando Amazon SageMaker características, incluido el modelo de registro, Monitor de modelo de Amazon SageMakery Canalizaciones de Amazon SageMaker para agilizar el ciclo de vida del aprendizaje automático (ML) mediante la automatización y estandarización de las prácticas de MLOps. Brindamos una descripción general de la configuración, que muestra el proceso de creación, capacitación, implementación y monitoreo de modelos ML para plantas en todo el mundo.

Resumen de la solución

ELC utiliza datos de sensores de Internet de las cosas (IoT) de una planta. Estos sensores miden métricas como el rendimiento de producción, las condiciones ambientales y las condiciones de la materia prima, etc. Estos datos se usan para entrenar un modelo de predicción de energía que luego se usa para generar predicciones por hora. Los operadores de planta controlan el consumo de energía real y lo comparan con el consumo óptimo previsto por ELC. Si el consumo de energía actual se desvía demasiado del punto óptimo, ELC proporciona una acción para ajustar las variables internas del proceso para optimizar la eficiencia energética con base en modelos analíticos.

ELC está alojado en la nube. Para transmitir datos de sensores de una planta en tiempo real, Yara utiliza AWS IoT Greengrass para comunicarse de forma segura con Núcleo de AWS IoT y exportar datos de IoT a la nube de AWS. AWS IoT SiteWise es un servicio gestionado que puede recopilar, organizar, buscar y consumir datos de equipos industriales a escala. Yara ha creado API utilizando Puerta de enlace API de Amazon para exponer los datos del sensor a aplicaciones como ELC.

El backend de la aplicación ELC se implementa a través de Amazon ECS y alimenta los tableros de ELC en el front-end que utilizan los operadores de la planta. La aplicación ELC es responsable de proporcionar métricas de consumo de energía predictivo por hora a los operadores de planta. Cada planta está equipada con su propio modelo, ya que sus características de consumo energético son diferentes. Además, las plantas se agrupan en diferentes regiones de AWS según su ubicación.

El siguiente diagrama ilustra esta arquitectura.

Para construir ELC y escalar a múltiples plantas, necesitábamos una solución MLOps que admitiera lo siguiente:

• Escalabilidad – Puede escalar en respuesta a los volúmenes de datos. Algunas plantas producen más datos que otras; cada planta puede producir varios gigabytes de datos por día.
• Extensibilidad – Puede implementarse en nuevas regiones y cuentas.
• repetibilidad – Tiene plantillas comunes que podemos usar para incorporar una nueva planta.
• Flexibilidad – Puede cambiar la configuración de despliegue en función de las necesidades de cada planta.
• Confiabilidad y monitoreo – Puede ejecutar pruebas y tener una visibilidad clara del estado de todas las plantas activas. En caso de falla, puede retroceder al estado estable anterior.
• Mantenimiento – La solución debe tener una sobrecarga de mantenimiento baja. Debe utilizar servicios sin servidor siempre que sea posible para reducir la huella de la infraestructura.

Para ML, Yara decidió usar SageMaker. SageMaker es un servicio completamente administrado que cubre todo el flujo de trabajo de ML. Las siguientes características fueron fundamentales para seleccionar SageMaker:

• Contenedores del marco SageMaker – Yara había entrenado modelos predictivos de ELC en TensorFlow, y con los contenedores de marco de SageMaker, Yara pudo levantar y cambiar estos modelos con cambios mínimos de código en SageMaker.
• Tuberías de SageMaker – Las canalizaciones de SageMaker ofrecen una interfaz de Python para que los científicos de datos escriban canalizaciones de aprendizaje automático. Una gran parte del código ELC consiste en un entrenamiento y una canalización de inferencia, que se definen en Python.
• Registro de modelos de SageMaker – El registro de modelos de SageMaker permite catalogar y controlar versiones de modelos. Además, facilita la gestión de los metadatos del modelo, como las métricas de entrenamiento.
• Monitor modelo SageMaker – Yara quería monitorear la calidad y la distribución de los datos entrantes, así como el rendimiento del modelo ELC. Las API de supervisión de modelos de SageMaker ofrecen supervisión de la calidad de los datos y los modelos.

Para administrar la integración continua y la entrega continua (CI/CD) para las canalizaciones de ML, Yara utiliza Marco de implementación de Amazon (Alimentador automático de documentos). ADF es un marco de código abierto desarrollado por AWS para administrar e implementar recursos en múltiples cuentas y regiones de AWS dentro de una organización de AWS. ADF permite implementaciones por etapas, paralelas, multicuenta y entre regiones de aplicaciones o recursos a través de la estructura definida en Organizaciones de AWS, aprovechando servicios como AWS CodePipeline, Construcción de código AWS, Compromiso de código de AWSy Formación en la nube de AWS para aliviar el trabajo pesado y la gestión en comparación con una configuración tradicional de CI/CD.

Resumen de la solución

La solución completa para la plataforma MLOps se creó en dos meses en un esfuerzo de colaboración con Servicios profesionales de AWS. El equipo que trabajaba en el proyecto estaba formado por científicos de datos, ingenieros de datos y especialistas en DevOps. Para facilitar un desarrollo más rápido en un entorno de varios equipos, Yara optó por utilizar Zona de aterrizaje de AWSne y Organizaciones para crear, administrar y gobernar de forma centralizada diferentes cuentas de AWS. Por ejemplo, Yara tiene una cuenta de implementación central y usa cuentas de carga de trabajo para alojar aplicaciones comerciales. ELC es un caso de uso de optimización de procesos y se implementa para optimizar las cuentas de carga de trabajo. El equipo de producción digital de Yara también trabaja en casos de uso de ML en áreas distintas a la optimización. El marco de MLOps admite la implementación en cualquier cuenta de carga de trabajo siempre que las cuentas se creen a través de Organizaciones.

El siguiente diagrama ilustra esta arquitectura.

El uso de una cuenta de implementación central facilita la administración de artefactos comunes y canalizaciones de CI/CD. En términos de administración de acceso y seguridad de estos artefactos comunes, es un diseño más simple porque los límites de permisos y las claves de cifrado se administran de forma centralizada en un solo lugar. En las siguientes secciones, lo guiaremos a través de los pasos necesarios para incorporar un nuevo caso de uso a la plataforma MLOps de Yara.

En términos de estrategia de cuenta, Yara tiene una configuración de sandbox, DEV, TEST y PROD. La cuenta sandbox se utiliza para experimentar y probar nuevas ideas. La cuenta DEV es el punto de partida de las canalizaciones de CI/CD, y todo el desarrollo comienza aquí. La cuenta de implementación contiene la definición de canalización de CI/CD y puede implementarse en las cuentas DEV, TEST y PROD. La configuración de esta cuenta se muestra en la siguiente figura.

Incorporación de un nuevo caso de uso

Para esta publicación, asumimos que tenemos un prototipo funcional de un caso de uso, y ahora queremos ponerlo en funcionamiento. En caso de que este caso de uso pertenezca a un área de producto nueva, primero debemos aprovisionar las cuentas mediante Organizaciones, lo que activa automáticamente ADF para iniciar estas cuentas para la implementación. Yara sigue una estrategia de cuenta DEV>TEST>PROD; sin embargo, esta configuración no es obligatoria. Las cuentas de datos exponen las API para el acceso a los datos y, para un nuevo caso de uso, se debe otorgar a los roles la necesaria Gestión de identidades y accesos de AWS (IAM) para que puedan acceder a las API de datos.

A continuación, debemos definir en qué cuentas se implementa este caso de uso. Esto se hace usando un mapa de implementación en ADF. El mapa de implementación es un archivo de configuración que contiene el mapeo de etapas y destinos para la canalización. Para ejecutar el mapa de implementación, ADF usa CodePipeline. ADF proporciona la flexibilidad para administrar parámetros por entorno de destino en el que se implementa la pila. Esto facilita la administración de implementaciones y pruebas con instancias más pequeñas.

Para cifrar todos los artefactos, como código, datos y archivos de modelos, generamos un Servicio de administración de claves de AWS (AWS KMS) clave. También puede utilizar el cifrado del lado del servidor. Sin embargo, debido a que se accede a algunos de los artefactos generados a través de cuentas, necesitamos generar nuestra propia clave y administrar sus políticas de permisos para otorgar acceso entre cuentas.

Finalmente, necesitamos crear un grupo de paquetes de modelos para agrupar diferentes versiones de un modelo usando el registro de modelos de SageMaker, que es la capacidad de SageMaker para rastrear y administrar modelos a medida que avanzan en el ciclo de vida de ML.

Tubería de entrenamiento de modelos

Para cada nueva planta incorporada para ELC, creamos una nueva canalización de capacitación de SageMaker. Esta canalización consta de pasos de preprocesamiento de datos y entrenamiento del modelo. Las canalizaciones de SageMaker son una buena opción para Yara porque ofrecen una interfaz de Python para definir un flujo de trabajo de ML. Además, se pueden configurar diferentes pasos del flujo de trabajo para escalar de manera diferente. Por ejemplo, puede definir una instancia mucho más grande para el entrenamiento que para el paso de evaluación del modelo. Los parámetros de entrada y salida para cada paso de la canalización se almacenan, lo que facilita el seguimiento de cada ejecución y sus salidas. El esquema de alto nivel del flujo de trabajo de capacitación es el siguiente.

Como parte de la etapa de evaluación del modelo, se utiliza un conjunto de datos de evaluación para generar métricas, como la precisión y la desviación del error cuadrático medio (RMSE) en el modelo entrenado. Estas métricas se agregan a los metadatos del modelo antes de registrar el modelo en el registro de modelos. Actualmente, los modelos se promocionan manualmente a entornos superiores y el aprobador del modelo puede ver las métricas del modelo para asegurarse de que la nueva versión funciona mejor que el modelo actual.

La versión de los modelos se controla con el registro de modelos, y cada planta tiene su propio grupo de paquetes de modelos. Además, puede usar el registro de modelos para rastrear qué versiones de modelos se implementan en qué entornos. Un modelo puede estar en un Rechazado, Aprobación manual pendienteo Aprobado estado, y sólo los modelos que están en el Aprobado El estado puede ser desplegado. Esto también ofrece protección contra la implementación accidental de una versión no aprobada del modelo.

Inferencia de modelos y canalización de supervisión

Para implementar el modelo y configurar la supervisión del modelo, configuramos una segunda canalización de SageMaker. La aplicación ELC proporciona a los operadores de planta predicciones bajo demanda, por lo que se accede a los modelos a través de llamadas API realizadas desde el backend de ELC. Los terminales de inferencia de SageMaker proporcionan una solución de hospedaje de modelos completamente administrada con una capa de API; los puntos finales toman la entrada del modelo como carga útil y devuelven predicciones. Debido a que la latencia también es un factor crucial para los usuarios finales que no quieren esperar mucho antes de obtener predicciones actualizadas, Yara optó por los puntos finales de inferencia en tiempo real de SageMaker, que son especialmente adecuados para cargas de trabajo con requisitos de latencia muy bajos. Finalmente, debido a que la aplicación ELC no puede tener tiempo de inactividad mientras se implementan los modelos actualizados, se basa en la capacidad de implementación azul/verde de los puntos finales en tiempo real de SageMaker para garantizar que la versión del modelo anterior continúe brindando predicción hasta que se implemente la nueva versión. .

El siguiente diagrama ilustra la configuración de implementación y monitoreo.

Para el monitoreo de modelos, Yara ejecuta SageMaker calidad de los datos, calidad del modeloy explicabilidad del modelo vigilancia. El monitoreo de la calidad de los datos verifica la consistencia y genera estadísticas de distribución de datos. La supervisión de la calidad del modelo comprueba el rendimiento del modelo y compara la precisión del modelo con las métricas de entrenamiento.. Los informes de seguimiento del modelo se generan cada hora. Estos informes se utilizan para supervisar el rendimiento del modelo en producción. El monitoreo de la explicabilidad del modelo se utiliza para comprender qué características contribuyen más a una predicción.

Estos resultados de la explicabilidad del modelo se comparten en el tablero de ELC para brindar a los operadores de la planta más contexto sobre lo que impulsa el consumo de energía. Esto también ayuda a determinar la acción para ajustar el proceso interno en caso de que el consumo de energía se desvíe del punto óptimo.

Flujo CI/CD

El flujo de CI/CD para las canalizaciones de entrenamiento comienza en la cuenta DEV. Yara sigue un modelo de desarrollo basado en funciones y cuando se desarrolla una nueva función, la rama de funciones se fusiona con el tronco, lo que inicia la implementación. Los modelos ELC se entrenan en la cuenta DEV y, una vez que el modelo se entrena y evalúa, se registra en el registro de modelos. Un aprobador de modelos realiza comprobaciones de cordura antes de actualizar el estado del modelo a Aprobado. Esta acción genera un evento que desencadena la implementación de la canalización de inferencia del modelo. La canalización de inferencia del modelo implementa la nueva versión del modelo en un extremo de SageMaker en DEV.

Después de la implementación del punto final, se inician las pruebas para verificar el comportamiento de la configuración. Para las pruebas, Yara utiliza Informes de prueba de CodeBuild. Esta función permite a los desarrolladores ejecutar pruebas unitarias, pruebas de configuración y pruebas funcionales antes y después de la implementación. En este caso, Yara ejecuta pruebas funcionales al pasar cargas útiles de prueba a puntos finales de SageMaker y evaluar la respuesta. Una vez superadas estas pruebas, la canalización procede a implementar los puntos finales de SageMaker en TEST. El backend de ELC también se implementa en TEST, lo que hace posible la realización de pruebas de extremo a extremo para la aplicación en este entorno. Además, Yara ejecuta pruebas de aceptación del usuario en TEST. El activador de la implementación de TEST a PROD es una acción de aprobación manual. Una vez que la nueva versión del modelo ha superado las pruebas de aceptación funcional y de usuario en TEST, el equipo de ingeniería aprueba la implementación del modelo en PROD.

La siguiente figura ilustra este flujo de trabajo.

Componentes comunes

Para ELC, usamos varios componentes que son comunes para todas las etapas de implementación (DEV, TEST, PROD) y modelos. Estos componentes residen en nuestra cuenta de implementación e incluyen el control de versiones del modelo, un repositorio de imágenes de contenedor, una clave de cifrado y un depósito para almacenar artefactos comunes.

Hay varias ventajas de usar artefactos comunes. Por ejemplo, no es necesario crear los recursos para cada cuenta, lo que impone la compatibilidad entre las cuentas. Eso significa que creamos imágenes de contenedores una vez y las reutilizamos en todas las cuentas de destino, lo que reduce el tiempo de creación.

Esta canalización almacena las diferentes versiones del modelo en un registro de modelo común en la cuenta de implementación. Desde esta ubicación central, los modelos se pueden implementar en todas las cuentas sin transferirlos. Del mismo modo, el uso de una clave de cifrado almacenada centralmente facilita la administración de la clave y los permisos entre cuentas.

Una desventaja de usar artefactos comunes es que el paso de incorporación de un nuevo caso de uso puede volverse más elaborado. Para incorporar un nuevo caso de uso, se debe crear un nuevo registro modelo y, si es necesario, un nuevo repositorio de imágenes de contenedores. También recomendamos crear una nueva clave de cifrado para separar estrictamente los recursos y los datos almacenados.

Conclusión

En esta publicación, demostramos cómo Yara usó SageMaker y ADF para crear una plataforma MLOps altamente escalable. ML es una capacidad interfuncional, y los equipos implementan modelos en diferentes cuentas de unidades comerciales. Por lo tanto, ADF, que ofrece integración nativa con Organizaciones, lo convierte en un candidato ideal para arrancar cuentas para configurar canalizaciones de CI/CD. Desde el punto de vista operativo, las canalizaciones de ADF se ejecutan en la cuenta de implementación central, lo que facilita obtener una vista general del estado de las implementaciones. Finalmente, ADF utiliza servicios administrados por AWS como CodeBuild, CodeDeploy, CodePipeline y CloudFormation, lo que facilita su configuración y mantenimiento.

SageMaker proporciona un amplio espectro de capacidades de ML, lo que permite que los equipos se concentren más en resolver problemas comerciales y menos en construir y mantener la infraestructura. Además, SageMaker Pipelines proporciona un amplio conjunto de API para crear, actualizar e implementar flujos de trabajo de ML, lo que lo convierte en una excelente opción para MLOps.

Por último, MLOps proporciona las mejores prácticas para implementar y mantener modelos ML en producción de manera confiable y eficiente. Es fundamental para los equipos que crean e implementan soluciones de ML a escala implementar MLOps. En el caso de Yara, MLOps reduce significativamente el esfuerzo requerido para incorporar una nueva planta, implementar actualizaciones de ELC y garantizar que los modelos sean monitoreados por calidad.

Para obtener más información sobre cómo implementar aplicaciones mediante ADF, consulte la ejemplos.

---

Sobre los autores

Shaheer Mansoor es científico de datos en AWS. Su atención se centra en la creación de plataformas de aprendizaje automático que puedan albergar soluciones de IA a escala. Sus áreas de interés son MLOps, tiendas de características, hospedaje de modelos y monitoreo de modelos.

tim becker es científico de datos sénior en Yara International. Dentro de Producción Digital, su enfoque está en la optimización de procesos de producción de amoníaco y ácido nítrico. Tiene un doctorado en termodinámica y le apasiona unir la ingeniería de procesos y el aprendizaje automático.

Yongyos Kaewpitakkun es científico de datos sénior en el equipo de producción digital de Yara International. Tiene un doctorado en IA/aprendizaje automático y muchos años de experiencia práctica en el aprovechamiento del aprendizaje automático, la visión por computadora y los modelos de procesamiento del lenguaje natural para resolver problemas comerciales desafiantes.