تطرح ورقة بعنوان The Fragility of Jailbreak Robustness Across Operational States، قُبلت في EMNLP 2026 Findings، ادعاءً ضيقًا ومزعجًا: إن درجة متانة النموذج خاصية للتكوين الذي قيس فيه، لا للنموذج نفسه. ومع إبقاء الهجوم ثابتًا وتغيير مجرد system prompt اعتيادي — لا علاقة له بالأمان — ارتفع معدل نجاح الهجوم في إحدى الحالات من 2% إلى 58%، أي بفارق 56 نقطة. وتمتد النتيجة عبر سبعة نماذج متوافقة وثلاثة هجمات تمثيلية.
الآلية المقترحة
يربط المؤلفون هذا الأثر بموضع التمثيلات الخفية على ما يسمونه refusal axis. ويُتنبأ من خلال إسقاط على هذا المحور بما إذا كان jailbreak معين سينجح — وهو ما يعيد تأطير system prompt تشغيلي بوصفه شيئًا يدفع النموذج بهدوء على طول اتجاه ذي صلة بالأمان، من دون أي قصد عدائي من جانب من كتبه.
ما لا تقوله الورقة
هي لا تزعم أن النماذج أصبحت أقل أمانًا، وأي عنوان من نوع "النماذج يسهل عمل jailbreak لها" يعكس الحجة. فالنتيجة تتعلق بالقياس: الإبلاغ عن المتانة على أنها رقم ASR واحد في إعداد vanilla يولد ثقة زائفة، لأن الرقم لا يصمد عند الاصطدام بـ system prompt تشغيلي. وهذا نقد لمنهجية تُستخدم عبر بطاقات الأمان لدى الشركات والمعايير العامة، لا هجوم جديد.
تفصيلان ينبغي عدم الخلط بينهما
القبول كان في Findings، لا في المسار الرئيسي لـ EMNLP — وهو تمييز غالبًا ما تسقطه الملخصات الصحفية. كما أن تاريخ arXiv يشير إلى تقديم نسخة محددة: هذه هي v1، المقدمة في 31 أغسطس، من دون مراجعة لاحقة، لذا فالأمر ليس عملًا أقدم عاد للظهور تحت تاريخ إدراج جديد.
لماذا ينبغي أن يهتم الممارسون
في النشر، يكتب system prompt جهة الدمج، لا المختبر. وإذا كانت المتانة المقاسة باستخدام prompt المختبر الافتراضي لا تنتقل، فإن كل رقم أمان يُعرض على المشتري يصف تكوينًا لن يوجد في منتجه. والدلالة العملية هي أن red-teaming يجب أن يُجرى على prompt الإنتاج الفعلي، وأن يُعاد كلما تغير ذلك prompt — وهو ما يُعامل اليوم بوصفه تعديلًا اعتياديًا في النص.