The Replication Assessment Problem in Software Engineering
यह शोधपत्र हाल के साहित्य की एक व्यवस्थित समीक्षा करके सॉफ्टवेयर इंजीनियरिंग में प्रतिकृति अध्ययनों (replication studies) के मूल्यांकन में मौजूद विसंगति और अस्पष्टता को संबोधित करता है ताकि पद्धतिगत दोषों की पहचान की जा सके और मूल्यांकन मानदंडों को मानकीकृत करने के लिए एक सिद्धांत-आधारित, सांख्यिकीय रूप से सुदृढ़ ढांचे का प्रस्ताव दिया जा सके।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
विज्ञान की कल्पना एक विशाल, वैश्विक "टेलीफोन" खेल के रूप में करें, लेकिन यहाँ संदेशों को एक लाइन में फुसफुसाकर नहीं, बल्कि वैज्ञानिक दुनिया भर में जटिल विचारों और प्रयोगों को साझा कर रहे हैं। सॉफ्टवेयर इंजीनियरिंग के क्षेत्र में, शोधकर्ता समस्याओं को हल करने के लिए उपकरण बनाते हैं, सिद्धांतों का परीक्षण करते हैं और कोड लिखते हैं। लेकिन यहाँ एक पेंच है: सिर्फ इसलिए कि एक टीम कहती है, "अरे, यह कोड पूरी तरह से काम करता है!" इसका मतलब यह नहीं है कि यह हर किसी के लिए काम करेगा। यहीं पर प्रतिकृति (replication) काम आती है। प्रतिकृति एक अलग समूह के दोस्तों से वही खेल उन्हीं नियमों के साथ खेलने के लिए पूछने जैसा है ताकि यह देखा जा सके कि क्या उन्हें वही स्कोर मिलता है। यह परम सत्य-जांच (truth-check) है। यदि पहली टीम जीतती है, और दूसरी टीम भी जीतती है, तो हम काफी आश्वस्त हो सकते हैं कि खेल पक्षपाती नहीं है। लेकिन यदि दूसरी टीम हार जाती है, या उसे बहुत अलग स्कोर मिलता है, तो हमें पूछना होगा: क्या उन्होंने गलत तरीके से खेला? क्या पहली टीम भाग्यशाली थी? या क्या खेल इतना कठिन है कि इसे दोबारा एक ही तरह से खेलना मुश्किल है?
बड़ा सवाल जिसने वैज्ञानिकों को परेशान कर रखा है वह यह है: हम कैसे तय करें कि दूसरी टीम वास्तव में "जीती" या "हारी"? अतीत में, यह एक रेफरी द्वारा अपने अंतर्ज्ञान के आधार पर "गोल!" या "नो गोल!" चिल्लाने जैसा था, या शायद केवल स्कोरबोर्ड को देखकर यह कहने जैसा था, "खैर, वे काफी करीब हैं, मुझे लगता है।" लेकिन बिना किसी स्पष्ट नियम पुस्तिका के, एक रेफरी एक खेल को सफलता घोषित कर सकता है जबकि दूसरा उसे विफलता कह सकता है, भले ही स्कोर बिल्कुल समान हों। यह एक विश्वसनीय ज्ञान का ढेर बनाना असंभव बना देता है, क्योंकि हमें नहीं पता कि कौन से खेल वास्तव में दोबारा खेलने लायक हैं।
महान स्कोरकार्ड रहस्य
इस शोध पत्र में, ग्यूसेप डेस्टेफ़ानिस, मार्टिन शेपरड और लैला यूसेफी ने यह पता लगाने के लिए जासूस की भूमिका निभाने का निर्णय लिया कि सॉफ्टवेयर इंजीनियर इन प्रतिकृति खेलों का निर्णय कैसे ले रहे हैं। उन्होंने कोई नया खेल नहीं बनाया; उन्होंने बस पिछले कुछ वर्षों (विशेष रूप से 2021 और 2025 के बीच प्रकाशित अध्ययनों) के स्कोरकार्ड को देखा ताकि यह देख सकें कि रेफरी अपना काम कैसे कर रहे थे।
उन्होंने पिछले सॉफ्टवेयर प्रयोगों को दोहराने की कोशिश करने वाले कुल 10 हालिया अध्ययन खोजे। जब उन्होंने स्कोरकार्ड पढ़ना शुरू किया, तो उन्हें एहसास हुआ कि रेफरी नियमों के एक अराजक मिश्रण का उपयोग कर रहे थे। यह ऐसा था जैसे कुछ रेफरी स्केल (रूलर) का उपयोग कर रहे थे, कुछ 'मैजिक 8-बॉल' का, और कुछ बस खिलाड़ियों को देखकर अनुमान लगा रहे थे।
स्कोरबोर्ड में अराजकता
लेखकों ने पाया कि इन अध्ययनों का निर्णय लेने का तरीका पूरी तरह से बिखरा हुआ था।
- "अंतर्ज्ञान" की समस्या: कई मामलों में, शोधकर्ताओं ने केवल "विशेषज्ञ निर्णय" (expert judgment) का उपयोग किया। यह एक ऐसे रेफरी की तरह है जो कहता है, "मैंने खेल देखा, और यह जीत जैसा महसूस हुआ," बिना कोई संख्या दिखाए या यह समझाए कि ऐसा क्यों था। 10 में से 3 अध्ययनों में, अंतिम निर्णय का कारण स्पष्ट रूप से बताया भी नहीं गया था। यह एक रहस्यमयी बॉक्स था!
- "मिश्रण" का जाल: तीन अध्ययनों ने इस सवाल को छोड़ने का फैसला किया कि "क्या यह विशिष्ट प्रतिकृति सफल रही?" और इसके बजाय उन्होंने मूल खेल और नए खेलों के सभी डेटा को एक बड़े बर्तन में मिला दिया ताकि औसत निकाला जा सके। लेखक इसे "पूलिंग" (pooling) कहते हैं। हालांकि डेटा को मिलाना बाद में उपयोगी हो सकता है, लेकिन यह शोध पत्र तर्क देता है कि आप यह जांचने के चरण को नहीं छोड़ सकते कि क्या नया खेल वास्तव में पुराने खेल से मेल खाता है। यह यह कहने जैसा है, "हमें नहीं पता कि यह नया खिलाड़ी अच्छा है, लेकिन अगर हम उनके आंकड़ों को पुरानी टीम के साथ मिला दें, तो औसत ठीक दिखता है!"
- लुप्त उपकरण: शोध पत्र बताता है कि रेफरी उपलब्ध सर्वोत्तम उपकरणों का उपयोग नहीं कर रहे थे। वे "प्रेडिक्शन इंटरवल्स" (जो स्कोरबोर्ड पर एक सुरक्षा क्षेत्र खींचने जैसा है यह देखने के लिए कि क्या नया स्कोर अपेक्षित सीमा के भीतर आता है) या "बायेसियन विधियों" (नया साक्ष्य आने पर अपने विश्वासों को अपडेट करने का एक शानदार तरीका) का उपयोग नहीं कर रहे थे। इसके बजाय, वे अक्सर सरल "हाँ/नहीं" जाँचों पर निर्भर थे जो स्थिति की सूक्ष्मता को समझने में विफल हो सकती हैं।
निर्णय पूरी तरह से अलग-अलग थे
जब लेखकों ने इन 10 अध्ययनों के अंतिम परिणामों को देखा, तो उत्तर भ्रमित करने वाले थे:
- 5 अध्ययनों ने कहा कि प्रतिकृति "आंशिक" या "मिश्रित" थी।
- 2 ने कहा कि यह "सफलता" थी।
- 1 ने कहा कि यह "विफल" रही।
- 1 ने इसे "अनिर्णायक" कहा।
- 1 अध्ययन ने 11 नए प्रयोग चलाने के बावजूद कोई अंतिम निर्णय तक नहीं दिया!
लेखकों द्वारा पाई गई सबसे बड़ी समस्या यह थी कि खेल शुरू होने से पहले स्पष्ट नियम लिखे बिना, यह जानना असंभव है कि "सफलता" वास्तविक है या केवल एक भाग्यशाली अनुमान। उदाहरण के लिए, एक अध्ययन ने दावा किया कि एक प्रतिकृति सफल थी क्योंकि एक विशेषज्ञ को ऐसा लगा, बिना यह बताए कि कौन सी संख्याएँ इसे विफलता मानतीं। एक अन्य अध्ययन ने दो संख्याओं की तुलना की लेकिन यह नहीं बताया कि उन्हें मैच मानने के लिए कितनी करीब होना चाहिए था।
नई नियम पुस्तिका
इस अव्यवस्था के कारण, लेखक स्कोरकार्ड को ठीक करने के लिए चार सिद्धांतों का एक नया सेट प्रस्तावित करते हैं। वे यह नहीं कह रहे हैं कि उन्होंने पूरी समस्या को हल कर लिया है; बल्कि वे चीजों को निष्पक्ष बनाने के लिए एक शुरुआती बिंदु प्रदान कर रहे हैं।
- नियम पहले लिखें: परिणाम देखने से पहले ही, आपको यह लिखना होगा कि जीत और हार किसे माना जाएगा। आप खेल खत्म होने के बाद नियम तय नहीं कर सकते क्योंकि आपको वह स्कोर पसंद आ गया है।
- केवल "जीत" नहीं, बल्कि "फिट" की जाँच करें: केवल यह पूछने के बजाय कि "क्या उन्हें उच्च स्कोर मिला?", यह पूछें कि "क्या नया स्कोर पुराने स्कोर के सुरक्षा क्षेत्र के भीतर फिट बैठता है?" यह यह देखने के बारे में है कि परिणाम संगत (compatible) हैं या नहीं, न कि केवल यह कि वे सांख्यिकीय रूप से महत्वपूर्ण हैं या नहीं।
- जाँच को न छोड़ें: आप यह जाँचने की कड़ी मेहनत से बचने के लिए सारा डेटा (पूलिंग) एक साथ नहीं मिला सकते कि क्या नया प्रयोग वास्तव में काम कर गया। आपको पहले व्यक्तिगत खेल की जाँच करनी होगी।
- "मुझे नहीं पता" कहना ठीक है: यदि डेटा बहुत अस्पष्ट है या संख्याएँ बहुत विस्तृत हैं, तो "सफलता" या "विफलता" का निर्णय देने के बजाय "अनिर्णायक" कहना बेहतर है। अनिश्चितता को स्वीकार करना यह दावा करने से अधिक ईमानदार है कि आप कुछ जानते हैं।
यह दिखाने के लिए कि यह कैसे काम करता है, लेखकों ने एक भ्रमित करने वाले अध्ययन (जहाँ एक विशेषज्ञ ने बस कहा "यह काम कर गया!") को लिया और नए नियमों का उपयोग करके उसका पुनर्मूल्यांकन किया। नई प्रणाली के तहत, चूंकि मूल अध्ययन ने नियम और संख्याएँ नहीं लिखी थीं, इसलिए निर्णय "सफलता" से बदलकर "अनिर्णायक" हो जाएगा। इसका मतलब यह नहीं है कि प्रयोग विफल हो गया; इसका मतलब केवल यह है कि हमारे पास अभी यह कहने के लिए पर्याप्त जानकारी नहीं है कि यह काम कर गया।
मुख्य निष्कर्ष
शोध पत्र निष्कर्ष निकालता है कि वर्तमान में, सॉफ्टवेयर इंजीनियरिंग प्रतिकृति एक ऐसे खेल की तरह है जहाँ रेफरी चलते-फिरते नियम बना रहे हैं। इन नए सिद्धांतों को अपनाकर—पहले नियम लिखना, अनुकूलता की जाँच करना और अनिश्चितता के बारे में ईमानदार रहना—हम ज्ञान का एक ऐसा ढेर बनाना शुरू कर सकते हैं जिस पर हर कोई भरोसा कर सके। लेखक स्वीकार करते हैं कि उन्होंने केवल 10 अध्ययनों को देखा है, इसलिए यह केवल बातचीत की शुरुआत है, अंतिम उत्तर नहीं। लेकिन यदि हम वास्तव में जानना चाहते हैं कि कौन से सॉफ्टवेयर उपकरण और सिद्धांत भरोसेमंद हैं, तो हमें अनुमान लगाना बंद करना होगा और एक स्पष्ट, साझा नियम पुस्तिका के अनुसार खेलना होगा।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।