حلقة «المخترق – المُصلح» تسد ثغرات المُحقِّقات في Terminal Bench وKernelBench وSETA

أصبحت بيئات الوكلاء أساسًا لتدريب نماذج LLM وتقييمها: فالمُحقِّق البرمجي (verifier) يحوّل نتيجة عمل معقد إلى مكافأة. لكن المُحقِّق نفسه شيفرة برمجية، ويمكن خداعه. فيحصل الوكيل على الدرجة الكاملة دون أن يحل المهمة، وينحرف التقييم والتدريب عن مسارهما. ويقترح مؤلفو الدراسة الجديدة سد هذه الثغرات تلقائيًا. وقد طبّقوا الطريقة على ثلاث بيئات هي Terminal Bench وKernelBench وSETA، وخفّضوا في الثلاث جميعها نسبة الهجمات الناجحة بشكل ملحوظ. واعتُمدت نسخة مبكرة من الحلقة بالفعل في المستودع الرسمي لـ Terminal Bench أداةً لتدقيق الثغرات.

كيف تعمل الطريقة

صيغ السؤال الأصلي على هيئة مسألة weak-to-strong: هل يستطيع نموذج اليوم، مدعومًا بميزانية حوسبة كبيرة، أن يحصّن البيئة مسبقًا بحيث لا تتمكن نماذج المستقبل الأقوى من اختراقها؟ وتقوم الإجابة على خطوتين.

أولًا، تُنشأ بيئة معزولة (sandbox) للمُحقِّق لا يستطيع الوكيل تعديلها مباشرة. وهذا يسد أخشن فئات الالتفاف، وهي أن يعدّل الوكيل شيفرة التحقق أو البيانات التي يعتمد عليها التقييم. ثم تبدأ حلقة hacker-fixer. يحاول أحد الدورين الحصول على المكافأة الكاملة دون تنفيذ المهمة. أما الدور الآخر فيحلل الالتفاف الذي اكتُشف ويُصلح المُحقِّق. بعد ذلك تتكرر الحلقة على النسخة المحدّثة.

أبرز المعايير التي يذكرها المؤلفون:

• عزل المُحقِّق: لا يستطيع الوكيل تعديله مباشرة؛
• الأتمتة: يجري اكتشاف الثغرات وإصلاحها دون تحليل يدوي؛
• بيئات الاختبار: Terminal Bench وKernelBench وSETA؛
• قابلية التوسع: تزداد الحماية قوة مع زيادة عدد تكرارات الحلقة؛
• خط الأساس للمقارنة: نسخة ثابتة غير تكرارية، تتفوق عليها الحلقة التكرارية؛
• التطبيق: تُستخدم نسخة مبكرة من الحلقة في المستودع الرسمي لـ Terminal Bench.

لماذا تهم التكرارات

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

واختيار المنصات ذو دلالة أيضًا. يختبر Terminal Bench عمل الوكيل في الطرفية، ويقيّم KernelBench توليد أنوية GPU، وهي حالة يسهل فيها التلاعب بالقياس بدلًا من تسريع الشيفرة فعلًا. أما SETA فتنتمي إلى الفئة نفسها من البيئات. هذه أنواع مختلفة من المهام وأسطح هجوم مختلفة، والطريقة تعمل على الثلاثة.

والقيود واضحة كذلك. فلا تتضمن الملخّص البحثي أرقامًا محددة، إذ يقول فقط إن الهجمات انخفضت «بشكل كبير». كما يُختبر افتراض weak-to-strong بالاستقراء: يؤدي دور المخترق النموذج الحالي، ويبقى مفتوحًا السؤال عن مدى تغطية الثغرات التي يكتشفها لفضاء هجمات الأنظمة الأقوى. وهذا استنتاجي من صياغة المسألة، وليس ادعاءً من المؤلفين. وينبغي البحث عن التفاصيل في صفحة المشروع verifier-hardening.github.io.

ماذا على الفرق التي تبني البيئات أن تفعل؟

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

وإذا كنتم تنشرون اختبارًا معياريًا، فمن المنطقي أن تعدّوا النتائج المبالغ فيها مؤشرًا على عيب في البيئة، لا على نجاح. وتُظهر تجربة Terminal Bench أن هذا التدقيق يمكن دمجه مباشرة في المستودع. وكلما زاد عدد البيئات التي تتدرب على فئة المُحقِّقات نفسها، ارتفعت كلفة كل ثغرة لم تُكتشف، والحلقة الآلية هنا أرخص من الفحص اليدوي.