Fluxos de trabalho de MLOps no Azure Databricks
Este artigo descreve como você pode usar o MLOps na plataforma Databricks para otimizar o desempenho e a eficiência de longo prazo nos sistemas de ML (machine learning). 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 o processo de desenvolvimento para produção de ML. Para obter modificações desse fluxo de trabalho para aplicativos LLMOps, consulte fluxos de trabalho do LLMOps.
Para mais detalhes, consulte O Grande Livro do MLOps.
O que é MLOps?
O 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 de longo prazo em sistemas de ML. Ele combina DevOps, DataOps e ModelOps.
Ativos de ML, como código, dados e modelos, são desenvolvidos em estágios que progridem desde estágios iniciais de desenvolvimento que não têm limitações de acesso apertadas e não são rigorosamente testados, por meio de um estágio de teste intermediário, para um estágio de produção final que é fortemente controlado. A plataforma Databricks permite que você gerencie esses ativos em uma única plataforma com controle de acesso unificado. Você pode desenvolver aplicativos de dados e aplicativos 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.
Criar um ambiente separado para cada estágio
Um ambiente de execução é o local em que modelos e dados são criados ou consumidos por código. Cada ambiente de execução consiste em instâncias de computação, seus runtimes e bibliotecas e trabalhos automatizados.
O Databricks recomenda a criação de ambientes separados para os diferentes estágios de desenvolvimento de código ML e modelo com transições claramente definidas entre estágios. O fluxo de trabalho descrito neste artigo segue esse processo, usando os nomes comuns para as fases:
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
Controle de acesso e controle de versão são componentes-chave de qualquer processo de operações de software. O Databricks recomenda o seguinte:
- Usar 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 estágios pode ser interpretado como mover o código do branch de desenvolvimento, para o branch de preparo, para o branch de lançamento. Use as pastas Git do Databricks para integrar com seu provedor Git e sincronizar notebooks e código-fonte com workspaces do Databricks. O Databricks também fornece ferramentas adicionais para integração do Git e controle de versão; consulte Ferramentas do desenvolvedor.
- Armazene dados em uma arquitetura do lakehouse usando tabelas Delta. Os dados devem ser armazenados em uma arquitetura do lakehouse em sua conta de nuvem. Os dados brutos e 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 o MLflow. Você pode usar o MLflow para acompanhar o processo de desenvolvimento do modelo e salvar instantâneos de código, parâmetros de modelo, métricas e outros metadados.
- Use Models no Catálogo do Unity para gerenciar o modelo de ciclo de vida. Use Modelos no Catálogo do Unity para gerenciar a versão do modelo, a governança e o status da implantação.
Implantar código, não modelos
Na maioria das situações, o Databricks recomenda que, durante o processo de desenvolvimento de ML, você promova o código, em vez de modelos, de um ambiente para o outro. Mover ativos de projeto dessa forma garante que todo o código no processo de desenvolvimento de ML passe pelos mesmos processos de teste de integração e revisão de código. 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 de MLOps recomendado
As seções a seguir descrevem um fluxo de trabalho MLOps típico, 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 do MLOps variam entre equipes e organizações.
Estágio de desenvolvimento
O foco do estágio 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 ML que pode incluir computação de recursos, treinamento de modelo, inferência e monitoramento.
As etapas numeradas a seguir correspondem aos números no diagrama.
1. Fontes de dados
O ambiente de desenvolvimento é representado pelo catálogo de desenvolvimento no Catálogo do Unity. Cientistas de dados têm acesso de leitura/gravação ao catálogo de desenvolvimento, pois criam tabelas de dados temporários e tabelas de recursos no espaço de trabalho de desenvolvimento. Os modelos criados na fase de preparo são registrados no catálogo de desenvolvimento.
O ideal é que os cientistas de dados que trabalham no espaço de trabalho de desenvolvimento também tenham acesso somente leitura aos dados de produção no catálogo de produção. Permitir que os cientistas de dados tenham acesso de leitura aos dados de produção, às tabelas de inferência e às tabelas métricas no catálogo de produção 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 de produção, 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. EDA (análise exploratória de dados)
Os cientistas de dados exploram e analisam os dados em um processo interativo e iterativo usando notebooks. A meta é avaliar se os dados disponíveis têm o potencial de resolver o problema dos negócios. Nessa etapa, o cientista de dados começa a identificar as etapas de preparação de dados e de recurso 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 Mosaic 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 notebook 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 sobre seu conjunto de dados e salva essas informações em um notebook que pode ser revisado.
3. Código
O repositório de código contém todos os pipelines, módulos e outros arquivos do 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 de projetos. Iniciando pela EDA e nas fases iniciais de um projeto, os cientistas de dados devem trabalhar em um repositório para compartilhar código e acompanhar as alterações.
4. Modelo de treinamento (desenvolvimento)
Os cientistas de dados desenvolvem o pipeline de treinamento de modelo no ambiente de desenvolvimento usando tabelas dos catálogos de desenvolvimento ou produção.
Esse pipeline inclui 2 tarefas:
Treinamento e ajuste. O processo de treinamento registra logs de parâmetros, métricas e artefatos do modelo no servidor de Acompanhamento do MLflow. Após treinar e ajustar os hiperparâmetros, o artefato do modelo final é registrado no servidor de acompanhamento para registrar um vínculo entre o modelo, os dados de entrada nos quais foi treinado e o código usado para gerá-lo.
Avaliação. Avalie a qualidade do modelo testando dados retidos. Os resultados desses testes estão registrados no servidor de Acompanhamento do MLflow. O objetivo da avaliação é determinar se o modelo recém-desenvolvido tem um desempenho melhor do que o modelo de produção atual. Fornecidas permissões de acesso suficientes, qualquer modelo de produção registrado no catálogo de produção 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 acompanhamento do MLflow. Os artefatos típicos são descrições em texto sem formatação e interpretações de modelos, como os plotados produzidos pelo SHAP. Requisitos específicos de governança podem vir de um diretor de governança de dados ou stakeholders do negócio.
A saída do pipeline de treinamento do modelo é um artefato de modelo de ML armazenado no servidor de Acompanhamento do MLflow para o ambiente de desenvolvimento. Se o pipeline for executado no espaço de trabalho de preparo ou produção, o artefato do modelo será armazenado no servidor de Acompanhamento do MLflow nesse espaço de trabalho.
Quando o treinamento do modelo for concluído, registre o modelo no Catálogo do Unity. 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 multitarefa do Databricks no qual a primeira tarefa é o pipeline de treinamento do modelo, seguido pelas tarefas de validação e implantação do modelo. A tarefa de treinamento do 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 o modelo (desenvolvimento)
Além do pipeline de treinamento de modelos, outros pipelines, como os pipelines de validação e implantação de modelos, 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 Catálogo do Unity e executa verificações de validação.
As verificações de validação dependem do contexto. É possível incluir verificações fundamentais, como a confirmação do formato e dos metadados necessários, e verificações mais complexas que podem ser requeridas para setores altamente regulamentados, como verificações de conformidade predefinidas e a confirmação do desempenho do modelo em fatias de dados selecionadas.
A principal função 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 pré-implantação, ele pode ser atribuído ao alias "Desafiante" no Catálogo do Unity. Se as verificações falharem, o processo será encerrado. É possível configurar seu fluxo de trabalho para notificar os usuários sobre uma falha de validação. Confira Adicionar notificações de email e sistema para eventos de trabalho.
Implantação de modelo. O pipeline de implantação do modelo normalmente promove diretamente o novo modelo "Desafiante" para o status de "Campeão" usando uma atualização de alias, ou facilita uma comparação entre o modelo "Campeão" existente e o novo modelo "Desafiante". Esse pipeline também pode configurar qualquer infraestrutura de inferência necessária, como pontos de extremidade do Serviço de Modelo. Para obter uma discussão detalhada das etapas envolvidas no pipeline de implantação de modelos, confira Produção.
6. Confirmar código
Após desenvolver o 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 preparo
O foco dessa fase é 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 fase, 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 os testes de unidade e integração executados nesta fase. A saída do processo de preparo é um branch de versão que dispara o sistema CI/CD para iniciar o estágio de produção.
1. Dados
O ambiente de preparo deve ter seu próprio catálogo no Catálogo do Unity para testar pipelines de ML e registrar modelos no Catálogo do Unity. Esse catálogo é mostrado como o catálogo de "processo de preparo" no diagrama. Os ativos gravados nesse catálogo geralmente são temporários e só são retidos até a conclusão do teste. O ambiente de desenvolvimento também pode requerer acesso ao catálogo de preparação para fins de depuração.
2. Mesclar código
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.
Solicitação de pull. O processo de implantação começa quando uma pull request é criada em relação à ramificação principal do projeto no controle do código-fonte.
Testes de unidade (CI). A pull request cria automaticamente o código-fonte e dispara os 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 (CI)
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 modelo, inferência e monitoramento) para garantir que eles funcionem corretamente juntos. O ambiente de preparo deve corresponder ao ambiente de produção tão próximo quanto razoável.
Se estiver implantando um aplicativo de ML com inferência em tempo real, deverá ser criada e testada a infraestrutura de serviço no ambiente de preparo. Isso envolve disparar o pipeline de implantação de modelos, 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 os testes de integração, algumas etapas podem ser negociadas entre a fidelidade dos testes e a velocidade ou o custo. Por exemplo, se o treinamento dos modelos for dispendioso ou demorado, você poderá usar pequenos subconjuntos de dados ou executar menos iterações de treinamento. Para o serviço de modelos, dependendo dos requisitos de produção, você pode realizar testes de carga em grande escala nos testes de integração, ou pode apenas testar pequenos trabalhos em lote ou solicitações para um ponto de extremidade temporário.
4. Mesclar ao branch de preparo
Se todos os testes forem aprovados, o novo código será mesclado à ramificação principal do projeto. Se os testes falharem, o sistema CI/CD deverá notificar os usuários e postar os resultados na pull request.
Você pode agendar testes de integração periódicos na ramificação principal. Essa é uma boa ideia se a ramificação for atualizada simultaneamente com pull requests de vários usuários.
5. Criar uma ramificação da versão
Após a aprovação dos testes de CI e a mesclagem da ramificação de desenvolvimento na ramificação principal, o engenheiro de ML cria uma ramificação de versão, que dispara o sistema de CI/CD para atualizar os trabalhos de produção.
Estágio de Produção
Os engenheiros de ML são proprietários do ambiente de produção em que os pipelines de ML são implantados e executados. Esses pipelines disparam o treinamento do modelo, validam e implantam novas versões de modelos, publicam previsões em tabelas ou aplicativos downstream e monitoram todo o processo para evitar a 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. Entretanto, é importante que eles tenham visibilidade dos resultados dos testes, dos logs, dos artefatos do modelo, do status do pipeline de produção e das tabelas de monitoramento. Essa visibilidade lhes permite identificar e diagnosticar problemas na produção e comparar o desempenho de novos modelos com os 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.
As etapas numeradas a seguir correspondem aos números no diagrama.
1. Treinar um modelo
Esse pipeline pode ser disparado por alterações de código ou por trabalhos de retreinamento automatizados. Nessa etapa, as tabelas do catálogo de produção são usadas para as etapas seguintes.
Treinamento e ajuste. Durante o processo de treinamento, os logs são registrados no servidor de Acompanhamento do MLflow do ambiente de produção. Esses logs incluem métricas de modelo, parâmetros, marcas e o próprio modelo. Se você usar tabelas em destaque, o modelo será registrado no MLflow usando o cliente do Repositório de Recursos do Databricks, que empacota o modelo com informações de pesquisa de recursos que são 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ído no pipeline de implantação 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 registrados no servidor de rastreamento do 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 um código personalizado.
Registrar modelo. 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 Catálogo do Unity. A tarefa de treinamento do 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 o modelo
Esse pipeline usa o URI do modelo da Etapa 1 e carrega o modelo do Catálogo do Unity. 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 conformidade com requisitos organizacionais, como verificações de conformidade para marcas ou documentação.
Se o modelo passar com sucesso em todas as verificações de validação, você pode atribuir o alias "Desafiante" à versão do modelo no Catálogo do Unity. 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 marcas para adicionar atributos de chave-valor, dependendo do resultado dessas verificações de validação. Por exemplo, você pode criar uma marca "model_validation_status" e definir o valor como "PENDENTE" à medida que os testes são executados e, em seguida, atualizá-lo para "APROVADO" ou "FALHA" quando o pipeline for concluído.
Como o modelo estiver registrado no Catálogo do Unity, os cientistas de dados que trabalham no ambiente de desenvolvimento poderão 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. Implantar modelo
Assim como o pipeline de validação, o pipeline de implantação de modelo depende da sua organização e do caso de uso. Esta seção pressupõe que você tenha atribuído ao novo modelo validado o alias "Desafiante" e que o modelo de produção existente tenha sido atribuído o alias "Campeão". A primeira etapa antes da implantação do novo modelo é confirmar que seu desempenho é, no mínimo, tão bom quanto o do modelo de produção atual.
Compare o modelo "DESAFIANTE" com o modelo "CAMPEÃO". Você pode fazer essa comparação offline ou online. Uma comparação offline avalia os dois modelos em relação a um conjunto de dados retido e acompanha os resultados usando o servidor de Acompanhamento do MLflow. Para o serviço de modelo em tempo real, talvez você deseje executar comparações online de longa duração, como testes A/B ou uma distribuição gradual do novo modelo. Se a versão do modelo "Desafiante" tiver um desempenho melhor na comparação, ela substituirá o atual alias "Campeão".
O Mosaic AI Model Serving e o Monitoramento do Lakehouse do Databricks permitem que você colete e monitore automaticamente as tabelas de inferência que contêm dados de solicitação e resposta para um ponto de extremidade.
Se não houver um modelo "Campeão" existente, você pode comparar o modelo "Desafiante" com uma heurística de negócios ou outro limiar como uma linha de base.
O processo descrito aqui é totalmente automatizado. Se forem necessárias etapas de aprovação manual, você poderá defini-las usando notificações de fluxo de trabalho ou retornos de chamada de CI/CD no pipeline de implantação de modelo.
Implantar modelo. Os pipelines de inferência em lote ou de 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 ponto de extremidade usando o Mosaic AI Model Serving. Se um ponto de extremidade já estiver em uso no modelo atual, você poderá fazer a atualização do ponto de extremidade com o novo modelo. O Mosaic AI Model Serving executa uma atualização com tempo de inatividade zero ao manter a configuração existente em execução até que a nova esteja pronta.
4. Serviço de Modelo
Ao configurar um ponto de extremidade de Serviço de Modelo, especifique o nome do modelo no Catálogo do Unity e a versão a ser fornecida. Se a versão do modelo foi treinada usando recursos de tabelas do Catálogo do Unity, o modelo armazenará as dependências para os recursos e as funções. O Serviço de Modelo usa automaticamente esse grafo de dependência para pesquisar recursos nos repositórios online apropriados no momento da inferência. Essa abordagem também pode ser usada para aplicar funções para o pré-processamento de dados ou para computação de recursos sob demanda durante a pontuação do modelo.
É possível criar um único ponto de extremidade com vários modelos e especificar a divisão do tráfego do ponto de extremidade entre esses modelos, permitindo que você realize comparações online entre "Campeão" e "Desafiante".
5. Inferência: lote ou streaming
O pipeline de inferência faz a leitura dos dados mais recentes do catálogo de produção, executa funções para computação de recursos sob demanda, carrega o modelo "Campeão", pontua os dados e retorna as previsões. A inferência de lote ou streaming geralmente é a opção mais econômica para casos de maior taxa de transferência e maior latência. Para cenários em que são necessárias previsões de baixa latência, mas as previsões podem ser computadas offline, essas previsões colocadas em lote podem ser publicadas em um repositório online de chave-valor, como o DynamoDB ou o Cosmos DB.
O modelo registrado no Catálogo do Unity é referenciado por seu alias. O pipeline de inferência está configurado para carregar e aplicar a versão do modelo "Campeão". 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 na sua próxima execução. Dessa forma, a etapa de implantação do modelo é desacoplada 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 geralmente publicam previsões nas tabelas do Catálogo do Unity ou em filas de mensagens como o Apache Kafka.
6. Monitoramento do Lakehouse
O Monitoramento do Lakehouse monitora as propriedades estatísticas, como descompasso de dados e desempenho do modelo, dos dados de entrada e das previsões do modelo. Você pode criar alertas com base nessas métricas ou publicá-los em dashboards.
- Ingestão de dados. Esse pipeline lê em logs de lote, streaming ou inferência online.
- Verifique a precisão e a descompasso de dados. O pipeline calcula as métricas sobre os dados de entrada, as previsões do modelo e o desempenho da infraestrutura. Os cientistas de dados especificam métricas de dados e modelos 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 relatórios. Você deve configurar essas tabelas para que sejam legíveis no ambiente de desenvolvimento, para que os cientistas de dados tenham acesso à 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.
- Disparar 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 alertas no SQL para notificar os cientistas de dados quando isso acontecer.
7. Retreinamento
Essa arquitetura dá suporte para o retreinamento automático usando o mesmo pipeline de treinamento do modelo acima. O Databricks recomenda começar com um retreinamento agendado e periódico e mover para um retreinamento disparado 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. Confira Tipos de gatilho para trabalhos do Databricks
- Disparados. Se o pipeline de monitoramento puder identificar os problemas de desempenho do modelo e enviar alertas, ele também poderá disparar o retreinamento. Por exemplo, se a distribuição dos dados de entrada for alterada significativamente ou se o desempenho do modelo for degradado, o retreinamento e a reimplantação automáticos podem aumentar o desempenho do modelo com o mínimo de intervenção humana. Isso pode ser alcançado através de um alerta SQL para verificar se uma métrica é anômala (por exemplo, verificar o descompasso de dados ou a qualidade do modelo em relação a um limite). O alerta pode ser configurado para usar um destino de webhook, que pode disparar posteriormente o fluxo de trabalho de treinamento.
Se o pipeline de retreinamento ou outros pipelines apresentarem problemas de desempenho, o cientista de dados talvez precise retornar ao ambiente de desenvolvimento para fazer mais experimentos e abordar os problemas.