إزالة حالات الرفض من DeepSeek V4.1 Flash: من 81.6% إلى 4.3% عبر 838 مطالبة

تخيل أنك اشتريت خزنة، ثم اكتشفت أن قفلها الرقمي يمكن نزعه بمفك خلال أمسية واحدة. هذه تقريبا هي الصورة التي يرسمها منشور واسع الانتشار على منصة X عن DeepSeek V4.1 Flash. ويقول صاحبه إن شخصا ما أزال معظم حالات الرفض من النموذج باستخدام OBLITERATUS، وهي أداة مجانية ومفتوحة المصدر أصدرها Pliny.

ما الذي يدعيه المنشور تحديدا

لا يتضمن المنشور سوى بضعة معطيات. فبحسب صاحبه، كان النموذج الأصلي يرفض الإجابة عن 81.6% من أصل 838 مطالبة اختبار. وبعد التعديل، انخفضت نسبة الرفض إلى 4.3%. ووُصفت الأداة بأنها مجانية ومفتوحة المصدر، من دون تقديم مزيد من التفاصيل التقنية.

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

لماذا يعد ذلك ممكنا من حيث المبدأ

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

السمة الأساسية لهذا النهج أنه يتطلب الوصول إلى الأوزان، لكنه لا يتطلب إعادة تدريب مكلفة. ولهذا يكون السؤال المعتاد بشأن أي نموذج مفتوح هو: متى ستظهر نسخة بلا حالات رفض، وليس هل ستظهر أصلا.

ما الذي ينبغي للمطورين وفرق المنتجات فعله

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

ثانيا: إذا كنتم تستخدمون نقاط تحقق أعاد آخرون تدريبها من Hugging Face أو منصات مشابهة، فتحققوا من مصدرها. فقد يتصرف نموذج يحمل اسما مشابها بطريقة مختلفة تماما عن النسخة الرسمية. شغلوا مجموعة اختبارات red-team خاصة بكم قبل النشر في بيئة الإنتاج، ولا سيما مع الوكلاء الذين يمكنهم الوصول إلى الأدوات والبيانات.

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

القيود والخلاصة

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

من المرجح ألا تكون قصة DeepSeek V4.1 Flash الأخيرة من نوعها. فكلما ازدادت قوة النموذج المفتوح، ظهرت أدوات إزالة قيوده بوتيرة أسرع، وازدادت أهمية بنية الأمان المحيطة به.