Retreinamento automático para modelos de aprendizado de máquina: dicas e lições aprendidas

Escrito por Felipe Almeida com contribuições de Marcelo Koga, Raphael Soares, Gabriel Bakiewicz e George Salvino

---

Os modelos de aprendizado de máquina começam a decair no mesmo instante em que começam a ser usados. Na verdade, eles precisam perder desempenho porque são treinados com uma imagem estática do mundo (um conjunto de treinamento).

O mundo, entretanto, muda constantemente, o que torna essa captura obsoleta com o passar do tempo. Essas mudanças no mundo (conforme representado pelas características usadas) costumam ser chamadas de “desvio de conceito” (concept drift) ou “desvio de dados” (data drift).

A velocidade com a qual o modelo decai depende de várias razões. Por exemplo:

• a quantidade de características que você está usando e como elas estão correlacionadas.
• O quão regularizado e/ou robusto é o modelo.
• Eventos não previstos e repentinos que mudam as coisas (por exemplo, a covid).
• A variação inerente no campo dos problemas. 
• O quão antagonizador é o seu caso de uso (ou seja, quanto incentivo as pessoas têm para tentar enganar o modelo de propósito).

Às vezes, o jeito mais fácil e robusto de atualizar o seu modelo é apenas retreiná-lo com dados mais recentes, sem necessariamente adicionar novas características. Isso permite ao seu modelo ver uma captura mais recente do estado do mundo e atualizar os próprios parâmetros de acordo com isso.

Isso envolve alguns riscos e muitas concessões e provavelmente só é adequado quando você já tem um fluxo sólido e bem desenvolvido de Operações de Aprendizado de Máquina, mas existem benefícios claros também.

Nas próximas seções, vamos falar sobre algumas das lições que aprendemos ao longos desses últimos anos que passamos retreinando modelos de maneira automática no Nubank.

Pré-requisitos: CI/CD, monitoramento e um pipeline de dados sólido

Se você não puder implantar com confiança uma nova versão de um modelo com um só clique, o retreinamento automático não será possível. 

Você precisa, no mínimo, destes três componentes na sua arquitetura de MLOps:

• CI/CD: algum tipo de sistema no qual o código recém-enviado é testado automaticamente (unidade/integração) e mudanças no código acionam automaticamente uma nova implantação na produção.
• Monitoramento de modelo: algum tipo de sistema no qual você pode ver continuamente estatísticas sobre o seu modelo e os dados, como: distribuição das características inseridas, distribuição de pontuações e desempenho em comparação à verdade fundamental, por exemplo.
  • Sem um monitoramento apropriado, você não tem como saber o quão bom ou ruim é o seu modelo atual; você não devia estar pensando em substituí-lo ainda.
• Pipeline de dados sólido: você precisa de uma maneira de gerar conjuntos de dados de treinamento/teste (incluindo destinos) de maneira programática e confiável. (O ideal é que haja engenheiros de dados na sua equipe para cuidar disso para você.)

Check our job opportunies

“Automático” normalmente não significa totalmente automático 

Retreinar e implantar de maneira automática um novo modelo provavelmente não vale o risco. Implantar um modelo falho e ele ser usado para tomar decisões falhas na produção é uma das piores coisas que podem acontecer em uma organização impulsionada por dados.

Uma sugestão alternativa é simplesmente fazer a última etapa do pipeline abrir um pull request (PR) no Github, com o desempenho comparado do modelo-base e do modelo contestador. Mas o PR ainda precisa ser aprovado/mesclado manualmente antes de acionar uma implantação que substituirá o modelo atual pelo novo modelo na produção.

Na nossa experiência, esse é um meio-termo com um bom custo-benefício entre não ter automação e ter o processo totalmente automatizado (sem intervenção manual de qualquer tipo).

Não se esqueça da camada de política

Vamos supor que as previsões do seu modelo estejam sendo usadas por alguma equipe/sistema em estágios posteriores (se um modelo não estiver sendo usado, ele é um risco, não um benefício, e você deveria provavelmente desativá-lo).

A maneira como as outras equipes usam as previsões feitas pelo modelo se chama política.  O modo mais simples de derivar uma política de uma pontuação de modelo é usar uma instrução if simples na qual uma ação (por exemplo, ceder o empréstimo, adquirir um bem) deverá ser executada se a pontuação do modelo estiver acima de algum limite.

O exemplo mais simples possível de uma política é um limite de pontuação trivial: IF pontuação do modelo ≥ limite, THEN executar uma ação

Sempre que retreinar um modelo, pode ser que você precise ajustar a política também. Isso é essencial. Se você esquecer de fazer o ajuste, todos os usos do modelo em estágios posteriores poderão não ser precisos.

Dependendo da complexidade da política, você perceberá que é bem mais difícil retreinar ou reajustar a política do que retreinar um modelo. Se você não tomar cuidado, isso poderá se tornar um gargalo no seu pipeline.

Na nossa experiência, uma maneira de tornar os ajustes de políticas mais fácil é fazer os seus modelos usarem previsões com probabilidades calibradas.

Use parâmetros de comparação justos

Após conseguir retreinar um modelo com dados mais recentes, você provavelmente vai querer comparar o desempenho dele com o modelo atual na produção.

Existem muitas maneiras de comparar modelos:

• Comparar a importância das características (por exemplo, usando gráficos da SHAP).
• Ver qual deles tem o melhor desempenho fora da amostra (OOS) (por exemplo, ROCAUC, PRAUC, logloss etc).
• O quão estáveis são as previsões do modelo com o passar do tempo?

Qualquer que seja a métrica que você queira usar para comparar as duas versões do modelo (ou seja, o modelo-base e o modelo contestador), ela precisa ser calculada em um conjunto de dados holdout e neutro.

Isso significa que o conjunto de dados de referência deve estar fora da amostra do ponto de vista de ambos os modelos. Do contrário, existe o risco de um vazamento de dados por parte de qualquer um dos conjuntos de treinamento e os seus resultados não serão confiáveis.

P.S.: se por alguma razão, você não tiver acesso a um conjunto de dados neutro para testar os dois modelos, é melhor implantar as duas versões (a de base e a contestadora) juntas como parte de um teste A/B (e monitorá-las de perto!).

Cuidado com ciclos de feedback

Quando se fala em modelos de aprendizado de máquina, o termo ciclo de feedback refere-se aos casos em que o uso do modelo afeta o conjunto de treinamento futuro com o qual ele será retreinado. 

Ciclos de feedback em modelos de aprendizado de máquina: quando o modelo afeta seus próprios dados de treinamento futuros

Há vários exemplos de ciclos de feedback no aprendizado de máquina:

• Concessão de crédito: somos capazes de perceber a falta de pagamento apenas dos clientes que receberam algum dinheiro (por definição, não representa toda a população).
• Sistemas de recomendação: a ação do modelo vai mudar o comportamento do usuário no futuro (por exemplo, um modelo de atendimento ao cliente ou um sistema para sugerir filmes).

Por que os ciclos de feedback são um problema para o retreinamento automático? Nem sempre são um problema, mas sem dúvida são algo do qual você precisa estar ciente e talvez mitigar de alguma forma, dependendo das necessidades do seu negócio. 

Eles poderão se tornar um problema se o viés introduzido pelo modelo alterar seus dados de treinamento de uma maneira que atrapalhe o treinamento do modelo. Esse não é um problema simples de ser resolvido, mas há alguns modos de lidar com ele. Por exemplo:

• Podemos usar um grupo de controle que não seja afetado pelas decisões do modelo, de modo que possamos observá-las sem viés?

Podemos inferir qual teria sido o rótulo verdadeiro se o modelo não tivesse executado uma ação?

Teste de unidade (mais ou menos) para modelos de aprendizado de máquina (ML)

Nós gostaríamos de poder garantir que um modelo recém-retreinado será melhor do que a versão atual para todos os exemplos pontuados.

Normalmente, é impossível ter esse tipo de garantia porque os modelos de aprendizado de máquina (ML) são inerentemente estocásticos. Dizer que um modelo se sai melhor do que outro na verdade significa apenas que ele é melhor em média.Uma maneira de ter um pouco de tranquilidade é ter alguns exemplos sintéticos que qualquer modelo conseguiria classificar de maneira correta com facilidade e depois pontuar esses exemplos “artificiais” com o modelo retreinado e verificar se ele teve o resultado esperado. 

O resultado esperado pode ser a classe prevista, no caso de uma classificação, ou uma pontuação dentro de algum intervalo se você tiver um modelo de regressão.

Avaliar o desempenho em subpopulações/extratos também ajuda, como você pode ver abaixo.

Avaliar o desempenho em subpopulações/extratos 

É muito provável que os exemplos pontuados pelo seu modelo possam ser divididos como subpopulações separadas ou grupos vagos. Por exemplo:

• um modelo de concessão de crédito que estime o risco de inadimplência de indivíduos e de empresas. 
• Um modelo para detectar fraude em compras online, mas também em compras presenciais e em compras internacionais.
• Um modelo de previsão de preços que estime os preços de casas, apartamentos e condomínios.

Avaliar as métricas de desempenho de ambos os modelos (o modelo-base e o modelo contestador) separadamente para cada extrato ajuda você a verificar mais uma vez se não surgiu algum problema inesperado no novo conjunto de treinamento.

Outras dicas

Não combine o pipeline de retreinamento com um modelo específico

Quando você escrever um pipeline (por exemplo, com Airflow, Kubeflow ou scripts independentes) para retreinar o modelo com dados mais recentes e fazer todas as análises, certifique-se de que ele seja escrito de uma maneira que não esteja combinada com um modelo ou caso de uso único.

Siga as práticas de engenharia de software padrão: passar as variáveis como argumentos para que o pipeline possa ser usado por outros modelos, para períodos arbitrários, usando comparação personalizada ou estratégias de avaliação etc.

Leve a censura de rótulos em consideração

Os rótulos são geralmente obtidos de fontes de dados diferentes das características. Além disso, os rótulos costumam estar atrasados em relação ao horário de pontuação.

Isso significa que o rótulo verdadeiro para o exemplo pontuado hoje poderá estar disponível apenas após algum tempo (por exemplo, quando o empréstimo foi pago novamente/caiu em inadimplência).

Não se esqueça de levar isso em consideração quando estiver decidindo com quais períodos os modelos retreinados serão treinados/validados (ou seja, você provavelmente deve ignorar (ou censurar) dados para os quais destinos ainda não estejam disponíveis).

Leve custos em consideração quando estiver decidindo com que frequência fazer o retreinamento

Normalmente, há custos associados ao retreinamento de modelos. Alguns deles são:

• Custos do sistema: executar as tarefas de dados e modelos de treinamento necessários exige recursos computacionais, e eles custam dinheiro, principalmente na escala da Web.
• Custos humanos/trabalhistas:
  • os cientistas de dados vão precisar passar um tempo depurando e/ou verificando os resultados antes de implantar um modelo retreinado na produção
  • Os usuários em estágios posteriores poderão ter que atualizar os processos deles para se adaptarem a mudanças na precisão/desempenho do modelo.

Esses custos devem se comparar aos benefícios esperados de retreinar um modelo (normalmente, aumentar o desempenho em comparação ao modelo-base), ou fazer isso não terá sentido econômico.

Ferramentas sugeridas

Kubeflow Pipelines (KFP)

O Kubeflow tem um componente chamado Kubeflow Pipelines (abreviado como KFP) que pode ser usado para criar pipelines e fluxos de trabalho, inclusive aqueles para retreinar um modelo, como criar conjuntos de dados de treinamento, treinar classificadores e fazer rotinas de avaliação, por exemplo.

Nós usamos isso no Nubank e tem nos servido bem até agora.

Papermill

O Papermill é uma ferramenta usada para tornar Jupyter Notebooks executáveis e parametrizáveis (ou seja, você pode executar Notebooks como se fossem scripts e passar parâmetros para eles).É uma ferramenta útil para preencher a lacuna entre o código de tempo de desenvolvimento (normalmente criado pelos cientista de dados) e o código de tempo de produção.