Multi-stage Dynamic Selection for Cross-Project Defect Prediction

Stel je voor dat je een detective bent die een mysterie probeert op te lossen, maar je hebt de plaats delict nog nooit eerder gezien. Je hebt alleen een stapel oude dossierstukken van volkomen verschillende steden, geschreven door verschillende politiekorpsen met verschillende straattaal en gewoonten. Je taak is om te voorspellen waar de volgende crimineel zal toeslaan in je nieuwe stad. Dit is de dagelijkse strijd van software engineers die proberen hun programma's foutvrij te houden. Ze willen "defecten" (bugs) vinden in hun code voordat de software crasht, maar veel nieuwe projecten zijn als een onbeschreven blad: ze hebben nog niet lang genoeg gelopen om een geschiedenis van fouten op te bouwen. Daarom proberen engineers te leren van andere projecten, in de hoop dat wat werkte bij een videogamebedrijf ook kan helpen bij het oplossen van een bank-app. Dit wordt Cross-Project Defect Prediction genoemd. Het probleem is dat elk project uniek is; een model dat perfect werkt op het ene, kan hopeloos falen op het andere omdat de "plaatsen delict" (de code) er zo verschillend uitzien.

Maak kennis met een nieuw team van digitale detectives genaamd Multi-DES. In plaats van een enkele detective in te huren om elke zaak in de nieuwe stad op te lossen, of één "superdetective" te dwingen om elk buurtje tegelijk te begrijpen, gebruikt dit team een slimme tweestapsstrategie. Eerst auditioneren ze een enorme menigte verschillende detectives, elk met hun eigen unieke stijl en gereedschapskist, om te zien welke groep experts het beste samenwerkt bij het bekijken van oude dossiers. Wanneer er vervolgens een nieuwe zaak binnenkomt, kiezen ze niet zomaets één detective. In plaats daarvan kijken ze naar de specifieke details van die nieuwe zaak en roepen ze direct de beste expert in voor die specifieke situatie aan. Het is alsof je een team van specialisten hebt waarbij een verkeersagent een auto-ongeluk afhandelt, een forensisch accountant een fraudezaak afhandelt en een onderhandelaar een gijzelingssituatie afhandelt, allemaal ter plekke gekozen. De onderzoekers ontdekten dat deze "juiste expert voor het juiste moment"-aanpak veel beter is in het vinden van bugs in nieuwe, onbekende projecten dan de oude methoden die probeerden dezelfde enkele oplossing voor alles te gebruiken.

Het Detectivebureau: Hoe Multi-DES werkt

In de wereld van software is een "defect" een bug — een fout in de code die ervoor kan zorgen dat het programma crasht of vreemd gedrag vertoont. Het voorspellen van deze bugs is cruciaal omdat het vinden ervan in een vroeg stadium tijd en geld bespaart. Maar hier is de crux: om een computer te leren hoe hij een bug kan opsporen, heb je meestal veel eerdere voorbeelden van bugs nodig. Nieuwe projecten hebben deze voorbeelden nog niet. Daarom proberen engineers kennis te lenen van andere, oudere projecten. Dit is het "Cross-Project"-gedeelte.

Er is echter een grote hindernis: Distribution Shift. Denk hierbij aan het proberen te leren autorijden in een land waar iedereen links rijdt, met alleen een handleiding die geschreven is voor een land waar iedereen rechts rijdt. De regels zijn vergelijkbaar, maar de details zijn omgedraaid. In software kan het ene project een specifieke programmeerstijl gebruiken, terwijl een ander een totaal andere stijl gebruikt. Traditionele methoden proberen één gigantisch model te bouwen dat probeert al deze verschillen tegelijkertijd te begrijpen. De auteurs van dit paper beargumenteren dat dit is also kind aan het gebruik van een enkele, generieke kaart voor elke stad ter wereld; het is te breed en mist de lokale straten.

Het paper stelt Multi-DES (Multi-stage Dynamic Ensemble Selection) voor, wat een beetje is als een slimme, adaptieve wervingsorganisatie voor software-detectives. Het werkt in twee hoofdfasen:

Fase 1: De Grote Auditie (Projectniveau)
Voordat het systeem het nieuwe project ooit ziet, gaat het door een enorme "overproductie"-fase. Stel je een castingcall voor waarbij ze elke mogelijke combinatie testen van:

• Base Classifiers: Verschillende soorten algoritmen (zoals Decision Trees, Random Forests, enz.). Zie dit als verschillende typen detectives (de observante, de logische, de patroonherkenner).
• Dynamic Selection Techniques: Verschillende manieren om te beslissen welke detective je vertrouwt.
• Pool Sizes: Hoeveel detectives er in de kamer zijn.

Ze testen al deze combinaties (4 base algorithms × 8 selection techniques × 10 pool sizes = 320 verschillende configuraties) op een set van "trainingsprojecten". Maar ze kiezen niet simpelweg degene die de hoogste score behaalde op een enkele test. In plaats daarvan gebruiken ze een strategie genaamd Aggregate Rank Minimization (ARM).

De ARM-strategie: De "All-Rounder" Rechter
Stel je een talentenjacht voor waarbij je een winnaar moet kiezen op basis van zingen, dansen en acteren. Als je alleen iemand kiest met de beste stem, kan diegene verschrikkelijk zijn in acteren. ARM is als een rechter die elke deelnemer op alle drie de vaardigheden rangschikt, en dan de rangen bij elkaar optelt om de persoon te vinden die de meest consistente allrounder is. Het paper suggereert dat door naar meerdere prestatie-indicatoren te kijken (zoals F1-score, AUC en False Alarm) samen, het systeem een configuratie vindt die robuust is en niet zal falen wanneer het nieuwe project anders is dan de oude projecten.

Fase 2: De Selectie Ter Plekke (Moduulniveau)
Zodod de beste "auditie"-configuratie is gekozen, is het systeem klaar voor het nieuwe project. Maar hier zit de magie: het past niet slechts één model toe op het hele project. Software bestaat uit vele "modules" (zoals individuele kamers in een huis of hoofdstukken in een boek).

Wanneer het systeem naar een specifieke module in het nieuwe project kijkt, vraat het: "Welke van onze getrainde detectives is het best in het opsporen van bugs in dit specifieke soort code?" Het selecteert dynamisch de meest competente classifiers voor dat specifieke stuk code. Als een module lijkt op een bank-app, kiest het de "financiële expert" uit de pool. Als een andere module lijkt op een game-engine, kiest het de "graphics expert". Dit gebeurt in realtime, voor elk stuk code.

Wat ze hebben gevonden

De onderzoekers hebben dit idee getest op 82 softwareprojecten uit vier verschillende publieke datasets (PROMISE, RELINK, NASA en AEEEM). Ze gebruikten een strikte testmethode genaamd "leave-one-project-out", wat betekent dat ze trainden op 81 projecten en probeerden de bugs in het 82e project te voorspellen, en dit herhaalden voor elk project.

De resultaten waren zeer veelbelovend:

• Beter dan de beste: Multi-DES presteerde beter dan of kwam overeen met de beste bestaande methoden in de meeste scenario's. Specifiek behaalde het de beste resultaten voor de AUC (een maatstaf voor hoe goed het model onderscheid maakt tussen buggy en schone code) en False Alarm (hoe vaak het vals alarm slaat) metrieken op de meeste datasets.
• De cijfers: Op de AEEEM-dataset behaalde Multi-DES een AUC van 0,755, waarmee het de op één na beste methode (EASC-NB) versloeg, die een score van 0,692 behaalde. Op de NASA-dataset scoorde het 0,737 vergeleken met 0,666.
• Robuustheid: Het systeem was bijzonder goed in het laag houden van "False Alarms", wat betekent dat het ingenieurs geen tijd verspilde aan het controleren van code die eigenlijk in orde was.
• Geen valsspelen: Cruciaal is dat het systeem dit deed zonder enkele data van het nieuwe doelproject te bekijken tijdens de trainingsfase. Het vertrouwde volledig op de oude projecten, wat bewees dat je niet in de geheimen van het nieuwe project hoeft te gluren om een goede voorspeller te bouwen.

Wat ze hebben uitgesloten

Het paper beargumenteert expliciet tegen het idee dat een enkel, statisch model (één vaste set regels toegepast op het hele project) de beste oplossing is. Ze laten zien dat omdat verschillende delen van een softwareproject verschillende kenmerken hebben, een "one-size-fits-all"-aanpak slecht generaliseert wanneer het nieuwe project anders is dan de trainingsdata. Ze sloten ook het idee uit dat je de datadistributie van het doelproject vooraf moet kennen om goede voorspellingen te doen; hun methode werkt zelfs wanneer het doelproject een compleet mysterie is.

Hoe zeker zijn ze?

De auteurs zijn vol vertrouwen in hun bevindingen op basis van de verzamelde gegevens. Ze hebben niet alleen gesimuleerd; ze hebben uitgebreide experimenten uitgevoerd op 82 echte projecten met standaard, algemeen aanvaarde metrieken. Ze gebruikten statistische tests (de Wilcoxon Signed-Rank test) om te bevestigen dat hun resultaten niet op toeval berustten. Het paper stelt dat Multi-DES "statistisch superieur" is in de meeste paarvergelijkingen, met name voor AUC en False Alarm. Ze merken echter een kleine uitzondering op: op de PROMISE-dataset was hun methode niet de absolute beste voor de "False Alarm"-metriek, wat aantoont dat hoewel de methode sterk is, het geen magische oplossing is die in elk scenario en in elke situatie wint.

Kortom, Multi-DES suggereert dat de beste manier om bugs in een nieuw, onbekend project te voorspellen, het hebben van een divers team van experts die klaarstaan om te worden opgeroepen, en de juiste expert te kiezen voor de specifiend taak, in plaats van te proberen één algemene specialist alles te laten doen.