Removing Noise or Introducing Bias? The Hidden Cost of MSR Filtering
यह अध्ययन 1.57 मिलियन GitHub रिपॉजिटरीज़ का विश्लेषण करता है ताकि यह प्रदर्शित किया जा सके कि माइनिंग सॉफ़्टवेयर रिपॉजिटरीज़ (MSR) अनुसंधान में सामान्य फ़िल्टरिंग मानदंड महत्वपूर्ण रखरखाव, पारिस्थितिकी तंत्र और संबंध संबंधी पूर्वाग्रह पेश करते हैं जो प्रोजेक्ट परित्याग दरों और चर संबंधों को विकृत करते हैं, तथा स्तरित नमूनाकरण (stratified sampling) और परिष्कृत शोर पहचान (noise detection) की ओर बदलाव की वकालत करते हैं।
मूल पेपर CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने नहीं लिखा है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि इंटरनेट एक विशाल, अराजक पुस्तकालय है जहाँ कोई भी अपनी एक शेल्फ बना सकता है और उसे लाइब्रेरी कह सकता है। यह ओपन सोर्स सॉफ्टवेयर (OSS) की दुनिया है, जो एक विशाल डिजिटल खेल का मैदान है जहाँ लाखों लोग—छात्रों से लेकर जो कोडिंग के नए विचारों का परीक्षण कर रहे हैं, से लेकर पेशेवर डेवलपर्स तक जो अगला बड़ा ऐप बना रहे हैं—अपने प्रोजेक्ट्स को स्टोर करते हैं। शोधकर्ता, जो किसी जासूस की तरह होते हैं जो इस रहस्य को सुलझाने की कोशिश करते हैं कि सॉफ्टवेयर कैसे काम करता है, इस पुस्तकालय में आना पसंद करते हैं। वे शेल्फों को खंगालते हैं, यह देखते हैं कि कितने लोगों ने किसी प्रोजेक्ट को "पसंद" किया (stars), कितनी बार लोगों ने किताबों में बदलाव किए (commits), और कितने लोगों ने उन्हें लिखने में मदद की। ये सुराग उन्हें सॉफ्टवेयर इंजीनियरिंग के रहस्यों को समझने में मदद करते हैं। लेकिन यहाँ एक पेंच है: पुस्तकालय इतना विशाल है कि यह खाली बक्सों, नकली पुतलों और आधे-अधूरे रेखाचित्रों से भरा हुआ है। "असली" किताबों को खोजने के लिए, शोधकर्ता आमतौर पर उन चीजों को फेंक देते हैं जो पर्याप्त लोकप्रिय या व्यस्त नहीं दिखतीं। वे ऐसे नियम अपनाते हैं जैसे, "यदि किसी प्रोजेक्ट में 10 स्टार्स नहीं हैं, तो वह केवल शोर (noise) है, इसलिए चलो इसे हटा देते हैं।"
लेकिन क्या होगा अगर वे नियम सबसे दिलचस्प कहानियों को भी फेंक रहे हैं? क्या होगा अगर हम अपनी लाइब्रेरी को साफ करने की कोशिश में, अनजाने में इस तथ्य को छिपा देते हैं कि अधिकांश किताबें वास्तव में छोड़ी जा चुकी हैं, या हम केवल उन्हीं किताबों को पढ़ रहे हैं जो कुछ प्रसिद्ध लेखकों द्वारा लिखी गई हैं? यह वही बड़ा सवाल है जो शोधकर्ता मोहित कौशिक और ज्योति बावा पूछ रहे हैं। उन्हें चिंता है कि जिन फिल्टर्स का उपयोग वैज्ञानिक अपने डेटा को "साफ" बनाने के लिए करते हैं, वे उनके निष्कर्षों को "गंदा" बना सकते हैं क्योंकि वे सॉफ्टवेयर प्रोजेक्ट्स की वास्तविक, अव्यवस्थित वास्तविकता को छिपा देते हैं।
द ग्रेट फ़िल्टर: डेटा की सफाई या सच्चाई को छिपाना?
इस अध्ययन में, लेखकों ने डेटा के एक विशाल ढेर के साथ "क्या होगा अगर?" का खेल खेलने का निर्णय लिया। उन्होंने SEART नामक एक प्लेटफॉर्म से 1.57 मिलियन सॉफ्टवेयर रिपॉजिटरी (repositories) का अध्ययन किया। इस डेटासेट को मिश्रित लेगो (LEGO) ब्रिक्स की एक बड़ी बाल्टी के रूप में समझें। कुछ बड़े, रंगीन महल के सेट हैं; कुछ छोटे, एकल लाल ईंटें हैं; और कई तो बस टूटे हुए टुकड़े हैं जिन्हें कभी पूरा नहीं किया गया।
आमतौर पर, शोधकर्ता इस बाल्टी को देखते हैं और कहते हैं, "ठीक है, हम केवल बड़े, पूरे किए गए महलों को चाहते हैं। आइए उन चीजों को हटा दें जिनमें 10 स्टार्स (पसंद) या 10 कमिट्स (बदलाव) से कम हैं।" लेखकों ने यह परीक्षण किया कि जब वे इन सख्त नियमों को लागू करते हैं, तो क्या होता है, जैसे कि एक फिल्टर की आवाज़ को तब तक तेज़ करना जब तक कि वह बहुत तेज़ न हो जाए।
"लोकप्रियता" की छिपी हुई लागत
जब शोधकर्ताओं ने "लोकप्रियता फ़िल्टर" (अधिक स्टार्स वाले प्रोजेक्ट्स को देखना) लागू किया, तो उन्हें एक आश्चर्यजनक बात पता चली। जैसे-जैसे उन्होंने स्टार थ्रेशोल्ड (सीमा) को 10 से बढ़ाकर 1,000 किया, उनके सैंपल में "औसत" प्रोजेक्ट केवल थोड़ा बेहतर नहीं हुआ; बल्कि वह 7 गुना बड़ा हो गया। प्रोजेक्ट्स पुराने हो गए, उनमें अधिक लोग काम करने लगे, और उनके पास एक औपचारिक लाइसेंस (जैसे कि एक नियम पुस्तिका) होने की संभावना बहुत अधिक थी।
लेकिन यहाँ एक मोड़ है: लोकप्रिय प्रोजेक्ट्स के पीछे भागते हुए, उन्होंने वास्तविकता को पूरी तरह से खो दिया। उनकी मूल, बिना फिल्टर वाली बाल्टी में, 73.42% प्रोजेक्ट्स वास्तव में निष्क्रिय या "छोड़े हुए" (abandoned) थे। हालाँकि, जैसे ही उन्होंने लोकप्रियता के लिए फिल्टर लगाया, यह संख्या गिर गई। जब तक वे सुपर-पॉपुलर प्रोजेक्ट्स (1,000+ स्टार्स) को देख रहे थे, डेटा ने ऐसा दिखाया जैसे केवल 50.65% ही छोड़े गए थे। फिल्टर ने केवल शोर को हटाया नहीं; इसने इस तथ्य को छिपा दिया कि अधिकांश प्रोजेक्ट्स वास्तव में विफल हो जाते हैं या पीछे छूट जाते हैं। यह वैसा ही है जैसे यदि आप किसी शहर के सबसे सफल लोगों से उनकी नौकरियों के बारे में पूछें, और फिर यह निष्कर्ष निकालें कि "बेरोजगारी कम है" क्योंकि आपने कभी उन लोगों से बात ही नहीं की जिन्होंने अपनी नौकरियां खो दी थीं।
"सक्रियता" का जाल
लेखकों ने "एक्टिविटी फिल्टर" का भी परीक्षण किया, जो केवल उच्च कमिट्स (बदलावों) वाले प्रोजेक्ट्स को रखते हैं। यह और भी चरम था। जब उन्होंने उच्च सक्रियता के लिए फिल्टर किया, तो औसत प्रोजेक्ट का आकार 18 गुना बढ़ गया! इन फिल्टर्स ने सॉफ्टवेयर के "व्यक्तित्व" को भी बदल दिया। उदाहरण के लिए, C++ भाषा का उपयोग करने वाले प्रोजेक्ट्स निचले-थ्रेशोल्ड समूहों में आम थे लेकिन जैसे ही फिल्टर सख्त हुआ, वे शीर्ष 5 में से गायब हो गए। इस बीच, TypeScript और Go फिल्टर की गई सूचियों में बहुत अधिक सामान्य हो गए।
अध्ययन बताता है कि ये फिल्टर तटस्थ नहीं हैं। वे एक छलनी की तरह काम करते हैं जो केवल विशिष्ट प्रकार के प्रोजेक्ट्स को ही गुजरने देते हैं: पुराने, विशाल, अच्छी तरह से वित्त पोषित इंफ्रास्ट्रक्चर प्रोजेक्ट्स। वे छोटे, नए या अधिक प्रयोगात्मक प्रोजेक्ट्स को बाहर धकेल देते हैं, भले ही वे छोटे प्रोजेक्ट्स वास्तविक और सक्रिय हों।
संबंधों का खेल
शायद सबसे चंचल (और खतरनाक) निष्कर्ष विभिन्न चीजों के बीच संबंधों के बारे में है। कल्पना कीजिए कि आप यह पता लगाने की कोशिश कर रहे हैं कि क्या "कड़ी मेहनत" (कमिट्स) से "लोकप्रियता" (स्टार्स) मिलती है। वास्तविक, अव्यवस्थित दुनिया (बेसलाइन डेटा) में, ये दो चीजें केवल कमजोर रूप से जुड़ी हुई हैं। लेकिन जब शोधकर्ताओं ने अपने फिल्टर लागू किए, तो यह संबंध अचानक बहुत मजबूत दिखने लगा।
उदाहरण के लिए, "कमिट्स" और "प्रोजेक्ट साइज" के बीच का संबंध एक्टिविटी-फिल्टर्ड ग्रुप में मध्यम 0.466 से बढ़कर बहुत मजबूत 0.808 हो गया। लेखक बताते हैं कि ऐसा इसलिए नहीं है क्योंकि प्रोजेक्ट्स वास्तव में बदले हैं; बल्कि इसलिए है क्योंकि फिल्टर ने उन्हें इस तरह दिखने के लिए मजबूर किया। केवल बड़े, व्यस्त प्रोजेक्ट्स को रखकर, फिल्टर ने ऐसा दिखाया जैसे "बड़े प्रोजेक्ट्स में हमेशा बहुत सारे कमिट्स होते हैं", जबकि वास्तव में, संबंध बहुत अधिक जटिल है। यह वैसा ही है जैसे यदि आप केवल सबसे लंबे बास्केटबॉल खिलाड़ियों का अध्ययन करें और निष्कर्ष निकालें कि "खेलों में केवल ऊंचाई ही मायने रखती है," बाकी सभी को अनदेखा करते हुए।
फैसला: शोर को बस फेंक न दें
लेखक निष्कर्ष निकालते हैं कि हालांकि हमें अपने डेटा को साफ करने की आवश्यकता है, लेकिन हम बिना सोचे-समझे "10 स्टार्स" या "500 कमिट्स" जैसे मनमाने नियम नहीं अपना सकते। ये नियम एक कुंद हथौड़े की तरह हैं: वे "शोर" को तो तोड़ देते हैं, लेकिन वे सच्चाई को भी तोड़ देते हैं। वे एक विकृत तस्वीर बनाते हैं जहाँ सॉफ्टवेयर प्रोजेक्ट्स वास्तव में जितने हैं, उससे कहीं अधिक सफल, पुराने और एक समान दिखाई देते हैं।
बिना सोचे-समझे फिल्टर करने के बजाय, लेखक सुझाव देते हैं कि शोधकर्ताओं को स्तरीकृत नमूनाकरण (stratified sampling) का उपयोग करना चाहिए। कल्पना कीजिए कि लेगो बाल्टी में से एक ऐसा स्कूप लेना जिसमें बड़े महलों, छोटे घरों और टूटे हुए टुकड़ों का एक उचित मिश्रण हो, बजाय इसके कि केवल सबसे बड़े महलों को चुना जाए। वे वैज्ञानिकों से यह भी आग्रह करते हैं कि वे "शोर" के अर्थ पर पुनर्विचार करें। शायद शून्य स्टार वाला प्रोजेक्ट केवल एक विफल प्रयोग नहीं है; शायद वह एक छिपा हुआ रत्न है जिसे अभी तक खोजा नहीं गया है।
संक्षेप में, यह पेपर हमें चेतावनी देता है कि "परफेक्ट" डेटा खोजने की जल्दबाजी में, हम शायद ताश के पत्तों का एक ऐसा घर बना रहे हैं जो बाहर से तो एकदम सही दिखता है लेकिन जैसे ही हम वास्तविक, अव्यवस्थित दुनिया को समझने की कोशिश करते हैं, वह ढह जाता है। लेखक यह नहीं कहते कि हमें पूरी तरह से फिल्टर करना बंद कर देना चाहिए, लेकिन वे दृढ़ता से सुझाव देते हैं कि हम इन "एक ही आकार के सभी के लिए" (one-size-fits-all) वाले नियमों का उपयोग करना बंद करें और इस बारे में अधिक सावधान रहें कि हम वास्तव में क्या फेंक रहे हैं।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।