Drift de modelo é a perda de performance de um modelo de machine learning em produção causada por mudanças nos dados que ele recebe, ou na relação entre esses dados e o resultado que ele tenta prever. O código continua igual, o endpoint responde dentro do SLA e a infraestrutura não acusa falha, enquanto a qualidade das predições cai sem gerar nenhum erro de execução.
Este guia trata de modelos preditivos de machine learning: classificação, regressão, scoring de crédito, previsão de demanda, propensão de churn. Monitorar agentes de IA e aplicações de LLM é outro problema, com outras métricas (rastros de execução, custo por token, taxa de alucinação) e outro ferramental. Aqui o objeto de medição são as distribuições das variáveis de entrada e a relação entre entrada e alvo.
A mesma palavra cobre dois fenômenos distintos, e cada um exige um tipo de detecção. O primeiro aparece sem nenhum rótulo novo, já no dia seguinte ao deploy. O segundo só se confirma quando o resultado real chega, o que leva semanas ou anos, dependendo do negócio. A arquitetura de MLOps prevê essa camada de monitoramento, e este texto explica como montá-la.
Data drift e concept drift: o mesmo sintoma, causas opostas
Data drift é a mudança na distribuição das entradas, ou P(X) na notação estatística. As variáveis que alimentam o modelo passam a ter outra forma: a idade média dos clientes sobe, o mix de canal de venda muda depois de uma campanha, um sensor troca de fabricante e passa a reportar em outra escala. A regra que o modelo aprendeu continua válida, porém ele está sendo consultado sobre uma população que viu pouco durante o treino.
Concept drift é a mudança na relação entre entrada e alvo, ou P(Y|X). As entradas podem estar idênticas, e o significado delas mudou. Um modelo antifraude é o caso clássico: o fraudador observa o bloqueio, adapta o modus operandi e passa a produzir transações que parecem legítimas segundo as features antigas. Modelos de precificação sofrem o mesmo quando um concorrente muda de estratégia, e os de crédito sofrem quando a política interna de aprovação é alterada.
A diferença tem consequência prática direta. Data drift você detecta comparando distribuições, sem saber se a predição estava certa. Concept drift exige o resultado real, ou uma estimativa dele, porque seu sintoma é o erro, e não a forma dos dados. Os dois entram no monitoramento como sinais separados, com cadências e gatilhos próprios.

No data drift a nuvem de dados se move e a regra aprendida continua correta. No concept drift a nuvem fica no lugar e a regra deixa de valer.
Existe ainda um terceiro sinal, mais barato que os dois: o prediction drift, a mudança na distribuição das saídas do modelo. Se um scorer que aprovava uma fração estável de pedidos passa a aprovar o triplo, algo mudou na entrada ou no pipeline, e você descobre isso sem rótulo. Ele é o teste mais simples de manter ligado, e quando dispara indica que vale rodar a bateria completa de verificações.
Os testes que detectam drift de modelo: PSI, KS e qui-quadrado
Detectar drift é comparar duas amostras: uma janela de referência, normalmente o conjunto de treino, e uma janela atual. Os três testes mais usados no mercado fazem essa comparação de formas diferentes. A sua escolha depende do tipo da variável e do tamanho da amostra.
PSI (Population Stability Index)
O PSI divide a variável em faixas, em geral dez faixas de igual frequência, recortadas pelos decis da janela de referência, e soma a divergência entre a proporção esperada e a observada em cada faixa. O resultado é um número único por variável, sem p-valor, fácil de colocar em painel e de acompanhar ao longo do tempo. A convenção herdada do crédito trata valores abaixo de 0,1 como estabilidade, entre 0,1 e 0,25 como mudança moderada que pede investigação, e acima de 0,25 como deslocamento relevante da população.
O Databricks calcula o population_stability_index no perfil de inferência e documenta cortes semelhantes: abaixo de 0,1 sem mudança, abaixo de 0,2 mudança moderada, e a partir de 0,2 mudança significativa. Vale saber de onde vêm esses números. Um artigo publicado no Journal of Risk Model Validation mostrou que os cortes de 0,10 e 0,25 são prática de indústria sem sustentação acadêmica, e que a distribuição do PSI depende do número de faixas e do tamanho das duas amostras. Use 0,1 e 0,25 como ponto de partida e calibre o limiar com o histórico do seu próprio modelo.
import numpy as np
def psi(ref, atual, faixas=10):
"""PSI entre a janela de referencia e a janela atual, em faixas de igual frequencia."""
cortes = np.percentile(ref, np.linspace(0, 100, faixas + 1))
cortes[0], cortes[-1] = -np.inf, np.inf
e = np.histogram(ref, bins=cortes)[0] / len(ref)
a = np.histogram(atual, bins=cortes)[0] / len(atual)
e, a = np.clip(e, 1e-6, None), np.clip(a, 1e-6, None) # evita divisao por zero
return float(np.sum((a - e) * np.log(a / e)))
Kolmogorov-Smirnov (KS)
O teste KS de duas amostras mede a distância máxima entre as funções de distribuição acumulada da referência e da produção, e devolve um p-valor. Serve apenas para variáveis numéricas contínuas e tem uma armadilha conhecida: com amostras grandes, qualquer diferença irrelevante para o negócio vira estatisticamente significativa, e o monitor passa a disparar todos os dias. A documentação do NannyML registra outras duas limitações, a insensibilidade a mudanças nas caudas e a tendência a falsos positivos.
Qui-quadrado
O teste de qui-quadrado compara frequências observadas e esperadas por categoria, então é o teste natural para variáveis categóricas: canal, região, produto, faixa de renda. Ele também devolve p-valor e sofre do mesmo efeito de escala. Conforme a documentação do NannyML, a estatística de qui-quadrado cresce junto com o tamanho da amostra, então janelas de tamanhos diferentes não são comparáveis sem cuidado adicional.
| Teste | Tipo de variável | O que devolve | Limiar usual | Onde falha |
|---|---|---|---|---|
| PSI | numérica ou categórica binada | índice único | 0,1 atenção · 0,25 ação | sensível ao número de faixas e ao tamanho da amostra |
| Kolmogorov-Smirnov | numérica contínua | p-valor | p < 0,05 | falso positivo em amostra grande; ignora as caudas |
| Qui-quadrado | categórica | p-valor | p < 0,05 | estatística cresce com o tamanho da amostra |
| Wasserstein | numérica contínua | distância | 0,1 | precisa de escala interpretável por variável |
| Jensen-Shannon | categórica | distância entre 0 e 1 | 0,1 | dilui mudança em categoria rara |
As duas últimas linhas mostram para onde as ferramentas migram quando o volume cresce. A documentação do Evidently descreve a troca de forma explícita: com até 1.000 observações na referência o padrão é KS para numéricas com mais de cinco valores distintos e qui-quadrado para categóricas, ambos a 95% de confiança; acima de 1.000 observações o padrão vira distância de Wasserstein para numéricas e divergência de Jensen-Shannon para categóricas, com limiar de 0,1. A lógica é simples: teste de hipótese perde utilidade em amostra grande, e métrica de distância não perde.
Esse ferramental vem se consolidando dentro das plataformas de dados: o Databricks calcula ks_test, chi_squared_test, js_distance, wasserstein_distance e population_stability_index em uma tabela dedicada. A AWS, por sua vez, informa na própria documentação que o SageMaker Model Monitor deixou de aceitar novos clientes e não receberá novas funcionalidades.
Com que frequência rodar e qual o gatilho de retreino
A frequência sai de três variáveis: o volume de inferências, a velocidade com que o fenômeno muda e o tempo que o rótulo real leva para chegar. Um scorer de crédito consultado milhares de vezes por dia sustenta janela diária; um modelo de demanda que roda em lote semanal não tem dado para uma janela diária dizer nada útil.
O tamanho da janela importa mais do que a cadência. Com poucas centenas de observações, métricas de distância ficam ruidosas e testes de hipótese perdem poder, e é por isso que o Evidently usa o corte de 1.000 observações para trocar de método. Sem volume para uma janela dessa ordem por dia, acumule por semana.
Vale ainda manter duas comparações ligadas, porque elas encontram coisas distintas. Contra a linha de base do treino, você mede o desgaste acumulado desde o deploy. Contra a janela imediatamente anterior, pega a quebra abrupta, quase sempre bug de pipeline ou mudança de schema no upstream. O Databricks nomeia as duas como drift de baseline e drift consecutivo.
| Cenário | Janela | Cadência dos testes | Comparação | Sinal primário |
|---|---|---|---|---|
| Scoring em tempo real, alto volume | 1 dia | diária | baseline + consecutiva | prediction drift e PSI das features de topo |
| Lote diário, volume médio | 7 dias móveis | diária sobre janela móvel | baseline | PSI e qui-quadrado por variável |
| Lote semanal ou mensal, baixo volume | 1 mês | mensal | baseline | qualidade de dados e prediction drift |
| Rótulo com atraso longo (crédito, seguro) | 1 mês | mensal | baseline | performance estimada e feature attribution |
Qualidade de dados é a exceção que roda sempre, em toda execução, seja qual for a cadência de drift: nulos acima do esperado, valores fora de faixa, cardinalidade nova em campo categórico, mudança de schema. Boa parte dos alertas de drift em operação real nasce aí, antes de qualquer mudança verdadeira do mundo. Manter as features em uma feature store ajuda, porque a definição da variável fica versionada em um lugar só e a comparação treino contra produção para de depender de dois códigos diferentes.
O gatilho de retreino
Alerta de drift é abertura de investigação, não ordem de retreino. Retreinar no primeiro sinal desperdiça recurso, e pior, corre o risco de treinar sobre dado quebrado e degradar um modelo que estava saudável. O caminho que se sustenta em produção tem quatro etapas encadeadas.
- Confirmar que o dado está íntegro. Elimine bug de pipeline, join duplicado, mudança de schema e falha de ingestão antes de qualquer hipótese sobre o mundo.
- Localizar o drift. Ver quais variáveis se moveram e quanto elas pesam na predição. Técnicas de explicabilidade como SHAP values resolvem isso: drift em variável de baixa importância raramente justifica ação.
- Medir performance, real ou estimada. Com rótulo, compare a métrica de negócio com a linha de base. Sem rótulo, estime.
- Treinar um candidato e passá-lo pela porta de validação do deploy original. Ele só substitui o modelo atual se superá-lo no conjunto de validação, com atenção ao equilíbrio entre viés e variância para não trocar um modelo estável por um ajustado ao ruído recente.

Do teste estatístico ao retreino, com a triagem no meio: o alerta abre investigação e a promoção do candidato depende da porta de validação.
A etapa três trava a maioria das operações, porque o rótulo real chega tarde: um contrato de crédito só revela inadimplência meses depois da aprovação, e o modelo pode passar esse intervalo inteiro errando. Para cobrir esse intervalo existem estimadores sem rótulo, como o CBPE para classificação, que reconstrói a matriz de confusão a partir das probabilidades previstas, e o DLE para regressão, que treina um segundo modelo para prever o erro do primeiro. Ambos têm um limite bem documentado: o CBPE não funciona sob concept drift, porque assume P(Y|X) estável, e depende de probabilidades calibradas.
O desenho final tem quatro camadas de sinal, da mais barata para a mais confiável: qualidade de dados e prediction drift avisam rápido e sem rótulo, PSI e os testes por variável dizem o que mudou nas entradas, performance estimada aproxima o impacto antes do rótulo, e performance real confirma a perda. Quem monta as quatro camadas descobre a degradação em dias.
Drift é a condição normal de qualquer modelo que opera sobre um mundo em movimento, e tratá-lo como falha pontual é o que gera projeto frágil. Uma operação madura tem detecção instrumentada, limiar calibrado com histórico próprio e uma porta de validação entre o alerta e a troca do modelo. Começar é simples: escolha as cinco features mais importantes, calcule PSI diário contra o treino, ligue um alerta em 0,25 e observe por um mês antes de ajustar. O passo anterior a isso é treinar e registrar o modelo em um ambiente já preparado para produção.
Se a sua empresa tem modelos de machine learning em produção sem monitoramento de drift, ou quer calibrar limiares e definir o gatilho de retreino com critério, nossos especialistas podem ajudar a desenhar a camada de monitoramento adequada ao seu contexto. Fale com a nossa equipe e avance na maturidade dos seus dados.
Perguntas frequentes sobre drift de modelo
O que é drift de modelo? Drift de modelo é a queda de performance de um modelo de machine learning em produção provocada por mudanças nos dados. Existem dois tipos: data drift, quando a distribuição das entradas muda, e concept drift, quando a relação entre entrada e alvo muda. O código do modelo permanece igual e a degradação acontece sem erro de execução.
Qual a diferença entre data drift e concept drift? Data drift é mudança na distribuição das entradas, P(X), e você detecta comparando distribuições, sem precisar do resultado real. Concept drift é mudança na relação entre entrada e alvo, P(Y|X), e só se confirma com rótulo ou performance estimada. Fraude adaptativa é o exemplo típico de concept drift.
Como detectar drift de modelo sem rótulos em produção? Combine três sinais que não dependem de rótulo: qualidade dos dados de entrada, prediction drift na distribuição das saídas e testes de distribuição por variável, como PSI, KS e qui-quadrado. Para aproximar a performance, use estimadores como CBPE em classificação, lembrando que eles assumem ausência de concept drift.
Qual o limiar de PSI que indica drift? A convenção de mercado trata PSI abaixo de 0,1 como estável, entre 0,1 e 0,25 como mudança moderada que pede investigação, e acima de 0,25 como deslocamento relevante. Esses cortes são prática de indústria, dependem do número de faixas e do tamanho da amostra, então calibre com o histórico do próprio modelo.
Com que frequência devo monitorar drift de modelo? A cadência sai do volume de inferências e da velocidade de mudança do fenômeno. Alto volume em tempo real sustenta janela diária; lote semanal ou mensal pede janela mensal. Qualidade de dados roda em toda execução, e vale comparar sempre contra a linha de base do treino e contra a janela anterior.








