Automated Root-Cause Subclassification and No-Code Fix Generation for Invalid Bug Reports

Resumo Técnico: Subclassificação Automatizada de Causa Raiz e Geração de Correções Sem Código para Relatórios de Bugs Inválidos

Declaração do Problema
A manutenção de software incorre em custos significativos, com uma parcela substancial de relatórios de bugs sendo "inválidos" — o que significa que não exigem modificações no código-fonte. Esses relatórios frequentemente decorrem de mal-entendidos do usuário, erros de configuração, dependências externas ou solicitações de funcionalidades. Atualmente, equipes de suporte ao cliente realizam manualmente a triagem desses relatórios para identificar causas raiz e fornecer "correções sem código" (orientações acionáveis sem alterações no código). Esse processo manual é intensivo em recursos, atrasa a resolução e deixa os usuários incertos sobre como resolver seus problemas. Embora pesquisas anteriores tenham abordado a detecção de bugs inválidos ou a análise de causa raiz, nenhum estudo automatizou simultaneamente a subclassificação de causa raiz de relatórios inválidos e a geração de correções acionáveis sem código.

Metodologia
Os autores propõem o IssueSupport, um framework automatizado projetado para subclassificar relatórios de bugs inválidos por causa raiz e gerar as correspondentes correções sem código. O estudo utiliza um benchmark novo e curado manualmente, derivado do repositório GitHub do Navegador Brave, contendo 302 relatórios de bugs inválidos de alta qualidade e anotados, com subclasses de verdade fundamental e correções sem código bem-sucedidas ou falhas.

O framework avalia quatro configurações experimentais distintas para abordar perguntas de pesquisa específicas:

1. Pipeline LLM Vanilla: Prompting zero-shot de LLMs proprietários (Gemini 3.1 Pro, GPT-5.4, Claude Opus 4.6) e de código aberto (GLM-5, MiniMax M2.7, Kimi 2.5) para classificar e gerar correções.
2. Sem Informações Prévias (Ablação): Uma configuração onde o LLM é solicitado sem a taxonomia específica de subclasses inválidas ou diretrizes de correção, para medir o impacto do conhecimento prévio.
3. Geração Aumentada por Recuperação (RAG): O LLM é aumentado com um processo de recuperação em duas etapas (busca vetorial densa seguida de reclassificação por cross-encoder) usando relatórios de bugs históricos e documentação oficial da wiki do projeto.
4. Busca Web Agente: Um pipeline baseado em agente (inspirado no WebThinker) que realiza buscas web limitadas e multi-etapa para coletar evidências externas dinâmicas (por exemplo, changelogs de upstream, rastreadores de terceiros) antes de gerar uma resposta.

Principais Contribuições

1. Taxonomia e Metodologia: Uma taxonomia abrangente baseada em causa raiz para relatórios de bugs inválidos (abrangendo sete subclasses: Sistema Externo e Dependência, Configuração Defeituosa, Solicitação de Funcionalidade, Não Reprodutível, Pergunta, Funcionando Conforme Projetado e Versão Errada) e uma metodologia para subclassificação automatizada.
2. Geração de Correções Sem Código: Uma abordagem inovadora para gerar automaticamente soluções acionáveis e não invasivas para relatórios inválidos.
3. Avaliação Abrangente: Uma avaliação rigorosa de como informações prévias (subclasses) e engenharia de contexto (RAG, busca web) afetam tanto a precisão da classificação quanto a qualidade da geração de correções.
4. Novo Benchmark: A introdução de um benchmark padrão-ouro contendo relatórios de bugs inválidos, suas subclasses de causa raiz e correções sem código verificadas, preenchendo uma lacuna em conjuntos de dados existentes que carecem de rotulagem explícita de subclasses e avaliação da qualidade da correção.

Resultados Experimentais
O estudo avaliou o desempenho usando F1-Score Ponderado para subclassificação e uma combinação de BERTScore e taxas de sucesso do Judge LLM para geração de correções sem código.

• Subclassificação (RQ1):

  • RAG alcançou o melhor desempenho geral com um F1 Ponderado de 0,66, superando ligeiramente os LLMs Vanilla (0,65) e a Busca Web Agente (0,64).
  • O RAG destacou-se em Não Reprodutibilidade (0,85 F1) e Problemas de Sistema Externo e Dependência (0,67 F1).
  • Versão Errada permaneceu a subclass mais desafiadora em todos os métodos, com pontuações variando de 0,00 a 0,29.
  • A Busca Web Agente mostrou utilidade específica para a categoria Versão Errada (melhorando a pontuação do Gemini de 0,00 para 0,20) ao acessar dados de versão externos.

• Geração de Correções Sem Código (RQ2):

  • Busca Web Agente alcançou a maior taxa geral de sucesso do Judge LLM em 68,9% (usando Gemini 3.1 Pro), superando o RAG (64,4%) e os LLMs Vanilla (64,9%).
  • A busca agêntica foi particularmente eficaz para as categorias Pergunta (72,2%) e Versão Errada (41,7%), onde o contexto externo é crítico.
  • RAG teve o melhor desempenho para Funcionando Conforme Projetado (88,2% de taxa de sucesso), aproveitando discussões históricas do projeto.
  • O estudo de ablação "Sem Prévios" revelou que fornecer informações de subclasses geralmente melhora o desempenho, embora em casos específicos (por exemplo, Configuração Defeituosa), a remoção de prévios permitiu que os modelos inferissem correções mais diretamente, sem serem distraídos por categorizações rígidas.

Significância e Alegações
O artigo afirma que diferentes componentes são eficazes para diferentes tarefas: RAG é superior para tarefas de subclassificação que exigem contexto histórico e conhecimento específico do projeto, enquanto Busca Web Agente é mais benéfica para gerar correções sem código que exigem informações externas atualizadas (por exemplo, lançamentos de versão, dependências de terceiros).

O estudo conclui que automatizar esse fluxo de trabalho tem o potencial de:

• Reduzir o esforço de triagem manual para suporte ao cliente e desenvolvedores.
• Fornecer orientação imediata e acionável aos usuários dentro dos sistemas de rastreamento de bugs.
• Melhorar a experiência do usuário ao resolver relatórios inválidos sem intervenção humana.

Os autores enfatizam que, embora o BERTScore indique alta similaridade textual, a métrica Judge LLM é mais crítica para avaliar a correção funcional. Eles também observam que a eficácia do framework depende da disponibilidade de dados ricos do projeto (para RAG) e da capacidade do modelo de navegar na busca externa sem alucinações (para Busca Agente). O artigo não afirma resolver todos os relatórios de bugs inválidos, reconhecendo que subclasses como "Versão Errada" e "Configuração Defeituosa" permanecem desafiadoras.