Cross-Context Verification: Hierarchical Detection of Benchmark Contamination through Session-Isolated Analysis

Título: Verificação de Contexto Cruzado (CCV): Detecção Hierárquica de Contaminação de Benchmarks através de Análise Isolada por Sessão

1. O Problema

Os benchmarks de codificação para Grandes Modelos de Linguagem (LLMs), especificamente o SWE-bench Verified, enfrentam uma crise de credibilidade.

• Vazamento de Soluções: Estudos indicam que uma porcentagem significativa de "sucessos" no benchmark resulta de vazamento de soluções (o modelo memorizou a resposta exata do texto do problema ou comentários, em vez de raciocinar).
• Limitações dos Métodos Atuais: As técnicas existentes de detecção de contaminação (como consistência de paráfrase, sobreposição de n-gramas e análise de perplexidade) analisam apenas artefatos finais (texto) e não observam diretamente o processo de geração do modelo. Elas não conseguem distinguir se o modelo está raciocinando ou apenas recuperando uma memória.
• Falha na Repetição Simples: Tentativas de melhorar a detecção através da repetição de verificações (multi-turn) falharam, gerando mais falsos positivos do que erros reais descobertos, devido ao viés de confirmação e ao efeito de âncora.

2. Metodologia

Os autores propõem duas inovações principais: o método de detecção CCV e a arquitetura de análise HCCA.

A. Cross-Context Verification (CCV)

O método baseia-se no princípio de que, se um modelo memorizou uma solução, ele a reproduzirá de forma determinística (idêntica) em sessões independentes. Se o modelo estiver raciocinando genuinamente, a não-determinística natural da inferência (mesmo com temperatura 0) produzirá soluções diversas.

• Isolamento de Sessão: O mesmo problema é resolvido $N$ vezes (no estudo, 5 vezes) em sessões de API totalmente isoladas (sem histórico, repositório limpo, histórico git futuro removido).
• Métricas de Diversidade:
  • Diversidade de Código: Calculada via similaridade de AST, BLEU nível de linha e distância de edição normalizada entre os patches gerados.
  • Proximidade do Ouro (Gold Proximity): Similaridade BLEU entre os patches gerados e a solução oficial (gold patch).
• Classificação de Raciocínio: Um classificador heurístico analisa os primeiros 100 tokens. Se a saída começa imediatamente com um diff/patch (sem pré-ambulo analítico), é classificado como "Sem Raciocínio" (suspeito de contaminação).
• Pontuação de Contaminação (CS): Uma fórmula ponderada combina proximidade com o ouro, diversidade de código e variância da proximidade.
  • CS Alto: Indica contaminação (baixa diversidade, alta similaridade com o ouro).
  • CS Baixo: Indica raciocínio genuíno (alta diversidade).

B. Hierarchical Cross-Context Architecture (HCCA)

Para analisar os resultados do CCV sem introduzir viés humano ou de modelo, os autores criaram uma estrutura multi-agente com restrição intencional de informação.

• Camadas:
  • Designer: Define o protocolo (não vê dados).
  • Executor: Gera os dados brutos (patches e métricas).
  • Analistas (Camada 2): Três analistas independentes analisam grupos diferentes de problemas. Crucialmente, eles não veem as conclusões uns dos outros.
  • Integrador: Combina os resultados das camadas 2.
• Mecanismo Chave: A restrição de informação impede o viés de confirmação e o efeito de âncora. Um experimento piloto mostrou que, se um "Verificador" vê as conclusões de um "Trabalhador" anterior, ocorre uma confirmação sycophântica (100% de concordância), anulando qualquer benefício da verificação.

3. Contribuições Principais

1. Método CCV: Primeira abordagem "caixa-preta" que observa diretamente se o modelo raciocina ou memoriza durante a geração de código, usando diversidade de sessão isolada.
2. Arquitetura HCCA: Um framework que previne viés de confirmação através da restrição de informação entre analistas, estendendo o conceito de isolamento de contexto para o nível de análise.
3. Validação Empírica: Separação perfeita entre comportamentos contaminados e genuínos em 9 problemas do SWE-bench.
4. Descoberta de Mecanismo: Evidência convergente de que a restrição de informação (não a complexidade estrutural ou a repetição) é a condição necessária para verificação eficaz.
5. Ferramentas Práticas: Código aberto, fórmula de pontuação de contaminação e um classificador de raciocínio com 100% de precisão no conjunto de dados.

4. Resultados

O estudo foi realizado no Claude Opus 4.6 (temperatura 0) em 9 problemas do SWE-bench Verified (45 tentativas totais).

• Separação Perfeita: O método CCV alcançou uma separação estatística perfeita entre problemas contaminados e genuínos (Mann-Whitney U = 0, $p \approx 0.012$, $r = 1.0$).
  • Contaminados: Pontuação de Contaminação (CS) $\ge 0.6$ (na verdade, $\ge 0.95$ para casos puros). Diversidade de código = 0.0 (soluções byte-identicas).
  • Genuínos: CS < 0.6. Alta diversidade de soluções.
• Contaminação Binária: Os dados sugerem que a contaminação é um fenômeno binário: o modelo ou recupera a solução perfeitamente (diversidade zero) ou raciocina genuinamente (diversidade alta). Não há um "meio-termo" claro nos dados observados.
• Falsos Positivos Detectados: 33% das etiquetas de contaminação anteriores foram reclassificadas como falsos positivos. Exemplo: O problema astropy-13236, previamente rotulado como suspeito, mostrou-se genuíno (alta diversidade, presença de raciocínio) sob o CCV.
• Detecção de Falhas no Teste (Test Flaws): O HCCA identificou casos compostos (Contaminação + Falha no Teste). Por exemplo, astropy-7606 mostrou sinais de contaminação (baixa diversidade), mas a solução memorizada não era o "gold patch" (que falhava no teste). Isso só foi descoberto porque analistas independentes cruzaram dados sem se influenciarem.
• Tempo de Resposta: Problemas contaminados foram respondidos 3.2x mais rápido (média de 5.77s) do que os genuínos (18.45s), indicando recuperação de memória vs. computação ativa.

5. Significado e Conclusão

• Mudança de Paradigma: O trabalho demonstra que a simples repetição de tarefas não melhora a verificação; pelo contrário, a estrutura de isolamento de informação é o fator crítico.
• Ferramenta de Validação de Labels: O CCV não serve apenas para detectar contaminação, mas para auditar as próprias etiquetas dos benchmarks, revelando que muitos problemas considerados "contaminados" podem ser limpos para modelos específicos, e vice-versa.
• Implicações para Pesquisa: A descoberta de que a contaminação é binária e que a ausência de raciocínio é um discriminador perfeito oferece uma nova métrica robusta para avaliar a capacidade real de raciocínio de LLMs.
• Limitações: O estudo focou em um único modelo (Claude Opus 4.6) e em Python. A generalização para outros modelos e linguagens requer validação futura. Além disso, o classificador de raciocínio foi validado no mesmo conjunto de dados (risco de circularidade), embora a independência comportamental dos sinais mitigue essa preocupação.

Em suma, o artigo propõe que a integridade de benchmarks e a verificação de LLMs dependem fundamentalmente de isolamento de contexto e restrição de informação entre os agentes de análise, superando as limitações das abordagens tradicionais de repetição e compartilhamento total de dados.