Detecção Fora da Distribuição

Visão geral

Detecção fora da distribuição (Out-of-Distribution, OOD) é o problema de identificar, em tempo de inferência, se uma entrada (x) está fora da distribuição na qual o modelo foi treinado (a dentro da distribuição, ou ID). Quando um modelo encontra entradas OOD, suas previsões podem se tornar não confiáveis — muitas vezes com alta confiança, mas saídas erradas — o que cria problemas sérios para segurança, robustez e confiabilidade operacional.

A detecção OOD se insere no tema mais amplo de mudança de distribuição (distribution shift), mas foca especificamente em detectar quando uma mudança está acontecendo, em vez de se adaptar a ela. Para contexto sobre tipos de mudança (mudança de covariáveis, mudança de rótulos etc.), veja Mudança de Distribuição. Para métodos que adaptam modelos a novos domínios, veja Adaptação de Domínio.

Motivações típicas no mundo real:

  • Imagem médica: um classificador treinado nos scanners de um hospital encontra um novo protocolo de scanner; diagnósticos errados com alta confiança são inaceitáveis.
  • Direção autônoma: um modelo de percepção treinado em condições ensolaradas encontra neve ou objetos incomuns (por exemplo, um caminhão tombado).
  • Moderação de conteúdo: um modelo encontra novas gírias, novos formatos de meme ou idiomas que não são o alvo.
  • Detecção de fraude: adversários criam deliberadamente padrões novos que diferem dos dados históricos.

A detecção OOD frequentemente é combinada com abstenção (abstention) (“não sei”), revisão com humano no loop (human-in-the-loop) ou sistemas de fallback para mitigar risco.

O que “OOD” significa (e por que é sutil)

Seja (p_{\text{train}}(x, y)) a distribuição conjunta usada durante o treinamento. Em produção, as entradas podem vir de uma distribuição diferente (p_{\text{deploy}}(x, y)). Uma entrada (x) é OOD se for improvável sob a distribuição de entradas de treinamento (p_{\text{train}}(x)), ou se pertencer a um universo semântico de classes diferente do treinamento.

Distinções comuns:

  • Quase-OOD vs OOD distante
    • Quase-OOD: mudança pequena, mas significativa (nova câmera, iluminação, demografia).
    • OOD distante: domínio completamente diferente (dígitos vs imagens naturais).
  • Reconhecimento de conjunto aberto (open-set recognition) / “classes desconhecidas”
    • Entradas são visualmente semelhantes, mas pertencem a classes que não existem nos rótulos de treinamento (por exemplo, um classificador treinado em raças de cães vê uma raposa).
  • Detecção de anomalias (anomaly detection)
    • Frequentemente não supervisionada; OOD é “raro/anormal” em relação aos dados normais. Relacionado, mas não idêntico; veja Detecção de Anomalias.

Um desafio central: em geral, você não conhece a distribuição OOD antecipadamente. Não dá para simplesmente treinar um classificador binário com “todos os OOD possíveis”.

A formulação padrão de detecção OOD

A maioria dos detectores OOD computa um escore escalar (s(x)) a partir do modelo e o compara com um limiar (\tau):

  • Predizer ID se (s(x) \ge \tau)
  • Predizer OOD se (s(x) < \tau) (ou o inverso, dependendo da convenção)

A utilidade do detector depende de:

  1. Quão bem o escore separa ID de OOD.
  2. Como os limiares são definidos e mantidos em produção.
  3. O que o sistema faz ao detectar OOD (abster-se, encaminhar para humano etc.).

A detecção OOD é comumente adicionada por cima de um classificador já treinado, mas também pode ser incorporada ao treinamento.

Por que a detecção OOD importa para confiabilidade e segurança

Modelos modernos — especialmente redes profundas — podem ficar excessivamente confiantes sob mudança. Um classificador softmax pode produzir 0,999 de confiança para uma entrada completamente desconhecida porque o softmax normaliza escores mesmo quando nenhuma das classes se encaixa.

Em contextos críticos de segurança, você quer:

  • Comportamento à prova de falhas: detectar condições desconhecidas e evitar ações inseguras.
  • Incerteza confiável: confiança deve se correlacionar com acerto.
  • Monitoramento operacional: detectar quando pipelines de dados derivam (drift) ou quebram.

A detecção OOD não corrige o entendimento do modelo; ela fornece um guardrail: “esta entrada parece estar fora do que treinamos”.

Abordagens comuns

1) Métodos baseados em incerteza e escore (logits/features)

Esses métodos derivam um escore a partir das saídas de um classificador ou de suas representações internas. São populares porque são baratos (não exigem um modelo gerativo adicional) e fáceis de colocar em produção.

Probabilidade Máxima do Softmax (Maximum Softmax Probability, MSP)

Para um classificador de (K) classes que produz probabilidades (p(y=k\mid x)), defina:

[ s_{\text{MSP}}(x) = \max_k p(y=k \mid x) ]

Uma probabilidade máxima baixa sugere incerteza e possível OOD.

Prós

  • Simples e rápido.
  • Funciona razoavelmente para OOD distante.

Contras

  • Muitas vezes falha para quase-OOD; redes modernas podem errar com alta confiança.

Escalonamento de temperatura e perturbações no estilo ODIN

ODIN melhora a separação ao:

  • Aplicar escalonamento de temperatura (temperature scaling) para suavizar ou tornar mais “pontudas” as probabilidades.
  • Adicionar uma pequena perturbação de entrada (input perturbation), semelhante a adversarial, para amplificar diferenças entre ID e OOD.

Isso pode melhorar o desempenho, mas introduz hiperparâmetros e pode ser frágil entre domínios. (O escalonamento de temperatura também é usado para calibração; veja Calibração.)

Escores baseados em energia

Uma alternativa cada vez mais comum usa a energia dos logits (f(x)\in \mathbb{R}^K):

[ E(x) = -T \cdot \log \sum_{k=1}^K \exp\left(\frac{f_k(x)}{T}\right) ]

Energia mais baixa frequentemente corresponde a “mais dentro da distribuição”. Escores de energia podem ser mais estáveis do que MSP e funcionam bem com regularizadores no treinamento.

Trecho prático em PyTorch (escore de energia + limiarização)

import torch

@torch.no_grad()
def energy_score(logits, T=1.0):
    # logits: [batch, K]
    return -T * torch.logsumexp(logits / T, dim=1)

def ood_flag_from_logits(logits, tau, T=1.0):
    # Example convention: ID if energy <= tau (since energy is often lower for ID)
    E = energy_score(logits, T=T)
    is_ood = E > tau
    return is_ood, E

Na prática, você ajusta (\tau) em um conjunto de validação (detalhes na seção de implantação).

Distância de Mahalanobis no espaço de características

Compute estatísticas condicionais por classe a partir de uma representação (h(x)) em uma camada escondida:

  • Média (\mu_k) para cada classe
  • Covariância compartilhada (\Sigma)

Pontue pela (negativa) distância à classe mais próxima:

[ d(x) = \min_k (h(x)-\mu_k)^\top \Sigma^{-1} (h(x)-\mu_k) ]

Distância grande sugere OOD.

Prós

  • Eficaz para modelos de visão com boas características.
  • Intuitivo e frequentemente forte para quase-OOD (com bons embeddings).

Contras

  • Exige armazenar/estimar a covariância; pode ser sensível à escolha da camada.
  • Menos direto para modelos em larga escala ou de sequência sem um design cuidadoso.

Melhorias no treinamento: exposição a outliers e perdas de margem

Se você tiver dados auxiliares de “background” que não estejam nas suas classes-alvo, pode treinar o modelo para atribuir baixa confiança a esses exemplos. Isso é frequentemente chamado de exposição a outliers (outlier exposure, OE).

Estratégias comuns:

  • Incentivar softmax uniforme em amostras OE.
  • Penalizar energia baixa em amostras OE (OE baseada em energia).
  • Adicionar classe “desconhecido” (funciona em alguns cenários, mas pode superajustar a tipos OOD conhecidos).

Ressalva principal: OE melhora a robustez sobretudo para OOD semelhante ao que você expõe durante o treinamento; não resolve o problema de “desconhecidos desconhecidos”.

2) Estimação de densidade e modelagem gerativa

Uma ideia natural: aprender (p_{\text{train}}(x)) e sinalizar entradas com baixa verossimilhança.

Modelos usados:

A “armadilha da verossimilhança” / problema de tipicidade

Um problema bem conhecido: modelos baseados em verossimilhança podem atribuir maior verossimilhança a dados OOD do que a dados ID por causa de estatísticas de fundo (por exemplo, alguns fluxos atribuem maior verossimilhança a dígitos do SVHN do que a imagens do CIFAR).

Isso acontece porque:

  • Verossimilhança captura estatísticas em nível de pixel, não necessariamente semântica.
  • Alta verossimilhança não garante que a amostra seja típica sob a distribuição.

Mitigações incluem:

  • Razões de verossimilhança (comparar com um modelo de fundo)
  • Testes de tipicidade (usar estatísticas do log-verossimilhança sob ID)
  • Combinar escores de densidade com escores baseados em características ou baseados em classificador

Onde modelos de densidade brilham

  • Quando “OOD” realmente significa “estatisticamente raro sob (p(x))” (detecção de anomalias industriais, falhas de sensores).
  • Quando você consegue modelar bem a distribuição de entrada e a semântica se alinha com a verossimilhança.

3) Ensembles e métodos Bayesianos aproximados

Uma razão central para falhas sob OOD é a incerteza epistêmica (epistemic uncertainty): incerteza por falta de conhecimento fora do suporte de treinamento. Ensembles aproximam isso treinando múltiplos preditores e medindo discordância.

Ensembles profundos (deep ensembles)

Treine (M) modelos com diferentes sementes aleatórias (e, às vezes, dados com bootstrap). Calcule:

  • Média preditiva: (\bar{p}(y\mid x) = \frac{1}{M}\sum_m p_m(y\mid x))
  • Entropia preditiva: entropia alta sugere incerteza.
  • Informação mútua (proxy epistêmico): discordância entre modelos.

Prós

  • Baseline forte e confiável.
  • Frequentemente melhora tanto a acurácia quanto a detecção OOD.

Contras

  • (M\times) computação/memória na inferência (pode ser mitigado via destilação ou ensembles pequenos).

Aproximações relacionadas:

Nota prática: Ensembles estão entre os métodos mais consistentemente eficazes em implantações reais porque são robustos e conceitualmente simples, apesar do custo extra de computação.

4) Predição conformal e abstenção (predição seletiva)

Em vez de tentar rotular OOD explicitamente, muitos sistemas se concentram em saber quando não responder.

Classificação seletiva (abstenção)

Você define um escore de confiança (MSP, energia, entropia do ensemble etc.) e se abstém quando a confiança é baixa. Isso fornece um trade-off controlável entre:

  • Cobertura: fração das entradas que você responde
  • Risco: taxa de erro no subconjunto respondido

Essa costuma ser a forma mais relevante para produto: “Responda apenas quando estiver confiante; caso contrário, escale.”

Predição conformal (garantias sensíveis à distribuição)

Predição Conformal fornece um arcabouço para produzir conjuntos de predição com uma garantia formal de cobertura, tipicamente:

[ \Pr(y \in \Gamma(x)) \ge 1-\alpha ]

sob uma suposição de intercambiabilidade (em termos gerais: dados de calibração e dados de teste são amostrados de forma semelhante).

Para OOD, métodos conformais ajudam você a:

  • Controlar erro/cobertura em dados semelhantes aos de calibração.
  • Detectar problemas quando a cobertura degrada ou os conjuntos de predição ficam grandes.

Limitação importante: garantias conformais padrão podem falhar sob mudanças severas de distribuição — exatamente quando OOD ocorre. Ainda assim, ferramentas conformais são valiosas para políticas de abstenção e para monitorar degradação.

Avaliação: como a detecção OOD é medida

A detecção OOD é um problema de decisão binária (ID vs OOD), mas a avaliação é difícil porque:

  • Há muitos tipos de OOD.
  • Os custos são assimétricos (falsos negativos podem ser perigosos).
  • Você também se importa com o desempenho da tarefa em dados ID.

Métricas comuns

  • AUROC: probabilidade de uma amostra ID aleatória ter um “escore de ID” maior do que uma amostra OOD aleatória.
    • Boa para separabilidade geral.
    • Pode ser otimista demais se OOD for muito diferente (OOD distante).
  • AUPR (ID como positivo ou OOD como positivo):
    • Útil quando o desbalanceamento importa ou quando você se preocupa com precisão em baixas taxas de falsos positivos.
  • FPR@95%TPR (ou similar):
    • “Que taxa de falsos positivos incorremos ao capturar 95% de ID?” (ou o inverso, dependendo da convenção)
    • Popular em artigos de OOD; destaca desempenho no regime de baixo FPR.
  • Erro de detecção:
    • Menor taxa possível de misclassificação ao variar o limiar, dadas priors assumidas.
  • Curvas cobertura vs risco (para abstenção):
    • Plota erro nos exemplos respondidos vs fração respondida.
  • Métricas de calibração (complementares):
    • ECE (erro esperado de calibração), diagramas de confiabilidade. Veja Calibração.

Protocolos de avaliação e armadilhas

  • Use múltiplos conjuntos de dados OOD: um detector pode superajustar a um benchmark.
  • Separe quase-OOD e OOD distante: OOD distante pode ser “fácil demais”, mascarando falhas.
  • Controle artefatos de pré-processamento: redimensionamento, compressão ou padding diferentes podem vazar sinais.
  • Reporte acurácia ID junto com desempenho OOD: alguns métodos melhoram OOD piorando a classificação ID.
  • Considere ID corrompido vs OOD verdadeiro: imagens corrompidas (desfoque/ruído) não são necessariamente OOD; são um teste de estresse diferente.

Em muitas aplicações, a avaliação mais significativa é: “Em um limiar que produz X% de alarmes falsos no tráfego limpo de validação, que fração de entradas realmente problemáticas capturamos?”

Considerações de implantação

Detecção OOD em produção tem menos a ver com um único escore de benchmark e mais com limiarização, monitoramento e resposta operacional.

Escolha de limiares

Quase sempre você implanta uma regra como: “abster-se se (s(x) < \tau).” Como escolher (\tau)?

Abordagens comuns:

  • Quantil em dados ID de validação: definir (\tau) para que apenas (por exemplo) 1% do tráfego ID de validação seja rejeitado.
  • Otimizar uma função de custo: escolher (\tau) para minimizar o custo esperado de falsos aceites vs falsas rejeições.
  • Ajustar para um FPR alvo: escolher (\tau) para que alarmes falsos sejam manejáveis para revisão humana.

Exemplo prático (limiar por quantil)

  • Colete um conjunto de validação ID separado.
  • Calcule escores (s(x)).
  • Defina (\tau = \text{quantile}(s, 0.01)) se você quer 1% de rejeição em ID.

Em seguida, acompanhe se as taxas de rejeição disparam em produção (um sinal de drift).

O que fazer quando OOD é detectado

Detecção só é útil se o sistema responder com segurança:

  • Abstenção + fallback: não classificar; usar regras, um modelo menor e seguro, ou recuperação (retrieval).
  • Encaminhar para humano: para decisões de alto impacto (saúde, finanças).
  • Pedir mais informações: solicitar uma imagem mais clara, campos adicionais ou checagens de sensor.
  • Registrar e colocar em quarentena: armazenar exemplos para análise e retreinamento futuro.

Monitoramento e alertas

Escores OOD são sinais operacionais. Em produção, monitore:

  • Deriva na distribuição de escores: mudanças em média/quantis de (s(x)).
  • Taxa de rejeição: fração sinalizada como OOD (global e por segmento).
  • Resultados a jusante: taxas de erro, reclamações, relatórios de incidentes no tráfego aceito.

Você pode combinar escores OOD com detectores de drift (por exemplo, testes de duas amostras) e checagens de qualidade de dados. Para estratégias mais amplas de monitoramento, veja Monitoramento de Modelos (se disponível no seu wiki).

Lidar com loops de feedback e retreinamento

Se você rejeitar muitas amostras e rotular apenas um subconjunto, pode criar viés de seleção. Planeje:

  • Amostrar itens rejeitados para rotulagem.
  • Retreinamento ou fine-tuning periódico com domínios recém-observados.
  • Manter um “conjunto de calibração” estável para limiares (ou recalibrar limiares deliberadamente com gestão de mudanças).

Considerações de segurança

Detecção OOD não é uma defesa completa contra adversários:

  • Exemplos adversariais (adversarial examples) podem ser criados para parecer ID de acordo com seu detector enquanto causam misclassificação; veja Exemplos Adversariais.
  • Atacantes podem aprender o comportamento do seu limiar e se adaptar.

Em ambientes de alto risco, combine detecção OOD com medidas de robustez adversarial, validação de entrada e limitação de taxa (rate limiting).

Exemplos práticos

Exemplo 1: Classificador de imagens com abstenção

Um modelo de câmera de vida selvagem classifica “cervo / javali / raposa”. Em produção, ele vê:

  • humanos (classe inesperada)
  • artefatos de visão noturna
  • desfoque extremo por movimento

Uma configuração pragmática:

  1. Use um ensemble ou escore de energia como (s(x)).
  2. Se incerto / alta energia → abster-se.
  3. Amostras com abstenção entram em uma fila para:
    • rotulagem humana (se o orçamento permitir),
    • ou categorização como “desconhecido”,
    • e depois são usadas para retreinamento no estilo OE.

Isso reduz previsões falsas e confiantes, como chamar um humano de “cervo” com 99,9%.

Exemplo 2: Classificação de texto sob mudança de domínio

Um classificador de tickets de suporte treinado no produto A é implantado no produto B. Muitas frases são novas (“OAuth device code”, “SAML assertion”), e a taxonomia de rótulos pode não coincidir totalmente.

A detecção OOD pode:

  • sinalizar mensagens de baixa confiança ou alta incerteza,
  • encaminhá-las para um modelo geral ou triagem humana,
  • e acionar um pipeline de coleta de dados para adaptação de domínio depois.

OOD em texto pode ser especialmente difícil porque similaridade superficial pode mascarar novidade semântica; abordagens com ensembles e conformal/abstenção costumam ser mais confiáveis do que escores brutos de softmax.

Resumo de trade-offs entre métodos

  • MSP / escores de logit: mais simples; pode ser fraco para quase-OOD.
  • Energia / ODIN / Mahalanobis: baselines práticos fortes; ainda exigem ajuste e avaliação cuidadosos.
  • Estimação de densidade: atraente em princípio; pode falhar por questões de verossimilhança/tipicidade; melhor quando “raro = ruim” se alinha com a semântica.
  • Ensembles: consistentemente fortes, mas mais caros; frequentemente valem a pena em produção.
  • Conformal / abstenção: foca em controlar risco em vez de rotular OOD perfeitamente; muito útil para pipelines de decisão.

Fluxo de trabalho baseline recomendado (ponto de partida prático)

  1. Comece com um classificador forte e calibre-o (escalonamento de temperatura é um primeiro passo comum).
  2. Implemente escore de energia ou incerteza de ensemble como seu sinal OOD.
  3. Escolha um limiar de abstenção com base em uma taxa aceitável de rejeição em ID (por exemplo, 0,5–2%).
  4. Avalie em:
    • ID limpo,
    • ID corrompido,
    • múltiplos conjuntos quase-OOD e OOD distante.
  5. Faça o deploy com:
    • logging de escores e abstenções,
    • alertas sobre mudanças na taxa de rejeição,
    • um processo para revisar e rotular amostras com abstenção.

A detecção OOD é melhor vista não como um único algoritmo, mas como uma capacidade de sistema: pontuação + limiarização + monitoramento + comportamento seguro de fallback.