Resumo Técnico: Avaliando Modelos de Linguagem para Identificação de Classes Salientes

Declaração do Problema

A revisão de código é uma prática crítica para manter a qualidade do software, mas torna-se significativamente desafiadora quando um único commit modifica múltiplas classes. Nesses cenários, os revisores devem reconstruir a intenção geral da mudança a partir de fragmentos de modificação dispersos. Para auxiliar os revisores, o conceito de Classes Salientes foi introduzido: uma ou mais classes primariamente modificadas que impulsionam a intenção central de um commit e induzem modificações em outras classes (frequentemente referidas como "efeitos de propagação" ou ripple effects).

A identificação automatizada precisa dessas classes salientes é difícil. As abordagens atuais de estado da arte (SOTA), como ISC e GBSCI, dependem de procedimentos complexos de análise de programa. Esses métodos exigem o parsing de Árvore de Sintaxe Abstrata (AST), extração de relações entre classes, construção de grafos de dependência e engenharia de atributos (feature engineering) manual. Essas dependências criam barreções significativas: elas falham em repositórios com builds incompletos ou linguagens mistas, incorrem em altos custos para adaptação a novas linguagens e dificultam a integração em fluxos de trabalho de revisão leves.

Este artigo investiga se Modelos de Linguagem (LMs), especificamente Grandes Modelos de Linguagem (LLMs) e Pequenos Modelos de Linguagem (SLMs), podem identificar classes salientes diretamente de diffs de código bruto sem engenharia de atributos, construção de grafos ou treinamento supervisionado.

Metodologia

Construção do Dataset: ApacheJavaCM

Para avaliar os LMs, os autores construíram um novo dataset, o ApacheJavaCM, derivado do dataset ApacheCM.

• Escopo: Limitado a projetos Java para garantir compatibilidade com baselines existentes (que dependem de parsing de AST Java) e para manter a consistência com configurações de pesquisas anteriores.
• Regras de Rotulagem: Uma classe é rotulada como saliente (positiva) se seu nome for explicitamente mencionado na mensagem do commit. Classes modificadas no commit, mas não mencionadas na mensagem, são rotuladas como não-salientes (negativas).
• Pipeline de Filtragem: O dataset passou por um processo de filtragem de 8 etapas para excluir commits sem classes Java, commits onde todas as classes foram mencionadas (casos degenerados) e commits que careciam de um contraste claro entre amostras positivas e negativas.
• Estatísticas Finais: O dataset contém 7.911 commits e 25.914 classes rotuladas (8.382 positivas, 17.532 negativas), com uma média de 3,276 classes por commit.

Design Experimental

O estudo avaliou sistematicamente o desempenho dos LMs contra dois baselines:

1. Most-Modified-Class: Um baseline heurístico que seleciona a classe com o maior número de linhas modificadas.
2. ISC: O baseline SOTA reprodutível mais forte, baseado em análise estática e classificação de floresta aleatória (random forest).

Modelos Avaliados:

• LLMs: GPT-5.4 (Código fechado) e DeepSeek-V3.2 (Código aberto).
• SLM: Qwen3.5-9B (Código aberto, 9B parâmetros).

Estratégias de Prompting:

• Zero-shot: Definição direta da tarefa e da definição de classe saliente.
• Few-shot: Inclusão de dois exemplos rotulados para demonstrar a distinção entre classes salientes e efeitos de propagação.
• Chain-of-Thought (CoT): Etapas de raciocínio explícito exigindo que o modelo liste as mudanças, infira a intenção e separe causas de consequências antes de produzir a resposta.

Métricas de Avaliação:
Dada a disparidade de classes (aprox. 1:2.1), o estudo priorizou a Acurácia do Commit (CmtAccuracy) (um commit é correto apenas se todas as suas classes modificadas forem classificadas corretamente) e o Coeficiente de Correlação de Matthews (MCC). Outras métricas incluíram Precisão, Recall, Acurácia e F1 score.

Principais Contribuições

1. Primeiro Estudo Empírico Sistemático: Este trabalho fornece a primeira avaliação abrangente de LMs (tanto LLMs quanto SLMs) para identificação de classes salientes diretamente de diffs de código, contornando a análise estática.
2. Novo Benchmark (ApacheJavaCM): A construção de um dataset curado de 7.911 commits com 25.914 classes rotuladas, especificamente desenhado para esta tarefa e compatível com baselines Java existentes.
3. Avaliação Abrangente: Uma análise minuciosa cobrindo nove configurações (3 modelos × 3 estratégias de prompting) através de três dimensões de características de commit (total de classes, contagem de classes salientes e comprimento de tokens do diff).
4. Análise Qualitativa de Falhas: Uma investigação detalhada das causas raízes dos erros dos LMs, categorizando-os em problemas de dependência implícita, difusão de atenção em diffs longos e confusão entre causas raiz e implementações reativas.

Resultados

Desempenho vs. Baselines (RQ1)

• Superioridade dos LMs: Todos os três LMs superaram substancialmente tanto o baseline heurístico quanto o baseline SOTA ISC em todas as métricas.
• Magnitude da Melhoria: Mesmo o LM mais fraco (DeepSeek-V3.2) melhorou o baseline ISC em 18,52% em CmtAccuracy e 26,19% em MCC.
• Eficiência: Diferente do ISC, que requer parsing de AST e extração de atributos, os LMs alcançaram esses resultados usando apenas diffs de código bruto.

Impacto da Seleção de Modelo e Prompting (RQ2)

• LLM vs. SLM: O SLM de 9 bilhões de parâmetros de código aberto (Qwen3.5-9B) alcançou um desempenho comparável ao LLM de código fechado (GPT-5.4). Sob prompting few-shot, o Qwen3.5-9B atingiu uma CmtAccuracy de 0,7232, quase igualando os 0,7204 do GPT-5.4.
• Estratégias de Prompting:
  • LLMs (GPT-5.4, DeepSeek-V3.2): O desempenho foi relativamente estável entre as estratégias zero-shot, few-shot e CoT. O CoT não melhorou os resultados de forma consistente.
  • SLM (Qwen3.5-9B): Beneficiou-se significativamente do prompting few-shot, alcançando seus melhores resultados com esta estratégia. O CoT resultou, na verdade, no menor desempenho para o SLM.
• Implicação: SLMs leves e implantáveis localmente são suficientes para esta tarefa, oferecendo uma alternativa prática aos LLMs de código fechado para reduzir custos e riscos de privacidade.

Impacto das Características do Commit (RQ3)

• Total de Classes: O desempenho não declinou monotonicamente com o número de classes. Em vez disso, seguiu um padrão em forma de U, sendo que commits de tamanho médio (5–10 classes) foram os mais desafiadores.
• Contagem de Classes Salientes: O desempenho caiu significativamente conforme o número de classes salientes por commit aumentava. Commits com múltiplas classes salientes continuam sendo um desafio primário para todos os métodos.
• Comprimento de Tokens do Diff: À medida que o comprimento do diff aumentava, a CmtAccuracy declinava (monotonicamente), indicando que diffs mais longos tornam mais difícil identificar o conjunto completo de classes salientes, provavelmente devido à difusão de atenção.

Análise de Falhas (RQ4)

A análise qualitativa identificou três modos principais de falha:

1. Dependência Implícita: Os LMs perderam classes raiz quando as dependências não estavam explícitas no diff, frequentemente selecionando classes de downstream com maiores volumes de modificação em vez disso.
2. Difusão de Atenção: Em diffs longos, sinais semânticos cruciais foram diluídos por formatação ou mudanças periféricas, fazendo com que o modelo perdesse classes críticas.
3. Confusão de Implementação Reativa: Os LMs confundiram o "portador da reparação" (repair carrier - classes modificadas para implementar um conserto) com a "causa raiz" (root cause - a classe que motivou a mudança).

Significância e Alegações

O artigo afirma que Modelos de Linguagem representam uma alternativa viável e leve aos métodos tradicionais de análise estática para identificação de classes salientes. As principais conclusões incluem:

• Viabilidade: LMs podem identificar classes salientes diretamente de diffs de código sem o overhead de análise estática ao nível do repositório, construção de grafos ou treinamento supervisionado.
• Praticidade de SLMs: SLMs de código aberto (ex: Qwen3.5-9B) podem alcançar desempenho comparável a grandes LLMs de código fechado, tornando-os adequados para implantação industrial onde custos e privacidade de dados são preocupações.
• Limitações: Embora eficazes, os LMs ainda enfrentam dificuldades com commits que contêm múltiplas classes salientes ou diffs muito longos, e carecem do contexto estrutural (ex: grafos de chamada) que a análise estática fornece para resolver dependências implícitas.

Os autores concluem que, embora os LMs ofereçam um avanço significativo na redução de custos de configuração e melhoria da acessibilidade para ferramentas de revisão de código, trabalhos futuros devem explorar a integração de contexto de programa estruturado (como grafos de chamada) para abordar os modos de falha restantes.