On the Role of Fault Localization Context for LLM-Based Program Repair

Título: Sobre o Papel do Contexto de Localização de Falhas para Reparo de Programas Baseado em LLM

Autores: Melika Sepidband, Hung Viet Pham e Hadi Hemmati (York University, Canadá).
Fonte: Artigo submetido à ACM (2026), baseado em dados do SWE-bench Verified.

---

1. O Problema

O Reparo Automático de Programas (APR) baseado em Grandes Modelos de Linguagem (LLMs) tem avançado significativamente, mas sua eficácia ainda depende criticamente de como o modelo identifica onde focar a análise dentro de bases de código complexas.

• A Lacuna: Embora a Localização de Falhas (FL) seja um componente chave, seu impacto no contexto de LLMs é pouco explorado. Não está claro quanto contexto é necessário, se expandir o contexto além da localização exata do bug é benéfico, e como esse contexto deve ser recuperado.
• A Tensão: Existe um conflito fundamental no design de APR baseado em LLMs: fornecer mais contexto pode ajudar o modelo a entender o bug e a solução, mas um contexto excessivo pode sobrecarregar o modelo, introduzir ruído (código irrelevante) e diluir o sinal de onde o bug realmente reside.
• Hipótese Incorreta: Estudos anteriores assumiam que aumentar a precisão da localização ou expandir uniformemente o contexto melhora o reparo. Este trabalho questiona essa premissa.

2. Metodologia

Os autores realizaram um estudo empírico em larga escala para isolar e analisar o impacto de diferentes granularidades de contexto.

• Dataset: 500 instâncias do benchmark SWE-bench Verified (repositórios Python reais como Django, Matplotlib, Scikit-learn).
• Modelo: Utilização do GPT-5-mini (na época do estudo, o melhor modelo pequeno na liderança do SWE-bench) para gerar os patches.
• Design Experimental Fatorial:
  • Foram testadas 61 configurações distintas, variando três dimensões ortogonais de contexto:
    1. Nível de Arquivo: Sem arquivos, Arquivos com bug (Ground Truth), Arquivos relevantes baseados em regras (importações), Arquivos relevantes recuperados por LLM.
    2. Nível de Elemento: Sem elementos, Elementos com bug (funções/classes), Elementos via Grafo de Chamadas, Elementos recuperados por LLM.
    3. Nível de Linha: Sem linhas, Linhas com bug, Janela de contexto (±10 linhas), Fatiamento de código estático (Static Slicing), Linhas recuperadas por LLM.
  • Controle de Variáveis: Para evitar confusão entre a precisão da localização e o impacto da expansão de contexto, o estudo assumiu uma localização perfeita (Ground Truth) para extrair os arquivos, elementos e linhas com bugs. O objetivo era avaliar se expandir além desses locais perfeitos ajuda ou atrapalha.
• Métrica Principal: Taxa de resolução (proporção de instâncias onde o patch gerado passou em todos os testes).
• Análise Estatística: Teste de postos sinalizados de Wilcoxon para determinar significância estatística entre pares de configurações.

3. Principais Contribuições e Resultados

A. O Impacto do Contexto de Arquivo (Dominante)

• Melhoria Massiva: A introdução de contexto de nível de arquivo gerou uma melhoria de 15 a 17 vezes em comparação com a base sem arquivos (que resolveu apenas 3,6% dos casos).
• Expansão Beneficia: Expandir além dos arquivos com bug (incluindo arquivos relacionados) geralmente melhora o desempenho.
• LLM vs. Regras: A recuperação de arquivos baseada em LLM superou consistentemente a expansão baseada em regras (importações).
  • Desempenho: LLM recuperou arquivos melhores em 17/20 configurações.
  • Custo: A abordagem baseada em LLM foi mais barata, utilizando menos arquivos e menos tokens (em média 8,54 arquivos vs. 18,12 para regras), evitando contextos excessivamente grandes.

B. O Impacto do Contexto de Elemento (Condicional)

• Benefício Condicional: Adicionar elementos (funções/classes) ajuda, mas o ganho depende fortemente da qualidade do contexto de arquivo.
• LLM vs. Grafo de Chamadas: A recuperação de elementos via LLM superou a expansão baseada em Grafos de Chamadas (Call Graph). A abordagem estrutural (grafo) muitas vezes introduziu contexto irrelevante, enquanto a semântica do LLM capturou melhor as relações conceituais.
• Limitação: Expandir além dos elementos com bug não trouxe ganhos consistentes e significativos em todas as configurações, sugerindo que a precisão nos elementos é crucial.

C. O Impacto do Contexto de Linha (Frequentemente Prejudicial)

• Descoberta Surpreendente: Ao contrário dos níveis de arquivo e elemento, expandir o contexto de linha geralmente degrada o desempenho.
• Ruído: Técnicas como "janela de contexto" (±10 linhas) e "fatiamento de código estático" frequentemente introduziram ruído, diluindo o sinal de localização precisa.
• Melhor Estratégia: A localização precisa de linhas ("linhas com bug" ou Ground Truth) foi superior à maioria das expansões. Quando a localização de linha não é precisa, é melhor não fornecer contexto de linha do que tentar inferir linhas relevantes que podem ser erradas.
• Exceção: A recuperação de linhas via LLM foi a única estratégia de expansão que mostrou ganhos modestos e mais estáveis em comparação com janelas ou fatiamento, mas ainda assim, a precisão absoluta ("buggy lines") foi o padrão-ouro.

D. A Estratégia Ideal (Complementaridade)

• A configuração de melhor desempenho (63,4% de resolução) combinou:
  1. Arquivos: Recuperados por LLM (Contexto amplo e semântico).
  2. Elementos: Recuperados por LLM (Contexto semântico intermediário).
  3. Linhas: Precisas/Ground Truth (Localização exata para edição).
• Princípio: O sucesso vem de combinar uma compreensão semântica ampla em níveis de abstração mais altos (arquivos/elementos) com uma localização precisa e mínima no nível de linha.

4. Análise Qualitativa

Os autores analisaram casos onde mais contexto ajudou ou atrapalhou:

• Quando mais contexto ajuda: Bugs complexos que exigem raciocínio entre múltiplos módulos ou dependências cruzadas (ex: entender como uma função em um arquivo afeta outra em um arquivo diferente).
• Quando mais contexto atrapalha:
  • Contexto Excessivo: Sobrecarrega o modelo, levando a correções generalizadas em arquivos irrelevantes.
  • Interferência Irrelevante: Código semanticamente relacionado, mas não causal, desvia o modelo da verdadeira causa do bug.
  • Reparos Localizados Simples: Bugs simples que exigem edições pequenas sofrem com a adição de contexto desnecessário, que pode induzir o modelo a refatorar indevidamente.

5. Significado e Implicações Práticas

Este trabalho desafia a suposição comum de que "mais contexto é sempre melhor" ou que a precisão deve ser uniforme em todos os níveis.

• Diretrizes para APR:
  1. Priorize a Localização de Arquivos: Invista em recuperação semântica de arquivos (via LLM) em vez de heurísticas estruturais.
  2. Mantenha o Contexto de Linha Mínimo: Evite expandir linhas com janelas ou fatiamento; prefira precisão absoluta ou nenhuma linha se a precisão não for garantida.
  3. Estratégias Adaptativas: Como diferentes bugs se beneficiam de diferentes configurações de contexto, sistemas futuros devem adotar estratégias de ensemble ou adaptativas, ajustando o contexto dinamicamente com base na complexidade do bug.
• Eficiência de Custo: A recuperação baseada em LLM não apenas melhora a precisão, mas reduz custos de tokens e arquivos em comparação com métodos baseados em regras, tornando-a mais viável economicamente.

Conclusão

O estudo demonstra que a eficácia do reparo baseado em LLM não depende apenas da precisão da localização, mas da qualidade e da granularidade adequada do contexto. A estratégia mais eficaz não é expandir uniformemente, mas sim criar um equilíbrio onde o contexto é amplo para compreensão (arquivos/elementos) e preciso para execução (linhas).