Multi-stage Dynamic Selection for Cross-Project Defect Prediction

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, ein Verbrechen aufzuklären, aber Sie haben noch nie einen Tatort gesehen. Sie haben lediglich einen Stapel alter Fallakten aus völlig unterschiedlichen Städten, geschrieben von verschiedenen Polizeikräften mit unterschiedlichem Jargon und unterschiedlichen Gewohnheiten. Ihr Job ist es, vorherzusagen, wo der nächste Kriminelle in Ihrer neuen Stadt zuschlagen wird. Dies ist der tägliche Kampf von Softwareentwicklern, die versuchen, ihre Programme fehlerfrei zu halten. Sie wollen „Defekte“ (Bugs) in ihrem Code finden, bevor die Software abstürzt, aber viele neue Projekte sind wie unbeschriebene Blätter: Sie sind noch nicht lange genug gelaufen, um eine Historie von Fehlern aufzubauen. Deshalb versuchen Ingenieure, von anderen Projekten zu lernen, in der Hoffnung, dass das, was in einem Spieleunternehmen funktioniert hat, auch bei der Behebung einer Banking-App helfen kann. Dies nennt man Cross-Project Defect Prediction (projektübergreifende Defektprognose). Das Problem ist, dass jedes Projekt einzigartig ist; ein Modell, das bei einem perfekt funktioniert, kann bei einem anderen kläglich scheitern, weil die „Tatorte“ (der Code) so unterschiedlich aussehen.

Hier kommt ein neues Team digitaler Detektive namens Multi-DES ins Spiel. Anstatt einen einzelnen Detektiv einzustellen, der jeden Fall in der neuen Stadt lösen soll, oder einen „Super-Detektiv“ zu zwingen, gleichzeitig alle Viertel zu verstehen, nutzt dieses Team eine clevere zweistufige Strategie. Zuerest führt es eine große Audition für eine riesige Menge verschiedener Detektive durch, jeder mit seinem eigenen einzigartigen Stil und Werkzeugsatz, um zu sehen, welche Gruppe von Experten am besten zusammenarbeitet, wenn sie alte Fallakten sichten. Wenn dann ein neuer Fall eintrifft, wählt man nicht einfach nur einen Detektiv aus. Stattdessen betrachtet man die spezifischen Details dieses neuen Falls und ruft sofort den besten Experten für genau diese Situation. Es ist, als hätte man ein Team von Spezialisten, bei dem ein Verkehrspolizist einen Autounfall bearbeitet, ein forensischer Buchhalter einen Betrugsfall handhabt und ein Verhandler eine Geiselnahme bewältigt – alles spontan für die jeweilige Situation ausgewählt. Die Forscher fanden heraus, dass dieser „richtige Experte für den richtigen Moment“-Ansatz viel besser darin ist, Bugs in neuen, unbekannten Projekten zu finden als die alten Methoden, die versuchten, dieselbe einzelne Lösung für alles zu verwenden.

Die Detektivagentur: Wie Multi-DES funktioniert

In der Welt der Software ist ein „Defekt“ ein Bug – ein Fehler im Code, der dazu führen könnte, dass das Programm abstürzt oder sich seltsam verhält. Die Vorhersage dieser Bugs ist entscheidend, da das frühe Finden Zeit und Geld spart. Aber hier liegt der Haken: Um einem Computer beizubringen, einen Bug zu erkennen, benötigt man normalerweise viele vergangene Beispiele für Bugs. Neue Projekte besitzen diese Beispiele noch nicht. Daher versuchen Ingenieure, Wissen aus anderen, älteren Projekten zu entleihen. Dies ist der „Cross-Project“-Teil.

Es gibt jedoch eine große Hürri: den Distribution Shift (Verteilungsverschiebung). Denken Sie an den Versuch, das Autofahren in einem Land zu lernen, in dem alle auf der linken Seite fahren, indem man nur ein Handbuch verwendet, das für ein Land geschrieben wurde, in dem alle auf der rechten Seite fahren. Die Regeln sind ähnlich, aber die Details sind umgekehrt. In der Software kann ein Projekt einen spezifischen Codierungsstil verwenden, während ein anderes einen völlig anderen nutzt. Traditionelle Methoden versuchen, ein einziges riesiges Modell zu bauen, das versucht, all diese Unterschiede gleichzeitig zu verstehen. Die Autoren dieses Papers argumentieren, dass dies so ist, als würde man versuchen, eine einzige, generische Karte für jede Stadt der Welt zu verwenden; sie ist zu breit gefasst und übersieht die lokalen Straßen.

Das Paper schlägt Multi-DES (Multi-stage Dynamic Ensemble Selection) vor, was ein wenig wie eine kluge, adaptive Personalagentur für Software-Detektive ist. Es arbeitet in zwei Hauptstadien:

Stufe 1: Die große Audition (Projektebene)
Bevor das System das neue Projekt überhaupt sieht, durchläuft es eine massive „Überproduktionsphase“. Stellen Sie sich eine Casting-Aufruf vor, bei dem jede mögliche Kombination aus Folgendem getestet wird:

• Base Classifiers (Basis-Klassifikatoren): Verschiedene Arten von Algorithmen (wie Entscheidungsbäume, Random Forests usw.). Betrachten Sie dies als verschiedene Typen von Detektiven (den Beobachtungsgabe besitzenden, den Logischen, den Mustererkennenden).
• Dynamic Selection Techniques (Dynamische Auswahltechniken): Verschiedene Wege, um zu entscheiden, welchem Detektiv man vertraut.
• Pool Sizes (Pool-Größen): Wie viele Detektive sich im Raum befinden.

Sie testen all diese Kombinationen (4 Basis-Algorithmen × 8 Auswahltechniken × 10 Pool-Größen = 320 verschiedene Konfigurationen) an einer Gruppe von „Trainings“-Projekten. Aber sie wählen nicht einfach diejenste aus, die bei einem einzelnen Test die höchste Punktzahl erreicht hat. Stattdessen nutzen sie eine Strategie namens Aggregate Rank Minimization (ARM).

Die ARM-Strategie: Der „Allrounder“-Richter
Stellen Sie sich ein Talentshow-Szenario vor, in dem Sie einen Gewinner basierend auf Gesang, Tanz und Schauspiel auswählen müssen. Wenn Sie nur jemanden mit der besten Singstimme wählen, kann er beim Schauspielen schrecklich sein. ARM ist wie ein Richter, der jeden Teilnehmer in allen drei Fähigkeiten bewertet und dann deren Ränge zusammenzählt, um die Person zu finden, die der konsistenteste Allrounder ist. Das Paper legt nahe, dass das System durch die Betrachtung mehrerer Leistungsmetriken (wie F1-Score, AUC und False Alarm) gemeinsam eine Konfiguration findet, die robust ist und nicht scheitert, wenn das neue Projekt anders aussieht als die alten Projekte.

Stufe 2: Die Auswahl „on-the-fly“ (Modulebene)
Sobeder die beste Konfiguration der „Audition“ gewählt wurde, ist das System bereit für das neue Projekt. Aber hier liegt die Magie: Es wendet nicht nur ein einziges Modell auf das gesamte Projekt an. Software besteht aus vielen „Modulen“ (wie einzelnen Zimmern in einem Haus oder Kapiteln in einem Buch).

Wenn das System ein spezifisches Modul im neuen Projekt betrachtet, fragt es: „Welcher unserer trainierten Detektive ist am besten darin, Bugs in genau dieser Art von Code aufzuspüren?“ Es wählt dynamisch die kompetentesten Klassifikatoren für dieses spezifische Stück Code aus. Wenn ein Modul wie eine Banking-App aussieht, wählt es den „Finanzexperten“ aus seinem Pool. Wenn ein anderes Modul wie eine Game-Engine aussieht, wählt es den „Grafikexperten“. Dies geschieht in Echtzeit, für jedes einzelne Stück Code.

Was sie herausgefunden haben

Die Forscher haben diese Idee an 82 Softwareprojekten aus vier verschiedenen öffentlichen Datensätzen (PROMISE, RELINK, NASA und AEEEM) getestet. Sie verwendeten eine strenge Testmethode namens „Leave-one-project-out“, was bedeutet, dass sie an 81 Projekten trainierten und versuchten, die Bugs im 82. Projekt vorherzusagen, und dies für jedes Projekt wiederholten.

Die Ergebnisse waren sehr vielversprechend:

• Besser als die Besten: Multi-DES übertraf die führenden bestehenden Methoden oder entsprach ihnen in den meisten Szenarien. Insbesondere erzielte es die besten Ergebnisse für die Metriken AUC (ein Maß dafür, wie gut das Modell zwischen fehlerhaftem und sauberem Code unterscheidet) und False Alarm (wie oft es Fehlalarm schlägt) in den meisten Datensätzen.
• Die Zahlen: Auf dem AEEEM-Datensatz erreichte Multi-DES eine AUC von 0,755 und schlug damit die nächstbeste Methode (EASC-NB), die einen Wert von 0,692 erreichte. Auf dem NASA-Datensatz erreichte es 0,737 im Vergleich zu 0,666.
• Robustheit: Das System war besonders gut darin, „False Alarms“ niedrig zu halten, was bedeutet, dass es die Zeit der Ingenieure nicht mit der Überprüfung von Code verschwendet, der eigentlich in Ordnung war.
• Kein Schummeln: Entscheidend ist, dass das System dies tat, ohne während der Trainingsphase irgendwelche Daten des neuen Zielprojekts zu betrachten. Es stützte sich vollständig auf die alten Projekte, was beweist, dass man nicht in die Geheimnisse des neuen Projekts hineinspähen muss, um einen guten Prädiktor aufzubauen.

Was sie ausgeschlossen haben

Das Paper argumentiert explizit gegen die Vorstellung, dass ein einzelnes, statisches Modell (ein fester Satz von Regeln, der auf das gesamte Projekt angewendet wird) die beste Lösung ist. Sie zeigen, dass, da verschiedene Teile eines Softwareprojekts unterschiedliche Merkmale aufweisen, ein „Einheitsansatz“ (One-size-fits-all) bei der Generalisierung schlecht abschneidet, wenn das neue Projekt sich von den Trainingsdaten unterscheidet. Sie schlossen auch die Idee aus, dass man die Datenverteilung des Zielprojekts im Voraus kennen muss, um gute Vorhersagen zu treffen; ihre Methode funktioniert auch dann, wenn das Zielprojekt ein völliges Mysterium ist.

Wie sicher sind sie sich?

Die Autoren sind aufgrund der gesammelten Daten von ihren Ergebnissen überzeugt. Sie haben nicht nur simuliert, sondern umfangreiche Experimente mit 82 realen Projekten unter Verwendung standardisierter, weitgehend akzeptierter Metriken durchgeführt. Sie verwendeten statistische Tests (den Wilcoxon-Signed-Rank-Test), um zu bestätigen, dass ihre Ergebnisse nicht bloß Glück waren. Das Paper stellt fest, dass Multi-DES in den meisten paarweisen Vergleichen „statistisch überlegen“ ist, insbesondere bei AUC und False Alarm. Sie merken jedoch eine kleine Ausnahme an: Beim PROMISE-Datensatz war ihre Methode nicht die absolut beste für die Metrik „False Alarm“, was zeigt, dass die Methode zwar stark ist, aber kein magisches Heilmittel ist, das nicht in jedem einzelnen Szenario gewinnt.

Kurz gesagt legt Multi-DES nahe, dass der beste Weg, Bugs in einem neuen, unbekannten Projekt vorherzusagen, darin besteht, ein diverses Team von Experten bereitzuhalten und den richtigen Experten für die jeweilige Aufgabe auszuwählen, anstatt zu versuchen, einen allgemeinen Generalisten für alles zu erzwingen.