Inferência de Participação

O que é inferência de pertencimento?

Inferência de pertencimento refere-se a uma classe de ataques de privacidade que tentam determinar se um determinado registro de dados (por exemplo, uma consulta médica de uma pessoa, uma imagem específica ou um trecho de texto) foi incluído no conjunto de dados de treinamento de um modelo.

De forma informal:

Dado um modelo treinado e um exemplo-alvo (x), o atacante produz um palpite: “no conjunto de treinamento” vs “fora do conjunto de treinamento.”

A inferência de pertencimento é um tema central em segurança de aprendizado de máquina (machine learning) porque pode revelar fatos sensíveis mesmo quando o atacante nunca vê diretamente os dados de treinamento. Ela é intimamente relacionada (mas distinta de) Extração de Dados de Treinamento e Inversão de Modelo, e frequentemente surge em implantações do mundo real como APIs de predição, sistemas de recomendação e aplicações de LLMs (large language models).

Por que o pertencimento importa (impacto na privacidade)

Saber que um registro estava nos dados de treinamento pode ser sensível por si só. Exemplos:

• Modelos médicos: Se um hospital treina um modelo com registros de oncologia, inferir que o registro de uma pessoa foi incluído pode implicar que ela recebeu atendimento relacionado a câncer.
• Modelos de localização / mobilidade: O pertencimento pode implicar que alguém visitou um lugar específico em um horário específico.
• Ajuste fino e texto em LLMs: O pertencimento pode indicar que um usuário escreveu uma mensagem específica que acabou em um corpus de ajuste fino (por exemplo, chats de suporte, reclamações de RH, minutas jurídicas).
• Reconhecimento facial / biometria: O pertencimento pode indicar que uma pessoa aparece em um conjunto de treinamento coletado a partir de um evento ou fonte específicos.

A inferência de pertencimento também é uma forma prática de auditar se certos conjuntos de dados foram usados no treinamento (por exemplo, dados protegidos por direitos autorais, violações de opt-out), embora auditorias normalmente exijam metodologia cuidadosa para evitar conclusões falsas.

Modelo de ameaça: o que o atacante obtém?

Ataques de inferência de pertencimento variam conforme o acesso do atacante:

Acesso de caixa-preta

O atacante pode consultar o modelo e ver alguma forma de saída:

• Apenas o rótulo top-1 (por exemplo, “spam” vs “não spam”)
• Pontuações de confiança / probabilidades (comum em APIs mais antigas)
• Logits (menos comum, mas às vezes exposto em sistemas internos)
• Valores de perda (raramente expostos diretamente, mas podem ser derivados em algumas configurações)
• Múltiplas consultas / consultas adaptativas (o atacante pode criar consultas com base em saídas anteriores)

Muitos ataques clássicos assumem que o modelo produz um vetor de probabilidades. Restringir as saídas é uma mitigação comum, mas não é uma solução completa (mais sobre isso adiante).

Acesso de caixa-branca (ou “caixa-cinza”)

O atacante pode inspecionar internamente elementos como:

• Pesos do modelo (por exemplo, checkpoint roubado)
• Gradientes, perdas por exemplo, ou estado do otimizador (risco comum em Aprendizado Federado e treinamento colaborativo)
• Ativações intermediárias

O acesso de caixa-branca normalmente torna a inferência de pertencimento mais fácil e mais forte.

Conhecimento auxiliar

Atacantes frequentemente se beneficiam de informações laterais:

• Conhecimento da distribuição dos dados (por exemplo, “pacientes desta clínica em 2023”)
• Um “conjunto de dados sombra” de uma distribuição similar
• Conhecimento da arquitetura do modelo ou do procedimento de treinamento

Intuição central: por que a inferência de pertencimento funciona

A inferência de pertencimento está fortemente ligada a sobreajuste (overfitting) e memorização (memorization).

Um modelo treinado para minimizar a perda empírica normalmente ajusta melhor os pontos de treinamento do que pontos não vistos. Se um modelo se comporta de forma perceptivelmente diferente em um registro que viu durante o treinamento, um atacante pode explorar essa diferença.

Uma heurística simples ilustra a ideia:

• Calcular a confiança do modelo (ou a perda) em (x).
• Se o modelo estiver muito confiante (ou a perda estiver muito baixa), chutar “membro”.

Isso nem sempre está correto — modelos que generalizam bem podem ser confiantes também em não-membros —, mas na prática frequentemente funciona surpreendentemente bem, especialmente para modelos de alta capacidade treinados sem proteções fortes de privacidade.

Uma lente teórica: lacuna de generalização e vantagem do ataque

Uma formalização (comum na literatura) conecta inferência de pertencimento à diferença entre desempenho em treino e teste.

Seja (\ell(\theta, x)) a perda do modelo (\theta) no exemplo (x). Se a perda esperada em exemplos de treinamento for significativamente menor do que em não-membros, então a inferência de pertencimento pode ter sucesso. Um ataque simples por limiar é:

[ \text{prever membro se } \ell(\theta, x) \le t ]

O melhor limiar (t) depende das distribuições e do conhecimento do atacante.

O sucesso do ataque frequentemente é resumido por:

• AUC (Área Sob a Curva ROC)
• Acurácia para um teste balanceado entre membro/não-membro
• Vantagem, aproximadamente:
  [ \text{Adv} = \Pr[\text{correto}] - \tfrac{1}{2} ] onde (1/2) é o chute aleatório para uma priori balanceada.

Modelos com uma lacuna de generalização (treino vs teste) maior tendem a vazar mais informação de pertencimento, mas vazamento ainda pode acontecer mesmo quando a acurácia padrão no teste parece boa — especialmente para outliers, subpopulações raras ou registros duplicados.

Famílias comuns de ataques

1) Ataques por limiar de confiança / perda (simples, mas eficazes)

Se o atacante consegue obter probabilidades (ou estimar a perda), ele pode usar:

• Probabilidade máxima (também conhecida como “confiança”): (\max_k p_\theta(y=k\mid x))
• Entropia da distribuição prevista
• Perda por exemplo (por exemplo, entropia cruzada se o rótulo verdadeiro for conhecido)

Intuição: pontos de treinamento frequentemente produzem maior confiança e menor perda.

Isso funciona mesmo sem treinar modelos adicionais e é um bom baseline para defensores medirem.

2) Ataques com modelos sombra (abordagem clássica de caixa-preta)

Introduzida em trabalhos iniciais sobre inferência de pertencimento, a ideia é:

1. O atacante treina vários modelos sombra para imitar o comportamento do modelo-alvo.
2. Ele coleta saídas dos modelos sombra em exemplos que são membros/não-membros conhecidos dos conjuntos de treinamento sombra.
3. Ele treina um classificador de ataque que mapeia saídas do modelo (probabilidades/logits) para uma predição de pertencimento.
4. Ele aplica esse classificador às saídas do modelo-alvo.

Modelos sombra aproximam como o modelo-alvo se comporta em membros vs não-membros.

3) Ataques apenas com rótulo

Se a API retorna apenas a classe predita, atacantes ainda podem inferir pertencimento explorando:

• Estimativas de distância à fronteira de decisão usando estratégias de consulta
• Propriedades de robustez / margem (quão facilmente a predição muda sob perturbações)
• Consultas repetidas com pequenas modificações na entrada

Ataques apenas com rótulo tipicamente são mais fracos do que ataques baseados em probabilidades, mas ainda podem ser práticos contra endpoints expostos.

4) Ataques de caixa-branca usando gradientes ou ativações

Com acesso interno, atacantes podem usar características como:

• Perda de treinamento por exemplo
• Normas ou direções de gradiente
• Padrões de ativação

Em cenários colaborativos, os próprios gradientes podem vazar pertencimento, o que é uma das motivações para técnicas de treinamento com preservação de privacidade.

5) Inferência de pertencimento para LLMs (baseada em perplexidade e além)

Para modelos de linguagem, atacantes frequentemente usam perplexidade (negative log-likelihood) de uma sequência:

• Se um LLM atribui probabilidade anormalmente alta a um trecho de texto específico, isso pode indicar que o texto (ou algo muito próximo) apareceu no treinamento.
• Modelos ajustados finamente com corpus pequeno ou sensível estão especialmente em risco.

Isso se relaciona com Extração de Dados de Treinamento: inferência de pertencimento responde “estava no treinamento?” enquanto extração visa recuperar o conteúdo. Na prática, os dois podem se reforçar mutuamente.

Exemplo prático: uma inferência de pertencimento simples com modelo sombra (toy)

Abaixo está um exemplo educacional simplificado usando scikit-learn. Ataques reais exigem correspondência cuidadosa de conjuntos de dados e avaliação, mas isto ilustra o fluxo de trabalho.

import numpy as np
from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score
from sklearn.ensemble import RandomForestClassifier

# 1) "Target" model trained on private data
X, y = make_classification(n_samples=5000, n_features=20, random_state=0)
X_target_train, X_target_test, y_target_train, y_target_test = train_test_split(
    X, y, test_size=0.5, random_state=1
)

target = LogisticRegression(max_iter=2000).fit(X_target_train, y_target_train)

# Attacker can query the target model for probabilities
def query_model_proba(model, X):
    return model.predict_proba(X)  # shape: [n, num_classes]

# Build an attack dataset: model outputs + membership label
# Members: samples from target training set
# Non-members: samples from target test set
P_mem = query_model_proba(target, X_target_train)
P_non = query_model_proba(target, X_target_test)

X_attack = np.vstack([P_mem, P_non])
y_attack = np.hstack([np.ones(len(P_mem)), np.zeros(len(P_non))])

# Train an attack model (here: random forest on probability vectors)
X_a_train, X_a_test, y_a_train, y_a_test = train_test_split(
    X_attack, y_attack, test_size=0.3, random_state=0, stratify=y_attack
)

attack = RandomForestClassifier(n_estimators=200, random_state=0).fit(X_a_train, y_a_train)
score = attack.predict_proba(X_a_test)[:, 1]
print("Attack AUC:", roc_auc_score(y_a_test, score))

Notas:

• Isto está mais próximo de um ataque direto do que de uma configuração completa de modelos sombra porque usa diretamente as divisões de treino/teste do alvo. Em cenários realistas, o atacante não tem exemplos rotulados de membro/não-membro do alvo; ele os aproxima com modelos sombra treinados em dados similares.
• Mesmo esta abordagem simplista frequentemente alcança AUC > 0.5 quando o modelo-alvo tem sobreajuste.

Onde a inferência de pertencimento aparece na prática

APIs de ML como serviço

Se uma API retorna vetores de probabilidade, a inferência de pertencimento muitas vezes pode ser tentada em escala. Mesmo que a API tenha limitação de taxa, atacantes podem focar em alvos de alto valor.

Isso se relaciona com riscos mais amplos em Extração / Roubo de Modelo: extração copia o comportamento, enquanto inferência de pertencimento revela inclusão no treinamento — ambas exploram acesso via consultas.

Ajuste fino em dados empresariais sensíveis

Organizações frequentemente fazem ajuste fino em modelos (incluindo LLMs) com:

• tickets de suporte,
• documentos internos,
• transcrições de chat,
• repositórios de código.

Se o conjunto de ajuste fino for pequeno ou contiver strings únicas, sinais de pertencimento podem ficar mais fortes. Atacantes podem testar se um e-mail, frase ou trecho de documento específico foi usado.

Aprendizado federado e treinamento colaborativo

Participantes podem inferir se certos registros foram usados por outro participante (ou se um evento raro ocorreu) por meio de atualizações compartilhadas. Isso se sobrepõe a vazamento por gradientes e motiva proteções mais fortes em treinamento distribuído.

Avaliando o risco de pertencimento (para defensores)

Inferência de pertencimento não é “um número”; depende das suposições sobre o atacante. Uma boa avaliação tipicamente inclui:

1. Definir a visão do atacante

   • Tipo de saída: apenas rótulo vs probabilidades vs logits
   • Orçamento de consultas
   • Conhecimento dos rótulos
   • Se o atacante conhece a distribuição dos dados

2. Usar um conjunto realista de não-membros

   • Não-membros devem vir da mesma (ou de uma) distribuição plausível.
   • Cuidado com divisões temporais, duplicatas ou artefatos do pipeline de dados.

3. Medir múltiplas métricas

   • ROC-AUC, TPR em FPR baixa (importante para atacantes que precisam de alta confiança)
   • Acurácia sob uma priori fixa (a taxa base de pertencimento importa em implantações reais)

4. Análise por recortes (slices)

   • O risco de pertencimento pode ser muito maior para:
     • classes raras,
     • outliers,
     • registros duplicados,
     • subpopulações sub-representadas.

5. “Canários” e auditorias de privacidade (opcional)

   • Inserir exemplos sintéticos únicos (canários) durante o treinamento e testar se ataques os detectam.
   • Isso ajuda a acompanhar memorização, mas deve ser interpretado com cuidado.

Para avaliação em nível de sistema e pensamento adversarial, combine isso com Modelagem de Ameaças para Apps de LLM e exercícios estruturados como Red Teaming.

Defesas e mitigações

Nenhuma mitigação única resolve completamente a inferência de pertencimento sem custos. Na prática, as defesas são em camadas.

1) Reduzir sobreajuste (ajuda, mas não é suficiente)

Como a inferência de pertencimento frequentemente explora sobreajuste:

• Use Regularização mais forte (weight decay, dropout)
• Parada antecipada (early stopping)
• Aumento de dados (data augmentation) (por exemplo, Mixup, RandAugment)
• Ensemble (pode suavizar sinais de confiança)
• Garanta separação limpa entre treino e teste; remova duplicatas

Esses passos normalmente reduzem vazamento, mas não fornecem uma garantia formal de privacidade. Algum vazamento pode permanecer mesmo com boa acurácia no teste.

2) Limitar ou higienizar saídas (endurecimento prático de APIs)

Se você expõe um modelo via API:

• Retorne rótulos top-k em vez de vetores completos de probabilidade
• Evite retornar probabilidades calibradas a menos que seja necessário
• Adicione ruído na predição (cuidado: pode prejudicar utilidade e pode ser “médio” com consultas repetidas)
• Use limitação de taxa (rate limits), detecção de anomalias e autenticação
• Considere arredondamento de resposta (precisão limitada), embora atacantes determinados possam se adaptar

Restrição de saída frequentemente reduz a força do ataque, mas não é uma solução de privacidade com base em princípios — especialmente contra ataques apenas com rótulo ou cenários de caixa-branca.

3) Calibrar e suavizar confiança (mitigação parcial)

Ataques de pertencimento frequentemente usam confiança como sinal, então técnicas como:

• temperature scaling,
• label smoothing,
• penalidades de confiança,

podem reduzir vazamento em alguns casos. Contudo, calibração não é um mecanismo de privacidade; ela às vezes pode aumentar a confiança em não-membros ou deslocar sinais de formas inesperadas. Trate como uma medida de defesa em profundidade, não como uma garantia. (Relacionado: Calibração de Modelos.)

4) Privacidade diferencial (garantia padrão mais forte)

Privacidade Diferencial é a principal abordagem formal para limitar inferência de pertencimento.

Um algoritmo de treinamento é ((\varepsilon, \delta))-diferencialmente privado se a distribuição de saída do modelo muda apenas levemente quando qualquer registro individual de treinamento é adicionado/removido. Isso mira diretamente inferência de pertencimento: se a privacidade diferencial vale com (\varepsilon) pequeno, então nenhum atacante pode inferir pertencimento de forma confiável além do limite da privacidade diferencial.

Em aprendizado profundo, a abordagem mais comum é DP-SGD:

• Fazer clipping de gradientes por exemplo
• Adicionar ruído ao gradiente agregado
• Rastrear perda de privacidade com um contador de privacidade

Trade-offs:

• Privacidade diferencial frequentemente reduz a acurácia do modelo (especialmente com (\varepsilon) pequeno)
• Pode ser computacionalmente mais pesada
• Exige ajuste cuidadoso e contabilização correta

Ainda assim, a privacidade diferencial é amplamente considerada a defesa mais robusta quando são necessárias garantias fortes de privacidade.

5) Governança e minimização de dados (não técnica, mas crítica)

Como a inferência de pertencimento transforma “inclusão no treinamento” em um evento de privacidade, governança importa:

• Evite coletar atributos sensíveis a menos que seja necessário
• Aplique limites de retenção e controles de acesso
• Documente proveniência dos dados de treinamento e consentimento
• Para pipelines de LLM, rastreie o que entra em pré-treinamento vs ajuste fino vs recuperação (retrieval)

Isso complementa mitigações técnicas e apoia requisitos de conformidade.

Relação com tópicos de segurança próximos

A inferência de pertencimento se situa em uma família de ataques de privacidade e segurança:

• Inversão de Modelo: inferir características/atributos sobre um registro (por exemplo, reconstruir uma entrada) em vez de apenas pertencimento.
• Extração de Dados de Treinamento: elicitar texto ou amostras de treinamento memorizadas; inferência de pertencimento pode ser usada como um sinal de que há memorização.
• Extração / Roubo de Modelo: copiar o modelo via consultas; modelos extraídos podem então ser usados offline para executar ataques de pertencimento mais fortes.
• Exemplos Adversariais: principalmente ataques de integridade/robustez, mas alguns ataques de pertencimento apenas com rótulo exploram propriedades de robustez/margem.
• Envenenamento de Dados e Backdoors: ataques de integridade em tempo de treinamento; embora diferentes de inferência de pertencimento, ambos destacam que dados de treinamento são uma fronteira-chave de segurança.

Armadilhas e equívocos comuns

• “Alta acurácia no teste significa que não há vazamento de pertencimento.”
  Falso. Vazamento pode persistir para pontos raros, duplicatas ou outliers mesmo quando métricas agregadas parecem boas.

• “Se não liberarmos probabilidades, estamos seguros.”
  Muitas vezes é falso. Ataques apenas com rótulo existem, e muitos sistemas vazam sinais adicionais (confiança via UI, pontuações parciais, tempo de resposta ou consultas repetidas).

• “Inferência de pertencimento só importa se os registros forem únicos.”
  Unicidade aumenta o risco, mas pertencimento ainda pode ser inferido estatisticamente para pontos não únicos, especialmente em conjuntos de dados pequenos ou modelos muito sobreajustados.

• “Privacidade diferencial elimina todos os riscos de privacidade.”
  Privacidade diferencial limita significativamente inferência de pertencimento com respeito ao conjunto de dados protegido e ao modelo de ameaça, mas não resolve automaticamente todo risco de privacidade (por exemplo, vazamento de fatos sensíveis que são comuns na população, ou riscos fora do escopo da privacidade diferencial).

Checklist de boas práticas

• Durante o desenvolvimento

  • Acompanhe lacunas treino/teste e comportamento por recortes para sobreajuste
  • Execute avaliações de inferência de pertencimento como parte de testes de segurança
  • Evite duplicatas; garanta divisão adequada de dados

• Antes da implantação

  • Minimize informações de saída expostas por APIs
  • Adicione limitação de taxa e monitoramento
  • Considere treinamento com privacidade diferencial quando requisitos de privacidade forem fortes

• Para sistemas de LLM

  • Tenha cautela com conjuntos pequenos e sensíveis de ajuste fino
  • Prefira recuperação (retrieval) + controle de acesso em vez de embutir texto sensível diretamente nos pesos sempre que possível
  • Incorpore testes de privacidade em Red Teaming

Resumo

Ataques de inferência de pertencimento buscam responder a uma pergunta enganosamente simples — este registro estava nos dados de treinamento? —, mas as implicações são sérias: inclusão no treinamento pode revelar fatos pessoais sensíveis, proveniência de conjuntos de dados ou violações de política. Esses ataques exploram diferenças no comportamento do modelo entre pontos de treinamento e pontos fora do treinamento, frequentemente amplificadas por sobreajuste e memorização. As defesas vão desde endurecimento prático de APIs até técnicas formais como Privacidade Diferencial, e implantações no mundo real normalmente exigem mitigações em camadas e modelagem cuidadosa de ameaças.

---