Como a Yara está usando os recursos MLOps do Amazon SageMaker para dimensionar a otimização de energia em suas fábricas de amônia

Yara é a empresa líder mundial em nutrição de culturas e fornecedora de soluções ambientais e agrícolas. A ambição da Yara está focada em cultivar um futuro alimentar positivo para a natureza que crie valor para clientes, acionistas e a sociedade em geral e forneça uma cadeia de valor alimentar mais sustentável. Apoiando nossa visão de um mundo sem fome e um planeta respeitado, a Yara persegue uma estratégia de crescimento de valor sustentável, promovendo uma nutrição de cultivos amigável ao clima e soluções de energia com emissão zero. A Yara também é a maior produtora mundial de amônia, nitratos e NPK fertilizantes. Seu segmento de produção é, portanto, um bloco de construção integral para cumprir sua missão - com uma ambição claramente declarada de se tornar líder mundial em métricas como segurança, impacto ambiental, qualidade e custos de produção. A meta de longo prazo da Yara é a “Fábrica do Futuro” com emissões zero e custos baixos.

Com base em uma transformação enxuta, a Yara aumenta seu foco em soluções digitais para ajudá-los a alcançar suas ambições. Para liderar esse esforço, a Yara estabeleceu uma unidade global chamada Produção Digital. O sucesso da Produção Digital e suas soluções é uma prioridade fundamental para a Yara, e a Yara aumentou significativamente seus esforços nesse campo. Uma área de foco crítico é aproveitar a grande quantidade de dados gerados como parte de suas operações. Portanto, a Yara está construindo produtos baseados em dados que os ajudam a otimizar a produção, aumentar a qualidade dos produtos, aumentar a confiabilidade dos locais de produção, reduzir as emissões, aumentar a segurança e a produtividade dos trabalhadores, automatizar processos manuais e muito mais.

A energia é um componente de custo importante para muitas plantas de produção; portanto, a eficiência energética tem um impacto substancial na lucratividade. No entanto, muitas vezes há uma falta de referências sólidas sobre o que é um bom desempenho e como chegar lá. A curva de carga de energia (ELC) da Yara é uma solução que usa o melhor desempenho histórico no consumo de energia comparado ao desempenho atual. Se o consumo atual se desviar muito do melhor histórico, a ferramenta dá recomendações aos operadores para orientar o consumo de energia.

Para implantar o ELC nas fábricas e dimensioná-lo para vários locais em todo o mundo, a Yara precisava construir uma plataforma MLOps. Isso garantiria que a Yara treinasse, implantasse e mantivesse modelos de forma confiável e eficiente. Além disso, para dimensionar isso para vários locais, a Yara precisava automatizar os processos de implantação e manutenção. Neste post, discutimos como a Yara está usando Amazon Sage Maker recursos, incluindo o registro do modelo, Monitor de modelo do Amazon SageMaker e Pipelines Amazon SageMaker para simplificar o ciclo de vida do aprendizado de máquina (ML), automatizando e padronizando as práticas de MLOps. Fornecemos uma visão geral da configuração, mostrando o processo de criação, treinamento, implantação e monitoramento de modelos de ML para fábricas em todo o mundo.

Visão geral da solução

A ELC usa dados de sensores da Internet das Coisas (IoT) de uma planta. Esses sensores medem métricas como rendimento de produção, condições ambientais e condições de matéria-prima, etc. Esses dados são usados ​​para treinar um modelo de previsão de energia que é então usado para gerar previsões por hora. Os operadores da planta monitoram o consumo real de energia e o comparam com o consumo ideal previsto pela ELC. Se o consumo atual de energia se desviar muito do ponto ideal, o ELC fornece uma ação para ajustar as variáveis ​​internas do processo para otimizar a eficiência energética com base em modelos analíticos.

A ELC está hospedada na nuvem. Para transmitir dados do sensor de uma planta em tempo real, a Yara usa AWS IoT Greengrass se comunicar com segurança com Núcleo da AWS IoT e exporte dados de IoT para a nuvem AWS. AWS IoT Site Wise é um serviço gerenciado que pode coletar, organizar, pesquisar e consumir dados de equipamentos industriais em escala. A Yara construiu APIs usando Gateway de API da Amazon para expor os dados do sensor a aplicativos como ELC.

O back-end do aplicativo ELC é implantado por meio do Amazon ECS e alimenta os painéis ELC no front-end que são usados ​​pelos operadores da planta. O aplicativo ELC é responsável por fornecer métricas preditivas de consumo de energia por hora para os operadores da usina. Cada usina é equipada com seu próprio modelo, pois suas características de consumo de energia diferem. Além disso, as fábricas são agrupadas em diferentes regiões da AWS com base em sua localização.

O diagrama a seguir ilustra essa arquitetura.

Para construir ELC e escalar para várias plantas, precisávamos de uma solução MLOps que suportasse o seguinte:

• AMPLIAR – Pode escalar em resposta a volumes de dados. Algumas fábricas produzem mais dados do que outras; cada planta pode produzir vários gigabytes de dados por dia.
• Extensibilidade – Pode implantar em novas regiões e contas.
• Repetibilidade – Tem modelos comuns que podemos usar para embarcar em uma nova planta.
• Flexibilidade – Pode alterar a configuração de implantação de acordo com a necessidade de cada planta.
• Confiabilidade e monitoramento – Pode executar testes e ter uma visibilidade clara do status de todas as plantas ativas. Em caso de falha, ele pode reverter para o estado estável anterior.
• Manutenção – A solução deve ter uma baixa sobrecarga de manutenção. Ele deve usar serviços sem servidor sempre que possível para reduzir o impacto da infraestrutura.

Para ML, Yara decidiu usar o SageMaker. O SageMaker é um serviço totalmente gerenciado que abrange todo o fluxo de trabalho de ML. Os seguintes recursos foram essenciais na seleção do SageMaker:

• Contêineres de estrutura do SageMaker – Yara treinou modelos preditivos ELC no TensorFlow e, com os contêineres de estrutura SageMaker, Yara conseguiu levantar e deslocar esses modelos com alterações mínimas de código no SageMaker.
• Pipelines SageMaker – O SageMaker Pipelines oferece uma interface Python para cientistas de dados escreverem pipelines de ML. Uma grande parte do código ELC consiste em um pipeline de treinamento e inferência, que são definidos em Python.
• Registro de modelo SageMaker – O registro de modelo do SageMaker permite catalogar e controlar a versão dos modelos. Além disso, facilita o gerenciamento de metadados do modelo, como métricas de treinamento.
• Monitor de modelo SageMaker – A Yara queria monitorar a qualidade e a distribuição dos dados recebidos, bem como o desempenho do modelo ELC. As APIs do SageMaker Model Monitor oferecem dados e monitoramento da qualidade do modelo.

Para gerenciar a integração contínua e a entrega contínua (CI/CD) para os pipelines de ML, a Yara usa Estrutura de implantação da Amazon (ADF). O ADF é uma estrutura de código aberto desenvolvida pela AWS para gerenciar e implantar recursos em várias contas e regiões da AWS em uma organização da AWS. O ADF permite implantações de aplicativos ou recursos em etapas, paralelas, multicontas e entre regiões por meio da estrutura definida em Organizações da AWS, aproveitando serviços como AWS Code Pipeline, AWS CodeBuild, AWS CodeCommit e Formação da Nuvem AWS para aliviar o trabalho pesado e o gerenciamento em comparação com uma configuração CI/CD tradicional.

Visão geral da solução

Toda a solução para a plataforma MLOps foi construída em dois meses em um esforço colaborativo com Serviços Profissionais AWS. A equipe que trabalhava no projeto consistia em cientistas de dados, engenheiros de dados e especialistas em DevOps. Para facilitar o desenvolvimento mais rápido em um ambiente de várias equipes, a Yara optou por usar AWS Landing Zone e organizações para criar, gerenciar e controlar centralmente diferentes contas da AWS. Por exemplo, a Yara tem uma conta de implantação central e usa contas de carga de trabalho para hospedar aplicativos de negócios. ELC é um caso de uso de otimização de processo e é implantado para otimizar contas de carga de trabalho. A equipe de produção digital da Yara também trabalha em casos de uso de ML em outras áreas além da otimização. A estrutura MLOps oferece suporte à implantação em qualquer conta de carga de trabalho, desde que as contas sejam criadas por meio de organizações.

O diagrama a seguir ilustra essa arquitetura.

O uso de uma conta de implantação central facilita o gerenciamento de artefatos comuns e pipelines de CI/CD. Em termos de gerenciamento de acesso e segurança desses artefatos comuns, é um projeto mais simples porque os limites de permissão e as chaves de criptografia são gerenciados centralmente em um só lugar. Nas seções a seguir, orientamos você pelas etapas necessárias para integrar um novo caso de uso à plataforma MLOps da Yara.

Em termos de estratégia de conta, a Yara possui uma configuração de sandbox, DEV, TEST e PROD. A conta sandbox é usada para experimentação e experimentação de novas ideias. A conta DEV é o ponto de partida dos pipelines de CI/CD e todo o desenvolvimento começa aqui. A conta de implantação contém a definição do pipeline CI/CD e é capaz de implantar nas contas DEV, TEST e PROD. Essa configuração de conta é descrita na figura a seguir.

Integrando um novo caso de uso

Para esta postagem, assumimos que temos um protótipo funcional de um caso de uso e agora queremos operacionalizá-lo. Caso esse caso de uso pertença a uma nova área de produto, primeiro precisamos provisionar as contas usando Organizações, o que aciona automaticamente o ADF para inicializar essas contas para implantação. A Yara segue uma estratégia de conta DEV>TEST>PROD; no entanto, essa configuração não é obrigatória. As contas de dados expõem APIs para acesso a dados e, para um novo caso de uso, as funções precisam receber o necessário Gerenciamento de acesso e identidade da AWS (IAM) para que possam acessar as APIs de dados.

Em seguida, precisamos definir em quais contas esse caso de uso será implantado. Isso é feito usando um mapa de implantação no ADF. O mapa de implantação é um arquivo de configuração que contém o mapeamento de estágios e destinos para o pipeline. Para executar o mapa de implantação, o ADF usa o CodePipeline. O ADF oferece flexibilidade para gerenciar parâmetros por ambiente de destino no qual a pilha é implantada. Isso facilita o gerenciamento de implantações e testes com instâncias menores.

Para criptografar todos os artefatos, como código, dados e arquivos de modelo, geramos um Serviço de gerenciamento de chaves AWS (AWS KMS). Você também pode usar a criptografia do lado do servidor. No entanto, como alguns dos artefatos gerados são acessados ​​entre contas, precisamos gerar nossa própria chave e gerenciar suas políticas de permissão para conceder acesso entre contas.

Por fim, precisamos criar um grupo de pacotes de modelo para agrupar diferentes versões de um modelo usando o registro de modelo do SageMaker, que é o recurso do SageMaker para rastrear e gerenciar modelos à medida que avançam no ciclo de vida do ML.

Pipeline de treinamento de modelo

Para cada nova fábrica integrada à ELC, criamos um novo canal de treinamento SageMaker. Esse pipeline consiste em etapas de pré-processamento de dados e treinamento de modelo. Os pipelines do SageMaker são adequados para Yara porque oferecem uma interface Python para definir um fluxo de trabalho de ML. Além disso, diferentes etapas do fluxo de trabalho podem ser configuradas para serem dimensionadas de maneira diferente. Por exemplo, você pode definir uma instância muito maior para treinamento do que para a etapa de avaliação do modelo. Os parâmetros de entrada e saída para cada etapa do pipeline são armazenados, o que facilita o rastreamento de cada execução e suas saídas. O esboço de alto nível do fluxo de trabalho de treinamento é o seguinte.

Como parte do estágio de avaliação do modelo, um conjunto de dados de avaliação é usado para gerar métricas, como precisão e desvio do erro quadrático médio (RMSE) no modelo treinado. Essas métricas são adicionadas aos metadados do modelo antes de registrar o modelo no registro do modelo. Atualmente, os modelos são promovidos manualmente para ambientes superiores e o aprovador do modelo pode visualizar as métricas do modelo para garantir que a nova versão tenha um desempenho melhor do que o modelo atual.

Os modelos são controlados por versão com o registro de modelos, com cada planta tendo seu próprio grupo de pacotes de modelos. Além disso, você pode usar o registro de modelo para rastrear quais versões de modelo são implantadas em quais ambientes. Um modelo pode estar em um Rejeitado, Aprovação manual pendenteou aprovado estado, e apenas os modelos que estão no aprovado estado pode ser implantado. Isso também oferece proteção contra a implantação acidental de uma versão não aprovada do modelo.

Inferência de modelo e pipeline de monitoramento

Para implantar o modelo e configurar o monitoramento do modelo, configuramos um segundo pipeline do SageMaker. O aplicativo ELC fornece previsões sob demanda aos operadores da planta, portanto, os modelos são acessados ​​por meio de chamadas de API feitas a partir do back-end do ELC. Os endpoints de inferência do SageMaker fornecem uma solução de hospedagem de modelo totalmente gerenciada com uma camada de API; os endpoints recebem a entrada do modelo como carga útil e previsões de retorno. Como a latência também é um fator crucial para os usuários finais que não querem esperar muito antes de obter previsões atualizadas, a Yara optou pelos endpoints de inferência em tempo real do SageMaker, que são particularmente adequados para cargas de trabalho com requisitos de latência muito baixos. Finalmente, como o aplicativo ELC não pode ter tempo de inatividade enquanto os modelos atualizados estão sendo implantados, ele conta com o recurso de implantação azul/verde dos endpoints em tempo real do SageMaker para garantir que a versão do modelo antigo continue a servir a previsão até que a nova versão seja implantada .

O diagrama a seguir ilustra a configuração de implantação e monitoramento.

Para monitoramento de modelos, Yara executa o SageMaker qualidade de dados, qualidade do modelo e explicabilidade do modelo monitoramento. O monitoramento de qualidade de dados verifica a consistência e gera estatísticas de distribuição de dados. O monitoramento da qualidade do modelo verifica o desempenho do modelo e compara a precisão do modelo com as métricas de treinamento. Os relatórios de monitoramento do modelo são gerados a cada hora. Esses relatórios são usados ​​para monitorar o desempenho do modelo na produção. O monitoramento da explicabilidade do modelo é usado para entender quais recursos contribuem mais para uma previsão.

Esses resultados da explicabilidade do modelo são compartilhados no painel ELC para fornecer aos operadores da planta mais contexto sobre o que impulsiona o consumo de energia. Isso também ajuda a determinar a ação para ajustar o processo interno caso o consumo de energia se desvie do ponto ideal.

Fluxo CI/CD

O fluxo de CI/CD para os pipelines de treinamento começa na conta DEV. A Yara segue um modelo de desenvolvimento baseado em features e quando uma nova feature é desenvolvida, o branch feature é mesclado no trunk, que inicia a implantação. Os modelos ELC são treinados na conta DEV e após o modelo ser treinado e avaliado, ele é registrado no registro do modelo. Um aprovador de modelo realiza verificações de sanidade antes de atualizar o status do modelo para aprovado. Essa ação gera um evento que aciona a implantação do pipeline de inferência de modelo. O pipeline de inferência de modelo implanta a nova versão do modelo em um endpoint do SageMaker no DEV.

Após a implantação do endpoint, são iniciados os testes para verificar o comportamento do setup. Para testes, a Yara usa Relatórios de teste do CodeBuild. Esse recurso permite que os desenvolvedores executem testes de unidade, testes de configuração e testes funcionais pré e pós-implantação. Nesse caso, Yara executa testes funcionais passando cargas úteis de teste para endpoints do SageMaker e avaliando a resposta. Depois que esses testes são aprovados, o pipeline prossegue para implantar os endpoints do SageMaker em TEST. O back-end ELC também é implantado no TEST, o que torna possível o teste de ponta a ponta do aplicativo nesse ambiente. Além disso, a Yara executa testes de aceitação do usuário em TEST. O gatilho da implantação de TEST para PROD é uma ação de aprovação manual. Depois que a nova versão do modelo passou nos testes funcionais e de aceitação do usuário no TEST, a equipe de engenharia aprova a implantação do modelo no PROD.

A figura a seguir ilustra esse fluxo de trabalho.

Componentes comuns

Para ELC, utilizamos diversos componentes que são comuns a todas as etapas de implantação (DEV, TEST, PROD) e modelos. Esses componentes residem em nossa conta de implantação e incluem controle de versão de modelo, um repositório de imagens de contêiner, uma chave de criptografia e um depósito para armazenar artefatos comuns.

Existem várias vantagens de usar artefatos comuns. Por exemplo, os recursos não precisam ser criados para todas as contas, o que reforça a compatibilidade entre as contas. Isso significa que criamos imagens de contêiner uma vez e as reutilizamos em todas as contas de destino, reduzindo o tempo de compilação.

Esse pipeline armazena as diferentes versões de modelo em um registro de modelo comum na conta de implantação. A partir desta localização central, os modelos podem ser implantados em todas as contas sem transferi-los. Da mesma forma, o uso de uma chave de criptografia armazenada centralmente facilita o gerenciamento da chave e das permissões entre contas.

Uma desvantagem de usar artefatos comuns é que a etapa de integração de um novo caso de uso pode se tornar mais elaborada. Para integrar um novo caso de uso, um novo registro de modelo deve ser criado e, se necessário, um novo repositório de imagens de contêiner. Também recomendamos a criação de uma nova chave de criptografia para separar estritamente os recursos e os dados armazenados.

Conclusão

Nesta postagem, demonstramos como a Yara usou o SageMaker e o ADF para construir uma plataforma MLOps altamente escalável. O ML é um recurso multifuncional e as equipes implantam modelos em diferentes contas de unidades de negócios. Portanto, o ADF, que oferece integração nativa com organizações, o torna um candidato ideal para inicializar contas para configurar pipelines de CI/CD. Operacionalmente, os pipelines ADF são executados na conta de implantação central, o que facilita a obtenção de uma visão geral da integridade das implantações. Por fim, o ADF usa serviços gerenciados pela AWS, como CodeBuild, CodeDeploy, CodePipeline e CloudFormation, facilitando a configuração e a manutenção.

O SageMaker fornece um amplo espectro de recursos de ML, que permite que as equipes se concentrem mais na solução de problemas de negócios e menos na criação e manutenção da infraestrutura. Além disso, o SageMaker Pipelines fornece um rico conjunto de APIs para criar, atualizar e implantar fluxos de trabalho de ML, tornando-o uma ótima opção para MLOps.

Por fim, o MLOps fornece as práticas recomendadas para implantar e manter modelos de ML em produção de maneira confiável e eficiente. É fundamental para as equipes que criam e implantam soluções de ML em escala implementar MLOps. No caso da Yara, MLOps reduz significativamente o esforço necessário para integrar uma nova fábrica, implementar atualizações para ELC e garantir que os modelos sejam monitorados quanto à qualidade.

Para obter mais informações sobre como implantar aplicativos usando o ADF, consulte o exemplos.

---

Sobre os autores

Shaheer Mansur é cientista de dados na AWS. Seu foco está na construção de plataformas de aprendizado de máquina que podem hospedar soluções de IA em escala. Suas áreas de interesse são MLOps, lojas de recursos, hospedagem de modelos e monitoramento de modelos.

Tim Becker é cientista de dados sênior da Yara International. Dentro da Produção Digital, seu foco é a otimização do processo de produção de amônia e ácido nítrico. Ele possui um PhD em Termodinâmica e é apaixonado por reunir engenharia de processos e aprendizado de máquina.

Yongyos Kaewpitakkun é cientista de dados sênior da equipe de produção digital da Yara International. Ele tem doutorado em IA/aprendizado de máquina e muitos anos de experiência prática aproveitando aprendizado de máquina, visão computacional e modelos de processamento de linguagem natural para resolver problemas de negócios desafiadores.