Ciclo de vida da aprendizagem automática

Esta página descreve o percurso de ponta a ponta para levar um projeto de aprendizagem automática (ML) desde o âmbito inicial até à produção, mantendo-o a funcionar bem ao longo do tempo. Código, dados e modelos passam por três grandes etapas: desenvolvimento, encenação e produção. Cada fase tem objetivos e requisitos distintos:

  1. Defina o âmbito do caso de uso e defina sucesso
  2. Explore e compreenda os dados
  3. Preparar dados e funcionalidades
  4. Treinar modelos e acompanhar experiências
  5. Avaliar
  6. Registar, preparar e testar modelos
  7. Implementação em produção
  8. Monitorizar e reeducar

1. Definir o âmbito do caso de uso e definir o sucesso

Antes de construir qualquer coisa, alinhe-se com o que o modelo precisa de fazer e como vai saber que está a funcionar.

  • Qual é o alvo de previsão e que classe de problema de ML implica isso: classificação, regressão, previsão, recomendação, classificação, deteção de anomalias ou outra coisa qualquer?
  • Que dados de entrada estão disponíveis e é suficiente para aprender o padrão alvo?
  • Que métricas definem sucesso: precisão, AUC, precisão em K ou KPIs empresariais?
  • Quais são os requisitos de inferência e de produção: latência, taxa de processamento e atualidade dos dados?
  • Que partes interessadas têm de aprovar as implementações na produção? Quais são os requisitos deles em relação à explicabilidade?

Os requisitos anteriores não ditam o método específico de ML. Pode começar a modelar com uma abordagem mais simples, como árvores com gradiente aumentado, e mais tarde decidir que são necessários métodos de aprendizagem profunda mais potentes.

2. Explorar e compreender os dados

Antes de preparar funcionalidades ou treinar um modelo, explore os dados para compreender a sua estrutura, qualidade e relação com o alvo de previsão. A análise exploratória de dados (EDA) é o processo de resumir e visualizar um conjunto de dados para distribuições de superfície, correlações, valores em falta e valores atípicos que moldam decisões de modelação a jusante.

Logo no início, decida como verificar se tem dados de teste válidos que estão retidos no treino. Mesmo durante a EDA, cuidado ao tomar decisões de modelação baseadas nos seus dados de teste.

A EDA responde a perguntas que informam o resto do ciclo de vida:

  • Quais são as entradas mais preditivas da variável-alvo, e alguma delas está indisponível no momento da inferência?
  • Existem valores em falta, valores atípicos ou distribuições assimétricas que exigem limpeza ou transformação?
  • O conjunto de dados é suficientemente grande e representativo para aprender o padrão alvo?

O Azure Databricks simplifica o EDA com ferramentas interativas, colaborativas e assistidas por IA. Explore os seus dados usando chat em linguagem natural, interfaces ou código, e colabore tanto através de co-edição em tempo real como de partilha de código baseada em Git:

  • Os cadernos proporcionam espaços colaborativos para exploração, visualização e documentação.
  • Os dashboards fornecem exploração baseada em SQL e visualização.
  • O Genie Chat disponibiliza uma interface de página inteira, em linguagem natural, para colocar questões sobre dados.
  • O Código Génio pode realizar EDA totalmente automatizado ou atuar como assistente interativo.

3. Preparar dados e funcionalidades

Com os dados compreendidos, transforme as fontes brutas e transformações identificadas durante a EDA em funcionalidades para modelos de ML. Avalie os seus pipelines de dados para formação e serviço, incluindo velocidade, volume, frescura e propriedade das fontes de dados. A fronteira entre engenharia de dados (preparação e transformação de dados) e engenharia de funcionalidades (derivar entradas de ML) é difusa. No Azure Databricks, a engenharia de dados e o ML partilham a mesma plataforma e camada de governação no Unity Catalog, pelo que os dados preparados por uma equipa podem ser disponibilizados imediatamente como funcionalidades para outra, sem movimentação de dados ou pipelines duplicados.

Procure dados existentes e definições de características:

  • Explore dados e funcionalidades disponíveis no Catálogo Unity. Se a sua organização tiver modelos relacionados, use a linhagem do Unity Catalogue para descobrir fontes de dados e funcionalidades usadas para esses modelos.
  • A pesquisa em espaços de trabalho pode ajudá-lo a descobrir que dados, modelos ou aplicações governados já existem.

Crie e gere novos ativos conforme necessário:

  • Consulte Engenharia de Dados com Databricks para mais informações sobre ferramentas de ingestão e engenharia de dados, incluindo o Lakeflow Designer para uma experiência sem código assistida por IA.
  • Use a Feature Store para definir e gerir funcionalidades como ativos reutilizáveis e governados. As mesmas definições de funcionalidades são usadas no treino e produção, com suporte para ingestão de dados em lote e em tempo real, bem como para serviço em lote e em tempo real.

Use o Código Genie para acelerar a descoberta e preparação de dados, navegando pelo Unity Catalog para descobrir tabelas relevantes, sugerindo transformações de funcionalidades e gerando código inicial para pipelines de ingestão e funcionalidades.

4. Treinar modelos e acompanhar experiências

As aplicações de ciência de dados e ML utilizam muitas abordagens diferentes, cada uma com os seus próprios requisitos para algoritmos e bibliotecas de ML, requisitos de computação e fluxos de trabalho. O Azure Databricks fornece ambientes flexíveis e computação para diferentes cargas de trabalho, com o acompanhamento de experiências unificado no MLflow.

Ambientes e computação

Por predefinição, utilize a computação sem servidor tanto para notebooks interativos como para trabalhos automatizados. A computação serverless começa instantaneamente e escala automaticamente para cima e para baixo conforme a sua carga de trabalho.

Para a aceleração da GPU, liga GPUs ao teu computador serverless, que depois usa o AI Runtime, um ambiente pré-configurado para treino e inferência da GPU.

Para cargas de trabalho tanto de CPU como de GPU, pode também usar computação clássica com o Databricks Runtime for Machine Learning.

Personaliza qualquer um dos ambientes anteriores com as tuas bibliotecas de ML. Uma vez que os ambientes são frequentemente muito personalizados para aplicações de ML, utilize o rastreio do MLflow para registar dependências, verificar a reprodutibilidade e evitar o desvio entre treino e inferência.

Monitorização no MLflow

Use o MLflow gerido pelo Azure Databricks para acompanhar a sua experimentação e registar os metadados dos modelos:

Comece a modelar

O Genie Code pode gerar um caderno completo de ML a partir de uma descrição em linguagem simples da tarefa de previsão, incluindo seleção de funcionalidades da Feature Store, treino de ML e rastreamento de MLflow.

Consulte também recursos para afinação de hiperparâmetros, exemplos de treino de modelos e Ray on Databricks.

Para aprendizagem profunda e treino de modelos clássicos de aprendizagem automática acelerado por GPU, consulte notebooks de exemplo para o AI Runtime.

5. Avaliar

Durante o desenvolvimento, defina métricas de avaliação da qualidade com base nos requisitos definidos na fase de definição do âmbito:

  • As tuas métricas base podem ser métricas comuns de ML como precisão, AUC, RMSE ou métricas específicas de domínio.
  • A sua avaliação pode também incluir métricas derivadas, como viés e justiça entre segmentos populacionais, medidas comparando métricas base entre segmentos dos seus dados.

Define métricas usando a tua biblioteca ou framework de ML escolhido, usando o módulo de métricas incorporado do MLflow ou a tua lógica personalizada. Para todas as métricas, registe as métricas nas execuções do MLflow para associá-las aos respetivos modelos. As métricas que defines durante o desenvolvimento e treino podem ser reutilizadas mais tarde como métricas para monitorização de produção.

6. Registar, preparar e testar modelos

Depois de treinares um modelo ou pipeline de ML, regista-o no MLflow Model Registry no Unity Catalog para simplificar a governação e gestão à medida que promoves o modelo para a produção. Um modelo registado tem versões, cada uma das quais está associada à execução de treino original que o produziu. As versões dos modelos permitem fluxos de trabalho de implementação seguros: pode testar uma nova versão em staging antes de a promover para produção, reverter para uma versão anterior se a qualidade piorar e manter um registo completo de auditoria do que foi implementado e quando.

Antes de uma nova versão do modelo processar tráfego de produção, teste-a num ambiente de staging em condições realistas:

  • Atribua aliases à versão candidata do modelo (Staging, Production) para assinalar o estado do ciclo de vida sem mudar o nome dos artefactos.
  • Execute os testes de integração na infraestrutura de staging: confirme que o ponto terminal de disponibilização arranca, que a latência cumpre os requisitos e que os resultados têm o formato correto.
  • Realizar testes A/B ou sombra em dados de produção para validar o desempenho antes do corte completo.
  • Recolha a aprovação das partes interessadas com base nos resultados da avaliação.

Esta descrição simplifica em excesso as práticas de implementação e as operações de ML (MLOps). Saiba mais detalhes sobre MLOps em MLOps workflows no Azure Databricks.

7. Coloque em produção

Após a validação de etapas, promova e implemente o modelo em produção para gerar previsões para entradas do mundo real. Azure Databricks suporta dois padrões principais de serviço:

  • Serviço em tempo real: Implemente o modelo como um endpoint REST de baixa latência usando o Model Serving para casos de uso que exijam decisões de baixa latência, como interceção de fraude no momento da transação, personalização em tempo real ou preços dinâmicos.
  • Inferência em lote: ai_query proporciona uma inferência em lote eficiente para modelos personalizados implementados como endpoints de Model Serving. Também pode usar código personalizado com UDFs do Apache Spark (exemplo) ou mlflow.pyfunc para inferência em lote. Os pipelines por lotes gravam os resultados em tabelas Delta para aplicações, painéis ou pipelines subsequentes. Este padrão gere previsões diárias, atualizações noturnas de recomendações e outros trabalhos periódicos.

Ambos os padrões usam o mesmo artefacto de modelo treinado. Treine uma vez e implemente para serviço em lote ou em tempo real a partir da mesma versão registada, com a mesma governação e linhagem.

O Genie Code pode tanto gerar código para implementação como ajudar a resolver problemas de serviço, explicar o comportamento dos endpoints e acelerar a iteração quando os modelos precisam de ser atualizados ou reimplementados.

8. Monitorizar e reeducar

Os sistemas de ML em produção podem degradar-se com o tempo à medida que o comportamento do utilizador muda ou os pipelines de dados mudam. Monitorize continuamente os seus dados de produção e previsões de modelos:

  • Regista as entradas e saídas dos teus modelos implementados. Para servir em tempo real, as tabelas de inferência fornecem registos automáticos sem alterações ao código do seu modelo. No processamento em lote, os seus fluxos de dados leem naturalmente de e escrevem para tabelas Delta geridas no Unity Catalog.
  • Alimente estes registos na monitorização da qualidade dos dados, que acompanha a qualidade dos dados, a deriva das características e a distribuição das previsões ao longo do tempo. Se tiver dados de referência ou de feedback, pode combinar esses dados com os registos de produção para calcular métricas da qualidade das previsões.
  • Use a interface de monitorização e os alertas de deteção de anomalias para desencadear escalonamento ou re-treino antes que a qualidade se degrade visivelmente.

Saiba mais sobre aprendizagem automática em produção em fluxos de trabalho de MLOps no Azure Databricks.

Recursos adicionais

  • Last updated on