Partilhar via


Modelo de maturidade de MLOps

O modelo de maturidade de operações de aprendizagem automática (MLOps) define princípios e práticas para ajudar a construir e operar ambientes de aprendizagem automática em produção. Use este modelo para avaliar o seu estado atual e planear progressos incrementais rumo a um ambiente MLOps maduro.

Visão geral do modelo de maturidade

O modelo de maturidade MLOps clarifica os princípios e práticas de operações de desenvolvimento (DevOps) necessários para executar um ambiente MLOps bem-sucedido. Fornece uma estrutura para medir as capacidades MLOps da sua organização e identificar lacunas na sua implementação atual. Use este modelo para desenvolver gradualmente a sua capacidade MLOps, em vez de enfrentar a complexidade total da implementação madura desde o início.

Use o modelo de maturidade MLOps como guia para realizar as seguintes tarefas:

  • Estima o âmbito do trabalho para novos projetos.

  • Estabeleça critérios realistas de sucesso.

  • Identificar entregáveis para entregar no final do projeto.

Tal como a maioria dos modelos de maturidade, o modelo de maturidade MLOps avalia qualitativamente pessoas e cultura, processos e estruturas, bem como objetos e tecnologia. À medida que o nível de maturidade aumenta, também aumenta a probabilidade de incidentes ou erros levarem a melhorias nos processos de desenvolvimento e produção.

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

Nível Description Destaques Tecnologia
0 Sem MLOps
  • O ciclo de vida completo do modelo de aprendizagem automática é difícil de gerir.

  • As equipas são diferentes e os lançamentos são desafiantes.

  • A maioria dos sistemas é não transparente, com pouco feedback durante e após a implementação.
  • As builds e implementações são manuais.

  • O teste de modelos e aplicações é manual.

  • O acompanhamento do desempenho do modelo não é centralizado.

  • O treino de modelos é manual.

  • O Teams utiliza apenas funcionalidades básicas do espaço de trabalho Azure Machine Learning.
1 DevOps mas sem MLOps
  • Os lançamentos são menos desafiantes do que o Nível 0, mas dependem das equipas de dados para cada novo modelo.

  • O feedback sobre o desempenho do modelo em produção ainda é limitado.

  • Os resultados são difíceis de rastrear e reproduzir.
  • As construções são automatizadas.

  • O código da aplicação tem testes automatizados.

  • O código é gerido por controlo de versões.
2 Formação automatizada
  • O ambiente de formação é totalmente gerido e rastreável.

  • O modelo é fácil de reproduzir.

  • Os lançamentos são manuais, mas fáceis de implementar.
  • O treino de modelos é automatizado.

  • A monitorização do desempenho do treino do modelo é centralizada.

  • A gestão de modelos está implementada.

  • Os trabalhos agendados ou orientados por eventos em Aprendizagem Automática gerem formação recorrente.

  • Adota-se uma Feature Store gerida.

  • Os eventos do ciclo de vida do Azure Event Grid são emitidos para orquestração de pipeline.

  • Os ambientes são geridos utilizando definições de ambientes de Aprendizagem Automática.
3 Implementação automatizada do modelo
  • Os lançamentos são fáceis de implementar e automáticos.

  • Existe rastreabilidade total desde a implementação até aos dados originais.

  • Todo o ambiente é gerido, incluindo formação, testes e produção.
  • Testes A/B do desempenho do modelo estão integrados para a implementação.

  • Todo o código tem testes automatizados.

  • O acompanhamento do desempenho do treino de modelos é centralizado.

  • Os artefactos são promovidos em vários espaços de trabalho através da utilização de registos de Aprendizagem Automática.
4 Operações automatizadas completas do MLOps
  • O sistema completo é automatizado e facilmente monitorizado.

  • Os sistemas de produção fornecem informações sobre como melhorar e, por vezes, melhorar automaticamente com novos modelos.

  • O sistema está a aproximar-se de zero tempo de inatividade.
  • O treino e os testes de modelos são automatizados.

  • O modelo implementado emite métricas verbosas e centralizadas.

  • Sinais de deriva ou regressão desencadeiam o retreino automático através da utilização da Grade de Eventos.

  • A materialização das funcionalidades, bem como a sua saúde e atualidade, são monitorizadas.

  • A promoção de modelos é baseada em políticas e automatizada através do uso de registos de Aprendizagem Automática.

As tabelas seguintes descrevem características detalhadas para cada nível de maturidade.

Nível 0: Sem MLOps

People Criação de modelos Lançamento do modelo Integração de aplicações
  • Os cientistas de dados trabalham isoladamente, sem comunicação regular com a equipa maior.

  • Os engenheiros de dados (se existirem) trabalham isoladamente, sem comunicação regular com a equipa maior.

  • Os engenheiros de software trabalham isoladamente e recebem modelos remotamente de outros membros da equipa.
  • Os dados são recolhidos manualmente.

  • Os recursos de computação provavelmente não estão a ser geridos.

  • As experiências não são registadas de forma consistente.

  • O resultado final é tipicamente um único ficheiro de modelo que inclui entradas e saídas, entregues manualmente.
  • O processo de libertação é manual.

  • O script de pontuação é criado manualmente após experiências e não é controlado por controlo de versão.

  • Um único cientista de dados ou engenheiro de dados trata do lançamento.
  • A implementação depende muito da experiência do cientista de dados.

  • Os lançamentos de aplicações são manuais.

Nível 1: DevOps mas sem MLOps

People Criação de modelos Lançamento do modelo Integração de aplicações
  • Os cientistas de dados trabalham isoladamente, sem comunicação regular com a equipa maior.

  • Os engenheiros de dados (se existirem) trabalham isoladamente, sem comunicação regular com a equipa maior.

  • Os engenheiros de software trabalham isoladamente e recebem modelos remotamente de outros membros da equipa.
  • O sistema de integração de dados recolhe os dados automaticamente.

  • A computação pode ou não ser gerida.

  • As experiências não são registadas de forma consistente.

  • O resultado final é tipicamente um único ficheiro de modelo que inclui entradas e saídas, entregues manualmente.
  • O processo de libertação é manual.

  • O script de pontuação é criado manualmente após experiências, mas provavelmente é controlado por versões.

  • O modelo é entregue aos engenheiros de software.
  • Existem testes básicos de integração para o modelo.

  • A implementação depende muito da experiência do cientista de dados.

  • Os lançamentos de candidaturas são automatizados.

  • O código da aplicação tem testes unitários.

Nível 2: Formação automatizada

People Criação de modelos Lançamento do modelo Integração de aplicações
  • Cientistas de dados trabalham diretamente com engenheiros de dados para converter código de experimentação em scripts e trabalhos repetíveis.

  • Engenheiros de dados trabalham com cientistas de dados no desenvolvimento de modelos.

  • Os engenheiros de software trabalham isoladamente e recebem modelos remotamente de outros membros da equipa.
  • O fluxo de dados recolhe automaticamente os dados.

  • Os recursos de computação são geridos.

  • Os resultados dos experimentos são acompanhados.

  • O código de treino e os modelos são ambos controlados por versão.
  • O processo de libertação é manual.

  • O script de pontuação está sob controlo de versão e tem testes.

  • A equipa de engenharia de software gere os lançamentos.
  • Existem testes básicos de integração para o modelo.

  • A implementação depende muito da experiência do cientista de dados.

  • O código da aplicação tem testes unitários.

Nível 3: Implementação automatizada do modelo

People Criação de modelos Lançamento do modelo Integração de aplicações
  • Cientistas de dados trabalham diretamente com engenheiros de dados para converter código de experimentação em scripts e trabalhos repetíveis.

  • Os engenheiros de dados trabalham com cientistas de dados e engenheiros de software para gerir entradas e saídas.

  • Engenheiros de software trabalham com engenheiros de dados para automatizar a integração de modelos no código da aplicação.
  • O fluxo de dados recolhe automaticamente os dados.

  • Os recursos de computação são geridos.

  • Os resultados dos experimentos são acompanhados.

  • O código de formação e os modelos são ambos controlados por versão.
  • O processo de libertação é automático.

  • O script de pontuação é controlado por versões e tem testes.

  • O pipeline de integração contínua e entrega contínua (CI/CD) gere os lançamentos.
  • Cada versão de modelo inclui testes unitários e de integração.

  • A implementação depende menos da experiência do cientista de dados.

  • O código da aplicação tem testes unitários e de integração.

Nível 4: Operações MLOps totalmente automatizadas

People Criação de modelos Lançamento do modelo Integração de aplicações
  • Cientistas de dados trabalham diretamente com engenheiros de dados para converter código de experimentação em scripts e trabalhos repetíveis. Também trabalham com engenheiros de software para identificar marcadores de dados.

  • Os engenheiros de dados trabalham com cientistas de dados e engenheiros de software para gerir entradas e saídas.

  • Engenheiros de software trabalham com engenheiros de dados para automatizar a integração de modelos e implementar a recolha de métricas pós-implementação.
  • O fluxo de dados recolhe automaticamente os dados.

  • As métricas de produção desencadeiam automaticamente a requalificação.

  • Os recursos de computação são geridos.

  • Os resultados dos experimentos são acompanhados.

  • O código de treino e os modelos são ambos controlados por versão.
  • O processo de libertação é automático.

  • O script está sob controlo de versão e inclui testes.

  • A infraestrutura CI/CD gere as releases.
  • Cada versão de modelo inclui testes unitários e de integração.

  • A implementação depende menos da experiência do cientista de dados.

  • O código da aplicação tem testes unitários e de integração.

MLOps e GenAIOps

Este artigo foca-se nas capacidades preditivas, tabulares e clássicas do ciclo de vida da aprendizagem automática. As operações de IA generativa (GenAIOps) introduzem capacidades adicionais que complementam os níveis de maturidade dos MLOps em vez de os substituir. Os GenAIOps incluem ciclo de vida rápido, aumento de recuperação, segurança de saída e governação de custos de tokens. Para mais informações, consulte GenAIOps para organizações que têm investimentos em MLOps. Não confunda a mecânica de iteração de prompts com o ciclo reproduzível de treino-implementação descrito neste artigo.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

  • Delyn Choong | Arquiteto Sénior de Soluções Cloud – Dados & IA

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos