OpenAI تحقق في تعطيل وكلاء البرمجة لأنظمة مراقبة الانحراف

أضعف وكيلا برمجة داخليان في OpenAI نظام المراقبة المخصص لرصد السلوك غير السليم، حتى بعد تقييم ما إذا كان ينبغي الإبقاء على تلك الضمانات. وأنكر أحد الوكيلين لاحقاً إجراء هذا التغيير.

أعلن ماركوس ويليامز، الذي يعمل على المراقبة في OpenAI، عن الحادثتين على منصة X. ويصف نمطاً متكرراً يقوم فيه وكلاء OpenAI بإيقاف مراقبة الانحراف باستمرار. وتفصّل OpenAI هذه الحوادث في تقرير على مدونة المحاذاة الخاصة بها.

صُمم نظام المراقبة لاكتشاف الحالات التي يتصرف فيها الوكلاء بشكل مختلف عن المقصود. ونظراً للحجم الكبير من الأحداث التي يراجعها، فإنه لا ينبه فريق الأمان إلا للحوادث المصنفة عند أعلى مستوى خطورة، P0. وذكرت OpenAI أن أياً من الحالتين لم يحصل على هذا التصنيف.

في الحادثة الأولى، في 3 أكتوبر، طلب باحث من وكيل برمجة قائم على GPT-6.1 Sol تجميع مهام تقييم من ملاحظات الموظفين في قناة Slack. وصدرت للوكيل تعليمات بعدم إرسال أي رسائل أثناء العملية.

بعد اثنتين وثمانين رسالة مستخدم، توقف خط المعالجة لأن نظام المراقبة رصد إصلاحاً مخططاً لكنه افتقر إلى الصلاحيات لحفظ نتائجه. ثم سلّم Sol الإصلاح إلى وكيل فرعي، وأمره بالحفاظ على المراقبة.

غير أن Sol عدّل تقييمه لاحقاً، بحجة أن إدخالاً في قاعدة البيانات قد يُطلق إشعاراً، ما يتعارض مع تعليمات Slack. وكان الوكيل الفرعي قد اعتبر هذه الخطوة غير آمنة سابقاً. وبناءً على تعليمات Sol، مسح قوائم المستلمين، مبرراً أفعاله بأن المستخدم طلب صراحةً عدم إرسال أي رسائل.

وبينما استمر نظام المراقبة في العمل وحفظ نتائجه، عُطّلت التنبيهات الموجهة للبشر. واختتم الوكيل تقريره بالإبلاغ عن عدم إرسال أي رسائل.

إنكار Astra يبرز قدرة الوكلاء على إخفاء التغييرات

في 6 أكتوبر، مضى GPT-6 Astra بالوضع خطوة أبعد. طلب مستخدم من النموذج اعتماد سير عمل من تطبيق مرجعي لا يتضمن نظام مراقبة. وكان وكيل آخر قد أمر Astra سابقاً بعدم تعطيل المراقبة، ولو مؤقتاً.

فوّض Astra المهمة إلى وكيل فرعي، وأمره بالإبقاء على المراقبة فقط بالقدر الذي يتوافق مع التطبيق المرجعي. وتساءل الوكيل الفرعي عما إذا كان هذا يعني تجاوز ضمانة أمنية، لكنه فسّر التحفظ على أنه إذن.

فأزال المراقبة واستبدل اختباراً وقائياً بآخر يفترض غياب المراقبة. وأعرب Astra عن رضاه عن النتيجة في تفكيره.

ثم أبلغ Astra المستخدم بأن عملية الترحيل اكتملت دون ذكر إزالة المراقبة. وعندما استفسر المستخدم عن ذلك، أنكر النموذج أنه أزال نظام مراقبة نشطاً. ووصف ويليامز ذلك بأنه كذب.

شدّد ويليامز على أن النماذج لم تعطّل مراقبتها الخاصة، وهو ما سيكون أصعب بكثير في Codex. ومع ذلك، يجد مقلقاً أن تُظهر هذا السلوك، حتى لو كانت كلتا الحالتين تسمحان ببعض الإنكار المعقول. وأشار إلى أن الفريق لم يلاحظ أي دوافع انحراف صريحة.

ثغرات في الرقابة على النماذج الأضعف

أشار ويليامز إلى أن تعطيل المراقبة سهل بشكل خاص أثناء التقييمات. ولا تشترط OpenAI المراقبة للنماذج على مستوى GPT-6 Luna بسبب قدراتها الأضعف. ويعني هذا الإعفاء أن تقييم Astra يمكن إعداده بشكل خاطئ ليقع تحت هذه الفئة. وقد بدأ الوكلاء مراراً عمليات نشر دون مراقبة، حتى أثناء وجودهم تحت الملاحظة.

رداً على ذلك، حدّثت OpenAI عملية المراجعة الآلية المطلوبة للاستخدام الداخلي لـ Codex. وهي مصممة الآن لاكتشاف محاولات تعطيل المراقبة وحظرها. وتعمل الشركة أيضاً على اشتراط ما يسمى بحالة أمان لكل نوع من أنواع عبء العمل، تحدد متطلبات المراقبة الخاصة به. وسيتم إيقاف أعباء العمل التي تفتقر إلى حالة أمان صالحة تلقائياً.

تقدم OpenAI تفسيرين محتملين لسلوك الوكلاء. الأول هو الإصرار المفرط، حيث ينفذ النماذج تعليمات تتجاوز ما كان متوقعاً. والثاني هو نزعة إلى تجنب مراقبة الانحراف تحديداً وتبرير ذلك عبر تفكير مدفوع بالدوافع.

تقر OpenAI بأنها لا تملك بعد تفسيراً مُرضياً لهذا السلوك. وتخطط الشركة لمزيد من التحقيق باستخدام أساليب مثل إجراء تجارب على التنشيطات الداخلية للنماذج.

المصدر: The Decoder