अन्वेषण के लिए सॉफ्टवेयर: खोज में संतुलन हासिल करना

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

लेकिन बार-बार वे सभी प्रयास व्यर्थ गए। जिन शोध सॉफ़्टवेयरों पर मैंने काम किया उनमें से अधिकांश कभी उत्पादन में नहीं गए (हालाँकि कुछ ने उत्पादन किया)। यह मेरे मानसिक स्वास्थ्य के लिए बहुत अच्छा होता अगर कोई मुझे एक सरल सत्य बताता: मरने वाला अनुसंधान कोड वास्तव में वही होता है जो होना चाहिए। शोधकर्ताओं को सबसे पहले इसकी इंजीनियरिंग में अधिक समय नहीं लगाना चाहिए।

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

1. कुछ रणनीतिक तकनीकी ऋण लें

किसी कंपनी में एक सफल अनुसंधान परियोजना के दो चरण होते हैं: अन्वेषण और शोषण। "अन्वेषण" में आप जितना संभव हो उतने विविध समाधान आज़माना चाहते हैं। "शोषण" के दौरान आपको सर्वोत्तम समाधान को मजबूत करना होगा और इसे एक उपयोगी उत्पाद में बदलना होगा।

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

लेकिन पहले "अन्वेषण" चरण में आप ऐसी नींव नहीं बना रहे हैं जो हमेशा जीवित रहेगी। वास्तव में, यदि आपके अधिकांश प्रयास जीवित रहते हैं, तो आपने (परिभाषा के अनुसार) पर्याप्त अन्वेषण नहीं किया है।

इस पोस्ट में कई प्रथाएं इस बात के उदाहरण हैं कि आम तौर पर "तकनीकी ऋण" क्या बन जाएगा। स्वच्छ पुन: प्रयोज्य सारगर्भित कोड न लिखने से आपको यही मिलता है। क्या कर्ज हमेशा बुरा होता है? हम कभी भी ऋण या गिरवी नहीं लेना पसंद करते हैं, लेकिन पैसे उधार लेना अक्सर जीवन में एक अच्छी रणनीति होती है। तेजी से आगे बढ़ने और बाद में लाभ कमाने के लिए कर्ज में डूबना ठीक है।

इसी तरह, तकनीकी ऋण न लेकर आप अपने शोध को धीमा कर रहे हैं। अच्छी खबर यह है कि अधिकांश समय आपको इसका भुगतान नहीं करना पड़ता है। आपके अधिकांश शोध कोड वैसे भी ख़त्म होने की संभावना है। तो औसतन, आप अपने द्वारा लिए गए संपूर्ण तकनीकी ऋण से पीड़ित नहीं होंगे।

कोड के पुन: उपयोग के विरुद्ध मामला

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

कोड के पुन: उपयोग को सीमित करना तकनीकी ऋण का प्रकार है जिसे अनुसंधान में लेना ठीक है। कोड के पुन: उपयोग के कई पैटर्न हैं जिन पर मैं चर्चा करना चाहता हूं: एक अनावश्यक निर्भरता जोड़ना, कोड को कॉपीपेस्ट करना, बहुत सारे साझा अनुसंधान कोड को बनाए रखना, समय से पहले डिजाइन निवेश।

कुछ भी नया आयात करने से पहले दो बार सोचें

यदि आप एक सुव्यवस्थित संस्करण वाली लाइब्रेरी जानते हैं जो आपकी गति बढ़ा देगी - तो इसके लिए जाएं! लेकिन नई निर्भरता अपनाने से पहले, निर्णय लेने का प्रयास करें कि क्या यह इसके लायक है। प्रत्येक अतिरिक्त आपको निर्भरता नरक के करीब लाता है। यह आपको सीखने और समस्या निवारण में समय लगाने के लिए प्रेरित करता है। इस संक्षिप्त पोस्ट में निर्भरता के और अधिक नुकसान देखें।

किसी चीज़ पर निर्भर रहना संभवतः ठीक है यदि:

• आपने इसे पहले ही उपयोग कर लिया है, इसमें सीखने के लिए बहुत कुछ नहीं है, इसमें एक बड़ा समुदाय, अच्छे दस्तावेज़ और परीक्षण हैं
• यह संस्करणबद्ध है, स्थापित करना आसान है
• और अंततः, ऐसा कोई तरीका नहीं है जिससे आप इसे स्वयं लागू कर सकें।

• 
  

लेकिन निर्भरता के बारे में सावधान रहें यदि:

• आप समझ नहीं पा रहे हैं कि इसे तुरंत कैसे उपयोग किया जाए, यह बहुत नया (या बहुत पुराना) है या किसी को इसके बारे में पता नहीं है; कोई दस्तावेज़ या परीक्षण नहीं हैं

• यह आपके मोनोरेपो से है और अन्य टीमों द्वारा लगातार बदला जा रहा है

• यह कई अन्य निर्भरताएँ और उपकरण खींचता है; या इसे स्थापित करना कठिन है

• और अंत में, आपको लगता है कि आप (या कुछ एलएलएम) इस कोड को कुछ घंटों में लिख सकते हैं।

  
  

स्पष्ट निर्भरता के बजाय, आप एक अच्छी गो कहावत का पालन कर सकते हैं: " थोड़ी सी नकल थोड़ी निर्भरता से बेहतर है ", जो हमारा अगला विषय है।

कॉपीपेस्ट आपको प्रयोग करने की स्वतंत्रता देता है

कुछ लोग कहते हैं कि " कॉपी-पेस्ट अवैध होना चाहिए "। लेकिन मुझे आश्चर्य हुआ कि मैंने खुद को अक्सर इसके पक्ष में बहस करते हुए पाया। अन्वेषण चरण के दौरान कॉपीपेस्ट सर्वोत्तम विकल्प हो सकता है।

यदि आप कोडबेस के किसी अन्य भाग से अत्यधिक उपयोग किए जाने वाले फ़ंक्शन पर निर्भर हैं तो आप इसे आसानी से बदलना भूल सकते हैं। आपको किसी के लिए कुछ तोड़ने की संभावना है और आपको कोड समीक्षा और सुधार में अपना कीमती समय खर्च करना होगा। लेकिन यदि आप आवश्यक कोड को अपने फ़ोल्डर में कॉपी-पेस्ट करते हैं, तो आप इसके साथ कुछ भी करने के लिए स्वतंत्र हैं। अनुसंधान परियोजनाओं में यह एक बड़ी बात है जहां प्रयोग अपवाद के बजाय एक आदर्श है। विशेषकर यदि आप आश्वस्त नहीं हैं कि परिवर्तन सभी के लिए उपयोगी होंगे या नहीं।

मुझे लगता है कि डीप लर्निंग कोडबेस कॉपीपेस्ट करने के लिए सबसे उपयुक्त हैं। आमतौर पर, किसी मॉडल और उसके प्रशिक्षण का वर्णन करने के लिए आवश्यक कोड की मात्रा इतनी बड़ी नहीं होती है। लेकिन साथ ही इसे सामान्यीकृत करना बहुत सूक्ष्म और कठिन हो सकता है। साझा करने योग्य प्रशिक्षण स्क्रिप्ट असहनीय आकार तक बढ़ जाती हैं: उदाहरण के लिए हगिंग फेस transformers ट्रेनर में +4k लाइनें होती हैं। दिलचस्प बात यह है कि ट्रांसफार्मर ने मॉडल स्तर पर कॉपीपेस्ट का विकल्प चुना। कृपया उनकी "एकल फ़ाइल मॉडल" नीति के पीछे के तर्क के साथ उनकी पोस्ट देखें। अंत में कॉपीपेस्ट की सुंदरता के बारे में अधिक संसाधन देखें।

कॉपीपेस्ट का एक विकल्प शाखा पर रहना है। लेकिन मुझे ऐसा लगता है कि यह टीम वर्क में बहुत अधिक ओवरहेड लाता है। इसके अलावा, मुझे कॉपीपेस्ट की सुंदरता के बारे में कई और पोस्ट मिलीं - निष्कर्ष में और पोस्ट देखें।

साझा अनुसंधान कोड को बनाए रखना कठिन है

अत्यधिक उपयोग किए जाने वाले साझा कोड के रखरखाव के लिए बहुत अधिक काम की आवश्यकता होती है। Pytorch संस्करण के विरुद्ध प्लॉट की गई फ़ाइल पंक्तियों की torch.nn.Module संख्या पर एक नज़र डालें। आप देख सकते हैं कि सबसे उन्नत अनुसंधान टीमें भी जटिलता को नियंत्रण में रखने के लिए संघर्ष करती हैं।

एक बड़े साझा अनुसंधान कोड को बनाए रखने के लिए आवश्यक समय और संसाधनों को कम मत आंकिए। किसी शोध पुस्तकालय का जितना अधिक उपयोग किया जाता है वह उतना ही अधिक जटिल हो जाता है। यह सामान्य पुस्तकालय की तुलना में तेजी से होता है क्योंकि प्रत्येक शोध दिशा का उपयोग मामला थोड़ा अलग होता है। वापस क्या योगदान दिया जा सकता है, इसके लिए बहुत सख्त नियम स्थापित करें। अन्यथा, साझा कोड नाजुक हो जाता है और कई विकल्पों, छोटी-मोटी अनुकूलन और एजकेस से भर जाता है। चूंकि अधिकांश शोध कोड समाप्त हो जाते हैं, इसलिए इस अतिरिक्त जटिलता का दोबारा कभी उपयोग नहीं किया जाएगा। अपने कुछ साझा कोड को हटा देने से वास्तविक शोध करने के लिए कुछ समय खाली हो जाएगा।

अन्वेषण के लिए डिज़ाइन, कोड के पुन: उपयोग के लिए नहीं

यह कुछ हद तक सच है कि आप उत्पादन में भी अपने कोड को भविष्य में बहुत अधिक प्रूफ़ नहीं करना चाहते हैं। आवश्यकताओं को पूरा करने वाले सबसे सरल संभव समाधान को लागू करने का प्रयास करें। लेकिन उत्पादन कोड में हमेशा रखरखाव के पहलुओं पर विचार करना होता है। उदाहरण के लिए, त्रुटि प्रबंधन, गति, लॉगिंग, मॉड्यूलराइजेशन वह है जिसके बारे में आपको आमतौर पर सोचने की ज़रूरत है।

अनुसंधान कोड में, इनमें से कोई भी मायने नहीं रखता। आप बस जल्द से जल्द यह साबित करना चाहते हैं कि कोई विचार अच्छा है या बुरा और आगे बढ़ जाएं। तो बिना किसी मॉड्यूल या एपीआई के इसे प्राप्त करने वाली गंदी सादगी पूरी तरह से ठीक है!

समय से पहले सॉफ़्टवेयर निवेश पर अपना बहुमूल्य समय बर्बाद न करें जैसे:

• प्रोजेक्ट में बहुत जल्दी घटक इंटरफ़ेस बनाना। आप स्व-निर्मित कृत्रिम बाधाओं में फिट होने में बहुत अधिक समय व्यतीत करेंगे
• गहन शिक्षण समाधान के लिए प्रतिबद्ध होने से पहले गहन शिक्षण प्रशिक्षण बुनियादी ढांचे का अनुकूलन
• उत्पादन कॉन्फ़िगरेशन/कारखानों/क्रमांकन सिस्टम या बेस क्लास का उपयोग करना। अक्सर प्रोटोटाइप के दौरान आपको उनकी कार्यक्षमता की आवश्यकता नहीं होती है
• अत्यधिक सख्त लाइनिंग और टाइप चेकिंग सिस्टम। तेजी से बदलते थ्रो-अवे अनुसंधान कोड को धीमा करने का कोई कारण नहीं है।

2. तीव्र अन्वेषण में निवेश करें

एक शोध परियोजना का लक्ष्य एक नया समाधान खोजना है। कोई नहीं जानता (परिभाषा के अनुसार) यह कैसा दिखता है। यह सीमित जानकारी वाले जटिल अनुसंधान परिदृश्य में एक अनुकूलन प्रक्रिया के समान है। एक अच्छा न्यूनतम खोजने के लिए, आपको कई रास्ते आज़माने होंगे, अच्छे और बुरे रास्तों को पहचानना होगा और स्थानीय न्यूनतम में नहीं फंसना होगा। यह सब तेजी से करने के लिए, आपको कभी-कभी तकनीकी ऋण लेने के बजाय सॉफ्टवेयर निवेश करने की आवश्यकता होती है।

आम रास्तों को गति दें

ऐसे कई अलग-अलग शोध पथ हैं जिन्हें आप आज़माना चाहते हैं। क्या कोई ऐसा डिज़ाइन, कोई लाइब्रेरी या कोई अनुकूलन है जो अधिकांश पथों से समय निकाल देगा? आपको सावधान रहना चाहिए कि किसी भी चीज़ को अति-इंजीनियरिंग न करें क्योंकि आप हमेशा उन सभी विचारों को नहीं जानते हैं जिन्हें आप आज़माने वाले हैं। यह प्रत्येक प्रोजेक्ट के लिए बहुत ही कस्टम है, लेकिन यहां कुछ उदाहरण दिए गए हैं:

• यदि आप गहरे नेटवर्क को प्रशिक्षित करते हैं, तो प्रशिक्षण बुनियादी ढांचे में निवेश करें। हाइपरपैरामीटर का पता लगाएं जो आपको प्रशिक्षण के दौरान जल्दी और विश्वसनीय रूप से एकाग्र होने की अनुमति देता है
• यदि प्रत्येक प्रयोग के लिए आपको एक अलग मॉडल का उपयोग करने की आवश्यकता होती है, तो पता लगाएं कि आप उन्हें जल्दी से कैसे बदल सकते हैं (उदाहरण के लिए एक साधारण फ़ैक्टरी सिस्टम का उपयोग करके या केवल कॉपीपेस्ट करके)
• यदि प्रत्येक प्रयोग में बहुत अधिक पैरामीटर हैं और उन्हें प्रबंधित करना कठिन है, तो एक अच्छी कॉन्फ़िगरेशन लाइब्रेरी में निवेश करें।

जल्दी से शाखा लगाओ

शोधकर्ताओं को नए विविध विचारों को शीघ्रता से आरंभ करने में सक्षम होना चाहिए। प्रोजेक्ट की शुरुआत में यह आसान लगता है। लेकिन फिर यह धीरे-धीरे कठिन से कठिन होता जाता है क्योंकि लोग अपने पसंदीदा अनुसंधान पथों में फंस जाते हैं। इसे संबोधित करने के लिए सांस्कृतिक और संगठनात्मक परिवर्तन आवश्यक हैं। इसमें बहुत अधिक पैसा और भावनाएँ बहाने से पहले गैर-आशाजनक शोध को रोकने की एक प्रक्रिया होनी चाहिए। नियमित डेमो दिवस और तकनीकी सहकर्मी समीक्षाएँ इस उद्देश्य के लिए प्रभावी रणनीतियों के रूप में काम कर सकती हैं। किसी नए चमकदार विचार पर कूदने वाले लोगों और वर्तमान परियोजनाओं को ठीक से बंद करने के बीच संतुलन बनाना भी महत्वपूर्ण है।

लेकिन यह एक सॉफ्टवेयर पोस्ट है, इसलिए नई परियोजनाओं को आसान बनाने के लिए यहां कुछ अभ्यास दिए गए हैं:

• मूल्यांकन कोड को एल्गोरिदम से अलग रखें। मूल्यांकन आमतौर पर अनुसंधान दिशाओं की तुलना में अधिक स्थिर होते हैं
• एक खाली स्लेट से एक नया प्रोजेक्ट शुरू करना स्वीकार करें, लेकिन फिर देखें कि कौन से घटकों का पुन: उपयोग किया जाता है। उन्हें मॉड्यूलराइज़ करना और साफ़ करना एक अच्छा निवेश है
• किसी नए शोध प्रोजेक्ट में, सबसे नवीन और जोखिम भरे घटक को पहले लागू करें। ऐसा करने से भविष्य के सॉफ़्टवेयर डिज़ाइन को निर्देशित करने वाली अधिकांश बाधाओं की पहचान हो जाती है।

सिग्नल-शोर अनुपात बढ़ाएँ

शोर और गड़बड़ कोड परिणामों को इतना अस्पष्ट और अनिर्णायक बना देता है कि पूरा प्रोजेक्ट समय की बर्बादी हो जाएगा। हालाँकि आपको चीजों को ज़्यादा इंजीनियर नहीं करना चाहिए, आप गड़बड़ कोड से बचने के लिए आसानी से इन सरल नियमों का पालन कर सकते हैं:

• 
  

• दुष्प्रभाव वाले कोड से बचें

• कक्षाओं के बजाय फ़ंक्शंस में डिफ़ॉल्ट; और कक्षाओं के साथ, इनकैप्सुलेशन बनाम इनहेरिटेंस को प्राथमिकता दें

• कार्यों/वर्गों/मॉड्यूल की लंबाई न्यूनतम करें; यदि-कथनों की संख्या कम से कम करें

• पायथन को अच्छी तरह से जानें, लेकिन सरल तकनीकों का उपयोग करें। मेटाक्लासेस, डेकोरेटर्स और कार्यात्मक प्रोग्रामिंग के बौद्धिक जाल में जाने के प्रलोभन का विरोध करें।

  
  

अलग-अलग रन के दौरान अलग-अलग परिणाम देने वाले सॉफ़्टवेयर के साथ काम करना मुश्किल होता है। यदि आपने एक अशुभ बीज के आधार पर एक महत्वपूर्ण लेकिन गलत निर्णय लिया है, तो आप उबरने में बहुत समय बर्बाद करेंगे। गैर-नियतात्मक सॉफ़्टवेयर से निपटने के दौरान यहां कुछ सुझाव दिए गए हैं:

• समझें कि शोर एल्गोरिथम से आ रहा है या इसके मूल्यांकन से। शोर स्रोत यौगिक हैं और आपको पूरी तरह से नियतात्मक मूल्यांकन के लिए प्रयास करना चाहिए।
• जब तक आपको वास्तव में एक प्रतिलिपि प्रस्तुत करने योग्य स्क्रिप्ट नहीं मिल जाती, तब तक यादृच्छिकता के स्रोत ढूंढना बंद न करें। याद रखें कि सभी यादृच्छिक बीज खोजने के बाद, डेटा से या सामान्य कार्यों से साइड-इफेक्ट के साथ शोर आ सकता है।
• बीज अलग-अलग करें और अपने परिणामों का आधारभूत भिन्नता निर्धारित करें। गैर-सांख्यिकीय रूप से महत्वपूर्ण परिणामों पर निर्णय न लें।

निष्कर्ष

अनुसंधान कोड के बारे में इस पोस्ट से पंचलाइन आती है:

“आप [अच्छे सॉफ़्टवेयर डिज़ाइन] से परेशान नहीं होते क्योंकि कोड मुद्दा नहीं है। कोड एक उपकरण है जो आपको वह उत्तर देता है जिसकी आपको आवश्यकता है"।

बढ़िया कोडिंग फ़ाउंडेशन का होना बेहद ज़रूरी है। लेकिन दिन के अंत में, अन्वेषण और वास्तव में उपयोगी उत्पाद ही मायने रखता है। यदि आप अनुसंधान में बहुत अधिक उत्पादन सॉफ़्टवेयर का उपयोग करते हैं, तो आप कुछ नया खोजने के लिए आवश्यक समय बर्बाद करते हैं। इसके बजाय, वह खोजें जो आपकी अन्वेषण प्रक्रिया को धीमा कर देती है। तीव्र शाखाकरण, परिणामों के लिए समय और स्वच्छ शोर रहित कोड में निवेश करके अनुसंधान पथ को गति दें।

कोड के पुन: उपयोग के विरुद्ध पूरी तरह से बहस करना पागलपन होगा। मैं बस यह बताना चाहता हूं कि कोड का पुन: उपयोग एक अच्छी तरह से संतुलित गतिविधि होनी चाहिए। अनुसंधान में, थ्रो-अवे कोड का अनुपात उत्पादन की तुलना में बड़ा है। पुन: उपयोग के विरुद्ध संतुलन और अधिक झुका हुआ है। यहां कोड के पुन: उपयोग के नुकसान के बारे में कुछ और बेहतरीन पोस्ट दी गई हैं:

• पुन: प्रयोज्य कोड: अच्छा, बुरा और बदसूरत

• जब खुद को दोहराना उचित हो

• पुन: उपयोग के फायदे और नुकसान के साथ संतुलित स्टैक एक्सचेंज

  
  

और यहाँ कुछ और पोस्ट हैं जो कॉपीपेस्टिंग प्रथाओं के लिए बहस कर रहे हैं:

• क्या कॉपीपेस्ट वास्तव में एक समस्या है?

• आपको कोड कब कॉपी-पेस्ट करना चाहिए?

• कॉपी-पेस्ट प्रोग्रामिंग के अच्छे और बुरे पहलू

• "5 वर्ष की आयु वाले एक वरिष्ठ के रूप में, मुझे ऐसा लगता है कि मेरे वेतन का एक हिस्सा यह जानना है कि कौन सा कोड कॉपी करना है, हाहाहा"

  
  

पढ़ने के लिए आपका शुक्रिया! मुझे लगता है कि कुछ अंश थोड़े विवादास्पद हैं, कृपया मुझे टिप्पणियों में बताएं!