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

1. Énoncé du problème

Contexte : Les systèmes de recommandation d'API basés sur l'apprentissage automatique (ML) aident les développeurs à identifier les méthodes d'API appropriées pour compléter le code d'une application. Cependant, ces systèmes reposent sur des ensembles de données d'entraînement qui présentent une distribution à longue traîne.

• Le problème : Bien que les API de « tête » (fréquemment utilisées) soient bien représentées dans les données d'entraînement, les API de « queue » (rarement utilisées) souffrent d'une pénurie de données.
• Conséquence : Les modèles ML entraînés sur de telles données ont tendance à produire des recommandations peu fiables pour les API de queue. L'adoption de ces recommandations incorrectes peut introduire des bugs, augmenter les coûts de débogage et compromettre la fiabilité du logiciel.
• Lacune : Les approches existantes traitent souvent toutes les entrées de manière égale. Il manque des mécanismes pour détecter et gérer spécifiquement les « cas de queue » (entrées susceptibles de nécessiter des API rares) afin d'éviter la génération de sorties à faible confiance ou incorrectes.

2. Méthodologie : NvRec

Les auteurs proposent N-version API Recommendation (NvRec), un cadre inspiré de la programmation N-version. Au lieu d'entraîner un modèle monolithique unique, NvRec exploite la diversité de plusieurs modèles ML pré-entraînés pour filtrer les sorties peu fiables.

Le cadre fonctionne en deux phases principales :

A. Profilage des modèles (Phase hors ligne)

Avant l'inférence, le système analyse les performances de $N$ modèles ML différents sur un ensemble de données de profilage.

• Génération du profil de modèle : Pour chaque méthode d'API, le système enregistre :
  • Fréquence : Pour classer l'API comme « Tête » (fréquence élevée) ou « Queue » (fréquence faible).
  • Historique des performances : Le nombre de fois où chaque modèle a recommandé l'API et combien de ces recommandations étaient correctes.
• Drapeau de queue : Un indicateur binaire ($H$ ou $T$) est attribué à chaque méthode d'API sur la base d'un seuil de fréquence cumulative (par exemple, les 50 % supérieurs sont Tête, le reste est Queue).

B. Pipeline d'inférence (Phase en ligne)

Lorsqu'un utilisateur fournit une requête en langage naturel et un contexte de code source :

1. Analyseur de queue : Un classificateur binaire prédit si l'entrée est un « cas de queue » (susceptible de nécessiter des API de queue).
   • Si Queue : La demande est rejetée immédiatement pour supprimer les recommandations peu fiables.
   • Si Tête : Le processus passe à l'inférence multi-version.
2. Inférence multi-version : $N$ modèles ML différents (par exemple, CodeBERT, CodeT5, MulaRec) génèrent indépendamment des candidats de séquences de méthodes d'API.
3. Filtrage : Les candidats sont filtrés sur la base du Profil de modèle :
   • Filtrage enregistré (R-Filter) : Rejette les séquences contenant des API non vues dans l'historique du modèle.
   • Filtrage Tête (H-Filter) : Rejette les séquences contenant toute API marquée comme « Queue ».
   • Filtrage RH : Une combinaison des deux.
4. Décision de sortie : Le résultat final est déterminé à partir des candidats restants en utilisant l'une des trois stratégies suivantes :
   • Rejet simple : Si aucun consensus (vote majoritaire) n'est atteint, tout est rejeté.
   • Basé sur le score : Sélectionne le candidat ayant la moyenne géométrique la plus élevée des scores de précision dérivés du profil de modèle.
   • Meilleur modèle : Sélectionne la sortie du modèle historiquement le plus performant (si disponible).

3. Contributions clés

1. Cadre NvRec : Une architecture novatrice qui combine des modèles ML N-version avec un filtrage sensible à la queue pour améliorer la fiabilité de la recommandation d'API.
2. Analyseur de queue : Une démonstration empirique qu'un classificateur dédié peut identifier efficacement les cas de queue, permettant au système de rejeter proactivement les entrées susceptibles de générer des erreurs.
3. Utilisation du profil de modèle : Une méthode pour enregistrer et exploiter les caractéristiques de performance spécifiques de différents modèles pour des méthodes d'API spécifiques afin de filtrer dynamiquement les candidats.
4. Évaluation complète : Une évaluation rigoureuse sur l'ensemble de données 50K-C (projets Java) comparant diverses combinaisons de modèles (3 contre 5 versions), stratégies de filtrage et règles de décision.

4. Résultats expérimentaux

L'étude a évalué NvRec en utilisant cinq modèles : CodeBERT, CodeT5, MulaRec, UniXcoder et CodeT5+.

• Efficacité de l'Analyseur de queue :

  • L'application de l'Analyseur de queue seul a amélioré le taux d'acceptation vrai (TAR) des modèles individuels en rejetant environ 51,6 % des entrées.
  • Exemple : Le TAR de MulaRec est passé de 46,3 % à 52,2 %.

• Configuration à trois versions (Meilleure performance) :

  • La combinaison de CodeT5, MulaRec et UniXcoder a donné les meilleurs résultats.
  • Configuration : H-Filter (Filtrage Tête) + Rejet simple.
  • Métriques :
    • Taux d'acceptation vrai (TAR) : 83,8 % (Significativement plus élevé que le meilleur modèle unique, MulaRec à 46,3 %).
    • Taux de rejet (RR) : 80,7 %.
    • Taux de faux rejet (FRR) : 32,2 %.

• Configuration à cinq versions :

  • Étonnamment, l'ajout de plus de modèles (5 versions) a dégradé les performances lorsque le filtrage strict était appliqué.
  • Le meilleur TAR à cinq versions était de 83,1 % (avec R-Filter + Rejet simple), mais cela était inférieur au pic à trois versions.
  • Insight : Avec des modèles plus diversifiés, le filtrage strict (comme H-Filter) tendait à rejeter des candidats corrects que seuls des modèles plus faibles pouvaient prédire, augmentant ainsi le taux de faux rejet. Pour 5 versions, éviter le filtrage et se fier au vote majoritaire simple était plus efficace.

• Règles de décision :

  • Le Rejet simple (vote majoritaire) a constamment surpassé les stratégies basées sur le score et le meilleur modèle en termes de TAR.
  • Les approches basées sur le score ont réduit le taux de rejet mais ont considérablement abaissé le TAR.

5. Signification et implications

• Fiabilité plutôt que disponibilité : NvRec privilégie la sécurité. En acceptant un taux de rejet élevé (rejetant environ 80 % des demandes), il garantit que les recommandations restantes sont hautement fiables (83,8 % de précision). Cela est crucial pour le développement de logiciels à haute assurance.
• Gestion des données à longue traîne : L'approche atténue efficacement le problème de la « longue traîne » dans le ML en identifiant et en supprimant explicitement les cas de queue plutôt qu'en essayant de forcer un modèle à les prédire avec précision.
• Application pratique : Bien que des taux de rejet élevés limitent la disponibilité de l'outil, les auteurs suggèrent que les recommandations rejetées (mais potentiellement utiles) pourraient être présentées aux développeurs sous forme d'« alertes de faible confiance » pour aider à la révision manuelle plutôt que d'être totalement écartées.
• Généralisabilité : Le cadre N-version n'est pas limité à la recommandation d'API et pourrait être appliqué à d'autres tâches de génération de code où la fiabilité est primordiale.

Conclusion : L'article démontre que l'exploitation de la diversité de plusieurs modèles ML, combinée à un mécanisme pour détecter et filtrer les entrées de « queue », surpasse significativement les modèles uniques de l'état de l'art dans la génération de séquences d'API fiables, bien que cela se fasse au prix d'un taux de rejet plus élevé.