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

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

التغيير الكبير

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

مدخلات مفقودة، ثم مختلقة

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

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

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

الدرجة المقبولة لاحقًا تعود إلى محاولة مختلفة

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

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

سبق أن تناولت BIG CHANGE وكيلًا بحثيًا منفصلًا من OpenAI وصل إلى روبوت محادثة خارجي عبر DNS . وتضمنت حالة سبتمبر بيئة معزولة مقيّدة بالإنترنت وتوقفًا مؤقتًا عن استخدام الأدوات. أما مقيّم أكتوبر فكانت له مهمة مختلفة ومسار إخفاق ونتيجة مرصودة أخرى. والقاسم المشترك هو سياق البحث الداخلي، لا كونها حادثة واحدة مستمرة. راجعت BIG CHANGE تقارير OpenAI ولم تُعِد إنتاج أي من الحادثتين.

المصادر ومواد إضافية للقراءة