Resumo Técnico: Abster-se e Validar: Uma Política de Dual-LLM para Redução de Ruído em Reparação de Programas Agêntica

Declaração do Problema

Sistemas de Reparação Automática de Programas (APR) agênticos demonstraram a capacidade de resolver bugs complexos em nível de repositório, alcançando altas taxas de pass@1 em benchmarks como o SWE-Bench-Verified. No entanto, implantar esses sistemas em ambientes industriais apresenta um desafio crítico: o problema do "ruído". Mesmo com taxas de resolução crescentes, uma parcela significativa dos patches gerados dificilmente será aceita por desenvolvedores humanos. Apresentar esses patches de baixa qualidade ou intratáveis desperdiça o valioso tempo do desenvolvedor, erode a confiança em ferramentas automatizadas e incorre em custos computacionais desnecessários. O problema central abordado é como filtrar bugs que um sistema de APR dificilmente corrigirá antes das tentativas de reparação, e como rejeitar patches que dificilmente serão corretos após a geração, otimizando assim a relação sinal-ruído para revisores humanos.

Metodologia

Os autores propõem um framework de política de dual-LLM composto por dois estágios complementares: Abstenção de Bug e Validação de Patch.

1. Política de Abstenção de Bug

Esta política opera antes do agente de reparação tentar uma correção. Ela funciona como um pré-filtro para excluir bugs considerados improváveis de serem resolvidos pelo sistema.

• Entrada: Apenas o relatório de bug (título, descrição, metadados). A política não acessa a base de código ou a trajetória do agente para manter a eficiência.
• Mecanismo: Um LLM prevê a probabilidade de uma tentativa de reparação bem-sucedida. Os autores formalizam isso como a estimativa da probabilidade de sucesso empírica ($\hat{\pi}_b$) de um bug $b$.
• Representações: Duas estratégias de prompting foram avaliadas:
  • Prompt de Instrução sem Diretrizes: Entrada básica do relatório de bug.
  • Prompt de Instrução com Diretrizes: Aumentado com critérios derivados de humanos (ex: "Problema & Ação Claros", "Localização de Código Precisa") para guiar a avaliação de dificuldade pelo LLM.
• Decisão: Se a probabilidade prevista $P_a(b)$ cair abaixo de um limiar configurável $\tau$, o sistema "abstrai-se" de tentar a reparação, economizando computação e evitando a geração de patches de baixa qualidade.

2. Política de Validação de Patch

Esta política opera após o agente gerar uma trajetória de reparação. Ela avalia se um patch específico é uma correção correta.

• Entrada: O relatório do bug, a trajetória do agente (pensamentos e ações), o patch gerado (diff) e os resultados dos testes.
• Mecanismo: Uma abordagem de múltiplos estágios:
  1. Verificações Determinísticas: Construção e verificações de regressão para remover patches com falhas óbvias.
  2. Geração de Especificação de Correção: Um LLM gera uma "especificação de correção" — um conjunto de critérios para uma correção correta baseada apenas no relatório do bug e nos arquivos originais da fonte (sem conhecimento da verdade fundamental/ground-truth).
  3. Julgamento por LLM: Uma segunda chamada de LLM avalia a tentativa do agente contra a especificação gerada, o patch e os resultados dos testes.
• Saída: Um triplet consistindo em um julgamento binário (corrigido/não corrigido), uma explicação em linguagem natural e um escore de confiança derivado das probabilidades de log por token.
• Decisão: Os patches podem ser filtrados com base no julgamento binário ou em um corte de percentil da pontuação de confiança, permitindo um rigor ajustável.

3. Framework Combinado

As duas políticas são compostas sequencialmente: a Abstenção de Bug filtra o conjunto inicial de bugs, o sistema de APR tenta as reparações nos bugs restantes e a Validação de Patch filtra os patches resultantes. Isso cria um funil configurável para revisão humana.

Avaliação e Resultados

As políticas foram avaliadas em três conjuntos de dados industriais do codebase do Google:

1. Bugs Reportados por Humanos (174 bugs): Correções de verdade fundamental conhecidas e testes de reprodução de falha-ao-passar (fail-to-pass).
2. Bugs NPE Reportados por Máquina (198 bugs): Exceções de ponteiro nulo (Null Pointer Exceptions) de implantação ao vivo com stack traces.
3. Bugs Reportados por Sanitizer (50 bugs): Erros de memória e condições de corrida com testes de reprodução conhecidos.

Principais Descobertas:

• Bugs Reportados por Humanos:
  • Baseline: O sistema não filtrado alcançou uma taxa de fail-to-pass@1 de 11,29%.
  • Abstenção de Bug: Usando diretrizes ($r_2$), a taxa de fail-to-pass@1 filtrada aumentou para 21,05%.
  • Validação de Patch: Usando uma validação estrita baseada em percentil (percentil 90), a taxa de fail-to-pass@1 filtrada aumentou para 29% (um ganho de 15 pontos percentuais sobre o baseline).
  • Política Combinada: A abordagem de política dupla alcançou um fail-to-pass@1 filtrado de 53% (um ganho de 39 pontos percentuais) com a configuração mais estrita (combined-p90), efetivamente elevando a taxa de sucesso para 1-em-2 para os patches mostrados aos desenvolvedores.
• Bugs Reportados por Máquina:
  • A validação de patch melhorou significativamente as taxas de accept@1 filtradas para bugs de NPE (de 0,38 para 0,62) e bugs de sanitizer (até 15 pontos percentuais acima do baseline).
• Trade-offs: O estudo destaca um compromisso entre o volume de bugs tentados e a precisão dos patches apresentados. Filtros mais estritos (ex: percentil 90) reduzem drasticamente o número de bugs apresentados aos desenvolvedores (ex: de 174 para 12), mas garantem uma taxa de sucesso muito maior para os que restam.

Principais Contribuições

1. Política de Abstenção de Bug: Um novo mecanismo de pré-filtragem de reparação que utiliza LLMs para prever a viabilidade da reparação baseando-se apenas nos relatórios de bugs, evitando tentativas de reparação fúteis.
2. Política de Validação de Patch: Um framework de avaliação pós-reparação de múltiplos estágios que utiliza "especificações de correção" geradas sem conhecimento da verdade fundamental para filtrar patches candidatos.
3. Avaliação Industrial Extensa: Um estudo abrangente através de três categorias distintas de bugs (reportados por humanos, NPE e sanitizer) demonstrando a natureza complementar das duas políticas.
4. Inovação de Métrica: Introdução do "filtered success@k", uma métrica que avalia taxas de sucesso apenas no subconjunto de bugs e patches permitidos pelas políticas, fornecendo uma medida mais realista da experiência do desenvolvedor.

Significância e Alegações

O artigo alega que esta abordagem de duas políticas fornece um caminho prático para a implantação confiável e em escala industrial de sistemas de APR agênticos. Ao reduzir significativamente o ruído de tentativas de reparação improdutivas, o framework aborda o gargalo crítico da confiança e do gerenciamento de tempo do desenvolvedor.

Os autores enfatizam que, embora a taxa geral de resolução de bugs possa diminuir devido à filtragem agressiva (já que alguns bugs corrigíveis são rejeitados), a qualidade dos patches apresentados aos desenvolvedores melhora dramaticamente. Em termos práticos, isso transforma a experiência do desenvolvedor de revisar um patch com uma probabilidade de sucesso de ~10% para revisar um patch com uma probabilidade de sucesso de ~50% (sob configurações estritas) ou ~33% (sob configurações permissivas). Essa mudança é argumentada como essencial para a adoção de ferramentas de IA na engenharia de software, pois alinha a saída de sistemas automatizados com a capacidade limitada dos revisores humanos. O trabalho não pretende resolver a dificuldade fundamental de reparar todos os bugs, mas sim otimizar a interação entre sistemas agênticos e desenvolvedores humanos, garantindo que apenas os candidatos mais promissores cheguem à etapa humana.