Tail-aware N-version Machine Learning Models for Reliable API Recommendation

1. Declaração do Problema

Contexto: Sistemas de recomendação de APIs baseados em Aprendizado de Máquina (ML) auxiliam desenvolvedores a identificar métodos de API adequados para completar o código de aplicações. No entanto, esses sistemas dependem de conjuntos de dados de treinamento que exibem uma distribuição de cauda longa.

• O Problema: Enquanto as APIs de "cabeça" (frequentemente usadas) são bem representadas nos dados de treinamento, as APIs de "cauda" (pouco usadas) sofrem com escassez de dados.
• Consequência: Modelos de ML treinados nesses dados tendem a produzir recomendações pouco confiáveis para APIs de cauda. Adotar essas recomendações incorretas pode introduzir bugs, aumentar os custos de depuração e comprometer a confiabilidade do software.
• Lacuna: Abordagens existentes frequentemente tratam todas as entradas igualmente. Há uma falta de mecanismos para detectar e lidar especificamente com "casos de cauda" (entradas que provavelmente exigem APIs raras) a fim de evitar a geração de saídas de baixa confiança ou incorretas.

2. Metodologia: NvRec

Os autores propõem a Recomendação de API em N-Versões (NvRec), um framework inspirado na programação em N-versões. Em vez de treinar um único modelo monolítico, o NvRec aproveita a diversidade de múltiplos modelos de ML pré-treinados para filtrar saídas pouco confiáveis.

O framework opera em duas fases principais:

A. Perfilagem de Modelos (Fase Offline)

Antes da inferência, o sistema analisa o desempenho de $N$ modelos de ML diferentes em um conjunto de dados de perfilagem.

• Geração de Perfil de Modelo: Para cada método de API, o sistema registra:
  • Frequência: Para classificar a API como "Cabeça" (alta frequência) ou "Cauda" (baixa frequência).
  • Histórico de Desempenho: O número de vezes que cada modelo recomendou a API e quantas dessas recomendações foram corretas.
• Flag de Cauda: Uma flag binária ($H$ ou $T$) é atribuída a cada método de API com base em um limite de frequência cumulativa (por exemplo, os 50% superiores são Cabeça, o restante é Cauda).

B. Pipeline de Inferência (Fase Online)

Quando um usuário fornece uma consulta em linguagem natural e contexto de código-fonte:

1. Analisador de Cauda: Um classificador binário prevê se a entrada é um "caso de cauda" (provável de exigir APIs de cauda).
   • Se Cauda: A solicitação é rejeitada imediatamente para suprimir recomendações pouco confiáveis.
   • Se Cabeça: O processo prossegue para inferência em múltiplas versões.
2. Inferência em Múltiplas Versões: $N$ modelos de ML diferentes (por exemplo, CodeBERT, CodeT5, MulaRec) geram independentemente candidatos de sequência de métodos de API.
3. Filtragem: Os candidatos são filtrados com base no Perfil do Modelo:
   • Filtragem Registrada (R-Filter): Descarta sequências contendo APIs não vistas no histórico do modelo.
   • Filtragem de Cabeça (H-Filter): Descarta sequências contendo qualquer API marcada como "Cauda".
   • RH-Filter: Uma combinação de ambas.
4. Decisão de Saída: O resultado final é determinado a partir dos candidatos restantes usando uma de três estratégias:
   • Rejeição Simples: Se nenhum consenso (votação majoritária) for alcançado, rejeite tudo.
   • Baseada em Pontuação: Selecione o candidato com a maior média geométrica de pontuações de precisão derivadas do perfil do modelo.
   • Melhor Modelo: Selecione a saída do modelo historicamente de melhor desempenho (se disponível).

3. Contribuições Principais

1. Framework NvRec: Uma arquitetura inovadora que combina modelos de ML em N-versões com filtragem consciente da cauda para aumentar a confiabilidade da recomendação de APIs.
2. Analisador de Cauda: Uma demonstração empírica de que um classificador dedicado pode identificar efetivamente casos de cauda, permitindo que o sistema rejeite proativamente entradas propensas a gerar erros.
3. Utilização de Perfis de Modelo: Um método para registrar e utilizar as características de desempenho específicas de diferentes modelos para métodos de API específicos, a fim de filtrar candidatos dinamicamente.
4. Avaliação Abrangente: Uma avaliação rigorosa no conjunto de dados 50K-C (projetos Java) comparando várias combinações de modelos (3 vs. 5 versões), estratégias de filtragem e regras de decisão.

4. Resultados Experimentais

O estudo avaliou o NvRec usando cinco modelos: CodeBERT, CodeT5, MulaRec, UniXcoder e CodeT5+.

• Eficácia do Analisador de Cauda:

  • Aplicar apenas o Analisador de Cauda melhorou a Taxa de Aceitação Verdadeira (TAR) de modelos individuais ao rejeitar ~51,6% das entradas.
  • Exemplo: A TAR do MulaRec aumentou de 46,3% para 52,2%.

• Configuração de Três Versões (Melhor Desempenho):

  • A combinação de CodeT5, MulaRec e UniXcoder produziu os melhores resultados.
  • Configuração: H-Filter (Filtragem de Cabeça) + Rejeição Simples.
  • Métricas:
    • Taxa de Aceitação Verdadeira (TAR): 83,8% (Significativamente maior que o melhor modelo único, MulaRec com 46,3%).
    • Taxa de Rejeição (RR): 80,7%.
    • Taxa de Falsa Rejeição (FRR): 32,2%.

• Configuração de Cinco Versões:

  • Surpreendentemente, adicionar mais modelos (5 versões) degradou o desempenho quando filtragem rigorosa foi aplicada.
  • A melhor TAR de 5 versões foi 83,1% (com R-Filter + Rejeição Simples), mas isso foi inferior ao pico de 3 versões.
  • Insight: Com modelos mais diversos, a filtragem rigorosa (como H-Filter) tendeu a descartar candidatos corretos que apenas modelos mais fracos conseguiam prever, aumentando a Taxa de Falsa Rejeição. Para 5 versões, evitar a filtragem e confiar na votação majoritária simples foi mais eficaz.

• Regras de Decisão:

  • Rejeição Simples (Votação majoritária) superou consistentemente as estratégias Baseadas em Pontuação e Melhor Modelo em termos de TAR.
  • Abordagens Baseadas em Pontuação reduziram a Taxa de Rejeição, mas diminuíram significativamente a TAR.

5. Significado e Implicações

• Confiabilidade sobre Disponibilidade: O NvRec prioriza a segurança. Ao aceitar uma alta Taxa de Rejeição (rejeitando ~80% das solicitações), garante que as recomendações restantes sejam altamente confiáveis (83,8% de precisão). Isso é crucial para o desenvolvimento de software de alta garantia.
• Tratamento de Dados de Cauda Longa: A abordagem mitiga efetivamente o problema da "cauda longa" em ML, identificando e suprimindo explicitamente casos de cauda em vez de forçar um modelo a prevê-los com precisão.
• Aplicação Prática: Embora altas taxas de rejeição limitem a disponibilidade da ferramenta, os autores sugerem que recomendações rejeitadas (mas potencialmente úteis) poderiam ser apresentadas aos desenvolvedores como "alertas de baixa confiança" para auxiliar na revisão manual, em vez de serem descartadas totalmente.
• Generalização: O framework em N-versões não se limita à recomendação de APIs e pode ser aplicado a outras tarefas de geração de código onde a confiabilidade é primordial.

Conclusão: O artigo demonstra que aproveitar a diversidade de múltiplos modelos de ML, combinada com um mecanismo para detectar e filtrar entradas de "cauda", supera significativamente os modelos únicos mais avançados na geração de sequências de APIs confiáveis, embora ao custo de uma taxa de rejeição mais alta.