MIT Technology Review تحذّر: الثقة في رفض نماذج الذكاء الاصطناعي مفرطة

في عدد 9 أكتوبر من نشرة The Download، تضع MIT Technology Review في الصدارة طرحًا يعدّه كثيرون في الصناعة من البديهيات: نحن نثق أكثر مما ينبغي في قدرة الذكاء الاصطناعي على قول «لا». فالنماذج الحالية مدرَّبة على رفض عدد هائل من الطلبات. اسأل روبوت دردشة عن كيفية تسميم شخص، ومن المرجّح أن يرفض. وترى المجلة أن الصناعة تعلّق على هذا الرفض آمالًا مفرطة. وتتناول المادة الثانية في النشرة الآثار الجانبية لأدوية إنقاص الوزن، ولا علاقة لها بالذكاء الاصطناعي.

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

كيف تتعلم النماذج قول «لا»

الرفض ليس مدمجًا في LLM منذ البداية. فالنموذج الأساسي يكتفي بمتابعة النص، وبالاستعداد نفسه يصف وصفة فطيرة أو إجراءً خطرًا. أما سلوك «لا أستطيع المساعدة في هذا» فيظهر لاحقًا، في مراحل التدريب الإضافي: يقيّم البشر ونماذج أخرى الإجابات، ويتعلم النظام اختيار تلك التي تُعدّ آمنة. وتُضاف فوق ذلك مطالبات النظام (system prompts) ومرشحات خارجية تفحص الطلب عند الدخول والإجابة عند الخروج.

تبدو النتيجة كأنها حد فاصل، لكنها في الواقع ميل إحصائي. فالنموذج لا «يفهم» أن الطلب خطر، بل يتعرف على أنماط مألوفة من الطلبات الخطرة.

أين ينكسر الرفض

لهذا النوع من الحماية ثلاث نقاط ضعف معروفة.

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

وتظهر مشكلة منفصلة لدى الوكلاء (agents). فحين يملك النموذج صلاحية الوصول إلى المتصفح والبريد والشيفرة وأدوات الدفع، لا يضمن الرفض المهذب في الدردشة شيئًا. إذ يمكن تركيب إجراء خطر من سلسلة خطوات تبدو كل واحدة منها بريئة إذا نُظر إليها منفردة.

مم تتكوّن الحماية عمليًا

إذا لم نعتمد على الرفض بوصفه حاجزًا وحيدًا، فإن الصورة تصبح متعددة الطبقات:

• التدريب على أمثلة الرفض وعلى تفضيلات البشر؛
• تعليمات النظام من المشغّل، مع وصف ما يجوز وما لا يجوز؛
• مصنّفات (classifiers) منفصلة عند الدخول والخروج، مستقلة عن النموذج الرئيسي؛
• red teaming: محاولات اختراق مقصودة قبل الإصدار وبعده؛
• تقييد صلاحيات الوكيل على مستوى البنية التحتية، لا على مستوى المطالبة (prompt).

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

ماذا ينبغي أن تفعل الفرق التي تعتمد النماذج

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

ثانيًا: اختبروا سيناريوهاتكم الخاصة، لا المعايير العامة (benchmarks) فقط. فقد تبدو الطلبات الخطرة في مجالكم مختلفة تمامًا عمّا هي عليه في المجموعات العامة.

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

رابعًا: قيسوا الخطأ في الاتجاهين. فنسبة الطلبات الخطرة التي جرى تمريرها ونسبة حالات الرفض الخاطئ في المهام المشروعة تكشفان عن جودة النظام أكثر من أي مؤشر منفرد.