मार्गदर्शिका

डेटा तैयारी से लेकर डिप्लॉयमेंट और मॉनिटरिंग तक, पूरे मशीन लर्निंग जीवनचक्र के लिए एक केंद्रीकृत, सहयोगात्मक प्लेटफ़ॉर्म की आवश्यकता है।

→Azure मशीन लर्निंग वर्कस्पेस।

क्यों: यह वह मूलभूत सेवा है जो सभी आवश्यक घटकों को एकीकृत करती है: कंप्यूट, डेटास्टोर, वातावरण, एक्सपेरिमेंट ट्रैकिंग, मॉडल रजिस्ट्री और एंडपॉइंट्स।

संदर्भ↗

आवश्यकता है कि सभी ML वर्कस्पेस ट्रैफ़िक, जिसमें Storage और ACR जैसे निर्भर संसाधनों का ट्रैफ़िक भी शामिल है, Azure निजी नेटवर्क पर रहे और सार्वजनिक इंटरनेट पर उजागर न हो।

→Azure ML वर्कस्पेस को एक प्रबंधित वर्चुअल नेटवर्क के साथ कॉन्फ़िगर करें और वर्कस्पेस तथा उसके सभी निर्भर संसाधनों (Storage, Key Vault, ACR) के लिए निजी एंडपॉइंट्स का उपयोग करें।

क्यों: निजी एंडपॉइंट्स Azure सेवाओं के लिए सुरक्षित, निजी कनेक्टिविटी प्रदान करते हैं, यह सुनिश्चित करते हुए कि ट्रैफ़िक सार्वजनिक इंटरनेट से होकर न गुजरे। एक प्रबंधित VNet ML कंप्यूट के लिए इस कॉन्फ़िगरेशन को सरल बनाता है।

संदर्भ↗

ML समाधान को सख्त डेटा रेजिडेंसी नियमों का पालन करना चाहिए, यह सुनिश्चित करते हुए कि सभी डेटा और कंप्यूट एक विशिष्ट भौगोलिक क्षेत्र (जैसे यूरोपीय संघ) के भीतर रहें।

→आवश्यक भौगोलिक क्षेत्र के भीतर एक क्षेत्र में Azure ML वर्कस्पेस, सभी संबंधित स्टोरेज अकाउंट्स और कंप्यूट संसाधन बनाएँ। डेटा एक्सफ़िल्ट्रेशन को रोकने के लिए नेटवर्क आइसोलेशन का उपयोग करें।

क्यों: Azure संसाधन उस क्षेत्र से बंधे होते हैं जहाँ उन्हें बनाया जाता है। यह भौतिक डेटा स्थान अनुपालन सुनिश्चित करता है। नेटवर्क आइसोलेशन (प्रबंधित VNet) डेटा को इस सीमा के बाहर संसाधित होने से रोकता है।

सभी ML वर्कस्पेस में संगठनात्मक मानकों को लागू करें, जैसे लागत-आवंटन टैग की आवश्यकता, VM आकारों को प्रतिबंधित करना, या डायग्नोस्टिक लॉग शिपिंग अनिवार्य करना।

→संसाधन निर्माण और कॉन्फ़िगरेशन के लिए नियम लागू करने और उन्हें लागू करने के लिए Azure Policy का उपयोग करें।

क्यों: Azure Policy स्केलेबल, केंद्रीकृत गवर्नेंस प्रदान करता है। यह गैर-अनुपालक संसाधनों को बनने से रोकता है, जिससे मैन्युअल निगरानी के बिना लगातार मानक सुनिश्चित होते हैं।

संदर्भ↗

कोड या कॉन्फ़िगरेशन में क्रेडेंशियल्स (अकाउंट कीज़, SAS टोकन) को संग्रहीत किए बिना एक ML वर्कस्पेस से Azure Storage में डेटा एक्सेस करें।

→पहचान-आधारित प्रमाणीकरण का उपयोग करके डेटास्टोर कनेक्शन बनाएँ। वर्कस्पेस की प्रबंधित पहचान (या उपयोगकर्ता/कंप्यूट पहचान) को स्टोरेज अकाउंट पर उपयुक्त RBAC भूमिका (जैसे Storage Blob Data Reader) प्रदान करें।

क्यों: यह एक क्रेडेंशियल-लेस, ज़ीरो-ट्रस्ट पैटर्न है जो प्रमाणीकरण के लिए Azure AD का उपयोग करता है, जिससे सुरक्षा में सुधार होता है और क्रेडेंशियल प्रबंधन सरल हो जाता है।

विभिन्न सुरक्षा स्तरों (जैसे PII बनाम अनाम डेटा) वाले प्रोजेक्ट्स पर कई टीमें काम करती हैं। संसाधन अलगाव प्रदान करने की आवश्यकता है।

→प्रत्येक सुरक्षा सीमा के लिए अलग Azure ML वर्कस्पेस बनाएँ। PII प्रोजेक्ट्स के लिए वर्कस्पेस में गैर-संवेदनशील प्रोजेक्ट्स की तुलना में सख्त नेटवर्क आइसोलेशन होना चाहिए।

क्यों: वर्कस्पेस प्राथमिक सुरक्षा और अलगाव सीमा है। सुरक्षा स्तर के अनुसार अलग करना डेटा लीकेज को रोकने और उचित नियंत्रण लागू करने के लिए एक सर्वोत्तम अभ्यास है।

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

→विकास और उत्पादन वातावरण के लिए अलग-अलग Azure ML वर्कस्पेस का उपयोग करें।

क्यों: यह उत्पादन संसाधनों, डेटा और मॉडलों को प्रायोगिक कार्य से अलग करता है, उत्पादन MLOps पाइपलाइनों के लिए स्थिरता और स्पष्ट शासन प्रदान करता है।

ML प्रशिक्षण कार्यों के लिए कंप्यूट प्रावधान करें जो रुक-रुक कर चलते हैं, जिसमें लागत को कम करने पर उच्च प्राथमिकता होती है।

→कम-प्राथमिकता वाले VM, 0 की न्यूनतम नोड गणना, और कॉन्फ़िगर किए गए ऑटो-स्केलिंग के साथ एक Azure ML कंप्यूट क्लस्टर का उपयोग करें।

क्यों: कम-प्राथमिकता वाले VM व्यवधान योग्य वर्कलोड के लिए महत्वपूर्ण लागत बचत प्रदान करते हैं। 0 नोड्स की न्यूनतम संख्या सुनिश्चित करती है कि जब क्लस्टर निष्क्रिय हो तो आप कुछ भी भुगतान नहीं करते।

संदर्भ↗

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

→इंटरैक्टिव विकास के लिए कंप्यूट इंस्टेंस (प्रति उपयोगकर्ता एक) प्रावधान करें। बैच प्रशिक्षण कार्यों के लिए कंप्यूट क्लस्टर प्रावधान करें।

क्यों: कंप्यूट इंस्टेंस एकल-उपयोगकर्ता, स्थायी VM हैं जो इंटरैक्टिव कार्य के लिए अनुकूलित हैं। कंप्यूट क्लस्टर ऑटो-स्केलिंग, मल्टी-नोड संसाधन हैं जो बैच कार्यों के लिए अनुकूलित हैं।

यह सुनिश्चित करें कि ML प्रशिक्षण रन सभी सॉफ़्टवेयर निर्भरताओं, जिसमें विशिष्ट Python पैकेज संस्करण भी शामिल हैं, को कैप्चर करके पुनरुत्पादनीय हों।

→एक conda वातावरण YAML फ़ाइल या एक Dockerfile का उपयोग करके एक Azure ML Environment को परिभाषित करें। प्रशिक्षण कार्यों में उपयोग के लिए इस वातावरण को पंजीकृत और संस्करणित करें।

क्यों: वातावरण रनटाइम के संस्करणित, पुन: प्रयोज्य विनिर्देश हैं। यह वातावरण को कंप्यूट से अलग करता है, यह सुनिश्चित करता है कि उस वातावरण संस्करण के साथ कोई भी रन समान हो।

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

→फ़ीचर्स को परिभाषित करने, कंप्यूट करने और परोसने के लिए Azure ML Managed Feature Store का उपयोग करें।

क्यों: एक फ़ीचर स्टोर निरंतरता सुनिश्चित करता है (प्रशिक्षण-सेवा तिरछापन को रोकता है), फ़ीचर खोज और पुन: उपयोग को सक्षम बनाता है, और ऑफ़लाइन (प्रशिक्षण के लिए) और ऑनलाइन (कम-विलंबता अनुमान के लिए) दोनों स्टोरेज प्रदान करता है।

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

→MLflow का उपयोग करें, जो Azure ML में स्वाभाविक रूप से एकीकृत है। प्रशिक्षण स्क्रिप्ट में ऑटोलॉगिंग सक्षम करें या स्पष्ट `mlflow.log_*` कमांड का उपयोग करें।

क्यों: MLflow प्रयोग ट्रैकिंग के लिए एक मानकीकृत, ओपन-सोर्स फ्रेमवर्क प्रदान करता है। Azure ML एक प्रबंधित MLflow ट्रैकिंग सर्वर के रूप में कार्य करता है, जो रन की तुलना के लिए एक UI प्रदान करता है।

संदर्भ↗

गंभीर क्लास असंतुलन (जैसे धोखाधड़ी का पता लगाना) वाले डेटासेट पर एक क्लासिफिकेशन मॉडल को प्रशिक्षित करना, जिससे अल्पसंख्यक क्लास पर खराब प्रदर्शन होता है।

→प्रशिक्षण डेटा पर SMOTE (सिंथेटिक माइनॉरिटी ओवर-सैंपलिंग तकनीक) जैसी तकनीकों को लागू करें। असंतुलन के प्रति असंवेदनशील मेट्रिक्स, जैसे Precision-Recall AUC या F1-स्कोर का उपयोग करके मॉडल का मूल्यांकन करें।

क्यों: केवल सटीकता का उपयोग करना भ्रामक है। SMOTE मॉडल को सीखने में मदद करने के लिए सिंथेटिक अल्पसंख्यक नमूने बनाता है, और PR-AUC/F1-स्कोर सकारात्मक क्लास पर प्रदर्शन को सही ढंग से मापता है।

लंबे प्रशिक्षण समय और सीमित कंप्यूट बजट वाले मॉडल के लिए इष्टतम हाइपरपैरामीटर्स खोजने की आवश्यकता है।

→बेयसियन सैंपलिंग और एक प्रारंभिक समाप्ति नीति (जैसे बैंडिट या मीडियम स्टॉपिंग) के साथ एक स्वीप जॉब का उपयोग करें।

क्यों: बेयसियन सैंपलिंग समझदारी से खोज स्थान की पड़ताल करता है, आशाजनक क्षेत्रों पर ध्यान केंद्रित करता है। प्रारंभिक समाप्ति खराब प्रदर्शन वाले रन को जल्दी रोक देती है, जिससे महत्वपूर्ण कंप्यूट समय और लागत बचती है।

AutoML का उपयोग करके एक टाइम सीरीज़ फ़ोरकास्टिंग मॉडल बनाएँ।

→AutoML जॉब को `task='forecasting'` के साथ कॉन्फ़िगर करें, `time_column_name` निर्दिष्ट करें, और `forecast_horizon` सेट करें।

क्यों: "फ़ोरकास्टिंग" के रूप में कार्य निर्दिष्ट करना AutoML को टाइम-सीरीज़-विशिष्ट तकनीकों जैसे लैग फ़ीचर जनरेशन, सीज़नैलिटी डिटेक्शन और टाइम-अवेयर क्रॉस-वैलिडेशन को लागू करने में सक्षम बनाता है।

प्रशिक्षण समय को कम करने के लिए कई कंप्यूट नोड्स पर कई GPU में एक बड़ा डीप लर्निंग मॉडल प्रशिक्षित करें।

→GPU-सक्षम नोड्स के साथ एक कंप्यूट क्लस्टर का उपयोग करें। कमांड जॉब में, `distribution` प्रॉपर्टी को कॉन्फ़िगर करें (जैसे `type: "PyTorch"`, `process_count_per_instance: <# GPUs>`)।

क्यों: Azure ML नोड सेटअप और संचार का प्रबंधन करके वितरित प्रशिक्षण को सरल बनाता है। `distribution` कॉन्फ़िगरेशन Azure ML को बताता है कि वितरित प्रशिक्षण प्रक्रियाओं को कैसे लॉन्च किया जाए।

संदर्भ↗

एक बहु-चरणीय ML वर्कफ़्लो (जैसे डेटा तैयारी, प्रशिक्षण, मूल्यांकन) को स्वचालित करें जिसे विभिन्न मापदंडों के साथ पुन: उपयोग किया जा सके।

→प्रत्येक चरण के लिए घटकों का उपयोग करके एक Azure ML पाइपलाइन को परिभाषित करें। वर्कफ़्लो को पैरामीटराइज़ करने के लिए पाइपलाइन इनपुट का उपयोग करें।

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

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

→यह ओवरफिटिंग का एक क्लासिक संकेत है। नियमितीकरण (जैसे ड्रॉपआउट, L2) लागू करके, डेटा संवर्धन का उपयोग करके, प्रारंभिक स्टॉपिंग लागू करके, या मॉडल की जटिलता को कम करके इसे कम करें।

क्यों: प्रशिक्षण और सत्यापन प्रदर्शन के बीच का अंतर दिखाता है कि मॉडल ने सामान्यीकरण के बजाय प्रशिक्षण डेटा को याद कर लिया है। नियमितीकरण तकनीक सामान्यीकरण में सुधार के लिए जटिलता को दंडित करती हैं।

कम-प्राथमिकता वाले (स्पॉट) VM पर एक लंबा चलने वाला प्रशिक्षण कार्य प्रीएम्प्शन और प्रगति खोने के जोखिम में है।

→प्रशिक्षण स्क्रिप्ट के भीतर चेकपॉइंटिंग लागू करें ताकि मॉडल और ऑप्टिमाइज़र स्थिति को समय-समय पर `./outputs` डायरेक्टरी में सहेजा जा सके।

क्यों: `./outputs` डायरेक्टरी Azure ML द्वारा स्वचालित रूप से स्थायी की जाती है। चेकपॉइंट्स सहेजने से जॉब को प्रीएम्प्शन पर अंतिम सहेजी गई स्थिति से फिर से शुरू करने की अनुमति मिलती है, जिससे प्रगति संरक्षित होती है और लागत बचती है।

एक संगठन की नीति है कि उत्पादन में केवल कुछ ML एल्गोरिदम का उपयोग किया जा सकता है। AutoML रन के दौरान इसे लागू करने की आवश्यकता है।

→AutoML कॉन्फ़िगरेशन में, खोज स्थान से अस्वीकृत एल्गोरिदम को स्पष्ट रूप से बाहर करने के लिए `blocked_models` पैरामीटर का उपयोग करें।

क्यों: यह शासन नीतियों के साथ AutoML को संरेखित करने का एक सीधा, प्रवर्तनीय तरीका प्रदान करता है, जिससे गैर-अनुपालक मॉडलों के चयन को रोका जा सकता है।

उच्च उपलब्धता के साथ वास्तविक समय, कम-विलंबता (<100ms) भविष्यवाणियों के लिए एक मॉडल डिप्लॉय करें।

→मॉडल को एक Azure ML Managed Online Endpoint पर डिप्लॉय करें।

क्यों: प्रबंधित ऑनलाइन एंडपॉइंट्स वास्तविक समय के अनुमान के लिए अनुकूलित एक पूरी तरह से प्रबंधित सेवा है, जो ऑटो-स्केलिंग, लोड बैलेंसिंग, ब्लू-ग्रीन डिप्लॉयमेंट और अंतर्निहित मॉनिटरिंग प्रदान करती है।

संदर्भ↗

लागत दक्षता को प्राथमिकता देते हुए, बड़ी मात्रा में डेटा (लाखों रिकॉर्ड) को एसिंक्रोनस रूप से स्कोर करें।

→मॉडल को एक Azure ML Batch Endpoint पर डिप्लॉय करें।

क्यों: बैच एंडपॉइंट्स बड़े डेटासेट के उच्च-थ्रूपुट, एसिंक्रोनस स्कोरिंग के लिए डिज़ाइन किए गए हैं। वे स्केलेबल कंप्यूट क्लस्टर का उपयोग कर सकते हैं जो निष्क्रिय होने पर शून्य तक घूमते हैं, जिससे लागत अनुकूलित होती है।

जोखिम को कम करते हुए एक नया मॉडल संस्करण डिप्लॉय करें। नए संस्करण में ट्रैफ़िक को धीरे-धीरे स्थानांतरित करने और आसान रोलबैक की अनुमति देने की आवश्यकता है।

→दो डिप्लॉयमेंट (जैसे पुराने मॉडल के लिए "ब्लू", नए के लिए "ग्रीन") के साथ एक एकल प्रबंधित ऑनलाइन एंडपॉइंट का उपयोग करें। प्रत्येक डिप्लॉयमेंट पर जाने वाले अनुरोधों के प्रतिशत को नियंत्रित करने के लिए ट्रैफ़िक स्प्लिटिंग का उपयोग करें।

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

डिप्लॉयमेंट के लिए एक मानकीकृत, फ्रेमवर्क-अज्ञेयवादी तरीके से एक मॉडल को उसकी निर्भरताओं और कलाकृतियों के साथ पैकेज करें।

→MLflow मॉडल प्रारूप का उपयोग करें। मॉडल को पंजीकृत करते समय, conda.yaml या requirements.txt फ़ाइल और किसी भी आवश्यक कोड आर्टिफैक्ट्स को शामिल करें।

क्यों: MLflow एक मानक मॉडल पैकेजिंग कन्वेंशन प्रदान करता है जिसे Azure ML स्वाभाविक रूप से समझता है। यह डिप्लॉयमेंट को सरल बनाता है क्योंकि Azure ML स्वचालित रूप से आवश्यक वातावरण का निर्माण कर सकता है।

एक डिप्लॉय किए गए मॉडल में उच्च विलंबता होती है क्योंकि यह प्रत्येक भविष्यवाणी अनुरोध पर बड़ी सहायक फ़ाइलों (जैसे एक बड़ा फ़ीचराइज़र) को लोड करता है।

→फाइल लोडिंग लॉजिक को स्कोरिंग स्क्रिप्ट में `run()` फ़ंक्शन से `init()` फ़ंक्शन में ले जाएँ।

क्यों: `init()` फ़ंक्शन कंटेनर शुरू होने पर केवल एक बार चलता है। यहाँ एसेट्स लोड करने से वे सभी `run()` कॉलों के लिए विश्व स्तर पर उपलब्ध हो जाते हैं, जिससे प्रत्येक अनुरोध पर अनावश्यक लोडिंग से बचा जा सकता है।

एक वास्तविक समय एंडपॉइंट परिवर्तनीय ट्रैफ़िक (उच्च शिखर, निम्न गर्त) का अनुभव करता है। लागत-प्रभावी ढंग से प्रदर्शन बनाए रखने की आवश्यकता है।

→प्रबंधित ऑनलाइन एंडपॉइंट डिप्लॉयमेंट पर ऑटो-स्केलिंग कॉन्फ़िगर करें। इंस्टेंस की न्यूनतम और अधिकतम संख्या सेट करें और CPU उपयोग या अनुरोध विलंबता के आधार पर एक स्केलिंग नियम परिभाषित करें।

क्यों: ऑटो-स्केलिंग ट्रैफ़िक लोड से मेल खाने के लिए कंप्यूट इंस्टेंस की संख्या को स्वचालित रूप से समायोजित करता है, जिससे शिखर के दौरान प्रदर्शन सुनिश्चित होता है और कम गतिविधि के दौरान लागत बचती है।

एक मॉडल डिप्लॉयमेंट को विशिष्ट सिस्टम लाइब्रेरी, कस्टम CUDA संस्करण, या डिफ़ॉल्ट Azure ML इमेज में मौजूद न होने वाले कस्टम अनुमान सर्वर की आवश्यकता होती है।

→एक कस्टम Dockerfile बनाएँ जो एक Azure ML बेस अनुमान इमेज का विस्तार करता है, आवश्यक निर्भरताओं को जोड़ें, इसे बनाएँ, और इसे Azure Container Registry पर पुश करें। डिप्लॉयमेंट वातावरण में इस इमेज को संदर्भित करें।

क्यों: एक बेस इमेज का विस्तार करना रनटाइम वातावरण पर पूर्ण नियंत्रण प्रदान करता है जबकि Azure ML की सेवारत अवसंरचना के साथ संगतता बनाए रखता है।

कोड या डेटा परिवर्तनों द्वारा ट्रिगर किए गए पुनर्प्रशिक्षण, मूल्यांकन और डिप्लॉयमेंट सहित एंड-टू-एंड ML जीवनचक्र को स्वचालित करें।

→CI/CD पाइपलाइन बनाने के लिए Azure ML CLI v2 के साथ एकीकृत Azure DevOps या GitHub Actions का उपयोग करें। पाइपलाइन में एक क्वालिटी गेट शामिल होना चाहिए जो डिप्लॉय करने से पहले नए मॉडल की बेसलाइन से तुलना करता है।

क्यों: यह MLOps पैटर्न ML वर्कफ़्लो को स्वचालित करता है, निरंतरता, गुणवत्ता और तीव्र पुनरावृति सुनिश्चित करता है। क्वालिटी गेट मॉडल प्रदर्शन प्रतिगमन को रोकता है।

इनपुट डेटा वितरण में बदलाव के कारण एक उत्पादन मॉडल का प्रदर्शन खराब हो रहा है। महत्वपूर्ण ड्रिफ्ट का पता चलने पर मॉडल को स्वचालित रूप से पुनर्प्रशिक्षित करने की आवश्यकता है।

→एंडपॉइंट पर एक Azure ML डेटा ड्रिफ्ट मॉनिटर कॉन्फ़िगर करें। एक अलर्ट सेट करें जो एक Azure Logic App या Azure Function को ट्रिगर करता है, जो बदले में पुनर्प्रशिक्षण पाइपलाइन शुरू करता है।

क्यों: यह एक क्लोज्ड-लूप MLOps सिस्टम बनाता है जो मैन्युअल हस्तक्षेप के बिना, बदलते डेटा पैटर्न के जवाब में मॉडल की प्रासंगिकता को स्वचालित रूप से बनाए रखता है।

उत्पादन में एक नया डिप्लॉय किया गया मॉडल संस्करण दोषपूर्ण पाया गया है। पिछली स्थिर संस्करण पर शीघ्रता से वापस लौटने की आवश्यकता है।

→यदि ब्लू-ग्रीन डिप्लॉयमेंट का उपयोग कर रहे हैं, तो 100% ट्रैफ़िक को स्थिर डिप्लॉयमेंट पर वापस स्थानांतरित करें। वैकल्पिक रूप से, मॉडल रजिस्ट्री से पिछले मॉडल संस्करण को फिर से डिप्लॉय करने के लिए एंडपॉइंट को अपडेट करें।

क्यों: ट्रैफ़िक शिफ्टिंग एक तात्कालिक रोलबैक प्रदान करती है। रजिस्ट्री से एक संस्करण को फिर से डिप्लॉय करना भी एक ज्ञात-अच्छी स्थिति को बहाल करने का एक तेज़ और विश्वसनीय तरीका है।

एक डिप्लॉय किए गए मॉडल के परिचालन स्वास्थ्य (विलंबता, त्रुटियाँ) और भविष्य कहनेवाला गुणवत्ता (डेटा ड्रिफ्ट, सटीकता) दोनों की निगरानी करने की आवश्यकता है।

→परिचालन मेट्रिक्स के लिए एंडपॉइंट पर Application Insights एकीकरण सक्षम करें। मॉडल गुणवत्ता मेट्रिक्स के लिए Azure ML डेटा संग्रह और डेटा ड्रिफ्ट मॉनिटरिंग कॉन्फ़िगर करें।

क्यों: यह दो-तरफ़ा दृष्टिकोण मॉडल स्वास्थ्य का एक पूर्ण दृश्य प्रदान करता है। App Insights सिस्टम प्रदर्शन को ट्रैक करता है, जबकि डेटा संग्रह/ड्रिफ्ट मॉनिटरिंग मॉडल के भविष्य कहनेवाला प्रदर्शन को ट्रैक करता है।

क्लाइंट्स से गलत या अप्रत्याशित इनपुट डेटा के कारण मॉडल एंडपॉइंट विफल हो रहा है।

→स्कोरिंग स्क्रिप्ट के `run()` फ़ंक्शन के भीतर इनपुट सत्यापन लॉजिक लागू करें। डेटा प्रकार, रेंज और संरचनाओं की जाँच करें, और अमान्य अनुरोधों के लिए एक सार्थक त्रुटि (जैसे HTTP 400) लौटाएँ।

क्यों: सर्वर-साइड सत्यापन मॉडल को क्रैश होने से बचाता है और API उपभोक्ताओं को स्पष्ट, तत्काल प्रतिक्रिया प्रदान करता है, जिससे सेवा अधिक मजबूत बनती है।

डिबगिंग, अनुपालन, या हितधारक विश्वास के लिए, यह समझने की आवश्यकता है कि एक जटिल "ब्लैक-बॉक्स" मॉडल कुछ भविष्यवाणियाँ क्यों कर रहा है।

→मॉडल स्पष्टीकरण उत्पन्न करने के लिए Azure ML में Responsible AI डैशबोर्ड का उपयोग करें। स्थानीय (व्यक्तिगत भविष्यवाणी) स्पष्टीकरणों के लिए SHAP का और समग्र मॉडल व्यवहार के लिए वैश्विक फ़ीचर महत्व का उपयोग करें।

क्यों: SHAP मान एक विशिष्ट भविष्यवाणी पर प्रत्येक फ़ीचर के प्रभाव को जिम्मेदार ठहराने का एक मजबूत, मॉडल-अज्ञेयवादी तरीका प्रदान करते हैं, जो नियामक और डिबगिंग परिदृश्यों के लिए महत्वपूर्ण है।

ऋण अनुमोदन जैसे निर्णयों के लिए उपयोग किया जाने वाला मॉडल निष्पक्ष होना चाहिए और संरक्षित जनसांख्यिकीय समूहों के खिलाफ भेदभाव नहीं करना चाहिए।

→संवेदनशील सुविधाओं में निष्पक्षता मेट्रिक्स (जैसे जनसांख्यिकीय समानता, समतल ऑड्स) का विश्लेषण करने के लिए Responsible AI डैशबोर्ड के निष्पक्षता मूल्यांकन का उपयोग करें। यदि विसंगतियाँ पाई जाती हैं तो पोस्ट-प्रोसेसिंग थ्रेशोल्ड समायोजन जैसी शमन तकनीकों को लागू करें।

क्यों: निष्पक्षता मूल्यांकन समूहों में एक मॉडल के व्यवहार का मात्रात्मक प्रमाण प्रदान करता है। शमन तकनीकें न्यायसंगत परिणाम सुनिश्चित करने के लिए पूर्वाग्रहों को ठीक करने में मदद करती हैं।

एक LLM को विशिष्ट, निजी कंपनी दस्तावेज़ों के आधार पर प्रश्नों का उत्तर देना होगा, बिना तथ्यों को गढ़े (hallucinating).

→एक रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) पैटर्न लागू करें। दस्तावेज़ों का एक वेक्टर इंडेक्स बनाने के लिए Azure AI Search का उपयोग करें। क्वेरी समय पर, प्रासंगिक दस्तावेज़ खंडों को पुनः प्राप्त करें और उन्हें प्रॉम्प्ट में संदर्भ के रूप में LLM को पास करें।

क्यों: RAG LLM की प्रतिक्रिया को तथ्यात्मक, अद्यतन जानकारी में आधार बनाता है, जिससे मतिभ्रम (hallucinations) काफी कम हो जाते हैं और यह अपने मूल प्रशिक्षण डेटा में न होने वाले ज्ञान का उपयोग कर पाता है।

एक LLM को लगातार विशिष्ट दिशानिर्देशों, टोन और आउटपुट स्वरूपों (जैसे JSON उत्पन्न करना) का पालन करना चाहिए।

→विस्तृत सिस्टम प्रॉम्प्ट इंजीनियरिंग का उपयोग करें। एक स्पष्ट व्यक्ति, स्पष्ट नियम और बाधाएँ, और वांछित इनपुट/आउटपुट जोड़े के कुछ-शॉट उदाहरण प्रदान करें।

क्यों: एक अच्छी तरह से तैयार किया गया सिस्टम प्रॉम्प्ट फाइन-ट्यूनिंग की लागत और जटिलता के बिना एक LLM के व्यवहार को निर्देशित करने का सबसे सीधा और प्रभावी तरीका है।

RAG-आधारित LLM एप्लिकेशन की गुणवत्ता मापने की आवश्यकता है।

→RAG के लिए विशिष्ट मूल्यांकन मेट्रिक्स का उपयोग करें, जैसे ग्राउंडेडनेस (क्या उत्तर संदर्भ द्वारा समर्थित है?) और प्रासंगिकता (क्या उत्तर उपयोगकर्ता के प्रश्न को संबोधित करता है?)।

क्यों: ROUGE जैसे मानक NLP मेट्रिक्स अपर्याप्त हैं। ग्राउंडेडनेस और प्रासंगिकता सीधे RAG की मुख्य चुनौतियों को मापती हैं: मतिभ्रम (hallucination) को रोकना और उपयोगी उत्तर प्रदान करना।

एक LLM एप्लिकेशन उत्पादन उपयोग के लिए बहुत धीमा या महंगा है।

→सरल कार्यों के लिए छोटे, सस्ते मॉडल (जैसे GPT-3.5-Turbo) का उपयोग करने के लिए एक राउटर लागू करें। बार-बार की गई क्वेरी के लिए प्रतिक्रिया कैशिंग सक्षम करें। प्रॉम्प्ट लंबाई को अनुकूलित करें।

क्यों: कार्य के लिए सही आकार के मॉडल का उपयोग करना सबसे प्रभावी लागत-बचत उपाय है। कैशिंग अनावश्यक API कॉलों को समाप्त करता है, सीधे लागत और विलंबता को कम करता है।

एक LLM एप्लिकेशन संवेदनशील डेटा को संसाधित करता है जिसे कॉर्पोरेट नेटवर्क से बाहर नहीं जाना चाहिए या मॉडल प्रशिक्षण के लिए उपयोग नहीं किया जाना चाहिए।

→एक निजी एंडपॉइंट के साथ Azure OpenAI सेवा डिप्लॉय करें। प्रॉम्प्ट/कंप्लीशन डेटा को लॉग न करने के लिए संसाधन को कॉन्फ़िगर करें।

क्यों: निजी एंडपॉइंट नेटवर्क अलगाव सुनिश्चित करते हैं। नो-लॉगिंग विकल्प डेटा गोपनीयता की एक अतिरिक्त परत प्रदान करता है, जो सख्त अनुपालन आवश्यकताओं को पूरा करता है।

Azure AI Studio में विकसित एक प्रॉम्प्ट फ्लो को एक अत्यधिक उपलब्ध, स्केलेबल उत्पादन एंडपॉइंट के रूप में डिप्लॉय करने की आवश्यकता है।

→प्रॉम्प्ट फ्लो को एक Azure ML Managed Online Endpoint के रूप में डिप्लॉय करें।

क्यों: यह विकास से उत्पादन तक एक सहज मार्ग प्रदान करता है, जो पारंपरिक ML मॉडलों के लिए उपयोग किए जाने वाले समान मजबूत अवसंरचना (ऑटो-स्केलिंग, लोड बैलेंसिंग, मॉनिटरिंग) का लाभ उठाता है।

एक उपयोगकर्ता-सामना करने वाले जेनरेटिव AI एप्लिकेशन को हानिकारक, आपत्तिजनक, या असुरक्षित सामग्री उत्पन्न करने या संसाधित करने से संरक्षित किया जाना चाहिए।

→प्रॉम्प्ट और कंप्लीशन दोनों के लिए गहराई से मॉडरेशन के लिए अंतर्निहित Azure OpenAI कंटेंट फिल्टर और Azure AI कंटेंट सेफ्टी सेवा दोनों का उपयोग करें।

क्यों: स्तरित सुरक्षा महत्वपूर्ण है। अंतर्निहित फिल्टर एक बेसलाइन प्रदान करते हैं, जबकि समर्पित कंटेंट सेफ्टी सेवा अधिक विस्तृत नियंत्रण और मल्टी-मोडल क्षमताएं प्रदान करती है।

एक संवादी AI चैटबॉट को कई उपयोगकर्ता मोड़ों में संदर्भ बनाए रखने की आवश्यकता है।

→LLM स्टेटलेस होते हैं। एप्लिकेशन को वार्तालाप इतिहास (जैसे एक सत्र या डेटाबेस में) का प्रबंधन करना चाहिए और LLM को प्रत्येक नए प्रॉम्प्ट में इतिहास के प्रासंगिक हिस्सों को शामिल करना चाहिए।

क्यों: प्रत्येक API कॉल में स्पष्ट रूप से संदर्भ प्रदान करना ही एक स्टेटलेस LLM के लिए वार्तालाप को "याद रखने" का एकमात्र तरीका है।

सबसे अच्छा LLM प्रदर्शन देने वाले प्रॉम्प्ट को खोजने के लिए विभिन्न प्रॉम्प्ट का व्यवस्थित रूप से परीक्षण करने की आवश्यकता है।

→प्रॉम्प्ट फ्लो वेरिएंट का उपयोग करें। एक नोड के लिए कई प्रॉम्प्ट संस्करणों को परिभाषित करें और प्रदर्शन मेट्रिक्स की तुलना करने के लिए एक मूल्यांकन डेटासेट के खिलाफ एक बल्क टेस्ट चलाएँ।

क्यों: वेरिएंट प्रॉम्प्ट इंजीनियरिंग के लिए एक संरचित, डेटा-संचालित दृष्टिकोण प्रदान करते हैं, मैन्युअल ट्रायल-एंड-एरर से परे व्यवस्थित अनुकूलन की ओर बढ़ते हुए।

उत्पादन LLM एप्लिकेशन की परिचालन स्वास्थ्य और प्रतिक्रिया गुणवत्ता दोनों की निगरानी करने की आवश्यकता है।

→परिचालन टेलीमेट्री (विलंबता, त्रुटि दर, टोकन उपयोग) के लिए Application Insights को प्रतिक्रिया गुणवत्ता (ग्राउंडेडनेस, प्रासंगिकता) का आकलन करने के लिए एक मूल्यांकन प्रवाह का उपयोग करके आवधिक बैच मूल्यांकन कार्यों के साथ संयोजित करें।

क्यों: LLM मॉनिटरिंग के लिए सिस्टम प्रदर्शन और उत्पन्न सामग्री की गुणवत्ता दोनों को ट्रैक करने की आवश्यकता होती है। यह संयोजन एप्लिकेशन स्वास्थ्य का एक समग्र दृश्य प्रदान करता है।