Fluxos de trabalho MLOps no Azure Databricks
Este artigo descreve como você pode usar MLOps na plataforma Databricks para optimize o desempenho e a eficiência a 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?
O MLOps é uma set 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 os modelos e dados where 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 sync 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 Delta tables. Os dados devem ser armazenados em uma arquitetura lakehouse em sua conta na nuvem. Tanto os dados brutos quanto a funcionalidade tables devem ser armazenados como Delta tables, com controles de acesso para determinar quem pode lê-los e modificá-los.
- Gerencie o desenvolvimento de modelos com MLflow. Você pode usar MLflow para acompanhar o processo de desenvolvimento do modelo e salvar instantâneos de código, parametersdo 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 da 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 optimize 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 dev catalog na Unity Catalog. Os cientistas de dados têm acesso de leitura e gravação ao catalog de desenvolvimento enquanto criam dados temporários e características tables no ambiente de desenvolvimento. Os modelos criados na etapa de desenvolvimento são registrados para o catalogde desenvolvimento.
Idealmente, os cientistas de dados que trabalham no espaço de trabalho de desenvolvimento também têm acesso de leitura aos dados de produção no prod catalog. Permitir que os cientistas de dados tenham acesso de leitura aos dados de produção, inferência tablese métricas tables no ambiente prod catalog permite-lhes analisar as previsões e o desempenho atuais do modelo de produção. 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 grant acesso somente leitura ao prod catalog, um instantâneo dos dados de produção pode ser gravado no catalog 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 regista um conjunto de set 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 possa rever, 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 treino do modelo no ambiente de desenvolvimento utilizando tables do catalogsde desenvolvimento ou produção.
Este pipeline inclui 2 tarefas:
Formação e afinação. O processo de treinamento registra o modelo parameters, métricas e artefatos para o 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 generate-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. Dadas as permissões suficientes, qualquer modelo de produção registado no prod catalog pode ser carregado no ambiente de desenvolvimento e comparado a um modelo que foi recentemente 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. Set o código do pipeline para registrar o modelo no catalog correspondente ao ambiente em que o pipeline do modelo foi executado; Neste exemplo, o dev catalog.
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. Pode usar a tarefa values para passar este 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 recebe o URI do modelo a partir do pipeline de treino, carrega o modelo do Unity Cataloge 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 Adicione notificações num trabalho.
Implantação do modelo. O pipeline de implementação do modelo geralmente promove diretamente o modelo "Challenger" recém-treinado ao status de "Champion" através de um alias update, ou facilita uma comparação entre o modelo "Champion" atual e o novo modelo "Challenger". Esse pipeline também pode set 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 teste deve ter o seu próprio catalog no Unity Catalog para testar pipelines de ML e registar modelos no Unity Catalog. Esta catalog é mostrada como a catalog de "preparação" no diagrama. Os ativos gravados neste catalog geralmente são temporários e só são retidos até que os testes sejam concluídos. O ambiente de desenvolvimento também pode exigir acesso ao ambiente intermediário catalog para propósitos de depuração.
2. Código de mesclagem
Os especialistas em ciência de dados desenvolvem o fluxo de treino do modelo no ambiente de desenvolvimento utilizando tables proveniente de catalogsde 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 update trabalhos de produção.
Fase de produção
Os engenheiros de ML são proprietários do ambiente de produção where 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 para tables 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 sobre os resultados dos testes, logs, artefatos do modelo, status do pipeline de produção e monitorização tables. 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 grant aos cientistas de dados acesso somente leitura a ativos no catalog 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, tables do catalog de produção são usados 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 de modelo, parameters, tags e o próprio modelo. Se você usar o recurso tables, 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 catalogde produção, eles poderão determinar o set ideal de hiperparâmetros para um modelo. Nesse caso, o pipeline de treinamento do modelo implementado em produção pode ser executado usando o set selecionado de hiperparâmetros, normalmente incluído no próprio 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 treino do modelo é concluído, o artefato do modelo é salvo como uma versão registada do modelo no caminho do modelo especificado na área de produção catalog 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 a tarefa values para passar esse URI para o modelo.
2. Validar modelo
Esta canalização 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 set o valor para "PENDING" à medida que os testes são executados e, em seguida, update-lo para "PASSED" ou "FAILED" quando o pipeline for concluído.
Como o modelo é registrado no Unity Catalog, os cientistas de dados que trabalham no ambiente de desenvolvimento podem carregar essa versão do modelo a partir do catalog de produção para investigar se o modelo falha na validação. Independentemente do resultado, os resultados são registados no modelo registado de produção catalog, utilizando 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 set 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 recolher e monitorizar automaticamente inferências tables que contêm dados de solicitação e resposta para um endpoint.
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á set-las usando notificações de fluxo de trabalho ou retornos de chamada de CI/CD do pipeline de implantação do modelo.
Implantar modelo. As pipelines de inferência em lote ou em fluxo contínuo podem ser set para utilizar o modelo com o alias "Campeão". Para casos de uso em tempo real, você deve set 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á update o ponto de extremidade com o novo modelo. O Mosaic AI Model Serving executa um update 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 do tables 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 catalogde produção, executa funções para calcular características sob demanda, carrega o modelo "Campeão", avalia 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 where são necessárias previsões de baixa latência, 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 geralmente publicam previsões para tables no catalogde produção, para arquivos simples ou por meio de uma conexão JDBC. As tarefas de streaming normalmente publicam previsões tanto para o Unity Catalogtables como 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 alertas set. O pipeline grava em tables na produção catalog para análise e relatórios. Você deve configurar esses tables 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 set 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 set 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 Automação de tarefas com programações e gatilhos
- 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.