Resumo Técnico: EVIACT – Um Framework de Evidência para Ação para Reparo de Programas Agêntico

Declaração do Problema

O Reparo Automático de Programas (APR) evoluiu da geração de correções em contexto fixo para reparo interativo em nível de repositório usando agentes de Modelo de Linguagem de Grande Escala (LLM). Embora os sistemas existentes de APR agêntico ofereçam flexibilidade, eles lutam para utilizar efetivamente evidências de execução para guiar o processo de reparo. O artigo identifica uma lacuna crítica de "evidência para ação" em sistemas de APR agêntico baseados em fluxo de trabalho.

Nos sistemas baseados em fluxo de trabalho atuais, o reparo é decomposto em etapas (por exemplo, localização, geração de correção, validação), mas os limites entre essas etapas são subespecificados. Essa falta de controle estrito leva a três modos de falha primários, ilustrados como uma "cascata de localização incorreta" na Figura 1:

1. Localização Incorreta: Evidências de falha fracas levam a conjuntos de suspeitos incorretos, fazendo com que o agente edite código não relacionado.
2. Tentativas de Correção Inválidas: Agentes geram correções malformadas, inaplicáveis ou não compiláveis que atingem a etapa de validação.
3. Alto Custo de Validação: O sistema testa repetidamente correções semanticamente irrelevantes ou não executáveis, desperdiçando recursos computacionais.

O problema central é que a evidência de execução é observada, mas não é usada de forma confiável para controlar o que recuperar, o que editar e quando validar.

Metodologia: O Framework EVIACT

Para abordar essa lacuna, os autores propõem o EVIACT (Evidência para Ação), um framework de APR agêntico que coordena três "guarda-chuvas" orientados por evidências em um pipeline padrão de quatro etapas: Configuração, Localização, Correção e Verificação.

1. O Pipeline

• Configuração: Inicializa um espaço de trabalho limpo, constrói um índice de recuperação que preserva a estrutura (usando spans AST e grafos de código) e reproduz a falha alvo para obter evidências VERMELHAS (logs de teste falhos, rastros de pilha).
• Localização: Converte evidências VERMELHAS em consultas fundamentadas na falha para classificar locais de código suspeitos.
• Correção: Sintetiza edições candidatas com base no conjunto de suspeitos localizado.
• Verificação: Reexecuta os testes alvo e suites de regressão completas para aceitar uma correção.

2. Os Três Guarda-Chuvas

O EVIACT introduz controles específicos nas transições de etapa para transformar evidências em restrições acionáveis:

• Andaime de Recuperação (Configuração $\to$ Localização):
  Em vez de busca por palavras-chave sem restrições, este andaime mapeia evidências de falha VERMELHAS para um conjunto de suspeitos focado usando um grafo de código estrutural. Ele realiza recuperação determinística ao combinar sinais de falha (quadros de pilha, mensagens de erro) com spans AST e descritores estruturais (caminhos de arquivo, símbolos, grafos de chamada). Ele classifica candidatos com base em correspondências exatas de rastro-símbolo, proximidade de arquivo e distância no grafo, gerando um conjunto compacto dos principais K suspeitos (padrão $K=3$).

• Portão de Compilação (Etapa de Correção):
  Antes de qualquer validação de teste, este portão filtra correções candidatas. Ele verifica se uma correção é uma diff bem-formada, aplica-se limpa e passa em verificações de sintaxe ou construção. Se uma correção falhar, diagnósticos estruturados (tipo de falha, arquivos afetados, saída de construção) são retornados ao agente para refinamento, impedindo que candidatos inválidos alcancem suites de teste caras.

• Portão Orientado a Testes (TD) (Configuração $\to$ Verificação):
  Este portão impõe um fluxo VERMELHO-VERDE antes da regressão completa.

  • VERMELHO: O teste alvo originalmente falho deve falhar na revisão com defeito para ancorar a localização.
  • VERDE: Após a correção, o mesmo teste alvo deve passar antes que o sistema prossiga para testes de regressão completos.
    Isso garante que a correção aborde especificamente a falha observada antes de incorrer no custo da validação completa.

Contribuições Principais

1. Identificação da Lacuna de Evidência para Ação: O artigo enquadra a ineficiência em APR agêntico baseado em fluxo de trabalho como um problema de design de limites de etapa onde a evidência de execução falha em restringir decisões subsequentes de reparo.
2. O Framework EVIACT: Uma arquitetura inovadora que coordena três guarda-chuvas (Andaime de Recuperação, Portão de Compilação, Portão TD) para garantir que as trajetórias de reparo permaneçam vinculadas a falhas observadas, feedback do compilador e resultados de validação.
3. Avaliação Abrangente: Avaliação em quatro benchmarks (Defects4J 2.0, SWE-bench Verified, SWE-bench Lite, SWE-bench Live) usando múltiplos backbones de LLM (GPT-4o, GPT-5.2, DeepSeek-V3.2, Gemini-2.5-Pro).
4. Evidência Empírica: Resultados demonstrando que o controle coordenado de evidências melhora tanto a eficácia (taxa de resolução) quanto a eficiência (custo de API, tempo de execução).

Resultados Experimentais

Avaliado sob o backbone GPT-4o, o EVIACT supera as melhores linhas de base comparáveis relatadas em todos os quatro conjuntos de dados:

• Taxas de Resolução: O EVIACT alcança melhorias de 1,6 a 6,0 pontos percentuais sobre as linhas de base (por exemplo, 25,0% no Defects4J 2.0 versus 19,6% para o RepairAgent; 40,4% no SWE-bench Verified versus 38,8% para o Agentless).
• Eficiência: Onde os custos de linha de base estão disponíveis, o EVIACT mostra 70,1–88,6% de custos de API por bug menores.
• Escalonamento de Modelo: O uso de backbones mais fortes como o GPT-5.2 aumenta ainda mais as taxas de resolução (até 70,2% no SWE-bench Verified), enquanto modelos custo-efetivos como o DeepSeek-V3.2 mantêm alto desempenho com custos significativamente menores ($0,03–$0,05 por bug).

Estudos de Ablação:
A remoção dos guarda-chuvas degrada significativamente o desempenho. O sistema completo EVIACT melhora a taxa de resolução em +13,0 pontos percentuais sobre uma linha de base sem guarda-chuvas em uma amostra estratificada, enquanto reduz o uso de tokens em 84,1 mil e o tempo de execução em 195,3 segundos. O estudo confirma que o andaime de recuperação reduz o desvio de localização, o portão de compilação filtra candidatos inválidos e o portão TD previne regressão completa prematura.

Análise de Falhas:
Em execuções falhas, 46,5% são devidas à localização incorreta e 38,5% a edições incorretas (contexto correto, mas mudança semântica errada). Notavelmente, correções malformadas ou não compiláveis são efetivamente filtradas pelo portão de compilação, deslocando a fronteira de falha de "invalidade executável" para "fundamentação semântica". A análise manual de correções resolvidas mostra que 78,0% são semanticamente corretas, embora 11,5% sejam superajustadas (passando nos testes, mas não implementando um reparo geral).

Significado e Alegações

O artigo alega que o EVIACT fornece um mecanismo prático de controle de evidência para ação para APR agêntico. Ao ancorar ações de reparo em evidências rastreáveis (logs de falha, diagnósticos do compilador e resultados de teste), o framework torna as decisões de reparo mais eficazes e confiáveis.

Os autores notam modestamente que, embora o EVIACT reduza significativamente o custo de validação e melhore a localização, os gargalos restantes são a fundamentação semântica (garantir que a edição seja o certo reparo, não apenas um reparo funcionando) e a recuperação robusta em estruturas complexas de repositório. O artigo não alega resolver completamente o superajuste semântico, mas demonstra que deslocar a fronteira de falha de erros sintáticos/executáveis para erros semânticos é um passo necessário para um reparo agêntico mais robusto. Sugere-se trabalho futuro para estender este design para sistemas adaptativos que refinam a localização e a validação com base no feedback de execução acumulado.