Fluxo de trabalho MLOps em Databricks

Este artigo descreve como pode utilizar MLOps na plataforma Databricks para otimizar o desempenho e a eficiência a longo prazo dos seus sistemas machine learning (ML). Inclui recomendações gerais para uma arquitetura MLOps e descreve um fluxo de trabalho generalizado usando a plataforma Databricks que você pode usar como modelo para seu processo de desenvolvimento até a produção de ML.

Para obter mais detalhes, consulte O Grande Livro dos MLOps.

O que é MLOps?

MLOps é um conjunto de processos e passos automatizados para gerenciar código, dados e modelos. Ele combina DevOps, DataOps e ModelOps.

O ML ativo, como código, dados e modelos, é desenvolvido em estágios que progridem desde os estágios iniciais de desenvolvimento, que não têm limitações rígidas de acesso e não são rigorosamente testados, passando por um estágio intermediário de testes, até um estágio final de produção que é rigidamente controlado. A plataforma Databricks permite gerenciar esses ativos em uma única plataforma com controle de acesso unificado. Você pode desenvolver aplicativos de dados e aplicativos de ML na mesma plataforma, reduzindo os riscos e atrasos associados à movimentação de dados.

Recomendações gerais para MLOps

Esta seção inclui algumas recomendações gerais para MLOps em Databricks com links para mais informações.

Crie um ambiente separado para cada estágio

Um ambiente de execução é o local onde os modelos e dados são criados ou consumidos pelo código. Cada ambiente de execução consiste em instâncias compute , seu Runtime e bibliotecas e Job automatizadas.

Databricks recomenda a criação de ambientes separados para os diferentes estágios de código ML e desenvolvimento de modelo com transições claramente definidas entre os estágios. O fluxo de trabalho descrito neste artigo segue este processo, usando os nomes comuns para os estágios:

• Desenvolvimento

• Encenação

• Produção

Outras configurações também podem ser utilizadas para atender às necessidades específicas de sua organização.

Controle de acesso e versionamento

O controle de acesso e o controle de versão são componentes key de qualquer processo de operações de software. Databricks recomenda o seguinte:

• Use o Git para controle de versão. O pipeline e o código devem ser armazenados no Git para controle de versão. Mover a lógica de ML entre os estágios pode ser interpretado como mover o código do ramo de desenvolvimento para o ramo de preparação e para o ramo de lançamento. Use as pastas Git do Databricks para integrar-se ao seu provedor Git e sincronizar o Notebook e o código-fonte com o espaço de trabalho do Databricks. A Databricks também fornece ferramentas adicionais para integração do Git e controle de versão; consulte Ferramentas e orientação para desenvolvedores.

• Armazene dados em uma arquitetura lakehouse usando tabelas Delta. Os dados devem ser armazenados em uma arquitetura lakehouse em sua clouds account. Tanto os dados brutos quanto as tabelas de recursos devem ser armazenados como tabelas Delta com controles de acesso para determinar quem pode lê-los e modificá-los.

• Gerenciar o desenvolvimento de modelos com MLflow. Você pode usar o MLflow para rastrear o processo de desenvolvimento do modelo e salvar Snapshot de código, parâmetros de modelo, métricas e outros metadados.

• Use Models no Unity Catalog para gerenciar o ciclo de vida do modelo. Use os modelos no Unity Catalog para gerenciar o controle de versão, a governança e o status da implantação do modelo.

código aprimorado, não modelos

Na maioria das situações, o Databricks recomenda que, durante o processo de desenvolvimento de ML, você promova code, em vez de models, de um ambiente para outro. Mover os ativos do projeto dessa maneira garante que todo o código no processo de desenvolvimento de ML passe pelos mesmos processos de revisão de código e teste de integração. Ele também garante que a versão de produção do modelo seja treinada no código de produção. Para obter uma discussão mais detalhada sobre as opções e compensações, consulte Padrões de implantação de modelo.

Fluxo de trabalho MLOps recomendado

As seções a seguir descrevem um fluxo de trabalho típico de MLOps, abrangendo cada um dos três estágios: desenvolvimento, preparo e produção.

Esta seção usa os termos “cientista de dados” e “engenheiro de ML” como personas arquetípicas; funções e responsabilidades específicas no fluxo de trabalho MLOps variam entre equipes e organizações.

Estágio de desenvolvimento

O foco da fase de desenvolvimento é a experimentação. cientistas de dados desenvolvem recursos e modelos e experimentos de execução para otimizar o desempenho do modelo. A saída do processo de desenvolvimento é o código ML pipelines que pode incluir computação de recursos, treinamento de modelo, inferência e monitoramento.

Os passos numerados correspondem aos números mostrados no diagrama.

1. fonte de dados

O ambiente de desenvolvimento é representado pelo catálogo dev no Unity Catalog. cientista de dados tem acesso de leitura e gravação ao catálogo de desenvolvimento à medida que cria dados temporários e tabelas de recursos no workspace de desenvolvimento. Os modelos criados na fase de desenvolvimento são registrados no catálogo de desenvolvimento.

Idealmente, o cientista de dados que trabalha no workspace de desenvolvimento também tem acesso somente leitura aos dados de produção no catálogo de produtos. Permitir que cientistas de dados leiam o acesso aos dados de produção, tabelas de inferência e tabelas de métricas no catálogo de produtos permite que eles analisem as previsões e o desempenho do modelo de produção atual. O cientista de dados também deverá ser capaz de carregar modelos de produção para experimentação e análise.

Se não for possível conceder acesso somente leitura ao catálogo de produtos, um Snapshot dos dados de produção pode ser gravado no catálogo de desenvolvimento para permitir que o cientista de dados desenvolva e avalie o código do projeto.

2. Análise exploratória de dados (EDA)

cientista de dados explora e analisa dados em um processo interativo e iterativo usando Notebook. O objetivo é avaliar se os dados disponíveis têm potencial para resolver o problema de negócio. Nesta etapa, o cientista de dados começa a identificar os passos de preparação e caracterização de dados para o treinamento do modelo. Esse processo ad hoc geralmente não faz parte de um pipeline que será implantado em outros ambientes de execução.

O Databricks AutoML acelera esse processo gerando modelos de linha de base para um dataset. O AutoML executa e registra um conjunto de testes e fornece um Python Notebook com o código-fonte para cada execução de teste, para que você possa revisar, reproduzir e modificar o código. O AutoML também calcula estatísticas resumidas em seu dataset e salva essas informações em um Notebook que você pode revisar.

3. Código

O repositório de código contém todos os pipeline, módulos e outros arquivos de projeto de um projeto de ML. cientista de dados cria pipeline novo ou atualizado em um branch de desenvolvimento (“dev”) do repositório do projeto. A partir do EDA e das fases iniciais de um projeto, o cientista de dados deve trabalhar em um repositório para compartilhar código e rastrear alterações.

4. modelo de ensino (desenvolvimento)

cientista de dados desenvolve o pipeline de treinamento do modelo no ambiente de desenvolvimento usando tabelas dos catálogos dev ou prod.

Este pipeline inclui 2 tarefas:

• treinamento e afinação. Os modelos do processo de treinamento registraram parâmetros, métricas e artefatos no servidor de acompanhamento do MLflow. Após o treinamento e ajuste dos hiperparâmetros, o artefato final do modelo é logs no servidor de acompanhamento para registrar um link entre o modelo, os dados de entrada nos quais ele foi treinado e o código usado para gerá-lo.

• Avaliação. Avalie a qualidade do modelo testando dados mantidos. Os resultados desses testes são logs para o servidor de acompanhamento do MLflow. O objetivo da avaliação é determinar se o modelo recém-desenvolvido tem desempenho melhor que o modelo de produção atual. Com permissões suficientes, qualquer modelo de produção registrado no catálogo de produtos pode ser carregado no workspace de desenvolvimento e comparado com um modelo recém-treinado.

  Caso os requisitos de governança da sua organização incluam informações adicionais sobre o modelo, você poderá salvá-las usando o MLflow acompanhamento. Artefatos típicos são descrições de texto simples e interpretações de modelos, como gráficos produzidos pelo SHAP. Os requisitos específicos de governança podem vir de um responsável pela governança de dados ou de partes interessadas empresariais.

A saída do pipeline de treinamento do modelo é um artefato do modelo de ML armazenado no servidor de acompanhamento do MLflow para o ambiente de desenvolvimento. Se o pipeline for executado no workspace temporário ou de produção, o artefato do modelo será armazenado no servidor de acompanhamento do MLflow para esse workspace.

Quando o treinamento do modelo for concluído, registre o modelo no Catálogo do Unity. Configure o código do seu pipeline para registrar o modelo no catálogo correspondente ao ambiente em que o pipeline do modelo foi executado; neste exemplo, o catálogo de desenvolvimento.

Com a arquitetura recomendada, você implementou um fluxo de trabalho multitarefa do Databricks em que a primeira tarefa é o pipeline de treinamento do modelo, seguido pela validação do modelo e pelas tarefas de implantação do modelo. A tarefa de treinamento de modelo produz um URI de modelo que a tarefa de validação de modelo pode usar. Você pode usar valores de tarefa para passar esse URI para o modelo.

5. Validar e implantar modelo (desenvolvimento)

Além do pipeline de treinamento de modelo, outros pipelines, como validação de modelo e pipeline de implantação de modelo, são desenvolvidos no ambiente de desenvolvimento.

• Validação do modelo. O pipeline de validação do modelo pega o URI do modelo do pipeline de treinamento do modelo, carrega o modelo do Unity Catalog e verifica a validação de execução.

  As verificações de validação dependem do contexto. Eles podem incluir verificações fundamentais, como a confirmação do formato e dos metadados necessários, e verificações mais complexas que podem ser necessárias para indústrias altamente regulamentadas, como verificações compliance predefinidas e confirmação do desempenho do modelo em fatias de dados selecionadas.

  A função principal do pipeline de validação de modelo é determinar se um modelo deve prosseguir para a implantação ou passo. Se o modelo passar nas verificações de pré-implantação, ele poderá receber o alias “Challenger” no Unity Catalog. Se as verificações falharem, o processo termina. Você pode configurar seu fluxo de trabalho para notificar os usuários sobre uma falha de validação. Consulte Adicionar notificações email e do sistema para eventos Job .

• Implantação do modelo. O pipeline de implantação do modelo normalmente promove diretamente o modelo “Challenger” recém-treinado ao status de “Champion” usando uma atualização de alias ou facilita uma comparação entre o modelo “Champion” existente e o novo modelo “Challenger”. Este pipeline também pode configurar qualquer infraestrutura de inferência necessária, como o modelo de instalação endpoint. Para uma discussão detalhada dos passos envolvidos no pipeline de implantação do modelo, consulte Produção.

6. Confirme o código

Depois de desenvolver o código para treinamento, validação, implantação e outros pipeline, o cientista de dados ou engenheiro de ML commit as alterações do branch de desenvolvimento para o controle de origem.

Estágio de preparação

O foco desta passo é testar o código ML pipelines para garantir que esteja pronto para produção. Todo o código ML pipelines é testado neste estágio, incluindo código para treinamento de modelo, bem como pipelines de engenharia de recursos, código de inferência e assim por diante.

Os engenheiros de ML criam um pipeline de CI para implementar a execução dos testes de unidade e integração nesta passo. A saída do processo de encenação é um ramo de liberação que aciona o sistema CI/CD para iniciar a fase de produção.

1. Dados

O ambiente de teste deve ter seu próprio catálogo no Unity Catalog para testar ML pipelines e modelos de registro no Unity Catalog. Este catálogo é mostrado como o catálogo de “preparo” no diagrama. ativos gravados neste catálogo são geralmente temporários e retidos apenas até que o teste seja concluído. O ambiente de desenvolvimento também pode exigir acesso ao catálogo de teste para fins de depuração.

2. Mesclar código

cientista de dados desenvolve o pipeline de treinamento do modelo no ambiente de desenvolvimento utilizando tabelas dos catálogos de desenvolvimento ou produção.

• Solicitação de pull. O processo de implantação começa quando uma solicitação pull é criada na ramificação principal do projeto no controle de origem.

• Testes unitários (CI). A solicitação pull cria automaticamente o código-fonte e aciona testes de unidade. Se os testes de unidade falharem, a solicitação pull será rejeitada.

  Os testes unitários fazem parte do processo de desenvolvimento de software e são continuamente executados e adicionados à base de código durante o desenvolvimento de qualquer código. A execução de testes de unidade como parte de um pipeline de CI garante que as alterações feitas em uma ramificação de desenvolvimento não interrompam a funcionalidade existente.

3. Testes de integração (CI)

O processo de CI então executa os testes de integração. A integração testa a execução de todos os pipelines (incluindo engenharia de recursos, treinamento de modelo, inferência e monitoramento) para garantir que funcionem corretamente juntos. O ambiente de preparação deve corresponder ao ambiente de produção o mais próximo possível.

Se você estiver implantando um aplicativo de ML com inferência em tempo real, deverá criar e testar a infraestrutura de atendimento no ambiente de teste. Isto envolve acionar o pipeline de implantação do modelo, que cria um endpoint de serviço no ambiente de preparação e carrega um modelo.

Para reduzir o tempo necessário para a execução dos testes de integração, alguns passos podem equilibrar entre fidelidade dos testes e velocidade ou custo. Por exemplo, se os modelos forem caros ou demorados para serem ensinados, você poderá usar pequenos subconjuntos de dados ou executar menos iterações de treinamento. Para o modelo de operação, dependendo dos requisitos de produção, você pode fazer testes de carga em grande escala em testes de integração ou apenas testar pequenos trabalhos em lote ou solicitações para um endpoint temporário.

4. Mesclar para ramificação de teste

Se todos os testes forem aprovados, o novo código será merge no branch principal do projeto. Se os testes falharem, o sistema CI/CD deverá notificar os usuários e publicar os resultados na solicitação pull.

Você pode programar testes periódicos de integração na ramificação principal. Esta é uma boa ideia se o branch for atualizado frequentemente com solicitações pull simultâneas de vários usuários.

5. Crie uma ramificação de lançamento

Depois que os testes de CI forem aprovados e a ramificação dev for merge na ramificação principal, o engenheiro de ML cria uma ramificação de lançamento, que aciona o sistema CI/CD para atualizar Job de produção.

Fase de produção

Os engenheiros de ML possuem o ambiente de produção onde ML pipelines são implantados e executados. Esses pipeline acionam o treinamento do modelo, validam e implantam novas versões do modelo, publicam previsões em tabelas ou aplicativos downstream e monitoram todo o processo para evitar degradação e instabilidade do desempenho.

cientista de dados normalmente não tem acesso de gravação ou compute no ambiente de produção. No entanto, é importante que eles tenham visibilidade dos resultados dos testes, dos artefatos registrados nos modelos, do status do pipeline de produção e das tabelas de monitoramento. Essa visibilidade permite identificar e diagnosticar problemas na produção e comparar o desempenho de novos modelos com modelos atualmente em produção. Você pode conceder ao cientista de dados acesso somente leitura ao ativo no catálogo de produção para esses fins.

Os passos numerados correspondem aos números mostrados no diagrama.

1. modelo de ensino

Esse pipeline pode ser acionado por alterações de código ou por retreinamento automatizado Job. Neste passo são utilizadas tabelas do catálogo de produção para os passos seguintes.

• treinamento e afinação. Durante o processo de treinamento, os logs são registrados no servidor de acompanhamento MLflow do ambiente de produção. Esses logs incluem métricas do modelo, parâmetros, tags e o próprio modelo. Se você usar tabelas de recursos, o modelo será logs no MLflow usando o cliente Databricks Feature Store, que empacota o modelo com informações de pesquisa de recursos usadas no momento da inferência.

  Durante o desenvolvimento, o cientista de dados pode testar muitos algoritmos e hiperparâmetros. No código de treinamento de produção, é comum considerar apenas as opções de melhor desempenho. Limitar o ajuste dessa maneira economiza tempo e pode reduzir a variação do ajuste no retreinamento automatizado.

  Se o cientista de dados tiver acesso somente leitura ao catálogo de produção, ele poderá determinar o conjunto ideal de hiperparâmetros para um modelo. Nesse caso, o pipeline de treinamento de modelo implantado na produção pode ser executado usando o conjunto selecionado de hiperparâmetros, normalmente incluído no pipeline como um arquivo de configuração.

• Avaliação. A qualidade do modelo é avaliada por testes em dados de produção retidos. Os resultados desses testes são logs no servidor de acompanhamento do MLflow. Esta passo usa as métricas de avaliação especificadas pelo cientista de dados na passo de desenvolvimento. Essas métricas podem incluir código personalizado.

• modelo de registro. Quando o treinamento do modelo for concluído, o artefato do modelo será salvo como uma versão de modelo registrada no caminho do modelo especificado no catálogo de produção no Unity Catalog. A tarefa de treinamento de modelo produz um URI de modelo que a tarefa de validação de modelo pode usar. Você pode usar valores de tarefa para passar esse URI para o modelo.

2. Validar modelo

Este pipeline usa o URI do modelo da etapa 1 e carrega o modelo do Unity Catalog. Em seguida, ele executa uma série de verificações de validação. Essas verificações dependem da sua organização e do caso de uso e podem incluir itens como validações básicas de formato e metadados, avaliações de desempenho em fatias de dados selecionadas e compliance com requisitos organizacionais, como verificações compliance para tags ou documentação.

Se o modelo passar com êxito em todas as verificações de validação, você poderá atribuir o alias “Challenger” à versão do modelo no Unity Catalog. Se o modelo não passar em todas as verificações de validação, o processo será encerrado e os usuários poderão ser notificados automaticamente. Você pode usar tags para adicionar atributos de valor- keydependendo do resultado dessas verificações de validação. Por exemplo, você pode criar tags “model_validation_status” e definir o valor como “PENDING” conforme os testes são executados e, em seguida, atualizá-lo para “PASSED” ou “FAILED” quando o pipeline for concluído.

Como o modelo está registrado no Unity Catalog, o cientista de dados que trabalha no ambiente de desenvolvimento pode carregar esta versão do modelo do catálogo de produção para investigar se o modelo falha na validação. Independentemente do resultado, os resultados são registrados no modelo cadastrado no catálogo de produção utilizando anotação para a versão do modelo.

3. Modelo implantado

Assim como o pipeline de validação, o pipeline de implantação do modelo depende da sua organização e do caso de uso. Esta seção pressupõe que você atribuiu ao modelo recém-validado o alias “Challenger” e que o modelo de produção existente recebeu o alias “Champion”. O primeiro passo antes de implantar o novo modelo é confirmar se ele tem um desempenho pelo menos tão bom quanto o modelo de produção atual.

• Compare o modelo “CHALLENGER” com o “CHAMPION”. Você pode realizar essa comparação offline ou online. Uma comparação offline avalia ambos os modelos em relação a um conjunto de dados retido e rastreia os resultados usando o servidor de acompanhamento MLflow. Para o modelo de atividade em tempo real, você pode querer realizar comparações online mais longas, como testes A/B ou uma implementação gradual do novo modelo. Caso a versão do modelo “Challenger” tenha melhor desempenho na comparação, ela substitui o atual pseudônimo “Champion”.

  O modelo de operação do Databricks e o Databricks Lakehouse Monitoring permitem coletar e monitorar automaticamente tabelas de inferência que contêm dados de solicitação e resposta para um endpoint.

  Se não existir um modelo “Campeão”, você poderá comparar o modelo “Desafiador” a uma heurística de negócios ou outro limite como linha de base.

  O processo descrito aqui é totalmente automatizado. Se a aprovação manual dos passos for necessária, você poderá configurá-los usando notificações de fluxo de trabalho ou retornos de chamada de CI/CD do pipeline de implantação do modelo.

• modelo implantado. lotes ou pipeline inferência de transmissão podem ser configurados para usar o modelo com o alias “Champion”. Para casos de uso em tempo real, você deve configurar a infraestrutura para implantar o modelo como um endpoint da API REST. Você pode criar e gerenciar esse endpoint usando o modelo instalado do Databricks. Se um endpoint já estiver em uso para o modelo atual, será possível atualizar o endpoint com o novo modelo. O modelo de atividade do Databricks executa uma atualização com tempo de inatividade zero, mantendo a configuração existente em execução até que a nova esteja pronta.

4. Modelo de atividade

Ao configurar um endpoint de modelo funcional, você especifica o nome do modelo no Unity Catalog e a versão a ser veiculada. Se a versão do modelo foi treinada usando recursos de tabelas no Unity Catalog, o modelo armazena as dependências do recurso e das funções. O modelo específico utiliza automaticamente este gráfico de dependência para consultar recursos de lojas online apropriadas no momento da inferência. Esta abordagem também pode ser usada para aplicar funções para pré-processamento de dados ou para compute recursos sob demanda durante a pontuação do modelo.

Você pode criar um único endpoint com vários modelos e especificar a divisão do tráfego do endpoint entre esses modelos, permitindo realizar comparações online de “Campeão” versus “Desafiador”.

5. Inferência: lotes ou transmissão

O pipeline de inferência lê os dados mais recentes do catálogo de produção, executa funções para compute recursos sob demanda, carrega o modelo “Champion”, pontua os dados e retorna previsões. inferência de lotes ou transmissão é geralmente a opção mais econômica para casos de uso de taxa de transferência mais alta e latência mais alta. Para cenários em que são necessárias previsões de baixa latência, mas as previsões podem ser compute offline, essas previsões de lotes podem ser publicadas em um armazenamento keyonline, como DynamoDB ou Cosmos DB.

O modelo registrado no Unity Catalog é referenciado por seu alias. O pipeline de inferência está configurado para carregar e aplicar a versão do modelo “Champion”. Se a versão “Champion” for atualizada para uma nova versão do modelo, o pipeline de inferência usará automaticamente a nova versão para sua próxima execução. Desta forma, a implantação do modelo o passo é desacoplada do pipeline de inferência.

trabalho em lote normalmente publica previsões em tabelas no catálogo de produção, em arquivos simples ou em uma conexão JDBC. Job de transmissão normalmente publica previsões em tabelas do Catálogo do Unity ou em filas de mensagens como Apache Kafka.

6. Lakehouse Monitoring

O Lakehouse Monitoring monitora propriedades estatísticas, como desvio de dados e desempenho do modelo, de dados de entrada e previsões de modelo. Você pode criar alertas com base nessas métricas ou publicá-los em dashboards.

• ingestão de dados. Este pipeline lê logs de lotes, transmissão ou inferência online.

• Verifique a precisão e o desvio de dados. O pipeline compute métricas sobre os dados de entrada, as previsões do modelo e o desempenho da infraestrutura. cientista de dados especifica métricas de dados e modelos durante o desenvolvimento, e engenheiros de ML especificam métricas de infraestrutura. Você também pode definir métricas personalizadas com Lakehouse Monitoring.

• Publique métricas e configure alertas. O pipeline grava em tabelas do catálogo de produção para análise e geração de relatórios. Você deve configurar essas tabelas para serem legíveis no ambiente de desenvolvimento para que cientistas de dados tenham acesso para análise. Você pode usar o Databricks SQL para criar painéis de monitoramento para acompanhar o desempenho do modelo e configurar o Job de monitoramento ou a ferramenta de painel para emitir uma notificação quando uma análise exceder um limite especificado.

• Acione o retreinamento do modelo. Quando as métricas de monitoramento indicam problemas de desempenho ou alterações nos dados de entrada, o cientista de dados pode precisar desenvolver uma nova versão do modelo. Você pode configurar o alerta SQL para notificar o cientista de dados quando isso acontecer.

7. Retreinamento

Essa arquitetura oferece suporte ao retreinamento automático usando o mesmo modelo de pipeline de treinamento acima. A Databricks recomenda começar com um retreinamento periódico e programado e passar para um retreinamento acionado quando necessário.

• Agendado. Se novos dados estiverem disponíveis regularmente, você poderá criar um Jobagendado para executar o código de treinamento do modelo nos dados disponíveis mais recentes.

• Provocado. Se o pipeline de monitoramento puder identificar problemas de desempenho do modelo e enviar alertas, ele também poderá desencadear um novo treinamento. Por exemplo, se a distribuição dos dados recebidos mudar significativamente ou se o desempenho do modelo diminuir, o retreinamento e a redistribuição automáticos podem aumentar o desempenho do modelo com o mínimo de intervenção humana. Isto pode ser conseguido através de um alerta SQL para verificar se uma informação é anômala (por exemplo, verificar o desvio ou a qualidade do modelo em relação a um limite). O alerta pode ser configurado para usar um destino de webhook, que pode posteriormente acionar o fluxo de trabalho de treinamento.

Se o pipeline de retreinamento ou outros pipelines apresentarem problemas de desempenho, o cientista de dados poderá precisar retornar ao ambiente de desenvolvimento para experimentação adicional para resolver os problemas.