Padrões de implantação do modelo

Este artigo descreve dois padrões comuns para mover artefatos de ML através do preparo e para a produção. A natureza assíncrona das alterações em modelos e código significa que há vários padrões possíveis que um processo de desenvolvimento de ML pode seguir.

Os modelos são criados por código, mas os artefatos de modelo resultantes e o código que os criou podem operar de forma assíncrona. Ou seja, novas versões de modelo e alterações de código podem não acontecer ao mesmo tempo. Por exemplo, considere os seguintes cenários:

• Para detetar transações fraudulentas, você desenvolve um pipeline de ML que retreina um modelo semanalmente. O código pode não mudar com muita frequência, mas o modelo pode ser retreinado a cada semana para incorporar novos dados.
• Você pode criar uma rede neural grande e profunda para classificar documentos. Neste caso, treinar o modelo é computacionalmente caro e demorado, e é provável que o retreinamento do modelo aconteça com pouca frequência. No entanto, o código que implanta, serve e monitora esse modelo pode ser atualizado sem treinar novamente o modelo.

Os dois padrões diferem se o artefato modelo ou o código de treinamento que produz o artefato modelo é promovido para a produção.

Implantar código (recomendado)

Na maioria das situações, o Databricks recomenda a abordagem "implantar código". Essa abordagem é incorporada ao fluxo de trabalho MLOps recomendado.

Neste padrão, o código para treinar modelos é desenvolvido no ambiente de desenvolvimento. O mesmo código é movido para o preparo e, em seguida, para a produção. O modelo é treinado em cada ambiente: inicialmente no ambiente de desenvolvimento como parte do desenvolvimento do modelo, no preparo (em um subconjunto limitado de dados) como parte dos testes de integração e no ambiente de produção (nos dados de produção completos) para produzir o modelo final.

Vantagens:

• Em organizações onde o acesso aos dados de produção é restrito, esse padrão permite que o modelo seja treinado em dados de produção no ambiente de produção.
• O retreinamento automatizado do modelo é mais seguro, uma vez que o código de treinamento é revisado, testado e aprovado para produção.
• O código de suporte segue o mesmo padrão do código de treinamento do modelo. Ambos passam por testes de integração no preparo.

Desvantagens:

• A curva de aprendizado para cientistas de dados entregarem código aos colaboradores pode ser íngreme. Modelos de projeto e fluxos de trabalho predefinidos são úteis.

Também nesse padrão, os cientistas de dados devem ser capazes de revisar os resultados do treinamento do ambiente de produção, pois têm o conhecimento para identificar e corrigir problemas específicos de ML.

Se sua situação exigir que o modelo seja treinado em preparo sobre todo o conjunto de dados de produção, você poderá usar uma abordagem híbrida implantando código para preparação, treinando o modelo e, em seguida, implantando o modelo na produção. Essa abordagem economiza custos de treinamento na produção, mas adiciona um custo de operação extra na preparação.

Implementar modelos

Nesse padrão, o artefato do modelo é gerado pelo código de treinamento no ambiente de desenvolvimento. O artefato é então testado no ambiente de preparação antes de ser implantado na produção.

Considere esta opção quando uma ou mais das seguintes situações se aplicarem:

• O treinamento de modelo é muito caro ou difícil de reproduzir.
• Todo o trabalho é feito em um único espaço de trabalho do Azure Databricks.
• Você não está trabalhando com repositórios externos ou um processo de CI/CD.

Vantagens:

• Uma transferência mais simples para cientistas de dados
• Nos casos em que o treinamento do modelo é caro, requer treinamento do modelo apenas uma vez.

Desvantagens:

• Se os dados de produção não estiverem acessíveis a partir do ambiente de desenvolvimento (o que pode ser verdade por motivos de segurança), essa arquitetura pode não ser viável.
• O retreinamento automatizado de modelos é complicado nesse padrão. Você pode automatizar o retreinamento no ambiente de desenvolvimento, mas a equipe responsável pela implantação do modelo em produção pode não aceitar o modelo resultante como pronto para produção.
• O código de suporte, como pipelines usados para engenharia de recursos, inferência e monitoramento, precisa ser implantado na produção separadamente.

Normalmente, um ambiente (desenvolvimento, preparação ou produção) corresponde a um catálogo no Unity Catalog. Para obter detalhes sobre como implementar esse padrão, consulte o guia de atualização.

O diagrama abaixo contrasta o ciclo de vida do código para os padrões de implantação acima nos diferentes ambientes de execução.

O ambiente mostrado no diagrama é o ambiente final no qual uma etapa é executada. Por exemplo, no padrão de modelos de implantação, os testes de unidade final e integração são realizados no ambiente de desenvolvimento. No padrão de código de implantação, os testes de unidade e os testes de integração são executados nos ambientes de desenvolvimento, e os testes finais de unidade e integração são executados no ambiente de preparação.