Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis

Imagine que você é um detetive tentando encontrar um único traidor escondido em uma multidão de mil cidadãos inocentes. Seu trabalho é apontar quem é o traidor antes que ele cause qualquer problema. Este é o cotidiano dos engenheiros de software, que atuam como detetives digitais caçando "bugs" ou defeitos em código de computador. No mundo da engenharia de software, essa caçada é chamada de Predição de Defeitos de Software. É um jogo de alto risco onde o objetivo é detectar o código ruim antes que ele quebre o sistema.

Para jogar este jogo, os engenheiros usam programas de computador chamados Modelos de Aprendizado de Máquina (Machine Learning). Pense nesses modelos como assistentes superinteligentes que leram milhões de linhas de código no passado. Eles olham para um novo pedaço de código e dão a ele uma "pontuação de suspeita" entre 0 e 1. Uma pontuação de 0 significa "totalmente inocente", e uma pontuação de 1 significa "culpado como acusado". A parte complicada é decidir onde traçar a linha. Se você definir a linha muito baixa, pode acusar pessoas inocentes (alarmes falsos), desperdiçando o tempo de todos. Se você a definir muito alta, pode deixar o verdadeiro traidor escapar (defeitos perdidos), o que pode ser desastroso. Por muito tempo, a maioria dos detetives usou uma regra padrão: "Se a pontuação for acima de 0,5, é culpado". Mas, como esta nova pesquisa sugere, essa regra padrão pode estar errando o alvo.

---

A Grande Ideia do Artigo: Encontrando a Linha Perfeita

Em seu artigo, "Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis", Nitin Sai Bommi, Umamaheswara Sharma Bhutamapuram e Atul Negi argumentam que a antiga "regra do 0,5" é como usar um chapéu de tamanho único para uma multidão de pessoas com tamanhos de cabeça muito diferentes. Simplesmente não serve para todos.

Os autores propõem uma nova maneira de jogar o jogo. Em vez de confiar cegamente na linha padrão, eles sugerem dois truques inteligentes para encontrar a linha perfeita para cada situação específica. O objetivo deles é maximizar a diferença entre capturar os vilões (Probabilidade de Detecção) e evitar acusações falsas (Probabilidade de Alarme Falso). Eles querem pegar o traidor sem perder tempo com espectadores inocentes.

Truque nº 1: A Mudança da Trave (Limiar Ótimo)

O primeiro truque consiste em ajustar a "linha de suspeita". Os pesquisadores testaram três tipos diferentes de assistentes detetives: Regressão Logística, Naïve Bayes e Redes Neurais. Eles descobriram que o número mágico não era 0,5 para nenhum deles.

• Para o assistente de Regressão Logística, o ponto ideal era em torno de 0,35.
• Para o Naïve Bayes, era ainda mais baixo, em 0,3.
• Para a Rede Neural, era 0,38.

Pense nisso como sintonizar um rádio. Se você deixar o botão no meio, poderá ouvir estática. Mas se você o mover levemente para a esquerda ou para a direita, de repente a música entra clara e cristalina. Ao mover o limiar para baixo (para cerca de 0,3 ou 0,4), esses modelos tornaram-se muito melhores em detectar os defeitos reais, mantendo o número de alarmes falsos baixo. Em seus testes em 36 versões de 10 projetos de software, esse ajuste simples superou consistentemente o método padrão.

Truque nº 2: O Jogo do "E Se?" (Explicações Contrafatuais)

O segundo truque é um pouco mais mágico. Os autores utilizaram algo chamado Explicações Contrafatuais. Imagine que você tem a foto de um suspeito "culpado" (um módulo de código defeituoso). O modelo diz: "Isso é ruim". Agora, imagine que você pudesse perguntar ao modelo: "E se eu mudasse esta pequena coisa? Isso o tornaria inocente?".

Os pesquisadores fizeram exatamente isso. Eles pegaram códigos que o modelo já sabia serem bons ou ruins e perguntaram: "Que pequena mudança transformaria isso de bom para ruim, ou de ruim para bom?". Eles usaram esses cenários de "e se" para criar novos exemplos sintéticos de código. Em seguida, alimentaram esses novos exemplos de volta ao modelo para dar a ele um treinamento extra.

É como um treinador mostrando a um jogador um vídeo de uma jogada perfeita e depois perguntando: "E se você errasse a bola por um centímetro?" e usando isso para ensinar o jogador como se ajustar. O artigo descobriu que esse método ajudou os modelos a entenderem melhor os dados, embora nem sempre tenha superado o truque simples da "mudança da trave".

O Que Eles Descobriram (e o Que Não Descobriram)

Os resultados foram promissores, mas específicos. Os autores mediram seu sucesso usando duas ferramentas principais:

1. Taxa de Omissão Falsa (FOR): Com que frequência eles perderam um defeito real? (Eles queriam que fosse baixa).
2. Percentual de Orçamento Salvo (PSB): Quanto tempo e dinheiro eles economizaram ao não testar o código limpo?

Quando usaram o novo método de "mudança da trave", os modelos tiveram um desempenho melhor do que o método antigo. Por exemplo, com o modelo de Regressão Logística, o limiar ótimo médio foi de 0,35, e ele reduziu significamente a taxa de defeitos perdidos em comparação com o limiar padrão de 0,5.

No entanto, os autores são cuidadosos ao não chamar isso de uma solução mágica. Eles afirmam explicitamente que, embora esses métodos melhorem o equilíbrio entre capturar bugs e evitar alarmes falsos, eles não resolvem tudo. O método contrafatual (o jogo do "e se") ajudou, mas nem sempre apresentou os melhores resultados porque o modelo não é perfeito ao gerar esses exemplos falsos em primeiro lugar.

Eles também apontam que suas descobertas baseiam-se em conjuntos de dados específicos (repositório PROMISE) e podem parecer diferentes se aplicadas a tipos totalmente diferentes de projetos de software. Eles não provaram que isso funciona para todo software no universo, mas mostraram que, para os projetos que testaram, afastar-se da regra padrão de 0,5 é uma decisão inteligente.

Por Que Isso Importa

Este artigo é um lembrete de que, no mundo do software, o "tamanho único" é frequentemente uma armadilha. A maneira padrão de decidir o que é um bug e o que não é pode ser rígida demais. Ao simplesmente perguntar ao computador: "Qual é a melhor linha para desenhar para este trabalho específico?" e ao usar perguntas de "e se" para aprender mais, podemos construir softwares que são mais seguros e mais baratos de manter. É uma pequena mudança de perspectiva, mas para os detetives que caçam bugs na escuridão digital, pode ser justamente a lanterna que eles precisavam.