Modelo de maturidade das operações de Machine Learning

Azure Machine Learning

A finalidade desse modelo de maturidade é ajudar a esclarecer os princípios e as práticas de MLOps (operações de machine learning). O modelo de maturidade mostra a melhoria contínua na criação e na operação de um ambiente de aplicativo de machine learning em nível de produção. Você pode usá-lo como uma métrica para estabelecer os requisitos progressivos necessários para medir a maturidade de um ambiente de produção de machine learning e os processos associados.

Modelo de maturidade

O modelo de maturidade de MLOps ajuda a esclarecer os princípios e as práticas de operações de desenvolvimento (DevOps) necessários para executar um ambiente MLOps bem-sucedido. Seu objetivo é identificar lacunas que possam existir quando uma organização tenta implementar esse ambiente. Também é uma maneira de mostrar como aumentar sua capacidade de MLOps em incrementos, em vez de sobrecarregar você com os requisitos de um ambiente totalmente maduro. Use como um guia para:

  • Estimar o escopo do trabalho para novas participações.

  • Estabeleça critérios de sucesso realistas.

  • Identifique os resultados que você entregará na conclusão do trabalho.

Como na maioria dos modelos de maturidade, o modelo de maturidade de MLOps avalia qualitativamente pessoas/cultura, processos/estruturas e objetos/tecnologia. À medida que o nível de maturidade aumenta, aumenta a probabilidade de que incidentes ou erros levem a melhorias na qualidade dos processos de desenvolvimento e produção.

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

Nível Descrição Destaques Tecnologia
0 Sem MLOps
  • É difícil gerenciar o ciclo de vida completo do modelo de machine learning
  • As equipes são diferentes e os lançamentos de versões são dolorosos
  • A maioria dos sistemas existem como "caixas pretas", pouco feedback durante/pós-implantação
  • Compilações e implantações manuais
  • Teste manual de modelo e aplicativo
  • Não há acompanhamento centralizado do desempenho do modelo
  • O treinamento do modelo é manual
1 Com DevOps, mas sem MLOps
  • Os lançamentos de versões são menos dolorosos que do que sem MLOps, mas dependem da Equipe de Dados para cada novo modelo
  • Feedback ainda limitado sobre o desempenho de um modelo na produção
  • Resultados difíceis de rastrear/reproduzir
  • Compilações automatizadas
  • Testes automatizados para o código do aplicativo
2 Treinamento automatizado
  • O ambiente de treinamento é totalmente gerenciado e rastreável
  • Modelo fácil de reproduzir
  • Os lançamentos de versões são manuais, mas com baixo atrito
  • Treinamento de modelo automatizado
  • Acompanhamento centralizado do desempenho do treinamento do modelo
  • Gerenciamento de modelos
3 Implantação de modelo automatizada
  • Os lançamentos de versões são de baixo atrito e automáticas
  • Rastreabilidade completa da implantação até os dados originais
  • Todo o ambiente é gerenciado: treinamento > teste > produção
  • Teste A/B integrado do desempenho do modelo para implantação
  • Testes automatizados para todos os códigos
  • Acompanhamento centralizado do desempenho do treinamento do modelo
4 Operações automatizadas MLOps completas
  • Sistema completamente automatizado e facilmente monitorado
  • Os sistemas de produção estão fornecendo informações sobre como melhorar e, em alguns casos, melhorar automaticamente através dos novos modelos
  • Aproximando-se de um sistema de tempo de inatividade zero
  • Treinamento e teste de modelo automatizado
  • Métricas detalhadas e centralizadas do modelo implantado

As tabelas a seguir identificam as características detalhadas para esse nível de maturidade do processo. O modelo continuará evoluindo. Esta versão foi atualizada pela última vez em janeiro de 2020.

Nível 0: Sem MLOps

Pessoas Criação do Modelo Versão do Modelo Integração de Aplicativo
  • Cientistas de dados: compartimentalizados, sem comunicações regulares com a equipe maior
  • Engenheiros de dados (se existirem): compartimentalizados, sem comunicações regulares com a equipe maior
  • Engenheiros de software: compartimentalizados, recebem o modelo remotamente dos outros membros da equipe
  • Dados coletados manualmente
  • Provavelmente, a computação não é gerenciada
  • Os experimentos não são acompanhados de forma previsível
  • O resultado final pode ser um único arquivo de modelo entregue manualmente com entradas/saídas
  • Processo manual
  • O script de pontuação pode ser criado manualmente bem depois dos experimentos, sem controle de versão
  • Lançamento de versões manipulado apenas pelo cientista ou engenheiro de dados
  • Depende muito da experiência do cientista de dados para implementar
  • Lançamentos manuais de versões sempre

Nível 1: DevOps no MLOps

Pessoas Criação do Modelo Versão do Modelo Integração de Aplicativo
  • Cientistas de dados: compartimentalizados, sem comunicações regulares com a equipe maior
  • Engenheiros de dados (se existirem): compartimentalizados, sem comunicação regular com a equipe maior
  • Engenheiros de software: compartimentalizados, recebem o modelo remotamente dos outros membros da equipe
  • O pipeline de dados coleta dados automaticamente
  • A computação é ou não é gerenciada
  • Os experimentos não são acompanhados de forma previsível
  • O resultado final pode ser um único arquivo de modelo entregue manualmente com entradas/saídas
  • Processo manual
  • O script de pontuação pode ser criado manualmente bem depois dos experimentos, provavelmente com controle de versão
  • É entregue aos engenheiros de software
  • Existem testes de integração básicos para o modelo
  • Depende muito da experiência do cientista de dados para implementar o modelo
  • Lançamentos de versões automatizados
  • O código do aplicativo tem testes de unidade

Nível 2: Treinamento Automatizado

Pessoas Criação do Modelo Versão do Modelo Integração de Aplicativo
  • Cientistas de dados: trabalham diretamente com os engenheiros de dados para converter código de experimentação em scripts/trabalhos repetíveis
  • Engenheiros de dados: trabalham com os cientistas de dados
  • Engenheiros de software: compartimentalizados, recebem o modelo remotamente dos outros membros da equipe
  • O pipeline de dados coleta dados automaticamente
  • Computação gerenciada
  • Resultados de experimentos monitorados
  • Tanto o código de treinamento quanto os modelos resultantes têm controle de versão
  • Lançamento de versão manual
  • O script de pontuação tem controle de versão com testes
  • Lançamento de versão gerenciado pela equipe de engenharia de software
  • Existem testes de integração básicos para o modelo
  • Depende muito da experiência do cientista de dados para implementar o modelo
  • O código do aplicativo tem testes de unidade

Nível 3: Implantação de Modelo Automatizada

Pessoas Criação do Modelo Versão do Modelo Integração de Aplicativo
  • Cientistas de dados: trabalham diretamente com os engenheiros de dados para converter código de experimentação em scripts/trabalhos repetíveis
  • Engenheiros de dados: trabalham com cientistas de dados e engenheiros de software para gerenciar entradas/saídas
  • Engenheiros de software: trabalham com engenheiros de dados para automatizar a integração de modelos no código do aplicativo
  • O pipeline de dados coleta dados automaticamente
  • Computação gerenciada
  • Resultados de experimentos monitorados
  • Tanto o código de treinamento quanto os modelos resultantes têm controle de versão
  • Lançamento de versão automático
  • O script de pontuação tem controle de versão com testes
  • Lançamento de versão gerenciado por pipeline de CI/CD (integração contínua e entrega contínua)
  • Testes de unidade e de integração para cada lançamento de versão do modelo
  • Menos dependente da experiência do cientista de dados para implementar o modelo
  • O código do aplicativo tem testes de unidade/integração

Nível 4: Retreinamento automatizado de MLOps completos

Pessoas Criação do Modelo Versão do Modelo Integração de Aplicativo
  • Cientistas de dados: trabalham diretamente com os engenheiros de dados para converter código de experimentação em scripts/trabalhos repetíveis. Trabalham com engenheiros de software para identificar marcadores para engenheiros de dados
  • Engenheiros de dados: trabalham com cientistas de dados e engenheiros de software para gerenciar entradas/saídas
  • Engenheiros de software: trabalham com engenheiros de dados para automatizar a integração de modelos no código do aplicativo. Implementação da coleta de métricas pós-implantação
  • O pipeline de dados coleta dados automaticamente
  • Retreinamento disparado automaticamente com base nas métricas de produção
  • Computação gerenciada
  • Resultados de experimentos monitorados
  • Tanto o código de treinamento quanto os modelos resultantes têm controle de versão
  • Lançamento de Versão Automático
  • O Script de Pontuação tem controle de versão com testes
  • Lançamento de versão gerenciado por integração contínua e pipeline de CI/CD
  • Testes de Unidade e de Integração para cada lançamento de versão do modelo
  • Menos dependente da experiência do cientista de dados para implementar o modelo
  • O código do aplicativo tem testes de unidade/integração

Próximas etapas