Fluxos de trabalho MLOps no Azure Databricks
Este artigo descreve como você pode usar MLOps na plataforma Databricks para otimizar o desempenho e a eficiência de longo prazo de seus sistemas de aprendizado de máquina (ML). Ele 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 para produção de ML. Para modificações desse fluxo de trabalho para aplicativos LLMOps, consulte Fluxos de trabalho LLMOps.
Para obter mais detalhes, consulte O Grande Livro dos MLOps.
O que é o MLOps?
MLOps é um conjunto de processos e etapas automatizadas para gerenciar código, dados e modelos para melhorar o desempenho, a estabilidade e a eficiência a longo prazo dos sistemas de ML. Ele combina DevOps, DataOps e ModelOps.
Os ativos de ML, como código, dados e modelos, são desenvolvidos em estágios que progridem desde os estágios iniciais de desenvolvimento que não têm limitações de acesso rígidas e não são rigorosamente testados, através de um estágio de teste intermediário, até um estágio de produção final que é rigorosamente 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 no Databricks com links para obter mais informações.
Crie um ambiente separado para cada estágio
Um ambiente de execução é o local onde modelos e dados são criados ou consumidos pelo código. Cada ambiente de execução consiste em instâncias de computação, seus tempos de execução e bibliotecas e trabalhos automatizados.
O Databricks recomenda a criação de ambientes separados para os diferentes estágios de código de ML e desenvolvimento de modelos com transições claramente definidas entre estágios. O fluxo de trabalho descrito neste artigo segue esse processo, usando os nomes comuns para os estágios:
Outras configurações também podem ser usadas para atender às necessidades específicas da sua organização.
Controle de acesso e controle de versão
O controle de acesso e o controle de versão são componentes-chave de qualquer processo de operações de software. A Databricks recomenda o seguinte:
- Use o Git para controle de versão. Pipelines e código devem ser armazenados no Git para controle de versão. Mover a lógica de ML entre os estágios pode então ser interpretado como mover o código da ramificação de desenvolvimento, para a ramificação de preparo, para a ramificação de versão. Use pastas Git Databricks para integrar com seu provedor Git e sincronizar blocos de anotações e código-fonte com espaços de trabalho Databricks. O Databricks também fornece ferramentas adicionais para integração com Git e controle de versão; consulte Ferramentas de desenvolvedor.
- Armazene dados em uma arquitetura lakehouse usando tabelas Delta. Os dados devem ser armazenados em uma arquitetura lakehouse em sua conta na nuvem. Os dados brutos e as tabelas de recursos devem ser armazenados como tabelas Delta com controles de acesso para determinar quem pode lê-las e modificá-las.
- Gerencie o desenvolvimento de modelos com MLflow. Você pode usar o MLflow para acompanhar o processo de desenvolvimento do modelo e salvar instantâneos de código, parâmetros do modelo, métricas e outros metadados.
- Use Modelos no Unity Catalog para gerenciar o ciclo de vida do modelo. Use Modelos no Unity Catalog para gerenciar o controle de versão, a governança e o status de implantação do modelo.
Implantar código, não modelos
Na maioria das situações, o Databricks recomenda que, durante o processo de desenvolvimento de ML, você promova código, em vez de modelos, de um ambiente para o outro. Mover ativos de 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 das 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 MLOps típico, cobrindo cada um dos três estágios: desenvolvimento, preparação 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.
Fase de desenvolvimento
O foco da etapa de desenvolvimento é a experimentação. Os cientistas de dados desenvolvem recursos e modelos e executam experimentos para otimizar o desempenho do modelo. A saída do processo de desenvolvimento é o código de pipeline de ML que pode incluir computação de recursos, treinamento de modelos, inferência e monitoramento.
Os passos numerados correspondem aos números mostrados no diagrama.
1. Fontes de dados
O ambiente de desenvolvimento é representado pelo catálogo de desenvolvimento no Unity Catalog. Os cientistas de dados têm acesso de leitura e gravação ao catálogo de desenvolvimento à medida que criam dados temporários e tabelas de recursos no espaço de trabalho de desenvolvimento. Os modelos criados no estágio de desenvolvimento são registrados no catálogo de desenvolvimento.
Idealmente, os cientistas de dados que trabalham no espaço de trabalho de desenvolvimento também têm acesso somente leitura aos dados de produção no catálogo prod. Permitir que os cientistas de dados leiam o acesso aos dados de produção, tabelas de inferência e tabelas métricas no catálogo prod permite que eles analisem as previsões e o desempenho do modelo de produção atual. Os cientistas de dados também devem ser capazes 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 prod, um instantâneo dos dados de produção pode ser gravado no catálogo de desenvolvimento para permitir que os cientistas de dados desenvolvam e avaliem o código do projeto.
2. Análise exploratória de dados (AED)
Os cientistas de dados exploram e analisam dados em um processo interativo e iterativo usando notebooks. O objetivo é avaliar se os dados disponíveis têm potencial para resolver o problema do negócio. Nesta etapa, o cientista de dados começa a identificar as etapas de preparação e featurização de dados para o treinamento de modelos. Esse processo ad hoc geralmente não faz parte de um pipeline que será implantado em outros ambientes de execução.
O AutoML acelera esse processo gerando modelos de linha de base para um conjunto de dados. O AutoML executa e registra um conjunto de avaliações e fornece um bloco de anotações Python com o código-fonte de cada execução de avaliação, para que você possa revisar, reproduzir e modificar o código. O AutoML também calcula estatísticas resumidas em seu conjunto de dados e salva essas informações em um bloco de anotações que você pode revisar.
3. Código
O repositório de código contém todos os pipelines, módulos e outros arquivos de projeto para um projeto de ML. Os cientistas de dados criam pipelines novos ou atualizados em uma ramificação de desenvolvimento ("dev") do repositório do projeto. A partir da EDA e das fases iniciais de um projeto, os cientistas de dados devem trabalhar em um repositório para compartilhar código e rastrear alterações.
4. Modelo de comboio (desenvolvimento)
Os cientistas de dados desenvolvem o pipeline de treinamento de modelos no ambiente de desenvolvimento usando tabelas dos catálogos dev ou prod.
Este pipeline inclui 2 tarefas:
Formação e afinação. O processo de treinamento registra parâmetros, métricas e artefatos do modelo no servidor MLflow Tracking. Depois de treinar e ajustar os hiperparâmetros, o artefato do modelo final é registrado no servidor de rastreamento 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 retidos. Os resultados desses testes são registrados no servidor MLflow Tracking. O objetivo da avaliação é determinar se o modelo recém-desenvolvido tem um desempenho melhor do que o modelo de produção atual. Com permissões suficientes, qualquer modelo de produção registrado no catálogo prod pode ser carregado no espaço de trabalho de desenvolvimento e comparado com um modelo recém-treinado.
Se os requisitos de governança da sua organização incluírem informações adicionais sobre o modelo, você poderá salvá-lo usando o rastreamento MLflow. Artefatos típicos são descrições de texto simples e interpretações de modelos, como plotagens produzidas por SHAP. Os requisitos específicos de governança podem vir de um responsável pela governança de dados ou partes interessadas do negócio.
A saída do pipeline de treinamento do modelo é um artefato de modelo de ML armazenado no servidor MLflow Tracking para o ambiente de desenvolvimento. Se o pipeline for executado no espaço de trabalho de preparação ou produção, o artefato do modelo será armazenado no servidor MLflow Tracking desse espaço de trabalho.
Quando o treinamento do modelo estiver concluído, registre-o no Unity Catalog. Configure o código do 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ê implanta um fluxo de trabalho Databricks multitarefa no qual a primeira tarefa é o pipeline de treinamento de modelo, seguido por tarefas de validação e implantação de modelo. A tarefa de treinamento do modelo produz um URI do modelo que a tarefa de validação do 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 pipelines de implantação de modelo, são desenvolvidos no ambiente de desenvolvimento.
Validação do modelo. O pipeline de validação do modelo obtém o URI do modelo do pipeline de treinamento do modelo, carrega o modelo do Unity Catalog e executa verificações de validaçã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 setores altamente regulamentados, como verificações de conformidade predefinidas e confirmação do desempenho do modelo em fatias de dados selecionadas.
A função principal do pipeline de validação do modelo é determinar se um modelo deve prosseguir para a etapa de implantação. 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 de uma falha de validação. Consulte Adicionar notificações por e-mail e do sistema para eventos de trabalho.
Implantação do modelo. O pipeline de implantação do modelo normalmente promove diretamente o modelo "Challenger" recém-treinado para o status "Champion" usando uma atualização de alias ou facilita uma comparação entre o modelo "Champion" existente e o novo modelo "Challenger". Esse pipeline também pode configurar qualquer infraestrutura de inferência necessária, como pontos de extremidade de serviço de modelo. Para obter uma discussão detalhada das etapas envolvidas no pipeline de implantação do modelo, consulte Produção.
6. Código de confirmação
Depois de desenvolver código para treinamento, validação, implantação e outros pipelines, o cientista de dados ou engenheiro de ML confirma as alterações da ramificação de desenvolvimento no controle do código-fonte.
Estágio de preparação
O foco desta etapa é testar o código de pipeline de ML para garantir que ele esteja pronto para produção. Todo o código de pipeline de ML é testado nesta etapa, 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 unidade e os testes de integração são executados nesta etapa. A saída do processo de preparação é uma ramificação de lançamento que aciona o sistema CI/CD para iniciar a etapa de produção.
1. Dados
O ambiente de preparo deve ter seu próprio catálogo no Unity Catalog para testar pipelines de ML e registrar modelos no Unity Catalog. Este catálogo é mostrado como o catálogo de "preparação" no diagrama. Os 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 preparo para fins de depuração.
2. Código de mesclagem
Os cientistas de dados desenvolvem o pipeline de treinamento do modelo no ambiente de desenvolvimento usando tabelas dos catálogos de desenvolvimento ou produção.
Pull request. O processo de implantação começa quando uma solicitação pull é criada em relação à ramificação principal do projeto no controle do código-fonte.
Testes unitários (IC). 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 de unidade 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 (IC)
Em seguida, o processo de CI executa os testes de integração. Os testes de integração executam todos os pipelines (incluindo engenharia de recursos, treinamento de modelos, inferência e monitoramento) para garantir que eles 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 serviço no ambiente de preparação. Isso envolve acionar o pipeline de implantação do modelo, que cria um ponto de extremidade de serviço no ambiente de preparo e carrega um modelo.
Para reduzir o tempo necessário para executar testes de integração, algumas etapas podem trocar entre fidelidade de teste e velocidade ou custo. Por exemplo, se os modelos forem caros ou demorados para treinar, você pode usar pequenos subconjuntos de dados ou executar menos iterações de treinamento. Para o serviço de modelo, dependendo dos requisitos de produção, você pode fazer testes de carga em escala total em testes de integração ou pode apenas testar pequenos trabalhos em lote ou solicitações para um ponto de extremidade temporário.
4. Mesclar para ramificação de preparo
Se todos os testes forem aprovados, o novo código será mesclado na ramificação principal do projeto. Se os testes falharem, o sistema CI/CD deve notificar os usuários e postar os resultados na solicitação pull.
Você pode agendar testes de integração periódicos na ramificação principal. Essa é uma boa ideia se a ramificação for atualizada com freqüência com solicitações pull simultâneas de vários usuários.
5. Criar uma ramificação de liberação
Depois que os testes de CI passam e a ramificação de desenvolvimento é mesclada na ramificação principal, o engenheiro de ML cria uma ramificação de versão, que aciona o sistema de CI/CD para atualizar os trabalhos de produção.
Fase de produção
Os engenheiros de ML são proprietários do ambiente de produção onde os pipelines de ML são implantados e executados. Esses pipelines 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.
Os cientistas de dados normalmente não têm acesso de gravação ou computação no ambiente de produção. No entanto, é importante que eles tenham visibilidade para testar resultados, logs, artefatos de modelo, status do pipeline de produção e tabelas de monitoramento. Esta visibilidade permite-lhes identificar e diagnosticar problemas na produção e comparar o desempenho de novos modelos com modelos atualmente em produção. Você pode conceder aos cientistas de dados acesso somente leitura aos ativos no catálogo de produção para esses fins.
Os passos numerados correspondem aos números mostrados no diagrama.
1. Modelo de comboio
Esse pipeline pode ser acionado por alterações de código ou por trabalhos de retreinamento automatizado. Nesta etapa, as tabelas do catálogo de produção são usadas para as etapas a seguir.
Formação e afinação. Durante o processo de treinamento, os logs são registrados no servidor MLflow Tracking 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á registrado 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, os cientistas de dados podem 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 forma economiza tempo e pode reduzir a variação do ajuste no retreinamento automatizado.
Se os cientistas de dados tiverem acesso somente leitura ao catálogo de produção, eles poderão determinar o conjunto ideal de hiperparâmetros para um modelo. Nesse caso, o pipeline de treinamento do modelo implantado na produção pode ser executado usando o conjunto selecionado de hiperparâmetros, normalmente incluídos no pipeline como um arquivo de configuração.
Avaliação. A qualidade do modelo é avaliada por meio de testes em dados de produção retidos. Os resultados desses testes são registrados no servidor de rastreamento MLflow. Esta etapa usa as métricas de avaliação especificadas pelos cientistas de dados no estágio de desenvolvimento. Essas métricas podem incluir código personalizado.
Modelo de registo. Quando o treinamento do modelo é concluído, o artefato do modelo é salvo como uma versão do modelo registrado no caminho do modelo especificado no catálogo de produção no Unity Catalog. A tarefa de treinamento do modelo produz um URI do modelo que a tarefa de validação do modelo pode usar. Você pode usar valores de tarefa para passar esse URI para o modelo.
2. Validar modelo
Esse pipeline usa o URI do modelo da Etapa 1 e carrega o modelo do Unity Catalog. Em seguida, executa uma série de verificações de validação. Essas verificações dependem da sua organização e do seu caso de uso, e podem incluir coisas como validações básicas de formato e metadados, avaliações de desempenho em fatias de dados selecionadas e conformidade com requisitos organizacionais, como verificações de conformidade 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 é encerrado e os usuários podem ser notificados automaticamente. Você pode usar tags para adicionar atributos chave-valor dependendo do resultado dessas verificações de validação. Por exemplo, você pode criar uma tag "model_validation_status" e definir o valor como "PENDING" à medida que 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, os cientistas de dados que trabalham no ambiente de desenvolvimento podem carregar essa 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 registrado no catálogo de produção usando anotações na versão do modelo.
3. Modelo de implantação
Assim como o pipeline de validação, o pipeline de implantação do modelo depende da sua organização e do seu 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". A primeira etapa antes de implantar o novo modelo é confirmar se ele funciona pelo menos tão bem quanto o modelo de produção atual.
Compare o modelo "CHALLENGER" com o modelo "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 retidos e rastreia os resultados usando o servidor MLflow Tracking. Para servir o modelo em tempo real, convém realizar comparações on-line de execução mais longa, como testes A/B ou uma implantação gradual do novo modelo. Se a versão do modelo "Challenger" tiver um melhor desempenho na comparação, ela substituirá o alias "Champion" atual.
O Mosaic AI Model Serving 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 ponto de extremidade.
Se não houver nenhum modelo "Campeão" existente, você pode comparar o modelo "Challenger" com uma heurística de negócios ou outro limite como uma linha de base.
O processo descrito aqui é totalmente automatizado. Se forem necessárias etapas de aprovação manual, você poderá configurá-las usando notificações de fluxo de trabalho ou retornos de chamada de CI/CD do pipeline de implantação do modelo.
Implantar modelo. Pipelines de inferência em lote ou streaming podem ser configurados para usar o modelo com o alias "Campeão". Para casos de uso em tempo real, você deve configurar a infraestrutura para implantar o modelo como um ponto de extremidade da API REST. Você pode criar e gerenciar esse endpoint usando o Mosaic AI Model Serving. Se um ponto de extremidade já estiver em uso para o modelo atual, você poderá atualizá-lo com o novo modelo. O Mosaic AI Model Serving executa uma atualização de tempo de inatividade zero, mantendo a configuração existente em execução até que a nova esteja pronta.
4. Modelo de Porção
Ao configurar um ponto de extremidade de serviço de modelo, você especifica o nome do modelo no Unity Catalog e a versão a ser servida. Se a versão do modelo foi treinada usando recursos de tabelas no Unity Catalog, o modelo armazena as dependências para os recursos e funções. O Model Serving usa automaticamente esse gráfico de dependência para procurar recursos de lojas online apropriadas no momento da inferência. Essa abordagem também pode ser usada para aplicar funções para pré-processamento de dados ou para calcular recursos sob demanda durante a pontuação do modelo.
Você pode criar um único ponto de extremidade com vários modelos e especificar a divisão de tráfego de ponto de extremidade entre esses modelos, permitindo que você realize comparações online "Campeão" versus "Desafiante".
5. Inferência: lote ou streaming
O pipeline de inferência lê os dados mais recentes do catálogo de produção, executa funções para calcular recursos sob demanda, carrega o modelo "Campeão", pontua os dados e retorna previsões. A inferência em lote ou streaming é geralmente a opção mais econômica para casos de uso de maior taxa de transferência e maior latência. Para cenários em que previsões de baixa latência são necessárias, mas as previsões podem ser calculadas offline, essas previsões em lote podem ser publicadas em um armazenamento de chave-valor online, como o DynamoDB ou o Cosmos DB.
O modelo registrado no Unity Catalog é referenciado por seu alias. O pipeline de inferência é configurado para carregar e aplicar a versão do modelo "Champion". Se a versão "Campeão" 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. Dessa forma, a etapa de implantação do modelo é dissociada dos pipelines de inferência.
Os trabalhos em lote normalmente publicam previsões em tabelas no catálogo de produção, em arquivos simples ou em uma conexão JDBC. Os trabalhos de streaming normalmente publicam previsões para tabelas do Catálogo Unity ou para filas de mensagens como o Apache Kafka.
6. Monitorização Lakehouse
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 painéis.
- Ingestão de dados. Esse pipeline lê em logs de lote, streaming ou inferência online.
- Verifique a precisão e o desvio de dados. O pipeline calcula métricas sobre os dados de entrada, as previsões do modelo e o desempenho da infraestrutura. Os cientistas de dados especificam dados e métricas de modelo durante o desenvolvimento, e os engenheiros de ML especificam métricas de infraestrutura. Você também pode definir métricas personalizadas com o Lakehouse Monitoring.
- Publique métricas e configure alertas. O pipeline grava em tabelas no catálogo de produção para análise e emissão de relatórios. Você deve configurar essas tabelas para serem legíveis a partir do ambiente de desenvolvimento para que os 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 trabalho de monitoramento ou a ferramenta de painel para emitir uma notificação quando uma métrica exceder um limite especificado.
- Retreinamento do modelo de gatilho. 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 alertas SQL para notificar cientistas de dados quando isso acontecer.
7. Reconversão profissional
Essa arquitetura oferece suporte ao retreinamento automático usando o mesmo pipeline de treinamento de modelo acima. A Databricks recomenda começar com um retreinamento programado e periódico e passar para o retreinamento acionado quando necessário.
- Agendado: Se novos dados estiverem disponíveis regularmente, você poderá criar um trabalho agendado para executar o código de treinamento do modelo nos dados disponíveis mais recentes. Consulte Tipos de gatilho para trabalhos do Databricks
- Acionado. Se o pipeline de monitoramento puder identificar problemas de desempenho do modelo e enviar alertas, ele também poderá acionar o retreinamento. Por exemplo, se a distribuição dos dados recebidos mudar significativamente ou se o desempenho do modelo diminuir, o retreinamento e a reimplantação automáticos podem aumentar o desempenho do modelo com intervenção humana mínima. Isso pode ser conseguido por meio de um alerta SQL para verificar se uma métrica é anômala (por exemplo, verificar desvio ou 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 pode precisar retornar ao ambiente de desenvolvimento para experimentação adicional para resolver os problemas.