Melhorando a estabilidade e a flexibilidade dos pipelines de ML na Amazon Packaging Innovation com o Amazon SageMaker Pipelines

Para encantar os clientes e minimizar o desperdício de embalagens, a Amazon deve selecionar o tipo de embalagem ideal para bilhões de pacotes enviados todos os anos. Se for usada pouca proteção para um item frágil, como uma caneca de café, o item chegará danificado e a Amazon arriscará a confiança de seu cliente. Usar muita proteção resultará em aumento de custos e lixeiras de reciclagem cheias demais. Com centenas de milhões de produtos disponíveis, é necessário um mecanismo de decisão escalável para aprender continuamente com os testes de produtos e feedback dos clientes.

Para resolver esses problemas, a equipe de inovação em embalagens da Amazon desenvolveu modelos de aprendizado de máquina (ML) que classificam se os produtos são adequados para tipos de embalagem da Amazon, como malas diretas, sacolas ou caixas, ou podem até ser enviados sem embalagem adicional. Anteriormente, a equipe desenvolveu um pipeline personalizado baseado em Funções de etapa da AWS para realizar treinamentos semanais e trabalhos de inferência diários ou mensais. No entanto, com o tempo, o pipeline não forneceu flexibilidade suficiente para lançar modelos com novas arquiteturas. O desenvolvimento dos novos pipelines apresentou uma sobrecarga e exigiu coordenação entre cientistas de dados e desenvolvedores. Para superar essas dificuldades e melhorar a velocidade de implantação de novos modelos e arquiteturas, a equipe optou por orquestrar o treinamento e a inferência de modelos com Pipelines Amazon SageMaker.

Neste post, discutimos a arquitetura de orquestração anterior com base em Step Functions, descrevemos as arquiteturas de treinamento e inferência usando Pipelines e destacamos a flexibilidade alcançada pela equipe do Amazon Packaging Innovation.

Desafios do antigo pipeline de ML na Amazon Packaging Innovation

Para incorporar feedback contínuo sobre o desempenho das embalagens, um novo modelo é treinado a cada semana usando um número crescente de etiquetas. A inferência para todo o estoque de produtos é realizada mensalmente e uma inferência diária é realizada para fornecer previsões just-in-time para o estoque recém-adicionado.

Para automatizar o processo de treinamento de vários modelos e fornecer previsões, a equipe desenvolveu um pipeline personalizado baseado em Step Functions para orquestrar as seguintes etapas:

• Preparação de dados para trabalhos de treinamento e inferência e carregamento de previsões para o banco de dados (Amazon RedShift) com Cola AWS.
• Treinamento de modelo e inferência com Amazon Sage Maker.
• Cálculo de métricas de desempenho do modelo no conjunto de validação com Lote da AWS.
• utilização Amazon DynamoDB para armazenar configurações de modelo (como proporção de divisão de dados para treinamento e validação, localização do artefato do modelo, tipo de modelo e número de instâncias para treinamento e inferência), métricas de desempenho do modelo e a versão mais recente do modelo treinado com êxito.
• Cálculo das diferenças nas pontuações de desempenho do modelo, mudanças na distribuição dos rótulos de treinamento e comparação do tamanho dos dados de entrada entre a versão anterior e a nova do modelo com AWS Lambda funções.
• Dado o grande número de etapas, o pipeline também exigia um sistema de alarme confiável em cada etapa para alertar as partes interessadas sobre quaisquer problemas. Isso foi feito por meio de uma combinação de Serviço de fila simples da Amazon (Amazon SQS) e Serviço de notificação simples da Amazon (Amazônia SNS). Os alarmes foram criados para notificar as partes interessadas do negócio, cientistas de dados e desenvolvedores sobre quaisquer etapas com falha e grandes desvios no modelo e nas métricas de dados.

Depois de usar essa solução por quase 2 anos, a equipe percebeu que essa implementação só funcionava bem para um fluxo de trabalho de ML típico em que um único modelo era treinado e pontuado em um conjunto de dados de validação. No entanto, a solução não era suficientemente flexível para modelos complexos e não era resiliente a falhas. Por exemplo, a arquitetura não acomodava facilmente o treinamento de modelo sequencial. Era difícil adicionar ou remover uma etapa sem duplicar todo o pipeline e modificar a infraestrutura. Mesmo mudanças simples nas etapas de processamento de dados, como ajustar a taxa de divisão de dados ou selecionar um conjunto diferente de recursos, exigiam coordenação de um cientista de dados e de um desenvolvedor. Quando o pipeline falhava em qualquer etapa, ele precisava ser reiniciado desde o início, o que resultava em execuções repetidas e aumento de custo. Para evitar execuções repetidas e ter que reiniciar a partir da etapa com falha, a equipe criaria uma nova cópia de uma máquina de estado abreviada. Essa solução de problemas levou a uma proliferação das máquinas de estado, cada uma começando pelas etapas que geralmente falhavam. Por fim, se um trabalho de treinamento encontrasse um desvio na distribuição de rótulos, pontuação do modelo ou número de rótulos, um cientista de dados precisava revisar o modelo e suas métricas manualmente. Em seguida, um cientista de dados acessaria uma tabela do DynamoDB com as versões do modelo e atualizaria a tabela para garantir que o modelo correto fosse usado para o próximo trabalho de inferência.

A manutenção dessa arquitetura exigia pelo menos um recurso dedicado e um recurso adicional em tempo integral para desenvolvimento. Dadas as dificuldades de expandir o pipeline para acomodar novos casos de uso, os cientistas de dados começaram a desenvolver seus próprios fluxos de trabalho, o que, por sua vez, levou a uma base de código crescente, várias tabelas de dados com esquemas de dados semelhantes e monitoramento de modelo descentralizado. O acúmulo desses problemas resultou em menor produtividade da equipe e aumento da sobrecarga.

Para enfrentar esses desafios, a equipe da Amazon Packaging Innovation avaliou outras soluções existentes para MLOps, incluindo SageMaker Pipelines (Anúncio de lançamento de dezembro de 2020). Pipelines é um recurso do SageMaker para criar, gerenciar, automatizar e dimensionar fluxos de trabalho de ML de ponta a ponta. Pipelines permite reduzir o número de etapas em todo o fluxo de trabalho de ML e é flexível o suficiente para permitir que cientistas de dados definam um fluxo de trabalho de ML personalizado. Ele se encarrega de monitorar e registrar as etapas. Ele também vem com um registro de modelo que faz a versão automática de novos modelos. O registro de modelo possui fluxos de trabalho de aprovação integrados para selecionar modelos para inferência na produção. Pipelines também permite armazenar em cache as etapas chamadas com os mesmos argumentos. Se uma execução anterior for encontrada, um cache será criado, o que permite uma reinicialização fácil em vez de recalcular as etapas concluídas com êxito.

No processo de avaliação, o Pipelines destacou-se das demais soluções pela flexibilidade e disponibilidade de recursos para suportar e expandir os fluxos de trabalho atuais e futuros. A mudança para Pipelines liberou o tempo dos desenvolvedores da manutenção e solução de problemas da plataforma e redirecionou a atenção para a adição dos novos recursos. Neste post, apresentamos o design para fluxos de trabalho de treinamento e inferência na equipe Amazon Packaging Innovation usando Pipelines. Também discutimos os benefícios e a redução de custos que a equipe percebeu ao mudar para Pipelines.

Canal de treinamento

A equipe Amazon Packaging Innovation treina modelos para cada tipo de embalagem usando um número crescente de etiquetas. O diagrama a seguir descreve todo o processo.

O fluxo de trabalho começa extraindo rótulos e recursos de um banco de dados do Amazon Redshift e descarregando os dados para Serviço de armazenamento simples da Amazon (Amazon S3) por meio de um trabalho agendado de extração, transformação e carregamento (ETL). Junto com os dados de entrada, um objeto de arquivo com o tipo de modelo e os parâmetros é colocado no bucket do S3. Esse arquivo serve como gatilho de pipeline por meio de uma função do Lambda.

As próximas etapas são totalmente personalizáveis ​​e definidas inteiramente por um cientista de dados usando o SageMaker Python SDK for Pipelines. No cenário que apresentamos neste post, os dados de entrada são divididos em conjuntos de treinamento e validação e salvos de volta em um bucket do S3 ao iniciar um trabalho de processamento do SageMaker.

Quando os dados estiverem prontos no Amazon S3, um trabalho de treinamento do SageMaker será iniciado. Depois que o modelo é treinado e criado com sucesso, a etapa de avaliação do modelo é executada nos dados de validação por meio de um trabalho de transformação em lote do SageMaker. As métricas do modelo são comparadas com as métricas do modelo da semana anterior usando um trabalho do SageMaker Processing. A equipe definiu vários critérios personalizados para avaliar os desvios no desempenho do modelo. O modelo é rejeitado ou aprovado com base nesses critérios. Se o modelo for rejeitado, o modelo aprovado anterior será usado para os próximos trabalhos de inferência. Se o modelo for aprovado, sua versão é registrada e esse modelo é usado para trabalhos de inferência. As partes interessadas recebem uma notificação sobre o resultado via Amazon CloudWatch alarmes.

A captura de tela a seguir de Estúdio Amazon SageMaker mostra as etapas do pipeline de treinamento.

Pipelines rastreia cada execução de pipeline, que você pode monitorar no Studio. Alternativamente, você pode consultar o progresso da execução usando boto3 ou de Interface de linha de comando da AWS (AWS CLI). Você pode visualizar as métricas do modelo no Studio e comparar diferentes versões do modelo.

Pipeline de inferência

A equipe Amazon Packaging Innovation atualiza as previsões para todo o inventário de produtos mensalmente. Previsões diárias são geradas para fornecer recomendações de empacotamento just-in-time para inventário recém-adicionado usando o modelo treinado mais recente. Isso requer que o pipeline de inferência seja executado diariamente com diferentes volumes de dados. O diagrama a seguir ilustra esse fluxo de trabalho.

Semelhante ao pipeline de treinamento, a inferência começa com o descarregamento dos dados do Amazon Redshift para um bucket do S3. Um objeto de arquivo colocado no Amazon S3 aciona a função do Lambda que inicia o pipeline de inferência. Os recursos são preparados para inferência e os dados são divididos em arquivos de tamanho apropriado usando um trabalho do SageMaker Processing. Em seguida, o pipeline identifica o modelo aprovado mais recente para executar as previsões e carregá-las em um bucket do S3. Por fim, as previsões são carregadas de volta no Amazon Redshift usando a API boto3-data no trabalho de processamento do SageMaker.

A captura de tela a seguir do Studio mostra os detalhes do pipeline de inferência.

Benefícios de optar por arquitetar fluxos de trabalho de ML com o SageMaker Pipelines

Nesta seção, discutimos os ganhos que a equipe Amazon Packaging Innovation obteve ao mudar para Pipelines para treinamento e inferência de modelos.

Recursos de MLOps de nível de produção prontos para uso

Ao comparar diferentes soluções internas e externas para a próxima solução de pipeline de ML, um único cientista de dados conseguiu prototipar e desenvolver uma versão completa de um fluxo de trabalho de ML com Pipelines em um ambiente Studio Jupyter em menos de 3 semanas. Mesmo na fase de prototipagem, ficou claro que o Pipelines fornecia todos os componentes de infraestrutura necessários para um fluxo de trabalho em nível de produção: versão de modelo, cache e alarmes. A disponibilidade imediata desses recursos significava que nenhum tempo adicional seria gasto para desenvolvê-los e personalizá-los. Esta foi uma clara demonstração de valor, que convenceu a equipe Amazon Packaging Innovation de que Pipelines era a solução certa.

Flexibilidade no desenvolvimento de modelos de ML

O maior ganho para os cientistas de dados da equipe foi a capacidade de experimentar facilmente e iterar por meio de diferentes modelos. Independentemente da estrutura preferida para o trabalho de ML e do número de etapas e recursos envolvidos, o Pipelines atendeu às suas necessidades. Os cientistas de dados foram autorizados a experimentar sem ter que esperar para entrar no sprint de desenvolvimento de software para adicionar um recurso ou etapa adicional.

Custos Reduzidos

O recurso Pipelines do SageMaker é sem: você paga apenas pelos recursos de computação e pelo armazenamento associado ao treinamento e à inferência. No entanto, ao pensar no custo, você precisa considerar não apenas o custo dos serviços usados, mas também as horas do desenvolvedor necessárias para manter o fluxo de trabalho, depurá-lo e corrigi-lo. Orquestrar com Pipelines é mais simples porque consiste em menos partes e infraestrutura familiar. Anteriormente, adicionar um novo recurso exigia pelo menos duas pessoas (cientista de dados e engenheiro de software) na equipe de inovação do Amazon Packaging para implementá-lo. Com o pipeline redesenhado, os esforços de engenharia agora são direcionados para infraestrutura personalizada adicional ao redor do pipeline, como a criação de um único repositório para rastreamento do código de aprendizado de máquina, simplificação da implantação do modelo nas contas da AWS, desenvolvimento de trabalhos ETL integrados e funções reutilizáveis.

A capacidade de armazenar em cache as etapas com uma entrada semelhante também contribuiu para a redução de custo, porque as equipes tinham menos probabilidade de executar novamente todo o pipeline. Em vez disso, eles poderiam facilmente iniciá-lo do ponto de falha.

Conclusão

A equipe do Amazon Packaging Innovation treina modelos de ML mensalmente e atualiza regularmente as previsões para os tipos de embalagens de produtos recomendados. Essas recomendações os ajudaram a atingir várias metas de toda a equipe e da empresa, reduzindo o desperdício e encantando os clientes a cada pedido. Os pipelines de treinamento e inferência devem ser executados de forma confiável em uma base regular, mas permitir o aprimoramento constante dos modelos.

A transição para Pipelines permitiu que a equipe implementasse quatro novas arquiteturas de modelo multimodal para produção em menos de 2 meses. A implantação de um novo modelo usando a arquitetura anterior exigiria de 5 dias (com a mesma arquitetura de modelo) a 1 mês (com uma nova arquitetura de modelo). A implantação do mesmo modelo usando Pipelines permitiu que a equipe reduzisse o tempo de desenvolvimento para 4 horas com a mesma arquitetura de modelo e para 5 dias com uma nova arquitetura de modelo. Isso equivale a uma economia de quase 80% das horas de trabalho.

Recursos adicionais

Para obter mais informações, consulte os seguintes recursos:

---

Sobre os autores

Ankur Shukla é um cientista de dados principal da AWS-ProServe com sede em Palo Alto. A Ankur tem mais de 15 anos de experiência em consultoria trabalhando diretamente com o cliente e ajudando-o a resolver problemas de negócios com tecnologia. Ele lidera várias iniciativas globais de ciência aplicada e ML-Ops na AWS. Em seu tempo livre, ele gosta de ler e passar tempo com a família.

Akash Singla é um engenheiro de desenvolvimento de sistemas sênior da equipe de inovação de embalagens da Amazon. Ele tem mais de 17 anos de experiência na solução de problemas críticos de negócios por meio de tecnologia para diversas verticais de negócios. Atualmente, ele se concentra na atualização da infraestrutura do NAWS para uma variedade de aplicativos centrados em empacotamento para melhor dimensioná-los.

Vitalina Komashko é um cientista de dados com AWS Professional Services. Ela é PhD em Farmacologia e Toxicologia, mas fez a transição para a ciência de dados do trabalho experimental porque queria “possuir a geração de dados e a interpretação dos resultados”. No início de sua carreira, ela trabalhou com empresas de biotecnologia e farmacêutica. Na AWS, ela gosta de resolver problemas para clientes de vários setores e aprender sobre seus desafios exclusivos.

Prasanth Meiyappan é cientista aplicado sênior da Amazon Packaging Innovation há mais de 4 anos. Ele tem mais de 6 anos de experiência no setor em aprendizado de máquina e enviou produtos para melhorar a experiência de pesquisa do cliente e a experiência de embalagem do cliente. Prasanth é apaixonado por sustentabilidade e tem doutorado em modelagem estatística de mudanças climáticas.

Matheus Bales é um cientista de pesquisa sênior que trabalha para otimizar a seleção de tipo de pacote usando feedback de clientes e aprendizado de máquina. Antes da Amazon, Matt trabalhou como pós-doc realizando simulações de física de partículas na Alemanha e em uma vida anterior, gerente de produção de dispositivos de implantes médicos radioativos em uma startup. Ele tem um Ph.D. em Física pela Universidade de Michigan.