कुछ महीने पहले, मैंने खुद को चुनौती देने की कोशिश की ताकि मैं डेटा एनालिटिक्स बैकग्राउंड से डेटा इंजीनियरिंग तक के सफर पर निकल सकूं। अब तक मैंने कुल दो प्रभावशाली वास्तविक दुनिया की परियोजनाएं बनाई हैं जिन्होंने मुझे कुछ उपयोगी सिखाया। मैंने एक Git Hub ET L पाइपलाइन बनाई जो Git Hub रिपॉजिटरी को निकालती है और उन्हें SQLite डेटाबेस में लोड करती है — यह Git Hub Actions का उपयोग करके एक शेड्यूल पर चलता था। मैंने एक RSS पाइपलाइन भी बनाई जो RSS फीड से लेख निकालती है और उन्हें Kestra डेटाबेस में स्टोर करती है — Kestra द्वारा घंटे के शेड्यूल पर चलने के लिए ऑर्केस्ट्रेट किया गया। अब जब मैंने ET L को कुछ हद तक समझ लिया है, मैं कुछ नया आजमाना चाहता था। मैं नया कुछ बनाते हुए अतीत में जो कुछ भी सीखा था उसका अभ्यास जारी रखना चाहता था। मुझे हमेशा मशीन लर्निंग के क्षेत्र से मोहित किया गया था, लेकिन मेरे पास इसमें कदम रखने का साहस कभी नहीं था क्योंकि मुझे लगता था कि इसमें जटिल गणित था। अब ऐसा नहीं है। हाल ही में, मैंने एक काल्पनिक टेलीकॉम कंपनी के लिए एक चर्न प्रेडिक्शन मॉडल बनाया जिसे मैं Northline Mobile कह रहा हूं (पी.एस. मैं एक काल्पनिक कंपनी का उपयोग कर रहा हूं क्योंकि मैं वास्तविक दुनिया के परिदृश्यों के साथ चीजों को सबसे अच्छी तरह समझता हूं)। मैंने इसे 7043 ग्राहकों के डेटा के साथ प्रदान किया, यह बताते हुए कि उन्होंने 1-वर्ष के अनुबंध या मासिक योजनाओं के लिए साइन अप किया था या नहीं, ग्राहक की लंबाई, मासिक शुल्क, ऐड-ऑन आदि। इसके अलावा, मैंने इसे बताया कि अंततः कौन Northline Mobile छोड़ गया। मैंने ऐसे ग्राहकों के साथ मॉडल को क्रॉस-वैलिडेट किया जिन्हें उसने अभी तक नहीं देखा था। इसने 81% सटीकता हासिल की। इसने मुझे वह सब कुछ सिखाया जो मॉडल बनाने में जाता है। जाहिर है मैंने सभी जटिल कोड को नहीं समझा, क्योंकि मैं जटिल कोड के बजाय सहज ड्रैग और ड्रॉप इंटरफेस पसंद करता हूं। लेकिन मैंने मॉडल बनाने के आवश्यक बिल्डिंग ब्लॉक्स को समझा; मैं एक सरलीकृत आर्किटेक्चर के साथ नीचे आगे समझाऊंगा। तो मशीन लर्निंग के दृष्टिकोण से इस मॉडल को बनाना एक जीत की तरह महसूस हुआ; मेरा मॉडल काम कर रहा था। लेकिन अभी भी एक समस्या थी: यह अभी भी वास्तव में उपयोगी नहीं था। मान लें कि एक Northline कर्मचारी जिसे एक प्रेडिक्शन की आवश्यकता है, मेरे पास आता है, मुझे Jupyter खोलना होगा, सही नोटबुक लोड करनी होगी, सेल्स को सही क्रम में चलाना होगा और predict_churn() को मैन्युअल रूप से कॉल करना होगा। हां, मॉडल मौजूद है, लेकिन मैं ही एकमात्र व्यक्ति हूं जो जानता है कि इसका उपयोग कैसे करें। Northline में कोई और बस किसी ग्राहक की जानकारी मॉडल पर नहीं भेज सकता और प्रेडिक्शन प्राप्त नहीं कर सकता और यह किसी अन्य एप्लिकेशन से भी बात नहीं कर सकता था। यह लेख इसी को कवर करेगा। मैंने हाल ही में सीखा कि एक मॉडल रखने और एक सेवा रखने के बीच एक अंतर है। यदि कोई मॉडल केवल एक नोटबुक में बैठा है तो केवल उस व्यक्ति का उपयोग कर सकता है जिसने इसे बनाया है। लेकिन इसे एक सेवा बनाने से यह संभव हो जाता है कि हर कोई इसका उपयोग कर सके, अन्य टीमें, ऐप्स, डैशबोर्ड और सिस्टम जिन्हें यह जानने या परवाह करने की आवश्यकता नहीं है कि प्रेडिक्शन कैसे किया जाता है। पता चलता है कि मशीन लर्निंग मॉडल बनाना सबसे आसान हिस्सा था, लेकिन इसे उपयोगी बनाना एक और महत्वपूर्ण तत्व है जिस पर विचार करने लायक है। API से पहले 'हो गया' का क्या मतलब थायहाँ लगभग बताया गया है कि मॉडल बनाना कैसा दिखता था: यह लगभग बस इतना है। कुछ बहुत फैंसी नहीं। उसके अंत तक, मेरे पास एक ट्रेंड चर्न क्लासिफायर था, एक प्रीप्रोसेसिंग पाइपलाइन जो कच्चे डेटा को साफ और एन्कोड करती थी, और मूल्यांकन संख्याएँ जिनके साथ मैं सहज था (इन संख्याओं पर जल्द ही और, वे सही नहीं हैं और मैं दिखावा नहीं करने जा रहा हूं कि वे हैं)। लेकिन जैसा कि मैंने कहा। मान लें कि Northline की रिटेंशन टीम एक डैशबोर्ड बनाती है, और वे चाहते हैं कि यह जोखिम वाले ग्राहकों को स्वचालित रूप से फ्लैग करे। उनका डैशबोर्ड उचित रूप से मेरी Jupyter नोटबुक नहीं खोल सकता और मेरी सेल्स को नहीं चला सकता। इसे पूरी तरह से कुछ और चाहिए। ऐसा कुछ: वह बदलाव है जिसे यह लेख कवर करता है। हालांकि, एक त्वरित अस्वीकरण: यह एक Fast API ट्यूटोरियल नहीं है। Fast API केवल वह उपकरण है जिसका उपयोग मैंने मॉडल को ... के रूप में उजागर करने के लिए किया था