Resumo Técnico: Explicando o Risco de Mudanças de Código usando Modelos de Predição Baseados em LLM

Declaração do Problema

No desenvolvimento de software em larga escala, sistemas de predição de defeitos Just-in-Time (JIT), como o Diff Risk Score (DRS), são usados para prever a probabilidade de uma mudança de código (diff) causar uma interrupção de serviço. Enquanto modelos tradicionais, como a regressão logística, oferecem certa explicabilidade por meio de coeficientes de características, eles têm dificuldade em utilizar o rico conteúdo textual das mudanças de código. Por outro outro lado, os Grandes Modelos de Linguagem (LLMs) demonstraram uma precisão superior na predição de risco, mas operam como "caixas pretas", fornecendo apenas um escore de risco sem uma justificativa acionável.

Essa falta de explicabilidade cria barreiras significativas para a adoção: engenheiros não conseguem determinar facilmente por que um diff foi sinalizado, o que leva à redução da confiança, ceticismo e dificuldade em estreitar os esforços de inspeção. Sem uma orientação clara, avisos de alto risco são frequentemente ignorados, ou os engenheiros são forçados a escanear manualmente diffs inteiros, comprometendo a produtividade. O desafio central é tornar as predições de risco baseadas em LLM acionáveis, identificando partes específicas de uma mudança de código que mais contribuem para o risco predito, sem introduzir alucinações ou latência excessiva.

Metodologia

Os autores propõem uma abordagem pragmática de explicabilidade que aproveita os mecanismos de atenção interna de um LLM durante a inferência padrão. A metodologia envolve três estágios primários:

1. Predição de Risco Baseada em LLM:

   • Um LLM pré-treinado (especificamente o Llama3-70B, ajustado por instrução em diffs históricos) é usado para classificar se um diff pode causar uma interrupção.
   • O modelo recebe um prompt contendo o conteúdo do diff e é instruído a gerar uma resposta de um único token (0 ou 1).
   • O escore de risco é derivado dos logits deste token de saída.

2. Extração e Agregação de Atenção:

   • Durante a inferência, o modelo gera um tensor de atenção que representa a correlação entre o token de saída e os tokens de entrada.
   • Os pesos de atenção são agrupados entre as cabeças de atenção para criar um vetor de importância por nível de token.
   • Os autores declaram explicitamente que não reivindicam fidelidade causal entre atenção e raciocínio; em vez disso, a atenção serve como um sinal de proxy prático para destacar regiões de código relevantes.

3. Agrupamento Hierárquico de Tokens e Mapeamento:

   • Para tornar os pesos de nível de token interpretáveis para desenvolvedores, o sistema os mapeia de volta para as unidades padrão de revisão de código: Linhas, Hunks (blocos contíguos de mudanças) e Arquivos.
   • Uma hierarquia de quatro níveis é construída:
     • Reconstituição de Tokens: Tokens de subpalavras (ex: de SentencePiece ou Tiktoken) são mesclados de volta em tokens delimitados por espaços em branco.
     • Recuperação de Estrutura: Tokens de nova linha e cabeçalhos de unified-diff (@@ ... @@) são usados para reconstruir a estrutura de arquivo e hunk.
     • Agregação de Escores: Os escores de atenção são agregados de baixo para cima. Para tokens folha, os escores são calculados pela média. Para nós internos (linhas, hunks, arquivos), funções de agregação específicas são aplicadas. Notavelmente, no nível de hunk, utiliza-se uma soma top-$k$ para capturar sinais concentrados enquanto limita a influência de hunks grandes.
   • Poda (Pruning): Para reduzir o ruído, os escores de tokens dentro de arquivos de teste (identificados via padrões de regex) são anulados, pois mudanças em testes raramente são a causa raiz de interrupções.

4. Saída:

   • O sistema apresenta as $K$ unidades com as maiores pontuações (ex: os top-2 hunks) ao desenvolvedor dentro da interface de revisão de código como um "orçamento de revisão", direcionando a atenção para as regiões mais suspeitas.

Principais Contribuições

• Sinal de Destaque Pragmático: O artigo introduz um método para converter os pesos de atenção de LLM em destaques de código acionáveis (linhas, hunks, arquivos) sem exigir treinamento adicional do modelo ou gerar explicações em linguagem natural potencialmente alucinadas.
• Estrutura de Agregação Hierárquica: Um pipeline inovador que reconstitui subpalavras de tokens e agrega recursivamente os escores de atenção através de granularidades de arquivo, hunk e linha, acomodando diferentes comportamentos de tokenização.
• Validação Industrial: A abordagem é avaliada em um contexto industrial de larga escala (FAANGCompany) usando um conjunto de dados de Causa Raiz de Interrupção (O-RC) curado manualmente, onde especialistas de domínio identificaram as linhas específicas responsáveis por interrupções reais.
• Escalabilidade: Como a atenção é computada como um subproduto da inferência padrão, o método adiciona latência mínima e é viável para fluxos de trabalho de revisão de código de alto rendimento.

Resultados Experimentais

O estudo avaliou a eficácia do método de destaque usando o conjunto de dados O-RC, medindo a Cobertura (a porcentagem de diffs onde as unidades destacadas contêm as linhas de causa raiz real) e o Percentual Médio de Revisão (ARP) (a porcentagem do total de linhas alteradas que um desenvolvedor deve revisar).

• Trocas de Granularidade (Trade-offs):
  • Nível de Linha: Destacar as 30 linhas superiores alcançou 53,85% de cobertura, mas exigiu a revisão de 22,8% do diff.
  • Nível de Arquivo: Destacar os 3 arquivos superiores alcançou 92,30% de cobertura, mas exigiu a revisão de 78,61% do diff, o que é frequentemente muito vago para depuração acionável.
  • Nível de Hunk: Destacar os 2 melhores hunks alcançou 53,85% de cobertura enquanto exigiu que os desenvolvedores revisassem apenas 26,28% das linhas alteradas, em média.
• Configuração Ótima: Os autores concluem que o destaque de nível de hunk (top-2) oferece o melhor equilíbrio entre cobertura e esforço do desenvolvedor. Ele se alinha à forma como os engenheiros revisam diffs naturalmente (inspecionando hunks) e evita a sobrecarga de troca de contexto de destaques de linhas espalhados ou o volume excessivo de destaques de nível de arquivo.
• Feedback do Usuário: O feedback qualitativo inicial de 55 usuários (48 negativos, 7 positivos) destacou modos de falha específicos, como destacar arquivos de teste (apesar do filtro) e código boilerplate, ou ambiguidade direcional onde a atenção pode indicar baixo risco em vez de alto risco.

Significância e Alegações

O artigo posiciona este trabalho como um estudo preliminar que visa preencher a lacuna entre as predições de alta precisão de LLM e a necessidade de confiança e acionabilidade do engenheiro.

• Acionabilidade: A principal alegação é que a atenção agregada fornece um sinal de baixa latência e escalável que estreita a inspeção para um pequeno número de regiões de código, tornando as predições de defeitos JIT acionáveis para engenheiros profissionais.
• Melhoria sobre o Baseline: A abordagem melhora mensuravelmente o baseline de produção atual de "sem destaque", onde os engenheiros recebem um escore de risco sem contexto.
• Confiança e Adoção: Ao fornecer um guia visual de onde olhar, o método visa aumentar a confiança no modelo DRS e ajudar engenheiros a mitigar os riscos associados às suas mudanças.
• Modéstia: Os autores reconhecem explicitamente as limitações, incluindo o potencial para os pesos de atenção serem influenciados pela estrutura do prompt em vez da semântica, a incompletude da filtragem de arquivos de teste e o fato de o estudo representar um recorte temporal. Eles não alegam que a atenção equivale ao raciocínio causal, mas sim que serve como um heurístico útil para priorizar a revisão humana.

O trabalho demonstra que, em um ambiente de alto risco e larga escala, o destaque simples baseado em atenção pode apoiar efetivamente modelos de risco complexos baseados em LLM, permitendo sua implementação mais ampla em ambientes industriais.