Compartilhar via

Operações de machine learning

  • Artigo

Este artigo descreve três arquiteturas do Azure para operações de aprendizado de máquina que têm pipelines de CI/CD (integração contínua e entrega contínua) de ponta a ponta e pipelines de retreinamento. As arquiteturas são para esses aplicativos de IA:

  • Aprendizado de máquina clássico
  • Pesquisa visual computacional (CV)
  • Processamento de idioma natural

Essas arquiteturas são resultado do projeto MLOps v2. Elas incorporam as práticas recomendadas que os arquitetos de solução identificaram no processo de desenvolvimento de várias soluções de aprendizado de máquina. O resultado são padrões implantáveis, repetíveis e sustentáveis. As três arquiteturas usam o serviço do Azure Machine Learning.

Para obter uma implementação com modelos de implantação de exemplo para MLOps v2, consulte Repositório GitHub do Azure MLOps v2.

Possíveis casos de uso

  • Aprendizado de máquina clássico: previsão, regressão e classificação de série temporal em dados estruturados tabulares são os casos de uso mais comuns nessa categoria. Os exemplos incluem:

    • Classificação binária e de vários rótulos.

    • Regressão linear, polinomial, de ridge, de laço, quantílica e bayesiana.

    • ARIMA, autorregressiva (AR), SARIMA, VAR, SES, LSTM.

  • CV: A estrutura de MLOps deste artigo concentra-se principalmente nos casos de uso de CV de segmentação e classificação de imagem.

  • Processamento de linguagem natural: use esta estrutura MLOps para implementar:

    • Reconhecimento de entidade nomeada:

    • Classificação de texto

    • Geração de texto

    • Análise de sentimento

    • Tradução

    • Respostas às perguntas

    • Resumo

    • Detecção de sentenças

    • Detecção de idioma

    • Marcação de parte do discurso

Simulações de IA, aprendizado de reforço profundo e outras formas de IA não são abordados neste artigo.

Arquitetura

O padrão de arquitetura MLOps v2 tem quatro componentes modulares,ou fases, principais do ciclo de vida do MLOps:

  • Acervo de dados
  • Administração e configuração
  • Desenvolvimento de modelo, ou fase de loop interno
  • Implantação de modelo, ou a fase de loop externo

Os componentes anteriores, as conexões entre eles e as personas típicas envolvidas são padrão em todas as arquiteturas de cenário MLOps v2. Pode haver variações nos detalhes de cada um, dependendo do cenário.

A arquitetura base do MLOps v2 para Machine Learning é o cenário clássico de aprendizado de máquina para dados tabulares. As arquiteturas CV e NLP se baseiam nessa arquitetura base e modificam.

O MLOps v2 abrange as seguintes arquiteturas descritas neste artigo:

Arquitetura do aprendizado de máquina clássico

Diagrama que mostra a arquitetura do aprendizado de máquina clássico.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de trabalho para a arquitetura do aprendizado de máquina clássico

  1. Acervo de dados

    Esse componente ilustra o patrimônio de dados da organização e as possíveis fontes e destinos de dados para um projeto de ciência de dados. Os engenheiros de dados são os principais proprietários desse componente do ciclo de vida do MLOps v2. As plataformas de dados do Azure neste diagrama não são completas nem prescritivas. Uma marca de seleção verde marca as fontes e destinos de dados que representam as práticas recomendadas com base no caso de uso do cliente.

  2. Administração e configuração

    Esse componente é a primeira etapa na implantação da solução MLOps v2. Ele consiste em todas as tarefas relacionadas à criação e gerenciamento de recursos e funções que são associadas ao projeto. Por exemplo, a equipe de infraestrutura pode:

    1. Crie repositórios de código-fonte do projeto.
    2. Use o Bicep ou o Terraform para criar workspaces do Machine Learning.
    3. Crie ou modifique conjuntos de dados e recursos de computação para desenvolvimento e implantação de modelos.
    4. Defina de usuários da equipe de projeto, suas funções e controles de acesso a outros recursos.
    5. Crie pipelines CI/CD.
    6. Crie componentes de monitoramento para coletar e criar alertas para métricas de modelo e infraestrutura.

    A principal persona associada a essa fase é a equipe de infraestrutura, mas uma organização também pode contar com engenheiros de dados, engenheiros de aprendizado de máquina e cientistas de dados.

  3. Desenvolvimento de modelo (fase de loop interno)

    A fase de loop interno consiste no fluxo de trabalho de ciência de dados iterativo que atua dentro de um workspace dedicado e seguro do Machine Learning. O diagrama anterior mostra um fluxo de trabalho típico. O processo começa com a ingestão de dados, passa pela análise exploratória de dados, experimentação, desenvolvimento e avaliação de modelos e, em seguida, registra um modelo para uso em produção. Esse componente modular é agnóstico e adaptável ao processo que sua equipe de ciência de dados usa para desenvolver modelos.

    As personas associadas a essa fase incluem cientistas de dados e engenheiros de aprendizado de máquina.

  4. Registros do Machine Learning

    Depois que a equipe de ciência de dados desenvolver um modelo que ela pode implantar, ela registra o modelo no registro do workspace do Machine Learning. Os pipelines de CI que são disparados, automaticamente por registro de modelo ou por aprovação human-in-the-loop fechada, promovem o modelo e quaisquer outras dependências de modelo para a fase de implantação do modelo.

    Personas associadas a esse estágio normalmente são engenheiros de aprendizado de máquina.

  5. Implantação de modelo (fase de loop externo)

    A fase de implantação de modelo ou loop externo consiste no processo de preparo e teste de pré-produção, implantação de produção e monitoramento do modelo, dos dados e da infraestrutura. Quando o modelo atende aos critérios da organização e do caso de uso, os pipelines de CD promovem o modelo e os ativos relacionados por meio de produção, monitoramento e possível retreinamento.

    Personas associadas a essa fase são principalmente engenheiros de aprendizado de máquina.

  6. Processo de preparo e teste

    A fase de preparação e teste varia de acordo com as práticas do cliente. Essa fase geralmente inclui operações como retreinamento e teste do candidato a modelo em dados de produção, implantações de teste para desempenho de ponto de extremidade, verificações de qualidade de dados, teste de unidade e verificações de IA responsável para identificar vieses de modelos e de dados. Essa fase ocorre em um ou mais workspaces dedicados e seguros do Machine Learning.

  7. Implantação de produção

    Depois que um modelo passa pela fase de preparação e teste, os engenheiros de aprendizado de máquina podem usar a aprovação humana no circuito para promovê-lo para produção. As opções de implantação de modelo incluem um ponto final de lote gerido para cenários de lote ou um ponto final online gerido ou implementação Kubernetes que utiliza o Azure Arc para cenários online, quase em tempo real. A produção costuma ocorrer em um ou mais workspaces dedicados e seguros do Machine Learning.

  8. Monitoramento

    Os engenheiros de aprendizado de máquina monitoraram componentes em preparação, teste e produção para análises detalhadas relacionadas a alterações no desempenho do modelo, dados e infraestrutura. Eles podem usar essas métricas para tomar medidas. O monitoramento de modelos e dados pode incluir verificação do descompasso de modelo e de dados, desempenho do modelo em novos dados e problemas de IA responsável. O monitoramento de infraestrutura pode identificar a resposta lenta do ponto de extremidade, a capacidade de computação inadequada ou problemas de rede.

  9. Monitoramento de dados e modelos: eventos e ações

    Com base em critérios relativos a modelo e dados como limites de métrica ou agendamentos, gatilhos automatizados e notificações podem implementar ações apropriadas a serem tomadas. Por exemplo, um gatilho pode treinar novamente um modelo para usar novos dados de produção e, em seguida, fazer um loopback do modelo para preparo e teste para uma avaliação de pré-produção. Ou um problema de modelo ou dados pode acionar uma ação que exija um loopback para a fase de desenvolvimento do modelo em que os cientistas de dados podem investigar o problema e potencialmente desenvolver um novo modelo.

  10. Monitoramento de infraestrutura: eventos e ações

    Com base em critérios de questões de infraestrutura preocupantes, como atraso de resposta de ponto de extremidade ou complexidade insuficiente para a implantação, gatilhos automáticos e notificações podem implementar ações para serem tomadas. Os gatilhos e notificações automáticos podem acionar um loopback para a fase de instalação e administração, na qual a equipe de infraestrutura pode investigar e potencialmente reconfigurar os recursos de computação e rede.

Arquitetura de CV do Machine Learning

Diagrama que mostra a arquitetura de visão computacional.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de trabalho para a arquitetura de CV

A arquitetura de CV do Machine Learning baseia-se na arquitetura de aprendizado de máquina clássica, mas tem modificações que são específicas para cenários de CV supervisionados.

  1. Acervo de dados

    Esse componente demonstra o patrimônio de dados da organização e as possíveis fontes e destinos de dados para um projeto de ciência de dados. Os engenheiros de dados são os principais proprietários desse componente no ciclo de vida do MLOps v2. As plataformas de dados do Azure neste diagrama não são completas nem prescritivas. As imagens para cenários de CV podem vir de diversas fontes de dados. Para obter eficiência ao desenvolver e implantar modelos de CV com o Machine Learning, recomendamos o Armazenamento de Blobs do Azure e o Azure Data Lake Storage.

  2. Administração e configuração

    Esse componente é a primeira etapa na implantação do MLOps v2. Ele consiste em todas as tarefas relacionadas à criação e gerenciamento de recursos e funções associadas ao projeto. Para cenários de CV, a administração e a configuração do ambiente MLOps v2 são basicamente as mesmas do aprendizado de máquina clássico, mas incluem uma etapa extra. A equipe de infraestrutura usa o recurso de rotulagem do Machine Learning ou outra ferramenta para criar projetos de rotulagem e anotação de imagens.

  3. Desenvolvimento de modelo (fase de loop interno)

    A fase de loop interno consiste no fluxo de trabalho de ciência de dados iterativo executado em um workspace dedicado e seguro do Machine Learning. A principal diferença entre esse fluxo de trabalho e o cenário clássico de aprendizado de máquina é que a rotulagem e a anotação de imagem são um componente-chave desse loop de desenvolvimento.

  4. Registros do Machine Learning

    Depois que a equipe de ciência de dados desenvolver um modelo que ela pode implantar, ela registra o modelo no registro do workspace do Machine Learning. Os pipelines de CI que são disparados automaticamente pelo registro do modelo ou pela aprovação human-in-the-loop promovem o modelo e quaisquer outras dependências de modelo para a fase de implantação do modelo.

  5. Implantação de modelo (fase de loop externo)

    A fase de implantação de modelo ou loop externo consiste no processo de preparo e teste de pré-produção, implantação de produção e monitoramento do modelo, dos dados e da infraestrutura. Quando o modelo atende aos critérios da organização e do caso de uso, os pipelines de CD promovem o modelo e os ativos relacionados por meio de produção, monitoramento e possível retreinamento.

  6. Processo de preparo e teste

    A fase de preparação e teste varia de acordo com as práticas do cliente. Essa fase normalmente inclui operações como implantações de teste para desempenho de ponto de extremidade, verificações de qualidade de dados, teste de unidade e verificações de IA responsável para identificar vieses de modelos e de dados. Para cenários de CV, os engenheiros de aprendizado de máquina não precisam treinar novamente o candidato ao modelo em dados de produção devido a restrições de recursos e tempo. Em vez disso, a equipe de ciência de dados pode usar dados de produção para o desenvolvimento do modelo. O modelo candidato registrado no loop de desenvolvimento é avaliado para produção. Essa fase ocorre em um ou mais workspaces dedicados e seguros do Machine Learning.

  7. Implantação de produção

    Depois que um modelo passa pela fase de preparação e teste, os engenheiros de aprendizado de máquina podem usar a aprovação humana no circuito para promovê-lo para produção. As opções de implantação de modelo incluem um ponto final de lote gerido para cenários de lote ou um ponto final online gerido ou implementação Kubernetes que utiliza o Azure Arc para cenários online, quase em tempo real. A produção costuma ocorrer em um ou mais workspaces dedicados e seguros do Machine Learning.

  8. Monitoramento

    Os engenheiros de aprendizado de máquina monitoraram componentes em preparação, teste e produção para análises detalhadas relacionadas a alterações no desempenho do modelo, dados e infraestrutura. Eles podem usar essas métricas para tomar medidas. O monitoramento de modelo e de dados podem incluir a verificação do desempenho do modelo em novas imagens. O monitoramento de infraestrutura pode identificar a resposta lenta do ponto de extremidade, a capacidade de computação inadequada ou problemas de rede.

  9. Monitoramento de dados e modelos: eventos e ações

    O monitoramento de dados e de modelos e as fases de evento e ação do MLOps para processamento de linguagem natural são as principais diferenças do aprendizado de máquina clássico. O retreinamento automatizado normalmente não é feito em cenários de CV quando uma degradação do desempenho do modelo em novas imagens é detectada. Nesse caso, é necessário um processo humano no circuito para revisar e anotar novos dados de texto para o modelo com desempenho insatisfatório. A próxima ação costuma ser voltar ao loop de desenvolvimento do modelo para atualizar o modelo com as novas imagens.

  10. Monitoramento de infraestrutura: eventos e ações

    Com base em critérios de questões de infraestrutura preocupantes, como atraso de resposta de ponto de extremidade ou complexidade insuficiente para a implantação, gatilhos automáticos e notificações podem implementar ações para serem tomadas. Os gatilhos e notificações automáticos podem acionar um loopback para a fase de instalação e administração, na qual a equipe de infraestrutura pode investigar e potencialmente reconfigurar os recursos de computação, rede e ambiente.

Arquitetura de processamento de linguagem natural de aprendizado de máquina

Diagrama para a arquitetura de processamento de linguagem natural.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de trabalho para a arquitetura de processamento de linguagem natural

A arquitetura de processamento de linguagem natural do Machine Learning baseia-se na arquitetura de aprendizado de máquina clássico, mas tem algumas modificações que são específicos a cenários de NLP.

  1. Acervo de dados

    Esse componente demonstra o patrimônio de dados da organização e as possíveis fontes e destinos de dados para um projeto de ciência de dados. Os engenheiros de dados são os principais proprietários desse componente no ciclo de vida do MLOps v2. As plataformas de dados do Azure neste diagrama não são completas nem prescritivas. Uma marca de seleção verde indica fontes e destinos de dados que representam as melhores práticas recomendadas com base no caso de uso do cliente.

  2. Administração e configuração

    Esse componente é a primeira etapa na implantação do MLOps v2. Ele consiste em todas as tarefas relacionadas à criação e gerenciamento de recursos e funções associadas ao projeto. Para cenários de processamento de linguagem natural, a administração e a instalação do ambiente do MLOps v2 são praticamente iguais ao aprendizado de máquina clássico, mas com uma etapa adicional: criar projetos de rotulagem e anotação de imagem usando o recurso de rotulagem do Machine Learning ou outra ferramenta.

  3. Desenvolvimento de modelo (fase de loop interno)

    A fase de loop interno consiste no fluxo de trabalho de ciência de dados iterativo executado em um workspace dedicado e seguro do Machine Learning. O ciclo típico de desenvolvimento de modelo de PNL difere do cenário clássico de aprendizado de máquina porque as etapas típicas de desenvolvimento para esse cenário incluem anotadores para frases e tokenização, normalização e incorporações para dados de texto.

  4. Registros do Machine Learning

    Depois que a equipe de ciência de dados desenvolver um modelo que ela pode implantar, ela registra o modelo no registro do workspace do Machine Learning. Os pipelines de CI que são disparados automaticamente pelo registro do modelo ou pela aprovação human-in-the-loop promovem o modelo e quaisquer outras dependências de modelo para a fase de implantação do modelo.

  5. Implantação de modelo (fase de loop externo)

    A fase de implantação de modelo ou loop externo consiste no processo de preparo e teste de pré-produção, implantação de produção e monitoramento do modelo, dos dados e da infraestrutura. Quando o modelo atende aos critérios da organização e do caso de uso, os pipelines de CD promovem o modelo e os ativos relacionados por meio de produção, monitoramento e possível retreinamento.

  6. Processo de preparo e teste

    A fase de preparação e teste varia de acordo com as práticas do cliente. Essa fase geralmente inclui operações como retreinamento e teste do candidato a modelo em dados de produção, implantações de teste para desempenho de ponto de extremidade, verificações de qualidade de dados, teste de unidade e verificações de IA responsável para identificar vieses de modelos e de dados. Essa fase ocorre em um ou mais workspaces dedicados e seguros do Machine Learning.

  7. Implantação de produção

    Depois que um modelo passa pela fase de preparação e teste, os engenheiros de aprendizado de máquina podem usar a aprovação humana no circuito para promovê-lo para produção. As opções de implantação de modelo incluem um ponto final de lote gerido para cenários de lote ou um ponto final online gerido ou implementação Kubernetes que utiliza o Azure Arc para cenários online, quase em tempo real. A produção costuma ocorrer em um ou mais workspaces dedicados e seguros do Machine Learning.

  8. Monitoramento

    Os engenheiros de aprendizado de máquina monitoraram componentes em preparação, teste e produção para análises detalhadas relacionadas a alterações no desempenho do modelo, dados e infraestrutura. Eles podem usar essas métricas para tomar medidas. O monitoramento de modelos e dados pode incluir a verificação de descompasso de modelos e de dados, de desempenho do modelo em novos dados de texto e de problemas de IA responsável. O monitoramento de infraestrutura pode identificar problemas como resposta lenta de ponto de extremidade, capacidade de computação inadequada e problemas de rede.

  9. Monitoramento de dados e modelos: eventos e ações

    Assim como acontece com a arquitetura de CV, o monitoramento de dados e de modelos e as fases de eventos e ações de MLOps para processamento de linguagem natural são as principais diferenças do aprendizado de máquina clássico. O retreinamento automatizado normalmente não é feito em cenários de processamento de linguagem natural quando uma degradação do desempenho do modelo em um novo texto é detectada. Nesse caso, é necessário um processo humano no circuito para revisar e anotar novos dados de texto para o modelo com desempenho insatisfatório. Geralmente, a próxima ação é voltar ao loop de desenvolvimento do modelo para atualizar o modelo com os novos dados de texto.

  10. Monitoramento de infraestrutura: eventos e ações

    Com base em critérios de questões de infraestrutura preocupantes, como atraso de resposta de ponto de extremidade ou complexidade insuficiente para a implantação, gatilhos automáticos e notificações podem implementar ações para serem tomadas. Os gatilhos e notificações automáticos podem acionar um loopback para a fase de instalação e administração, na qual a equipe de infraestrutura pode investigar e potencialmente reconfigurar os recursos de computação e rede.

Componentes

  • O Machine Learning é um serviço de nuvem que você pode usar para treinar, pontuar, implantar e gerenciar modelos de machine learning em escala.

  • Azure Pipelines: este é um sistema de compilação e teste que é baseado no Azure DevOps e usado para os pipelines de compilação e lançamento. O Azure Pipelines divide esses pipelines em etapas lógicas chamadas tarefas.

  • GitHub: é uma plataforma de hospedagem de código para controle de versão, colaboração e fluxos de trabalho de CI/CD.

  • O Azure Arc é uma plataforma que usa o Azure Resource Manager para gerenciar recursos do Azure e recursos locais. Os recursos podem incluir máquinas virtuais, clusters do Kubernetes e bancos de dados.

  • O Kubernetes é um sistema de código aberto para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos conteinerizados.

  • O Azure Data Lake Storage é um sistema de arquivos compatível com Hadoop. Tem um namespace hierárquico integrado e a grande escala e economia do Armazenamento de Blobs do Azure.

  • O Azure Synapse Analytics é um serviço de análise ilimitado que reúne integração de dados, armazenamento de dados corporativos e análise de Big Data.

  • Os O Hubs de Eventos do Azure é um serviço que ingere fluxos de dados gerados pelos aplicativos cliente. Depois, ele ingere e armazena os dados de streaming, o que preserva a sequência de eventos recebidos. Os consumidores podem se conectar aos pontos de extremidade do hub para recuperar mensagens para processamento. Essa arquitetura usa a integração do Data Lake Storage.

Outras considerações

O padrão de arquitetura MLOps v2 anterior tem vários componentes críticos, incluindo RBAC (controle de acesso baseado em função) que se alinha com as partes interessadas de negócios, gerenciamento eficiente de pacotes e mecanismos de monitoramento robustos. Esses componentes contribuem coletivamente para a implementação e o gerenciamento bem-sucedidos de fluxos de trabalho de aprendizado de máquina.

RBAC baseado em persona

É crucial que você gerencie o acesso a dados e recursos de aprendizado de máquina. O RBAC fornece uma estrutura robusta para ajudar você a gerenciar quem pode executar ações específicas e acessar áreas específicas em sua solução. Projete sua estratégia de segmentação de identidade para que se alinhe ao ciclo de vida dos modelos de aprendizado de máquina no Machine Learning e às personas incluídas no processo. Cada persona tem um conjunto específico de responsabilidades que são refletidas em suas funções RBAC e associação ao grupo.

Personas de exemplo

Para dar suporte à segmentação apropriada em uma carga de trabalho de aprendizado de máquina, considere as seguintes personas comuns que informam o design de grupo RBAC baseado em identidade.

Cientista de dados e engenheiro de aprendizado de máquina

Cientistas de dados e engenheiros de aprendizado de máquina executam várias atividades de aprendizado de máquina e ciência de dados em todo o ciclo de vida de desenvolvimento de software de um projeto. Suas funções incluem análise exploratória de dados e pré-processamento de dados. Cientistas de dados e engenheiros de aprendizado de máquina são responsáveis por treinar, avaliar e implantar modelos. As responsabilidades dessas funções também incluem atividades de reparo para modelos, pacotes e dados de aprendizado de máquina. Essas funções estão fora do escopo da equipe de suporte técnico da plataforma.

Tipo: Pessoa
Específico do projeto: Sim

Analista de dados

Os analistas de dados fornecem a entrada necessária para atividades de ciência de dados, como a execução de consultas SQL para business intelligence. As responsabilidades dessa função incluem trabalhar com dados, realizar análises de dados e apoiar o desenvolvimento e a implantação de modelos.

Tipo: Pessoa
Específico do projeto: Sim

Testador de modelo

Os testadores de modelo realizam testes em ambientes de teste e preparo. Essa função fornece segregação funcional dos processos de CI/CD.

Tipo: Pessoa
Específico do projeto: Sim

Stakeholders de negócios

As partes interessadas de negócios estão associadas ao projeto, como um gerente de marketing.

Tipo: Pessoa
Específico do projeto: Sim

Líder de projeto ou líder de ciência de dados

O líder de ciência de dados é uma função de administração de projeto para o workspace do Machine Learning. Essa função também faz atividades de reparo para os modelos e pacotes de aprendizado de máquina.

Tipo: Pessoa
Específico do projeto: Sim

Proprietário do projeto ou produto (proprietário da empresa)

Os stakeholders de negócios são responsáveis pelo workspace do Machine Learning de acordo com a propriedade dos dados.

Tipo: Pessoa
Específico do projeto: Sim

Suporte técnico da plataforma

O suporte técnico da plataforma é a equipe de suporte técnico responsável pelas atividades de reparo em toda a plataforma. Essa função abrange a infraestrutura ou o serviço, mas não os modelos, pacotes ou dados de aprendizado de máquina. Esses componentes permanecem sob a função de cientista de dados ou engenheiro de aprendizado de máquina e são de responsabilidade do líder do projeto.

Tipo: Pessoa
Específico do projeto: Não

Usuário final do modelo

Os usuários finais do modelo são os consumidores finais do modelo de aprendizado de máquina.

Tipo: Pessoa ou Processo
Específico do projeto: Sim

Processos de CI/CD

Os processos de CI/CD liberam ou revertem alterações em ambientes de plataforma.

Tipo: Processo
Específico do projeto: Não

Workspace do Machine Learning

Os workspaces do Machine Learning usam identidades gerenciadas para interagir com outras partes do Azure. Essa persona representa os vários serviços que compõem uma implementação do Machine Learning. Esses serviços interagem com outras partes da plataforma, como o workspace de desenvolvimento que se conecta ao armazenamento de dados de desenvolvimento.

Tipo: Processo
Específico do projeto: Não

Processos de monitoramento

Os processos de monitoramento são processos de computação que monitoram e alertam com base nas atividades da plataforma.

Tipo: Processo
Específico do projeto: Não

Processos de governança de dados

Os processos de governança de dados examinam o projeto de aprendizado de máquina e os armazenamentos de dados em busca de governança de dados.

Tipo: Processo
Específico do projeto: Não

Associação de grupo do Microsoft Entra

Quando você implementa o RBAC, os grupos do Microsoft Entra fornecem uma maneira flexível e escalonável de gerenciar permissões de acesso em diferentes personas. Você pode usar grupos do Microsoft Entra para gerenciar os usuários que precisam do mesmo acesso e das mesmas permissões para recursos, como aplicativos e serviços potencialmente restritos. Em vez de adicionar permissões especiais para usuários individuais, crie um grupo que as aplica a todos os membros.

Nesse padrão de arquitetura, você pode combinar esses grupos com uma configuração de Workspace do Machine Learning, como um projeto, uma equipe ou um departamento. Você pode associar usuários a grupos específicos para definir políticas de acesso refinadas. As políticas concedem ou restringem permissões a vários workspaces do Machine Learning com base em funções de trabalho, requisitos de projeto ou outros critérios. Por exemplo, você pode ter um grupo que concede a todos os cientistas de dados acesso a um workspace de desenvolvimento para um caso de uso específico.

RBAC de identidade

Considere a forma como você pode usar as seguintes funções RBAC internas do Azure para aplicar o RBAC a ambientes de produção e pré-produção. Para a arquitetura neste artigo, os ambientes de produção incluem ambientes de preparo, teste e produção. Os ambientes de pré-produção incluem ambientes de desenvolvimento. As funções RBAC a seguir são baseadas nas personas descritas anteriormente neste artigo.

Funções padrão

Funções específicas do componente

Essas abreviações de função de RBAC do Azure correspondem às tabelas a seguir.

Ambiente de produção
Persona Workspace do Machine Learning Cofre de Chave do Azure Registro de Contêiner Conta do Armazenamento do Azure Azure DevOps Azure Artifacts Espaço de Trabalho do Log Analytics Azure Monitor
Cientista de dados R LAR MR
Analista de dados
Testador de modelo
Stakeholders de negócios MR
Líder de projeto (líder de ciência de dados) R R, KVR R LAR MR
Proprietário do projeto/produto MR
Suporte técnico da plataforma O O, KVA DOPCA O O O
Usuário final do modelo
Processos de CI/CD O O, KVA AcrPush DOPCA O O O
Workspace do Machine Learning R C C
Processos de monitoramento R LAR MR
Processos de governança de dados R R R R R
Ambiente de pré-produção
Persona Workspace do Machine Learning Key Vault Registro de Contêiner Conta de armazenamento Azure DevOps Azure Artifacts Espaço de Trabalho do Log Analytics Azure Monitor
Cientista de dados ADS R, KVA C C C C LAC MC
Analista de dados R C LAR MC
Testador de modelo R R, KVR R R R R LAR MR
Stakeholders de negócios R R R R R
Líder de projeto (líder de ciência de dados) C C, KVA C C C C LAC MC
Proprietário do projeto/produto R R MR
Suporte técnico da plataforma O O, KVA O O DOPCA O O O
Usuário final do modelo
Processos de CI/CD O O, KVA AcrPush O DOPCA O O O
Workspace do Machine Learning R, KVR C C
Processos de monitoramento R R R R R R LAC
Processos de governança de dados R R R

Observação

Cada persona retém o acesso durante o projeto, exceto o suporte técnico da plataforma, que tem acesso temporário ou just-in-time ao Microsoft Entra Privileged Identity Management (PIM)..

O RBAC desempenha um papel fundamental na proteção e simplificação dos fluxos de trabalho de MLOps. O RBAC restringe o acesso com base nas funções atribuídas e impede que usuários não autorizados acessem dados confidenciais, o que reduz os riscos de segurança. Os dados confidenciais incluem dados ou modelos de treinamento e infraestrutura crítica, como pipelines de produção. Você pode usar o RBAC para garantir a conformidade com os regulamentos de privacidade de dados. O RBAC também fornece um registro claro de acesso e permissões, o que simplifica a auditoria, facilita a identificação de falhas de segurança e rastreia a atividade do usuário.

Gerenciamento de pacotes

Dependências em vários pacotes, bibliotecas e binários são comuns em todo o ciclo de vida do MLOps. Essas dependências, que muitas vezes desenvolvidas pela comunidade e estão evoluindo rapidamente, exigem conhecimento especializado no assunto para uso e compreensão adequados. Você deve garantir que as pessoas adequadas tenham acesso seguro a vários ativos, como pacotes e bibliotecas, mas também deve evitar vulnerabilidades. Os cientistas de dados encontram esse problema quando montam blocos de construção especializados para soluções de aprendizado de máquina. As abordagens tradicionais de gerenciamento de software são caras e ineficientes. Outras abordagens fornecem mais valor.

Para gerenciar essas dependências, é possível usar um processo de gerenciamento de pacotes seguro e de autoatendimento com base no padrão Quarentena. Você pode projetar esse processo para permitir que os cientistas de dados façam o autoatendimento a partir de uma lista coletada de pacotes e garantir que os pacotes sejam seguros e compatíveis com os padrões organizacionais.

Essa abordagem inclui a adição de três repositórios de pacotes de aprendizado de máquina padrão do setor à lista de segurança: Microsoft Artifact Registry, Python Package Index (PyPI) e Conda. A lista segura permite o autoatendimento de workspaces individuais do Machine Learning. Em seguida, use um processo de teste automatizado durante a implantação para examinar os contêineres de solução resultantes. As falhas saem elegantemente do processo de implantação e removem o contêiner. O diagrama e o fluxo do processo a seguir demonstram esse processo:

Diagrama que mostra a abordagem segura do pacote do Machine Learning.

Fluxo do processo

  1. Os cientistas de dados que trabalham em um workspace do Machine Learning que tem uma configuração de rede podem fazer autoatendimento de pacotes de aprendizado de máquina sob demanda dos repositórios de pacotes de aprendizado de máquina. Um processo de exceção é necessário para todo o resto usando o padrão de armazenamento privado, que é propagado e mantido usando uma função centralizada.

  2. O Machine Learning oferece soluções de aprendizado de máquina como contêineres do Docker. À medida que essas soluções são desenvolvidas, elas são carregadas no Registro de Contêiner. Microsoft Defender para Contêineres gera avaliações de vulnerabilidade para a imagem do contêiner.

  3. A implantação da solução ocorre por meio de um processo de CI/CD. O Microsoft Defender para DevOps é usado em toda a pilha para fornecer gerenciamento de postura de segurança e proteção contra ameaças.

  4. O contêiner de solução será implantado somente se passar por cada um dos processos de segurança. Se o contêiner da solução falhar em um processo de segurança, a implantação falhará com notificações de erro e trilhas de auditoria completas. O recipiente de solução é descartado.

O fluxo de processo anterior fornece um processo de gerenciamento de pacotes seguro e de autoatendimento para cientistas de dados e garante que os pacotes sejam seguros e compatíveis com os padrões organizacionais. Para equilibrar inovação e segurança, você pode conceder aos cientistas de dados acesso de autoatendimento a pacotes, bibliotecas e binários comuns de aprendizado de máquina em ambientes de pré-produção. Exija exceções para pacotes menos comuns. Essa estratégia garante que os cientistas de dados possam permanecer produtivos durante o desenvolvimento, o que evita um grande gargalo durante a entrega.

Para simplificar seus processos de lançamento, conteinerize ambientes para uso em ambientes de produção. Os ambientes em contêineres reduzem o trabalho árduo e garantem a segurança contínua por meio da verificação de vulnerabilidades. Esse fluxo de processo proporciona uma abordagem repetível que você pode usar em todos os casos de uso até o momento da entrega. Ele reduz o custo geral para criar e implantar soluções de aprendizado de máquina na sua empresa.

Monitoramento

No MLOps, o monitoramento é crucial para manter a integridade e o desempenho dos sistemas de aprendizado de máquina e garantir que os modelos permaneçam eficazes e alinhados com as metas de negócios. O monitoramento oferece suporte a controles de governança, segurança e custo durante a fase de loop interno. Ele também fornece observabilidade do desempenho, degradação do modelo e uso ao implantar soluções durante a fase de loop externo. As atividades de monitoramento são relevantes para personas como cientistas de dados, stakeholders de negócios, líderes de projeto, proprietários de projetos, suporte técnico de plataforma, processos de CI/CD e processos de monitoramento.

Escolha sua plataforma de monitoramento e verificação dependendo da configuração do workspace do Machine Learning, como um projeto, equipe ou departamento.

Desempenho do modelo

Monitore o desempenho do modelo para detectar problemas de modelo e degradação de desempenho antecipadamente. Acompanhe o desempenho para garantir que os modelos permaneçam precisos, confiáveis e alinhados com os objetivos de negócios.

Descompasso de dados

O descompasso de dados rastreia as alterações na distribuição dos dados de entrada de um modelo, comparando-os com os dados de treinamento do modelo ou com os dados de produção anteriores recentes. Essas alterações são resultado de mudanças na dinâmica do mercado, alterações de transformação de recursos ou alterações de dados upstream. Essas alterações podem degradar o desempenho do modelo, portanto, é importante monitorar o descompasso para garantir a correção oportuna. Para realizar uma comparação, a refatoração de descompasso de dados requer conjuntos de dados e saídas de produção recentes.

Ambiente: Produção
Facilitação do Azure: Machine Learning – Monitoramento de modelo

Descompasso de previsão

O descompasso de previsão rastreia as alterações na distribuição das saídas de previsão de um modelo, comparando-as com dados de validação, rotulados por teste, ou de produção recente. Para realizar uma comparação, a refatoração de descompasso de dados requer conjuntos de dados e saídas de produção recentes.

Ambiente: Produção
Facilitação do Azure: Machine Learning – Monitoramento de modelo

Recurso

Use várias métricas de ponto de extremidade de serviço de modelo para indicar qualidade e desempenho, como uso de CPU ou memória. Essa abordagem ajuda você a aprender com a produção para ajudar a impulsionar investimentos ou mudanças futuras.

Ambiente: Tudo
Facilitação do Azure: Monitor – Métricas de pontos de extremidade online

Métricas de uso

Monitore o uso de pontos de extremidade para garantir que você atenda aos principais indicadores de desempenho específicos da organização ou da carga de trabalho, rastreie os padrões de uso e diagnostique e corrija os problemas enfrentados pelos usuários.

Solicitações de cliente

Acompanhe o número de solicitações de cliente para o ponto de extremidade do modelo para entender o perfil de uso ativo dos pontos de extremidade, o que pode afetar os esforços de dimensionamento ou otimização de custos.

Ambiente: Produção
Facilitação do Azure: Monitor – Métricas de pontos de extremidade online, como RequestsPerMinute. Observações:

  • Você pode alinhar limites aceitáveis ao tamanho da camiseta ou anomalias adaptadas às necessidades da sua carga de trabalho.
  • Retire os modelos que não estão mais em uso da produção.
Atrasos de limitação

Atrasos de limitação são episódios de lentidão na solicitação e resposta de transferências de dados. A limitação ocorre no nível do Resource Manager e no nível de serviço. Acompanhe as métricas em ambos os níveis.

Ambiente: Produção
Facilitação do Azure:

  • Monitor – Resource Manager, soma de RequestThrottlingDelayMs, ResponseThrottlingDelayMs.
  • Machine Learning - Para verificar informações sobre as solicitações de seus pontos de extremidade, você pode habilitar logs de tráfego de ponto de extremidade online. Você pode usar um workspace do Log Analytics para processar logs.

Observações: alinhe os limites aceitáveis aos objetivos de nível de serviço (SLOs) ou SLAs (contratos de nível de serviço) da carga de trabalho e aos NFRs (requisitos não funcionais) da solução.

Erros gerados

Acompanhe erros de código de resposta para ajudar a medir a confiabilidade do serviço e garantir a detecção precoce de problemas de serviço. Por exemplo, um aumento repentino em 500 respostas de erro do servidor pode indicar um problema crítico que requer atenção imediata.

Ambiente: Produção
Facilitação do Azure: Machine Learning – Habilite logs de tráfego de ponto de extremidade online para verificar informações sobre a sua solicitação. Por exemplo, você pode verificar a contagem de XRequestId usando ModelStatusCode ou ModelStatusReason. Você pode usar um workspace do Log Analytics para processar logs.
Observações:

  • Todos os códigos de respostas HTTP no intervalo 400 e 500 são classificados como um erro.

Otimização de custo

O gerenciamento e a otimização de custos em um ambiente de nuvem são cruciais porque eles ajudam as cargas de trabalho a controlar despesas, alocar recursos com eficiência e maximizar o valor de seus serviços em nuvem.

Computação do workspace

Quando as despesas operacionais mensais atingirem ou excederem um valor predefinido, gere alertas para notificar os stakeholders relevantes, como líderes ou proprietários do projeto, com base nos limites de configuração do workspace. É possível determinar sua configuração do workspace com base nos limites relacionados ao projeto, à equipe ou ao departamento.

Ambiente: Tudo
Facilitação do Azure: Gerenciamento de Custos da Microsoft - Alertas de orçamento
Observações:

  • Defina limites de orçamento com base nos NFRs iniciais e nas estimativas de custo.
  • Use vários níveis de limite. Vários níveis de limite garantem que os stakeholders recebam o aviso apropriado antes que o orçamento seja excedido. Esses stakeholders podem incluir líderes de negócios, proprietários de projetos ou líderes de projetos, dependendo da organização ou carga de trabalho.
  • Alertas de orçamento consistentes também podem ser um gatilho para a refatoração para permitir uma demanda maior.
Desatualização workspace

Se um workspace do Machine Learning não mostrar sinais de uso ativo com base no uso de computação associado para o caso de uso pretendido, um proprietário do projeto poderá descontinuar o workspace se ele não for mais necessário para um determinado projeto.

Ambiente: Pré-produção
Facilitação do Azure:

Observações:

  • Os núcleos ativos devem ser iguais a zero com a agregação da contagem.
  • Alinhe os limites de data ao cronograma do projeto.

Segurança

Monitore para detectar desvios dos controles de segurança e linhas de base apropriados para garantir que os workspaces do Machine Learning estejam em conformidade com as políticas de segurança da sua organização. Você pode usar uma combinação de políticas predefinidas e personalizadas.

Ambiente: Tudo
Facilitação do Azure: Azure Policy para Machine Learning

Segurança do ponto de extremidade

Para obter visibilidade das APIs críticas para os negócios, implemente o monitoramento de segurança direcionado de todos os pontos de extremidade do Machine Learning. Você pode investigar e melhorar sua postura de segurança da API, priorizar correções de vulnerabilidade e detectar rapidamente ameaças ativas em tempo real.

Ambiente: Produção
Facilitação do Azure: o Microsoft Defender para APIs oferece ampla proteção do ciclo de vida, detecção e cobertura de resposta para APIs. Observações: o Defender para APIs fornece segurança para APIs que são publicadas no Gerenciamento de API do Azure. Você pode fazer a integração do Defender para APIs no portal do Microsoft Defender para Nuvem ou na instância do Gerenciamento de API no portal do Azure. É necessário integrar os pontos de extremidade online do Machine Learning ao Gerenciamento de API.

Implantação monitoramento

O monitoramento de implantação garante que todos os pontos de extremidade criados estejam em conformidade com as políticas da sua carga de trabalho ou organização e não apresentem vulnerabilidades. Esse processo requer que você imponha políticas de conformidade em seus recursos do Azure antes e depois da implantação, forneça segurança contínua por meio da verificação de vulnerabilidades e garanta que o serviço atenda aos SLOs durante a operação.

Padrões e governança

Monitore para detectar desvios dos padrões apropriados e garantir que sua carga de trabalho esteja em conformidade com as proteções.

Ambiente: Tudo
Facilitação do Azure:

  • Atribuição de política gerenciada e ciclo de vida por meio do Azure Pipelines para tratar a política como código.
  • O PSRule para Azure fornece uma estrutura de teste para a infraestrutura do Azure como código.
  • Você pode usar a política do Enterprise Azure como código em políticas de implantação do sistema baseadas em CI/CD, conjuntos de políticas, atribuições, isenções de política e atribuições de função.

Observações: para obter mais informações, consulte Diretrizes do Azure para conformidade regulatória do Machine Learning.

Verificação de segurança

Implemente verificações de segurança automatizadas como parte dos processos automatizados de integração e implantação.

Ambiente: Tudo
Facilitação do Azure: Defender para DevOps
Observações: você pode usar aplicativos no Azure Marketplace para estender esse processo para módulos de teste de segurança que não são da Microsoft.

Manutenção contínua

Monitore o serviço contínuo de uma API em termos de otimização de desempenho, segurança e uso de recursos. Garanta a detecção de erros em tempo hábil, a solução de problemas eficiente e a conformidade com os padrões.

Ambiente: Produção
Facilitação do Azure:

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas