Nubank: alertas de ML em tempo real e retreino automático

01 · CONTEXTO

Modelos que falham em silêncio

A equipe de ML do Nubank parte de uma observação: um modelo servido sob demanda é software, mas tem uma diferença importante, porque pode falhar silenciosamente, produzindo previsões erradas sem nenhuma exceção ou mensagem de erro. Esse é o ponto de partida para falar de monitoramento e observabilidade em um sistema de ML.

Este estudo de caso junta temas do Nubank que se complementam: como avisar rápido quando algo está errado no modelo servido e como substituí-lo por uma versão retreinada com cuidado.

Além das falhas comuns de qualquer software, a fonte lista modos de falha típicos de ML: features ausentes ou quebradas e mudanças repentinas na distribuição da população, ambos levando a previsões erradas.

02 · ALERTAS

Do modelo servido ao plantão

1. O diagrama mostra requisições de negócio chegando ao modelo, que lê suas features de uma fonte própria.

2. Mesmo sem exceções ou mensagens de erro, o modelo pode estar devolvendo previsões erradas.

3. Features ausentes ou quebradas e mudanças repentinas na distribuição da população estão entre as causas de previsões erradas em ML.

4. No diagrama, logs e métricas alimentam regras de alerta. O texto do alerta deve dizer o que era esperado e o intervalo avaliado, e trazer um link ou curso de ação claro para quem responde.

5. Se o serviço parar por completo, pode não haver logs, médias, contagens ou somas. Um alerta de heartbeat dispara quando o ping esperado não chega no período configurado.

A fonte descreve jeitos de um alerta deixar de funcionar com o tempo: ficar sensível demais, o que gera fadiga de alertas, ou ficar embotado e nunca mais disparar. Por isso, qualquer pessoa deve conseguir editar o limite para calibrar sinal e ruído.

Dicas de escala: um tamanho mínimo de amostra evita disparos sem dados suficientes, e usar uma amostra dos dados em vez do total contém o custo, desde que a distribuição subjacente seja grande o bastante. E, como qualquer código, o alerta deve ser testado.

03 · RETREINO

Retreinar sem entregar o controle

A fonte afirma que modelos perdem desempenho porque foram treinados em um retrato estático do mundo, e que muitas vezes a forma mais simples de atualizá-los é retreinar com dados mais novos, sem novas features.

1. O diagrama mostra o caminho do retreino: dados, pipeline, pull request, CI/CD e o modelo em produção.

2. Antes de automatizar, a fonte exige alicerces: CI/CD, monitoramento do modelo e um pipeline de dados que gere treino e teste de forma programática e confiável.

3. O pipeline retreina com dados mais novos e compara baseline e challenger em um conjunto de teste sem viés, que não faz parte dos treinos.

4. Em vez de implantar sozinho, o último passo do pipeline pode abrir um pull request com o desempenho comparado de baseline e challenger.

5. O pull request ainda precisa de aprovação manual antes da implantação que substitui o modelo em produção.

6. A forma como outras equipes usam as previsões do modelo é chamada de política. Ao retreinar, pode ser preciso ajustar a política também.

04 · ARMADILHAS

O que verificar antes de trocar o modelo

A política costuma ser a parte negligenciada. Segundo a fonte, dependendo da complexidade, é mais difícil retreinar ou reajustar a política do que o modelo, e usar probabilidades calibradas facilita esses ajustes.

Feedback loops merecem atenção: o uso do modelo afeta o conjunto de treino futuro. Em crédito, por exemplo, só se observa inadimplência de quem recebeu dinheiro, o que adiciona um viés perceptível nos dados coletados depois da introdução do modelo.

Outros cuidados da fonte: o rótulo de um exemplo pontuado hoje pode só estar disponível depois de algum tempo, e isso deve ser considerado ao escolher os períodos de treino e validação. Os custos do retreino devem ser comparados com o benefício esperado, e o pipeline não deve ficar acoplado a um único modelo ou caso de uso.

05 · LIÇÕES

Como levar isso para uma entrevista

Em uma discussão de design, vale mostrar que você prevê como o modelo será vigiado, como a troca será proposta e revisada e como a política que consome o score será mantida em sincronia com ele.