Resumo Técnico: SWE-PRBench

1. Problema e Motivação

O artigo identifica uma lacuna crítica nos benchmarks atuais de Inteligência Artificial para Engenharia de Software (como o SWE-Bench). Enquanto os benchmarks existentes avaliam a capacidade dos modelos de gerar ou corrigir código, nenhum deles mede eficazmente a capacidade de um modelo de avaliar mudanças de código propostas por outros, atuando como um revisor de código experiente.

A revisão de código é uma tarefa de julgamento (identificar problemas em trabalho alheio), não de geração. O "ground truth" (verdade fundamental) não é binário (passa/falha), mas distribuído em julgamentos humanos sobre profundidade, acionabilidade e precisão factual. O objetivo do SWE-PRBench é preencher essa lacuna, fornecendo uma métrica direta para a qualidade da revisão de código automatizada.

2. Metodologia e Construção do Dataset

2.1. Coleta e Filtragem (SWE-PRBench)

O dataset consiste em 350 Pull Requests (PRs) reais, selecionados de repositórios de código aberto ativos.

• Fonte da Verdade Fundamental: Comentários de revisão escritos por engenheiros humanos durante o processo real de revisão em PRs já mesclados (coletados via API do GitHub), sem geração sintética ou modificação.
• Filtro de Qualidade (RQS - Repository Quality Score): Repositórios são pontuados (máx. 100) com base em cultura de revisão, recência, qualidade de testes e volume de PRs. Apenas repositórios com pontuação ≥60 são considerados.
• Filtragem de PRs: Um pipeline de 10 estágios remove PRs de documentação, atualizações automáticas (Dependabot), reviews dominados por IA e garante que haja pelo menos dois comentários humanos substanciais.
• Contaminação: Medidas rigorosas são tomadas para evitar que os PRs estejam no conjunto de treinamento dos modelos (janela de coleta recente, penalização de repositórios populares, uso de licenças GPL e verificação de similaridade semântica).

2.2. Taxonomia de Dificuldade

Os PRs são classificados em três tipos de dificuldade, baseados na localização da evidência do problema:

1. Type1 (Direto - 34%): O problema é visível apenas nas linhas alteradas (diff).
2. Type2 (Contextual - 40%): O problema requer entender a interação entre o código alterado e o código não alterado no mesmo arquivo.
3. Type3 (Latente - 26%): O problema reside em arquivos que importam ou dependem dos arquivos alterados, exigindo raciocínio entre arquivos.

2.3. Configurações de Contexto (Ablação)

O estudo avalia os modelos sob três configurações de contexto "congeladas" (frozen), variando a riqueza da informação sem aumentar drasticamente o volume de tokens (2.000 a 2.500 tokens):

• Config A (Diff Only): Apenas o diff e metadados mínimos (análogo a uma notificação de e-mail do GitHub).
• Config B (Diff + Conteúdo do Arquivo): Adiciona contexto de execução e mapeamento de comportamento (análogo à visualização web do PR).
• Config C (Full Context): Adiciona assinaturas de testes e contexto completo do IDE.

2.4. Protocolo de Avaliação

• Agentes: 8 modelos de ponta (incluindo Claude Haiku/Sonnet, GPT-4o, DeepSeek V3, Mistral, Llama 3.3).
• Julgador (LLM-as-Judge): Um modelo fixo (GPT-5.2) classifica os comentários dos agentes como Confirmados (correspondem ao ground truth humano), Plausíveis (corretos, mas não no ground truth) ou Fabricados (alucinações).
• Métrica: Um escore composto ponderado que considera Recall, Precisão, Alinhamento Semântico, Acionabilidade e penalizações por alucinação e redundância. O acordo entre o julgador e o rubric humano foi validado com $\kappa=0.75$.

3. Resultados Principais

3.1. Desempenho Geral

• Baixa Eficácia: Nenhum dos 8 modelos detectou mais de 31% dos problemas sinalizados por humanos na configuração mais simples (Config A). A taxa média de detecção foi de aproximadamente 26%.
• Gap de Desempenho: Existe um abismo entre a capacidade atual de IA e a de revisores humanos (estimado em 20-40 pontos percentuais de recall).
• Ranking: Os quatro melhores modelos (Haiku, Sonnet, DeepSeek, Mistral Large) têm desempenho estatisticamente indistinguível (escore médio $\bar{s} \approx 0.147–0.153$), formando uma "Tier 1" clara, separada dos quatro restantes.

3.2. O Paradoxo do Contexto (Descoberta Crítica)

A descoberta mais significativa é a degradação monótona de desempenho à medida que o contexto aumenta:

• Config A > Config B > Config C: Todos os 8 modelos performaram pior quando mais contexto foi adicionado.
• Colapso do Type2: A detecção de problemas "Contextuais" (Type2) caiu drasticamente (mais de 50% em alguns casos) ao passar da Config A para a Config B.
• Causa: O estudo conclui que o problema não é a seleção de conteúdo (o contexto foi construído com extração AST e grafos de importação), mas sim a diluição da atenção. Ao fornecer o diff junto com arquivos inteiros em uma sequência plana de tokens, os modelos falham em distinguir as linhas alteradas do contexto estático, perdendo o foco.

3.3. Alucinações e Precisão

• Existe uma compensação (trade-off) entre Recall e Precisão. Modelos como o DeepSeek V3 têm maior detecção, mas taxas de alucinação mais altas. O GPT-4o apresenta a menor taxa de alucinação (FPR = 0.193), mas menor capacidade de detecção.
• O escore composto penaliza severamente as alucinações, favorecendo modelos que fazem menos afirmações falsas, mesmo que detectem menos bugs.

4. Contribuições Chave

1. Dataset SWE-PRBench: O primeiro benchmark de 350 PRs com ground truth humano real, focado especificamente na tarefa de avaliação de código, não geração.
2. Protocolo de Avaliação Robusto: Uso de um framework "LLM-as-Judge" validado estatisticamente ($\kappa=0.75$) com bipartite matching para evitar créditos duplicados.
3. Descoberta de Degradação de Contexto: Evidência empírica de que, para revisão de código, adicionar contexto não estruturado (ou mesmo semiestruturado) pode ser prejudicial devido a limitações de atenção dos modelos atuais, contradizendo a intuição de que "mais contexto é sempre melhor".
4. Infraestrutura Aberta: Disponibilização pública do dataset, dos artefatos de contexto congelados e do harness de avaliação no HuggingFace e GitHub.

5. Significado e Conclusão

O SWE-PRBench demonstra que, apesar dos avanços na geração de código, a revisão de código automatizada por IA ainda está longe de ser confiável para substituir revisores humanos. A principal limitação não é a falta de conhecimento do modelo, mas a incapacidade de manter o foco nas mudanças relevantes quando exposto a grandes volumes de contexto estático.

O trabalho sugere que o futuro da revisão de código por IA não reside apenas em fornecer mais contexto, mas em desenvolver estratégias de representação de contexto (como marcadores explícitos de fronteiras entre alterado/não alterado ou contextos recuperados de forma mais inteligente) que mitiguem a diluição da atenção. O benchmark serve como um ponto de referência crítico para a comunidade desenvolver modelos capazes de fechar essa lacuna de desempenho.