Partilhar via


Operações de machine learning

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

  • Aprendizagem automática clássica
  • Visão computacional (CV)
  • Processamento de linguagem natural

Essas arquiteturas são o produto do projeto MLOps v2. Eles incorporam as melhores práticas que os arquitetos de soluções 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 fáceis de manter. Todas as três arquiteturas usam o serviço Azure Machine Learning.

Para obter uma implementação com modelos de implantação de exemplo para MLOps v2, consulte Azure MLOps v2 solution accelerator.

Potenciais casos de utilização

  • Aprendizado de máquina clássico: previsão de séries temporais, regressão e classificação em dados estruturados tabulares são os casos de uso mais comuns nesta categoria. Exemplos incluem:

    • Classificação binária e multi-rótulo.

    • Regressão linear, polinomial, crista, laço, quantil e bayesiana.

    • ARIMA, autorregressiva, SARIMA, VAR, SES, LSTM.

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

  • Processamento de linguagem natural: Você pode usar esta estrutura MLOps para implementar:

    • Reconhecimento da entidade nomeada:

    • Classificação de textos

    • Geração de texto

    • Análise de sentimentos

    • Tradução

    • Perguntas e respostas

    • Resumo

    • Deteção de sentenças

    • Deteção de idioma

    • Identificação de classe gramatical

Simulações de IA, aprendizagem por reforço profundo e outras formas de IA não são descritas neste artigo.

Arquitetura

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

  • Património de dados
  • Administração e configuração
  • Desenvolvimento do modelo, ou a fase de loop interno
  • Implantação do 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. As variações nos detalhes de cada componente dependem do cenário.

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

O MLOps v2 abrange as seguintes arquiteturas descritas neste artigo:

Arquitetura clássica de aprendizado de máquina

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

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de trabalho para a arquitetura clássica de aprendizado de máquina

  1. Património de dados

    Este componente ilustra o patrimônio de dados da organização e potenciais fontes de dados e alvos para um projeto de ciência de dados. Os engenheiros de dados são os principais proprietários desse componente do ciclo de vida MLOps v2. As plataformas de dados do Azure neste diagrama não são exaustivas ou prescritivas. Uma marca de seleção verde indica as fontes de dados e os destinos que representam as práticas recomendadas baseadas no caso de uso do cliente.

  2. Administração e configuração

    Este componente é a primeira etapa na implantação do acelerador MLOps v2. Consiste em todas as tarefas relacionadas com a criação e gestão de recursos e funções que estão associados 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 espaços de trabalho de Machine Learning.
    3. Crie ou modifique conjuntos de dados e recursos de computação para desenvolvimento e implantação de modelos.
    4. Defina os usuários da equipe de projeto, suas funções e controles de acesso a outros recursos.
    5. Crie pipelines de CI/CD.
    6. Crie componentes de monitoramento para coletar e criar alertas para métricas de modelo e infraestrutura.

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

  3. Desenvolvimento do modelo (fase de loop interno)

    A fase de loop interno consiste em um fluxo de trabalho iterativo de ciência de dados que atua dentro de um espaço de trabalho dedicado e seguro de 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 do modelo e, em seguida, registra um modelo para uso na produção. Este componente modular, conforme implementado no acelerador MLOps v2, é agnóstico e adaptável ao processo que sua equipe de ciência de dados usa para desenvolver modelos.

    As personas associadas a esta fase incluem cientistas de dados e engenheiros de aprendizagem automática.

  4. Registos de Aprendizagem Automática

    Depois que a equipe de ciência de dados desenvolve um modelo que pode implantar na produção, eles registram o modelo no registro do espaço de trabalho do Aprendizado de Máquina. Os pipelines de CI que são acionados, automaticamente pelo registro do modelo ou pela aprovação human-in-the-loop fechada, promovem o modelo e quaisquer outras dependências do modelo para a fase de implantação do modelo.

    As personas associadas a este estágio são tipicamente engenheiros de aprendizado de máquina.

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

    A implantação do modelo, ou fase de loop externo, consiste em preparação e teste de pré-produção, implantação de produção e monitoramento do modelo, dados e 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 potencial retreinamento.

    As personas associadas a esta fase são principalmente engenheiros de machine learning.

  6. Estadiamento 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 endpoint, verificações de qualidade de dados, testes de unidade e verificações de IA responsáveis para viés de modelo e dados. Esta fase ocorre em um ou mais espaços de trabalho dedicados e seguros de Machine Learning.

  7. Implementação de produção

    Depois que um modelo passa na fase de preparação e teste, os engenheiros de aprendizado de máquina podem usar a aprovação fechada human-in-the-loop para promovê-lo à produção. As opções de implantação de modelo incluem um ponto de extremidade de lote gerenciado para cenários em lote ou um ponto de extremidade online gerenciado ou implantação do Kubernetes que usa o Azure Arc para cenários online quase em tempo real. A produção normalmente ocorre em um ou mais espaços de trabalho dedicados e seguros de Machine Learning.

  8. Monitorização

    Os engenheiros de aprendizado de máquina monitoram componentes em preparação, teste e produção para coletar métricas relacionadas a alterações no desempenho do modelo, dos dados e da infraestrutura. Eles podem usar essas métricas para agir. O monitoramento de modelos e dados pode incluir a verificação de desvio de modelos e dados, o desempenho do modelo em novos dados e problemas de IA responsáveis. O monitoramento de infraestrutura pode identificar resposta lenta do ponto final, capacidade de computação inadequada ou problemas de rede.

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

    Com base em critérios de modelo e dados, como limites ou cronogramas métricos, gatilhos e notificações automatizados 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 loopback do modelo para preparação e teste para uma avaliação de pré-produção. Ou um problema de modelo ou de dados pode desencadear uma ação que requer um loopback para a fase de desenvolvimento do modelo, onde os cientistas de dados podem investigar o problema e, potencialmente, desenvolver um novo modelo.

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

    Gatilhos e notificações automatizados podem implementar ações apropriadas a serem tomadas com base em critérios de infraestrutura, como um atraso na resposta do ponto final ou computação insuficiente para a implantação. Gatilhos e notificações automáticos podem disparar um loopback para a fase de configuração e administração, onde a equipe de infraestrutura pode investigar o problema e, potencialmente, reconfigurar os recursos de computação e rede.

Arquitetura de CV de Machine Learning

Diagrama que mostra a arquitetura de visão computacional.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de trabalho para a arquitetura CV

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

  1. Património de dados

    Este componente demonstra a propriedade de dados da organização e potenciais fontes de dados e destinos para um projeto de ciência de dados. Os engenheiros de dados são os principais proprietários desse componente no ciclo de vida MLOps v2. As plataformas de dados do Azure neste diagrama não são exaustivas ou prescritivas. As imagens para cenários de CV podem provir de várias fontes de dados. Para obter eficiência ao desenvolver e implantar modelos CV com Machine Learning, recomendamos o Armazenamento de Blobs do Azure e o Armazenamento do Azure Data Lake.

  2. Administração e configuração

    Este componente é a primeira etapa na implantação do acelerador MLOps v2. Consiste em todas as tarefas relacionadas com a criação e gestão de recursos e funções associadas ao projeto. Para cenários CV, a administração e configuração do ambiente MLOps v2 é basicamente a mesma que para o aprendizado de máquina clássico, mas inclui uma etapa extra. A equipe de infraestrutura usa o recurso de rotulagem do Machine Learning ou outra ferramenta para criar projetos de etiquetagem e anotação de imagens.

  3. Desenvolvimento do modelo (fase de loop interno)

    A fase de loop interno consiste em um fluxo de trabalho iterativo de ciência de dados executado em um espaço de trabalho dedicado e seguro de 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 imagens são um componente-chave desse ciclo de desenvolvimento.

  4. Registos de Aprendizagem Automática

    Depois que a equipe de ciência de dados desenvolve um modelo que pode implantar na produção, eles registram o modelo no registro do espaço de trabalho do Aprendizado de Máquina. Os pipelines de CI que são acionados automaticamente pelo registro do modelo ou pela aprovação human-in-the-loop fechada promovem o modelo e quaisquer outras dependências do modelo para a fase de implantação do modelo.

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

    A implantação do modelo ou fase de loop externo consiste em preparo e teste de pré-produção, implantação de produção e monitoramento do modelo, dados e 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 potencial retreinamento.

  6. Estadiamento 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 implantações de teste para desempenho de endpoint, verificações de qualidade de dados, testes de unidade e verificações responsáveis de IA para viés de modelo e dados. Para cenários de CV, os engenheiros de aprendizado de máquina não precisam treinar novamente o candidato a 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 de modelos. O modelo candidato registrado a partir do ciclo de desenvolvimento é avaliado para produção. Esta fase ocorre em um ou mais espaços de trabalho dedicados e seguros de Machine Learning.

  7. Implementação de produção

    Depois que um modelo passa na fase de preparação e teste, os engenheiros de aprendizado de máquina podem usar a aprovação fechada human-in-the-loop para promovê-lo à produção. As opções de implantação de modelo incluem um ponto de extremidade de lote gerenciado para cenários em lote ou um ponto de extremidade online gerenciado ou implantação do Kubernetes que usa o Azure Arc para cenários online quase em tempo real. A produção normalmente ocorre em um ou mais espaços de trabalho dedicados e seguros de Machine Learning.

  8. Monitorização

    Os engenheiros de aprendizado de máquina monitoram componentes em preparação, teste e produção para coletar métricas relacionadas a alterações no desempenho do modelo, dos dados e da infraestrutura. Eles podem usar essas métricas para agir. O monitoramento de modelos e dados pode incluir a verificação do desempenho do modelo em novas imagens. O monitoramento de infraestrutura pode identificar resposta lenta do ponto final, capacidade de computação inadequada ou problemas de rede.

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

    O monitoramento de dados e modelos e as fases de eventos e ações 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 a degradação do desempenho do modelo em novas imagens é detetada. Nesse caso, um processo human-in-the-loop é necessário para revisar e anotar novos dados de texto para o modelo que tem um desempenho ruim. A próxima ação geralmente volta ao loop de desenvolvimento do modelo para atualizar o modelo com as novas imagens.

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

    Gatilhos e notificações automatizados podem implementar ações apropriadas a serem tomadas com base em critérios de infraestrutura, como um atraso na resposta do ponto final ou computação insuficiente para a implantação. Gatilhos e notificações automáticos podem disparar um loopback para a fase de configuração e administração, onde a equipe de infraestrutura pode investigar o problema e, potencialmente, reconfigurar o ambiente, a computação e os recursos de rede.

Arquitetura de processamento de linguagem natural de Machine Learning

Diagrama para a arquitetura de processamento de linguagem natural.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de trabalho para a arquitetura de processamento de linguagem natural

A arquitetura de processamento de linguagem natural do Machine Learning é baseada na arquitetura clássica de aprendizado de máquina, mas tem algumas modificações que são específicas para cenários de PNL.

  1. Património de dados

    Este componente demonstra a propriedade de dados da organização e potenciais fontes de dados e destinos para um projeto de ciência de dados. Os engenheiros de dados são os principais proprietários desse componente no ciclo de vida MLOps v2. As plataformas de dados do Azure neste diagrama não são exaustivas ou prescritivas. Uma marca de seleção verde indica fontes e destinos que representam as práticas recomendadas com base no caso de uso do cliente.

  2. Administração e configuração

    Este componente é a primeira etapa na implantação do acelerador MLOps v2. Consiste em todas as tarefas relacionadas com a criação e gestão de recursos e funções associadas ao projeto. Para cenários de processamento de linguagem natural, a administração e configuração do ambiente MLOps v2 é basicamente a mesma que para o aprendizado de máquina clássico, mas com uma etapa extra: criar projetos de etiquetagem e anotação de imagem usando o recurso de rotulagem do Machine Learning ou outra ferramenta.

  3. Desenvolvimento do modelo (fase de loop interno)

    A fase de loop interno consiste em um fluxo de trabalho iterativo de ciência de dados executado em um espaço de trabalho dedicado e seguro de Machine Learning. O loop de desenvolvimento de modelo de PNL típico 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. Registos de Aprendizagem Automática

    Depois que a equipe de ciência de dados desenvolve um modelo que pode implantar na produção, eles registram o modelo no registro do espaço de trabalho do Aprendizado de Máquina. Os pipelines de CI que são acionados automaticamente pelo registro do modelo ou pela aprovação human-in-the-loop fechada promovem o modelo e quaisquer outras dependências do modelo para a fase de implantação do modelo.

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

    A implantação do modelo ou fase de loop externo consiste em preparo e teste de pré-produção, implantação de produção e monitoramento do modelo, dados e 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 potencial retreinamento.

  6. Estadiamento 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 endpoint, verificações de qualidade de dados, testes de unidade e verificações de IA responsáveis para viés de modelo e dados. Esta fase ocorre em um ou mais espaços de trabalho dedicados e seguros de Machine Learning.

  7. Implementação de produção

    Depois que um modelo passa na fase de preparação e teste, os engenheiros de aprendizado de máquina podem usar a aprovação fechada human-in-the-loop para promovê-lo à produção. As opções de implantação de modelo incluem um ponto de extremidade de lote gerenciado para cenários em lote ou um ponto de extremidade online gerenciado ou implantação do Kubernetes que usa o Azure Arc para cenários online quase em tempo real. A produção normalmente ocorre em um ou mais espaços de trabalho dedicados e seguros de Machine Learning.

  8. Monitorização

    Os engenheiros de aprendizado de máquina monitoram componentes em preparação, teste e produção para coletar métricas relacionadas a alterações no desempenho do modelo, dos dados e da infraestrutura. Eles podem usar essas métricas para agir. O monitoramento de modelos e dados pode incluir a verificação de desvio de modelos e dados, o desempenho do modelo em novos dados de texto e problemas de IA responsáveis. O monitoramento da infraestrutura pode identificar problemas, como resposta lenta do ponto final, capacidade de computação inadequada e problemas de rede.

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

    Tal como acontece com a arquitetura CV, o monitoramento de dados e modelos e as fases de eventos e ações 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 processamento de linguagem natural quando a degradação do desempenho do modelo em um novo texto é detetada. Nesse caso, um processo human-in-the-loop é necessário para revisar e anotar novos dados de texto para o modelo que tem um desempenho ruim. Muitas vezes, 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

    Gatilhos e notificações automatizados podem implementar ações apropriadas a serem tomadas com base em critérios de infraestrutura, como um atraso na resposta do ponto final ou computação insuficiente para a implantação. Gatilhos e notificações automáticos podem desencadear um loopback para a fase de configuração e administração, onde a equipe de infraestrutura pode investigar o problema e, potencialmente, reconfigurar 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 aprendizado de máquina em escala.

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

  • O 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 Kubernetes e bancos de dados.

  • O Kubernetes é um sistema de código aberto que você pode usar para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos em contêineres.

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

  • 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 Hubs de Eventos do Azure são um serviço que ingere fluxos de dados gerados por aplicativos cliente. Em seguida, ingere e armazena dados de streaming, o que preserva a sequência de eventos recebidos. Os clientes 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 do negócio, 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 ajudá-lo 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 se alinhar com o ciclo de vida dos modelos de aprendizado de máquina no Machine Learning e as personas incluídas no processo. Cada persona tem um conjunto específico de responsabilidades que se refletem em suas funções RBAC e participação no grupo.

Exemplo de personas

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. As suas funções incluem a análise exploratória de dados e o 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 correção de falhas 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álise de dados e dar suporte ao desenvolvimento e implantação de modelos.

Tipo: Pessoa
Específico do projeto: Sim

Testador de modelos

Os testadores de modelos conduzem testes em ambientes de teste e preparação. Esta função fornece segregação funcional dos processos de CI/CD.

Tipo: Pessoa
Específico do projeto: Sim

Intervenientes empresariais

As partes interessadas do negócio 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 espaço de trabalho de Aprendizado de Máquina. Essa função também faz atividades de break-fix 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 do negócio)

As partes interessadas do negócio são responsáveis pelo espaço de trabalho de 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 correção de falhas 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 responsabilidade do líder do projeto.

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

Utilizador 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 CI/CD

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

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

Espaço de trabalho de Aprendizado de Máquina

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

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

Monitorização de processos

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 para governança de dados.

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

Associação ao grupo Microsoft Entra

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

Nesse padrão de arquitetura, você pode associar esses grupos a uma configuração de espaço de trabalho do Aprendizado de Máquina, 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 espaços de trabalho 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 conceda a todos os cientistas de dados acesso a um espaço de trabalho de desenvolvimento para um caso de uso específico.

Identidade RBAC

Considere como você pode usar as seguintes funções internas do RBAC 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 preparação, 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 abreviaturas de função do Azure RBAC correspondem às tabelas a seguir.

Ambiente de produção
Persona Espaço de trabalho de Aprendizado de Máquina Azure Key Vault Container Registry Conta de armazenamento do Azure Azure DevOps Artefactos do Azure Área de trabalho do Log Analytics Azure Monitor
Cientista de dados R LAR MR
Analista de dados
Testador de modelos
Intervenientes empresariais MR
Líder de projeto (Data science lead) R R, KVR R LAR MR
Proprietário do projeto/produto MR
Suporte técnico da plataforma O O, KVA DOPCA O O O
Utilizador final do modelo
Processos CI/CD O O, KVA AcrPush DOPCA O O O
Espaço de trabalho de Aprendizado de Máquina R C C
Monitorização de processos R LAR MR
Processos de governança de dados R R R R R
Ambiente de pré-produção
Persona Espaço de trabalho de Aprendizado de Máquina Key Vault Container Registry Conta de armazenamento Azure DevOps Artefactos do Azure Área de trabalho do Log Analytics Azure Monitor
Cientista de dados ANÚNCIOS R, KVA C C C C ALC MC
Analista de dados R C LAR MC
Testador de modelos R R, KVR R R R R LAR MR
Intervenientes empresariais R R R R R
Líder de projeto (Data science lead) C C, KVA C C C C ALC MC
Proprietário do projeto/produto R R MR
Suporte técnico da plataforma O O, KVA O O DOPCA O O O
Utilizador final do modelo
Processos CI/CD O O, KVA AcrPush O DOPCA O O O
Espaço de trabalho de Aprendizado de Máquina R, KVR C C
Monitorização de processos R R R R R R ALC
Processos de governança de dados R R R

Nota

Todas as personas retêm o acesso durante a duração do 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 vital 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. 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 as regulamentações 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.

Gestão de pacotes

Dependências em vários pacotes, bibliotecas e binários são comuns durante todo o ciclo de vida do MLOps. Estas dependências, muitas vezes desenvolvidas pela comunidade e em rápida evolução, requerem conhecimentos especializados no assunto para uma utilização e compreensão adequadas. Você deve garantir que as pessoas apropriadas tenham acesso seguro a diversos 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 proporcionam mais valor.

Para gerenciar essas dependências, você pode usar um processo de gerenciamento de pacotes seguro e de autoatendimento com base no padrão de quarentena. Você pode projetar esse processo para permitir que os cientistas de dados se autossirvam a partir de uma lista selecionada de pacotes e garantir que os pacotes sejam seguros e compatíveis com os padrões organizacionais.

Essa abordagem inclui a listagem segura de três repositórios de pacotes de aprendizado de máquina padrão do setor: Microsoft Artifact Registry, Python Package Index (PyPI) e Conda. A listagem segura permite o autoatendimento a partir de espaços de trabalho individuais de Machine Learning. Em seguida, use um processo de teste automatizado durante a implantação para verificar 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 de Machine Learning.

Fluxo do processo

  1. Os cientistas de dados que trabalham em um espaço de trabalho de Aprendizado de Máquina que tem uma configuração de rede podem autosservir pacotes de aprendizado de máquina sob demanda a partir 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 é semeado 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 Container Registry. O Microsoft Defender for Containers 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 for DevOps é usado em toda a pilha para fornecer segurança, postura, gerenciamento e proteção contra ameaças.

  4. O contêiner de solução é 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 da solução é eliminado.

O fluxo de processo anterior fornece um processo de gerenciamento de pacotes seguro e autossuficiente para cientistas de dados e garante que os pacotes sejam seguros e estejam em conformidade com os padrões organizacionais. Para equilibrar inovação e segurança, você pode conceder aos cientistas de dados acesso de autoatendimento a pacotes comuns de aprendizado de máquina, bibliotecas e binários em ambientes de pré-produção. Exigir 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 liberação, coloque ambientes em contêineres para uso em ambientes de produção. Os ambientes em contentores reduzem o trabalho e garantem a segurança contínua através da análise de vulnerabilidades. Esse fluxo de processo fornece 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 em sua empresa.

Monitorização

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 os objetivos de negócios. O monitoramento oferece suporte a controles de governança, segurança e custos durante a fase de loop interno. E fornece observabilidade no 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, partes interessadas do negócio, líderes de projeto, proprietários de projetos, suporte técnico da plataforma, processos de CI/CD e processos de monitoramento.

Escolha sua plataforma de monitoramento e verificação dependendo da configuração do seu espaço de trabalho de Aprendizado de Máquina, como um projeto, equipe ou departamento.

Desempenho do modelo

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

Desvio de dados

O desvio 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 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. Tais alterações podem degradar o desempenho do modelo, por isso é importante monitorar desvios para garantir a correção oportuna. Para realizar uma comparação, a refatoração de desvio 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

Desvio de previsão

O desvio 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 de teste ou de produção recente. Para realizar uma comparação, a refatoração de desvio 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ários modelos que servem métricas de endpoint 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: Todos
Facilitação do Azure: Monitor - Métricas de pontos de extremidade online

Métricas de utilização

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

Pedidos de cliente

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

Ambiente: Produção
Facilitação do Azure: Monitorar - Métricas de pontos de extremidade online, como RequestsPerMinute. Notas:

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

Os atrasos de limitação são lentidão na solicitação e resposta de transferências de dados. A limitação acontece 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 - Gerenciador de recursos, soma de RequestThrottlingDelayMs, ResponseThrottlingDelayMs.
  • Machine Learning - Para verificar informações sobre as solicitações de seus endpoints, você pode habilitar logs de tráfego de endpoint online. Você pode usar um espaço de trabalho do Log Analytics para processar logs.

Notas: Alinhe limites aceitáveis aos SLOs (objetivos de nível de serviço) ou contratos de nível de serviço (SLAs) da sua carga de trabalho e aos requisitos não funcionais (NFRs) da solução.

Erros gerados

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

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

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

Otimização de custos

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

Computação do espaço de trabalho

Quando as despesas operacionais mensais atingirem ou excederem um valor predefinido, gere alertas para notificar as partes interessadas relevantes, como líderes de projeto ou proprietários de projetos, com base nos limites de configuração do espaço de trabalho. Você pode determinar a configuração do espaço de trabalho com base nos limites relacionados ao projeto, à equipe ou ao departamento.

Ambiente: Todos
Facilitação do Azure: Microsoft Cost Management - Alertas de orçamento
Notas:

  • Defina limites de orçamento com base nos NFRs iniciais e estimativas de custo.
  • Use várias camadas de limite. Vários níveis de limite garantem que as partes interessadas recebam um aviso apropriado antes que o orçamento seja excedido. Essas partes interessadas podem incluir líderes de negócios, proprietários de projetos ou líderes de projeto, dependendo da organização ou da carga de trabalho.
  • Alertas orçamentais consistentes podem também ser um gatilho para a refatoração para suportar uma maior procura.
Impasse no espaço de trabalho

Se um espaço de trabalho de Aprendizado de Máquina não mostrar sinais de uso ativo com base no uso de computação associado para o caso de uso pretendido, um proprietário de projeto poderá encerrar o espaço de trabalho se ele não for mais necessário para um determinado projeto.

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

Notas:

  • 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 detetar desvios dos controles de segurança e linhas de base apropriados para garantir que os espaços de trabalho 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: Todos
Facilitação do Azure: Política do Azure para Machine Learning

Segurança de pontos finais

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

Ambiente: Produção
Facilitação do Azure: o Microsoft Defender for APIs oferece ampla proteção do ciclo de vida, deteção e cobertura de resposta para APIs. Observações: O Defender for APIs fornece segurança para APIs publicadas no Gerenciamento de API do Azure. Você pode integrar o Defender for APIs no portal do Microsoft Defender for Cloud ou na instância de Gerenciamento de API no portal do Azure. Você deve integrar os endpoints online do Machine Learning com o Gerenciamento de API.

Monitoramento de implantação

O monitoramento de implantação garante que todos os pontos de extremidade criados sigam a carga de trabalho ou as políticas da organização e estejam livres de vulnerabilidades. Esse processo requer que você aplique 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.

Normas e governação

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

Ambiente: Todos
Facilitação do Azure:

Notas: Para obter mais informações, consulte Orientações do Azure para conformidade regulamentar 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: Todos
Facilitação do Azure: Defender For 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 sejam da Microsoft.

Serviço contínuo

Monitore o serviço contínuo de uma API para otimização de desempenho, segurança e uso de recursos. Garanta a deteção oportuna de erros, a solução eficiente de problemas e a conformidade com as normas.

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

  • Monitor - Métricas de Machine Learning
  • Machine Learning - Você pode habilitar logs de tráfego de ponto de extremidade on-line para verificar informações sobre seu serviço.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

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

Próximos passos