AI Autopilot کا جم جانا: ٹائم اسٹیمپ (Timestamps) پر بھروسہ کرنے کا خطرہ
ہمارے AI ایجنٹس 24/7 کام کرتے ہیں۔
وہ ضروریات کو ٹاسکس (tasks) میں تبدیل کرتے ہیں۔ وہ کوڈ لکھتے ہیں۔ وہ پل ریکویسٹ (pull requests) کھولتے ہیں۔ ایک AI ریویو کرنے والا کام کی منظوری دیتا ہے۔ پھر، سسٹم خود بخود کوڈ کو مرج (merge) کر دیتا ہے۔
ایک صبح، ہم نے دیکھا کہ تین دنوں سے کوئی بھی ٹاسک مکمل نہیں ہوا تھا۔
سسٹم بالکل ٹھیک نظر آ رہا تھا۔ ہر جز (component) کی صورتحال (status) سبز (green) دکھائی دے رہی تھی۔ پلانز بن رہے تھے۔ ایجنٹس کام کر رہے تھے۔ ریویو کرنے والا منظوری دے رہا تھا۔ صرف ایک چیز کی کمی تھی، اور وہ تھی مرج (merge)۔
اس کی وجہ ایک "فریشنس چیک" (freshness check) تھی جو ہم نے خود بنایا تھا۔
ہم ایک مخصوص غلطی سے بچنا چاہتے تھے۔ ہم نہیں چاہتے تھے کہ کوڈ اس وقت مرج ہو جائے جب کسی ریویو کرنے والے نے اسے منظور کیا ہو اور پھر بعد میں تبدیلیوں کا مطالبہ کیا ہو۔ اس مسئلے کو حل کرنے کے لیے، ہم نے سسٹم کو بتایا: "صرف ان ریویوز پر بھروسہ کریں جو ہمارے انتظار شروع کرنے کے بعد ہوئے ہوں۔"
یہ منطق (logic) سسٹم کی بحالی (recovery) کے دوران ناکام ہو گئی۔
اگر سسٹم ری اسٹارٹ ہوتا یا کسی ٹاسک کو نئے سرور پر منتقل کرتا، تو یہ "انتظار شروع کرنے" (start waiting) کے ٹائم اسٹیمپ کو موجودہ وقت پر ری سیٹ کر دیتا تھا۔
اگر کسی ریویو کرنے والے نے صبح 10:00 بجے کوڈ کی منظوری دی، لیکن سسٹم صبح 10:30 بجے ری اسٹارٹ ہوا، تو سسٹم صبح 10:00 بجے کی منظوری کو نظر انداز کر دیتا۔ اسے لگتا کہ منظوری بہت پرانی ہو چکی ہے۔
منظوری GitHub پر اب بھی موجود تھی۔ لیکن ہمارا کوڈ اسے دیکھ نہیں پا رہا تھا۔ سسٹم ایک مستقل ڈیڈ لاک (deadlock) میں پھنس گیا۔
میں نے اس سے تین مشکل سبق سیکھے:
بیرونی حالت (external state) کو ایک اسنیپ شاٹ (snapshot) کے طور پر لیں، نہ کہ ایک واقعے (event) کے طور پر۔ یہ نہ پوچھیں کہ "کیا کچھ نیا ہوا ہے؟" بلکہ یہ پوچھیں کہ "اس وقت موجودہ حالت کیا ہے؟" اگر آپ موجودہ حالت کو دیکھتے ہیں، تو ری اسٹارٹ سے کوئی فرق نہیں پڑتا۔
بحالی (recovery) کے دوران ٹائم اسٹیمپ کو ری سیٹ نہ کریں۔ اگر آپ دوبارہ کوشش (retry) کے دوران "شروع ہونے کا" (started at) وقت ری سیٹ کرتے ہیں، تو آپ اس لمحے سے پہلے ہونے والے تمام حقائق کو مٹا دیتے ہیں۔ ٹائم اسٹیمپ کو صرف اس وقت ری سیٹ کریں جب اصل کام تبدیل ہو۔
اس بات پر نظر رکھیں کہ ٹاسکس کہاں رک رہے ہیں، نہ کہ صرف یہ کہ وہ مکمل ہوئے یا نہیں۔ "مکمل" (done) کی تعداد آپ کو بتاتی ہے کہ آپ کو کوئی مسئلہ ہے، لیکن مرحلہ وار ٹاسکس کی تقسیم (distribution) آپ کو بتاتی ہے کہ مسئلہ کہاں ہے۔ ہمیں مسئلہ اس لیے معلوم ہوا کیونکہ ہم نے دیکھا کہ 28 ٹاسکس "ریویو کا انتظار" (wait for review) والے مرحلے پر پھنسے ہوئے تھے۔
ایک زندہ عمل (live process) جو غلط اصول پر عمل کر رہا ہو، وہ ہیلتھ چیک (health check) میں کبھی ظاہر نہیں ہوگا۔ یہ صحت مند نظر آتا ہے کیونکہ یہ بالکل ویسے ہی کام کر رہا ہے جیسے اسے پروگرام کیا گیا تھا۔
اگر آپ خودکار نظام (automated systems) بناتے ہیں، تو صرف غلطیوں کا انتظار نہ کریں۔ اس بات پر نظر رکھیں کہ آپ کے عمل (processes) کہاں جمع ہو رہے ہیں۔
Optional learning community: https://t.me/GyaanSetuAi