Multi-stage Dynamic Selection for Cross-Project Defect Prediction

Imaginez que vous êtes un détective essayant de résoudre un mystère, mais que vous n'avez jamais vu la scène du crime auparavant. Vous ne possédez qu'une pile de vieux dossiers d'affaires provenant de villes complètement différentes, écrits par des forces de police différentes avec des argots et des habitudes différents. Votre tâche est de prédire où le prochain criminel frappera dans votre nouvelle ville. C'est la lutte quotidienne des ingénieurs logiciels qui tentent de garder leurs programmes exempts de bogues. Ils veulent trouver des « défauts » (bogues) dans leur code avant que le logiciel ne plante, mais beaucoup de nouveaux projets sont comme des pages blanches : ils n'ont pas tourné assez longtemps pour constituer un historique d'erreurs. Ainsi, les ingénieurs essaient d'apprendre d'autres projets, espérant que ce qui a fonctionné dans une entreprise de jeux vidéo aidera à corriger une application bancaire. C'est ce qu'on appelle la Prédiction de Défauts Trans-Projets (Cross-Project Defect Prediction). Le problème est que chaque projet est unique ; un modèle qui fonctionne parfaitement sur l'un peut échouer lamentablement sur un autre parce que les « scènes de crime » (le code) sont si différentes.

Entrez une nouvelle équipe de détectives numériques appelée Multi-DES. Au lieu d'engager un détective unique pour résoudre chaque cas dans la nouvelle ville, ou de forcer un « super-détective » à essayer de comprendre tous les quartiers à la fois, cette équipe utilise une stratégie intelligente en deux étapes. D'abord, ils auditionnent une foule massive de différents détectives, chacun ayant son propre style et sa propre boîte à outils, pour voir quel groupe d'experts fonctionne le mieux en examinant les anciens dossiers d'affaires. Ensuite, lorsqu'un nouveau cas arrive, ils ne se contentent pas de choisir un seul détective. Au lieu de cela, ils examinent les détails spécifiques de ce nouveau cas et appellent instantanément le meilleur expert pour cette situation spécifique. C'est comme avoir une équipe de spécialistes où un agent de circulation s'occupe d'un accident de voiture, un expert-comptable judiciaire s'occupe d'un cas de fraude, et un négociateur s'occupe d'une situation de prise d'otages, tous choisis à la volée. Les chercheurs ont découvert que cette approche du « bon expert pour le bon moment » est bien meilleure pour trouver des bogues dans de nouveaux projets inconnus que les anciennes méthodes qui essayaient d'utiliser la même solution unique pour tout.

L'agence de détectives : Comment fonctionne Multi-DES

Dans le monde du logiciel, un « défaut » est un bogue — une erreur dans le code qui pourrait faire planter le programme ou le faire agir bizarrement. Prédire ces bogues est crucial car les trouver tôt permet de gagner du temps et de l'argent. Mais voici le piège : pour apprendre à un ordinateur comment repérer un bogue, vous avez généralement besoin de beaucoup d'exemples passés de bogues. Les nouveaux projets n'ont pas encore ces exemples. Ainsi, les ingénieurs tentent d'emprunter des connaissances à d'autres projets plus anciens. C'est la partie « Trans-Projet ».

Cependant, il existe un obstacle majeur : le Décalage de Distribution (Distribution Shift). Pensez à cela comme essayer d'apprendre à conduire dans un pays où tout le monde conduit à gauche, en utilisant uniquement un manuel écrit pour un pays où tout le monde conduit à droite. Les règles sont similaires, mais les détails sont inversés. Dans le logiciel, un projet peut utiliser un style de codage spécifique, tandis qu'un autre en utilise un complètement différent. Les méthodes traditionnelles tentent de construire un seul modèle géant qui essaie de comprendre toutes ces différences à la fois. Les auteurs de cet article soutiennent que c'est comme essayer d'utiliser une seule carte générique pour toutes les villes du monde ; elle est trop large et manque les rues locales.

L'article propose Multi-DES (Multi-stage Dynamic Ensemble Selection), qui est un peu comme une agence de recrutement intelligente et adaptative pour les détectives de logiciels. Il opère en deux étapes principales :

Étape 1 : La grande audition (Niveau Projet)
Avant même que le système ne voie le nouveau projet, il passe par une phase de « surproduction » massive. Imaginez un appel à l'audition où ils essaient toutes les combinaisons possibles de :

• Classificateurs de base : Différents types d'algorithmes (comme les arbres de décision, les forêts aléatoires, etc.). Considérez-les comme différents types de détectives (celui qui est observateur, celui qui est logique, le spécialiste de la reconnaissance de formes, etc.).
• Techniques de sélection dynamique : Différentes façons de décider quel détective croire.
• Tailles de pool : Combien de détectives sont dans la pièce.

Ils testent toutes ces combinaisons (4 algorithmes de base × 8 techniques de sélection × 10 tailles de pool = 320 configurations différentes) sur un ensemble de projets d'« entraînement ». Mais ils ne choisissent pas simplement celui qui a obtenu le score le plus élevé sur un seul test. Au lieu de cela, ils utilisent une stratégie appelée Minimisation du Rang Agrégé (Aggregate Rank Minimization - ARM).

La stratégie ARM : Le juge « polyvalent »
Imaginez un concours de talents où vous devez choisir un vainqueur basé sur le chant, la danse et le jeu d'acteur. Si vous choisissez seulement la personne qui a la meilleure voix de chanteur, elle pourrait être terrible en jeu d'acteur. L'ARM est comme un juge qui classe chaque candidat sur toutes les trois compétences, puis additionne leurs rangs pour trouver la personne qui est l'ensemble le plus cohérent et polyvalent. L'article suggère qu'en examinant plusieurs mesures de performance (comme le score F1, l'AUC et la fausse alerte) ensemble, le système trouve une configuration qui est robuste et qui ne fera pas défaut lorsque le nouveau projet sera différent de ceux des anciens projets.

Étape 2 : La sélection à la volée (Niveau Module)
Une fois la meilleure configuration d'« audition » choisie, le système est prêt pour le nouveau projet. Mais voici la magie : il n'applique pas un seul modèle à l'ensemble du projet. Un logiciel est composé de nombreux « modules » (comme les pièces individuelles d'une maison ou les chapitres d'un livre).

Lorsqu'un système examine un module spécifique dans le nouveau projet, il demande : « Quel est le meilleur détective de notre pool pour repérer les bogues dans ce type spécifique de code ? » Il sélectionne dynamiquement les classificateurs les plus compétents pour ce morceau de code précis. Si un module ressemble à une application bancaire, il choisit l'« expert en finance » de son pool. Si un autre module ressemble à un moteur de jeu, il choisit l'« expert en graphismes ». Cela se produit en temps réel, pour chaque morceau de code.

Ce qu'ils ont trouvé

Les chercheurs ont testé cette idée sur 82 projets logiciels provenant de quatre ensembles de données publics (PROMISE, RELINK, NASA et AEEEM). Ils ont utilisé une méthode de test stricte appelée « leave-one-project-out » (laisser un projet de côté), ce qui signifie qu'ils se sont entraînés sur 81 projets et ont essayé de prédire les bogues du 82e, puis ont répété l'opération pour chaque projet.

Les résultats sont très prometteurs :

• Meilleur que le meilleur : Multi-DES a surpassé ou égalé les meilleures méthodes existantes dans la plupart des scénarios. Plus précisément, il a obtenu les meilleurs résultats pour les métriques AUC (une mesure de la capacité du modèle à distinguer le code buggé du code propre) et Fausse Alerte (la fréquence à laquelle il donne l'alarme inutilement) sur la plupart des ensembles de données.
• Les chiffres : Sur l'ensemble de données AEEEM, Multi-DES a obtenu un AUC de 0,755, battant la méthode suivante la plus performante (EASC-NB) qui a obtenu 0,692. Sur l'ensemble de données NASA, il a obtenu 0,737 contre 0,666.
• Robustesse : Le système était particulièrement efficace pour maintenir les « Fausses Alertes » à un niveau bas, ce qui signifie qu'il ne faisait pas perdre de temps aux ingénieurs en vérifiant du code qui était en fait correct.
• Pas de triche : Crucialement, le système a fait cela sans regarder aucune donnée du nouveau projet cible pendant la phase d'entraînement. Il s'est appuyé entièrement sur les anciens projets, prouvant que vous n'avez pas besoin de jeter un coup d'œil aux secrets du nouveau projet pour construire un bon prédicteur.

Ce qu'ils ont écarté

L'article argumente explicitement contre l'idée qu'un modèle unique et statique (un ensemble de règles fixes appliqué à l'ensemble du projet) soit la meilleure solution. Ils démontrent que, comme différentes parties d'un projet logiciel ont des caractéristiques différentes, une approche « taille unique » échoue à bien se généraliser lorsque le nouveau projet est différent des données d'entraînement. Ils ont également écarté l'idée qu'il soit nécessaire de connaître la distribution des données du projet cible à l'avance pour faire de bonnes prédictions ; leur méthode fonctionne même lorsque le projet cible est un mystère total.

À quel point sont-ils sûrs ?

Les auteurs sont confiants dans leurs conclusions grâce aux données qu'ils ont collectées. Ils n'ont pas seulement simulé des scénarios ; ils ont mené des expériences approfondies sur 82 projets réels en utilisant des métriques standards et largement acceptées. Ils ont utilisé des tests statistiques (le test de rang signé de Wilcoxon) pour confirmer que leurs résultats n'étaient pas dus à la chance. L'article affirme que Multi-DES est « statistiquement supérieur » dans la plupart des comparaisons par paires, particulièrement pour l'AUC et la Fausse Alerte. Cependant, ils notent une petite exception : sur l'ensemble de données PROMISE, leur méthode n'était pas la meilleure absolue pour la métrique « Fausse Alerte », montée montrant que bien que la méthode soit forte, elle n'est pas une solution miracle qui gagne à chaque fois dans tous les scénarios.

En bref, Multi-DES suggère que la meilleure façon de prédire les bogues dans un nouveau projet inconnu est d'avoir une équipe diversifiée d'experts prêts à être sollicités, et de choisir le bon expert pour le travail spécifique, plutôt que d'essayer de forcer un généraliste à tout faire.