Multi-stage Dynamic Selection for Cross-Project Defect Prediction

कल्पना कीजिए कि आप एक जासूस हैं जो एक रहस्य को सुलझाने की कोशिश कर रहे हैं, लेकिन आपने पहले कभी अपराध स्थल नहीं देखा है। आपके पास केवल अलग-अलग शहरों की पुरानी केस फाइलों का एक ढेर है, जो अलग-अलग पुलिस बलों द्वारा लिखी गई हैं और जिनमें अलग-अलग शब्दावली और आदतें हैं। आपका काम यह अनुमान लगाना है कि आपके नए शहर में अगला अपराधी कहाँ हमला करेगा। यह सॉफ्टवेयर इंजीनियरों का दैनिक संघर्ष है जो अपने प्रोग्राम को बग-मुक्त रखने की कोशिश करते हैं। वे चाहते हैं कि उनके कोड में "दोष" (बग्स) को तब ढूंढ लिया जाए जब सॉफ्टवेयर क्रैश हो जाए, लेकिन कई नए प्रोजेक्ट्स अभी 'ब्लैंक स्लेट' की तरह हैं: उनके पास गलतियों का इतिहास बनाने के लिए पर्याप्त समय नहीं हुआ है। इसलिए, इंजीनियर अन्य प्रोजेक्ट्स से सीखने की कोशिश करते हैं, इस उम्मीद में कि एक वीडियो गेम कंपनी के लिए जो काम आया, वह एक बैंकिंग ऐप को ठीक करने में भी मदद करेगा। इसे क्रॉस-प्रोजेक्ट डिफेक्ट प्रेडिक्शन (Cross-Project Defect Prediction) कहा जाता है। समस्या यह है कि हर प्रोजेक्ट अद्वितीय है; एक मॉडल जो एक पर पूरी तरह से काम करता है, वह दूसरे पर बुरी तरह विफल हो सकता है क्योंकि "अपराध स्थल" (कोड) बहुत अलग दिखते हैं।

यहाँ डिजिटल जासूसों की एक नई टीम आती है जिसे Multi-DES कहा जाता है। नए शहर में हर केस को सुलझाने के लिए एक अकेला जासूस नियुक्त करने के बजाय, या एक "सुपर-डिटेक्टिव" को एक साथ सभी मोहल्लों को समझने के लिए मजबूर करने के बजाय, यह टीम एक चतुर दो-चरणीय रणनीति का उपयोग करती है। सबसे पहले, वे पुराने केस फाइलों को देखते समय यह देखने के लिए कि विशेषज्ञों का कौन सा समूह मिलकर सबसे अच्छा काम करता है, विभिन्न जासूसों की एक विशाल भीड़ का ऑडिशन लेते हैं। फिर, जब एक नया केस आता है, तो वे केवल एक जासूस को नहीं चुनते। इसके बजाय, वे उस नए केस के विशिष्ट विवरणों को देखते हैं और तुरंत उस विशिष्ट स्थिति के लिए सबसे अच्छे विशेषज्ञ को बुलाते हैं। यह विशेषज्ञों की एक ऐसी टीम होने जैसा है जहाँ एक ट्रैफिक पुलिस दुर्घटना को संभालता है, एक फोरेंसिक अकाउंटेंट धोखाधड़ी के मामले को संभालता है, और एक वार्ताकार (negotiator) बंधक स्थिति को संभालता है, जिन्हें मौके पर ही चुना जाता है। शोधकर्ताओं ने पाया कि यह "सही क्षण के लिए सही विशेषज्ञ" वाला दृष्टिकोण, पुराने तरीकों की तुलना में जो हर चीज़ के लिए एक ही समाधान का उपयोग करने की कोशिश करते थे, नए और अज्ञात प्रोजेक्ट्स में बग खोजने में बहुत बेहतर है।

डिटेक्टिव एजेंसी: Multi-DES कैसे काम करता है

सॉफ्टवेयर की दुनिया में, एक "दोष" (defect) एक बग है—कोड में एक गलती जो प्रोग्राम को क्रैश कर सकती है या अजीब व्यवहार करा सकती है। इन बग्स की भविष्यवाणी करना महत्वपूर्ण है क्योंकि उन्हें जल्दी ढूंढने से समय और पैसा बचता है। लेकिन यहाँ एक पेच है: कंप्यूटर को बग पहचानने के लिए सिखाने के लिए, आपको आमतौर पर बग्स के बहुत सारे पिछले उदाहरणों की आवश्यकता होती है। नए प्रोजेक्ट्स के पास अभी ये उदाहरण नहीं होते हैं। इसलिए, इंजीनियर दूसरे, पुराने प्रोजेक्ट्स से ज्ञान उधार लेने की कोशिश करते हैं। यह "क्रॉस-प्रोजेक्ट" वाला हिस्सा है।

हालाँकि, एक बड़ी बाधा है: डिस्ट्रीब्यूशन शिफ्ट (Distribution Shift)। इसे ऐसे समझें जैसे आप एक ऐसे देश में ड्राइविंग सीखने की कोशिश कर रहे हैं जहाँ हर कोई बाईं ओर गाड़ी चलाता है, जबकि आपने केवल एक ऐसे मैनुअल से सीखा है जो उस देश के लिए लिखा गया है जहाँ हर कोई दाईं ओर गाड़ी चलाता है। नियम समान हैं, लेकिन विवरण उलट गए हैं। सॉफ्टवेयर में, एक प्रोजेक्ट एक विशिष्ट कोडिंग शैली का उपयोग कर सकता है, जबकि दूसरा पूरी तरह से अलग शैली का उपयोग कर सकता है। पारंपरिक तरीके एक विशाल मॉडल बनाने की कोशिश करते हैं जो इन सभी अंतरों को एक साथ समझने की कोशिश करता है। लेखक तर्क देते हैं कि यह दुनिया के हर शहर के लिए एक ही सामान्य मानचित्र (map) का उपयोग करने जैसा है; यह बहुत व्यापक है और स्थानीय गलियों को छोड़ देता है।

यह पेपर Multi-DES (मल्टी-स्टेज डायनेमिक एनसेम्बल सिलेक्शन) का प्रस्ताव देता है, जो सॉफ्टवेयर जासूसों की एक स्मार्ट, अनुकूलन योग्य भर्ती एजेंसी की तरह है। यह दो मुख्य चरणों में काम करता है:

चरण 1: बड़ा ऑडिशन (प्रोजेक्ट स्तर)
इससे पहले कि सिस्टम नए प्रोजेक्ट को देखे, यह एक विशाल "ओवरप्रोडक्शन" चरण से गुजरता है। एक कास्टिंग कॉल की कल्पना करें जहाँ वे प्रत्येक संभव संयोजन का परीक्षण करते हैं:

• बेस क्लासिफायर (Base Classifiers): विभिन्न प्रकार के एल्गोरिदम (जैसे डिसीजन ट्री, रैंडम फॉरेस्ट, आदि)। इन्हें विभिन्न प्रकार के जासूसों के रूप में सोचें (अवलोकन करने वाला, तार्किक, पैटर्न पहचानने वाला)।
• डायनेमिक सिलेक्शन तकनीकें (Dynamic Selection Techniques): यह तय करने के विभिन्न तरीके कि किस जासूस पर भरोसा किया जाए।
• पूल साइज (Pool Sizes): कमरे में कितने जासूस मौजूद हैं।

वे इन सभी संयोजनों (4 बेस एल्गोरिदम × 8 सिलेक्शन तकनीकें × 10 पूल साइज = 320 विभिन्न कॉन्फ़िगरेशन) का "ट्रेनिंग" प्रोजेक्ट्स पर परीक्षण करते हैं। लेकिन वे केवल उस एक को नहीं चुनते जिसे एक एकल परीक्षण पर उच्चतम स्कोर मिला हो। इसके बजाय, वे एग्रीगेट रैंक मिनिमाइजेशन (ARM) नामक रणनीति का उपयोग करते हैं।

ARM रणनीति: एक "ऑल-राउंडर" जज
एक टैलेंट शो की कल्पना करें जहाँ आपको गायन, नृत्य और अभिनय के आधार पर विजेता चुनना है। यदि आप केवल उस व्यक्ति को चुनते हैं जिसकी गायन की आवाज़ सबसे अच्छी है, तो हो सकता है कि वह अभिनय में बहुत खराब हो। ARM एक ऐसे जज की तरह है जो प्रत्येक प्रतियोगी को तीनों कौशलों पर रैंक देता है, फिर उन रैंकों को जोड़कर उस व्यक्ति को पाता है जो सबसे सुसंगत ऑल-राउंडर है। पेपर सुझाव देता है कि कई प्रदर्शन मेट्रिक्स (जैसे F1-स्कोर, AUC, और फॉल्स अलार्म) को एक साथ देखकर, सिस्टम एक ऐसा कॉन्फ़िगरेशन पाता है जो मजबूत (robust) है और विफल नहीं होगा जब नया प्रोजेक्ट पुराने प्रोजेक्ट्स से अलग दिखेगा।

चरण 2: ऑन-द-फ्लाई सिलेक्शन (मॉड्यूल स्तर)
एक बार जब चुने गए "ऑडिशन" कॉन्फ़िगरेशन को चुन लिया जाता है, तो सिस्टम नए प्रोजेक्ट के लिए तैयार हो जाता है। लेकिन यहाँ जादू है: यह पूरे प्रोजेक्ट के लिए एक ही मॉडल लागू नहीं करता है। सॉफ्टवेयर कई "मॉड्यूल" (जैसे घर के व्यक्तिगत कमरे या पुस्तक के अध्याय) से बना होता है।

जब सिस्टम नए प्रोजेक्ट के एक विशिष्ट मॉड्यूल को देखता है, तो वह पूछता है: "हमारे प्रशिक्षित जासूसों में से कौन इस विशेष प्रकार के कोड में बग पकड़ने में सबसे अच्छा है?" यह उस कोड के विशिष्ट हिस्से के लिए सबसे सक्षम क्लासिफायर को गतिशील रूप से चुनता है। यदि कोई मॉड्यूल एक बैंकिंग ऐप जैसा दिखता है, तो यह अपने पूल से "फाइनेंस एक्सपर्ट" को चुनता है। यदि दूसरा मॉड्यूल एक गेम इंजन जैसा दिखता है, तो यह "ग्राफिक्स एक्सपर्ट" को चुनता है। यह हर एक कोड के टुकड़े के लिए वास्तविक समय (real-time) में होता है।

उन्होंने क्या पाया

शोधकर्ताओं ने 82 सॉफ्टवेयर प्रोजेक्ट्स पर इस विचार का परीक्षण किया जो चार अलग-अलग सार्वजनिक डेटासेट (PROMISE, RELINK, NASA, और AEEEM) से लिए गए थे। उन्होंने "लीव-वन-प्रोजेक्ट-आउट" नामक एक सख्त परीक्षण पद्धति का उपयोग किया, जिसका अर्थ है कि उन्होंने 81 प्रोजेक्ट्स पर प्रशिक्षण लिया और 82वें प्रोजेक्ट में बग की भविष्यवाणी करने की कोशिश की, और फिर प्रत्येक प्रोजेक्ट के लिए इसे दोहराया।

परिणाम काफी उत्साहजनक थे:

• सर्वश्रेष्ठ से बेहतर: Multi-DES ने अधिकांश परिदृश्यों में शीर्ष मौजूदा तरीकों को पछाड़ दिया या उनके बराबर रहा। विशेष रूप से, इसने अधिकांश डेटासेट पर AUC (यह मापने का एक तरीका कि मॉडल बग वाले और साफ कोड के बीच कितनी अच्छी तरह अंतर करता है) और फॉल्स अलार्म (कितनी बार वह गलत चेतावनी देता है) मेट्रिक्स के लिए सर्वश्रेष्ठ परिणाम प्राप्त किए।
• आंकड़े: AEEEM डेटासेट पर, Multi-DES ने 0.755 का AUC स्कोर किया, जो अगले सर्वश्रेष्ठ तरीके EASC-NB (जिसका स्कोर 0.692 था) से बेहतर था। NASA डेटासेट पर, इसने 0.737 का स्कोर किया जबकि अगले सर्वश्रेष्ठ का स्कोर 0.666 था।
• मजबूती (Robustness): सिस्टम विशेष रूप रूप से "फॉल्स अलार्म" को कम रखने में अच्छा था, जिसका अर्थ है कि इसने इंजीनियरों का समय उन कोडों की जांच करने में बर्बाद नहीं किया जो वास्तव में ठीक थे।
• बिना धोखाधड़ी के: महत्वपूर्ण रूप से, सिस्टम ने प्रशिक्षण चरण के दौरान नए लक्षित प्रोजेक्ट के किसी भी डेटा को देखे बिना यह सब किया। यह पूरी तरह से पुराने प्रोजेक्ट्स पर निर्भर था, जिससे यह सिद्ध हुआ कि एक अच्छा भविष्यवक्ता बनाने के लिए आपको नए प्रोजेक्ट के रहस्यों को झाँकने की आवश्यकता नहीं है।

उन्होंने किसे खारिज किया

पेपर स्पष्ट रूप से इस विचार के विरुद्ध तर्क देता है कि एक एकल, स्थिर मॉडल (पूरे प्रोजेक्ट पर लागू होने वाला एक निश्चित सेट के नियम) सबसे अच्छा समाधान है। वे दिखाते हैं कि चूंकि सॉफ्टवेयर प्रोजेक्ट के विभिन्न हिस्सों की अलग-अलग विशेषताएं होती हैं, इसलिए "एक ही आकार सबके लिए उपयुक्त" (one-size-fits-all) वाला दृष्टिकोण तब अच्छी तरह से सामान्यीकरण (generalize) नहीं कर पाता जब नया प्रोजेक्ट प्रशिक्षण डेटा से भिन्न होता है। उन्होंने इस विचार को भी खारिज कर दिया कि अच्छी भविष्यवाणियां करने के लिए आपको लक्षित प्रोजेक्ट के डेटा वितरण को पहले से जानने की आवश्यकता है; उनका तरीका तब भी काम करता है जब लक्षित प्रोजेक्ट एक पूर्ण रहस्य हो।

वे कितने आश्वस्त हैं?

लेखक अपने निष्कर्षों को लेकर आश्वस्त हैं। उन्होंने केवल सिमुलेशन नहीं किया; उन्होंने मानक, व्यापक रूप से स्वीकृत मेट्रिक्स का उपयोग करके 82 वास्तविक-विश्व प्रोजेक्ट्स पर व्यापक प्रयोग चलाए। उन्होंने यह पुष्टि करने के लिए कि उनके परिणाम केवल भाग्य नहीं थे, "विल्कॉक्सन साइन्ड-रैंक टेस्ट" (Wilcoxon Signed-Rank test) का उपयोग करके सांख्यिकीय परीक्षण किए। पेपर कहता है कि Multi-DES अधिकांश युग्म तुलनाओं (pairwise comparisons) में "सांख्यिकीय रूप से श्रेष्ठ" है, विशेष रूप से AUC और फॉल्स अलार्म के लिए। हालाँकि, वे एक छोटा अपवाद भी नोट करते हैं: PROMISE डेटासेट पर, उनका तरीका "फॉल्स अलार्म" मेट्रिक के लिए सबसे अच्छा नहीं था, जो दर्शाता है कि हालांकि यह तरीका मजबूत है, यह कोई जादुई समाधान नहीं है जो हर बार हर परिदृश्य में जीत हासिल करे।

संक्षेप में, Multi-DES सुझाव देता है कि एक नए, अज्ञात प्रोजेक्ट में बग की भविष्यवाणी करने का सबसे अच्छा तरीका विशेषज्ञों की एक विविध टीम तैयार रखना है, और एक सामान्य विशेषज्ञ को सब कुछ करने के लिए मजबूर करने के बजाय, विशिष्ट कार्य के लिए सही विशेषज्ञ को चुनना है।