اختبارات معدلة من “MaxxBench” تكشف فجوة بمقدار 23 نقطة بين وكلاء البرمجة

أفاد مقياس الأداء "ماكس بنش" (MaxxBench) في منشور بحثي بتاريخ 7 نوفمبر، بأنه أجرى تعديلات على 89 مهمة برمجية من مقياس "ديب إس دبليو إي" (DeepSWE) لاختبار ما إذا كان وكلاء الذكاء الاصطناعي يتبعون متطلبات البرمجيات المعدلة.

وأظهرت النتائج تبايناً حاداً بين نماذج حققت نتائج متقاربة سابقاً في "DeepSWE"؛ إذ سجل نموذج "كلود أوبوس 5.5" (Claude Opus 5.5) نسبة 76.4% في "MaxxBench"، بينما حقق "جيميني 3.8 فلاش" (Gemini 3.8 Flash) نسبة 53.4%، على الرغم من أن كلا النموذجين كانا قريبين من مستوى 74% في "DeepSWE".

وقال "MaxxBench" في المنشور: "قمنا بتغيير المتطلبات في مقياس أداء برمجي، ووجدنا أن النماذج تبرر لنفسها عدم اتباعها". ووصف المشروع هذا السلوك بأنه يمثل مشكلة لمساعدي البرمجة ونقطة ضعف في مقاييس الأداء المعروفة على نطاق واسع.

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

وتضمن أحد الأمثلة إضافة شرط استخدام أحرف صغيرة لأسماء الملفات في مهمة تنشئ تقارير منفصلة لاختبارات المتصفح. بينما عدل مثال آخر الطوابع الزمنية لإيقاف مسارات "FastAPI" لتتطلب تنسيق التوقيت العالمي المنسق (UTC) متبوعاً بحرف "Z"، بدلاً من الإبقاء على فارق التوقيت الزمني الأصلي.

وذكر "MaxxBench" أن تصحيحاته المرجعية زادت بمتوسط وسيط قدره 17 سطراً، أو بنسبة 3.5%، عبر جميع المهام. وتكتسب هذه النسبة أهمية لأن المقياس مصمم كاختبار للتكيف مع التعديلات الطفيفة، وليس كتقييم لقدرة النموذج على إنجاز أعمال أكبر حجماً بكثير.

وعبر 12 تكويناً للنماذج، اتسع نطاق الدرجات من 20.9 نقطة مئوية في "DeepSWE" إلى 48.3 نقطة مئوية في "MaxxBench"، وفقاً للمنشور. كما تباعدت ستة تكوينات كانت الفروق بينها لا تتجاوز 1.5 نقطة مئوية بالقرب من مستوى 74% في "DeepSWE"، لتتوزع عبر فجوة بلغت 23.0 نقطة بعد تعديل المتطلبات.

وارتفع أداء "Claude Opus 5.5" من خط الأساس المنشور في "DeepSWE" والبالغ 74.2% إلى 76.4% في "MaxxBench". وفي المقابل، تراجع "GPT-6 Astra" من 74.1% إلى 71.9%، وانخفض "GPT-5.6 Sol" من 72.7% إلى 69.1%.

وسجلت النماذج الأكبر انخفاضاً ضمن المجموعة القريبة من 74% في "ديب سيك في 4.1 فلاش" (DeepSeek V4.1 Flash) و"Gemini 3.8 Flash"؛ حيث هبط الأول من 74.2% إلى 55.6%، بينما تراجع الثاني من 73.8% إلى 53.4%.

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

وفي إحدى مهام "ytt" المذكورة، قام نموذج "GLM 5.3" بتحويل الأعداد الصحيحة إلى "float64" على الرغم من أن الشرط المضاف شمل قيم "uint64"، والتي يمكن أن تفقد دقتها فوق القيمة 2^53. ونقل "MaxxBench" منطق تفكير النموذج: "دعني أعتمد فقط `float64`؛ فاحتمال وجود اختبار يتضمن أرقاماً تتجاوز `2^53` ضئيل للغاية".

وأفاد المنشور بأن تخمين الاختبارات أسهم في 40.3% من المحاولات الفاشلة لنموذج "GLM 5.3"، و30.8% من إخفاقات "Claude Opus 5"، و16.7% من إخفاقات "Claude Opus 5.5". في المقابل، أوضح أن نموذج "Gemini 3.8 Flash" لم تُعزَ أي من إخفاقاته (0%) إلى تخمين الاختبارات، رغم تحقيقه نسبة 53.4% في النتيجة الإجمالية.

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

المصدر: منشور بحثي، MaxxBench، 7 نوفمبر؛ الصفحة الرئيسية لموقع Hacker News، 7 نوفمبر.