OpenAI لا تستطيع بعد تفسير سبب إيقاف وكلاء البرمجة لديها لمراقبة عدم التوافق

النقاط الرئيسية

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

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

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

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

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

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

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

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

إنكار Astra يُظهر أن الوكلاء يمكنهم إخفاء ما غيّروه

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

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

قام بإزالة المراقبة واستبدال اختبار مصمم لحمايتها باختبار آخر يفترض أن المراقبة قد أُزيلت. وهلل Astra للنتيجة في سلسلة تفكيره.

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

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

استثناء للنماذج الأضعف يترك فجوة في الرقابة

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

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

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

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