हमने एमएल परीक्षण अभ्यास विकसित करने का फैसला क्यों किया

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

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

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

इस संबंध में, हमें कई समस्याओं का सामना करना पड़ रहा है:

• क्या हमारा अनुकूलन मॉडल हमेशा संभव उत्पादन बाधाओं को ध्यान में रखता है?
  
• क्या हमारे मॉडल अड़चनों के साथ काम करने में सक्षम हैं?
  
• क्या हमारा मॉडल उत्पादन परिवर्तनों का सही ढंग से जवाब देने में सक्षम है?
  

यह वह जगह है जहां हमने परीक्षण टीम पर ध्यान केंद्रित करने का फैसला किया।

हमारा कार्य उपरोक्त सभी समस्याओं का जवाब देने में सक्षम होने के लिए एमएल परीक्षण अभ्यास को एकजुट करना है। फिलहाल, हम कई निष्कर्षों पर आए हैं, और अब मैं आपको बताऊंगा कि कौन से हैं।

अनुकूलन एल्गोरिथ्म द्वारा उनके विचार के लिए उत्पादन प्रतिबंध और आवश्यकताओं के अनुपालन का परीक्षण करें

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

सामग्री एन के उत्पादन को अनुकूलित करने के लिए एक वास्तविक परियोजना के उदाहरण पर (हमने अभी तक मामले का खुलासा नहीं किया है, इसलिए हम गुमनाम नामों का उपयोग करेंगे), हमने इस मुद्दे को निम्नानुसार हल किया:

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

इस प्रकार, हम प्रतिगमन परीक्षण की समस्या को हल करने और आत्मविश्वास हासिल करने में सक्षम थे कि मॉडल में पेश किए गए परिवर्तन हमारे काम के पहले परिणामों को प्रभावित नहीं करते हैं।

परीक्षण अड़चनों पर केंद्रित है

अनुकूलन मॉडल सबसे अच्छा अनुमान लगाने में सक्षम हैं कि ऐतिहासिक डेटा में सबसे अधिक बार क्या पाया जाता है, और, इसके विपरीत, एक मॉडल "कद्दू में बदल सकता है" जैसे ही वह अपने लिए कुछ असामान्य सामना करता है।

अक्सर ऐसे मामलों में, अनुकूलन सेवा में एक पर्याप्त व्यवहार मॉडल "प्रॉम्प्ट" होता है और यह उस हार्डकोड को उत्पन्न करता है जिसे मैंने पहले लिखा था। लेकिन इन बाधाओं को कैसे पहचानें और सेवा को डिबग करें? मैं इस बारे में बताऊंगा कि सामग्री एन के उत्पादन के प्रबंधन के लिए सिफारिशों के लिए एक सेवा विकसित करने के उदाहरण पर (मामला अभी तक प्रकटीकरण के अधीन नहीं है, इसलिए, घूंघट नामों को नीचे संदर्भित किया गया है)।

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

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

मॉडल को उत्पादन परिवर्तनों का जवाब देने में सक्षम होना चाहिए।

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

इस सेवा को विकसित करने की प्रक्रिया में, हमें एक जिज्ञासु समस्या का सामना करना पड़ा जिसे हम पहले से समझ नहीं सकते थे।

कई वर्षों के लिए ईंधन के उत्पादन में कंपनी ने एक निश्चित श्रेणी के क्रांतियों में काम किया और साथ ही साथ घटकों के समान अनुपात का प्लस / माइनस उपयोग किया।

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

1. बाधाओं और संभावित उत्पाद परिवर्तनों की पहचान करने के लिए उत्पादन इकाई से ग्राहक प्रतिनिधि के साथ अधिक निकटता से काम करें।
   
2. पहले से ही समान मामलों के साथ कवर मामलों को कवर करें।
   
3. उत्पादन प्रतिबंधों और संकेतों के सहसंबंध के अनुपालन की जांच करने के लिए ऑटोटेस्ट्स लिखें।
   

परीक्षण उपकरणों के बारे में कुछ शब्द जो हमें उपयोग करने थे:

• बगट्रैकिंग - जीरा,
  
• गुणवत्ता प्रबंधन प्रणाली - टेस्ट रेल,
  
• संस्करण नियंत्रण प्रणाली - GitLab,
  
• सीआई / सीडी - जेनकिंस,
  
• ऑटोटेस्ट्स - जावा + जूनिट / टेस्टएनजी,
  
• मॉडल के साथ सीधे संपर्क के लिए स्क्रिप्ट - पायथन + ज्यूपिटर।
  

क्या आप एमएल का परीक्षण करते हैं?

हमारे लिए, एक एमएल परीक्षण अभ्यास का निर्माण एक चुनौती बन गया है, इसे वास्तव में खरोंच से उगाया जाना था। लेकिन परीक्षण आवश्यक है - यह परीक्षण ऑपरेशन में जाने से पहले त्रुटियों की संख्या को कम करने और कार्यान्वयन समय को कम करने में मदद करता है।

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

सर्गेई अगल्त्सोव, टेस्ट मैनेजर, जेट इंफोसिस्टम्स