میں نے دریافت کیا کہ ایک واحد سیفٹی گیٹ میٹرک (safety-gate metric) نے AI سے تیار کردہ وضاحت کے فیچر میں پورے ایک دن کی تعطیلی کو چھپا لیا تھا۔ "گیٹ ریجیکشن" (gate rejection) اور "ماڈل لوڈ فیلئیر" (model load failure) کو ایک ہی چیز سمجھنے کی وجہ سے، اس میٹرک نے سسٹم کے درست ہونے کا ایک غلط احساس دلایا۔ اس نے چار ریجیکشنز اور صفر کامیابیوں کو لاگ کیا، حالانکہ اس دوران ماڈل کبھی چلا ہی نہیں تھا—یہ ایک ایسی غلطی تھی جو آپریٹرز کو ایک خراب سسٹم کے بارے میں اندھیرے میں رکھ سکتی تھی۔
یہ الجھن کیسے پیدا ہوئی
یہ فیچر خام مشین لاجک کو انسان کے پڑھنے کے قابل جملوں میں تبدیل کرنے کے لیے ایک مقامی لینگویج ماڈل کا استعمال کرتا ہے۔ ایک ڈاؤن اسٹریم سیفٹی گیٹ کسی بھی ایسے آؤٹ پٹ کو روک دیتا ہے جو پہلے سے طے شدہ قواعد کی خلاف ورزی کرتا ہو۔ پروڈکشن میں، میں نے ایک واحد کاؤنٹر ظاہر کیا جو اس وقت بڑھ جاتا تھا جب گیٹ کسی جملے کو مسترد کر دیتا تھا۔ جب ڈرون نے چار AI وضاحتیں لاگ کیں، تو کاؤنٹر نے چار ریجیکشنز اور کوئی کامیاب آؤٹ پٹ نہ ہونے کی اطلاع دی۔ میں نے اسے گیٹ کا اپنا کام کرنے کے طور پر لیا، نہ کہ اس طور پر کہ فیچر بند ہو چکا ہے۔
کاؤنٹر نے جس دو مرحلہ وار ناکامی کو چھپایا وہ یہ تھی:
- ماڈل کا نہ چلنا – ماڈل سسٹم کے باقی حصوں کے ساتھ ایک ہی مشین شیئر کرتا ہے۔ میموری بچانے کے لیے، ہوسٹ غیر فعالیت (inactivity) کے بعد اسے ان لوڈ کر دیتا ہے۔
- ری لوڈ پر ٹائم آؤٹ – جب ایک نیا خطرہ سامنے آیا، تو سسٹم نے تقریباً دو گیگا بائٹ ماڈل ڈیٹا کو دوبارہ لوڈ کرنے کی کوشش کی۔ ری لوڈ کا عمل تیسے سیکنڈ کے رسپانس ٹائم آؤٹ سے تجاوز کر گیا، اس لیے درخواست ٹائم آؤٹ ہو گئی اور ایک خالی جواب واپس آیا۔
چونکہ کاؤنٹر نے گیٹ ریجیکشن اور ٹائم آؤٹ کی وجہ سے آنے والے خالی جواب کو ایک ہی واقعہ سمجھا، اس لیے ڈیش بورڈ نے "کام کرنے والے سیفٹی گیٹ" کا اشارہ دیا جبکہ AI فیچر عملی طور پر بند تھا۔
یہ کیوں اہم ہے
AI پر مبنی مصنوعات میں، سیفٹی گیٹس نقصان دہ یا بے معنی آؤٹ پٹ کو روکتے ہیں۔ آپریٹرز صحت کے اشارے کے طور پر گیٹ کی فائر ریٹ (fire rate) پر نظر رکھتے ہیں۔ جب وہ اشارہ غیر متعلقہ ناکامیوں کے ساتھ مل جاتا ہے، تو میٹرک ایک خاموش جھوٹ بن جاتا ہے: یہ اس وقت اطمینان دلاتا ہے جب سروس دستیاب نہ ہو۔
وہ حل جس نے شفافیت بحال کی
میں نے تین عملی تبدیلیاں کیں:
- ماڈل کو میموری میں برقرار رکھیں – ہوسٹ کو اس طرح ایڈجسٹ کیا کہ ماڈل میموری میں رہے، جس سے ری لوڈ میں ہونے والی تاخیر ختم ہو گئی۔
- ٹائم آؤٹ میں اضافہ کریں – کبھی کبھار ہونے والی سست لوڈنگ کو سنبھالنے کے لیے رسپانس ونڈو کو بڑھا دیا۔
- کاؤنٹر کو تقسیم کریں – واحد "rejected by gate" میٹرک کو چار الگ الگ کاؤنٹرز سے بدل دیا: accepted, rejected, empty response, اور no answer۔
تیسرا قدم فیصلہ کن ثابت ہوا۔ ایک واحد نمبر کے بجائے جسے کسی بھی طرح سے پڑھا جا سکتا تھا، یہ چار حصوں میں تقسیم شدہ ڈیٹا دکھاتا ہے کہ آیا سیفٹی گیٹ فعال ہے، آیا ماڈل جواب دے رہا ہے، یا آیا درخواست ماڈل تک پہنچی ہی نہیں۔
توازن اور جوابی دلائل
آگے کیا دیکھنا چاہیے
AI اجزاء لانچ کرنے والے ڈویلپرز کو کسی بھی ایسے مجموعی کاؤنٹرز (aggregated counters) کا آڈٹ کرنا چاہیے جو سیفٹی چیکس کو سسٹم لیول کی ناکامیوں کے ساتھ ملا دیتے ہیں۔ ہر درخواست کے راستے کا ایک تفصیلی ہسٹری لاگ بنانا—ماڈل لوڈ کا آغاز، گیٹ کا جائزہ، حتمی نتیجہ—وہ فارنزک ڈیٹا فراہم کرتا ہے جو چھپی ہوئی پریشانیوں کو پکڑنے کے لیے ضروری ہے۔
حاصلِ کلام: ایک واحد "gate-rejection" میٹرک ایک بند AI سروس کو چھپا سکتا ہے؛ اس میٹرک کو اس کے بنیادی واقعات میں تقسیم کرنے سے حقیقت سامنے آتی ہے اور ایسے سسٹم پر غلط اعتماد سے بچا جا سکتا ہے جو حقیقت میں کام نہیں کر رہا ہوتا۔