Resumo Técnico: SrDetection

Definição do Problema

A avaliação de Modelos de Linguagem de Código (Code LLMs) está cada vez mais comprometida pelo vazamento de dados (data leakage), onde amostras de benchmarks são inadvertidamente incluídas no corpus de pré-treinamento de um modelo. Quando os modelos memorizam essas amostras, suas métricas de desempenho são artificialmente infladas, refletindo memorização em vez de uma generalização genuína. Isso compromete a imparcialidade das comparações de modelos e complica a avaliação da verdadeira inovação.

Os métodos de detecção existentes sofrem de três limitações primárias:

1. Dependência de Dados Proprietários: Métodos baseados em sobreposição (ex: correspondência de n-gramas) exigem acesso aos corpora de treinamento do modelo, que são tipicamente proprietários e não divulgados.
2. Heurísticas Frágeis: A filtragem baseada em carimbo de tempo (timestamp) assume que o código lançado após o corte de treinamento de um modelo não pode estar no corpus. Isso falha na prática devido ao reuso de código, herança e forking.
3. Instabilidade de Limiar (Threshold): Abordagens baseadas em confiança (ex: Perplexidade) dependem de conjuntos de referência externos para calibrar limiares de decisão. Esses limiares são frequentemente ajustados em dados de linguagem natural e não se generalizam bem para as regularidades estruturais de código, ou dependem das mesmas heurísticas temporais falhas.

Metodologia: SrDetection

Os autores propõem o SrDetection, um framework unificado e autorreferencial para detectar vazamento de dados tanto em configurações de caixa-cinza (acesso aos logits do modelo) quanto de caixa-preta (acesso apenas às saídas do modelo). A hipótese central é que, se um modelo memorizou um código específico, ele exibirá um comportamento significativamente mais previsível (menor perplexidade ou maior similaridade de geração) na forma de superfície original em comparação com variantes semanticamente equivalentes.

O framework opera em duas etapas principais:

1. Módulo de Transformação de Código

Este módulo gera um conjunto de $n$ variantes semanticamente equivalentes ($V = \{x_1, ..., x_n\}$) a partir de uma amostra de benchmark original ($x_0$) usando um LLM auxiliar. As transformações são mínimas e localizadas para preservar o comportamento de execução enquanto alteram as formas léxicas e sintáticas:

• Renomeação de Nome de Função ($\tau_f$): Substitui nomes de funções e locais de chamada por alternativas semanticamente equivalentes (ex: solve $\to$ compute).
• Renomeação de Nome de Variável ($\tau_v$): Substitui sistematicamente identificadores e parâmetros de variáveis (ex: nums $\to$ arr).
• Transformação de Caso de Teste ($\tau_t$): Gera novos inputs de teste semanticamente similares aos originais, valida-os via execução e substitui os casos de teste originais.

2. Módulo de Decisão de Vazamento

O framework compara o comportamento do modelo na amostra original ($x_0$) contra suas variantes ($V$) sem depender de limiares externos.

• Configuração de Caixa-Cinza (Baseado em Perplexidade):
  O escore de detecção $S_M(x)$ é a Perplexidade (PPL) da amostra. Se o modelo memorizou $x_0$, seu PPL será menor do que o de qualquer variante.
  $$\text{Leakage}_{gray}(x_0) = \mathbb{I}[S_M(x_0) < \min_{x_i \in V} S_M(x_i)]$$
  Onde $\mathbb{I}$ é a função indicadora.

• Configuração de Caixa-Preta (Baseado em Similaridade de Geração):
  O escore de detecção $S_M(x)$ é a Sobreposição de N-gramas (NGO) entre o sufixo gerado pelo modelo e o sufixo de referência (ground-truth) quando provocado por um prefixo. Se memorizado, o modelo gera um sufixo mais próximo do ground- truth para a forma original do que para as variantes.
  $$\text{Leakage}_{black}(x_0) = \mathbb{I}[S_M(x_0) > \max_{x_i \in V} S_M(x_i)]$$

Construção de Testbed Controlado

Para avaliar rigorosamente esses métodos, os autores construíram um testbed de vazamento controlado:

1. Preparação de Dataset: Um benchmark de código público foi filtrado para remover amostras que já mostravam sinais de vazamento (onde o original já era o mais fácil entre as variantes).
2. Vazamento Simulado: Os modelos foram submetidos ao pré-treinamento contínuo em um subconjunto dos dados (a divisão de "treinamento") misturado com um corpus web geral, enquanto o restante dos dados serviu como o conjunto de teste "mantido fora" (held-out). Isso cria uma verdade fundamental (ground truth) onde o vazamento é explicitamente controlado e conhecido.

Principais Contribuições

1. Framework Autorreferencial: O SrDetection elimina a necessidade de dados de referência externos ou limiares definidos manualmente ao usar o contraste dentro da própria amostra entre um trecho de código e suas variantes de preservação semântica.
2. Aumentação Automática: Um método customizado para gerar variantes de código que expõem a memorização sob edições comuns (renomeação, refatoração) enquanto preservam a funcionalidade semântica.
3. Avaliação Controlada: A introdução de um testbed baseado em treinamento que permite a medição precisa do desempenho de detecção de vazamento em diferentes modelos e estágios de treinamento, evitando a não confiabilidade das heurísticas temporais.

Resultados Experimentais

Os autores avaliaram o SrDetection contra fortes baselines (ex: PPL, Min-K% Prob, Zlib, VeilProbe, DPDLLM) em modelos Qwen2.5 e LLaMA3.1 submetidos a pré-treinamento contínuo.

• Ganhos de Desempenho: O SrDetection superou significativamente os baselines.
  • Caixa-Cinza: Melhorou o F1 médio em 21,52 pontos sobre os fortes baselines.
  • Caixa-Preta: Melhorou o F1 médio em 14,46 pontos.
• Robustez: Ao contrário dos baselines que mostraram desempenho instável ou dependente de épocas específicas, o SrDetection permaneceu consistente através de diferentes modelos e estágios de treinamento.
• Sensibilidade: O desempenho melhorou com um número maior de variantes ($n$), e o método permaneceu estável através de diferentes proporções de mistura de código-texto no corpus de pré-treinamento.
• Aplicação no Mundo Real: Um estudo de 15 Code LLMs amplamente utilizados em quatro benchmarks (APPS, HumanEval, MBPP, BigCodeBench) revelou padrões de vazamento específicos de cada benchmark. Notavelmente, o BigCodeBench mostrou altas taxas de vazamento na configuração de caixa-cinza, sugerindo que a detecção baseada em comportamento pode identificar contaminações perdidas pela análise estrita de sobreposição.

Significância e Alegações

O artigo afirma que o SrDetection aborda uma lacuna crítica na avaliação de Code LLMs ao fornecer um mecanismo de detecção independente de limiar e independente de corpus. Ao reformular a detecção de vazamento como um problema autorreferencial, o método evita a fragilidade das suposições temporais e a inacessibilidade dos dados de treinamento.

Os autores afirmam que seus achados demonstram que o vazamento não é meramente um artefato marginal, mas um confundidor sistemático nas práticas atuais de avaliação. A capacidade de detectar vazamento sem referências externas sugere que os padrões de contaminação específicos de benchmarks são mais prevalentes e complexos do que anteriormente compreendidos através de análises de sobreposição puras. O trabalho ressalta a necessidade de um design de benchmark e de reporte conscientes do vazamento para garantir a confiabilidade das avaliações de Code LLM.