شرح معيار CyberGym: ما الذي تقيسه درجة E2E فعليًا

إن نتيجة CyberGym الأكثر تداولاً على نطاق واسع — الرقم الوارد في منشور الإطلاق، والرقم الذي تُقارَن به النماذج بعضها ببعض — هي معدل نجاح المهام عبر 131 مهمة مُفلترة، حيث يعني النجاح أن يُنتج وكيل مدخل إثبات مفهوم يؤدي إلى تعطّل نسخة بناء C/C++ غير مُرقّعة، ويكتب رقعة توقف ذلك التعطل، ولا يكسر الاختبارات التي كتبها مطورو المشروع. وفي تجميعة BenchLM، يتصدر MiMo-V2.6-Flash بنسبة 95.1% وMiMo-V2.6-Pro بنسبة 94.0%، مع تأخر DeepSeek-V4.1-Flash ببضع نقاط في نطاق الثمانينيات العليا. ولا يكاد أيٌّ ممن يستشهدون بذلك الجدول يذكر ثلاثة أمور تحدد ما إذا كانت الأرقام قابلة للمقارنة: أن المعيار موجود في أكثر من تنفيذ، وأن معظم الصفوف تقارير ذاتية من المزوّدين لا عمليات تشغيل مستقلة، وأن المرحلة الأكثر إثارة للاهتمام وحدها تُسجَّل ولا تُحتسب. وهذا هو معيار الإسناد نفسه الذي أرشيف حوادث الذكاء الاصطناعي يطبقه على مدخلاته — فالادعاء بلا مصدر ليس نتيجة — وتفشل فيه مدونة CyberGym أكثر مما توحي به سمعتها.

هذا دليل إلى ما يطلبه المعيار المرجعي من الوكيل أن يفعله، وكيف بُنيت مجموعة المهام، وأين تتباين التنفيذات، وما ينبغي للمدافع أن يستنتجه وما لا ينبغي أن يستنتجه من درجة عالية.

المهمة: إيجاد، إعادة إنتاج، ترقيع — دون كسر أي شيء

يأتي CyberGym من مركز بيركلي للذكاء المسؤول واللامركزي، وم premise الخاص به ضيق عمدًا. تستهدف كل مهمة ثغرة تتعلق بسلامة الذاكرة في مشروع مفتوح المصدر بلغة C/C++ واسع الاستخدام. يجب على الوكيل تحديد موقع الخطأ، وكتابة مدخل إثبات مفهوم يتسبب في انهيار ترصده أداة Sanitizer، ثم ترقيع الشيفرة بحيث لا يتكرر الانهيار — مع استمرار اختبارات المشروع نفسه في النجاح. هذا التسلسل هو جوهر الأمر كله. إن معيارًا يكتفي بالسؤال "اعثر على الخطأ" سيكافئ التعرف على الأنماط؛ أما اشتراط مدخل انهيار عامل وتصحيح غير كاسر فيجبر الوكيل على إغلاق الحلقة من الشك إلى عيب مُثبت إلى إصلاح.

يستضيف RDI المعيار داخل مرصد أوسع يتتبع القدرة السيبرانية للذكاء الاصطناعي عبر مراحل الهجوم والدفاع، والتأطير جدير بالملاحظة: فـ CyberGym ليس سوى أداة واحدة على مقعد الاختبار، إلى جانب ExploitGym والنسخة من الطرف إلى الطرف. وقراءته كلوحة صدارة مستقلة تُفقد ذلك السياق، وهذا أحد أسباب ضعف قابلية نقل الأرقام بين السياقات.

أربع مراحل، ثلاث منها تُحتسب

قاعدة التقييم هي الجزء الأقل إبلاغًا عنه في المعيار، لأنها النقطة التي يمكن فيها لدرجة تبدو معقولة أن تبتعد عما حدث فعلاً.

المرحلة 1 هي إعادة الإنتاج: هل يُسبِّب مُدخل إثبات المفهوم الخاص بالوكيل تعطُّل النسخة غير المُرقَّعة. المرحلة 2 هي الترقيع: هل يوقف التغيير المُقدَّم ذلك التعطُّل المحدد. المرحلة 3 هي اختبار الانحدار: هل لا تزال اختبارات الوظائف التي كتبها المطوِّر تنجح. تلك الثلاث تُنتج الدرجة.

المرحلة 4 تسأل عمّا إذا كانت الرقعة تُصلح الثغرة الفعلية المرجعية، وتُسجَّل بوصفها تشخيصًا لا بوصفها محسوبة. يستحق هذا التباين وقفة، لأنه الفرق بين "أن يستطيع الوكيل جعل الانهيار يزول" و"أن يستطيع الوكيل إصلاح الخلل". كلا الادعاءين مفيد؛ لكنهما ليسا الادعاء نفسه. الوكيل الذي يكبت انهيارًا عبر التقاط الإشارة، أو توسيع فحص الحدود بما يتجاوز الفائض، أو تعطيل مسار الشيفرة بالكامل، سيحقق نقاطًا في المراحل من 1 إلى 3 ويفشل في المرحلة 4. إذا أفاد تقرير مكتوب برقم واحد دون أن يذكر ما إذا كانت المرحلة 4 قد روجعت، فلا يمكنك أن تعرف أي الأمرين قد قيس — ويوجد التشخيص تحديدًا كي تتمكن من السؤال.

كيف تم اختيار المهام الـ131 — وما تأثير ذلك على النتيجة

مجموعة البيانات المصدرية أكبر من المجموعة المُقيَّمة، والتصفية هي أكبر عامل منفرد يؤثر في قابلية المقارنة. تحتوي مجموعة بيانات RDI على 920 ثغرة عبر 139 مشروعًا مفتوح المصدر، مأخوذة من Google's OSS-Fuzz. أما النسخة من طرف إلى طرف التي يستخدمها المتتبِّعون من الجهات الخارجية فتحصر ذلك في 131 مهمة، بمهمة واحدة لكل مشروع، مختارة حسب الصعوبة، باستثناء المهام التي تتضمن تسريبات أوراكل أو قيود توافق مع الصندوق الرملي.

تترتب على ذلك ثلاث نتائج مباشرة. أولًا، مهمة واحدة لكل مشروع تعني أن النتيجة يهيمن عليها الاتساع لا العمق: فالوكيل المتوسط عبر مشاريع كثيرة سيتفوق على وكيل ممتاز في ثلاثة مشاريع، وهذا خيار تصميمي يمكن الدفاع عنه وقياس مختلف عن "كم عدد الثغرات التي يستطيع هذا الوكيل إصلاحها". ثانيًا، استبعاد تسريبات الأوراكل يزيل المهام التي يمكن اكتشاف الإجابة فيها من البيئة بدلًا من استنتاجها بالتفكير، لذا فإن المجموعة المتبقية أصعب بطريقة محددة — فهي تزيل الاختصارات بدلًا من إزالة المهام السهلة. ثالثًا، ميزانية 90 دقيقة لكل مهمة داخل بيئة معزولة مبنية من صورة OSS-Fuzz الخاصة بالمشروع هي جزء من تعريف النجاح، وليست تفصيلًا، لأن حصة كبيرة من عمل الثغرات الحقيقي محدودة بهذا النوع من القيود بالضبط، والوكلاء الذين يعتمدون على استكشاف غير محدود سيفشلون هنا بينما ينجحون في مواضع أخرى.

أي مقارنة تتجاهل قاعدة اختيار المهمة إنما تقارن بين اختبارين مختلفين يتصادف أن يحمل كلاهما الاسم نفسه.

تطبيقان، ولماذا لا يلزم أن يتفقا

هنا يكمن معظم الالتباس. يوجد {{1}}CyberGym-E2E{{/1}} بوصفه معيارًا لـ{{2}}RDI{{/2}} وبوصفه تنفيذًا يديره مُقيِّم من طرف ثالث، وليس مضمونًا أن ينتج الاثنان الرقم نفسه للنموذج نفسه. وتقول وثائق المُقيِّم نفسه ذلك بوضوح: إذ يستخدم تنفيذه مجموعة مُرشَّحة من {{3}}131{{/3}} مهمة، بمهمة واحدة لكل مشروع، مختارة وفق الصعوبة، ويشغّل كل مهمة داخل بيئة معزولة مبنية من صورة {{4}}OSS-Fuzz{{/4}} الخاصة بالمشروع باستخدام إطار تشغيل الوكيل الخاص به مع ميزانية {{5}}90 دقيقة{{/5}} لكل مهمة.

تحتوي تلك الجملة على المتغيرين اللذين يحددان النتيجة. إطار التشغيل هو الحلقة التي يعمل الوكيل داخلها — كيف يرصد مخرجات الأدوات، وكم خطوة يمكنه أن يتخذ، وكيف يتعافى من محاولة فاشلة. ويمكن لإطار تشغيل أقوى مع نموذج أضعف أن يتفوق على العكس، وإطار التشغيل ليس جزءًا من أوزان النموذج. الميزانية تتفاعل مع كليهما. لذا يُكتب رقم CyberGym على النحو الصحيح كالتالي: «هذا النموذج، في إطار التشغيل هذا، في هذا التطبيق»، وأي رقم يُقتبس دون ذكر التطبيق هو رقم بلا مقام.

ثمة تأثير من الدرجة الثانية يجدر ذكره: لأن أداة التقييم تقوم بعمل حقيقي، فقد يكون تحسّن نتيجة CyberGym بين نسختين من النموذج تحسّنًا في أداة التقييم جزئيًا، والمورّد الذي يقدّم نتائج أداته الخاصة إنما يقدّم قدرة النظام لا قدرة النموذج. كلا الأمرين مشروع؛ أما الخلط بينهما فليس كذلك.

قراءة جدول التتبّع بصدق

الجدول الذي يصادفه معظم الناس هو تجميع ثانوي، وهو يسمّي مصدره — وهذا هو الجزء المفيد، إن قرأت التسمية. من أصل 29 صفًا، تأتي 7 من مالك المعيار أو من تشغيل مستقل، و21 هي تقارير ذاتية من المزوّدين، وواحد تقرير ثانوي. يذكر التجميع صراحةً أنه يعرض الجدول للاستئناس ولا يرتّب النماذج بناءً عليه، وينصح بقراءته بحذر لأن معظم الصفوف تقارير ذاتية. وملاحظته الخاصة عن التشبّع هي أفيد سطر في الصفحة: الثلاثة الأوائل موزّعون على نحو 70 نقطة، بينما يقع العشرة الأوائل ضمن نحو 10 نقاط، لذا لا يزال الجدول يفصل بين النماذج — لكن ليس عند أعلى النطاق، حيث يكون الترتيب هزيلًا.

التقرير الذاتي من المورّد هو دليل قابل للعرض. وهو ليس قياسًا مستقلًا، والفرق يهم في هذا الاختبار المعياري أكثر من معظم الحالات، لأن متغيّر أداة الاختبار يمنح البائع هامشًا كبيرًا لضبط الرقم الذي يبلّغ عنه. وعندما يتعارض تقرير ذاتي مع تشغيل مستقل، يكون الاعتماد على التشغيل المستقل. وعندما لا يوجد سوى تقرير ذاتي، فإن القراءة الأمينة هي «غير مُتحقَّق منه، معقول، ولا يوجد خط أساس قابل للمقارنة».

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

ماذا تعني النتيجة العالية وماذا لا تعني بالنسبة للمدافع

السؤال الذي يطرحه فريق الأمن فعليًا ليس "أي نموذج يتصدر الجدول"، بل "ماذا يفعل وكيل يحقق نتيجة جيدة في هذا الاختبار بمخاطري". فالمعيار المرجعي يجيب عن سؤال أضيق من السؤال المطروح، والفجوة بينهما جديرة بأن نسمّيها.

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

هذا لا يعني أن الوكيل يفهم قاعدة الشيفرة لديك، أو نموذج التهديد الخاص بك، أو نشرك. فالمهام مأخوذة من أهداف OSS-Fuzz العامة ذات ثغرة معروفة مرجعيًا ومجموعة اختبارات تخبر الوكيل ما إذا كان قد انتهى. ولا توجد في شيفرة الإنتاج وسيلة تحقق مرجعية كهذه. كما أنه لا يعني أن الوكيل سيجد الخطأ المقصود بدلًا من خطأ آخر: فالمرحلة 4 موجودة لأن هذين يختلفان، والمرحلة 4 لا تُحتسب.

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

ما الأسئلة التي يجب طرحها قبل الوثوق برقم CyberGym؟

خمسة أسئلة يمكن الإجابة عنها من تقرير جيد الصياغة، وعادةً يتعذر الإجابة عنها من منشور إطلاق.

• أي تنفيذ؟ معيار RDI، أم نسخة مصفّاة من مُقيّم طرف ثالث. إذا لم يذكر التقرير ذلك، فالرقم غير قابل للمقارنة بأي شيء.

• مَن أجرى التشغيل؟ تقييم مستقل أم تقرير ذاتي من المزوّد. يوضّح جدول التجميع ذلك لكل صف؛ لكن معظم المواد التسويقية لا تفعل.

• أي إطار اختبار، وأي ميزانية؟ إذا كان إطار الاختبار مملوكًا للمورّد ولم يكن موصوفًا، فتعامل مع النتيجة كادّعاء على مستوى النظام بشأن تكوين منتج محدّد.

• هل تمت استشارة المرحلة 4؟ يخبرك المعدل المُبلَّغ عنه مع التشخيص إلى جانبه ما إذا كانت التصحيحات قد أصلحت الخلل أم اكتفت بإسكات الانهيار.

• أي مجموعة مهام؟ 131 مهمة، بواقع مهمة واحدة لكل مشروع، اختيرت حسب الصعوبة هي المجموعة الشائعة؛ وأي مرشّح مختلف هو اختبار مختلف.

Cybergym معيار مرجعي محكم البناء لمهمة واقعية صعبة، وبناؤه أكثر تشويقًا من لوحة صدارته. تخبرك المراحل بما كان على الوكيل فعله؛ وتخبرك التصفية بما يعنيه الدرجة فعليًا؛ ويخبرك إطار التقييم بمن يستحق الفضل. والرقم الذي يأتي مصحوبًا بهذه الثلاثة مفيد حقًا. أما الرقم الذي يأتي وحده فهو بيان صحفي يحمل علامة نسبة مئوية.