Resumo Técnico: Instabilidade de Modelo em Otimização de Engenharia de Software

1. Definição do Problema

Na análise de software, executar a mesma análise novamente em dados idênticos frequentemente resulta em modelos e conclusões diferentes. Este fenômeno, denominado instabilidade de modelo, mina a confiança nas ferramentas de engenharia de software (ES) e limita sua adoção prática. Embora a literatura anterior tenha reconhecido a instabilidade em domínios específicos (ex: predição de defeitos, mineração de texto, descoberta causal), ela é frequentemente tratada como um "bug" a ser corrigido com mais dados ou ensembling, ou descartada como ruído inevitável.

Este artigo argumenta que a instabilidade não é meramente um ruído a ser tolerado, mas uma propriedade que pode ser medida e gerenciada. Os autores distinguem dois tipos de instabilidade:

• Instabilidade Estrutural: Variação na forma do modelo, recursos utilizados e topologia da árvore (ex: diferentes árvores de decisão geradas a partir dos mesmos dados).
• Instabilidade de Desempenho: Variação nos resultados ou recomendações produzidos pelos modelos (ex: diferentes configurações otimizadas previstas).

O artigo postula que a instabilidade estrutural é frequentemente uma propriedade fundamental dos dados (o "Efeito Rashomon", onde muitos modelos estruturalmente diferentes se ajustam aos dados igualmente bem) e pode ser irredutível. No entanto, a instabilidade de desempenho é o problema crítico para os profissionais, pois determina se uma única execução de um otimizador pode ser confiada para fornecer recomendações consistentes.

2. Metodologia

O estudo emprega uma abordagem empírica de larga escala utilizando o repositório MOOT, uma coleção de 127 problemas de otimização de ES multiobjetivo.

Dados e Escopo

• Datasets: 127 conjuntos de dados abrangendo configurações de software, saúde do projeto, predição de defeitos, testes e análise comportamental.
• Escala: 12.700 casos de teste retidos (held-out) em todos os datasets.
• Aprendiz (Learner): O aprendiz principal é o EZR, um otimizador de aprendizado ativo de última geração que constrói árvores de decisão a partir de um orçamento limitado de rotulagem.
• Design Experimental: Cada configuração é repetida 20 vezes com diferentes sementes aleatórias para medir a variância.

Métricas

1. Estabilidade de Desempenho: Medida pela taxa de concordância (porcentagem de casos de teste onde 20 execuções repetidas produzem previsões suficientemente similares) e pelo desvio padrão do erro de otimização (distância ao paraíso/distance-to-heaven).
2. Estabilidade Estrutural: Medida usando similaridade de Jaccard ponderada de conjuntos de recursos entre árvores de decisão, ponderando os recursos pela sua profundidade na árvore.
3. Qualidade de Otimização: Avaliada via "distância ao paraíso" (d2h) e contagens estatísticas de topo de ranking em datasets.

Intervenções

Os autores testaram sistematicamente seis fatores para determinar seu impacto na instabilidade:

1. Orçamento de Rotulagem: O número de exemplos rotulados disponíveis (10 a 200).
2. Estratégia de Aquisição: Regras para selecionar quais dados rotular a seguir (ex: near, Xplor, Xploit, adapt).
3. Complexidade do Modelo: Tamanho mínimo da folha em árvores de decisão.
4. Critério de Divisão (Splitting): Entropia vs. impureza de Gini.
5. Intervenções Inspiradas em Causalidade: Filtragem de confundidores e divisão por Razão de Ganho (Gain-Ratio).
6. Localidade de Dados: Uso de agrupamento (KMeans, HDBSCAN, CURE) para particionar dados heterogêneos antes da modelagem.

3. Contribuições Principais e Resultados

RQ0: Prevalência de Instabilidade de Desempenho

Sob configurações padrão, execuções repetidas do otimizador concordaram em apenas 2,9% dos casos de teste (364 de 12.700). Mesmo com um limiar altamente permissivo, a concordância raramente excedeu 31,7%. Isso confirma que a instabilidade de desempenho é a norma, não a exceção, tornando as recomendações de uma única execução não confiáveis.

RQ1: Natureza da Instabilidade (Estrutural vs. Desempenho)

O estudo descobriu que a instabilidade estrutural e de desempenho são desacopladas.

• Achado: Mudanças de configuração que melhoraram drasticamente a estabilidade de desempenho (aumentando a concordância de 2,9% para 13,7%) tiveram quase nenhum efeito na similaridade estrutural. As árvores permaneceram estruturalmente diversas.
• Implicação: Os profissionais não devem esperar a mesma estrutura de modelo todas as vezes. A confiança deve ser baseada em recomendações consistentes, não em formas de modelo idênticas. A instabilidade estrutural é amplamente irredutível devido ao efeito Rashomon.

RQ2: Vetores e Correções

Os autores identificaram quatro fatores de configuração chave que impulsionam a instabilidade de desempenho e propuseram uma configuração refinada que melhora a estabilidade sem sacrificar a qualidade:

1. Orçamento de Rotulagem: Aumentar de 20 para 50 rótulos melhorou a estabilidade, mas os ganhos saturaram além de 50.
2. Estratégia de Aquisição: Mudar de Xploit (ganancioso) para near (selecionando candidatos mais próximos do atual centroide) gerou os ganhos de estabilidade mais significativos (estabilidade de topo de ranking aumentou de <50% para >80%) sem custo.
3. Complexidade do Modelo: Um tamanho mínimo de folha de 3 ofereceu o melhor equilíbrio entre estabilidade, desempenho e interpretabilidade.
4. Critério de Divisão: Mudar de Entropia para impureza de Gini proporcionou um ganho "gratuito" em estabilidade, já que a Entropia é altamente sensível a eventos raros sob orçamentos apertados.

Resultos da Configuração Refinada:

• Concordância: Aumentou de 2,9% para 13,7% (uma melhoria de 4,8×).
• Variância do Erro: Reduziu o desvio padrão do erro de otimização em 22% (média do desvio de 17,4 para 13,6).
• Qualidade: As configurações refinadas alcançaram qualidade de otimização estatisticamente no topo do ranking em 119 de 127 datasets, comparado a 74 para os padrões.

RQ3: Limites da Estabilidade

O estudo investigou se a instabilidade restante era devida ao aprendiz ou aos dados.

• Intervenções Causais: Adicionar filtros de confundidores e raciocínio causal ajudou apenas em datasets específicos onde recursos confundidos impulsionavam a instabilidade, mas não ofereceu melhoria global significativa.
• Localidade de Dados: Métodos de agrupamento (as famílias de modelos mais estáveis) concordaram em menos de 51% dos casos de teste.
• Conclusão: Existe um "piso de estabilidade", definido pelos próprios dados (ruído, rótulos escassos, objetivos de proxy e a existência de muitos modelos quase equivalentes). Nenhuma intervenção do lado do aprendiz pode eliminar totalmente essa instabilidade residual.

4. Significância e Alegações

O artigo afirma que a instabilidade de modelo deve ser tratada como um eixo de avaliação padrão em Engenharia de Software Baseada em Busca (SBSE), sendo rotineiramente medida e reportada junto com métricas de desempenho.

• Reenquadramento do Objetivo: O objetivo não é forçar execuções repetidas a produzir árvores idênticas (o que é frequentemente impossível devido ao efeito Rashomon), mas garantir que elas produzam recomendações consistentes.
• Linha de Base Acionável: As configurações refinadas propostas (50 rótulos, aquisição near, folha mín=3, divisão Gini) fornecem uma linha de base contra a qual futuros esforços para reduzir a instabilidade em SBSE podem ser julgados.
• Orientação Prática:
  1. Ferramentas de ES devem se afastar de padrões instáveis (divisão por Entropia, aquisição gananciosa).
  2. Artigos empíricos devem reportar taxas de concordância, não apenas a média de desempenho, para revelar discordâncias entre execuções.
  3. Pesquisadores devem evitar perseguir a estabilidade estrutural por si só e reconhecer que a instabilidade tem múltiplas causas que exigem correções compostas em vez de uma única "solução mágica".

Os autores concluem que, embora a instabilidade não possa ser totalmente eliminada, ela pode ser gerenciada a um nível onde os profissionais possam calibrar sua confiança em qualquer execução individual de uma ferramenta de otimização.