Vazamento

Vazamento (leakage) (frequentemente vazamento de dados (data leakage) ou vazamento do alvo (target leakage)) é qualquer situação em que informações que não estariam disponíveis no momento da predição (prediction time) acabam influenciando um modelo durante o treinamento, a validação ou o teste. O vazamento pode fazer as métricas offline parecerem espetaculares enquanto o desempenho no mundo real desaba — porque o modelo, na prática, “espiou” a resposta ou informações futuras.

O vazamento é especialmente comum na engenharia de atributos (feature engineering) porque é nela que transformamos, agregamos, codificamos e selecionamos dados — muitas vezes em todo o conjunto de dados — às vezes deixando, sem querer, que informações futuras ou derivadas do rótulo se infiltrem no processo de treinamento.

O que é vazamento (e por que isso importa)

Em alto nível, o aprendizado supervisionado (supervised learning) assume este fluxo de trabalho:

  1. Você tem entradas (X) que estariam disponíveis quando você precisa fazer uma predição.
  2. Você tem rótulos (y) (o desfecho) que não estão disponíveis no momento da predição.
  3. Você treina em exemplos históricos ((X, y)) e valida em exemplos retidos (held-out) que simulam predições futuras.

O vazamento quebra essa separação. Na prática, o vazamento leva a:

  • Pontuações offline infladas (AUC/acurácia/RMSE)
  • Validação instável (pontuações variam muito com diferentes divisões)
  • Falha em produção (desempenho cai após a implantação (deployment))
  • Importância de atributos (feature importance) enganosa (o modelo depende de atributos “trapaceiros”)

Vazamento não é a mesma coisa que sobreajuste (overfitting). Sobreajuste é aprender ruído do conjunto de treinamento que não generaliza. Vazamento é aprender informações que não deveriam estar presentes em primeiro lugar.

Tipos comuns de vazamento

1) Vazamento do alvo (vazamento do rótulo)

Vazamento do alvo acontece quando os atributos incluem informações diretamente derivadas do alvo — ou um proxy que, na prática, o revela.

Exemplo: atributos “pós-desfecho” em saúde

Objetivo: prever se um paciente será readmitido em até 30 dias.

Exemplos de atributos com vazamento:

  • length_of_stay (frequentemente determinado após a admissão e correlacionado com complicações)
  • discharge_disposition (pode refletir desfechos da internação)
  • received_followup_call (pode ocorrer apenas para pacientes de alto risco)

Se esses atributos são registrados depois do momento em que a predição deveria ser feita, eles vazam conhecimento futuro.

Exemplo: previsão de evasão com informação de cancelamento

Objetivo: prever se um usuário terá evasão (churn) no próximo mês.

Atributo com vazamento:

  • account_closed_date ou cancellation_reason (só é conhecido quando a evasão ocorre)

Um modelo treinado com esses atributos parecerá quase perfeito offline, mas não pode funcionar prospectivamente.

2) Contaminação entre treino e teste (vazamento na divisão dos dados)

Isso ocorre quando o processo de treinamento usa informações do conjunto de teste/validação.

Causas comuns:

  • Pré-processamento (preprocessing) (escalonamento (scaling), imputação (imputation)) ajustado no conjunto de dados completo
  • Seleção de atributos (feature selection) realizada antes da divisão
  • Registros duplicados ou quase duplicados aparecendo tanto no treino quanto no teste
  • Vazamento entre usuários/entidades (o mesmo cliente aparece no treino e no teste)

Exemplo: o mesmo cliente no treino e no teste

Se você está prevendo o valor do tempo de vida do cliente (customer lifetime value) e faz uma divisão aleatória por linhas, pode colocar transações mais antigas de um cliente no treino e transações mais recentes no teste. O modelo então se beneficia de já ter “visto” aquele cliente — levando a uma avaliação otimista demais.

Por isso, frequentemente você precisa de divisões agrupadas (grouped splits) (por exemplo, por ID do cliente). Veja: Validação Cruzada e Divisão Treino-Teste.

3) Vazamento temporal (olhar para o futuro)

Vazamento temporal é um caso especial de contaminação em que dados futuros influenciam o treinamento.

Comum em:

  • previsão de séries temporais (time series forecasting)
  • previsão de eventos
  • detecção de fraude
  • manutenção preditiva

Exemplo: médias móveis calculadas incorretamente

Você quer prever a demanda de amanhã. Você calcula uma “média de 7 dias”, mas acidentalmente inclui o valor de amanhã (ou calcula usando a série completa com janelas centradas). Sua validação vai parecer excelente, mas a implantação vai falhar.

Para problemas ordenados no tempo, em geral você precisa de divisão sensível ao tempo (time-aware splitting) e computação de atributos sensível ao tempo. Veja: Previsão de Séries Temporais.

4) Vazamento por agregação e joins

O vazamento frequentemente entra sorrateiro quando você faz joins de tabelas ou calcula agregações.

Exemplo: agregações que incluem a janela atual do rótulo

Suponha que você preveja se um usuário vai comprar nos próximos 7 dias. Você cria um atributo:

  • purchases_last_7_days

Se ele for calculado no treinamento sem cortes cuidadosos por timestamp, você pode incluir acidentalmente compras que ocorreram depois do momento da predição — especialmente se a sua janela de rotulagem se sobrepõe à janela do atributo.

Isso é um problema frequente de “correção ponto no tempo (point-in-time correctness)” em lojas de atributos (feature stores).

5) Vazamento por pré-processamento fora de um pipeline

Muitas transformações são aceitáveis — desde que sejam ajustadas apenas nos dados de treinamento. O vazamento acontece quando você as ajusta em todos os dados e só depois divide.

Culpados típicos:

  • Padronização/normalização
  • Imputação
  • Análise de Componentes Principais (PCA)
  • Vetorizadores de texto (text vectorizers) ajustados em todos os documentos (incluindo teste)
  • Seleção de atributos usando rótulos de teste indiretamente

Exemplo concreto: escalonar antes de dividir (com vazamento)

from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import roc_auc_score

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# WRONG: fitting scaler on full data (leaks test distribution)
scaler = StandardScaler().fit(X)
X_train_scaled = scaler.transform(X_train)
X_test_scaled = scaler.transform(X_test)

model = LogisticRegression(max_iter=1000).fit(X_train_scaled, y_train)
print("AUC:", roc_auc_score(y_test, model.predict_proba(X_test_scaled)[:, 1]))

Abordagem correta: usar um pipeline (sem vazamento)

from sklearn.pipeline import Pipeline

pipe = Pipeline([
    ("scaler", StandardScaler()),
    ("clf", LogisticRegression(max_iter=1000))
])

pipe.fit(X_train, y_train)  # scaler is fit only on X_train
print("AUC:", roc_auc_score(y_test, pipe.predict_proba(X_test)[:, 1]))

Isso se torna ainda mais importante com Validação Cruzada, em que o pré-processamento deve ser reajustado dentro de cada fold.

6) Vazamento por codificação pelo alvo e codificação pela média

Codificação pelo alvo (target encoding) substitui categorias por estatísticas do rótulo (por exemplo, média de (y) por categoria). Feita de forma ingênua, ela pode vazar o rótulo para dentro dos atributos — especialmente para categorias raras.

Codificação pelo alvo ingênua (com vazamento)

Se você calcula a média do alvo por categoria no conjunto de dados completo, cada linha “vê” a si mesma.

Abordagem mais segura: codificação pelo alvo fora da dobra (out-of-fold)

Calcule as codificações usando apenas as dobras de treinamento e aplique na dobra retida. Muitas bibliotecas oferecem suporte a isso; você também pode implementar manualmente com lógica de validação cruzada em K dobras (K-fold).

Conceitualmente:

  • Para cada dobra: compute categoria → média(y) nas outras dobras
  • Aplique essas médias à dobra
  • Use um prior global para categorias não vistas

7) Vazamento por seleção de atributos feita antes da validação

Se você seleciona atributos usando o conjunto de dados inteiro (incluindo validação/teste), você está implicitamente usando informações do conjunto de avaliação.

Padrão com vazamento:

  1. Calcular correlação com o alvo usando todos os dados
  2. Escolher os principais atributos
  3. Treinar e avaliar

Padrão correto:

  • A seleção de atributos deve estar dentro do loop de treinamento (pipeline / validação cruzada). Veja: Seleção de Atributos.

8) Vazamento por reamostragem (SMOTE, sobreamostragem) antes de dividir

Se você faz sobreamostragem (oversampling) de classes minoritárias antes de dividir, pontos sintéticos ou duplicados podem aparecer tanto no treino quanto no teste, contaminando a avaliação.

Correto:

  • Dividir primeiro
  • Aplicar sobreamostragem apenas no treinamento (e dentro de cada fold da validação cruzada)

9) Vazamento de benchmark / avaliação (contexto mais amplo de ML)

Fora da engenharia de atributos clássica, vazamento também pode ocorrer quando:

  • conjuntos de teste se tornam “públicos” e modelos são ajustados a eles ao longo do tempo
  • hiperparâmetros (hyperparameters) são ajustados repetidamente com base no mesmo conjunto de validação (na prática, sobreajustando à validação)

A mitigação padrão é um conjunto de teste de reserva (holdout) de verdade ou Validação Cruzada Aninhada.

Como o vazamento acontece em fluxos de trabalho reais

O vazamento frequentemente não é um único bug — é um descompasso entre os dados disponíveis no momento do treinamento e os dados disponíveis no momento da inferência (inference).

Causas-raiz típicas:

  • Momento de predição pouco claro: equipes não especificam o instante exato em que os atributos são “congelados”
  • Rótulos baseados em eventos com janelas sobrepostas: o rótulo usa desfechos futuros; atributos incluem acidentalmente parte dessa janela futura
  • Joins por conveniência: joins por chaves sem restrições de timestamp
  • Pré-processamento global: transformações ajustadas em todos os dados por conveniência
  • Divisões por linha para problemas por entidade: o mesmo usuário/paciente/dispositivo aparece em várias divisões
  • Iteração guiada por métricas: ajustes repetidos em um único conjunto de validação

Um modelo mental útil é correção ponto no tempo:

Para cada exemplo de treinamento, você consegue reconstruir exatamente o que teria sabido no momento em que a predição deveria ser feita?

Se não, o risco de vazamento é alto.

Como detectar vazamento

Detectar vazamento é parte ciência, parte investigação forense. O objetivo é responder: o modelo está usando informações que não estariam disponíveis no momento da predição?

1) Fique atento a resultados “bons demais para ser verdade”

Sinais de alerta incluem:

  • AUC/acurácia quase perfeita em um problema difícil do mundo real
  • Diferença dramática entre desempenho offline e online
  • Desempenho que quase não muda com a escolha do modelo (modelos simples igualam os complexos)
  • Atributos com importância suspeitamente alta que parecem indisponíveis operacionalmente

2) Compare múltiplas estratégias de divisão

Execute avaliações com divisões que se aproximem mais da implantação:

  • Divisão aleatória (baseline)
  • Divisão baseada em tempo (para problemas temporais)
  • Divisão agrupada por entidade (cliente/paciente/dispositivo)

Se o desempenho desaba sob divisões baseadas em tempo ou agrupadas, sua avaliação original provavelmente se beneficiou de vazamento ou contaminação.

3) Faça auditorias de “disponibilidade” de atributos

Para cada atributo, documente:

  • tabela e campo de origem
  • timestamp da observação
  • se ele pode ser conhecido no momento da predição
  • latência (quanto tempo até ser registrado)
  • se ele é inserido manualmente depois do fato

Essa costuma ser a técnica mais eficaz de prevenção de vazamento porque força clareza sobre o cenário de predição.

4) Use testes de ablação e verificações de sanidade com “embaralhamento de rótulos”

  • Ablação (ablation): remova atributos suspeitos e veja quanto a métrica cai.
  • Embaralhamento de rótulos (label shuffling): treine com rótulos aleatórios; o desempenho deve cair para o nível do acaso. Se não cair, há contaminação (por exemplo, duplicação de dados, alvo presente nos atributos).

5) Inspecione vazamento via importância e explicações de atributos

Usar importância por permutação (permutation importance) ou ferramentas do tipo SHAP (SHAP) pode destacar atributos suspeitos:

  • IDs que correlacionam com o desfecho
  • timestamps muito próximos do momento do desfecho
  • campos de “status” que codificam o resultado

Explicações não provam vazamento, mas ajudam a priorizar a investigação. Veja: Avaliação de Modelos.

6) Verifique duplicatas e quase duplicatas entre divisões

Especialmente em problemas de texto/imagem, exemplos quase duplicados podem vazar entre divisões (mesma imagem redimensionada, mesmo artigo sindicado etc.). Use checagens de similaridade ou desduplicação baseada em hash.

7) Valide seus caminhos de código de pré-processamento e treinamento

Verificações comuns no nível de código:

  • Garantir que chamadas a .fit() ocorram apenas nas dobras de treinamento
  • Garantir que a seleção de atributos esteja dentro da validação cruzada
  • Garantir que a reamostragem seja aplicada apenas no treinamento
  • Garantir que o conjunto de teste nunca seja usado para decisões de parada antecipada (early stopping) sem tratamento cuidadoso

Como prevenir vazamento (boas práticas)

Prevenir vazamento é mais fácil do que detectá-lo depois. O tema é: projetar seus dados e sua avaliação para simular a implantação.

1) Defina o problema de predição com precisão

Anote, explicitamente:

  • Qual é o alvo e o horizonte de predição? (por exemplo, “compra nos próximos 7 dias”)
  • Quando a predição é feita? (timestamp)
  • Quais dados estão disponíveis naquele momento?
  • Qual é a unidade de predição? (usuário, sessão, conta)

Essa definição orienta janelas corretas de atributos, joins e divisões.

2) Use divisão segura contra vazamento

Escolha divisões que combinem com o mundo real:

  • Séries temporais / predição de futuro: divisões baseadas em tempo (treinar no passado, testar no futuro)
  • Múltiplas linhas por entidade: divisões agrupadas (entidade inteira no treino ou no teste)
  • Sistemas não estacionários: avaliação em janela móvel/encadeamento para a frente (rolling/forward-chaining evaluation)

Evite divisões aleatórias por linha quando elas violam o cenário de implantação.

3) Coloque pré-processamento e seleção de atributos dentro de pipelines

Em Python/scikit-learn, use Pipeline e ColumnTransformer para que as transformações sejam ajustadas apenas nos dados de treinamento.

from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.impute import SimpleImputer
from sklearn.preprocessing import OneHotEncoder, StandardScaler
from sklearn.linear_model import LogisticRegression

numeric = ["age", "income"]
categorical = ["country", "device_type"]

preprocess = ColumnTransformer([
    ("num", Pipeline([
        ("imputer", SimpleImputer(strategy="median")),
        ("scaler", StandardScaler()),
    ]), numeric),
    ("cat", Pipeline([
        ("imputer", SimpleImputer(strategy="most_frequent")),
        ("onehot", OneHotEncoder(handle_unknown="ignore")),
    ]), categorical)
])

model = Pipeline([
    ("prep", preprocess),
    ("clf", LogisticRegression(max_iter=1000))
])

Isso evita, por construção, muitos erros de “ajustar no conjunto completo”.

4) Torne agregações corretas ponto no tempo

Ao construir agregados históricos:

  • imponha um corte estrito: apenas eventos com timestamp ≤ momento da predição
  • evite janelas que se sobreponham à janela de rotulagem
  • cuidado com dados preenchidos retroativamente e eventos que chegam com atraso

Lojas de atributos frequentemente fornecem junções “as of” (as of joins) ou consultas de viagem no tempo (time-travel queries) para suportar isso.

5) Use estratégias fora da dobra para codificações dependentes do rótulo

Se você precisar usar codificações baseadas em (y) (codificação pelo alvo), faça fora da dobra e aplique suavização/priores (smoothing/priors) para categorias raras.

Regra prática:

  • Qualquer transformação que use o rótulo deve ser computada sem acesso ao rótulo da linha atual (ou aos rótulos de validação).

6) Mantenha um conjunto de teste realmente intocado (e considere validação cruzada aninhada)

Para evitar que ajustes iterativos vazem para a avaliação:

  • Use treino/validação para iteração de modelo
  • Reserve um conjunto de teste final usado apenas uma vez

Para conjuntos pequenos ou ajuste intenso, considere validação cruzada aninhada. Veja: Validação Cruzada.

7) Controle o acesso a rótulos e campos pós-desfecho

Em ambientes de produção, vazamento pode ser organizacional:

  • Analistas podem ter acesso a tabelas pós-desfecho que não estão disponíveis em tempo real
  • Pipelines de dados podem incluir campos “futuros” porque eles existem no data warehouse

Mitigações:

  • separar conjuntos de atributos “online” de tabelas analíticas “offline”
  • manter um contrato de disponibilidade de atributos (esquema + latência)
  • implementar checagens automatizadas que bloqueiem atributos com timestamps após o momento da predição

8) Monitore desvio entre treinamento e serving

Mesmo que você tenha prevenido vazamento durante o treinamento, os dados no serving podem diferir:

  • campos ausentes
  • distribuições diferentes
  • atualizações atrasadas
  • lógica de join diferente

Acompanhe:

  • taxa de faltantes (missingness) dos atributos
  • deriva de distribuição (distribution drift)
  • paridade offline-online (offline-online parity)

Veja: Monitoramento de Modelos.

Cenários práticos de vazamento e correções

Cenário A: Prever inadimplência de empréstimo com “atividade de cobrança”

Vazamento: atributos como num_collection_calls registrados após o início da inadimplência.
Correção: congelar atributos na originação do empréstimo (ou no momento de predição escolhido). Remover atributos pós-originação, a menos que o produto explicitamente preveja mais tarde usando esses sinais.

Cenário B: Detecção de fraude com campos de “chargeback”

Vazamento: o chargeback ocorre após a fraude ser reportada, então campos ligados a ele revelam o rótulo.
Correção: garantir que os atributos venham apenas de sinais no momento da transação; tratar chargeback apenas como rótulo, não como atributo.

Cenário C: Evasão de clientes com “oferta de retenção enviada”

Vazamento: ofertas de retenção são disparadas porque se suspeita de risco de evasão; usá-las pode codificar decisões internas de negócio correlacionadas com evasão.
Correção: ou excluir tais atributos, ou tratá-los com cuidado usando um enquadramento causal (eles são intervenções). Isso se sobrepõe a conceitos de Inferência Causal.

Um checklist para engenharia de atributos segura contra vazamento

  • Temos um timestamp e um horizonte de predição claramente definidos?
  • As divisões são sensíveis ao tempo e/ou à entidade conforme necessário?
  • As etapas de pré-processamento são ajustadas apenas nas dobras de treinamento via pipelines?
  • Os agregados são computados “as of” o momento da predição?
  • Codificações dependentes do rótulo são computadas fora da dobra?
  • Duplicatas ou quase duplicatas são removidas entre divisões?
  • O conjunto de teste final fica intocado até o fim?
  • As definições de atributos correspondem à disponibilidade e latência no serving?

Resumo

Vazamento é uma das razões mais comuns para projetos de ML falharem após resultados offline promissores. Ele normalmente surge de etapas de engenharia de atributos que incluem acidentalmente informações derivadas do rótulo, dados futuros ou informações do conjunto de teste. As defesas mais confiáveis são:

  • definir com precisão o momento de predição e a disponibilidade de dados
  • usar estratégias de divisão que espelhem a implantação (sensíveis ao tempo/ao grupo)
  • encapsular pré-processamento/seleção em pipelines e dobras
  • impor correção ponto no tempo para joins e agregações
  • manter um protocolo de avaliação rigoroso com um conjunto de teste intocado

Trate a prevenção de vazamento como parte do projeto do sistema, não apenas como um detalhe de modelagem — porque o objetivo real não é maximizar métricas offline, e sim construir modelos que funcionem sob restrições operacionais reais.