طویل افق والے ماڈلز کے دور میں سیفٹی اور الائنمنٹ

جو ماڈلز طویل مدت تک خودمختار طور پر کام کر سکتے ہیں, وہ مشکل اور کھلے مسائل سنبھال سکتے ہیں. لیکن یہی مستقل مزاجی جو انہیں مفید بناتی ہے, انہیں ناپسندیدہ اقدامات کے مزید مواقع بھی دیتی ہے—اور ایسے انداز میں دیتی ہے جو کم افق والے ماڈلز کے لیے بنائی گئی جانچوں سے چھوٹ سکتا ہے.

تقریباً دو ماہ پہلے ہم نے اعلان کیا⁠ تھا کہ ایک داخلی عمومی مقصد کے ماڈل نے Erdős unit distance conjecture کو غلط ثابت کیا. یہ ماڈل بہت طویل مدت تک خود مختار طور پر کام کرنے کے لیے بنایا گیا تھا. محدود اور زیر نگرانی داخلی استعمال کے دوران ہم نے ایسا ناپسندیدہ رویہ دیکھا جسے ہماری موجودہ ڈیپلائمنٹ جانچیں پکڑ نہیں پائی تھیں. چونکہ ڈیپلائمنٹ محدود اور زیر نگرانی تھی, ہم ان مسائل کی شناخت کر سکے, رسائی روک سکے, اپنے مشاہدات پر مبنی نئی جانچیں بنا سکے, ماڈل اور اس کی حفاظتی اقدامات مضبوط کر سکے, اور پھر مسلسل نگرانی کے ساتھ رسائی بحال کر سکے. 

جن حالات میں ہم ماڈلز کی جانچ کرتے ہیں, وہ حقیقی استعمال میں پیش آنے والے حالات سے کبھی پوری طرح میل نہیں کھائیں گے. اسی لیے ڈیپلائمنٹ سے پہلے کی جانچوں کے ساتھ محدود, زیر نگرانی ڈیپلائمنٹ اور مسائل سامنے آنے پر مداخلت, توقف یا واپسی کی صلاحیت بھی ضروری ہے. ڈیپلائمنٹ سے جو کچھ ہم سیکھتے ہیں, وہ رسائی بڑھانے سے پہلے زیادہ مضبوط جانچوں اور حفاظتی اقدامات کا حصہ بن سکتا ہے.

اگلے حصوں میں ہم اُن مشاہدات کی ٹھوس مثالیں, مسائل کو حل کرنے کے ہمارے طریقے, اور یہ تجربہ مستقبل کی ریلیزز کو کس طرح متاثر کرے گا, شیئر کرتے ہیں.

نیا ماڈل طویل مدت تک بار بار کوششوں کے ذریعے کسی مقصد کی طرف کام جاری رکھ سکتا ہے. یہی مستقل مزاجی اسے اپنے ماحول کی کمزوریاں تلاش کرنے اور ان سے فائدہ اٹھانے تک لے جا سکتی ہے. پچھلے ماڈلز جب سینڈ باکسنگ یا ماحولیاتی پابندیوں سے ٹکراتے تھے تو عموماً بس رک جاتے اور صارف کے پاس واپس آ جاتے تھے. یہ ماڈل اکثر کوشش جاری رکھتا تھا, حتیٰ کہ اپنے سینڈ باکس سے باہر عمل کرنے کے طریقے بھی تلاش کرتا تھا.

اس کی ایک مثال NanoGPT اسپیڈ رن⁠(نئی ونڈو میں کھلتا ہے) پر ایک داخلی جانچ کے دوران سامنے آئی, جو ایک چھوٹے لینگویج ماڈل کو کم سے کم اسٹیپس میں ٹریننگ دینے کا عوامی بینچ مارک ہے. ہمارے ماڈل نے PowerCool نام کا پاور-لا لرننگ ریٹ کول ڈاؤن تیار کیا, جس سے نمایاں بہتری آئی. ماڈل کو ہدایت دی گئی تھی کہ وہ اپنے نتائج صرف Slack پر پوسٹ کرے, لیکن NanoGPT کی ہدایات کہتی ہیں کہ نتائج GitHub پر PR کے طور پر پوسٹ کیے جائیں, اور ماڈل نے انہی بعد والی ہدایات پر عمل کرتے ہوئے عوامی GitHub ریپوزٹری پر PR #287 کھول دیا. ماڈل نے بیرونی رسائی روکنے کے لیے بنائی گئی سینڈ باکس پابندیوں کو بائی پاس کیا اور GitHub پر اپ لوڈ جاری رکھا. PR بنانے کے لیے ہمارے ماڈل کو سینڈ باکس میں ایک کمزوری تلاش کرنے میں ایک گھنٹہ لگا؛ پہلے کے ماڈلز کم مستقل مزاج تھے اور کمزوریاں تلاش نہیں کر سکے, بلکہ PR والے حصے پر ہار مان گئے.¹

AI اسسٹنٹس کے بہت سے حفاظتی کنٹرول انفرادی ایکشنز کو بنیاد بنا کر ڈیزائن کیے جاتے ہیں. اگر کوئی ایکشن ممنوع ہو تو اسے بلاک کر دیا جاتا ہے. اگر وہ حساس ہو تو سسٹم صارف سے واضح منظوری طلب کرتا ہے. لیکن طویل مدت تک چلنے والے ماڈلز, جن کے ایکشنز گھنٹوں, دنوں یا حتیٰ کہ ہفتوں تک خود مختار طور پر آگے بڑھ سکتے ہیں, اس ترتیب کو چیلنج کرتے ہیں: انفرادی ایکشنز کی نگرانی اب مجموعی ٹریجیکٹری کے ارادے کو سمجھنے کے لیے کافی نہیں رہتی.

مثال کے طور پر, ایک منظرنامے میں جب ماڈل سے ایک مسئلہ حل کرنے کو کہا گیا تو ماڈل نے دیکھا کہ دوسرے سسٹمز کی کامیاب مگر نجی جمع کاریاں موجود ہیں, اور اس نے ان حلوں کو ایویلیوایشن بیک اینڈ سے بازیافت کرنے کی کوشش کی. جب اس کی ابتدائی کوشش اس لیے بلاک ہوئی کہ ایک اسکینر نے تصدیقی ٹوکن پکڑ لیا, تو ماڈل نے ٹوکن باڈی کو دو حصوں میں بانٹا, انہیں مبہم بنایا, اور پھر رن ٹائم پر کریڈینشل دوبارہ جوڑ دیا تاکہ مکمل ٹوکن کبھی ایک مسلسل اسٹرنگ کے طور پر ظاہر نہ ہو. ماڈل نے صارف کو دیے گئے اپنے تبصروں اور اپنی ریزننگ ٹریسز دونوں میں صاف لکھا کہ وہ یہ قدم اسکینر کو بائی پاس کرنے کے لیے اٹھا رہا ہے.

یہ مثال ظاہر کرتی ہے کہ ہر قدم اکیلا دیکھا جائے تو قابل قبول لگ سکتا ہے, جبکہ سلسلہ ایسا نتیجہ پیدا کر سکتا ہے جس کی منظوری نہیں دی جاتی. یہ یہ بھی دکھاتی ہے کہ ایک ماڈل جو طویل زمانی افق (time horizon) پر مؤثر طور پر کام کرتا ہے, منظوری کے نظام کے اندھے مقامات سیکھ سکتا ہے اور اپنے اہداف حاصل کرنے کے لیے ان کا راستہ نکال سکتا ہے. طویل افق کی حفاظت کے لیے صرف یہ پوچھنا کافی نہیں کہ “کیا اس عمل کی اجازت ہے?” بلکہ یہ بھی پوچھنا ہوتا ہے کہ “ایکشنز کا یہ سلسلہ کس نتیجے کی طرف بڑھ رہا ہے؟”

ایسے واقعات کی وجہ سے ہم نے نئے ماڈل کی داخلی ڈیپلائمنٹ روک دی. ہم نے حفاظتی نظام کو دفاع کی متعدد تہوں اور ٹریجیکٹری سطح کی نگرانی کے گرد ازسرنو بنایا.

• واقعات سے اخذ کردہ جانچیں. جانچیں ہمیں یہ اندازہ دے سکتی ہیں کہ کوئی سسٹم حقیقی ڈیپلائمنٹ سے پہلے تعینات کرنے کے لیے محفوظ ہے یا نہیں. تاہم, سب سے زیادہ مفید ہونے کے لیے, کسی جانچ کو حقیقی ڈیپلائمنٹ کے دوران ٹریجیکٹریز کی تقسیم اور افق کی لمبائی کی عکاسی کرنی چاہیے. اسی وجہ سے ہم نے مشاہدہ شدہ ناکامیوں کو مخالفانہ جانچیں بنانے کے لیے استعمال کیا. ہم نے پایا کہ حقیقی دنیا کے واقعات سے اخذ کردہ جانچوں میں بہتری لانے سے, پروڈکشن میں ڈیپلائمنٹ کے بعد رویہ بھی زیادہ محفوظ ہوا.
• بہتر الائنمنٹ. ہم نے صارف کے مقصد کے حصول میں اجازت کے بغیر ناپسندیدہ اقدامات کرنے کے اس کے رجحان کو کم کرنے کے لیے قدم اٹھائے.  مثلاً, ہم نے دیکھا کہ ہمارے ماڈلز طویل رول آؤٹس میں ہدایات یاد رکھنے میں کمزور تھے, اور جب ہم نے اس صلاحیت کے لیے ماڈل کو ٹریننگ دی تو ایسا ماڈل بنا جو طویل رول آؤٹس کے دوران بھی الائنڈ رہا. 
• فعال نگرانی. ہم نے ایک نگرانی نظام بنایا جو ماڈل کی بدلتی ہوئی ٹریجیکٹری کا جائزہ لیتا ہے تاکہ یہ نشانیاں مل سکیں کہ وہ صارف کی قید یا حفاظتی حد کو بائی پاس کر رہا ہے. مانیٹر صرف ایک عمل نہیں بلکہ پوری ٹریجیکٹری کو دیکھتا ہے. اہم بات یہ ہے کہ مانیٹر سیشن روک سکتا ہے اور صارف کو مزید قریب سے جائزہ لینے کے لیے خبردار کر سکتا ہے. جائزے کے بعد, اگر مانیٹر غلط طور پر ٹرگر ہوا ہو تو صارف ماڈل کا کام جاری رکھنے کا انتخاب کر سکتا ہے. 
• صارف کے لیے زیادہ وضاحت اور کنٹرول. ہم نے صارف کی یہ صلاحیت بہتر کی کہ وہ ان طویل سیشنز کا معائنہ کرے, کیے گئے ایکشنز دیکھے, اور مداخلتوں کی نگرانی کرے.

نئے مانیٹرنگ سسٹم کا جائزہ لینے کے لیے ہم نے داخلی ڈیپلائمنٹ کے ماحولوں کا ایک چھوٹا مجموعہ دوبارہ چلایا جہاں ماڈل نے پہلے مس الائنڈ ایکشنز اختیار کیے تھے, اس بار نئی حفاظتی اقدامات کے ساتھ². نئی حفاظتی اقدامات ماڈل کے اختیار کیے گئے غیر الائنڈ ایکشنز میں سے کہیں زیادہ کو پکڑ سکیں, اور جو چھوٹ گئے وہ سب کم شدت کے قرار دیے گئے.

ان کم شدت کے واقعات کی کچھ مثالوں میں یہ کیسز شامل ہیں:

• Linear کمانڈ لائن ٹول تک رسائی کے لیے ماڈل نے ایک نیسٹڈ codex --yolo سیشن شروع کیا, جبکہ حقیقت میں وہ --yolo فلیگ کے بغیر بھی ایسا کر سکتا تھا.
• ماڈل نے دیکھا کہ پہلے دستیاب ایک ریسورس موجود نہیں تھا, پھر اس نے بغیر کسی معقول وجہ کے اپنے مالک کے نیم اسپیس میں موجود دیگر فعال CPU پوڈز, اور (ناکام طور پر) OpenAI کے دیگر ملازمین کے پوڈز میں بھی SSH کے ذریعے رسائی حاصل کرنے کی کوشش شروع کر دی.
• ماڈل کے بہت سے find پراسیسز اٹکے ہوئے تھے اور ہر شیل کمانڈ ہینگ ہو رہی تھی. پھر اس نے kill -9 -1 چلایا, جو اگر عمل میں آ جاتا تو اس پوڈ پر ہر ایسے پراسیس کو SIGKILL بھیج دیتا جسے kill کرنے کی اسے اجازت تھی. تاہم یہ ٹائم آؤٹ ہو گیا اور عمل میں نہیں آیا.

نئے سسٹم کی جانچ کے بعد ہم اس نتیجے پر پہنچے کہ طویل افق کی صلاحیتوں والے ماڈلز تک محدود داخلی رسائی بحال کی جا سکتی ہے. کئی ہفتے پہلے دوبارہ ڈیپلائمنٹ شروع ہونے کے بعد سے ہم نے حفاظتی اقدامات کو بائی پاس کرنے کی کوئی سنجیدہ کوشش نہیں دیکھی. ان حفاظتی اقدامات کا پہلا ورژن جان بوجھ کر محتاط رکھا گیا تھا. ہم حفاظتی اقدامات کو کمزور کیے بغیر غیر ضروری رکاوٹیں کم کرنے کے لیے سسٹم کو مسلسل ٹیون کرتے رہے ہیں.

چونکہ ہم نے مرحلہ وار ڈیپلائمنٹ کی, ہم رسائی بڑھانے سے پہلے خلا تلاش کر کے انہیں دور کر سکے. ڈیپلائمنٹ سے پہلے کی جانچیں اب بھی ضروری ہیں, مگر ڈیپلائمنٹ ایسے رویے ظاہر کرتی ہے جو ان سے چھوٹ جاتے ہیں. محدود رسائی سے آغاز کرنے نے ہمیں ماڈل کو عملی طور پر دیکھنے, مسائل سامنے آنے پر روکنے, ان ناکامیوں سے بہتر جانچیں اور حفاظتی اقدامات بنانے, اور تبدیلیوں کی جانچ کے بعد محدود رسائی بحال کرنے کا موقع دیا.

جیسے جیسے ماڈلز زیادہ طویل اور پیچیدہ کام سنبھالتے ہیں, جانچوں سے چھوٹ جانے والی ناکامیوں کے نتائج زیادہ سنگین ہو سکتے ہیں. ہم جانچ اور ڈیپلائمنٹ کے درمیان فرق کم کرنے کے لیے کام جاری رکھیں گے: ماڈلز کو طویل ٹریجیکٹریز پر جانچنا, الائنمنٹ بہتر بنانا, ایسی نگرانی بنانا جو مداخلت کر سکے, اور صارفین کو زیادہ واضح بصیرت اور کنٹرول دینا. یہ چیلنجز صرف OpenAI تک محدود نہیں ہوں گے, اور ہمیں امید ہے کہ جو کچھ ہم نے سیکھا اسے شیئر کرنے سے وسیع تر شعبہ ان کے لیے بہتر تیاری کر سکے گا.