لقد بنيتُ ماسحًا أمنيًا للذكاء الاصطناعي — ثم اكتشفتُ خطأً في أداة الكشف الخاصة بي

يُعد "حقن الأوامر" (Prompt injection) أحد أكبر المخاطر الأمنية لتطبيقات النماذج اللغوية الكبيرة (LLM). فأنت تغذي النموذج بنص يطلب منه تجاهل تعليماته الأصلية، وأحيانًا، يستجيب النموذج لذلك.

لقد قمت ببناء AgentProbe لاختبار ذلك. يقوم البرنامج بإطلاق 49 أمر هجوم عبر 8 فئات، مثل عمليات كسر الحماية (jailbreaks) واستخراج البيانات. ويقوم بالتبليغ عن عدد المرات التي يفشل فيها النموذج.

لم يكن الدرس الحقيقي في الماسح نفسه، بل كان في خطأ برمجي (bug) في كود الكشف الخاص بي.

الجزء الصعب ليس الهجوم، بل الجزء الصعب هو الكشف.

كيف تعرف ما إذا كان النموذج قد استجاب للهجوم بالفعل؟ مطابقة الكلمات المفتاحية هي الطريقة السهلة؛ حيث تبحث عن عبارات الرفض مثل "لا يمكنني المساعدة" أو عبارات الامتثال مثل "وضع المطور" (developer mode).

لكن النماذج تستخدم نمط "المراوغة ثم الامتثال" (hedge-then-comply). فهي تقول "لا يمكنني المساعدة في ذلك"، ولكنها تقدم المعلومات المحظورة على أي حال. تفشل مطابقة الكلمات المفتاحية هنا لأن عبارة الرفض موجودة بالفعل.

ولإصلاح ذلك، استخدمت نظام "النموذج اللغوي كحكم" (LLM-as-judge). حيث أرسلت المحادثة إلى نموذج أقوى ليقرر ما إذا كان النموذج المستهدف قد امتثل بالفعل. كانت خطتي هي استخدام فحوصات الكلمات المفتاحية الرخيصة أولاً، واستخدام "الحكم" المكلف فقط عندما تكون نتيجة فحص الكلمات المفتاحية غير مؤكدة.

ثم اكتشفتُ الخطأ البرمجي الخاص بي.

أعطى كاشف الكلمات المفتاحية الخاص بي درجة ثقة تبلغ 1 عندما وجد نمط "المراوغة ثم الامتثال". ومع ذلك، كان الكود الخاص بي لا يثق في مرحلة الكلمات المفتاحية إلا إذا كانت درجة الثقة 2 أو أعلى.

وهذا يعني أن الكاشف "الرخيص" لم يتخذ قرارًا فعليًا أبدًا. فكل حالة كانت تُحال إلى "الحكم" المكلف. كنت أدفع ثمن "حكم" في كل حالة، حتى عندما كان ينبغي لأداتي المجانية التعامل مع الأمر.

علمني هذا الخطأ ثلاثة دروس حول استخدام النماذج اللغوية الكبيرة (LLMs) لتقييم نماذج لغوية أخرى:

  • يجب أن يكون "الحكم" أذكى من النموذج المستهدف. إذا كان الحكم بنفس حجم النموذج المستهدف، فسيشترك معه في نفس نقاط الضعف (blind spots).
  • الدقة قد تكون مضللة. إذا كانت معظم النماذج ترفض، فإن الحكم الذي يقول دائمًا "تم الرفض" سيبدو دقيقًا ولكنه لن يتعلم شيئًا. استخدم مقاييس مثل "كابا كوهين" (Cohen's kappa) لمراعاة عامل الحظ.
  • يجب أن يكون الحكم مستقرًا. قم بتشغيل الاختبار نفسه خمس مرات؛ فإذا غير الحكم رأيه، تكون النتيجة غامضة وتحتاج إلى مراجعة بشرية.

إذا كنت تبني تطبيقات باستخدام LLMs، فتذكر هذه النقاط:

  • اكتشاف الامتثال أصعب من التسبب فيه.
  • انتبه للنماذج التي ترفض في الجملة الأولى ولكنها تمتثل في الثانية.
  • لا تثق في "حكم" الـ LLM بشكل أعمى؛ بل قم بقياس مدى موثوقيته.
  • شارك أخطاءك البرمجية. فالعثور على عيوبي الخاصة علمني أكثر مما كان سيفعله إطلاق منتج مثالي.

المصدر: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a

مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi