Resumo Técnico: TrajSpec – Refinamento de Especificação de Relatório de Bug Guiado por Trajetória

Declaração do Problema

Agentes de Reparação Automática de Programas (APR) em nível de repositório dependem de relatórios de bugs como sua principal especificação de tarefa. No entanto, os relatórios de bugs padrão frequentemente descrevem apenas os sintomas de falha observados, omitindo informações críticas para a reparação, como o mecanismo subjacente da falha, requisitos comportamentais específicos e o escopo completo da implementação. Consequentemente, agentes de APR podem inspecionar código irrelevante, inferir requisitos incorretos ou gerar patches que abordam o sintoma relatado sem restaurar o comportamento pretendido do repositório. Embora trabalhos anteriores tenham focado em melhorar estratégias de busca, localização ou engenharia de prompt de agentes, essas abordagens frequentemente assumem que o relatório de entrada fornece uma especificação suficiente. Existe uma lacuna em métodos que refinam explicitamente o relatório coletando detalhes de especificação ausentes a partir do repositório antes que o processo de reparação a jusante comece.

Metodologia: TrajSpec

Os autores propõem o TrajSpec, uma abordagem guiada por trajetória para o refinamento de especificação suportada pelo repositório. O sistema opera sobre um relatório de bug original ($b$) e um snapshot pré-correção do repositório ($R_c$) através do seguinte pipeline:

1. Coleta de Trajetória Não Verificada:
   O TrajSpec executa um agente de coleta de trajetória usando apenas $b$ e $R_c$. Este agente explora o repositório, inspeciona o código e raciocina sobre o problema. Crucialmente, esta execução é não verificada: o TrajSpec não valida nenhum patch candidato produzido durante esta fase. Qualquer patch candidato é descartado, e apenas a trajetória de execução ($\tau$) — uma sequência de tuplas pensamento-ação-observação — é retida. Esta trajetória serve como uma fonte de evidência suportada pelo repositório, mesmo que o patch final do agente tenha sido incorreto.

2. Abstração Hierárquica de Evidências:
   Trajetórias brutas são frequentemente ruidosas e extensas. O TrajSpec extrai achados candidatos de $b$ e $\tau$ focando em três dimensões:

   • Mecanismo de Falha: O comportamento do código-fonte que explica o sintoma.
   • Requisito Comportamental: O comportamento que deve ser mantido.
   • Escopo de Implementação: Os locais de código envolvidos.

   Estes achados são organizados em uma representação hierárquica ($M$) com três níveis de detalhe para cada dimensão:

   • Alto nível: Uma conclusão de especificação candidata.
   • Nível médio: Raciocínio diagnóstico e relações (ex: caminhos de código, dependências).
   • Baixo nível: Observações concretas do repositório (ex: arquivos, funções ou variáveis específicas).

3. Geração de Rascunho e Revisão Baseada no Repositório:
   Usando $b$ e $M$, um LLM gera um rascunho de relatório refinado ($\hat{b}$) seguindo um esquema fixo (Título, Descrição, CausaRaiz, PassosParaReproduzir, ComportamentoEsperado, ComportamentoObservado).

   Uma etapa de revisão baseada no repositório então valida $\hat{b}$ contra $R_c$. Um agente revisor avalia se as afirmações no rascunho são suportadas pela evidência em $M$ e pelo código-fonte real. Ele remove afirmações não suportadas, revisa declarações incertas, adiciona detalhes ausentes suportados pelo repositório e garante que o escopo de implementação esteja apropriadamente delimitado. O resultado é o relatório refinado final ($\hat{b}_f$), que serve como a especificação de tarefa para o agente de reparação a jusante.

Principais Contribuições

• Formulação: O artigo formula o aprimoramento de relatórios de bugs para APR em nível de repositório como "refinamento de especificação suportada pelo repositório", visando tornar explícitos o mecanismo de falha, o requisito comportamental e o escopo de implementação.
• Framework TrajSpec: Introdução de um método que extrai e organiza hierarquicamente a evidência de especificação de uma execução de coleta de trajetória não verificada, revisa esta evidência contra o código-fonte e gera um relatório refinado sem assumir que os patches candidatos da trajetória estão corretos.
• Avaliação Abrangente: Avaliação em todas as 300 instâncias do SWE-Bench Lite usando o Mini-SWE-Agent V2, demonstrando melhorias significativas de desempenho.
• Generalização: Demonstração de que os benefícios do TrajSpec se generalizam entre diferentes agentes de reparação (Agentless e AutoCodeRover).
• Análise de Componentes: Estudos de ablação confirmando que tanto a representação de evidência hierárquica quanto a revisão baseada no repositório são críticos para os ganhos de desempenho.

Resultados de Avaliação

Os autores avaliaram o TrajSpec em 300 instâncias do SWE-Bench Lite:

• Agente de Reparação Primário (Mini-SWE-Agent V2):

  • Com GPT-5-mini, o Pass@1 melhorou de 41,00% (relatórios originais) para 59,67%.
  • Com MiniMax M2.5, o Pass@1 melhorou de 54,67% para 64,33%.
  • O TrajSpec superou um baseline "Agentic-Base" (que usa dados de trajetória, mas carece de abstração hierárquica e revisão de repositório) em ambos os cenários.
  • As melhorias foram amplamente distribuídas em 12 repositórios diferentes, com o TrajSpec expandindo a cobertura de reparação enquanto preservava quase todas as instâncias anteriormente reparadas pelos relatórios originais.

• Generalização entre Agentes (Amostra Estratificada de 100 instâncias):

  • Agentless: Pass@1 melhorou de 41,00% para 71,00%.
  • AutoCodeRover: Pass@1 melhorou de 47,00% para 72,00%.

• Estudos de Ablação:

  • Remover a revisão baseada no repositório reduziu o Pass@1 de 59,67% para 48,00%.
  • Remover a representação de evidência hierárquica reduziu o Pass@1 para 47,67%.
  • Isso confirma que tanto estruturar as evidências quanto verificar as afirmações contra o repositório são essenciais.

• Análise de Custo:

  • Embora o TrajSpec incorra em um custo adicional para a geração do relatório (aprox. $0,083 por instância com GPT-5-mini), ele reduz o uso de tokens de entrada da reparação a jusante em ~24% e diminui o custo monetário da execução da reparação em si. O custo total de ponta a ponta permanece modesto em relação aos ganhos significativos de sucesso.

Significância e Alegações

O artigo alega que o TrajSpec fornece uma direção promissora para melhorar a reparação em nível de repositório ao abordar o "problema da especificação" inerente aos relatórios de bugs subespecificados. Os autores enfatizam que:

1. Trajetórias são reutilizáveis além da geração de patch: Mesmo trajetórias não verificadas contêm evidências valiosas sobre mecanismos de falha e escopo de código que podem ser abstraídas e estruturadas para melhorar a especificação da tarefa.
2. Verificação é crítica: Simplesmente usar dados de trajetória é insuficiente; uma estrutura hierárquica e uma etapa de revisão baseada no repositório são necessárias para filtrar o ruído e garantir que as afirmações estejam fundamentadas no código pré-correção.
3. A especificação da tarefa importa: Melhorar a especificação de entrada (o relatório de bug) é tão importante quanto melhorar o próprio agente de reparação. O TrajSpec demonstra que fornecer aos agentes um contexto acionável e suportado pelo repositório melhora consistentemente o desempenho da reparação em diferentes modelos e arquiteturas de agentes.

Os autores mantêm uma postura modesta, observando que sua avaliação é limitada a repositórios Python no SWE-Bench Lite e que a eficácia para outras linguagens ou benchmarks permanece como trabalho futuro. Eles também reconhecem que, embora os relatórios refinados melhorem as métricas de reparação automatizada, o estudo foca na utilidade para APR, e não na qualidade do relatório percebida por humanos.