Crie um pipeline MLOps completo para inspeção visual de qualidade na borda – Parte 1 | Amazon Web Services

Crie um pipeline MLOps completo para inspeção visual de qualidade na borda – Parte 1 | Amazon Web Services

Carimbo de data / hora: 2 de outubro de 2023, 12:31

Uma implantação bem-sucedida de um modelo de aprendizado de máquina (ML) em um ambiente de produção depende muito de um pipeline de ML de ponta a ponta. Embora o desenvolvimento de tal pipeline possa ser um desafio, torna-se ainda mais complexo quando se trata de um caso de uso de ML de borda. O aprendizado de máquina na borda é um conceito que traz a capacidade de executar modelos de ML localmente em dispositivos de borda. Para implantar, monitorar e manter esses modelos na borda, é necessário um pipeline MLOps robusto. Um pipeline MLOps permite automatizar todo o ciclo de vida do ML, desde a rotulagem de dados até o treinamento e implantação do modelo.

A implementação de um pipeline MLOps na borda introduz complexidades adicionais que tornam os processos de automação, integração e manutenção mais desafiadores devido ao aumento da sobrecarga operacional envolvida. No entanto, o uso de serviços específicos, como Amazon Sage Maker e AWS IoT Greengrass permite reduzir significativamente esse esforço. Nesta série, orientamos você no processo de arquitetura e construção de um pipeline MLOps integrado de ponta a ponta para um caso de uso de visão computacional na borda usando SageMaker, AWS IoT Greengrass e o Kit de desenvolvimento em nuvem da AWS (AWSCDK).

Esta postagem se concentra no projeto da arquitetura geral do pipeline MLOps; Parte 2 e Parte 3 desta série concentram-se na implementação dos componentes individuais. Fornecemos um exemplo de implementação no anexo Repositório GitHub para você experimentar. Se você está apenas começando com MLOps na borda da AWS, consulte MLOps na borda com Amazon SageMaker Edge Manager e AWS IoT Greengrass para uma visão geral e arquitetura de referência.

Caso de uso: Inspeção da qualidade de etiquetas metálicas

Como engenheiro de ML, é importante compreender o caso de negócios no qual você está trabalhando. Portanto, antes de nos aprofundarmos na arquitetura do pipeline MLOps, vamos dar uma olhada no exemplo de caso de uso desta postagem. Imagine uma linha de produção de um fabricante que grava etiquetas de metal para criar etiquetas de bagagem personalizadas. O processo de garantia de qualidade é caro porque as etiquetas de metal bruto precisam ser inspecionadas manualmente em busca de defeitos como arranhões. Para tornar esse processo mais eficiente, usamos ML para detectar tags defeituosas no início do processo. Isto ajuda a evitar defeitos dispendiosos em fases posteriores do processo de produção. O modelo deve identificar possíveis defeitos como arranhões quase em tempo real e marcá-los. Em ambientes de chão de fábrica, muitas vezes você precisa lidar com a falta de conectividade ou com largura de banda restrita e maior latência. Portanto, queremos implementar uma solução de ML on-edge para inspeção visual de qualidade que possa executar inferências localmente no chão de fábrica e diminuir os requisitos em relação à conectividade. Para manter nosso exemplo simples, treinamos um modelo que marca os arranhões detectados com caixas delimitadoras. A imagem a seguir é um exemplo de tag do nosso conjunto de dados com três riscos marcados.

Etiqueta de metal com arranhões

Definindo a arquitetura do pipeline

Agora obtivemos clareza sobre nosso caso de uso e o problema específico de ML que pretendemos resolver, que gira em torno da detecção de objetos na borda. Agora é hora de esboçar uma arquitetura para nosso pipeline de MLOps. Nesta fase, ainda não estamos a olhar para tecnologias ou serviços específicos, mas sim para os componentes de alto nível do nosso pipeline. Para treinar e implantar rapidamente, precisamos automatizar todo o processo de ponta a ponta: desde a rotulagem de dados até o treinamento e a inferência. No entanto, existem alguns desafios que tornam particularmente difícil a configuração de um pipeline para um caso extremo:

  • Construir diferentes partes deste processo requer diferentes conjuntos de habilidades. Por exemplo, a rotulagem e o treinamento de dados têm um forte foco na ciência de dados, a implantação de borda requer um especialista em Internet das Coisas (IoT) e a automatização de todo o processo geralmente é feita por alguém com um conjunto de habilidades em DevOps.
  • Dependendo da sua organização, todo esse processo pode até ser implementado por várias equipes. Para nosso caso de uso, partimos do pressuposto de que equipes separadas são responsáveis ​​pela rotulagem, treinamento e implantação.
  • Mais funções e conjuntos de habilidades significam requisitos diferentes quando se trata de ferramentas e processos. Por exemplo, os cientistas de dados podem querer monitorar e trabalhar com seu ambiente familiar de notebook. Os engenheiros de MLOps desejam trabalhar usando ferramentas de infraestrutura como código (IaC) e podem estar mais familiarizados com o Console de gerenciamento da AWS.

O que isso significa para nossa arquitetura de pipeline?

Em primeiro lugar, é crucial definir claramente os principais componentes do sistema ponta a ponta que permite que diferentes equipas trabalhem de forma independente. Em segundo lugar, devem ser definidas interfaces bem definidas entre as equipas para aumentar a eficiência da colaboração. Essas interfaces ajudam a minimizar interrupções entre as equipes, permitindo-lhes modificar seus processos internos conforme necessário, desde que sigam as interfaces definidas. O diagrama a seguir ilustra como isso poderia ser para nosso pipeline de visão computacional.

Rabisco do pipeline MLOps

Vamos examinar detalhadamente a arquitetura geral do pipeline MLOps:

  1. O processo começa com uma coleção de imagens brutas de etiquetas metálicas, que são capturadas usando um dispositivo de câmera de borda no ambiente de produção para formar um conjunto de dados de treinamento inicial.
  2. A próxima etapa envolve rotular essas imagens e marcar os defeitos usando caixas delimitadoras. É essencial versionar o conjunto de dados rotulado, garantindo a rastreabilidade e a responsabilização dos dados de treinamento utilizados.
  3. Depois de termos um conjunto de dados rotulado, podemos prosseguir com o treinamento, o ajuste fino, a avaliação e o controle de versão de nosso modelo.
  4. Quando estivermos satisfeitos com o desempenho do nosso modelo, podemos implantá-lo em um dispositivo de borda e executar inferências ao vivo na borda.
  5. Enquanto o modelo opera em produção, o dispositivo de câmera de borda gera dados de imagem valiosos contendo defeitos e casos extremos nunca antes vistos. Podemos usar esses dados para melhorar ainda mais o desempenho do nosso modelo. Para conseguir isso, salvamos imagens para as quais o modelo prevê com baixa confiança ou faz previsões erradas. Essas imagens são então adicionadas de volta ao nosso conjunto de dados brutos, iniciando todo o processo novamente.

É importante observar que os dados brutos da imagem, o conjunto de dados rotulado e o modelo treinado servem como interfaces bem definidas entre os pipelines distintos. Os engenheiros de MLOps e cientistas de dados têm flexibilidade para escolher as tecnologias em seus pipelines, desde que produzam esses artefatos de forma consistente. Mais significativamente, estabelecemos um ciclo fechado de feedback. Previsões defeituosas ou de baixa confiança feitas na produção podem ser usadas para aumentar regularmente nosso conjunto de dados e treinar e aprimorar automaticamente o modelo.

Arquitetura alvo

Agora que a arquitetura de alto nível está estabelecida, é hora de aprofundar um pouco mais e ver como poderíamos construir isso com os serviços da AWS. Observe que a arquitetura mostrada nesta postagem pressupõe que você deseja assumir o controle total de todo o processo de ciência de dados. No entanto, se você está apenas começando com a inspeção de qualidade na borda, recomendamos Amazon Lookout para Visão. Ele fornece uma maneira de treinar seu próprio modelo de inspeção de qualidade sem precisar criar, manter ou entender o código de ML. Para obter mais informações, consulte O Amazon Lookout for Vision agora oferece suporte à inspeção visual de defeitos do produto na borda.

No entanto, se você quiser assumir o controle total, o diagrama a seguir mostra como seria uma arquitetura.

Arquitetura de pipeline MLOps

Semelhante a antes, vamos percorrer o fluxo de trabalho passo a passo e identificar quais serviços da AWS atendem aos nossos requisitos:

  1. Serviço de armazenamento simples da Amazon (Amazon S3) é usado para armazenar dados de imagem brutos porque nos fornece uma solução de armazenamento de baixo custo.
  2. O fluxo de trabalho de etiquetagem é orquestrado usando Funções de etapa da AWS, um mecanismo de fluxo de trabalho sem servidor que facilita a orquestração das etapas do fluxo de trabalho de etiquetagem. Como parte deste fluxo de trabalho, usamos Verdade no solo do Amazon SageMaker para automatizar totalmente a etiquetagem usando trabalhos de etiquetagem e forças de trabalho humanas gerenciadas. AWS Lambda é usado para preparar os dados, iniciar os trabalhos de etiquetagem e armazenar as etiquetas em Loja de recursos Amazon SageMaker.
  3. O SageMaker Feature Store armazena os rótulos. Ele nos permite gerenciar e compartilhar centralmente nossos recursos e nos fornece recursos integrados de controle de versão de dados, o que torna nosso pipeline mais robusto.
  4. Orquestramos a construção do modelo e o pipeline de treinamento usando Pipelines Amazon SageMaker. Ele se integra com outros recursos do SageMaker necessários por meio de etapas integradas. Vagas de treinamento do SageMaker são usados ​​para automatizar o treinamento do modelo, e Trabalhos de processamento do SageMaker são usados ​​para preparar os dados e avaliar o desempenho do modelo. Neste exemplo, estamos usando o Ultralíticos YOLOv8 Pacote Python e arquitetura de modelo para treinar e exportar um modelo de detecção de objetos para o Onnx. Formato de modelo ML para portabilidade.
  5. Se o desempenho for aceitável, o modelo treinado é registrado no Registro de modelos do Amazon SageMaker com um número de versão incremental anexado. Ele atua como nossa interface entre as etapas de treinamento do modelo e implantação de borda. Também gerenciamos o estado de aprovação dos modelos aqui. Semelhante aos demais serviços utilizados, é totalmente gerenciado, portanto não precisamos nos preocupar em administrar nossa própria infraestrutura.
  6. O fluxo de trabalho de implantação de borda é automatizado usando Step Functions, semelhante ao fluxo de trabalho de rotulagem. Podemos usar as integrações de API do Step Functions para chamar facilmente as várias APIs de serviço da AWS necessárias, como o AWS IoT Greengrass, para criar novos componentes de modelo e, posteriormente, implantar os componentes no dispositivo de borda.
  7. O AWS IoT Greengrass é usado como ambiente de tempo de execução do dispositivo de borda. Ele gerencia o ciclo de vida de implantação de nosso modelo e componentes de inferência na borda. Ele nos permite implantar facilmente novas versões de nosso modelo e componentes de inferência usando simples chamadas de API. Além disso, os modelos de ML na borda geralmente não funcionam isoladamente; podemos usar os vários AWS e comunidade forneceu componentes do AWS IoT Greengrass para conexão com outros serviços.

A arquitetura delineada se assemelha à nossa arquitetura de alto nível mostrada anteriormente. Amazon S3, SageMaker Feature Store e SageMaker Model Registry atuam como interfaces entre os diferentes pipelines. Para minimizar o esforço de execução e operação da solução, utilizamos serviços gerenciados e sem servidor sempre que possível.

Fusão em um sistema CI/CD robusto

As etapas de rotulagem de dados, treinamento de modelo e implantação de borda são essenciais para nossa solução. Como tal, qualquer alteração relacionada com o código ou dados subjacentes em qualquer uma dessas partes deverá desencadear uma nova execução de todo o processo de orquestração. Para conseguir isso, precisamos integrar esse pipeline em um sistema CI/CD que nos permita implantar automaticamente alterações de código e infraestrutura de um repositório de código versionado na produção. Semelhante à arquitetura anterior, a autonomia da equipe é um aspecto importante aqui. O diagrama a seguir mostra como isso seria usando os serviços da AWS.

pipeline de CI/CD

Vamos examinar a arquitetura CI/CD:

  1. AWS CodeCommit atua como nosso repositório Git. Para simplificar, em nosso exemplo fornecido, separamos as partes distintas (rotulagem, treinamento de modelo, implantação de borda) por meio de subpastas em um único repositório git. Em um cenário real, cada equipe pode usar repositórios diferentes para cada parte.
  2. A implantação da infraestrutura é automatizada usando o AWS CDK e cada parte (rotulagem, treinamento e borda) obtém seu próprio aplicativo AWS CDK para permitir implantações independentes.
  3. O recurso de pipeline do AWS CDK usa AWS Code Pipeline para automatizar a infraestrutura e as implantações de código.
  4. O AWS CDK implanta dois pipelines de código para cada etapa: um pipeline de ativos e um pipeline de fluxo de trabalho. Separamos o fluxo de trabalho da implantação de ativos para nos permitir iniciar os fluxos de trabalho separadamente caso não haja alterações de ativos (por exemplo, quando há novas imagens disponíveis para treinamento).
    • O pipeline de código de ativo implanta toda a infraestrutura necessária para que o fluxo de trabalho seja executado com êxito, como Gerenciamento de acesso e identidade da AWS (IAM), funções Lambda e imagens de contêiner usadas durante o treinamento.
    • O pipeline de código do fluxo de trabalho executa o fluxo de trabalho real de rotulagem, treinamento ou implantação de borda.
  5. Os pipelines de ativos são acionados automaticamente na confirmação e também quando um pipeline de fluxo de trabalho anterior é concluído.
  6. Todo o processo é acionado de acordo com um cronograma usando um Amazon Event Bridge regra para reciclagem regular.

Com a integração CI/CD, toda a cadeia ponta a ponta agora está totalmente automatizada. O pipeline é acionado sempre que o código muda em nosso repositório git, bem como de acordo com uma programação para acomodar as alterações de dados.

Pensando à frente

A arquitetura da solução descrita representa os componentes básicos para construir um pipeline MLOps ponta a ponta na borda. No entanto, dependendo dos seus requisitos, você pode pensar em adicionar funcionalidades adicionais. A seguir estão alguns exemplos:

Conclusão

Nesta postagem, descrevemos nossa arquitetura para construir um pipeline MLOps ponta a ponta para inspeção de qualidade visual na borda usando serviços AWS. Essa arquitetura agiliza todo o processo, abrangendo rotulagem de dados, desenvolvimento de modelo e implantação de borda, permitindo-nos treinar e implementar novas versões do modelo de forma rápida e confiável. Com serviços gerenciados e sem servidor, podemos direcionar nosso foco para a entrega de valor comercial, em vez de gerenciar a infraestrutura.

In Parte 2 desta série, nos aprofundaremos um nível mais profundo e examinaremos a implementação dessa arquitetura com mais detalhes, especificamente rotulagem e construção de modelo. Se você quiser ir direto para o código, você pode conferir o anexo GitHub repo.

Sobre os autores

Michael RothMichael Roth é arquiteto de soluções sênior na AWS, apoiando clientes de manufatura na Alemanha para resolver seus desafios de negócios por meio da tecnologia AWS. Além do trabalho e da família, ele se interessa por carros esportivos e gosta de café italiano.

Jörg WöhrleJörg Wöhrle é arquiteto de soluções na AWS e trabalha com clientes de manufatura na Alemanha. Apaixonado por automação, Joerg trabalhou como desenvolvedor de software, engenheiro de DevOps e engenheiro de confiabilidade de sites em sua vida pré-AWS. Além da nuvem, ele é um corredor ambicioso e gosta de passar bons momentos com sua família. Portanto, se você tiver um desafio de DevOps ou quiser correr: informe-o.

Johannes LangerJohannes Langer é arquiteto de soluções sênior na AWS, trabalhando com clientes empresariais na Alemanha. Johannes é apaixonado por aplicar aprendizado de máquina para resolver problemas reais de negócios. Em sua vida pessoal, Johannes gosta de trabalhar em projetos de reforma residencial e de passar tempo ao ar livre com sua família.

Carimbo de hora:

Mais de Aprendizado de máquina da AWS