SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring
تقدم الورقة البحثية SWE-Bench ProMax، وهو معيار مرجعي متعدد اللغات ومنسق بدقة يضم 170 مهمة لإعادة هيكلة الكود البرمجي واسعة النطاق، صُممت للتغلب على عيوب وتشبع التقييمات الحالية، مما يثبت أن وكلاء الذكاء الاصطناعي الرائدين الحاليين لا يزالون يعانون مع تحديات هندسة البرمجيات المعقدة التي تحافظ على السلوك.
المؤلفون الأصليون:Yuling Shi, Jinghan Xu, Kelin Fu, Wenhao Zeng, Shilin He, Lei Zhang, Yue Liu, Zelin Zhao, Terry Yue Zhuo, Jialun Cao, Siyu Ye, Tianyu Liu, Kai Cai, Shing-Chi Cheung, Xiaodong Gu
تخيل عالماً تتعلم فيه الحواسيب كيف تصبح مهندسي برمجيات. لسنوات، اختبر العلماء "وكلاء البرمجة بالذكاء الاصطناعي" عبر مطالبتهم بحل ألغاز صغيرة ومعزولة، مثل كتابة دالة واحدة لجمع رقمين. الأمر يشبه اختبار طيار بجعله يقود طائرة على مدرج المطار فقط. لكن البرمجيات الحقيقية لا تُبنى سطراً تلو الآخر؛ بل هي مدينة ضخمة ومترابطة من الأكواد، حيث قد يتطلب تغيير لوحة إرشادية واحدة تحديث الخرائط، وإشارات المرور، وجداول الحافلات في المدينة بأكملها. السؤال الكبير الذي يطرحه الباحثون هو: هل تستطيع وكلاء الذكاء الاصطناعي التعامل مع الواقع الفوضوي والمعقد لإعادة كتابة أجزاء ضخمة من البرمجيات دون كسر أي شيء؟ هذا هو مجال "إعادة هيكلة الكود" (Code Refactoring) — فن إعادة تنظيم التوصيلات الداخلية لمبنى ما دون تغيير كيفية عمل الأضواء للموجودين بداخله.
هنا يأتي دور SWE-Bench ProMax، وهو اختبار جديد فائق التحدي صُمم لمعرفة ما إذا كانت وكلاء الذكاء الاصطناعي مستعدين لدخول الدوريات الكبرى. الاختبارات السابقة كانت تشبه ألعاب الفيديو في "الوضع السهل"، حيث كان بإمكان الذكاء الاصطناعي غالباً الاعتماد على حفظ الإجابات أو حل مشكلات بسيطة للغاية. أدرك مبتكرو هذا المعيار الجديد أنه إذا كانت الاختبارات سهلة جداً أو سيئة التصميم، فإن الدرجات العالية التي يحققها الذكاء الاصطناعي ليست سوى وهم للذكاء. لذا، قاموا ببناء مسار عقبات بنمط "الوضع الصعب". لقد جمعوا 170 تحدياً برمجياً من العالم الحقيقي من سبع لغات برمجة مختلفة (بما في ذلك بايثون، وجافا، و++C، ورست). هذه ليست إصلاحات صغيرة؛ بل هي عمليات إصلاح شاملة حيث يجب على الذكاء الاصطناعي تنسيق التغييرات عبر ما معدله 11.4 ملفاً مختلفاً وإعادة كتابة أكثر من 260 سطراً من الكود، كل ذلك مع ضمان بقاء البرنامج يعمل تماماً كما كان من قبل.
النتائج كانت بمثابة مواجهة للواقع لصناعة الذكاء الاصطناعي. فعندما أُلقي بأذكى نماذج الذكاء الاصطناعي وأكثرها تكلفة في هذه الحلبة، لم تنجح في اجتياز الاختبار ببراعة. فقد تمكن أفضل نموذج من حل 41.2% فقط من المهام. يشير هذا إلى أنه بينما يزداد ذكاء الاصطناعي في أداء المهام الصغيرة، فإنه لا يزال يعاني مع التنسيق المعقد متعدد الخطوات المطلوب للهندسة الحقيقية في العالم الواقعي. ومن المثير للاهتمام أن الورقة البحثية وجدت أن إنفاق المزيد من المال على النموذج لا يعني دائماً نتائج أفضل؛ إذ حققت بعض النماذج مفتوحة المصدر والأقل تكلفة أداءً يقارب أداء العمالقة باهظي الثمن. والسبب الرئيسي لفشل الذكاء الاصطناعي؟ لقد كان يميل إلى كونه عاملاً "جزئياً". فقد كان يصلح المشكلة الرئيسية ولكنه ينسى تحديث الملفات الداعمة، مثل إصلاح أنبوب مسرب لكن نسيان إخبار عداد المياه، مما يؤدي إلى فشل النظام بأكره. يثبت هذا المعيار أن الإتقان الحقيقي لهندسة البرمجيات بالنسبة للذكاء الاصطناعي لا يزال عملاً قيد الإنجاز، ويتطلب مستوى من التخطيط والتنسيق عبر الملفات لم تتقنه الوكلاء الحاليون بعد.
ملخص تقني: SWE-Bench ProMax
بيان المشكلة
مع تقدم وكلاء البرمجة المعتمدين على الذكاء الاصطناعي، بدأت معايير هندسة البرمجيات الحالية في التشبع بسرعة، مما أثار مخاوف بشأن ما إذا كانت الدرجات المتزايدة تعكس تحسناً حقيقياً في القدرات أم مجرد قيود في تصميم المعايير الحالية. كشفت عملية تدقيق حديثة لـ SWE-bench Verified أن ما يقرب من 60% من الحالات غير المحلولة احتوت على مجموعات اختبار معيبة — إما ضيقة للغاية (ترفض الحلول الصحيحة) أو واسعة للغاية (تتحقق من متطلبات غير مذكورة) — وأن النماذج الرائدة يمكنها إعادة إنتاج الرقع البرمجية الذهبية (gold patches) من بيانات التدريب. علاوة على ذلك، تركز المعايير الحالية بشكل أساسي على إصلاح الأخطاء المنعزلة أو تنفيذ الميزات، والتي غالباً ما تتضمن تعديلات في ملف واحد فقط. هذا الإجراء يفشل في التقاط تعقيد إعادة هيكلة الكود (code refactoring)، وهي مهمة بالغة الأهمية وطويلة الأمد في التطوير المهني تتطلب تغييرات منسقة تحافظ على السلوك عبر ملفات عديدة. إن معايير إعادة الهيكلة الحالية إما محدودة النطاق، أو مقتصرة على لغة برمجة واحدة، أو تفتقر إلى التحقق البشري الصارم من جودة الاختبارات.
المنهجية
يقدم المؤلفون SWE-Bench ProMax، وهو معيار مُعد بعناية من قبل خبراء ومتعدد اللغات، صُمم لمعالجة هذه الفجوات من خلال خط إنتاج بناء يتكون من ثلاث مراحل صارمة:
جمع البيانات: حدد المؤلفون مستودعات مرشحة على GitHub تلبي معايير محددة (≥500 نجمة، رخصة مفتوحة المصدر معتمدة، واللغة الأساسية هي بايثون، جافا، تايب سكريبت، جو، سي، سي++، أو راست). استخرجوا التغييرات (commits) التي تم تقديمها بعد يناير 2025 والتي تحتوي على الكلمة المفتاحية "refactor" (باستثناء "bug fix") والتي عدلت كلاً من ملفات الاختبار والملفات غير المتعلقة بالاختبار. نتج عن ذلك مجموعة أولية مكونة من 29,782 مرشحاً.
بناء البيئة: لكل مرشح، تم إنشاء بيئة Docker معزولة تحتوي على المستودع في حالة ما قبل إعادة الهيكلة مع تثبيت جميع التبعيات. تم تطبيق الرقعة الذهبية (تغييرات المصدر والاختبار) وتشغيل مجموعة الاختبار. تم استبعاد الحالات التي فشلت فيها البيئة في البناء أو التي لم تجتز فيها الرقعة الذهبية جميع الاختبارات.
التصفية وإعادة كتابة المشكلة: تضمنت هذه المرحلة خبراء بشريين بمساعدة النماذج اللغوية الكبيرة لضمان الجودة العالية:
تحليل التغييرات (Commit Analysis): قام الخبراء بتحليل الفروقات (diffs) لفهم النطاق والقصد.
تصفية الجودة: تمت إزالة المهام ذات التعقيد غير الكافي (مثل التغييرات في ملف واحد، أو عدد الأسطر الضئيل). ومن الأهمية بمكان أنه تمت مراجعة مجموعات الاختبار يدوياً لإزالة الاختبارات الضيقة للغاية (التي تفرض تفاصيل تنفيذ محددة) والاختبارات الواسعة للغاية (التي تتحقق من سلوك خارج نطاق المهمة).
إعادة كتابة بيان المشكلة: تمت إعادة كتابة رسائل التغيير الأصلية من الصفر لتوفير مواصفات دقيقة وغير غامضة. تم التحقق من أن كل وصف يمثل شرطاً ضرورياً وكافياً للرقعة الذهبية.
التحقق البشري: ضمنت المراجعة النهائية التوافق بين وصف المشكلة، ومجموعة الاختبار، والرقعة الذهبية.
يتكون المعيار النهائي من 170 حالة مستخرجة من 70 مستودعاً مختلفاً عبر سبع لغات برمجة.
المساهمات الرئيسية
معيار عالي الجودة ومُعد من قبل خبراء: على عكس المعايير المؤتمتة، يخضع SWE-Bench ProMax لعملية تنسيق خبير متعددة المراحل. تتم إعادة كتابة أوصاف المشكلات لتكون مواصفات دقيقة، ويتم فحص مجموعات الاختبار يدوياً لإزالة العيوب التي عابت المعايب السابقة.
نطاق وتعقيد غير مسبوقين: يستهدف المعيار إعادة الهيكلة واسعة النطاق، حيث يبلغ متوسط الحالات 11.4 ملفاً معدلاً و 261.6 سطراً من الكود لكل مهمة. وهذا يتجاوز المعايير الحالية بشكل كبير (على سبيل المثال، 86% من حالات SWE-bench Verified تعدل ملفاً واحداً فقط).
تغطية متعددة اللغات: تغطي مجموعة البيانات سبع لغات متنوعة (بايثون، جافا، تايب سكريبت، جو، سي، سي++، راست)، مما يسمح بتحليل كيفية تأثير نماذج البرمجة الخاصة بكل لغة (مثل نماذج الملكية في راست، أو إدارة الذاكرة اليدوية في سي) على أداء الوكيل.
بروتوكول تقييم صارم: يستخدم المعيار تقييماً قائماً على النتيجة، حيث تُعتبر الحالة محلولة فقط إذا نجحت تعديلات الوكيل في اجتياز كل اختبار في المجموعة، دون الاعتماد على خطوات وسيطة أو أوامر محددة.
النتائج والتحليل
قام المؤلفون بتقييم ستة نماذج رائدة (ثلاثة نماذج مملوكة لشركات وثلاثة نماذج مفتوحة الأوزان) تحت إطار عمل وكيلين (mini-swe-agent و OpenHands).
تحدٍ غير مشبع: حقق أفضل نموذج أداءً، وهو GPT-5.2، معدل حل قدره 41.2% على SWE-Bench ProMax. وهذا أقل بكثير من معدلات الحل التي تتجاوز 75% في SWE-bench Verified، مما يؤكد أن إعادة الهيكلة واسعة النطلة ومتعددة الملفات تظل تحدياً كبيراً لم يُحل بعد.
كفاءة التكلفة للنماذج مفتوحة الأوزان: أظهرت النماذج مفتوحة الأوزان تنافسية مع النماذج المملوكة بتكلفة ضئيلة. على سبيل المثال، حقق GLM-5 معدل حل بنسبة 36.5% بتكلفة 0.24 دولار لكل حالة، مقارنة بـ Claude Sonnet 4.6 الذي حقق 38.8% بتكلفة 4.77 دولار.
تباين اللغات: لم يهيمن نموذج واحد على جميع اللغات. فقد تباين الأداء بشكل كبير حسب اللغة (على سبيل المثال، تفوق Claude Sonnet 4.6 في Rust و TypeScript، بينما كان GPT-5.2 الأفضل في Python و C)، مما يشير إلى أن نقاط قوة النماذج مرتبطة ببيانات تدريب وهياكل لغات محددة.
تحليل أنماط الفشل: كشف تحليل المسار عن نمطين رئيسيين للفشل:
إعادة الهيكلة غير المكتملة: قامت الوكلاء باستمرار بتعديل ملفات أقل مما تتطلبه الرقعة الذهبية. وبينما نجحوا غالباً في تحديد الملفات الأساسية، إلا أنهم فشلوا في نشر التغييرات إلى المواقع الطرفية، والوثائق، وملفات الإعداد، مما أدى إلى فشل الاختبارات بسبب عدم اتساق التبعيات اللاحقة.
الاستكشاف غير المنتج: استهلكت المحاولات الفاشلة جولات تفاعل أكثر بكثير من المحاولات الناجحة، وغالباً ما دخلت في دورات متكررة من التعديل والتراجع دون توسيع نطاق التعديلات.
الأهمية
يزعم البحث أن SWE-Bench ProMax يوفر معياراً ذا معنى وغير مشبع لتقييم وكلاء البرمجة المعتمدين على الذكاء الاصطناعي في مهام هندسة البرمجيات الواقعية واسعة النطاق. ومن خلال معالجة عيوب الجودة في المعايير السابقة (الاختبارات المعيبة، الأوصاف الغامضة) ورفع مستوى التعقيد ليتناسب مع إعادة الهيكلة في بيئات الإنتاج، فإنه يقدم اختباراً أكثر صرامة لقدرة الوكيل على الحفاظ على خطط متماسكة عبر ملفات متعددة. تشير النتائج إلى أنه بينما تتحسن النماذج الرائدة، فإن القدرة على التنسيق المستدام عبر الملفات تظل عائقاً أساسياً. علاوة على ذلك، يسلط المعيار الضوء على أن النماذج مفتوحة الأوزان يمكن أن تقترب من أداء النماذج الرائدة بتكلفة أقل بكثير، مما يتحدى الافتراض بأن تكاليف واجهة برمجة التطبيقات (API) الأعلى تضمن نتائج أفضل بشكل متناسب في سيناريوهات إعادة الهيكلة المعقدة.