मैंने पाया कि एक सिंगल सेफ्टी-गेट मेट्रिक ने AI-जनरेटेड एक्सप्लेनेशन फीचर में पूरे दिन की आउटेज (outage) को छिपा दिया। "गेट रिजेक्शन" (gate rejection) और "मॉडल लोड फेलियर" (model load failure) को एक ही चीज़ मानकर, मेट्रिक ने सिस्टम के ठीक होने का एक झूठा अहसास दिया। इसने चार रिजेक्शन लॉग किए और शून्य सफलताएं, फिर भी उस अवधि के दौरान मॉडल कभी चला ही नहीं—एक ऐसी गलती जो ऑपरेटरों को एक खराब सिस्टम के प्रति अंधा छोड़ सकती थी।
यह भ्रम कैसे हुआ
यह फीचर रॉ मशीन लॉजिक को मानव-पठनीय वाक्यों में बदलने के लिए एक लोकल लैंग्वेज मॉडल का उपयोग करता है। एक डाउनस्ट्रीम सेफ्टी गेट किसी भी ऐसे आउटपुट को ब्लॉक कर देता है जो पूर्व-निर्धारित नियमों का उल्लंघन करता है। प्रोडक्शन में, मैंने एक सिंगल काउंटर एक्सपोज़ किया था जो तब बढ़ जाता था जब गेट किसी वाक्य को रिजेक्ट कर देता था। जब ड्रोन ने चार AI एक्सप्लेनेशन लॉग किए, तो काउंटर ने चार रिजेक्शन और कोई सफल आउटपुट नहीं दिखाया। मैंने इसे गेट द्वारा अपना काम करने के रूप में लिया, न कि फीचर के डाउन होने के रूप में।
काउंटर ने जिस दो-चरणीय विफलता (two-stage failure) को छिपाया था, वह यह थी:
- मॉडल नहीं चल रहा था – मॉडल सिस्टम के बाकी हिस्सों के साथ एक ही मशीन साझा करता है। मेमोरी बचाने के लिए, होस्ट इसे निष्क्रियता के बाद अनलोड कर देता है।
- रीलोड पर टाइमआउट – जब एक नया खतरा सामने आया, तो सिस्टम ने लगभग दो गीगाबाइट मॉडल डेटा को रीलोड करने की कोशिश की। रीलोड तीस सेकंड के रिस्पॉन्स टाइमआउट से अधिक हो गया, इसलिए अनुरोध (request) टाइमआउट हो गया और एक खाली उत्तर लौटा दिया।
चूंकि काउंटर ने एक गेटेड रिजेक्शन और टाइमआउट के कारण मिले खाली उत्तर को एक ही घटना माना, इसलिए डैशबोर्ड ने "काम करने वाले सेफ्टी गेट" को दिखाया जबकि AI फीचर प्रभावी रूप से बंद था।
यह क्यों मायने रखता है
AI-संचालित उत्पादों में, सेफ्टी गेट हानिकारक या निरर्थक आउटपुट को रोकते हैं। ऑपरेटर स्वास्थ्य संकेत (health signal) के रूप में गेट के फायर रेट पर नज़र रखते हैं। जब वह संकेत असंबंधित विफलता मोड (failure modes) के साथ मिल जाता है, तो मेट्रिक एक मौन झूठ बन जाता है: यह आश्वासन देता है जबकि सेवा अनुपलब्ध होती है।
वह समाधान जिसने विजिबिलिटी बहाल की
मैंने तीन व्यावहारिक बदलाव किए:
- मॉडल को रेजिडेंट रखें – होस्ट को मेमोरी में मॉडल बनाए रखने के लिए एडजस्ट किया, जिससे रीलोड में होने वाली देरी खत्म हो गई।
- टाइमआउट बढ़ाएं – कभी-कभार होने वाले धीमे लोड को संभालने के लिए रिस्पॉन्स विंडो को बढ़ा दिया।
- काउंटर को विभाजित करें – सिंगल "rejected by gate" मेट्रिक को चार अलग-अलग काउंटरों से बदल दिया: accepted, rejected, empty response, और no answer।
तीसरा कदम निर्णायक साबित हुआ। एक सिंगल नंबर के बजाय जिसे किसी भी तरह से पढ़ा जा सकता था, चार-भागों वाला यह विवरण दिखाता है कि क्या सेफ्टी गेट सक्रिय है, क्या मॉडल उत्तर दे रहा है, या क्या अनुरोध मॉडल तक पहुँचा ही नहीं।
ट्रेड-ऑफ और काउंटर-तर्क
आगे क्या ध्यान रखें
AI कंपोनेंट्स रोल आउट करने वाले डेवलपर्स को किसी भी ऐसे एग्रीगेटेड काउंटर का ऑडिट करना चाहिए जो सेफ्टी चेक को सिस्टम-लेवल फेलियर के साथ मिलाते हैं। एक विस्तृत हिस्ट्री लॉग बनाना जो प्रत्येक अनुरोध के पथ—मॉडल लोड शुरू होना, गेट मूल्यांकन, अंतिम परिणाम—को रिकॉर्ड करता है, छिपी हुई समस्याओं का पता लगाने के लिए आवश्यक फॉरेंसिक डेटा प्रदान करता है।
मुख्य बात (Takeaway): एक सिंगल "gate-rejection" मेट्रिक एक मृत AI सर्विस को छिपा सकता है; उस मेट्रिक को उसके घटक इवेंट्स में विभाजित करने से सच्चाई सामने आती है और उस सिस्टम में झूठे भरोसे को रोकती है जो वास्तव में काम नहीं कर रहा है।