प्रोडक्शन एमएल में, लक्ष्य कोई एक मॉडल बनाना और उसे डिप्लॉय करना नहीं होता. इसका लक्ष्य समय के साथ मॉडल डेवलप करने, टेस्ट करने, और डिप्लॉय करने के लिए, अपने-आप काम करने वाली पाइपलाइन बनाना है. ऐसा क्यों हो रहा है? दुनिया बदलने के साथ-साथ डेटा में बदलाव भी होते हैं. इस वजह से, प्रोडक्शन में चल रहे मॉडल पुराने हो जाते हैं. लंबी अवधि के लिए अच्छी क्वालिटी के अनुमान दिखाना जारी रखने के लिए, मॉडल को आम तौर पर अप-टू-डेट डेटा की मदद से फिर से ट्रेनिंग की ज़रूरत होती है. दूसरे शब्दों में, आपको पुराने मॉडल को नए मॉडल से बदलने का कोई तरीका चाहिए.
पाइपलाइन के बिना, पुराने मॉडल को बदलने की प्रोसेस में गड़बड़ी हो सकती है. उदाहरण के लिए, जब किसी मॉडल ने खराब अनुमान दिखाना शुरू कर दिया, तो किसी व्यक्ति को मैन्युअल तरीके से नया डेटा इकट्ठा और प्रोसेस करना होगा, नए मॉडल को ट्रेनिंग देनी होगी, उसकी क्वालिटी की पुष्टि करनी होगी, और आखिर में उसे डिप्लॉय करना होगा. मशीन लर्निंग पाइपलाइन से, बार-बार होने वाली कई प्रोसेस को ऑटोमेट किया जाता है. इससे मॉडल का मैनेजमेंट और रखरखाव ज़्यादा आसान और भरोसेमंद हो जाता है.
पाइपलाइन बनाना
एमएल पाइपलाइन, अच्छी तरह से तय किए गए कामों में मॉडल बनाने और उन्हें डिप्लॉय करने के चरणों को व्यवस्थित करती हैं. पाइपलाइन के दो फ़ंक्शन होते हैं: अनुमान डिलीवर करना या मॉडल को अपडेट करना.
सुझाव देना
सर्विंग पाइपलाइन आपको सुझाव देती है. यह आपके मॉडल को वास्तविक दुनिया के बारे में बताता है, जिससे आपके उपयोगकर्ता उसे ऐक्सेस कर सकते हैं. उदाहरण के लिए, जब कोई उपयोगकर्ता यह जानना चाहता है कि आने वाले समय में मौसम कैसा रहेगा या हवाई अड्डे तक पहुँचने में कितने मिनट लगेंगे, तब सर्विंग पाइपलाइन में वीडियो की सूची दिखती है, जो उपयोगकर्ता के डेटा को प्रोसेस करती है, एक अनुमान लगाती है, और फिर उपयोगकर्ता को डिलीवर कर देती है.
मॉडल अपडेट करना
प्रोडक्शन शुरू होने के तुरंत बाद, मॉडल पुराने हो जाते हैं. इसका मतलब यह है कि वे पुरानी जानकारी का इस्तेमाल करके अनुमान लगा रहे हैं. उनके ट्रेनिंग डेटासेट ने एक दिन पहले या कुछ मामलों में एक घंटे पहले दुनिया की स्थिति की जानकारी दी थी. निस्संदेह दुनिया बदल गई है: उपयोगकर्ता ने ज़्यादा वीडियो देखे हैं और उन्हें सुझावों की नई सूची चाहिए; बारिश की वजह से ट्रैफ़िक धीमा हो गया है और उपयोगकर्ताओं को अपने पहुंचने के समय के लिए अपडेट किए गए अनुमानों की ज़रूरत है; एक लोकप्रिय रुझान की वजह से खुदरा दुकानदार कुछ आइटम के लिए, अपडेट की गई इन्वेंट्री का अनुमान लगाने के लिए अनुरोध करते हैं.
आम तौर पर, प्रोडक्शन मॉडल पुराना होने से पहले ही टीमें नए मॉडल को ट्रेनिंग देती हैं. कुछ मामलों में, टीमें लगातार ट्रेनिंग और डिप्लॉयमेंट साइकल के हिसाब से, रोज़ नए मॉडल को ट्रेनिंग देती हैं और उन्हें डिप्लॉय करती हैं. आम तौर पर, प्रोडक्शन मॉडल के खराब होने से पहले ही नए मॉडल को ट्रेनिंग दी जानी चाहिए.
नए मॉडल को ट्रेनिंग देने के लिए, ये पाइपलाइन साथ मिलकर काम करती हैं:
- डेटा पाइपलाइन. डेटा पाइपलाइन, ट्रेनिंग और टेस्ट डेटासेट बनाने के लिए, उपयोगकर्ता के डेटा को प्रोसेस करती है.
- ट्रेनिंग पाइपलाइन. ट्रेनिंग पाइपलाइन, डेटा पाइपलाइन से नए ट्रेनिंग डेटासेट का इस्तेमाल करके मॉडल को ट्रेनिंग देती है.
- पुष्टि करने की प्रोसेस. पुष्टि करने वाले पाइपलाइन से, ट्रेन किए गए मॉडल की पुष्टि की जाती है. इसके लिए, उसकी तुलना प्रोडक्शन मॉडल से की जाती है. इसके लिए, डेटा पाइपलाइन से जनरेट किए गए टेस्ट डेटासेट का इस्तेमाल किया जाता है.
इमेज 4 में, हर एमएल पाइपलाइन के इनपुट और आउटपुट दिखाए गए हैं.
एमएल पाइपलाइन
चौथी इमेज. एमएल पाइपलाइन, मॉडल बनाने और उनका रखरखाव करने के लिए कई प्रोसेस को ऑटोमेट करती हैं. हर पाइपलाइन में अपने इनपुट और आउटपुट दिखते हैं.
सामान्य तौर पर, यहां बताया गया है कि पाइपलाइन से प्रोडक्शन में नया मॉडल कैसे बनाया जाता है:
सबसे पहले, मॉडल को प्रोडक्शन में भेजा जाता है. इसके बाद, काम करने की सुविधा अनुमान डिलीवर करना शुरू कर देती है.
डेटा पाइपलाइन नई ट्रेनिंग और टेस्ट डेटासेट बनाने के लिए, तुरंत डेटा इकट्ठा करना शुरू कर देती है.
किसी शेड्यूल या ट्रिगर के आधार पर, ट्रेनिंग और पुष्टि करने वाली पाइपलाइन, डेटा पाइपलाइन से जनरेट हुए डेटासेट का इस्तेमाल करके नए मॉडल को ट्रेनिंग देती हैं और उसकी पुष्टि करती हैं.
जब पुष्टि करने वाले प्रोसेस से यह पुष्टि होती है कि नया मॉडल, प्रोडक्शन मॉडल से खराब नहीं है, तो नया मॉडल डिप्लॉय किया जाता है.
यह प्रक्रिया लगातार दोहराई जाती है.
मॉडल की गति और ट्रेनिंग की फ़्रीक्वेंसी
करीब सभी मॉडल पुराने हो गए हैं. कुछ मॉडल दूसरे की तुलना में तेज़ी से पुराने होते हैं. उदाहरण के लिए, कपड़ों का सुझाव देने वाले मॉडल, आम तौर पर जल्दी खराब हो जाते हैं, क्योंकि उपभोक्ता की पसंद बार-बार बदलने के लिए बदनाम होते हैं. वहीं दूसरी ओर, फूलों की पहचान करने वाले मॉडल शायद पुराने न हों. फूल की पहचान करने वाली विशेषताएं स्थिर रहती हैं.
प्रोडक्शन में डाले जाने के तुरंत बाद, ज़्यादातर मॉडल पुराने होने लगते हैं. आप एक ऐसी ट्रेनिंग फ़्रीक्वेंसी सेट करना चाहेंगे जिससे यह पता चले कि आपका डेटा किस तरह का है. अगर डेटा डाइनैमिक है, तो समय-समय पर ट्रेनिंग दें. अगर यह कम डाइनैमिक है, तो हो सकता है कि आपको इसे बार-बार ट्रेनिंग देने की ज़रूरत न पड़े.
मॉडल को पुराने होने से पहले ट्रेनिंग दें. शुरुआती ट्रेनिंग, संभावित समस्याओं को हल करने के लिए बफ़र करती है. जैसे, अगर डेटा या ट्रेनिंग पाइपलाइन काम नहीं करती या मॉडल की क्वालिटी खराब है.
हमारा सुझाव है कि हर दिन नए मॉडल को ट्रेनिंग दें और डिप्लॉय करें. यह सबसे सही तरीका है. आम सॉफ़्टवेयर प्रोजेक्ट की तरह ही हर दिन बनाने और रिलीज़ करने की प्रक्रिया होती है. ट्रेनिंग और पुष्टि के लिए मशीन लर्निंग पाइपलाइन भी रोज़ चलने पर सबसे अच्छी तरह काम करती हैं.
सर्विंग पाइपलाइन
सर्विंग पाइपलाइन दो में से किसी एक तरीके से पूर्वानुमान जनरेट और डिलीवर करती है: ऑनलाइन या ऑफ़लाइन.
ऑनलाइन अनुमान. ऑनलाइन अनुमान रीयल टाइम में होते हैं. आम तौर पर, ऐसा ऑनलाइन सर्वर पर अनुरोध भेजकर और अनुमान दिखाकर होता है. उदाहरण के लिए, जब कोई उपयोगकर्ता सुझाव चाहता है, तो उपयोगकर्ता के डेटा को मॉडल पर भेजा जाता है और मॉडल अनुमान दिखाता है. उदाहरण के लिए, Gmail, आने वाले मैसेज को रीयल टाइम में अलग-अलग कैटगरी में बांटता है. इसके लिए, ऑनलाइन मिलने वाले सुझावों का इस्तेमाल किया जाता है.
ऑफ़लाइन अनुमान. ऑफ़लाइन अनुमान पहले से कैलकुलेट किए जाते हैं और कैश मेमोरी में सेव किए जाते हैं. अनुमान दिखाने के लिए, ऐप्लिकेशन डेटाबेस में कैश मेमोरी में सेव किया गया अनुमान खोजता है और उसे दिखाता है. उदाहरण के लिए, सदस्यता पर आधारित सेवा, अपने सदस्यों की सदस्यता छोड़ने की दर का अनुमान लगा सकती है. यह मॉडल, हर सदस्य के चर्न आउट होने की संभावना का अनुमान लगाता है और इसे कैश मेमोरी में सेव करता है. जब ऐप्लिकेशन को पूर्वानुमान की ज़रूरत होती है—उदाहरण के लिए, ऐसे उपयोगकर्ताओं को इंसेंटिव देने के लिए जो चर्न आउट होने वाले हैं—तो यह पहले से तय किया गया अनुमान है.
इमेज 5 में दिखाया गया है कि ऑनलाइन और ऑफ़लाइन अनुमान कैसे जनरेट होते हैं और कैसे डिलीवर किए जाते हैं.
ऑनलाइन और ऑफ़लाइन अनुमान
पांचवी इमेज. ऑनलाइन सुझाव, रीयल टाइम में अनुमान दिखाते हैं. ऑफ़लाइन अनुमानों को कैश मेमोरी में सेव किया जाता है और उन्हें पेश करते समय देखा जाता है.
अनुमान की पोस्ट-प्रोसेसिंग
आम तौर पर, डिलीवरी के पहले अनुमान प्रोसेस हो जाते हैं. उदाहरण के लिए, बुरा बर्ताव या पक्षपातपूर्ण कॉन्टेंट को हटाने के लिए, अनुमानों को प्रोसेस करने के बाद ऐसा किया जा सकता है. क्लासिफ़िकेशन के नतीजों में, मॉडल का रॉ आउटपुट दिखाने के बजाय नतीजों का क्रम बदलने के लिए ट्विडिंग का इस्तेमाल किया जा सकता है. जैसे, ज़्यादा भरोसेमंद कॉन्टेंट को बढ़ावा देना, अलग-अलग तरह के नतीजे दिखाना, किसी खास नतीजे (जैसे क्लिकबेट) का दर्जा बढ़ाना या कानूनी वजहों से नतीजों को हटाना.
इमेज 6 में एक सेवा पाइपलाइन और अनुमान डिलीवर करने में शामिल सामान्य कामों को दिखाया गया है.
प्रोसेस के बाद का अनुमान
छठी इमेज. अनुमान लगाने के लिए किए जाने वाले सामान्य कामों को दिखाने वाली सर्विंग पाइपलाइन.
ध्यान दें कि फ़ीचर इंजीनियरिंग वाला चरण आम तौर पर मॉडल में ही बनाया जाता है, न कि यह अपने-आप में लागू होता है. काम करने की सुविधा में मौजूद डेटा प्रोसेसिंग कोड, अक्सर उस डेटा प्रोसेसिंग कोड के जैसा होता है जिसका इस्तेमाल, ट्रेनिंग और डेटासेट बनाने के लिए डेटा पाइपलाइन करता है.
एसेट और मेटाडेटा स्टोरेज
सर्विंग पाइपलाइन में, मॉडल के अनुमानों को लॉग करने के लिए, डेटा स्टोर करने की जगह होनी चाहिए और अगर मुमकिन हो, तो ज़मीनी जानकारी भी शामिल करनी चाहिए.
मॉडल के अनुमानों को लॉग करने से, आपको अपने मॉडल की क्वालिटी को मॉनिटर करने में मदद मिलती है. अनुमानों को इकट्ठा करके, अपने मॉडल की सामान्य क्वालिटी को मॉनिटर किया जा सकता है और यह भी तय किया जा सकता है कि कहीं इसकी क्वालिटी खराब तो नहीं हो रही. आम तौर पर, प्रोडक्शन मॉडल के अनुमानों का औसत, ट्रेनिंग डेटासेट के लेबल के बराबर होना चाहिए. ज़्यादा जानकारी के लिए, पूर्वाग्रह देखें.
ज़मीनी हकीकत का पता लगाना
कुछ मामलों में, असली जानकारी सिर्फ़ कुछ समय बाद उपलब्ध होती है. उदाहरण के लिए, अगर मौसम की जानकारी देने वाला कोई ऐप्लिकेशन, छह हफ़्तों तक आने वाले समय के मौसम का अनुमान लगाता है, तो छह हफ़्तों तक ज़मीनी हकीकत (असल में मौसम कैसा है) उपलब्ध नहीं होगी.
जब भी मुमकिन हो, ऐप्लिकेशन में सुझाव, शिकायत या राय जोड़ने के तरीके देकर, लोगों से वास्तविक जानकारी बताएं. जब भी उपयोगकर्ता मेल को इनबॉक्स से अपने स्पैम फ़ोल्डर में ले जाते हैं, तब Gmail उनकी राय को बिना किसी रुकावट के कैप्चर करता है. हालांकि, यह सिर्फ़ तब काम करता है, जब उपयोगकर्ता अपने मेल को सही तरीके से कैटगरी में बांटता है. जब उपयोगकर्ता अपने इनबॉक्स में स्पैम छोड़ देते हैं (क्योंकि उन्हें पता होता है कि यह स्पैम है और वे उसे कभी नहीं खोलते), तो ट्रेनिंग से जुड़ा डेटा गलत हो जाता है. जब "स्पैम" होना चाहिए, तब उस मेल के हिस्से को "स्पैम नहीं" के तौर पर लेबल किया जाएगा. दूसरे शब्दों में, हमेशा ज़मीनी हकीकत को कैप्चर करने और रिकॉर्ड करने के तरीके ढूंढने की कोशिश करते हैं, लेकिन सुझाव/शिकायत/राय सबमिट करने के तरीके की कुछ कमियों का ध्यान रखें.
सातवीं इमेज में, उपयोगकर्ता को मिलने वाले सुझावों को दिखाया गया है और डेटा स्टोर करने की जगह में लॉग किया गया है.
लॉगिंग के लिए अनुमान
सातवीं इमेज. मॉडल की क्वालिटी मॉनिटर करने के लिए, अनुमानों को लॉग करें.
डेटा पाइपलाइन
डेटा पाइपलाइन, ऐप्लिकेशन डेटा से ट्रेनिंग और टेस्ट डेटासेट जनरेट करती हैं. इसके बाद, ट्रेनिंग और पुष्टि करने वाली पाइपलाइन नए मॉडल को ट्रेनिंग देने और उनकी पुष्टि करने के लिए, डेटासेट का इस्तेमाल करती हैं.
डेटा पाइपलाइन में उन ही सुविधाओं और लेबल के साथ ट्रेनिंग और टेस्ट डेटासेट बनाए जाते हैं जिनका इस्तेमाल मूल रूप से मॉडल को ट्रेनिंग देने के लिए किया जाता है. हालांकि, इन डेटासेट का इस्तेमाल नई जानकारी के साथ किया जाता है. उदाहरण के लिए, Maps ऐप्लिकेशन लाखों उपयोगकर्ताओं के लिए हाल ही की यात्रा के समय से ट्रेनिंग और टेस्ट डेटासेट जनरेट करेगा. साथ ही, मौसम की जानकारी के साथ काम का अन्य डेटा भी जनरेट होगा.
वीडियो का सुझाव देने वाला ऐप्लिकेशन, ट्रेनिंग और टेस्ट डेटासेट जनरेट करेगा. इसमें वे वीडियो शामिल होते हैं जिन पर उपयोगकर्ता ने सुझाई गई सूची में से क्लिक किया था (उन वीडियो के साथ जिन पर क्लिक नहीं किया गया) के साथ-साथ काम का अन्य डेटा, जैसे कि 'देखने का इतिहास'.
इमेज 8 में, ट्रेनिंग और टेस्ट डेटासेट बनाने के लिए ऐप्लिकेशन डेटा का इस्तेमाल करके डेटा पाइपलाइन को दिखाया गया है.
डेटा पाइपलाइन
आठवीं इमेज. डेटा पाइपलाइन, ऐप्लिकेशन डेटा को प्रोसेस करती है, ताकि ट्रेनिंग और पुष्टि करने वाले पाइपलाइन के लिए डेटासेट बनाए जा सकें.
डेटा इकट्ठा करना और उसे प्रोसेस करना
डेटा पाइपलाइन में डेटा इकट्ठा और प्रोसेस करने के टास्क, शायद एक्सपेरिमेंट के चरण (जहां आपने तय किया था कि आपका समाधान मुमकिन था) से अलग होगा:
डेटा कलेक्शन. प्रयोग के दौरान, आम तौर पर डेटा इकट्ठा करने के लिए सेव किए गए डेटा को ऐक्सेस करने की ज़रूरत होती है. डेटा पाइपलाइन के लिए, डेटा इकट्ठा करने के लिए स्ट्रीमिंग लॉग का डेटा खोजना और उसे ऐक्सेस करने की अनुमति ज़रूरी हो सकती है.
अगर आपको किसी व्यक्ति के लेबल वाला डेटा (जैसे, मेडिकल इमेज) चाहिए, तो आपको उसे इकट्ठा करने और अपडेट करने की प्रोसेस भी पूरी करनी होगी. अगर आपको किसी ऐसे डेटा की ज़रूरत है जिसे किसी व्यक्ति को लेबल किया गया है, तो CrowdCompute पेज देखें.
डेटा प्रोसेसिंग. प्रयोग के दौरान, सही सुविधाएं उन्हें स्क्रेप करने, जोड़ने, और प्रयोग करने वाले डेटासेट से मिला. डेटा पाइपलाइन के लिए, वही सुविधाएं जनरेट करने के लिए पूरी तरह से अलग प्रोसेस की ज़रूरत हो सकती है. हालांकि, सुविधाओं और लेबल में एक जैसे गणितीय ऑपरेशन लागू करके, प्रयोग के चरण से डेटा ट्रांसफ़ॉर्मेशन की डुप्लीकेट कॉपी बनाना न भूलें.
एसेट और मेटाडेटा स्टोरेज
आपको अपनी ट्रेनिंग और टेस्ट डेटासेट को सेव करने, वर्शन बनाने, और मैनेज करने के लिए एक प्रोसेस की ज़रूरत होगी. वर्शन कंट्रोल करने वाले डेटा स्टोर करने की जगहों से ये फ़ायदे मिलते हैं:
दोबारा इस्तेमाल करना. मॉडल ट्रेनिंग एनवायरमेंट को फिर से बनाएं और उनका स्टैंडर्ड तय करें. साथ ही, अलग-अलग मॉडल के बीच अनुमान की क्वालिटी की तुलना करें.
अनुपालन. ऑडिट और पारदर्शिता के लिए, नियमों के पालन से जुड़ी ज़रूरी शर्तों का पालन करना.
उपयोगकर्ता को अपने साथ जोड़े रखना. डेटा को कितने समय तक सेव करके रखना है, इसके लिए डेटा के रखरखाव की वैल्यू सेट करें.
ऐक्सेस मैनेजमेंट. यह मैनेज करें कि बेहतर अनुमतियों की मदद से, आपका डेटा कौन ऐक्सेस कर सकता है.
डेटा का रखरखाव. समय के साथ डेटासेट में होने वाले बदलावों को ट्रैक करें और समझें. इससे आपके डेटा या अपने मॉडल से जुड़ी समस्याओं का आसानी से पता लगाया जा सकेगा.
खोजने लायक बनाना. अन्य लोगों के लिए अपने डेटासेट और सुविधाओं को ढूंढना आसान बनाएं. इसके बाद, दूसरी टीमें यह तय कर सकती हैं कि वे अपने काम के लिए मददगार होंगी या नहीं.
अपने डेटा का रिकॉर्ड रखना
अच्छे दस्तावेज़ दूसरे लोगों को आपके डेटा के बारे में ज़रूरी जानकारी, जैसे कि उसका टाइप, सोर्स, साइज़, और दूसरे ज़रूरी मेटाडेटा को समझने में मदद करते हैं. ज़्यादातर मामलों में, अपने डेटा को किसी डिज़ाइन दस्तावेज़ या g3doc में दर्ज करना काफ़ी होता है. अगर आपको अपना डेटा शेयर करना या पब्लिश करना है, तो जानकारी व्यवस्थित करने के लिए डेटा कार्ड इस्तेमाल करें. डेटा कार्ड, अन्य लोगों के लिए आपके डेटासेट को खोजना और समझना आसान बनाते हैं.
ट्रेनिंग और पुष्टि करने वाले पाइपलाइन
ट्रेनिंग और पुष्टि करने वाले पाइपलाइन से, प्रोडक्शन मॉडल के पुराने होने से पहले ही उनकी जगह नए मॉडल बनाए जाते हैं. नए मॉडल को लगातार ट्रेनिंग देने और उनकी पुष्टि करने से यह पक्का होता है कि सबसे अच्छा मॉडल हमेशा प्रोडक्शन में रहे.
ट्रेनिंग पाइपलाइन में, ट्रेनिंग डेटासेट से एक नया मॉडल जनरेट किया जाता है. साथ ही, पुष्टि करने वाली पाइपलाइन में, नए मॉडल की क्वालिटी की तुलना टेस्ट डेटासेट का इस्तेमाल करके, चल रहे मॉडल की क्वालिटी से की जाती है.
इमेज 9 में दिखाया गया है कि नए मॉडल को ट्रेनिंग देने के लिए, ट्रेनिंग डेटासेट का इस्तेमाल करके ट्रेनिंग पाइपलाइन का इस्तेमाल कैसे किया जाता है.
ट्रेनिंग पाइपलाइन
नौवीं इमेज. ट्रेनिंग पाइपलाइन में सबसे हाल के ट्रेनिंग डेटासेट का इस्तेमाल करके, नए मॉडल को ट्रेनिंग दी जाती है.
मॉडल को ट्रेनिंग देने के बाद, पुष्टि करने वाली पाइपलाइन में टेस्ट डेटासेट का इस्तेमाल होता है, ताकि प्रोडक्शन मॉडल की क्वालिटी की तुलना ट्रेनिंग वाले मॉडल से की जा सके.
आम तौर पर, अगर ट्रेन किया गया मॉडल, प्रोडक्शन मॉडल से ज़्यादा खराब नहीं होता, तो ट्रेन किए गए मॉडल को प्रोडक्शन में भेजा जाता है. अगर ट्रेन किया गया मॉडल खराब है, तो मॉनिटरिंग इन्फ़्रास्ट्रक्चर में एक चेतावनी बनाई जानी चाहिए. ट्रेनिंग वाले मॉडल, जिनकी अनुमान की क्वालिटी खराब है. इनसे डेटा या पुष्टि की पाइपलाइन में हो सकने वाली समस्याओं के बारे में पता चल सकता है. इस तरीके से यह पक्का करने में मदद मिलती है कि सबसे अच्छा मॉडल, हमेशा प्रोडक्शन में हो और जिसे सबसे नए डेटा के आधार पर तैयार किया गया हो.
एसेट और मेटाडेटा स्टोरेज
मॉडल डिप्लॉयमेंट और उन्हें ट्रैक करने के लिए, मॉडल और उनके मेटाडेटा को वर्शन वाले डेटा स्टोर करने की जगहों में सेव किया जाना चाहिए. मॉडल डेटा स्टोर करने की जगहों से ये फ़ायदे मिलते हैं:
ट्रैकिंग और आकलन. प्रोडक्शन में मॉडल ट्रैक करें और उनके इवैलुएशन और अनुमान की क्वालिटी मेट्रिक को समझें.
मॉडल रिलीज़ करने की प्रोसेस. आसानी से मॉडल की समीक्षा करें, उन्हें मंज़ूरी दें, रिलीज़ करें या रोल बैक करें.
दोबारा जनरेट करना और डीबग करना. सभी डिप्लॉयमेंट पर मॉडल के डेटासेट और डिपेंडेंसी को ट्रेस करके, मॉडल के नतीजों को फिर से बनाएं और समस्याओं को ज़्यादा असरदार तरीके से डीबग करें.
खोजने लायक बनाना. दूसरों के लिए अपना मॉडल ढूंढना आसान बनाएं. इसके बाद, दूसरी टीमें यह तय कर सकती हैं कि आपके मॉडल (या इसके कुछ हिस्सों) का इस्तेमाल, उनके काम के लिए किया जा सकता है या नहीं.
इमेज 10 में, मॉडल रिपॉज़िटरी में स्टोर किए गए ऐसे मॉडल को दिखाया गया है जिसकी पुष्टि हो चुकी है.
मॉडल स्टोरेज
10वीं इमेज. पुष्टि किए गए मॉडल, ट्रैकिंग और खोजने लायक बनाने के लिए, मॉडल रिपॉज़िटरी में सेव किए जाते हैं.
अपने मॉडल के बारे में अहम जानकारी शेयर करने और उसका इस्तेमाल करने के लिए, मॉडल कार्ड का इस्तेमाल करें. जैसे, मॉडल का मकसद, आर्किटेक्चर, हार्डवेयर की ज़रूरी शर्तें, इवैलुएशन मेट्रिक वगैरह.
पाइपलाइन बनाने में चुनौतियां
पाइपलाइन बनाते समय, आपको नीचे दी गई चुनौतियों का सामना करना पड़ सकता है:
जिस डेटा की आपको ज़रूरत है उसका ऐक्सेस पाना. डेटा ऐक्सेस करने के लिए आपको यह बताना पड़ सकता है कि आपको इसकी ज़रूरत क्यों है. उदाहरण के लिए, आपको यह बताना पड़ सकता है कि डेटा का इस्तेमाल कैसे किया जाएगा. साथ ही, आपको यह भी बताना पड़ सकता है कि व्यक्तिगत पहचान से जुड़ी जानकारी की समस्या को कैसे हल किया जाएगा. इस बात का सबूत दिखाने के लिए तैयार रहें कि आपका मॉडल, खास तरह के डेटा के ऐक्सेस के बारे में बेहतर अनुमान कैसे लगाता है.
सही सुविधाएं पाना. कुछ मामलों में, एक्सपेरिमेंट के चरण में इस्तेमाल की गई सुविधाएं, रीयल-टाइम डेटा से उपलब्ध नहीं होंगी. इसलिए, प्रयोग करते समय, यह पक्का करें कि आपको प्रोडक्शन में वे सुविधाएं ही मिलेंगी.
डेटा को इकट्ठा करने और उसे दिखाने का तरीका समझना. डेटा कैसे इकट्ठा किया गया, किसने इकट्ठा किया, और उसे कैसे इकट्ठा किया गया (अन्य समस्याओं के साथ), यह जानने में समय और मेहनत लगती है. डेटा को अच्छी तरह से समझना ज़रूरी है. प्रोडक्शन में जाने वाले मॉडल को ट्रेनिंग देने के लिए, ऐसे डेटा का इस्तेमाल न करें जिस पर आपको भरोसा न हो.
प्रोसेस, कीमत, और मॉडल क्वालिटी के बीच के अंतर को समझना. डेटा पाइपलाइन में कोई नई सुविधा जोड़ने के लिए बहुत मेहनत करनी पड़ सकती है. हालांकि, अतिरिक्त सुविधा से, मॉडल की क्वालिटी सिर्फ़ बेहतर हो सकती है. अन्य मामलों में, नई सुविधा जोड़ना आसान हो सकता है. हालांकि, इस सुविधा को पाने और स्टोर करने के संसाधन बहुत ज़्यादा महंगे हो सकते हैं.
कैलकुलेशन की जा रही है. अगर आपको फिर से ट्रेनिंग लेने के लिए TPU की ज़रूरत है, तो ज़रूरी कोटा हासिल करना मुश्किल हो सकता है. साथ ही, TPU को मैनेज करना मुश्किल है. उदाहरण के लिए, आपके मॉडल या डेटा के कुछ हिस्सों को TPU के कुछ हिस्सों को एक से ज़्यादा TPU चिप में बांटकर, खास तौर पर TPU के लिए डिज़ाइन करने की ज़रूरत हो सकती है.
सही गोल्डन डेटासेट ढूंढना. अगर डेटा बार-बार बदलता है, तो एक जैसे और सटीक लेबल के साथ गोल्डन डेटासेट पाना मुश्किल हो सकता है.
प्रयोग करने के दौरान इस तरह की समस्याओं का पता लगाने से समय बचता है. उदाहरण के लिए, आपको ऐसी सुविधाएं और मॉडल डेवलप नहीं करना है जिनसे यह पता चले कि वे प्रोडक्शन में इस्तेमाल नहीं किए जा सकते. इसलिए, जल्द से जल्द पुष्टि करने की कोशिश करें कि आपका सलूशन, प्रोडक्शन एनवायरमेंट में काम करेगा. प्रयोग के चरण पर वापस जाने के बजाय, समाधान के काम करने की पुष्टि करने में समय देना बेहतर होता है, क्योंकि पाइपलाइन चरण में बड़ी समस्याओं का पता चल गया.