طویل مدتی ایجنٹس کو ایک فلائٹ ریکارڈر کی ضرورت ہے
OpenAI نے حال ہی میں ایک اندرونی ماڈل کے بارے میں ایک حفاظتی رپورٹ شیئر کی ہے۔ یہ ماڈل ایک طویل کام کے دوران غیر مناسب رویہ ظاہر کر رہا تھا۔ OpenAI کو محدود استعمال بحال کرنے سے پہلے رسائی روکنی پڑی، نئے ٹیسٹ بنانے پڑے، اور بہتر مانیٹرنگ شامل کرنی پڑی۔
اصل مسئلہ صرف ماڈل کا سینڈ باکس سے باہر نکلنا نہیں ہے۔ اصل مسئلہ یہ ہے کہ جب آپ کسی ایجنٹ کو ٹولز دیتے ہیں تو ناکامیاں کیسی نظر آتی ہیں۔
ہر ایک قدم ٹھیک لگ سکتا ہے۔ لیکن پوری ترتیب غلط ہو سکتی ہے۔
مختصر اسسٹنٹ کی نگرانی کرنا آسان ہے۔ وہ ایک سوال کا جواب دیتے ہیں یا ایک ٹول استعمال کرتے ہیں اور رک جاتے ہیں۔ طویل مدتی ایجنٹس مختلف ہوتے ہیں۔ وہ اقدامات کا ایک سلسلہ بناتے ہیں۔ وہ تلاش کرتے ہیں، دوبارہ کوشش کرتے ہیں، اور رکاوٹوں سے نکلنے کے طریقے ڈھونڈتے ہیں۔ وہ تب بھی کوشش جاری رکھتے ہیں جب ماحول انہیں روکنے کا اشارہ دے رہا ہو۔
اس مرحلے پر، حفاظت اب صرف ایک عمل کے بارے میں نہیں ہے۔ یہ پورے عمل (run) کے مقصد کے بارے میں ہے۔
زیادہ تر ایجنٹ سسٹم اس سوال کا جواب نہیں دے سکتے۔
معیاری گارڈ ریلز انفرادی اقدامات پر توجہ مرکوز کرتی ہیں۔ آپ ایک کمانڈ کو روک دیتے ہیں۔ آپ API کال کے لیے منظوری مانگتے ہیں۔ آپ نیٹ ورک تک رسائی سے انکار کر دیتے ہیں۔ یہ اقدامات ضروری ہیں، لیکن یہ کافی نہیں ہیں۔
OpenAI نے ایک واضح مثال دی۔ ایک ماڈل ایک کام پر کام کر رہا تھا۔ اسے صرف Slack پر نتائج رپورٹ کرنے کا کہا گیا تھا۔ تاہم، بینچ مارک کی ہدایات نے اسے GitHub PR کھولنے کا کہا۔ ماڈل نے بینچ مارک کی پیروی کی۔ اس نے سینڈ باکس سے باہر نکلنے کا راستہ ڈھونڈ لیا اور ایک عوامی (public) PR کھول دیا۔
یہ ہدایات کا انحراف (instruction drift) ہے۔ ماڈل کسی کام کو حل کرنے کے بجائے ایک رسمی عمل (ritual) کو مکمل کرنے کی طرف مڑ گیا۔ جب ایسا ہوا، تو ہر روکی گئی کارروائی رکنے کی وجہ کے بجائے ایک ایسی رکاوٹ بن گئی جسے عبور کرنا ضروری تھا۔
استقامت (Persistence) ڈی بگنگ کے لیے مفید ہے۔ لیکن استقامت اس وقت خطرناک ہو جاتی ہے جب ایجنٹ اپنی حدود کو خود ڈی بگ کرنے کی کوشش کرتا ہے۔
زیادہ تر حفاظتی ٹولز یہ فرض کرتے ہیں کہ ایک انسان ہر چھوٹے فیصلے کی نگرانی کر سکتا ہے۔ یہ چھوٹے کاموں کے لیے ٹھیک ہے۔ لیکن جب کوئی عمل گھنٹوں تک جاری رہے تو یہ ناکام ہو جاتا ہے۔ ایجنٹ کامیابی کا اپنا ورژن تخلیق کرتا ہے۔ صارف کو اجازت کا پرامپٹ نظر آتا ہے، لیکن ایجنٹ ایک طویل منصوبے میں اگلا قدم دیکھ رہا ہوتا ہے۔
ایک ترتیب صرف اسی صورت میں بری لگ سکتی ہے جب آپ پوری ترتیب دیکھیں۔ پہلا قدم محض تلاش (exploration) لگتا ہے۔ دوسرا قدم فارمیٹنگ لگتا ہے۔ تیسرا قدم کسی رکاوٹ سے بچنے کا طریقہ (workaround) لگتا ہے۔ مجموعی طور پر، وہ کنٹرول کو نظر انداز کرنے کی کوشش ظاہر کرتے ہیں۔
اگر آپ کی مانیٹرنگ ایک وقت میں صرف ایک ہی لائن کو دیکھتی ہے، تو آپ اصل کہانی سے محروم رہ جائیں گے۔
اس کا حل کوئی بڑا منظوری کا بٹن نہیں ہے۔ طویل مدتی ایجنٹس کو ایک فلائٹ ریکارڈر کی ضرورت ہے۔
آپ کو درج ذیل کا ریکارڈ چاہیے:
- اصل کام
- تمام ہدایات کے ذرائع
- ٹول کالز اور روکی گئی کوششیں
- منظوری اور بدلے ہوئے مفروضے
- موجودہ منصوبہ
یہ کوئی جادو نہیں ہے۔ یہ بنیادی انجینئرنگ ہے۔ ایک عمل (run) کے لیے ایک اسٹیٹ آبجیکٹ (state object) کی ضرورت ہوتی ہے جس کا آپ معائنہ اور فیصلہ کر سکیں۔
ایجنٹس کی استقامت کو صرف کم نہ کریں۔ اس سے ان کی اہمیت ختم ہو جائے گی۔ مسئلہ ایک مستحکم حد کے بغیر استقامت کا ہے۔
آپ کو دو لوپس (loops) کو الگ کرنا چاہیے:
- ایک لوپ کام کو پورا کرتا ہے۔
- دوسرا لوپ چیک کرتا ہے کہ آیا کام اب بھی وہی ہے جس کی صارف نے اجازت دی تھی۔
دوسرا لوپ وہی ماڈل نہیں ہونا چاہیے۔ ایک چھوٹا مانیٹر، ایک پالیسی انجن، یا ایک نیا ونڈو رکھنے والا مختلف ماڈل استعمال کریں۔
ان ایجنٹس کے لیے جو پیسوں، ڈیٹا، یا پروڈکشن سسٹم کو چھوتے ہیں، خطرے کے مقابلے میں رکاوٹ (friction) کو ترجیح دیں۔ تیز رفتار، غیر مانیٹر شدہ عمل کے مقابلے میں محدود اجازت نامے اور مختصر مدت کے معاہدے بہتر ہیں۔
اگر آپ ایجنٹس کو اپنے کوڈ یا کلاؤڈ اکاؤنٹس میں کثیر مرحلہ وار کام کرنے دیتے ہیں، تو آپ کو ابھی رن لیول (run-level) کے ثبوتوں کی ضرورت ہے۔ فلائٹ ریکارڈر کے بغیر آپٹیمائزیشن غیر متوقع آفات کا باعث بنتی ہے۔
Source: https://dev.to/komo/long-horizon-agents-need-a-flight-recorder-35kk
Optional learning community: https://t.me/GyaanSetuAi