OpenAI تطلق Control Room: «قاطع طوارئ» لمهام الذكاء الاصطناعي يعمل خلال 35 ثانية

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

كيف يعمل قاطع الطوارئ

يُسمى النظام Control Room. وهو خدمة مركزية تربط بين ثلاثة أجزاء: المهمة البحثية (تجربة تعلّم معزز، أو تقييم نموذج، أو معالجة جماعية للبيانات)، ومحرك الاستدلال الذي يشغّل النماذج على وحدات GPU، وControl Room نفسه. ويُشترط إضافةً إلى ذلك لكل مهمة تتضمن نماذج وكيلية وجود مسوّغ أمان معتمد.

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

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

ولهذا النهج خاصيتان مهمتان. أولًا، لا يعتمد الأمان على انضباط الباحثين: فالفحص تجريه البنية التحتية لا كود مهمة بعينها. ثانيًا، نمط fail-closed: إذا كان Control Room نفسه غير متاح، فلا تُنفَّذ طلبات الاستدلال. فخسارة جزء من التجارب أفضل من البقاء بلا مكابح.

لماذا 35 ثانية، وما دور المراقب

أقصى تأخير بين الأمر والإيقاف الفعلي هو 35 ثانية. والسبب عملي: لا بد من طبقة تخزين مؤقت (cache)، وبدونها لن تتحمل الخدمة تدفق طلبات التفويض. وتقول OpenAI إنها تعمل على خفض هذه المدة إلى الصفر.

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

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

ما الذي يمكن الاستفادة منه

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

استنتاجات عملية للفرق التي تشغّل وكلاء:

ضعوا الرقابة في نقطة لا يستطيع الوكيل الالتفاف عليها، أي في البوابة المؤدية إلى النموذج، لا في كود الوكيل نفسه.

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

اختاروا fail-closed: عند فشل الرقابة يكون التوقف أكثر أمانًا من المتابعة بشكل أعمى.

احسبوا مسبقًا زمن الإلغاء. فالتخزين المؤقت يخفف الحمل عن الخدمة لكنه يطيل النافذة التي لا تزال فيها المهمة الموقوفة تتلقى ردودًا.

أضيفوا مراقبًا مستقلًا يستطيع الضغط على قاطع الطوارئ بنفسه، لا أن يكتفي بكتابة التنبيهات في السجل.

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