मला समजले की एका AI-जनरेटेड एक्सप्लेनेशन फीचरमधील (explanation feature) पूर्ण दिवसाचा आउटेज (outage) एका सिंगल सेफ्टी-गेट मेट्रिकमुळे (safety-gate metric) लपला होता. “गेट रिजेक्शन” (gate rejection) आणि “मॉडेल लोड फेल्युअर” (model load failure) या दोन्ही गोष्टींना एकच मानल्यामुळे, त्या मेट्रिकने सिस्टमच्या स्थितीबद्दल चुकीची खात्री दिली. त्याने चार रिजेक्शन्स आणि शून्य सक्सेस लॉग केले, तरीही त्या काळात मॉडेल कधीच चालले नव्हते—ही एक अशी चूक होती ज्यामुळे ऑपरेटर्सना बिघडलेली सिस्टम ओळखता आली नसती.
ही गोंधळाची स्थिती कशी निर्माण झाली
हे वैशिष्ट्य (feature) कच्च्या मशीन लॉजिकचे मानवाला वाचता येतील अशा वाक्यांमध्ये रूपांतर करण्यासाठी स्थानिक लँग्वेज मॉडेलचा वापर करते. डाऊनस्ट्रीममधील एक सेफ्टी गेट कोणत्याही आउटपुटला ब्लॉक करते जे पूर्वनिर्धारित नियमांचे उल्लंघन करते. प्रोडक्शनमध्ये, मी एक सिंगल काउंटर एक्सपोज केला होता जो गेटने वाक्य नाकारले की प्रत्येक वेळी वाढत असे. जेव्हा ड्रोनने चार AI स्पष्टीकरणे लॉग केली, तेव्हा काउंटरने चार रिजेक्शन्स आणि शून्य यशस्वी आउटपुट दाखवले. मी याला गेट आपले काम करत आहे असे मानले, फीचर बंद आहे असे नाही.
काउंटरने लपवलेले अपयश दोन टप्प्यांत होते:
- मॉडेल चालू नाहीये – मॉडेल सिस्टमच्या इतर भागांसोबत एकाच मशीनवर चालते. मेमरी वाचवण्यासाठी, इनॅक्टिव्हिटीनंतर होस्ट ते अनलोड करते.
- रीलोड करताना टाइमआउट – जेव्हा नवीन धोका समोर आला, तेव्हा सिस्टमने अंदाजे दोन गिगाबाइट मॉडेल डेटा रीलोड करण्याचा प्रयत्न केला. रीलोड प्रक्रियेला तीस सेकंदांच्या रिस्पॉन्स टाइमआउटपेक्षा जास्त वेळ लागला, त्यामुळे विनंती (request) टाइमआउट झाली आणि रिकामे उत्तर मिळाले.
कारण काउंटरने गेटद्वारे झालेला रिजेक्शन आणि टाइमआउटमुळे मिळालेले रिकामे उत्तर या दोन्ही गोष्टींना एकच घटना मानले, त्यामुळे डॅशबोर्डवर "काम करणारा सेफ्टी गेट" दिसत होता, तर प्रत्यक्षात AI फीचर बंद पडले होते.
हे महत्त्वाचे का आहे
AI-आधारित उत्पादनांमध्ये, सेफ्टी गेट्स हानिकारक किंवा अर्थहीन आउटपुट रोखतात. ऑपरेटर्स हेल्थ सिग्नल म्हणून गेटचा फायर रेट पाहतात. जेव्हा तो सिग्नल असंबंधित फेल्युअर मोडसोबत मिसळतो, तेव्हा ते मेट्रिक एक 'शांत खोटं' (silent lie) बनते: सेवा उपलब्ध नसतानाही ते खात्री देते.
व्हिजिबिलिटी परत आणणारा उपाय
मी तीन व्यावहारिक बदल केले:
- मॉडेल मेमरीमध्ये कायम ठेवा – रीलोडमधील विलंब टाळण्यासाठी होस्टमध्ये मॉडेल मेमरीमध्येच ठेवण्यासाठी बदल केले.
- टाइमआउट वाढवा – अधूनमधून होणाऱ्या स्लो लोड हाताळण्यासाठी रिस्पॉन्स विंडो वाढवली.
- काउंटर विभाजित करा – सिंगल “rejected by gate” मेट्रिकच्या जागी चार वेगळे काउंटर वापरले: accepted, rejected, empty response, आणि no answer.
तिसरा टप्पा निर्णायक ठरला. एका सिंगल नंबरऐवजी, जो कोणत्याही प्रकारे वाचला जाऊ शकत होता, या चार भागांच्या विभागणीमुळे सेफ्टी गेट सक्रिय आहे की नाही, मॉडेल उत्तर देत आहे की नाही, किंवा विनंती मॉडेलपर्यंत पोहोचलीच नाही, हे स्पष्टपणे समजते.
ट्रेड-ऑफ्स आणि प्रतिवाद (Trade-offs and counter-arguments)
पुढे काय पाहावे
AI घटक तैनात करणाऱ्या डेव्हलपर्सनी सेफ्टी चेक आणि सिस्टम-लेव्हल फेल्युअर एकत्र करणाऱ्या कोणत्याही एकत्रित (aggregated) काउंटर्सचे ऑडिट केले पाहिजे. प्रत्येक विनंतीचा मार्ग—मॉडेल लोडची सुरुवात, गेट इव्हॅल्युएशन, अंतिम निकाल—नोंदवणारा एक तपशीलवार हिस्ट्री लॉग तयार केल्यास लपलेल्या समस्या शोधण्यासाठी आवश्यक असलेला फॉरेन्सिक डेटा मिळेल.
महत्त्वाचा निष्कर्ष: एक सिंगल “gate-rejection” मेट्रिक बंद पडलेली AI सेवा लपवू शकते; त्या मेट्रिकचे त्याच्या घटक इव्हेंट्समध्ये विभाजन केल्यास सत्य समोर येते आणि प्रत्यक्षात काम न करणाऱ्या सिस्टमवर चुकीचा विश्वास निर्माण होण्यापासून वाचवते.