Padrões de implantação de modelo

Este artigo descreve dois padrões comuns para mover artefatos de ML pela preparação e para a produção. A natureza assíncrona das alterações nos modelos e no 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 mudanças de código podem não acontecer ao mesmo tempo. Por exemplo, considere os seguintes cenários:

Para detectar transações fraudulentas, você desenvolve um ML pipelines que retreina um modelo semanalmente. O código pode não mudar com muita frequência, mas o modelo pode ser treinado novamente toda semana para incorporar novos dados.
Você pode criar uma rede neural grande e profunda para classificar documentos. Nesse caso, o treinamento do modelo é computacionalmente caro e demorado, e é provável que o novo treinamento do modelo aconteça com pouca frequência. No entanto, o código que aprimora, atende e monitora esse modelo pode ser atualizado sem retreinar o modelo.

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

Código aprimorado (recomendado)

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

Nesse padrão, o código para ensinar modelos é desenvolvido no ambiente de desenvolvimento. O mesmo código passa para a preparação e depois para a produção. O modelo é treinado em cada ambiente: inicialmente no ambiente de desenvolvimento como parte do desenvolvimento do modelo, na preparação (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 definitivo.

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, pois 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 em staging.

Desvantagens:

A curva de aprendizado para o cientista de dados passar o código para os colaboradores pode ser íngreme. Projeto padrão predefinido e fluxo de trabalho são úteis.

Também nesse padrão, o cientista de dados deve ser capaz de revisar os resultados do treinamento do ambiente de produção, pois possui o conhecimento para identificar e corrigir problemas específicos do ML.

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

modelos aprimorados

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 essa opção quando um ou mais dos seguintes itens se aplicarem:

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

Vantagens:

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

Desvantagens:

Se os dados de produção não estiverem acessíveis no ambiente de desenvolvimento (o que pode ser verdade por motivos de segurança), essa arquitetura pode não ser viável.
O retreinamento automatizado do modelo é complicado nesse padrão. Você pode automatizar o retreinamento no ambiente de desenvolvimento, mas a equipe responsável por aprimorar o 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 passo é executada. Por exemplo, no padrão de modelos aprimorados, os testes finais de unidade e integração são realizados no ambiente de desenvolvimento. No padrão de código aprimorado, 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.