स्वायत्त वाहने, औद्योगिक रोबोट्स आणि ड्रोनचे तांडव (drone fleets) जुन्या ऑटोपायलट प्रणालींना चालवणारे कडक, हाताने लिहिलेले नियम पाळत नाहीत. ते मोठ्या प्रमाणात डेटावरून शिकतात, ज्याचा अर्थ असा आहे की त्यांचे वर्तन संभाव्य (probabilistic) आहे, निश्चित (deterministic) नाही. पारंपारिक विमानाचा ऑटोपायलट स्पष्टपणे कोड केलेल्या लॉजिकद्वारे सेन्सर इनपुटवर प्रतिक्रिया देतो. मशीन लर्निंग मॉडेल प्रशिक्षणादरम्यान (training) शोधलेल्या पॅटर्नद्वारे प्रतिक्रिया देते. हा फरक पडताळणी (verification) अधिक कठीण बनवतो, आणि म्हणूनच मशीन लर्निंग समुदाय 'ॲड-हॉक' (ad-hoc) टेस्टिंगऐवजी संरचित आश्वासन फ्रेमवर्ककडे (structured assurance frameworks) वळला आहे.
मशीन लर्निंग आश्वासन (Machine Learning Assurance) का अनिवार्य आहे
जेव्हा एखादी स्वायत्त प्रणाली चूक करते, तेव्हा त्याचे परिणाम केवळ सर्व्हर एरर किंवा एखादे ॲप्लिकेशन हँग होण्यापुरते मर्यादित नसतात. वेअरहाऊस रोबोटने एखादा अडथळा चुकीचा ओळखल्यास इन्व्हेंटरी नष्ट होऊ शकते किंवा कामगाराला इजा होऊ शकते. डिलिव्हरी ड्रोनने पॉवर लाईनला मोकळे आकाश समजल्यास तो पायाभूत सुविधांमध्ये धडकून कोसळू शकतो. या प्रणाली जटिल न्यूरल नेटवर्क्स आणि सांख्यिकीय मॉडेल्सवर (statistical models) अवलंबून असल्याने, त्यांच्या त्रुटींचे प्रकार (failure modes) सूक्ष्म असतात. ते क्वचितच स्पष्टपणे बिघडतात. त्याऐवजी, प्रशिक्षणादरम्यान पाहिलेल्या वितरणाबाहेरच्या (outside the 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) समाविष्ट असावेत. जरी न्यूरल नेटवर्कने एखाद्या वस्तूचे चुकीचे वर्गीकरण केले तरी, वाहन किंवा रोबोटने कठोर मर्यादांचे (hard constraints) उल्लंघन करणारा मार्ग (trajectory) अवलंबणे भौतिकदृष्ट्या शक्य नसावे. याचा अर्थ रोबोटिक आर्म्सवरील टॉर्क मर्यादा, ड्रोनसाठी जिओफेंसिंग किंवा जमिनीवरील वाहनांसाठी अनिवार्य ब्रेकिंग कॉरिडॉर असा असू शकतो. स्वायत्त प्रणालीला अशा आर्किटेक्चरल लेयर्सची गरज आहे ज्या एका मॉडेलच्या त्रुटीमुळे एखादी अनियंत्रित भौतिक घटना घडू नये याची काळजी घेतील.
अनिश्चितता कमी करण्याच्या पद्धती. मशीन लर्निंगमधील अनिश्चितता विविध स्वरूपात असते. यामध्ये 'अलेअटोरिक अनिश्चितता' (aleatoric uncertainty - सेन्सर रीडिंग किंवा वातावरणातील अंगभूत गोंधळ/नॉईज) आणि 'एपिस्टेमिक अनिश्चितता' (epistemic uncertainty - जे मॉडेलला अद्याप माहित नाही ते दर्शवते) यांचा समावेश होतो. AMLAS या दोन्ही गोष्टींचे परिमाण मोजणे आणि व्यवस्थापित करणे या पद्धतींना प्रोत्साहन देते. यामध्ये 'एन्सेम्बल मेथड्स' (ensemble methods) तंत्रांचा समावेश असू शकतो, जिथे अनेक मॉडेल्समधील मतभेद इशारा म्हणून सूचित केले जातात, किंवा इनपुट व्हॅलिडेशन लेयर्सचा समावेश असू शकतो जे अनियमित वर्तन निर्माण करू शकणाऱ्या डेटाला नाकारतात. तुम्ही अनिश्चितता पूर्णपणे काढून टाकण्यात सक्षम नसाल, तरीही प्रणालीला त्यावर आंधळेपणाने कृती करण्यापासून रोखू शकता.
विश्वास निर्माण करण्याचा व्यावहारिक मार्ग
जर टीम्सनी त्यांची प्रत्यक्ष अंमलबजावणी केली तरच फ्रेमवर्क महत्त्वाचे ठरतात. जेव्हा संस्था शिस्तबद्ध अनुक्रम (disciplined sequence) पाळतात, तेव्हा AMLAS सर्वोत्तम प्रकारे कृतीत उतरते.
एकही डेटासेट गोळा करण्यापूर्वी तुमची सुरक्षा उद्दिष्टे निश्चित करा. पारंपारिक सॉफ्टवेअर इंजिनिअरिंगमध्ये, आवश्यकता (requirements) आधी येतात. मशीन लर्निंग प्रकल्पांमध्ये अनेकदा याच्या उलट घडते, जिथे मॉडेल प्रशिक्षित केल्यानंतर सुरक्षिततेला एक समस्या म्हणून सोडवण्याचा प्रयत्न केला जातो. ही सवय बदला. स्पष्ट 'ऑपरेशनल डिझाइन डोमेन'ने सुरुवात करा. सिस्टीम कोणत्या परिस्थितीत काम करेल? प्रत्येक धोक्यासाठी स्वीकारार्ह अपयशाचा दर (failure rate) काय असेल? कोणत्या अपयशांसाठी त्वरित मानवी हस्तक्षेपाची (human override) आवश्यकता असेल? या प्रश्नांची लवकर केलेली उत्तरे डेटा संकलन ते मॉडेल आर्किटेक्चरपर्यंत सर्व गोष्टींना आकार देतात.
तुमच्या मॉडेल्सची चाचणी अशा डेटावर करा जो वास्तविक कार्यात्मक गुंतागुंत (operational messiness) दर्शवतो. लॅब बेंचमार्क सोयीस्कर वाटतात, पण ते फसवे असू शकतात. केवळ स्वच्छ बारकोड प्रतिमांवर प्रशिक्षित केलेला वेअरहाऊस रोबोट, जेव्हा लेबल्स सुरकुतलेली, कमी प्रकाशात असलेली किंवा घाणीमुळे अडवलेली असतील, तेव्हा अपयशी ठरेल. केवळ चांगल्या हवामानात चाचणी घेतलेला ऑटोनॉमस ड्रोन, प्रखर प्रकाश (glare) आणि वाऱ्याच्या वेगाशी (wind shear) संघर्ष करेल. तुम्हाला प्रत्यक्ष तैनात केलेल्या वातावरणातून (deployment environments) लॉग्सची आवश्यकता आहे, ज्यामध्ये अशा कठीण 'एज केसेस'चा (edge cases) समावेश असेल ज्या क्युरेटेड डेटासेटमध्ये कधीही दिसत नाहीत. 'शॅडो मोड ट्रायल्स' (shadow mode trials) चालवा, जिथे ऑटोनॉमस सिस्टीम मानवी ऑपरेटर्सच्या समांतर निर्णय घेते परंतु अद्याप हार्डवेअरवर नियंत्रण ठेवत नाही. या लॉग्सची काटेकोरपणे तुलना करा.
तैनातीनंतर (deployment) कामगिरीचे सतत निरीक्षण करा. जग स्थिर नाही. ऋतूंनुसार बदलणारा प्रकाश, घासलेल्या रस्त्यांचे पृष्ठभाग, नवीन पॅकेजिंग डिझाइन्स आणि बदलणारे नेटवर्क ट्रॅफिक पॅटर्न, या सर्व गोष्टींमुळे एकेकाळी उत्तम काम करणाऱ्या मॉडेलची कार्यक्षमता कमी होऊ शकते. प्रिडिक्शन कॉन्फिडन्स (prediction confidence), इनपुट डिस्ट्रिब्युशन ड्रिफ्ट (input distribution drift) आणि घटनेचा दर (incident rates) ट्रॅक करणारी टेलीमेट्री (telemetry) सेट करा. जेव्हा वर्तनात बदल होतो, तेव्हा मानवी पुनरावलोकन किंवा तात्पुरत्या कार्यात्मक मर्यादा लागू करण्यासाठी थ्रेशोल्ड्स (thresholds) निश्चित करा. मॉडेल ही एखादी स्थिर उत्पादन नाही जी तुम्ही पाठवता आणि विसरून जाता. ते एक असे घटक आहे जे वास्तविक जगाला भेटताच जुने होऊ लागते.
वास्तविक-जगातील वैधतेबद्दलचे (Real-World Validation) कठोर सत्य
अनेक टीम्स स्वतःला पटवून देतात की उच्च व्हॅलिडेशन स्कोअर म्हणजे तयारी पूर्ण झाली आहे. तसे नाही. वास्तविक-जगातील वैधतेसाठी अस्वस्थता स्वीकारणे आवश्यक आहे. याचा अर्थ वादळी परिस्थितीत ड्रोन उडवणे, रात्रीच्या शिफ्टमध्ये जेव्हा बल्ब लुकलुकत असतात तेव्हा वेअरहाऊस रोबोट चालवणे आणि रस्ता चिन्हांवरील अॅडव्हर्सरिअल स्टिकर्सना (adversarial stickers) परसेप्शन मॉडेल्ससमोर उभे करणे असा आहे. जर तुमचे टेस्टिंग एन्व्हायरमेंट नीटनेटके आणि अंदाज लावण्यायोग्य वाटत असेल, तर तुम्ही चाचणी करत नाही आहात. तुम्ही फक्त सराव करत आहात.
ही प्रक्रिया खर्चिक आणि संथ आहे. यासाठी मशीन लर्निंग इंजिनिअर्स, सेफ्टी स्पेशालिस्ट्स आणि भौतिक वातावरण समजून घेणारे डोमेन ऑपरेटर्स यांच्यातील सहकार्याची आवश्यकता असते. याचे फळ म्हणजे पुराव्यांचा एक संच मिळतो. जेव्हा तुम्ही शेवटी तैनात (deploy) कराल, तेव्हा तुम्ही विशिष्ट चाचणी परिस्थिती, ज्ञात अपयशाचे प्रकार (failure modes) आणि प्रत्येक जोखमीशी संबंधित निवारणांकडे (mitigations) निर्देश दाखवू शकले पाहिजेत. हे डॉक्युमेंटेशनच एक प्रोटोटाइप आणि मानवांच्या जवळ अनियंत्रितपणे चालवण्यास तयार असलेल्या सिस्टीममध्ये फरक करते.
सिस्टीम्सना काळानुसार अचूक ठेवणे
तैनातीनंतरचे (post-deployment) निरीक्षण ही अशी जागा आहे जिथे अनेक अश्युरन्स प्रोग्राम्स शांतपणे कोलमडतात. टीम्स लाँचचा आनंद साजरा करतात आणि संसाधने पुढील फीचरसाठी वळवतात. दरम्यान, तैनात केलेले मॉडेल अशा इनपुट्सचा सामना करते जे त्याच्या ट्रेनिंग अनुभवापासून सूक्ष्मपणे वेगळे होतात. सक्रिय देखरेखीशिवाय, हा 'ड्रिफ्ट' (drift) इतका साचतो की एखादी गंभीर घटना प्रतिक्रियात्मक तपासासाठी भाग पाडते.
स्ट्रक्चर्ड फीडबॅक लूप्स (structured feedback loops) सेट करा. मॉडेल जिथे कमी कॉन्फिडन्स दर्शवते किंवा जिथे मानवी ऑपरेटर्स हस्तक्षेप करतात अशा प्रत्येक घटनेची नोंद करा. मॉडेलला वेळोवेळी पुन्हा प्रशिक्षित करण्यासाठी किंवा फाईन-ट्यून करण्यासाठी या लॉग्सचा वापर करा, परंतु प्रत्येक अपडेटची पडताळणी त्याच अश्युरन्स गेट्सद्वारे करा ज्यांचा वापर मूळ रिलीजसाठी केला होता. मॉडेल अपडेट्सना त्याच सावधगिरीने हाताळा जशी तुम्ही मेकॅनिकल ब्रेक सिस्टम बदलताना एखाद्या नवीन डिझाइनसाठी हाताळाल.
मुख्य निष्कर्ष
ऑटोनॉमस सिस्टीममधील मशीन लर्निंग हे केवळ संशोधनाचे सँडबॉक्स नाही. हे असे इन्फ्रास्ट्रक्चर आहे ज्यामध्ये भौतिक जोखीम असते आणि त्याला एरोस्पेस आणि मेडिकल डिव्हाइस इंजिनिअर्स हार्डवेअरला लावतात तशाच कठोरतेची आवश्यकता आहे. AMLAS अशा कठोरतेसाठी शब्दसंग्रह आणि कार्यप्रवाह (workflow) प्रदान करते. ते तुमच्यासाठी विश्वास आपोआप निर्माण करणार नाही, परंतु तो मिळवण्यासाठी तुम्हाला एक पुनरावृत्ती करण्यायोग्य मार्ग देते. प्रामाणिक सुरक्षा उद्दिष्टांपासून सुरुवात करा. अशुद्ध आणि अस्सल डेटावर चाचणी करा. सिस्टीम लाईव्ह झाल्यावर एखाद्या संशयवादीप्रमाणे तिचे निरीक्षण करा. फ्रेमवर्क्स अस्तित्वात आहेत. बाकी सर्व शिस्त आहे.
AMLAS मार्गदर्शनाच्या पूर्ण तांत्रिक तपशिलासाठी, मूळ तपशील येथे वाचा: https://dev.to/paperium/guidance-on-the-assurance-of-machine-learning-in-autonomous-systems-amlas-f9
जर तुम्हाला अश्युरन्स स्ट्रॅटेजीजवर चर्चा करायची असेल आणि समान समस्यांवर काम करणाऱ्या समुदायासोबत व्यावहारिक नोट्सची देवाणघेवाण करायची असेल, तर येथे चर्चेत सामील व्हा: https://t.me/GyaanSetuAi