Resumo Técnico: Avaliação de Risco de Implantação Usando Recursos Sensíveis a Diferenças (Diff-Aware)

Declaração do Problema

Na Amazon Prime Video, gerenciar implantações de código durante eventos ao vivo (ex: NFL Thursday Night Football) e lançamentos rápidos de funcionalidades apresenta um desafio operacional crítico. Os mecanismos atuais de controle de mudanças dependem de "congelamentos de implantação generalizados" que bloqueiam todas as alterações, independentemente do risco, para evitar interrupções no serviço. Embora eficazes para a segurança, esses congelamentos criam um trabalho manual (toil) significativo para os desenvolvedores, atrasam o lançamento de recursos e acumulam mudanças pendentes.

Pesquisas existentes sobre previsão de defeitos Just-in-Time (JIT) frequentemente dependem de metadados específicos do desenvolvedor (ex: níveis de experiência) ou de dados históricos extensos do projeto. Essas dependências levantam preocupações de privacidade, dificultam a adoção por diversas equipes e limitam a aplicabilidade em novos projetos ou cenários de "cold-start" (início a frio), onde os dados históricos não estão disponíveis. Além disso, muitos modelos carecem de generalização entre diferentes linguagens de programação e contextos organizacionais. O desafio central é determinar quais mudanças específicas de código justificam cautela sem depender de congelamentos longos e genéricos baseados em eventos ou de metadados sensíveis.

Metodologia

Os autores propõem uma estrutura de avaliação de risco sensível a diferenças (diff-aware) que deriva recursos diretamente das modificações de código (diferenças), em vez de depender do histórico ou metadados do desenvolvedor. A metodologia consiste em três estáveis principais:

1. Coleta de Dados

• Verdade Fundamental (Ground Truth): A equipe vinculou relatórios de Correção de Erro (CoE) — revisões pós-incidente obrigatórias — aos commits específicos responsáveis pelas interrupções.
• Construção do Dataset: A partir de 377 CoEs, identificaram 100 Revisões de Código (CRs) como causas raiz, resultando em um conjunto de dados de 149 commits de risco e 2.831 commits não arriscados (uma proporção de 1:19) do ambiente de produção da Prime Video. O dataset foca em Java, Kotlin e TypeScript.
• Validação Externa: O dataset ApacheJIT foi utilizado para validação externa, amostrando 1.115 commits indutores de bugs e 21.185 limpos em 14 projetos Apache, mantendo a mesma proporção de classes.

2. Extração de Recursos (Feature Extraction)

A estrutura extrai 28 recursos categorizados em grupos quantitativos e qualitativos, evitando ferramentas específicas de linguagem ao utilizar Grandes Modelos de Linguagem (LLMs).

• Recursos Quantitativos:
  • Nível de Código: Estrutura de arquivo (linhas de código, comentários), complexidade (complexidade ciclomática, profundidade de aninhamento) e escopo (contagens de classe/método).
  • Nível de Mudança: Extensão da modificação (linhas adicionadas/deletadas/modificadas, churn, arquivos alterados).
  • Ferramenta de Extração: O Claude Sonnet 3.7 foi utilizado como um extrator de recursos multilingue. A validação contra o ground truth baseado em scripts mostrou uma correlação de Pearson de 0,730 e um Coeficiente de Correlação Intraclasse (ICC) de 0,861, confirmando a capacidade do LLM de capturar tendências subjacentes de forma confiável.
• Recursos Qualitativos:
  • Tipo de Mudança: Classificação em Adaptativa, Corretiva, Perfeccionista ou Preventiva com base nas mensagens de commit.
  • Violações de Estilo: Detecção de violações em 13 categorias (ex: convenções de nomenclatura, verificações de bloco) usando analisadores estáticos específicos de linguagem (Checkstyle, Detekt, ESLint) mapeados para categorias comuns.

3. Classificação

• Modelos: Classificadores XGBoost e Random Forest foram treinados usando validação cruzada de 10 dobras (10-fold cross-validation).
• Objetivo: O sistema é projetado como um "guarda-corpo" (guardrail) para sinalizar mudanças arriscadas para revisão humana, em vez de bloquear implantações autonomamente. Consequentemente, o limiar foi otimizado para maximizar o recall (minimizando mudanças arriscadas perdidas) em vez da precisão. Um limiar de 0,2 foi selecionado para equilibrar o desbalanceamento de classe de 1:19.
• Baselines: Regressão Logística e classificação baseada em LLM (prompting zero-shot e few-shot com Claude Sonso 3.7 e 4.5) foram avaliadas.

Principais Resultados

Desempenho de Classificação

• XGBoost: Alcançou o melhor desempenho com um F1-score de 0,846 no dataset da Prime Video (Recall: 0,788, Precisão: 0,926) e 0,771 no dataset ApacheJIT.
• Random Forest: Desempenhou de forma comparável (F1: 0,815 na Prime Video) com recall mais alto (0,830), mas precisão menor.
• Classificadores LLM: A classificação de ponta a ponta usando LLMs (zero-shot e few-shot) teve um desempenho significativamente inferior aos modelos de engenharia de recursos. Mesmo com o Claude Sonnet 4.5, o melhor F1-score de few-shot foi de apenas 0,261 na Prime Video. Isso indica que, embora os LLMs sejam eficazes para extração de recursos, eles atualmente ficam atrás dos modelos de ML tradicionais para classificação de risco de ponta a ponta neste contexto.

Insights do Estudo de Ablação

Um estudo de ablação revelou insights críticos sobre a utilidade dos recursos:

• Métricas de Nível de Código: Estas foram os preditores mais influentes. A exclusão delas causou a maior queda de desempenho (o F1 caiu de 0,846 para 0,781).
• Métricas de Nível de Mudança: Surpreendentemente, excluir recursos quantitativos de nível de mudança (ex: linhas adicionadas/deletadas) melhorou ligeiramente o desempenho (F1: 0,848), sugerindo que o volume bruto de mudanças é um preditor ruidoso de risco.
• Recursos Qualitativos: Ajudaram a equilibrar o modelo; excluí-los aumentou a precisão, mas reduziu o recall.
• Conclusão: A complexidade estrutural do código fornece um sinal de risco substancialmente mais forte do que o volume bruto de mudanças.

Significância e Alegações

O artigo afirma fornecer uma solução prática e preservadora de privacidade para a avaliação de risco de implantação em ambientes de alto risco. Sua significância reside em três contribuições principais:

1. Capacidade de Cold-Start: A estrutura opera sem metadados de desenvolvedor ou dados históricos, tornando-a imediatamente aplicável a novos projetos, novas bases de código e cenários com histórico limitado.
2. LLM como Extratores de Recursos: O estudo demonstra que os LLMs podem substituir efetivamente parsers de AST frágeis e específicos de linguagem para extrair métricas quantitativas estruturadas através de múltiplas linguagens (Java, Kotlin, TypeScript) usando um único template de prompt.
3. Validação Empírica de Recursos Baseados Apenas em Diff: Os resultados validam que um conjunto bem curado de recursos de nível de diff sozinho pode alcançar um desempenho forte (F1: 0,846), desafiando a necessidade de modelos complexos pesados em metadados para a avaliação de risco inicial.

Os autores enfatem que sua abordagem permite decisões de implantação mais direcionadas, potencialmente reduzindo o escopo dos congelamentos de implantação sem comprometer a segurança. Eles observam que, embora os LLMs sejam poderosos para extração de recursos, a lacuna entre a classificação de ponta a ponta baseada em LLM e os modelos de engenharia de recursos permanece significativa, sugerindo que a curadoria de recursos estruturados é atualmente essencial para uma previsão de risco confiável.