Qualidade de Dados e Deriva

Visão geral

Sistemas de aprendizado de máquina (machine learning) são tão confiáveis quanto os dados que consomem. Em produção, problemas de dados tendem a cair em duas categorias amplas:

Problemas de qualidade de dados: os dados estão errados em relação às expectativas (por exemplo, campos ausentes, valores inválidos, junções quebradas, eventos duplicados, texto corrompido).
Deriva de dados / mudança de distribuição: os dados estão diferentes do que o modelo foi treinado para ver (por exemplo, mudanças no comportamento do usuário, novos produtos, sazonalidade, mudanças de política, atualizações de sensores).

Ambos podem degradar o desempenho do modelo, aumentar o risco e quebrar análises downstream. Este artigo cobre a teoria por trás da qualidade de dados e da deriva, e os padrões práticos usados para detectar, diagnosticar e responder a esses problemas em sistemas reais de aprendizado de máquina.

Tópicos relacionados que você pode querer junto com este artigo: Coleta e Rotulagem de Dados, Pipelines de Dados (ETL/ELT para aprendizado de máquina), Versionamento de Dados, Documentação de Conjunto de Dados (Datasheets) e Governança de Dados.

Conceitos e definições-chave

Qualidade de dados vs. deriva

Problema de qualidade de dados: Uma violação de uma expectativa definida em um ponto no tempo.
- Exemplo: age = -3, country ausente, timestamps no futuro, esquema quebrado, taxa de nulos saltando de 0,1% para 30% devido a uma falha upstream.
Deriva: Uma mudança na distribuição dos dados que pode ser válida, mas ainda assim prejudicial para um modelo.
- Exemplo: um sistema de recomendação vê novos tipos de itens; um modelo de crédito enfrenta uma recessão; um chatbot vê novas gírias.

Na prática, a linha se confunde: uma “deriva” pode, na verdade, ser um bug no pipeline (por exemplo, mudança de unidade de dólares para centavos), e um “problema de qualidade” pode refletir uma mudança real no mundo (por exemplo, um novo segmento de usuários com campos legitimamente ausentes). Trate a detecção como o início da investigação, não como o fim.

Tipos de mudança de distribuição (por que a deriva acontece)

No aprendizado supervisionado (supervised learning), você pode pensar nos dados como extraídos de uma distribuição conjunta (P(X, Y)), onde:

(X) = características (features) (entradas)
(Y) = alvo (rótulo)

Tipos comuns de mudança:

Mudança de covariáveis (covariate shift): (P(X)) muda, (P(Y \mid X)) permanece semelhante.
- Exemplo: uma campanha de marketing muda a mistura de usuários, mas “dado um perfil de usuário, a probabilidade de compra” permanece semelhante.
Mudança de prior / rótulo (prior / label shift): (P(Y)) muda, (P(X \mid Y)) permanece semelhante.
- Exemplo: a taxa de fraude aumenta, mas os padrões de fraude dentro das características permanecem semelhantes.
Deriva de conceito (concept drift): (P(Y \mid X)) muda (a relação entre entradas e rótulo muda).
- Exemplo: adversários se adaptam às regras de detecção de fraude; uma mudança de preços altera como é o “alto risco”.

Para sistemas não supervisionados (unsupervised learning) (por exemplo, detecção de anomalias) ou sistemas generativos/LLM, a deriva ainda existe, mas pode ser medida em distribuições de entrada, distribuições de embeddings, corpora de recuperação, ou sinais de qualidade de saída.

Qualidade de dados: o que medir

Uma forma prática de estruturar qualidade de dados é por meio de dimensões. Algumas comuns:

Validade (conformidade com regras)

Faixas de valores (por exemplo, 0 <= discount <= 1)
Padrões de regex (e-mails, IDs)
Enumerações (códigos de país)
Integridade referencial (chaves estrangeiras existem)
Sanidade de timestamp (não muito no futuro, monotônico quando esperado)

Completude

Taxa de nulos/ausentes por coluna
Padrões de ausência (por exemplo, address ausente apenas para certas regiões)
Cobertura (por exemplo, pelo menos N eventos por hora)

Acurácia (mais difícil, frequentemente requer verdade de base)

Checagens pontuais / auditorias
Reconciliação entre sistemas (cobrança vs. logs de eventos)
Amostragem de auditoria de rótulos para correção de anotação

Consistência

Concordância entre fontes (dois pipelines devem bater dentro de uma tolerância)
Consistência de unidades (USD vs centavos; Celsius vs Fahrenheit)
Consistência de esquema ao longo do tempo (tipos, significado, codificação)

Unicidade / duplicação

IDs de evento duplicados
Mensagens reenviadas
Falhas de idempotência na ingestão

Pontualidade / frescor

Atraso de chegada de dados (minutos/horas de defasagem)
Valores de características desatualizados no momento do serving

Qualidade de rótulos (frequentemente a maior falha silenciosa)

Ruído e ambiguidade de anotação
Deriva de definição de classe (“o que conta como spam” evolui)
Viés de amostragem nos dados rotulados
Rótulos atrasados ou ausentes (comum em fraude/saúde)

Estabelecendo dados “esperados”: baselines e contratos

Detecção de qualidade e deriva exige uma referência.

Distribuições de referência

Baselines típicos:

Baseline de treinamento: a distribuição da qual o modelo aprendeu (bom para detectar mudança que ameaça generalização).
Baseline recente: último dia/semana (bom para pegar bugs súbitos de pipeline).
Baseline sazonal: mesmo dia da semana / mesmo mês do ano passado (reduz alertas falsos para padrões previsíveis).

Contratos de dados e expectativas de esquema

Defina o que “válido” significa explicitamente, idealmente próximo à ingestão:

Campos obrigatórios
Tipos
Faixas/categorias permitidas
Semântica (unidades, significado)
Chaves de junção e cardinalidades

Isso se encaixa naturalmente com Pipelines de Dados (ETL/ELT para aprendizado de máquina) e Governança de Dados: responsáveis, SLAs e caminhos de escalonamento importam tanto quanto métricas.

Detectando problemas de qualidade de dados na prática

1) Validação baseada em regras (rápida, interpretável)

Checagens de regra são altamente eficazes para capturar regressões de pipeline.

Exemplos:

Checagens de esquema: mudanças de tipo, colunas ausentes
Checagens de faixa: preços negativos, idades impossíveis
Checagens de consistência: end_time >= start_time
Checagens de cardinalidade: IDs únicos inesperadamente altos (possível bug de hashing)

Muitas equipes implementam isso em:

Jobs de ETL (falhar rápido)
Jobs de computação de características (bloquear materialização de características)
Serving online (rejeitar ou atribuir valores padrão a valores inválidos)

2) Detecção estatística de anomalias em métricas (boa para “picos”)

Acompanhe métricas de resumo ao longo do tempo:

taxa de nulos
média/desvio-padrão
percentis
contagem de únicos
taxa de duplicação
taxa de correspondência de junção
defasagem de frescor

Depois detecte anomalias usando:

limiares simples
z-scores robustos / desvio absoluto mediano
detecção de ponto de mudança (para mudanças súbitas)

Isso costuma ser melhor do que detecção de anomalias em nível de linha para monitorar pipelines.

3) Auditorias de rótulos e anotações

Para aprendizado supervisionado, problemas de rótulo podem dominar os erros do modelo.

Práticas comuns:

Concordância entre anotadores (inter-annotator agreement) para rótulos humanos
Conjunto ouro (gold set): um subconjunto rotulado confiável usado para detectar deriva de anotação
Revisão de confusão (confusion review): inspecionar regularmente falsos positivos/negativos
Rastreamento de política: versionar as diretrizes de rotulagem (se conecta a Documentação de Conjunto de Dados (Datasheets))

Exemplo: checagens simples de qualidade em Python

import pandas as pd

def quality_report(df: pd.DataFrame) -> dict:
    report = {}
    for col in df.columns:
        s = df[col]
        report[col] = {
            "dtype": str(s.dtype),
            "null_rate": float(s.isna().mean()),
            "n_unique": int(s.nunique(dropna=True))
        }
    return report

def assert_rules(df: pd.DataFrame):
    # Schema / required columns
    required = {"user_id", "price", "timestamp"}
    missing = required - set(df.columns)
    if missing:
        raise ValueError(f"Missing columns: {missing}")

    # Range checks
    if (df["price"] < 0).any():
        bad = int((df["price"] < 0).sum())
        raise ValueError(f"Found {bad} negative prices")

    # Timestamp sanity (example)
    ts = pd.to_datetime(df["timestamp"], errors="coerce")
    if ts.isna().mean() > 0.001:
        raise ValueError("Too many unparseable timestamps")

# Usage
# df = ...
# print(quality_report(df))
# assert_rules(df)

Esse tipo de validação é intencionalmente “chato”—e muito eficaz.

Detectando deriva: métodos e métricas

A detecção de deriva pergunta: “Os dados de hoje são estatisticamente diferentes da referência?” e “Essa diferença é significativa para o desempenho do modelo?”

Deriva univariada (por característica)

Testes/métricas comuns para características numéricas:

Teste de Kolmogorov–Smirnov (KS): compara duas distribuições contínuas
Distância de Wasserstein: distância “earth mover” interpretável entre distribuições
Índice de Estabilidade Populacional (Population Stability Index, PSI): amplamente usado no monitoramento de risco de crédito
Divergência de Jensen–Shannon / divergência KL: para distribuições discretas/agrupadas em bins

Deriva categórica:

Teste qui-quadrado
Distância de variação total
Deltas de frequência de categoria, mais taxa de “nova categoria”

Nota prática: significância estatística é fácil com tamanhos de amostra grandes. Sempre combine testes com tamanho de efeito (quão grande é a mudança?) e impacto no negócio (isso importa?).

Exemplo: PSI para uma característica numérica

import numpy as np
import pandas as pd

def psi(expected: pd.Series, actual: pd.Series, bins=10, eps=1e-6) -> float:
    # Bin by expected quantiles
    quantiles = np.linspace(0, 1, bins + 1)
    cuts = expected.quantile(quantiles).values
    cuts[0], cuts[-1] = -np.inf, np.inf

    e_counts, _ = np.histogram(expected.dropna(), bins=cuts)
    a_counts, _ = np.histogram(actual.dropna(), bins=cuts)

    e_perc = np.maximum(e_counts / max(e_counts.sum(), 1), eps)
    a_perc = np.maximum(a_counts / max(a_counts.sum(), 1), eps)

    return float(np.sum((a_perc - e_perc) * np.log(a_perc / e_perc)))

# Rule of thumb often used in industry (context-dependent):
# PSI < 0.1: minor shift
# 0.1–0.25: moderate shift
# > 0.25: major shift

O PSI é sensível à forma como você faz os bins; é melhor usá-lo de forma consistente e junto com outros sinais.

Deriva multivariada (entre muitas características)

A deriva real pode não aparecer em nenhuma característica isolada, mas nas interações entre características. Abordagens comuns:

Teste de duas amostras baseado em classificador (classifier-based two-sample test)
- Treine um modelo para distinguir amostras de “referência” vs “atual”.
- Se um classificador consegue separá-las bem (AUC alto), as distribuições diferem.
- Vantagens: funciona em alta dimensionalidade; captura interações.
- Ressalva: pode detectar mudanças que não afetam seu modelo preditivo.
Testes de duas amostras por kernel (por exemplo, MMD)
- Poderosos, mas podem ser computacionalmente pesados e sensíveis à escolha do kernel.
Deriva de embeddings (embedding drift)
- Para texto/imagens, compare distribuições de embeddings de um codificador congelado.

Exemplo: detecção de deriva baseada em classificador (esboço)

import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score
from sklearn.ensemble import RandomForestClassifier

def drift_auc(X_ref, X_cur, seed=0):
    X = np.vstack([X_ref, X_cur])
    y = np.hstack([np.zeros(len(X_ref)), np.ones(len(X_cur))])

    Xtr, Xte, ytr, yte = train_test_split(X, y, test_size=0.3, random_state=seed, stratify=y)

    clf = RandomForestClassifier(n_estimators=200, random_state=seed)
    clf.fit(Xtr, ytr)
    p = clf.predict_proba(Xte)[:, 1]
    return roc_auc_score(yte, p)

# Interpretation:
# AUC ~ 0.5 => no detectable drift
# AUC high (e.g., > 0.8) => strong separability => substantial drift

Para diagnosticar o que mudou, inspecione importâncias de características ou use SHAP no classificador de deriva.

Deriva no alvo e no desempenho

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

acurácia/ROC-AUC/PR-AUC
erro de calibração (probabilidades ficando mal calibradas)
perda (log loss, Brier score)
desempenho por subgrupo (a deriva pode ser localizada)

Se os rótulos são atrasados (fraude, churn), use proxies:

distribuição de pontuação do modelo
taxas de rejeição/aprovação
resultados downstream de revisão humana
KPIs de negócio (com cautela—KPIs podem ter confundidores)

A deriva de conceito frequentemente aparece primeiro como degradação de desempenho em vez de deriva óbvia de características.

Detecção de deriva em streaming (online / quase em tempo real)

Para cenários de streaming, use detectores de mudança desenhados para dados em evolução:

Teste de Page-Hinkley
ADWIN
DDM/EDDM (métodos de detecção de deriva baseados em taxas de erro)
Detectores no estilo CUSUM

Eles são comuns em detecção de anomalias em tempo real e pipelines de IoT, onde comparações em batch são lentas demais.

Interpretando sinais de deriva (evitando alarmes falsos)

Significância estatística vs. prática

Um teste KS pode sinalizar mudanças minúsculas como “significativas” com N grande. Acrescente:

limiares de tamanho de efeito (por exemplo, distância de Wasserstein, PSI)
limiares de impacto (por exemplo, mudança prevista de receita, aumento de risco)
análise de sensibilidade do modelo (“essa característica importa?”)

Múltiplos testes

Se você testa 500 características diariamente, algumas vão “derivar” por acaso. Mitigações:

controlar a taxa de falsas descobertas (por exemplo, Benjamini–Hochberg)
priorizar características-chave (maior importância, campos críticos conhecidos)
agregar pontuações de deriva em um pequeno número de alertas

Análise por segmento (slice)

Distribuições globais podem parecer estáveis enquanto um subgrupo crítico muda.

por geografia
tipo de dispositivo
canal de aquisição
usuários novos vs recorrentes
categoria de produto

Monitoramento baseado em slices frequentemente captura problemas mais cedo, mas aumenta o volume de alertas—use com parcimônia.

Mudanças planejadas e sazonalidade

Nem toda deriva é ruim:

promoções, feriados, lançamentos de produto
redesigns de UI
novo hardware de sensores
mudanças de política/regulatórias

Marque eventos na sua linha do tempo de monitoramento para que alertas de deriva sejam mais fáceis de interpretar.

Respondendo a problemas de qualidade de dados e deriva

Detecção sem resposta é apenas logging. Boas estratégias de resposta equilibram segurança, custo e velocidade de iteração.

Playbook de triagem (o que fazer quando um alerta dispara)

Confirmar o sinal
- É um bug de monitoramento? Um artefato de amostragem?
- Está limitado a um shard/região do pipeline?
Classificar
- regressão de qualidade de dados (esquema/faixa/frescor)?
- mudança real de distribuição (novo comportamento)?
- problema no pipeline de rótulos?
Avaliar impacto
- a saída do modelo muda materialmente?
- métricas de negócio são afetadas?
- quais segmentos são impactados?
Mitigar
- reverter mudança upstream
- bloquear dados ruins / valores padrão
- trocar para um modelo fallback
- limitar (throttle) ou adicionar revisão humana
Evitar recorrência
- adicionar/ajustar checagens de validação
- melhorar contratos de dados
- atualizar a cadência de retreinamento

Padrões comuns de mitigação

Para incidentes de qualidade de dados

Falhar rápido no ETL: impedir que dados ruins se propaguem.
Quarentena + replay: isolar batches suspeitos e reprocessar quando corrigido.
Características fallback: usar valores “último bom conhecido” por tempo limitado.
Controles de evolução de esquema: passos explícitos de migração; compatibilidade retroativa.

Para deriva (dados válidos, mas diferentes)

Ajuste de limiar/decisão: recalibrar limiares de decisão para manter uma taxa-alvo (útil sob mudança de rótulo).
Recalibração: atualizar calibração de probabilidades sem retreinamento completo se (P(Y)) mudou (comum em modelos de risco).
Retreinamento:
- com dados recentes (janela deslizante)
- com reponderação / amostragem por importância (importance sampling) (para mudança de covariáveis)
- com objetivos robustos ou aumento de dados
Portfólio de modelos:
- especializar por segmento
- fallback para um baseline mais simples em regiões incertas
Humano no loop (human-in-the-loop):
- encaminhar casos incertos para revisão
- acelerar a rotulagem para novos regimes

Isso se conecta naturalmente a práticas mais amplas de MLOps: implantações canário, avaliação em shadow e estratégias seguras de rollback.

Operacionalizando o monitoramento (onde isso fica na stack)

Onde medir

Ingestão: esquema, frescor, duplicação, validade básica
Transformação / engenharia de características: taxas de junção, taxas de nulos, outliers introduzidos por transformações
Treinamento: estatísticas do conjunto de dados, balanceamento de rótulos, checagens de vazamento, checagens de desvio treino/serving
Serving: distribuições de características ao vivo, taxas de características ausentes, distribuições de pontuação, latência/frescor
Feedback / rotulagem: taxas de chegada de rótulos, deriva de anotação

O que registrar

Para diagnosticar problemas, mantenha:

identificadores de versão de dados (se conecta a Versionamento de Dados)
versão de computação de características / hash do código
versões de esquema
snapshots de estatísticas resumidas (referência + atual)
versão do modelo e linhagem dos dados de treinamento

Alertas e SLOs

Defina objetivos de nível de serviço para dados:

“Taxa de nulos de country < 1%”
“Frescor do feature store < 15 minutos”
“Taxa de correspondência de junção > 99%”
“PSI nas top-10 características < 0,2”

Direcione alertas aos responsáveis com runbooks claros. Isso é um problema de governança tanto quanto técnico (veja Governança de Dados).

Exemplos práticos

Exemplo 1: previsão de demanda em e-commerce e sazonalidade

Um modelo de demanda treinado com os dados do ano passado vai “derivar” durante feriados. Se você comparar hoje com o baseline de treinamento, vai alertar o tempo todo.

Melhor:

usar uma janela de referência sazonal (por exemplo, a mesma semana do ano passado)
monitorar “deriva inesperada” além das normas sazonais
adicionar anotações de eventos (calendário de promoções)
retreinar em janelas móveis com características sazonais explícitas

Exemplo 2: detecção de fraude e atraso de rótulos

Rótulos de fraude podem chegar semanas depois. Checagens de deriva de características podem parecer ok, mas deriva de conceito pode ocorrer conforme atacantes se adaptam.

Monitoramento prático:

observar mudanças na distribuição de pontuação (há mais transações de alto risco?)
observar resultados de revisão (taxa de acerto da revisão manual)
avaliar periodicamente em um conjunto rotulado com atraso
usar detectores de deriva em taxa de erro quando os rótulos chegarem (estilo streaming)

Exemplo 3: sistemas de texto (LLMs, classificadores) e mudança de vocabulário

Para entradas de texto, checagens univariadas em contagens de tokens são frágeis. Melhor:

embutir textos (embed) usando um codificador fixo
monitorar deriva da distribuição de embeddings (por exemplo, deslocamento de centróide, MMD, deriva por classificador)
monitorar taxas de “novo tópico” via clusterização
acompanhar sinais operacionais (retries, insatisfação do usuário, taxa de escalonamento)

Se você usa recuperação (RAG), monitore também o corpus de recuperação: novos documentos, deleções e mudanças de relevância podem causar “deriva” mesmo se as entradas dos usuários permanecerem estáveis.

Checklist de boas práticas

Defina expectativas de dados explicitamente (esquema, faixas, frescor, junções).
Monitore tanto qualidade de dados (validade/completude) quanto deriva (mudança de distribuição).
Use múltiplos baselines (treinamento, recente, sazonal) para reduzir alertas falsos.
Prefira alertas acionáveis: combine testes estatísticos com tamanhos de efeito e impacto.
Monitore slices para segmentos críticos, mas gerencie o volume de alertas.
Versione dados, esquemas e código de características para diagnóstico reprodutível.
Construa um playbook de resposta: bloquear/quarentenar/rollback vs recalibrar/retreinar.
Trate deriva como um sinal de produto: mudança no mundo real pode exigir atualizações de modelo e de política, não apenas retreinamento.
Documente suposições e limitações em Documentação de Conjunto de Dados (Datasheets) para que o “esperado” não seja conhecimento tribal.

Resumo

O monitoramento de qualidade de dados protege você contra pipelines quebrados e entradas inválidas; o monitoramento de deriva protege você contra um mundo em mudança. Sistemas eficazes combinam contratos de dados claros, detecção estatística robusta e mecanismos operacionais de resposta (responsáveis, runbooks, estratégias de retreinamento/recalibração). O objetivo não é eliminar a deriva—é detectar mudanças significativas cedo e responder com segurança, com rastreabilidade e tempo de indisponibilidade mínimo.