Estrutura de operações de aprendizado de máquina (MLOps) para aumentar o ciclo de vida do aprendizado de máquina com o Azure Machine Learning

Este projeto de cliente ajudou uma empresa de alimentos da Fortune 500 a melhorar sua previsão de demanda. A empresa envia produtos diretamente para vários pontos de venda. A melhoria os ajudou a otimizar o estoque de seus produtos em diferentes lojas em várias regiões dos Estados Unidos. Para conseguir isso, a equipe de Engenharia de Software Comercial (CSE) da Microsoft trabalhou com os cientistas de dados do cliente em um estudo piloto para desenvolver modelos de aprendizado de máquina personalizados para as regiões selecionadas. Os modelos têm em conta:

• Demografia do consumidor
• Tempo histórico e previsto
• Envios anteriores
• Devoluções de produtos
• Eventos especiais

O objetivo de otimizar o estoque representou um componente importante do projeto e o cliente percebeu um aumento significativo nas vendas nos primeiros testes de campo. Além disso, a equipe viu uma redução de 40% na previsão de erro percentual absoluto médio (MAPE) quando comparado com um modelo de linha de base média histórica.

Uma parte fundamental do projeto foi descobrir como escalar o fluxo de trabalho de ciência de dados do estudo piloto para um nível de produção. Esse fluxo de trabalho de nível de produção exigia que a equipe CSE:

• Desenvolver modelos para muitas regiões.
• Atualizar e monitorar continuamente o desempenho dos modelos.
• Facilite a colaboração entre as equipes de dados e engenharia.

O fluxo de trabalho típico de ciência de dados hoje está mais próximo de um ambiente de laboratório único do que um fluxo de trabalho de produção. Um ambiente para cientistas de dados deve ser adequado para:

• Prepare os dados.
• Experimente diferentes modelos.
• Sintonize os hiperparâmetros.
• Crie um ciclo build-test-evaluate-refine.

A maioria das ferramentas usadas para essas tarefas tem finalidades específicas e não é adequada para automação. Em uma operação de aprendizado de máquina de nível de produção, deve haver mais consideração ao gerenciamento do ciclo de vida do aplicativo e ao DevOps.

A equipe CSE ajudou o cliente a escalar a operação para níveis de produção. Eles implementaram vários aspetos dos recursos de integração contínua e entrega contínua (CI/CD) e abordaram problemas como observabilidade e integração com os recursos do Azure. Durante a implementação, a equipe descobriu lacunas na orientação MLOps existente. Essas lacunas precisavam ser preenchidas para que o MLOps fosse melhor compreendido e aplicado em escala.

Compreender as práticas de MLOps ajuda as organizações a garantir que os modelos de aprendizado de máquina que o sistema produz sejam modelos de qualidade de produção que melhoram o desempenho dos negócios. Quando o MLOps é implementado, a organização não precisa mais gastar tanto tempo com detalhes de baixo nível relacionados à infraestrutura e ao trabalho de engenharia necessários para desenvolver e executar modelos de aprendizado de máquina para operações de nível de produção. A implementação de MLOps também ajuda as comunidades de ciência de dados e engenharia de software a aprender a trabalhar juntas para fornecer um sistema pronto para produção.

A equipe do CSE usou este projeto para atender às necessidades da comunidade de aprendizado de máquina, abordando questões como o desenvolvimento de um modelo de maturidade MLOps. Esses esforços tinham como objetivo melhorar a adoção de MLOps, compreendendo os desafios típicos dos principais atores no processo de MLOps.

Cenários técnicos e de envolvimento

O cenário de engajamento discute os desafios do mundo real que a equipe CSE teve que resolver. O cenário técnico define os requisitos para criar um ciclo de vida de MLOps que seja tão confiável quanto o ciclo de vida de DevOps bem estabelecido.

Cenário de envolvimento

O cliente entrega os produtos diretamente nos pontos de venda do mercado de retalho num horário regular. Cada ponto de venda varia em seus padrões de uso de produtos, portanto, o estoque de produtos precisa variar em cada entrega semanal. Maximizar as vendas e minimizar os retornos de produtos e as oportunidades de vendas perdidas são os objetivos das metodologias de previsão de demanda que o cliente utiliza. Este projeto centrou-se na utilização de aprendizagem automática para melhorar as previsões.

A equipa do CSE dividiu o projeto em duas fases. A fase 1 concentrou-se no desenvolvimento de modelos de aprendizagem automática para apoiar um estudo piloto baseado no terreno sobre a eficácia da previsão de aprendizagem automática para uma região de vendas selecionada. O sucesso da Fase 1 levou à Fase 2, na qual a equipe ampliou o estudo piloto inicial de um grupo mínimo de modelos que suportavam uma única região geográfica para um conjunto de modelos sustentáveis de nível de produção para todas as regiões de vendas do cliente. Uma consideração principal para a solução ampliada foi a necessidade de acomodar o grande número de regiões geográficas e seus pontos de venda locais. A equipe dedicou os modelos de aprendizado de máquina a grandes e pequenos pontos de venda em cada região.

O estudo piloto de Fase 1 determinou que um modelo dedicado aos pontos de venda de uma região poderia usar o histórico de vendas locais, demografia local, clima e eventos especiais para otimizar a previsão de demanda para os pontos de venda na região. Quatro modelos de previsão de aprendizado de máquina de conjunto atenderam pontos de venda de mercado em uma única região. Os modelos processaram os dados em lotes semanais. Além disso, a equipe desenvolveu dois modelos de linha de base usando dados históricos para comparação.

Para a primeira versão da solução ampliada da Fase 2, a equipe CSE selecionou 14 regiões geográficas para participar, incluindo pequenos e grandes pontos de venda. Eles usaram mais de 50 modelos de previsão de aprendizado de máquina. A equipe esperava um maior crescimento do sistema e um aperfeiçoamento contínuo dos modelos de aprendizado de máquina. Rapidamente ficou claro que essa solução de aprendizado de máquina de maior escala só é sustentável se for baseada nos princípios de melhores práticas de DevOps para o ambiente de aprendizado de máquina.

Environment	Região do Mercado	Formato	Modelos	Subdivisão do modelo	Descrição do modelo
Ambiente de desenvolvimento	Cada mercado/região geográfica (por exemplo, Norte do Texas)	Lojas de grande formato (supermercados, grandes lojas de caixa, e assim por diante)	Dois modelos de conjunto	Produtos de movimento lento	Lento e rápido ambos têm um conjunto de um modelo de regressão linear de operador de encolhimento e seleção menos absoluto (LASSO) e uma rede neural com incorporações categóricas
				Produtos de movimento rápido	Lenta e rápida ambas têm um conjunto de um modelo de regressão linear LASSO e uma rede neural com incorporações categóricas
			Um modelo de conjunto	N/A	Média histórica
		Lojas de pequeno formato (farmácias, lojas de conveniência e assim por diante)	Dois modelos de conjunto	Produtos de movimento lento	Lenta e rápida ambas têm um conjunto de um modelo de regressão linear LASSO e uma rede neural com incorporações categóricas
				Produtos de movimento rápido	Lento e ambos têm um conjunto de um modelo de regressão linear LASSO e uma rede neural com incorporações categóricas
			Um modelo de conjunto	N/A	Média histórica
	O mesmo que acima para mais 13 regiões geográficas
O mesmo que acima para o ambiente de prod

O processo MLOps forneceu uma estrutura para o sistema escalonado que abordou o ciclo de vida completo dos modelos de aprendizado de máquina. A estrutura inclui desenvolvimento, teste, implantação, operação e monitoramento. Satisfaz as necessidades de um processo clássico de CI/CD. No entanto, devido à sua relativa imaturidade em comparação com o DevOps, tornou-se evidente que a orientação MLOps existente tinha lacunas. A equipe do projeto trabalhou para preencher algumas dessas lacunas. Eles queriam fornecer um modelo de processo funcional que garantisse a viabilidade da solução de aprendizado de máquina ampliada.

O processo de MLOps que foi desenvolvido a partir deste projeto deu um passo significativo no mundo real para mover MLOps para um nível mais alto de maturidade e viabilidade. O novo processo é diretamente aplicável a outros projetos de machine learning. A equipe do CSE usou o que aprendeu para construir um rascunho de um modelo de maturidade MLOps que qualquer pessoa pode aplicar a outros projetos de aprendizado de máquina.

Cenário técnico

MLOps, também conhecido como DevOps para aprendizado de máquina, é um termo abrangente que engloba filosofias, práticas e tecnologias relacionadas à implementação de ciclos de vida de aprendizado de máquina em um ambiente de produção. Ainda é um conceito relativamente novo. Houve muitas tentativas de definir o que é MLOps e muitas pessoas questionaram se o MLOps pode subsumir tudo, desde como os cientistas de dados preparam os dados até como eles finalmente entregam, monitoram e avaliam os resultados do aprendizado de máquina. Embora o DevOps tenha tido anos para desenvolver um conjunto de práticas fundamentais, o MLOps ainda está no início de seu desenvolvimento. À medida que evolui, descobrimos os desafios de reunir duas disciplinas que muitas vezes operam com diferentes conjuntos de habilidades e prioridades: engenharia de software/operações e ciência de dados.

A implementação de MLOps em ambientes de produção do mundo real tem desafios únicos que devem ser superados. As equipes podem usar o Azure para dar suporte a padrões MLOps. O Azure também pode fornecer aos clientes serviços de gestão e orquestração de ativos para gerir eficazmente o ciclo de vida da aprendizagem automática. Os serviços do Azure são a base para a solução MLOps que descrevemos neste artigo.

Requisitos do modelo de aprendizado de máquina

Grande parte do trabalho durante o estudo de campo piloto da Fase 1 foi a criação dos modelos de aprendizado de máquina que a equipe CSE aplicou às grandes e pequenas lojas de varejo em uma única região. Requisitos notáveis para os modelos incluíram:

• Utilização do serviço Azure Machine Learning.

• Modelos experimentais iniciais que foram desenvolvidos em notebooks Jupyter e implementados em Python.

  Nota

  As equipes usavam a mesma abordagem de aprendizado de máquina para lojas grandes e pequenas, mas os dados de treinamento e pontuação dependiam do tamanho da loja.

• Dados que requerem preparação para o consumo do modelo.

• Dados que são processados em lote e não em tempo real.

• Retreinamento do modelo sempre que o código ou os dados forem alterados ou o modelo ficar obsoleto.

• Visualização do desempenho do modelo em painéis do Power BI.

• Desempenho do modelo na pontuação que é considerado significativo quando MAPE <= 45% quando comparado com um modelo de linha de base média histórica.

Requisitos de MLOps

A equipe teve que atender a vários requisitos-chave para ampliar a solução a partir do estudo de campo piloto de Fase 1, no qual apenas alguns modelos foram desenvolvidos para uma única região de vendas. A fase 2 implementou modelos personalizados de aprendizado de máquina para várias regiões. A implementação incluiu:

• Processamento semanal em lote para grandes e pequenas lojas em cada região para retreinar os modelos com novos conjuntos de dados.

• Aperfeiçoamento contínuo dos modelos de aprendizagem automática.

• Integração do processo de desenvolvimento/teste/pacote/teste/implantação comum ao CI/CD em um ambiente de processamento semelhante ao DevOps para MLOps.

  Nota

  Isso representa uma mudança na forma como cientistas de dados e engenheiros de dados geralmente trabalharam no passado.

• Um modelo exclusivo que representava cada região para lojas grandes e pequenas com base no histórico da loja, demografia e outras variáveis importantes. O modelo teve que processar todo o conjunto de dados para minimizar o risco de erro de processamento.

• A capacidade de expandir inicialmente para suportar 14 regiões de vendas com planos de expansão ainda maior.

• Planos para modelos adicionais para previsão de longo prazo para regiões e outros clusters de lojas.

Solução de modelo de aprendizado de máquina

O ciclo de vida do aprendizado de máquina, também conhecido como ciclo de vida da ciência de dados, se encaixa aproximadamente no seguinte fluxo de processo de alto nível:

Implantar modelo aqui pode representar qualquer uso operacional do modelo de aprendizado de máquina validado. Em comparação com o DevOps, o MLOps apresenta o desafio adicional de integrar o ciclo de vida do aprendizado de máquina no processo típico de CI/CD.

O ciclo de vida da ciência de dados não segue o ciclo de vida típico de desenvolvimento de software. Ele inclui o uso do Azure Machine Learning para treinar e pontuar os modelos, portanto, essas etapas tiveram que ser incluídas na automação de CI/CD.

O processamento em lote de dados é a base da arquitetura. Dois pipelines do Azure Machine Learning são centrais para o processo, um para treinamento e outro para pontuação. Este diagrama mostra a metodologia de ciência de dados que foi usada para a fase inicial do projeto cliente:

A equipa testou vários algoritmos. Eles finalmente escolheram um projeto de conjunto de um modelo de regressão linear LASSO e uma rede neural com incorporações categóricas. A equipa utilizou o mesmo modelo, definido pelo nível de produto que o cliente podia armazenar no local, tanto para grandes como para pequenas lojas. A equipe ainda subdividiu o modelo em produtos de movimento rápido e lento.

Os cientistas de dados treinam os modelos de aprendizado de máquina quando a equipe libera um novo código e quando novos dados estão disponíveis. Os treinos normalmente acontecem semanalmente. Consequentemente, cada execução de processamento envolve uma grande quantidade de dados. Como a equipe coleta os dados de muitas fontes em diferentes formatos, é necessário condicionar a colocação dos dados em um formato consumível antes que os cientistas de dados possam processá-los. O condicionamento de dados requer um esforço manual significativo e a equipe CSE o identificou como um candidato primário para automação.

Como mencionado, os cientistas de dados desenvolveram e aplicaram os modelos experimentais do Azure Machine Learning a uma única região de vendas no estudo de campo piloto de Fase 1 para avaliar a utilidade dessa abordagem de previsão. A equipe do CSE julgou que o aumento das vendas para as lojas no estudo piloto foi significativo. Este sucesso justificou a aplicação da solução a níveis máximos de produção na Fase 2, começando por 14 regiões geográficas e milhares de lojas. A equipe poderia então usar o mesmo padrão para adicionar outras regiões.

O modelo piloto serviu como base para a solução ampliada, mas a equipe CSE sabia que o modelo precisava de mais aperfeiçoamento em uma base contínua para melhorar seu desempenho.

Solução MLOps

À medida que os conceitos de MLOps amadurecem, as equipes geralmente descobrem desafios ao unir as disciplinas de ciência de dados e DevOps. A razão é que os principais intervenientes nas disciplinas, engenheiros de software e cientistas de dados, operam com diferentes conjuntos de competências e prioridades.

Mas há semelhanças a desenvolver. O MLOps, como o DevOps, é um processo de desenvolvimento implementado por uma cadeia de ferramentas. A cadeia de ferramentas MLOps inclui coisas como:

• Controlo de versões
• Análise de código
• Automação de construção
• Integração contínua
• Estruturas de teste e automação
• Políticas de conformidade integradas em pipelines de CI/CD
• Automação da implantação
• Monitorização
• Recuperação após desastre e elevada disponibilidade
• Gestão de embalagens e contentores

Como observado acima, a solução aproveita as diretrizes de DevOps existentes, mas é aumentada para criar uma implementação de MLOps mais madura que atenda às necessidades do cliente e da comunidade de ciência de dados. O MLOps baseia-se nas diretrizes de DevOps com estes requisitos adicionais:

• O controle de versão de dados e modelos não é o mesmo que o controle de versão de código: deve haver controle de versão de conjuntos de dados à medida que o esquema e os dados de origem são alterados.
• Requisitos da trilha de auditoria digital: acompanhe todas as alterações ao lidar com código e dados do cliente.
• Generalização: Os modelos são diferentes do código para reutilização, uma vez que os cientistas de dados devem ajustar os modelos com base em dados de entrada e cenário. Para reutilizar um modelo para um novo cenário, talvez seja necessário ajustar/transferir/aprender sobre ele. Você precisa do pipeline de treinamento.
• Modelos obsoletos: Os modelos tendem a decair com o tempo e você precisa da capacidade de retreiná-los sob demanda para garantir que permaneçam relevantes na produção.

Desafios do MLOps

Padrão MLOps imaturo

O padrão para MLOps ainda está evoluindo. Uma solução é normalmente construída do zero e feita para atender às necessidades de um cliente ou usuário específico. A equipe do CSE reconheceu essa lacuna e procurou usar as melhores práticas de DevOps neste projeto. Eles aumentaram o processo de DevOps para atender aos requisitos adicionais do MLOps. O processo que a equipe desenvolveu é um exemplo viável de como um padrão MLOps deve parecer.

Diferenças nos conjuntos de competências

Engenheiros de software e cientistas de dados trazem conjuntos de habilidades únicas para a equipe. Esses diferentes conjuntos de habilidades podem dificultar encontrar uma solução que atenda às necessidades de todos. É importante construir um fluxo de trabalho bem compreendido para a entrega do modelo, desde a experimentação até a produção. Os membros da equipe devem compartilhar um entendimento de como podem integrar as alterações no sistema sem interromper o processo MLOps.

Gerenciando vários modelos

Muitas vezes, há a necessidade de vários modelos para resolver cenários difíceis de aprendizado de máquina. Um dos desafios do MLOps é gerenciar esses modelos, incluindo:

• Ter um esquema de versionamento coerente.
• Avaliando e monitorando continuamente todos os modelos.

A linhagem rastreável de código e dados também é necessária para diagnosticar problemas de modelo e criar modelos reproduzíveis. Os painéis personalizados podem entender o desempenho dos modelos implantados e indicar quando intervir. A equipe criou esses painéis para este projeto.

Necessidade de condicionamento de dados

Os dados utilizados com estes modelos provêm de muitas fontes públicas e privadas. Como os dados originais estão desorganizados, é impossível para o modelo de aprendizado de máquina consumi-los em seu estado bruto. Os cientistas de dados devem condicionar os dados em um formato padrão para o consumo de modelos de aprendizado de máquina.

Grande parte do teste de campo piloto se concentrou em condicionar os dados brutos para que o modelo de aprendizado de máquina pudesse processá-los. Em um sistema MLOps, a equipe deve automatizar esse processo e acompanhar as saídas.

Modelo de maturidade de MLOps

O objetivo do modelo de maturidade MLOps é esclarecer os princípios e práticas e identificar lacunas em uma implementação MLOps. Também é uma maneira de mostrar a um cliente como aumentar incrementalmente sua capacidade de MLOps em vez de tentar fazer tudo de uma vez. O cliente deve usá-lo como um guia para:

• Estimar o escopo do trabalho para o projeto.
• Estabeleça critérios de sucesso.
• Identifique os resultados.

O modelo de maturidade MLOps define cinco níveis de capacidade técnica:

Level	Description
0	Sem Ops
1	DevOps, mas sem MLOps
2	Formação automatizada
3	Implantação automatizada de modelos
4	Operações automatizadas (MLOps completo)

Para obter a versão atual do modelo de maturidade MLOps, consulte o artigo Modelo de maturidade MLOps.

Definição do processo MLOps

O MLOps inclui todas as atividades, desde a aquisição de dados brutos até a entrega da saída do modelo, também conhecida como pontuação:

• Condicionamento de dados
• Preparação de modelos
• Teste e avaliação de modelos
• Definição de construção e pipeline
• Pipeline de versão
• Implementação
• Classificação

Processo básico de aprendizado de máquina

O processo básico de aprendizado de máquina se assemelha ao desenvolvimento de software tradicional, mas há diferenças significativas. Este diagrama ilustra as principais etapas do processo de aprendizado de máquina:

A fase Experimento é exclusiva do ciclo de vida da ciência de dados, que reflete como os cientistas de dados tradicionalmente fazem seu trabalho. Ele difere de como os desenvolvedores de código fazem seu trabalho. O diagrama a seguir ilustra esse ciclo de vida com mais detalhes.

A integração desse processo de desenvolvimento de dados no MLOps representa um desafio. Aqui você vê o padrão que a equipe usou para integrar o processo em um formulário que o MLOps pode suportar:

O papel do MLOps é criar um processo coordenado que possa suportar eficientemente os ambientes de CI/CD em grande escala que são comuns em sistemas de nível de produção. Conceitualmente, o modelo MLOps deve incluir todos os requisitos do processo, desde a experimentação até a pontuação.

A equipe CSE refinou o processo MLOps para atender às necessidades específicas do cliente. A necessidade mais notável foi o processamento em lote em vez do processamento em tempo real. À medida que a equipa desenvolvia o sistema escalonado, identificava e resolvia algumas deficiências. A mais significativa dessas deficiências levou ao desenvolvimento de uma ponte entre o Azure Data Factory e o Azure Machine Learning, que a equipe implementou usando um conector interno no Azure Data Factory. Eles criaram esse conjunto de componentes para facilitar o acionamento e o monitoramento de status necessários para fazer a automação do processo funcionar.

Outra mudança fundamental foi que os cientistas de dados precisavam da capacidade de exportar código experimental de notebooks Jupyter para o processo de implantação de MLOps, em vez de acionar treinamento e pontuação diretamente.

Aqui está o conceito final do modelo de processo MLOps:

Fluxo de processo MLOps

O diagrama a seguir descreve como aplicar fluxos de trabalho de desenvolvimento e lançamento de CI/CD ao ciclo de vida do aprendizado de máquina:

• Quando uma solicitação pull (PR) é criada a partir de uma ramificação de recurso, o pipeline executa testes de validação de código para validar a qualidade do código por meio de testes de unidade e testes de qualidade de código. Para validar a qualidade a montante, o pipeline também executa testes básicos de validação de modelo para validar as etapas de treinamento e pontuação de ponta a ponta com um conjunto de amostra de dados simulados.
• Quando o PR é fundido na ramificação principal, o pipeline de CI executará os mesmos testes de validação de código e testes de validação de modelo básico com maior época. O pipeline empacotará os artefatos, que incluem o código e os binários, para serem executados no ambiente de aprendizado de máquina.
• Depois que os artefatos estiverem disponíveis, um pipeline de CD de validação de modelo será acionado. Ele executa a validação de ponta a ponta no ambiente de aprendizado de máquina de desenvolvimento. É publicado um mecanismo de pontuação. Para um cenário de pontuação em lote, um pipeline de pontuação é publicado no ambiente de aprendizado de máquina e acionado para produzir resultados. Se quiser usar um cenário de pontuação em tempo real, você pode publicar um aplicativo Web ou implantar um contêiner.
• Depois que um marco é criado e mesclado na ramificação de versão, o mesmo pipeline de CI e pipeline de CD de validação de modelo são acionados. Desta vez, eles são executados contra o código da ramificação de lançamento.

Você pode considerar o fluxo de dados do processo MLOps mostrado acima como uma estrutura de arquétipo para projetos que fazem escolhas arquitetônicas semelhantes.

Testes de validação de código

Os testes de validação de código para aprendizado de máquina se concentram na validação da qualidade da base de código. É o mesmo conceito de qualquer projeto de engenharia que tenha testes de qualidade de código (linting), testes de unidade e medições de cobertura de código.

Testes básicos de validação do modelo

A validação do modelo normalmente refere-se à validação de todas as etapas do processo de ponta a ponta necessárias para produzir um modelo de aprendizado de máquina válido. Inclui etapas como:

• Validação de dados: garante que os dados de entrada sejam válidos.
• Validação de treinamento: Garante que o modelo possa ser treinado com sucesso.
• Validação de pontuação: Garante que a equipe possa usar com sucesso o modelo treinado para pontuar com os dados de entrada.

Executar esse conjunto completo de etapas no ambiente de aprendizado de máquina é caro e demorado. Como resultado, a equipe fez testes básicos de validação de modelo localmente em uma máquina de desenvolvimento. Ele executou as etapas acima e usou o seguinte:

• Conjunto de dados de teste local: um pequeno conjunto de dados, geralmente ofuscado, que faz check-in no repositório e é consumido como fonte de dados de entrada.
• Sinalizador local: um sinalizador ou argumento no código do modelo que indica que o código pretende que o conjunto de dados seja executado localmente. O sinalizador diz ao código para ignorar qualquer chamada para o ambiente de aprendizado de máquina.

Este objetivo destes testes de validação não é avaliar o desempenho do modelo treinado. Em vez disso, é para validar que o código para o processo de ponta a ponta é de boa qualidade. Ele garante a qualidade do código que é empurrado para cima, como a incorporação de testes de validação de modelo na compilação de RP e CI. Ele também possibilita que engenheiros e cientistas de dados coloquem pontos de interrupção no código para fins de depuração.

Pipeline de CD de validação de modelo

O objetivo do pipeline de validação de modelo é validar o treinamento de modelo de ponta a ponta e as etapas de pontuação no ambiente de aprendizado de máquina com dados reais. Qualquer modelo treinado que for produzido será adicionado ao registro do modelo e marcado, para aguardar a promoção após a conclusão da validação. Para previsão de lote, a promoção pode ser a publicação de um pipeline de pontuação que usa essa versão do modelo. Para pontuação em tempo real, o modelo pode ser marcado para indicar que foi promovido.

Pipeline de CD de pontuação

O pipeline de CD de pontuação é aplicável para o cenário de inferência em lote, onde o mesmo orquestrador de modelo usado para validação de modelo aciona o pipeline de pontuação publicado.

Ambientes de desenvolvimento vs. produção

É uma boa prática separar o ambiente de desenvolvimento (dev) do ambiente de produção (prod). A separação permite que o sistema acione o pipeline de CD de validação do modelo e o pipeline de CD de pontuação em diferentes horários. Para o fluxo MLOps descrito, os pipelines destinados à ramificação principal são executados no ambiente de desenvolvimento e o pipeline que tem como alvo a ramificação de liberação é executado no ambiente prod.

Alterações de código vs. alterações de dados

As seções anteriores lidam principalmente com como lidar com alterações de código do desenvolvimento para o lançamento. No entanto, as alterações de dados devem seguir o mesmo rigor que as alterações de código para fornecer a mesma qualidade de validação e consistência na produção. Com um gatilho de alteração de dados ou um gatilho de temporizador, o sistema pode acionar o pipeline de CD de validação de modelo e o pipeline de CD de pontuação do orquestrador de modelos para executar o mesmo processo que é executado para alterações de código no ambiente de prod de ramificação de versão.

Personas e papéis MLOps

Um requisito fundamental para qualquer processo MLOps é que ele atenda às necessidades dos muitos usuários do processo. Para fins de design, considere esses usuários como personas individuais. Para este projeto, a equipa identificou as seguintes personas:

• Cientista de dados: Cria o modelo de aprendizado de máquina e seus algoritmos.
• Engenheira
  • Engenheiro de dados: lida com condicionamento de dados.
  • Engenheiro de software: lida com a integração do modelo no pacote de ativos e no fluxo de trabalho de CI/CD.
• Operações ou TI: Supervisiona as operações do sistema.
• Stakeholders do negócio: Preocupado com as previsões feitas pelo modelo de machine learning e como elas ajudam o negócio.
• Usuário final de dados: consome a saída do modelo de alguma forma que ajuda na tomada de decisões de negócios.

A equipa teve de abordar três conclusões principais dos estudos de persona e papéis:

• Os cientistas de dados e os engenheiros têm uma incompatibilidade de abordagem e competências no seu trabalho. Facilitar a colaboração entre o cientista de dados e o engenheiro é uma consideração importante para o projeto do fluxo de processo MLOps. Requer novas aquisições de competências por parte de todos os membros da equipa.
• Há uma necessidade de unificar todas as personas principais sem alienar ninguém. Uma maneira de fazer isso é:
  • Certifique-se de que eles entendam o modelo conceitual para MLOps.
  • Concorde com os membros da equipe que trabalharão juntos.
  • Estabelecer diretrizes de trabalho para alcançar objetivos comuns.
• Se as partes interessadas da empresa e o usuário final de dados precisarem de uma maneira de interagir com a saída de dados dos modelos, uma interface do usuário amigável é a solução padrão.

Outras equipes certamente se depararão com problemas semelhantes em outros projetos de aprendizado de máquina à medida que aumentam a escala para uso em produção.

Arquitetura da solução MLOps

Arquitetura lógica

Os dados vêm de muitas fontes em muitos formatos diferentes, por isso são condicionados antes de serem inseridos no data lake. O condicionamento é feito usando microsserviços que operam como Azure Functions. Os clientes personalizam os microsserviços para ajustar as fontes de dados e transformá-los em um formato csv padronizado que os pipelines de treinamento e pontuação consomem.

Arquitetura do sistema

Arquitetura de processamento em lote

A equipe desenvolveu o projeto arquitetônico para suportar um esquema de processamento de dados em lote. Existem alternativas, mas tudo o que for usado deve suportar processos MLOps. O uso completo dos serviços disponíveis do Azure era um requisito de design. O diagrama a seguir mostra a arquitetura:

Descrição geral da solução

O Azure Data Factory faz o seguinte:

• Aciona uma função do Azure para iniciar a ingestão de dados e uma execução do pipeline do Azure Machine Learning.
• Inicia uma função durável para sondar o pipeline do Azure Machine Learning para conclusão.

Os painéis personalizados no Power BI exibem os resultados. Outros painéis do Azure que estão conectados ao Azure SQL, Azure Monitor e App Insights por meio do OpenCensus Python SDK, rastreiam os recursos do Azure. Esses painéis fornecem informações sobre a integridade do sistema de aprendizado de máquina. Eles também produzem dados que o cliente usa para previsão de pedidos de produtos.

Orquestração de modelos

A orquestração do modelo segue estas etapas:

1. Quando um PR é enviado, o DevOps aciona um pipeline de validação de código.
2. O pipeline executa testes de unidade, testes de qualidade de código e testes de validação de modelo.
3. Quando mesclados na ramificação principal, os mesmos testes de validação de código são executados e o DevOps empacota os artefatos.
4. A coleta de artefatos do DevOps aciona o Aprendizado de Máquina do Azure para:
   1. Validação de dados.
   2. Validação da formação.
   3. Validação de pontuação.
5. Após a conclusão da validação, o pipeline de pontuação final é executado.
6. Alterar dados e enviar um novo PR aciona o pipeline de validação novamente, seguido pelo pipeline de pontuação final.

Permitir a experimentação

Como mencionado, o ciclo de vida tradicional de aprendizado de máquina de ciência de dados não suporta o processo MLOps sem modificação. Ele usa diferentes tipos de ferramentas manuais e experimentação, validação, empacotamento e transferência de modelo que não podem ser facilmente dimensionados para um processo de CI/CD eficaz. O MLOps exige um alto nível de automação de processos. Quer um novo modelo de aprendizagem automática esteja a ser desenvolvido ou um antigo seja modificado, é necessário automatizar o ciclo de vida do modelo de aprendizagem automática. No projeto de Fase 2, a equipe usou o Azure DevOps para orquestrar e republicar pipelines do Azure Machine Learning para tarefas de treinamento. A ramificação principal de longa duração realiza testes básicos de modelos e envia versões estáveis através da ramificação de liberação de longa duração.

O controle do código-fonte torna-se uma parte importante desse processo. O Git é o sistema de controle de versão usado para rastrear o código do notebook e do modelo. Ele também suporta automação de processos. O fluxo de trabalho básico implementado para o controle do código-fonte aplica os seguintes princípios:

• Use o controle de versão formal para códigos e conjuntos de dados.
• Use uma ramificação para o desenvolvimento de novos códigos até que o código seja totalmente desenvolvido e validado.
• Depois que o novo código é validado, ele pode ser mesclado na ramificação principal.
• Para uma versão, é criada uma ramificação com versão permanente separada da ramificação principal.
• Use versões e controle de origem para os conjuntos de dados que foram condicionados para treinamento ou consumo, para que você possa manter a integridade de cada conjunto de dados.
• Use o controle do código-fonte para acompanhar seus experimentos do Jupyter Notebook.

Integração com fontes de dados

Os cientistas de dados usam muitas fontes de dados brutos e conjuntos de dados processados para experimentar diferentes modelos de aprendizado de máquina. O volume de dados em um ambiente de produção pode ser avassalador. Para que os cientistas de dados experimentem modelos diferentes, eles precisam usar ferramentas de gerenciamento como o Azure Data Lake. O requisito de identificação formal e controle de versão se aplica a todos os dados brutos, conjuntos de dados preparados e modelos de aprendizado de máquina.

No projeto, os cientistas de dados condicionaram os seguintes dados para entrada no modelo:

• Dados históricos semanais de envios desde janeiro de 2017
• Dados meteorológicos diários históricos e previstos para cada código postal
• Dados do comprador para cada ID de loja

Integração com controle do código-fonte

Para fazer com que os cientistas de dados apliquem as melhores práticas de engenharia, é necessário integrar convenientemente as ferramentas que eles usam com sistemas de controle de código-fonte, como o GitHub. Essa prática permite o controle de versão do modelo de aprendizado de máquina, a colaboração entre os membros da equipe e a recuperação de desastres caso as equipes sofram uma perda de dados ou uma interrupção do sistema.

Suporte a conjunto de modelos

O desenho do modelo neste projeto foi um modelo de conjunto. Ou seja, os cientistas de dados usaram muitos algoritmos no design do modelo final. Neste caso, os modelos usaram o mesmo design de algoritmo básico. A única diferença foi que eles usaram dados de treinamento e pontuação diferentes. Os modelos utilizaram a combinação de um algoritmo de regressão linear LASSO e uma rede neural.

A equipe explorou, mas não implementou, uma opção para levar o processo adiante até o ponto em que suportaria ter muitos modelos em tempo real rodando em produção para atender a uma determinada solicitação. Esta opção pode acomodar o uso de modelos de conjunto em testes A/B e experimentos intercalados.

Interfaces de utilizador final

A equipe desenvolveu interfaces de usuário final para observabilidade, monitoramento e instrumentação. Como mencionado, os painéis exibem visualmente os dados do modelo de aprendizado de máquina. Esses painéis mostram os seguintes dados em um formato amigável:

• Etapas do pipeline, incluindo o pré-processamento dos dados de entrada.
• Para monitorar a integridade do processamento do modelo de aprendizado de máquina:
  • Quais métricas você coleta do seu modelo implantado?
    • MAPE: Erro percentual absoluto médio, a métrica chave para acompanhar o desempenho geral. (Direcione um valor MAPE de <= 0,45 para cada modelo.)
    • RMSE 0: Erro quadrático médio (RMSE) quando o valor de destino real = 0.
    • RMSE All: RMSE em todo o conjunto de dados.
  • Como você avalia se seu modelo está tendo o desempenho esperado na produção?
  • Existe uma maneira de saber se os dados de produção estão se desviando demais dos valores esperados?
  • O seu modelo tem um desempenho fraco na produção?
  • Você tem um estado de failover?
• Acompanhe a qualidade dos dados processados.
• Exiba a pontuação/previsões produzidas pelo modelo de aprendizado de máquina.

O aplicativo preenche os painéis de acordo com a natureza dos dados e como ele processa e analisa os dados. Como tal, a equipe deve projetar o layout exato dos painéis para cada caso de uso. Aqui estão dois painéis de exemplo:

Os painéis foram projetados para fornecer informações prontamente utilizáveis para consumo pelo usuário final das previsões do modelo de aprendizado de máquina.

Componentes

• Azure Machine Learning
  • Computação do Azure Machine Learning
  • Azure Machine Learning Pipelines
  • Azure Machine Learning Model Registry
• Armazenamento de Blobs do Azure
• Azure Data Lake Storage
• Azure Pipelines
• Fábrica de Dados do Azure
• Azure Functions para Python
• Azure Monitor
  • Registos
  • Application Insights
• Base de Dados SQL do Azure
• Azure Dashboards
• Power BI

Considerações

Aqui você encontrará uma lista de considerações para explorar. Eles são baseados nas lições que a equipe do CSE aprendeu durante o projeto.

Considerações ambientais

• Os cientistas de dados desenvolvem a maioria de seus modelos de aprendizado de máquina usando Python, muitas vezes começando com notebooks Jupyter. Pode ser um desafio implementar esses notebooks como código de produção. Os notebooks Jupyter são mais uma ferramenta experimental, enquanto os scripts Python são mais apropriados para produção. As equipes geralmente precisam gastar tempo refatoração de código de criação de modelo em scripts Python.
• Conscientize os clientes que são novos em DevOps e aprendizado de máquina de que experimentação e produção exigem rigor diferente, por isso é uma boa prática separar os dois.
• Ferramentas como o Azure Machine Learning Visual Designer ou o AutoML podem ser eficazes para tirar modelos básicos do papel, enquanto o cliente aprimora as práticas padrão de DevOps para aplicar ao restante da solução.
• O Azure DevOps tem plug-ins que podem ser integrados ao Azure Machine Learning para ajudar a acionar etapas de pipeline. O repositório MLOpsPython tem alguns exemplos desses pipelines.
• O aprendizado de máquina geralmente requer máquinas poderosas de unidade de processamento gráfico (GPU) para treinamento. Se o cliente ainda não tiver esse hardware disponível, os clusters de computação do Azure Machine Learning podem fornecer um caminho eficaz para provisionar rapidamente hardware poderoso e econômico que é dimensionado automaticamente. Se um cliente tiver necessidades avançadas de segurança ou monitoramento, há outras opções, como VMs padrão, Databricks ou computação local.
• Para que um cliente seja bem-sucedido, suas equipes de construção de modelos (cientistas de dados) e equipes de implantação (engenheiros de DevOps) precisam ter um canal de comunicação forte. Eles podem conseguir isso com reuniões diárias de stand-up ou um serviço formal de bate-papo on-line. Ambas as abordagens ajudam na integração de seus esforços de desenvolvimento em uma estrutura MLOps.

Considerações sobre a preparação de dados

• A solução mais simples para usar o Azure Machine Learning é armazenar dados em uma solução de armazenamento de dados com suporte. Ferramentas como o Azure Data Factory são eficazes para canalizar dados de e para esses locais em uma programação.

• É importante que os clientes capturem frequentemente dados adicionais de retreinamento para manter seus modelos atualizados. Se eles ainda não tiverem um pipeline de dados, criar um será uma parte importante da solução geral. Usar uma solução como Conjuntos de Dados no Azure Machine Learning pode ser útil para o controle de versão de dados para ajudar na rastreabilidade de modelos.

Considerações sobre o modelo de treinamento e avaliação

• É esmagador para um cliente que está apenas começando em sua jornada de aprendizado de máquina tentar implementar um pipeline completo de MLOps. Se necessário, eles podem facilitar usando o Aprendizado de Máquina do Azure para acompanhar execuções de experimentos e usando a computação do Aprendizado de Máquina do Azure como destino de treinamento. Essas opções podem criar uma solução de barreira de entrada menor para começar a integrar os serviços do Azure.

• Passar de um experimento de notebook para scripts repetíveis é uma transição difícil para muitos cientistas de dados. Quanto mais cedo você conseguir que eles escrevam seu código de treinamento em scripts Python, mais fácil será para eles começarem a versionar seu código de treinamento e habilitar o retreinamento.

  Esse não é o único método possível. O Databricks suporta o agendamento de notebooks como trabalhos. Mas, com base na experiência atual do cliente, essa abordagem é difícil de instrumentar com práticas completas de DevOps devido às limitações de teste.

• Também é importante entender quais métricas estão sendo usadas para considerar um modelo um sucesso. A precisão por si só muitas vezes não é boa o suficiente para determinar o desempenho geral de um modelo em relação a outro.

Considerações sobre computação

• Os clientes devem considerar o uso de contêineres para padronizar seus ambientes de computação. Quase todos os destinos de computação do Azure Machine Learning dão suporte ao Docker. Ter um contêiner lidando com as dependências pode reduzir significativamente o atrito, especialmente se a equipe usar muitos destinos de computação.

Considerações sobre o modelo de serviço

• O SDK do Azure Machine Learning fornece uma opção para implantar diretamente no Serviço Kubernetes do Azure a partir de um modelo registrado, criando limites sobre quais segurança/métricas estão em vigor. Você pode tentar encontrar uma solução mais fácil para os clientes testarem seu modelo, mas é melhor desenvolver uma implantação mais robusta no AKS para cargas de trabalho de produção.

Próximos passos

• Saiba mais sobre MLOps
• MLOps no Azure
• Visualizações do Azure Monitor
• Ciclo de vida do aprendizado de máquina
• Extensão do Azure DevOps Machine Learning
• CLI do Azure Machine Learning
• Acionar aplicações, processos ou fluxos de trabalho CI/CD com base em eventos do Azure Machine Learning
• Configurar o treinamento e a implantação do modelo com o Azure DevOps

Recursos relacionados

• Modelo de maturidade MLOps
• Orquestre MLOps no Azure Databricks usando o Databricks Notebook
• MLOps para modelos Python usando o Azure Machine Learning
• Ciência de dados e aprendizagem automática com o Azure Databricks
• IA cidadã com a Power Platform
• Implante IA e computação de aprendizado de máquina no local e na borda