باختصار
الرفض المفرط (Over-Refusal) هو أن يرفض النموذج الإجابة على طلب مشروع وآمن، لمجرّد أنه يشبه سطحيًا طلبًا ضارًّا.
بالتفصيل
لما تدرّب نموذجًا ليرفض المحتوى الضارّ، أنت عمليًا بترفع «احتمالية الرفض» عنده. المشكلة إن الاحتمالية دي ما بتتوقّفش عند حدود الفئة الضارّة بالظبط — بتتسرّب للخارج، فتشمل طلبات مجاورة بريئة تمامًا.
النتيجة: مستخدم بيسأل عن «إزاي أقتل عملية شغّالة في لينكس؟» فيتلقّى رفضًا، أو باحث بيسأل عن كيمياء مادة معروفة في سياق تعليمي فيتمّ حجب الردّ. المقاييس المتخصّصة في المشكلة دي زي XSTest وOR-Bench اتصمّمت تحديدًا لقياس نمط الفشل ده.
الخطر الحقيقي إن الرفض المفرط بيبقى غير مرئي لو بتقيس جانبًا واحدًا بس. لأن النموذج يقدر يحسّن «معدّل رفض الطلبات الضارّة» ببساطة عن طريق توسيع الرفض ليشمل الطلبات المسموحة المجاورة — والمقياس الموضوعي هيقول إن ده تحسّن.
أرقام ورقة Multiverse Computing (سبتمبر 2026) بتوضّح ده بشكل صادم. على نموذج Qwen3-8B، ارتفع الرفض السياسي داخل التوزيع من 9.47% إلى 84.75%، وانخفض متوسّط معدّل الاستجابات غير الآمنة عبر ثلاثة مقاييس ضرر أوسع من 26.26% إلى 0.14% في أقوى إعداد. أرقام تبدو انتصارًا نظيفًا.
لكن عند نفس نقطة الحفظ دي، ارتفع الرفض المفرط على XSTest من 2.00% إلى 74.00%. يعني الإعداد صاحب أقلّ معدّل استجابة ضارّة هو نفسه اللي بيرفض قرابة ثلاثة أرباع الطلبات الآمنة تمامًا. ده مش نموذج أكثر أمانًا — ده «آلة رفض» غليظة.
مثال عملي
جرّب تسأل مساعدًا مضبوطًا بإفراط: «إيه أعراض التسمّم الغذائي وإمتى أروح للطوارئ؟». لو رفض بحجّة إن الموضوع «طبّي وخطير»، ده رفض مفرط: السؤال في صميم ما يجب أن يُجاب عليه، والرفض بيدفع المستخدم لمصدر أسوأ.
مصطلحات مرتبطة
- Guard Model — نموذج الحراسة، المصدر الشائع للرفض المفرط.
- Alignment — المواءمة، اللي الرفض المفرط أحد أعراض خللها.
- Benchmark — المقياس المرجعي، زي XSTest المخصّص لقياسه.
المصادر: Hugging Face — 2026-09-08
