स्वायत्त वाहन (Autonomous vehicles), औद्योगिक रोबोट और ड्रोन बेड़े उन कठोर, हस्तलिखित नियमपुस्तिकाओं का पालन नहीं करते हैं जिन्होंने पुराने ऑटोपायलट सिस्टम को संचालित किया था। वे डेटा की विशाल मात्रा से सीखते हैं, जिसका अर्थ है कि उनका व्यवहार संभाव्य (probabilistic) है, न कि नियतात्मक (deterministic)। एक पारंपरिक विमान ऑटोपायलट स्पष्ट रूप से कोड किए गए तर्क (logic) के माध्यम से सेंसर इनपुट पर प्रतिक्रिया करता है। एक मशीन लर्निंग मॉडल उन पैटर्न के माध्यम से प्रतिक्रिया करता है जिनका उसने प्रशिक्षण के दौरान अनुमान लगाया था। यह अंतर सत्यापन (verification) को कहीं अधिक कठिन बना देता है, और यही कारण है कि मशीन लर्निंग समुदाय एड-हॉक टेस्टिंग (ad-hoc testing) के बजाय संरचित आश्वासन ढांचे (structured assurance frameworks) की ओर बढ़ गया है।
मशीन लर्निंग आश्वासन (Machine Learning Assurance) क्यों अनिवार्य है
जब कोई स्वायत्त प्रणाली गलती करती है, तो उसके परिणाम सर्वर त्रुटि या किसी ऐप के फ्रीज होने से कहीं अधिक व्यापक होते हैं। एक वेयरहाउस रोबोट द्वारा किसी बाधा की गलत पहचान करने से इन्वेंट्री नष्ट हो सकती है या किसी कर्मचारी को चोट लग सकती है। एक डिलीवरी ड्रोन द्वारा बिजली की लाइन को खुला आसमान समझने से वह बुनियादी ढांचे (infrastructure) से टकरा सकता है। क्योंकि ये प्रणालियाँ जटिल न्यूरल नेटवर्क और सांख्यिकीय मॉडलों पर निर्भर करती हैं, इसलिए उनके विफलता मोड (failure modes) सूक्ष्म होते हैं। वे शायद ही कभी स्पष्ट रूप से खराब होते हैं। इसके बजाय, जब उन्हें ऐसे इनपुट मिलते हैं जो उनके प्रशिक्षण के दौरान देखे गए वितरण (distributions) से बाहर होते हैं, तो वे चुपचाप खराब होने लगते हैं।
स्वायत्त मशीन लर्निंग में त्रुटियाँ हमेशा स्पष्ट रूप से खराब कोड से उत्पन्न नहीं होती हैं। वे प्रशिक्षण डेटा में कमियों, अप्रत्याशित पर्यावरणीय बदलावों, या एज केस (edge cases) पर अत्यधिक आत्मविश्वासी भविष्यवाणियों से उत्पन्न हो सकती हैं। वे संगठन जो ML घटकों को मानक सॉफ्टवेयर मॉड्यूल की तरह मानते हैं और यह मान लेते हैं कि एक यूनिट टेस्ट सूट पर्याप्त है, उन्हें बहुत देर से पता चलता है कि प्रयोगशाला की सटीकता वास्तविक दुनिया की सुरक्षा में परिवर्तित नहीं होती है। आपको एक व्यवस्थित मानक की आवश्यकता है जो सीखे गए व्यवहार के अद्वितीय जोखिमों को संबोधित करे। यही वह कमी है जिसे भरने के लिए AMLAS फ्रेमवर्क को डिज़ाइन किया गया है।
AMLAS वास्तव में क्या कवर करता है
AMLAS, जिसका अर्थ है 'Assurance of Machine Learning for use in Autonomous Systems', यह सत्यापित करने के लिए एक एंड-टू-एंड दृष्टिकोण प्रदान करता है कि सीखे गए घटक उच्च-जोखिम वाले परिनियोजन (high-stakes deployment) के लिए उपयुक्त हैं। यह सुरक्षा को बाद में सोचने वाली चीज़ या रिलीज़ से पहले के अंतिम गेट के रूप में नहीं देखता है। इसके बजाय, यह आश्वासन गतिविधियों को सिस्टम के जीवनचक्र (lifecycle) में बुन देता है।
यह फ्रेमवर्क तीन व्यावहारिक स्तंभों पर केंद्रित है:
ML मॉडल के लिए सत्यापन विधियाँ। यह सटीकता (accuracy) या F1 स्कोर जैसे मानक ट्रेन-टेस्ट स्प्लिट मेट्रिक्स से कहीं आगे जाता है। AMLAS के तहत आश्वासन यह पूछता है कि क्या मॉडल निर्णय सीमाओं (decision boundaries) पर पूर्वानुमेय व्यवहार करता है, यह आउट-ऑफ-डिस्ट्रीब्यूशन (out-of-distribution) इनपुट पर कैसी प्रतिक्रिया देता है, और क्या इसके कॉन्फिडेंस स्कोर वास्तविक अनिश्चितता के विश्वसनीय संकेतक हैं। इंजीनियरों से अपेक्षा की जाती है कि वे एडवर्सरियल उदाहरणों (adversarial examples) के साथ मॉडल की जांच करें और प्रशिक्षण सेट से थोड़े बाहर के डोमेन के इनपुट के विरुद्ध इसका स्ट्रेस-टेस्ट करें। लक्ष्य पूर्णता प्राप्त करना नहीं है। बल्कि यह पर्याप्त प्रमाण प्राप्त करना है जिससे यह पता चल सके कि मॉडल पर कब भरोसा किया जा सकता है और कब नहीं।
स्वायत्त कार्यों के लिए सुरक्षा प्रोटोकॉल। एक सीखा हुआ परसेप्शन मॉडल (perception model) प्लानिंग और कंट्रोल सॉफ्टवेयर को डेटा देता है जो भौतिक हार्डवेयर को संचालित करता है। AMLAS की मांग है कि इन डाउनस्ट्रीम कार्यों में गार्डरेल्स (guardrails) शामिल हों। भले ही एक न्यूरल नेटवर्क किसी वस्तु को गलत वर्गीकृत कर दे, वाहन या रोबोट भौतिक रूप से ऐसी प्रक्षेपवक्र (trajectory) का पालन करने में सक्षम नहीं होना चाहिए जो कठोर बाधाओं (hard constraints) का उल्लंघन करती हो। इसका अर्थ रोबोटिक आर्म्स पर टॉर्क सीमाएं, ड्रोन के लिए जियोफेंसिंग, या जमीनी वाहनों के लिए अनिवार्य ब्रेकिंग कॉरिडोर हो सकता है। स्वायत्त प्रणाली को ऐसे आर्किटेक्चरल लेयर्स की आवश्यकता होती है जो मॉडल की एक एकल त्रुटि को अनियंत्रित भौतिक घटना बनने से रोक सकें।
अनिश्चितता को कम करने के तरीके। मशीन लर्निंग में अनिश्चितता कई रूपों में आती है। इसमें एलियटोरिक अनिश्चितता (aleatoric uncertainty) — सेंसर रीडिंग या वातावरण में अंतर्निहित शोर, और एपिस्टेमिक अनिश्चितता (epistemic uncertainty) — जो यह दर्शाती है कि मॉडल अभी क्या नहीं जानता, शामिल हैं। AMLAS ऐसी प्रथाओं को प्रोत्साहित करता है जो दोनों को मात्रात्मक रूप से मापें और प्रबंधित करें। तकनीकों में एन्सेम्बल विधियाँ (ensemble methods) शामिल हो सकती हैं, जहाँ कई मॉडल असहमति को चेतावनी संकेत के रूप में चिह्नित करते हैं, या इनपुट वैलिडेशन लेयर्स जो ऐसे डेटा को अस्वीकार कर देती हैं जिससे अनियमित व्यवहार होने की संभावना हो। आप अनिश्चितता को पूरी तरह से समाप्त नहीं कर सकते, लेकिन आप सिस्टम को उस पर आँख मूंदकर कार्रवाई करने से रोक सकते हैं।
विश्वास बनाने का एक व्यावहारिक मार्ग
फ्रेमवर्क तभी मायने रखते हैं जब टीमें उन्हें व्यवहार में लाती हैं। AMLAS का क्रियान्वयन तब सबसे अच्छा होता है जब संगठन एक अनुशासित क्रम का पालन करते हैं।
एक भी डेटासेट इकट्ठा करने से पहले अपने सुरक्षा लक्ष्यों को परिभाषित करें। पारंपरिक सॉफ्टवेयर इंजीनियरिंग में, आवश्यकताएँ पहले आती हैं। मशीन लर्निंग प्रोजेक्ट्स अक्सर इसके विपरीत करते हैं, सुरक्षा को मॉडल प्रशिक्षित होने के बाद हल की जाने वाली समस्या के रूप में देखते हैं। इस आदत को बदलें। एक स्पष्ट ऑपरेशनल डिज़ाइन डोमेन (operational design domain) के साथ शुरुआत करें। सिस्टम किन परिस्थितियों में चलेगा? प्रत्येक खतरे के लिए स्वीकार्य विफलता दर क्या होगी? किन विफलताओं के लिए तत्काल मानवीय हस्तक्षेप की आवश्यकता होगी? इन प्रश्नों का जल्दी उत्तर देना डेटा संग्रह से लेकर मॉडल आर्किटेक्चर तक सब कुछ आकार देता है।
अपने मॉडलों का परीक्षण ऐसे डेटा के विरुद्ध करें जो वास्तविक परिचालन की जटिलताओं को दर्शाता हो। लैब बेंचमार्क सुकून देने वाले हो सकते हैं, लेकिन वे भ्रामक होते हैं। एक वेयरहाउस रोबोट जिसे केवल साफ-सुथरी बारकोड छवियों पर प्रशिक्षित किया गया है, वह तब विफल हो जाएगा जब लेबल सिकुड़े हुए, कम रोशनी वाले, या गंदगी से ढके होंगे। एक स्वायत्त ड्रोन जिसका परीक्षण केवल साफ मौसम में किया गया है, उसे चमक (glare) और हवा के झोंकों (wind shear) के साथ संघर्ष करना पड़ेगा। आपको वास्तविक तैनाती वातावरण (deployment environments) के लॉग की आवश्यकता है, जिसमें वे परेशान करने वाले 'एज केसेस' भी शामिल हों जो क्यूरेटेड डेटासेट में कभी नहीं दिखाई देते। शैडो मोड ट्रायल चलाएं जहां स्वायत्त सिस्टम मानव ऑपरेटरों के साथ समानांतर में निर्णय लेता है लेकिन अभी हार्डवेयर को नियंत्रित नहीं करता है। लॉग्स की कठोरता से तुलना करें।
तैनाती के बाद प्रदर्शन की निरंतर निगरानी करें। दुनिया स्थिर नहीं है। मौसमी रोशनी में बदलाव, घिसी हुई सड़कों की सतह, नए पैकेजिंग डिज़ाइन और बदलते नेटवर्क ट्रैफिक पैटर्न, ये सभी उस मॉडल को खराब कर सकते हैं जिसने कभी शानदार प्रदर्शन किया था। ऐसी टेलीमेट्री सेटअप करें जो प्रेडिक्शन कॉन्फिडेंस, इनपुट डिस्ट्रीब्यूशन ड्रिफ्ट और घटना दरों (incident rates) को ट्रैक करे। ऐसे थ्रेशोल्ड स्थापित करें जो व्यवहार बदलने पर मानवीय समीक्षा या अस्थायी परिचालन प्रतिबंधों को ट्रिगर करें। एक मॉडल कोई स्थिर उत्पाद नहीं है जिसे आप शिप करके भूल जाएं। यह एक ऐसा घटक है जो वास्तविक दुनिया के संपर्क में आते ही पुराना होने लगता है।
वास्तविक दुनिया के सत्यापन (Real-World Validation) की कड़वी सच्चाई
कई टीमें खुद को यह विश्वास दिला लेती हैं कि उच्च वैलिडेशन स्कोर तैयारी का संकेत है। ऐसा नहीं है। वास्तविक दुनिया के सत्यापन के लिए असहजता को स्वीकार करना आवश्यक है। इसका अर्थ है तेज़ हवाओं के बीच ड्रोन उड़ाना, रात की शिफ्ट के दौरान वेयरहाउस रोबोट चलाना जब बल्ब टिमटिमा रहे हों, और परसेप्शन मॉडलों को सड़क संकेतों पर एडवर्सरियल स्टिकर्स के संपर्क में लाना। यदि आपका परीक्षण वातावरण व्यवस्थित और अनुमानित लगता है, तो आप परीक्षण नहीं कर रहे हैं। आप केवल अभ्यास कर रहे हैं।
यह प्रक्रिया महंगी और धीमी है। इसके लिए मशीन लर्निंग इंजीनियरों, सुरक्षा विशेषज्ञों और उन डोमेन ऑपरेटर्स के बीच सहयोग की आवश्यकता होती है जो भौतिक वातावरण को समझते हैं। इसका प्रतिफल साक्ष्यों का एक संग्रह है। जब आप अंततः तैनात करते हैं, तो आप विशिष्ट परीक्षण स्थितियों, ज्ञात विफलता मोड और प्रत्येक जोखिम से जुड़े समाधानों (mitigations) की ओर इशारा करने में सक्षम होने चाहिए। वही दस्तावेज़ीकरण एक प्रोटोटाइप को उस सिस्टम से अलग करता है जिसे आप मनुष्यों के पास बिना पर्यवेक्षण के चलाने के लिए तैयार हैं।
समय के साथ सिस्टम की विश्वसनीयता बनाए रखना
तैनाती के बाद की निगरानी वह जगह है जहाँ कई अश्योरेंस प्रोग्राम चुपचाप विफल हो जाते हैं। टीमें लॉन्च का जश्न मनाती हैं और संसाधनों को अगली विशेषता (feature) के लिए पुनर्वितरित कर देती हैं। इस बीच, तैनात मॉडल इनपुट के उस प्रवाह का सामना करता है जो उसके प्रशिक्षण अनुभव से सूक्ष्म रूप से अलग होते हैं। सक्रिय निगरानी के बिना, यह ड्रिफ्ट तब तक जमा होता रहता है जब तक कि कोई गंभीर घटना प्रतिक्रियात्मक जांच (reactive investigation) के लिए मजबूर न कर दे।
संरचित फीडबैक लूप स्थापित करें। हर उस उदाहरण को लॉग करें जहाँ मॉडल कम आत्मविश्वास (low confidence) व्यक्त करता है या जहाँ मानव ऑपरेटर हस्तक्षेप करते हैं। इन लॉग्स का उपयोग समय-समय पर मॉडल को पुन: प्रशिक्षित या फाइन-ट्यून करने के लिए करें, लेकिन प्रत्येक अपडेट को उन्हीं अश्योरेंस गेट्स के माध्यम से सत्यापित करें जो मूल रिलीज़ पर लागू थे। मॉडल अपडेट के साथ उतनी ही सावधानी बरतें जितनी आप एक नए डिज़ाइन के लिए मैकेनिकल ब्रेक सिस्टम को बदलने में बरतेंगे।
मुख्य निष्कर्ष (The Real Takeaway)
स्वायत्त प्रणालियों में मशीन लर्निंग कोई रिसर्च सैंडबॉक्स नहीं है। यह एक ऐसा इंफ्रास्ट्रक्चर है जिसमें भौतिक जोखिम शामिल है, और यह उसी कठोरता का हकदार है जो एयरोस्पेस और मेडिकल डिवाइस इंजीनियर हार्डवेयर पर लागू करते हैं। AMLAS उस कठोरता के लिए शब्दावली और वर्कफ़्लो प्रदान करता है। यह आपके लिए विश्वास को स्वचालित नहीं करेगा, लेकिन यह आपको इसे अर्जित करने का एक दोहराने योग्य तरीका देता है। ईमानदार सुरक्षा लक्ष्यों के साथ शुरुआत करें। गंदे, प्रामाणिक डेटा के विरुद्ध सत्यापन करें। एक बार लाइव होने के बाद सिस्टम को एक संशयवादी (skeptic) की तरह देखें। ढांचे मौजूद हैं। बाकी सब अनुशासन है।
AMLAS मार्गदर्शन के पूर्ण तकनीकी विवरण के लिए, यहाँ मूल विवरण पढ़ें: https://dev.to/paperium/guidance-on-the-assurance-of-machine-learning-in-autonomous-systems-amlas-f9
यदि आप अश्योरेंस रणनीतियों पर चर्चा करना चाहते हैं और समान समस्याओं पर काम कर रहे समुदाय के साथ व्यावहारिक नोट्स साझा करना चाहते हैं, तो यहाँ बातचीत में शामिल हों: https://t.me/GyaanSetuAi