Model Drift

Um modelo de machine learning que performa bem na avaliação antes do deploy frequentemente performa pior depois de alguns meses em produção. Não porque o código mudou, não porque houve bug, mas porque o mundo mudou. Os padrões que o modelo aprendeu durante o treinamento deixaram de ser válidos no ambiente onde o modelo opera agora.

Model Drift (ou Drift de Modelo) é a degradação da performance de um modelo de machine learning ao longo do tempo, causada por mudanças nas relações entre os dados de entrada e a variável que o modelo tenta prever. É a principal razão pela qual modelos de ML não são artefatos estáticos — requerem monitoramento contínuo e retreinamento periódico para manter sua utilidade.

O drift não é exceção — é a norma. Qualquer modelo implantado em um ambiente dinâmico (comportamento de consumidores, mercados financeiros, operações industriais, tráfego digital) vai sofrer drift. A questão não é se o modelo vai degradar, mas quando, quão rápido e como detectar antes de impactar decisões.

Data Drift (Covariate Drift): mudança na distribuição dos dados de entrada (features X), sem necessariamente mudar a relação entre X e Y. Exemplos: perfil demográfico dos clientes que usam o produto mudou; comportamento de navegação mudou com novos dispositivos; padrões de consumo sazonais que não estavam no dado de treino. O modelo foi treinado para uma distribuição de X e está recebendo outra — os padrões que aprendeu podem não se aplicar aos novos inputs.

Concept Drift: mudança na relação entre as features (X) e o target (Y) — a própria definição do que o modelo tenta prever mudou no mundo real. Exemplos: perfil de cliente que costumava indicar churn já não indica (porque mudou a estratégia de produto); padrão de transação que era fraude já não é (porque fraudadores adaptaram técnicas); correlação entre variáveis macroeconômicas e default mudou com novo regime de juros. Concept drift é mais insidioso que data drift porque a relação fundamental que o modelo aprendeu deixou de existir.

Label Drift: mudança na distribuição do target Y. Se o modelo de scoring de crédito foi treinado num período de baixa inadimplência e agora opera numa crise econômica, a proporção de defaults mudou — o modelo pode estar bem calibrado para a distribuição antiga mas subestima o risco atual.

Prediction Drift: mudança na distribuição das previsões do modelo, mesmo antes de observar o impacto nos outcomes reais. Pode ser sinal precoce de data drift — se as previsões estão distribuídas de forma diferente do histórico, vale investigar se os inputs mudaram.

Upstream Data Drift: mudança nos dados causada por upstream — schema que mudou num sistema de origem, pipeline que passou a calcular uma feature de forma diferente, fonte de dados que foi substituída. Tecnicamente não é "drift" do modelo, mas tem o mesmo efeito: o modelo recebe inputs diferentes do esperado.

Monitoramento de performance (quando ground truth está disponível): o método mais direto — comparar métricas de performance (acurácia, AUC, F1, RMSE) ao longo do tempo com um holdout de dados recentes. Exige que o label real (outcome) seja observável após a previsão. Em modelos de churn, o label é observado em 30-90 dias; em modelos de fraude, pode ser validado rapidamente. O problema: depende de ter labels, que frequentemente chegam com delay.

Monitoramento de distribuição de inputs (quando ground truth é atrasado ou indisponível): não esperar pelos outcomes — monitorar a distribuição das features de entrada. Testes estatísticos detectam se a distribuição atual é estatisticamente diferente da distribuição de referência (dados de treino). Testes comuns: Kolmogorov-Smirnov (KS) para variáveis contínuas, Chi-quadrado para categóricas, Population Stability Index (PSI) amplamente usado no setor financeiro. PSI > 0.25 é convencionalmente sinal de drift significativo.

Monitoramento de previsões: monitorar a distribuição das previsões do modelo — scores de probabilidade, distribuição de classes previstas. Se o modelo que costumava prever 5% de aprovações agora prevê 80%, algo mudou (nos dados de entrada ou no conceito).

Drift em embeddings: para modelos que usam embeddings (texto, imagem), monitorar drift no espaço de embeddings — a distância média entre embeddings de dados recentes e embeddings de dados de referência. Métrica: Maximum Mean Discrepancy (MMD).

Evidently AI: framework open source Python especializado em drift. Relatórios de data drift, concept drift, qualidade de dados e análise de previsões. Integra com MLflow, Grafana, Airflow. A ferramenta open source mais usada especificamente para monitoramento de ML em produção.

Whylogs / WhyLabs: biblioteca open source de profiling de dados + plataforma de monitoramento. Calcula estatísticas compactas de distribuição de forma eficiente (data sketches) e detecta anomalias. Útil para monitoramento em streaming e batch.

Arize AI: plataforma enterprise de monitoramento de ML em produção. Performance tracking, drift detection, análise de slice (drift em subgrupos específicos), root cause analysis. Integra com principais plataformas de ML.

Seldon / BentoML: frameworks de serving de modelos com capacidades integradas de monitoramento. Para times que usam essas plataformas, o monitoramento de drift pode ser integrado ao pipeline de serving.

MLflow + código customizado: MLflow registra experimentos e métricas; com monitoramento customizado de distribuição e logging periódico de métricas de performance, fornece visibilidade básica de drift sem ferramenta adicional.

Retreinamento periódico: a estratégia mais simples — retreinar o modelo com dados mais recentes em intervalos fixos (semanal, mensal, trimestral). Previne drift acumulado mesmo sem monitoramento sofisticado. O custo: retreinamento consome recursos computacionais e requer infraestrutura de MLOps para ser executado automaticamente.

Retreinamento trigger-based: retreinar quando métricas de drift ou performance caem abaixo de thresholds. Mais eficiente que retreinamento periódico — só retreina quando necessário. Requer monitoramento contínuo configurado corretamente.

Janelas deslizantes (sliding window): treinar o modelo apenas nos dados mais recentes (últimos N dias ou meses), descartando dados históricos antigos. Adapta o modelo para o regime atual, sacrificando o aprendizado sobre padrões históricos. Eficaz para concept drift onde o passado é fundamentalmente diferente do presente.

Champion-challenger: manter o modelo atual (champion) em produção enquanto avalia um modelo retreinado (challenger) com tráfego real menor. Só substituir quando o challenger demonstrar performance superior. Reduz risco de regressão ao trocar modelos.

Modelos online (online learning): para dados de streaming, alguns algoritmos (regressão logística online, Hoeffding Trees, algoritmos de bandit) atualizam os parâmetros do modelo incrementalmente a cada novo exemplo sem necessidade de retreinamento completo. Adapta-se continuamente ao drift, mas é mais complexo de implementar e monitorar.

É importante distinguir drift de problemas técnicos que causam sintomas similares.

Drift real: o mundo mudou e o modelo não captura mais os novos padrões. Solução: retreinamento com dados recentes.

Data quality issue upstream: um pipeline de feature engineering quebrou e está calculando features incorretamente. O modelo não mudou, mas os inputs estão errados. Solução: corrigir o pipeline upstream.

Schema change: o schema de um sistema de origem mudou e a feature de entrada agora tem significado diferente. Solução: atualizar o pipeline de ingestão e revalidar as features.

Bug em produção: erro no código de serving que afeta previsões. Solução: debugging e correção de código.

A distinção importa porque a resposta correta é diferente. Monitoramento de observabilidade de dados (freshness, schema, volume) ajuda a distinguir drift real de problemas técnicos.

Model drift é o custo invisível de modelos de ML em produção. Times que treinam um modelo, fazem o deploy e consideram o trabalho concluído frequentemente descobrem, meses depois, que o modelo que funcionava bem na avaliação inicial já não é confiável — mas continuou sendo usado para decisões porque ninguém estava monitorando.

Para PMEs implementando ML pela primeira vez, a prioridade de MLOps não é a plataforma mais sofisticada — é ter algum monitoramento em produção. Evidently AI com scripts básicos de monitoramento de distribuição e alertas quando PSI excede threshold é suficiente para os primeiros modelos. O retreinamento periódico (mensal ou trimestral, dependendo da velocidade de mudança do domínio) é mais simples de operar e já previne a maioria dos casos de degradação acumulada.

O KPI que importa: não é a acurácia no holdout do dia do deploy — é a acurácia do modelo 6 meses depois de estar em produção. Se ninguém monitora esse número, o modelo está operando no escuro.