Multi-stage Dynamic Selection for Cross-Project Defect Prediction

Imagine que você é um detetive tentando resolver um mistério, mas nunca viu a cena do crime antes. Você tem apenas uma pilha de arquivos de casos antigos de cidades completamente diferentes, escritos por diferentes forças policiais com diferentes gírias e hábitos. Seu trabalho é prever onde o próximo criminoso atacará em sua nova cidade. Este é o esforço diário de engenheiros de software tentando manter seus programas livres de erros. Eles querem encontrar "defeitos" (bugs) em seu código antes que o software trave, mas muitos novos projetos são como telas em branco: ainda não rodaram há tempo suficiente para construir um histórico de erros. Por isso, os engenheiros tentam aprender com outros projetos, esperando que o que funcionou em uma empresa de videogames ajude a corrigir um aplicativo bancário. Isso é chamado de Predição de Defeitos entre Projetos (Cross-Project Defect Prediction). O problema é que cada projeto é único; um modelo que funciona perfeitamente em um pode falhar miseravelmente em outro porque as "cenas do crime" (o código) são tão diferentes.

Apresentamos uma nova equipe de detetives digitais chamada Multi-DES. Em vez de contratar um único detetive para resolver todos os casos na nova cidade, ou forçar um "super-detetive" a tentar entender todos os bairros de uma só vez, esta equipe usa uma estratégia inteligente de duas etapas. Primeiro, eles fazem uma audição para uma multidão massiva de diferentes detetives, cada um com seu próprio estilo e kit de ferramentas único, para ver qual grupo de especialistas trabalha melhor ao analisar arquivos de casos antigos. Em seguida, quando um novo caso chega, eles não apenas escolhem um detetive. Em vez disso, eles observam os detalhes específicos desse novo caso e chamam instantaneamente o especialista melhor para aquela situação específica. É como ter uma equipe de especialistas onde um policial de trânsito cuida de um acidente de carro, um contador forense cuida de um caso de fraude e um negociador cuida de uma situação de reféns, todos escolhidos na hora. Os pesquisadores descobriram que essa abordagem de "o especialista certo para o momento certo" é muito melhor para encontrar bugs em novos projetos desconhecidos do que os métodos antigos que tentavam usar a mesma solução única para tudo.

A Agência de Detetives: Como o Multi-DES Funciona

No mundo do software, um "defeito" é um bug — um erro no código que pode fazer o programa travar ou agir de forma estranha. Prever esses bugs é crucial porque encontrá-los cedo economiza tempo e dinheiro. Mas aqui está o detalhe: para ensinar um computador a detectar um bug, você geralmente precisa de muitos exemplos passados de bugs. Novos projetos ainda não possuem esses exemplos. Por isso, os engenheiros tentam pegar emprestado o conhecimento de outros projetos mais antigos. Esta é a parte "Cross-Project" (entre projetos).

No entanto, há um grande obstáculo: o Deslocamento de Distribuição (Distribution Shift). Pense nisso como tentar aprender a dirigir em um país onde todos dirigem pelo lado esquerdo, usando apenas um manual escrito para um país onde todos dirigem pelo lado direito. As regras são semelhantes, mas os detalhes são invertidos. No software, um projeto pode usar um estilo de codificação específico, enquanto outro usa um completamente diferente. Os métodos tradicionais tentam construir um modelo gigante que tenta entender todas essas diferenças de uma só vez. Os autores deste artigo argumentam que isso é como tentar usar um mapa genérico para todas as cidades do mundo; é amplo demais e perde as ruas locais.

O artigo propõe o Multi-DES (Seleção de Ensemble Dinâmico Multi-estágio), que é um pouco como uma agência de contratação inteligente e adaptável para detetives de software. Ele opera em duas etapas principais:

Estágio 1: A Grande Audição (Nível de Projeto)
Antes que o sistema veja o novo projeto, ele passa por uma fase massiva de "superprodução". Imagine um teste de elenco onde eles experimentam todas as combinações possíveis de:

• Classificadores Base: Diferentes tipos de algoritmos (como Árvores de Decisão, Florestas Aleatórias, etc.). Pense neles como diferentes tipos de detetives (o observador, o lógico, o que identifica padrões).
• Técnicas de Seleção Dinâmica: Diferentes formas de decidir em qual detetive confiar.
• Tamanhos de Pool: Quantos detetives estão na sala.

Eles testam todas essas combinações (4 algoritmos base × 8 técnicas de seleção × 10 tamanhos de pool = 320 configurações diferentes) em um conjunto de projetos de "treinamento". Mas eles não escolhem apenas aquele que obteve a pontuação mais alta em um único teste. Em vez disso, utilizam uma estratégia chamada Minimização de Ranking Agregado (ARM).

A Estratégia ARM: O Juiz "Polivalente"
Imagine um show de talentos onde você tem que escolher um vencedor baseado em canto, dança e atuação. Se você escolher apenas a pessoa com a melhor voz, ela pode ser terrível na atuação. O ARM é como um juiz que classifica cada candidato em todas as três habilidades e, então, soma seus rankings para encontrar a pessoa que é o polivalente mais consistente. O artigo sugere que, ao observar múltiplas métricas de desempenho (como F1-score, AUC e Falso Alarme) juntas, o sistema encontra uma configuração que é robusta e não falhará quando o novo projeto for diferente dos antigos.

Estágio 2: A Seleção em Tempo Real (Nível de Módulo)
Uma vez que a melhor configuração de "audição" é escolhida, o sistema está pronto para o novo projeto. Mas aqui está a mágica: ele não aplica apenas um modelo a todo o projeto. O software é feito de muitos "módulos" (como quartos individuais em uma casa ou capítulos em um livro).

Quando o sistema observa um módulo específico no novo projeto, ele pergunta: "Qual dos nossos detetives treinados é o melhor para detectar bugs neste tipo específico de código?" Ele seleciona dinamicamente os classificadores mais competentes para aquele pedaço de código específico. Se um módulo parece um aplicativo bancário, ele escolhe o "especialista em finanças" de seu pool. Se outro módulo parece um motor de jogo, ele escolhe o "especialista em gráficos". Isso acontece em tempo real, para cada peça de código.

O Que Eles Descobriram

Os pesquisadores testaram essa ideia em 82 projetos de software de quatro conjuntos de dados públicos diferentes (PROMISE, RELINK, NASA e AEEEM). Eles usaram um método de teste rigoroso chamado "deixar um projeto de fora" (leave-one-project-out), o que significa que treinaram em 81 projetos e tentaram prever os bugs no 82º, repetindo o processo para cada projeto.

Os resultados foram bastante promissores:

• Melhor que o Melhor: O Multi-DES superou ou igualou os principais métodos existentes na maioria dos cenários. Especificamente, alcançou os melhores resultados para as métricas de AUC (uma medida de quão bem o modelo distingue entre código com erro e código limpo) e Falso Alarme (com que frequência ele dá alarmes falsos) na maioria dos conjuntos de dados.
• Os Números: No conjunto de dados AEEEM, o Multi-DES obteve um AUC de 0,755, superando o segundo melhor método (EASC-NB), que obteve 0,692. No conjunto de dados NASA, obteceu 0,737 comparado a 0,666.
• Robustez: O sistema foi particularmente bom em manter os "Falsos Alarmes" baixos, o que significa que não desperdiçou o tempo dos engenheiros verificando códigos que estavam, na verdade, corretos.
• Sem Trapaça: Crucialmente, o sistema fez isso sem olhar para nenhum dado do novo projeto alvo durante a fase de treinamento. Ele dependeu inteiramente dos projetos antigos, provando que você não precisa espiar os segredos do novo projeto para construir um bom preditor.

O Que Eles Descartaram

O artigo argumenta explicitamente contra a ideia de que um modelo único e estático (um conjunto fixo de regras aplicado a todo o projeto) seja a melhor solução. Eles mostram que, como diferentes partes de um projeto de software têm características diferentes, uma abordagem de "tamanho único" falha em generalizar bem quando o novo projeto é diferente dos dados de treinamento. Eles também descartaram a ideia de que você precise conhecer a distribuição de dados do projeto alvo antecipadamente para fazer boas previsões; o método deles funciona mesmo quando o projeto alvo é um completo mistério.

Quão Certos Eles Estão?

Os autores estão confiantes em suas descobertas com base nos dados coletados. Eles não apenas simularam cenários; eles realizaram experimentos extensos em 82 projetos reais usando métricas padrão e amplamente aceitas. Eles usaram testes estatísticos (o teste de postos sinalizados de Wilcoxon) para confirmar que seus resultados não foram apenas sorte. O artigo afirma que o Multi-DES é "estatisticamente superior" na maioria das comparações pareadas, particularmente para AUC e Falso Alarme. No entanto, eles observam uma pequena exceção: no conjunto de dados PROMISE, o método deles não foi o melhor absoluto para a métrica de "Falso Alarme", mostrando que, embora o método seja forte, não é uma bala de prata que vence todas as vezes em todos os cenários.

Em suma, o Multi-DES sugere que a melhor maneira de prever bugs em um novo projeto desconhecido é ter uma equipe diversificada de especialistas prontos para serem convocados e escolher o especialista certo para o trabalho em questão, em vez de tentar forçar um generalista para fazer tudo.