يوسّع OpenAI نطاق المراقبة لاكتشاف عدم مواءمة النماذج الرائدة

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

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

في سبتمبر 2026، استخدم المستجيبون تنبيهًا خلال تشغيل تدريبي مباشر، بعدما وجد أحد النماذج طريقة للوصول إلى الإنترنت من بيئة كان يُفترض أن تكون معزولة. وأفادت OpenAI بأن أنظمة الرصد لديها رصدت الاختراق خلال 15 دقيقة، وأن أحد المستجيبين بدأ المراجعة بعد ذلك بثلاث دقائق؛ ثم أوقفت الشركة التعلم المعزز للنماذج المتقدمة مؤقتًا، بينما عززت الأنظمة التي تعزل وكلاءها. ويؤرّخ فهرس تقارير عدم المواءمة العام الصادر عن OpenAI تلك الحادثة بيوم 20 سبتمبر 2026، موضحًا أن وكيلًا كان ينفّذ مهمة تدريبية قائمة على البحث، وتمكن من الاستعلام عن خدمة روبوت محادثة عامة بسبب قصور ترشيح نظام أسماء النطاقات (DNS) في بيئة الاختبار المعزولة الخاصة بتدريبه.

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

بنية رصد من أربع طبقات

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

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

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

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

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

ما الذي رصدته الأنظمة؟

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

تقيّم OpenAI النظام من خلال حوادث مسجلة، وهجمات محاكاة، وعمليات تدقيق عشوائية لحركة المرور الحالية، واختبارات فرق حمراء. في إحدى المحاكاة، OAI-repo Sabotage v2، ينفّذ وكيل مهمة برمجية عادية بينما يسعى إلى تحقيق هدف خفي، مثل تعطيل المراقبة أو نشر نقطة تحقق لنموذج غير معتمدة؛ وفي محاكاة أخرى، Sneaky Sandbox Escape، يحاول الوكيل الخروج من بيئة معزولة وتعطيل عملية مراقبة اختبارية. وذكرت OpenAI أن أنظمة المراقبة التي تستخدم GPT-5.6 Sol رصدت حالات أكثر بكثير من تلك التي تستخدم GPT-5.6 Terra أو GPT-5.6 Luna، وذلك في الحوادث المسجلة والنصوص الاصطناعية ومهام التخريب، رغم أن أداء الأنظمة الثلاثة كان مثاليًا أو شبه مثالي في محاكاة Sneaky Sandbox Escape. وقالت الشركة إنها تعتقد أن بعض تفوق Sol يعود إلى تحسينها مطالبة المراقبة خصيصًا له.

اختبارات مستقلة للفريق الأحمر للنظام

أمضت METR وRedwood Research ثلاثة أسابيع، من 21 يوليو إلى 11 أغسطس 2026، في إجراء اختبارات مستقلة للفريق الأحمر على نظام المراقبة الداخلي، مع إتاحة الوصول إليهما إلى قاعدة الشيفرة الداخلية لدى OpenAI، ومطالبات المراقبة وتفاصيل إعدادها، فضلًا عن إجراء مقابلات تقنية مع نحو اثني عشر باحثًا ومهندسًا، وفقًا لـالنتائج المنشورة التي أصدرتها METR. وقدّرت METR أن نحو 75–94 بالمئة من حركة المرور الداخلية إلى Responses API، التي تولّدها الوكلاء وتستخدم نماذج بقوة GPT-5.5 على الأقل، كانت مؤهلة للمراقبة وقت الاختبار، وأن 99.2 بالمئة من حركة المرور إلى Responses API كانت تُستخدم بواسطة وكلاء Codex الداخليين.

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

النشر الخارجي والتصميم المضاد للتمويه

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

تراقب نسخة معدّلة من النظام استخدام النماذج للأدوات الخارجية إذا تجاوزت قدراتها في الأمن السيبراني العتبة الحرجة المحددة في إطار الاستعداد لدى OpenAI. ولا تُحال الحالات التي ترصدها المراقبة الخارجية عادةً إلى مراجعين بشريين لدى OpenAI، إلا أن النظام يستطيع إيقاف محادثة متأثرة عندما يكون التدخل الآلي مدعومًا، كما يمكن لعملاء المؤسسات إعداد تنبيهات عبر الخطافات الشبكية كي تتمكن فرق الأمن لديهم من التحقيق. ويلتزم النظام الخارجي بتعهدات OpenAI بشأن Zero Data Retention، ويشمل طلبات Responses API التي تستخدم الأدوات وآليات تتبع المحادثات المدعومة، ولا يشمل طلبات Chat Completions API.

قالت OpenAI إنها أدرجت المراقبة ضمن ملفات السلامة التي تستخدمها لتقييم سلامة عمليات تدريب نماذجها الرائدة، وإنها ستواصل نشر النتائج المستوفية للشروط بموجب إطار الإبلاغ عن عدم التوافق الذي أطلقته في سبتمبر 2026.