Deriva de Conceito (Concept Drift)

O que é Deriva de Conceito?

A deriva de conceito (concept drift) acontece quando a relação entre as entradas do modelo (X) e o alvo (y) muda ao longo do tempo — isto é, o “conceito” que o modelo tenta aprender deixa de ser estável. Um modelo que teve bom desempenho no treinamento pode degradar em produção porque passa a resolver um problema ligeiramente diferente daquele em que foi treinado.

Formalmente, muitos modelos de aprendizado de máquina (machine learning) supervisionados assumem um processo gerador de dados estacionário. Se denotarmos a distribuição conjunta no tempo (t) como (P_t(X, y)), a deriva de conceito normalmente significa:

  • A relação condicional muda:
    [ P_t(y \mid X) \neq P_{t+\Delta}(y \mid X) ]
  • Ou a própria definição da tarefa muda (por exemplo, rótulos, regras de política, critérios de verdade-terreno, ou mudanças na intenção do usuário), o que efetivamente muda o que significa “correto”.

A deriva de conceito é intimamente relacionada à mudança de distribuição (distribution shift), mas não é idêntica. Um modelo mental útil:

  • Mudança de conjunto de dados (dataset shift) (frequentemente tratada dentro de mudança de distribuição) significa que (P(X)) e/ou (P(y)) muda. Veja Mudança de Conjunto de Dados.
  • Deriva de conceito enfatiza especificamente que o mapeamento de entradas para saídas muda: (P(y \mid X)) muda, o que geralmente é o tipo mais danoso porque invalida fronteiras de decisão aprendidas.

Na prática, isso frequentemente ocorre em conjunto: mudanças no mundo alteram tanto a distribuição de entrada quanto o significado dos rótulos.

Por que isso importa em produção

Em sistemas reais, os dados são gerados por processos em evolução:

  • Preferências dos usuários mudam.
  • Fraudadores se adaptam.
  • Produtos, preços e políticas mudam.
  • Sensores se degradam ou são recalibrados.
  • O próprio modelo muda o comportamento do ambiente (“efeitos performativos (performative effects)”).

Como resultado, modelos em produção podem falhar silenciosamente, a menos que a deriva seja monitorada e gerenciada explicitamente.

Sintomas comuns:

  • Queda gradual em acurácia/AUC/F1 após o deploy
  • Aumento da perda logarítmica (log loss) (piores estimativas de probabilidade)
  • Degradação de calibração (probabilidades previstas deixam de corresponder à realidade)
  • Mudanças em KPIs de negócio (conversão, receita, perda por fraude), mesmo que métricas offline pareçam estáveis
  • Aumento da taxa de revisão manual ou da taxa de sobrescrita humana em sistemas com humano no loop (human-in-the-loop)

Deriva de conceito vs. outros tipos de mudança

É útil separar alguns fenômenos relacionados:

Mudança de covariáveis (covariate shift) (mudança de entrada)

  • (P(X)) muda, mas (P(y \mid X)) permanece o mesmo.
  • Exemplo: um modelo de câmera muda, alterando distribuições de pixels, mas a definição de “gato vs. cachorro” permanece consistente.
  • Às vezes os modelos podem continuar precisos se generalizarem bem, mas o monitoramento ainda deve capturar isso.

Mudança de rótulos (label shift) (mudança a priori)

  • (P(y)) muda, mas (P(X \mid y)) permanece estável (frequentemente uma aproximação).
  • Exemplo: a proporção de transações fraudulentas aumenta durante feriados.

Deriva de conceito (mudança condicional / mudança de conceito)

  • (P(y \mid X)) muda.
  • Exemplo: spammers mudam táticas; palavras que antes indicavam spam se tornam comuns em e-mails legítimos.

A deriva de conceito costuma ser a mais difícil porque significa que a regra de decisão precisa mudar.

Tipos comuns de deriva de conceito

A deriva costuma ser descrita pelo seu padrão temporal e impacto operacional.

Deriva súbita (abrupta)

O conceito muda rapidamente — em minutos, horas ou um dia.

Exemplos

  • Um novo grupo de fraude inicia uma campanha.
  • Uma plataforma muda sua UI, alterando o comportamento do usuário imediatamente.
  • Uma atualização de política muda definições de rótulo da noite para o dia (por exemplo, o que conta como “elegível”).

Assinatura em produção

  • Uma queda brusca em métricas de desempenho após um horário específico.
  • Picos de alertas concentrados em torno de um deploy, mudança upstream ou evento externo.

Deriva gradual

O conceito muda lentamente à medida que o ambiente evolui.

Exemplos

  • Preferências dos clientes mudam lentamente com estações ou tendências.
  • A linguagem evolui (gírias novas), afetando modelos de PLN (NLP).
  • Concorrentes mudam preços, alterando gradualmente padrões de demanda.

Assinatura em produção

  • Queda lenta, porém persistente, nas métricas.
  • Aumento de taxas de erro em dados mais novos enquanto fatias antigas permanecem estáveis.

Deriva incremental

Um subtipo de deriva gradual em que o conceito se move em pequenos passos, potencialmente com fases intermediárias estáveis.

Exemplo

  • Padrões de concessão de crédito são endurecidos por etapas.

Deriva recorrente / sazonal

Conceitos antigos retornam (semanalmente, mensalmente, anualmente).

Exemplos

  • Padrões de demanda do varejo se repetem a cada temporada de feriados.
  • Modelos de escalas de trabalho veem ciclos semanais.
  • O comportamento de clique em anúncios muda durante grandes eventos anuais.

Assinatura em produção

  • Métricas se degradam em períodos previsíveis e se recuperam depois.
  • Forte periodicidade nas distribuições de atributos e nos erros.

Deriva pontual / transitória

Um choque de curta duração que rapidamente retorna à linha de base.

Exemplos

  • Uma indisponibilidade breve causa perda parcial de dados.
  • Um evento viral único gera tráfego anômalo.

Assinatura em produção

  • Anomalia súbita e recuperação rápida.
  • Muitas vezes é melhor tratada com estratégias de fallback do que com retreinamento imediato.

Exemplos práticos

Exemplo 1: Detecção de spam (deriva de conceito adversarial)

Um classificador de spam treinado com dados do ano passado usava palavras-chave como “free”, “winner” e certos padrões de links.

  • Atacantes se adaptam: newsletters legítimas começam a usar “free trial”, enquanto spammers migram para conteúdo apenas com imagens ou domínios aparentemente benignos.
  • Resultado: (P(y \mid X)) muda — atributos antes preditivos perdem força; novos padrões surgem.

O que você vê

  • Falsos negativos aumentam (spam passa).
  • Certos segmentos de usuários reclamam mais; taxas de reporte manual sobem.

Exemplo 2: Modelo de risco de crédito (deriva de conceito por política)

Um credor muda critérios de aprovação ou introduz um novo nível de produto. O significado de “inadimplência” também pode mudar devido a regras revisadas de reporte.

  • Mesmo que entradas (renda, utilização) pareçam semelhantes, o processo de rotulagem mudou.
  • O modelo agora está desalinhado com a realidade atual de concessão.

O que você vê

  • A calibração quebra: probabilidades previstas de inadimplência subestimam/superestimam de forma sistemática.
  • KPIs de negócio downstream (taxa de perda) divergem do esperado.

Exemplo 3: Previsão de demanda (deriva recorrente)

Um modelo de previsão para uma rede de supermercados enfrenta:

  • Sazonalidade semanal (finais de semana vs dias úteis)
  • Feriados anuais (pico de Thanksgiving)
  • Mudanças de tendência de longo prazo (novas dietas, inflação)

O que você vê

  • Se o modelo subpondera padrões sazonais, tem desempenho ruim durante eventos recorrentes.
  • Validação adequada sensível ao tempo e retreinamento periódico mitigam isso.

Como a deriva aparece em métricas de produção

1) Métricas de desempenho do modelo (requer rótulos)

Quando você tem rótulos em tempo hábil, monitore:

  • Acurácia / F1 / AUC (classificação)
  • RMSE / MAE / MAPE (regressão)
  • Perda logarítmica (classificação probabilística)
  • Erro de calibração (por exemplo, ECE), gráficos de confiabilidade

Monitore também desempenho por fatia:

  • Geografia, tipo de dispositivo, canal, segmento de clientes, idioma
  • “Usuários novos vs recorrentes”
  • Janelas de tempo (última hora/dia/semana)

A deriva frequentemente aparece primeiro em uma fatia específica antes de afetar métricas globais.

2) Métricas proxy (quando os rótulos atrasam)

Muitos sistemas só obtêm rótulos dias ou semanas depois (chargebacks, churn, desfechos médicos). Use proxies:

  • Mudanças na distribuição de previsões (por exemplo, a média do score aumenta)
  • Mudanças de confiança/incerteza (mais previsões com baixa confiança)
  • Métricas de deriva na distribuição de atributos (PSI, teste KS, deriva de embeddings)
  • Verificações de qualidade de dados (ausência de valores, mudanças de esquema, valores fora do intervalo)

Métricas proxy não provam deriva de conceito, mas ajudam a triagem (triage): “algo mudou; investigue”.

3) Métricas de negócio e operacionais

Às vezes o primeiro sinal não é “acurácia do modelo”, mas impacto operacional:

  • Aumento de tickets de suporte ao cliente
  • Maior volume de revisão manual ou taxa de sobrescrita
  • Mudanças na taxa de conversão
  • Mudanças na taxa de perdas por fraude
  • Picos de latência (podem correlacionar com degradação de sistemas upstream)

Estratégias de detecção de deriva

A detecção de deriva vai de monitoramento simples a testes estatísticos formais e detectores especializados. A abordagem correta depende da disponibilidade de rótulos, criticidade do sistema e tolerância a alarmes falsos.

A) Detecção supervisionada de deriva (com rótulos)

Se você consegue observar (y) relativamente rápido, pode detectar deriva diretamente pelos erros.

Abordagens comuns:

  • Acompanhamento de desempenho em janelas: comparar métrica recente vs baseline.
  • Detecção de ponto de mudança (change-point detection) em taxas de erro ou perda (CUSUM, Page-Hinkley).
  • Detectores dedicados de deriva de aprendizado de máquina em streaming:
    • DDM (Drift Detection Method)
    • EDDM (Early Drift Detection Method)
    • ADWIN (Adaptive Windowing)

Conceitualmente, esses métodos sinalizam deriva quando as estatísticas de erro do modelo mudam além do ruído esperado.

B) Detecção não supervisionada / sem rótulos (monitoramento de dados e previsões)

Quando rótulos atrasam ou não estão disponíveis, monitore:

  • Deriva na distribuição de atributos: teste KS (contínuo), qui-quadrado (categórico), PSI (comum em risco de crédito).
  • Deriva multivariada: MMD, distância de energia, testes de duas amostras baseados em classificadores.
  • Deriva de embeddings: comparar distribuições de embeddings aprendidos (útil para texto/imagem).
  • Deriva de previsões: mudanças em distribuições de score, estabilidade de ranking, composição do top-k (recomendação).

Cuidado: deriva de atributos não necessariamente significa deriva de conceito. É um indicador antecedente.

C) Detecção de deriva por fatias

O monitoramento agregado pode esconder deriva que afeta apenas um subconjunto do tráfego. Acompanhe sinais de deriva por fatia e alerte em:

  • Maiores deltas negativos
  • Fatias com alto volume e piora de desempenho
  • Fatias raras, mas de alto risco (por exemplo, transações de alto valor)

D) Verificações de “desalinhamento entre treinamento e serving (training-serving skew)”

Alguma “deriva” é, na verdade, bug:

  • Pré-processamento de atributos diferente online vs offline
  • Atributos faltantes no momento do serving
  • Vazamento de dados durante o treinamento
  • Inconsistências na definição de rótulos

Isso pode imitar deriva de conceito, mas requer correções de engenharia em vez de retreinamento.

Estratégias de mitigação

Nenhuma mitigação funciona universalmente. Um tratamento eficaz de deriva combina monitoramento, retreinamento, modelagem robusta e playbooks operacionais.

1) Estratégias de retreinamento

Retreinamento agendado

Retreinar em uma cadência fixa (semanal/mensal/trimestral).

  • Funciona bem para deriva recorrente ou gradual.
  • Simples operacionalmente.
  • Risco: lento demais para deriva súbita; desperdício se o ambiente estiver estável.

Retreinamento acionado (sensível à deriva)

Retreinar quando detectores de deriva ou limiares de KPI disparam.

  • Resposta mais rápida a mudanças abruptas.
  • Exige ajuste cuidadoso de alertas para evitar retreinar por ruído.

Janela deslizante / ponderação por recência

Treinar nos (N) dias/semanas mais recentes, ou dar mais peso a exemplos recentes.

  • Ajuda quando dados antigos são enganosos.
  • Risco: esquecimento catastrófico (perda de cobertura de cauda longa) se a deriva for recorrente.

Aprendizado online / atualizações incrementais

Atualizar o modelo continuamente (ou em pequenos lotes) conforme novos dados rotulados chegam. Veja Aprendizado Online.

  • Útil em ambientes que mudam rápido (anúncios, fraude).
  • Exige salvaguardas fortes: monitoramento, rollback e prevenção de loops de feedback.

Aprendizado ativo / rotulagem direcionada

Se rótulos são caros, priorize rotular casos recentes, incertos ou de alto impacto. Veja Aprendizado Ativo.

2) Técnicas de robustez do modelo

  • Regularização e modelos mais simples podem ser mais estáveis sob deriva leve.
  • Conjuntos (ensembles) podem ajudar: combinar modelos treinados em diferentes janelas de tempo.
  • Adaptação de domínio (domain adaptation) e aprendizado de representações podem reduzir sensibilidade a mudanças de covariáveis (embora não “consertem magicamente” deriva de conceito verdadeira).
  • Manutenção de calibração: recalibrar probabilidades (por exemplo, Platt scaling, regressão isotônica) quando o ranking ainda é bom, mas as probabilidades derivam. Veja Calibração de Modelo.

3) Endurecimento de pipelines de dados e atributos

Muitos “incidentes de deriva” são, na verdade, mudanças de pipeline:

4) Humano no loop e proteções de política

Em cenários de alto risco:

  • Encaminhar casos de baixa confiança ou fora da distribuição para revisão humana.
  • Adicionar restrições baseadas em regras para segurança (por exemplo, nunca negar automaticamente se documentos-chave estiverem faltando).
  • Monitorar motivos de sobrescrita para descobrir padrões de deriva.

5) Playbooks de fallback e rollback

Para confiabilidade em produção, assuma que a deriva vai acontecer e prepare procedimentos.

Fallback: manter um modo degradado seguro disponível:

  • Usar um modelo baseline mais simples
  • Usar heurísticas/regras
  • Aumentar revisão manual
  • Congelar certas ações automatizadas

Rollback: retornar para uma versão anterior do modelo se o modelo mais recente estiver com problema (por exemplo, um retreinamento ruim ou bug).

Exemplo de playbook operacional (simplificado):

1. Alert fires: KPI drop or drift detector triggers
2. Triage (within SLA):
   - Check data pipeline health (schema, missingness, latency)
   - Check recent deploys (features, model version, upstream services)
   - Identify impacted slices and time of onset
3. Mitigate immediately:
   - Enable fallback OR rollback model version
   - Increase human review for risky band
4. Diagnose:
   - Confirm label delay and estimate expected metric noise
   - Determine drift type (sudden/gradual/recurring) and scope
5. Recover:
   - Collect/label recent data
   - Retrain with appropriate windowing/weights
   - Validate offline + shadow test + canary deploy
6. Post-incident:
   - Document root cause and update monitors/thresholds

Projetando monitoramento para deriva de conceito

Uma pilha prática de monitoramento frequentemente inclui:

  • Verificações de qualidade de dados: esquema, valores ausentes, outliers
  • Verificações de deriva de distribuição: deriva univariada + multivariada em atributos-chave e embeddings
  • Monitoramento de previsões: distribuição de scores, confiança, taxas de decisão
  • Monitoramento de resultados (quando rótulos chegam): desempenho e calibração ao longo do tempo e por fatia
  • Monitoramento de KPIs de negócio: impacto ponta a ponta
  • Roteamento de alertas: ownership claro e SLAs (engenharia de dados vs ML vs produto)

Um padrão comum é um sistema de alertas em duas etapas:

  1. Alerta antecipado: sinais de deriva de atributos/previsões (maior sensibilidade, mais falsos positivos)
  2. Confirmação: queda de desempenho com rótulos (menor sensibilidade, maior confiança)

Práticas de avaliação que reduzem o risco de deriva

Uma boa avaliação offline não previne deriva, mas reduz surpresas.

  • Use divisões baseadas em tempo (treinar no passado, validar em períodos mais recentes) em vez de divisões aleatórias para dados temporais.
  • Faça backtest em múltiplos períodos históricos para capturar sazonalidade.
  • Acompanhe desempenho em fatias recentes explicitamente.
  • Simule atraso de rótulos se isso refletir a realidade de produção.
  • Mantenha um modelo baseline forte para comparação.

Para deploy, use práticas de liberação em estágios:

  • Modo sombra (shadow mode) (registrar previsões, não agir)
  • Deploy canário (canary deployment) (pequena % do tráfego)
  • Testes A/B quando viável. Veja Testes A/B

Armadilhas comuns

  • Confundir mudança de covariáveis com deriva de conceito: entradas mudarem não garante que (P(y \mid X)) mudou.
  • Reagir demais ao ruído: janelas pequenas levam a métricas de alta variância e falsos alarmes.
  • Ignorar deriva por fatias: métricas globais podem parecer boas enquanto um segmento-chave falha.
  • Retreinar em dados corrompidos: se a deriva for causada por um bug de pipeline, o retreinamento incorpora o bug no modelo.
  • Loops de feedback: decisões do modelo mudam os dados que você depois usa para treinar (por exemplo, sistemas de recomendação), complicando a interpretação de deriva.

Resumo

Deriva de conceito é a realidade prática de que o mundo muda: o mapeamento de entradas para resultados (ou a definição do resultado) evolui, fazendo com que modelos em produção se degradem. A deriva pode ser súbita, gradual, recorrente ou transitória, e aparece por meio de quedas de desempenho, problemas de calibração, falhas específicas por fatia e mudanças em KPIs de negócio.

Um tratamento robusto de deriva é tanto uma disciplina de engenharia quanto uma técnica de aprendizado de máquina:

  • Monitorar dados, previsões, resultados e KPIs de negócio
  • Detectar deriva com métodos sem rótulos e com rótulos
  • Mitigar com retreinamento (agendado ou acionado), janelas/ponderação, calibração e salvaguardas humanas
  • Operar com playbooks claros de fallback/rollback e resposta a incidentes

Para uma discussão mais ampla sobre mudanças entre distribuições de treinamento e deploy, veja Mudança de Conjunto de Dados.