قفزت درجات SWE-bench من 1.96% إلى 72.7% في أقل من عامين، وهو ارتفاع صاغته العناوين الصحفية على أنه قفزة بمقدار 37 ضعفاً في قدرات البرمجة للذكاء الاصطناعي. يجذب العنوان الانتباه، لكن الأرقام تقارن بين اختبارين مختلفين، وليس تحسناً مستمراً وواحداً في مهارات هندسة البرمجيات.
الأرقام الخام
في عام 2023، قام SWE-bench الأصلي بتقييم وكلاء الذكاء الاصطناعي بناءً على 2,294 مشكلة حقيقية من GitHub. كانت المهام خليطاً غير متجانس: أوصاف غامضة، واختبارات معطلة، والعديد من المشكلات التي قد يجد حتى البشر صعوبة في حلها. وبحلول عام 2025، ظهر نفس اسم المعيار (benchmark) بدرجة 72.7%، ولكن تم تضييق الاختبار إلى مجموعة فرعية "موثقة" (Verified) تضم 500 مهمة فقط قام البشر بمراجعتها للتأكد من وضوحها وقابلية حلها.
كيف تغير الاختبار
يعد التحول من الكتالوج الكامل إلى المجموعة الموثقة (Verified) التغيير الأول والأكثر وضوحاً. حاولت المجموعة الأصلية عكس الواقع الفوضوي للمساهمات في المصادر المفتوحة — وهي مشكلات غير مكتملة، أو موثقة بشكل سيئ، أو مستحيلة ببساطة دون سياق إضافي. وفي المقابل، تعمل النسخة الموثقة (Verified) على تصفية تلك الفوضى عمداً؛ فهي تقدم مجموعة مشكلات أكثر نظافة وقابلية للحل، حيث يمكن تحقيق درجات عالية بشكل واقعي.
ولأن النسختين تقيسان أجزاءً مختلفة من نطاق المشكلة، فإن المقارنة المباشرة بالنسب المئوية تكون مضللة. فرقم 1.96% يجسد الأداء في العمل الخام غير المصفى، بينما يجسد رقم 72.7% الأداء في عينة منسقة تكون فيها فرص النجاح أعلى بكثير.
الهندسة المستهدفة
حدث تحول ثانٍ وأكثر دقة في كيفية تعامل المطورين مع المعيار. في عام 2023، لم يقم أحد ببناء وكلاء خصيصاً للتفوق في SWE-bench؛ حيث كان الاختبار يعمل كعينة عشوائية لتحديات البرمجة في العالم. وبحلول عام 2025، حولت الفرق المعيار إلى لوحة نتائج؛ فقاموا ببناء هياكل دعم (scaffolding)، واستراتيجيات توجيه (prompting strategies)، وضبط النماذج (fine-tuned models) بهدف صريح وهو الحصول على درجات عالية في المجموعة الموثقة (Verified).
عندما يصمم المهندسون نظاماً لاجتياز اختبار معين، فإن الدرجة تعكس مدى ملاءمة النظام لهذا الاختبار، وليس مدى قدراته الواسعة. لقد توقف المعيار عن كونه عينة ممثلة للعمل في العالم الحقيقي في اللحظة التي تم فيها "إصلاحه" وتحويله إلى هدف.
ماذا تعني هذه القفزة حقاً
التحسن الذي تتصدر به العناوين حقيقي بمعنى أن وكلاء البرمجة الحاليين يؤدون بشكل أفضل بكثير في المهام الموثقة (Verified) مما كانوا عليه في المجموعة الأصلية. هذا التحسن مهم للمسابقات، والأوراق البحثية، وعروض المنتجات التي تعتمد على نفس المعيار المنسق.
ومع ذلك، فإن هذه القفزة لا تثبت أن وكلاء الذكاء الاصطناعي يمكنهم الآن التعامل مع فوضى تطوير البرمجيات اليومية. فمجموعة الـ 2,294 مشكلة الأصلية لا تزال موجودة، وتظل الدرجات في تلك النسخة منخفضة.
أسئلة يجب طرحها
كلما رأيت تحولاً هائلاً في نتائج المعايير، ضع هذه الفحوصات الثلاثة في اعتبارك:
- أي نسخة يتم الإبلاغ عنها؟ الأصلية (Original)، أم الخفيفة (Lite)، أم الموثقة (Verified)؟ الأسماء المتطابقة يمكن أن تخفي مجموعات مهام مختلفة تماماً.
- ما الذي تم استبعاده؟ إن إزالة المهام المشوشة أو المستحيلة يرفع سقف التوقعات لأي نظام، ولكنه يزيل أيضاً التحديات ذات الأهمية في بيئة الإنتاج.
- هل تم بناء النظام لاجتياز هذا الاختبار تحديداً؟ إذا قام المطورون بضبط النماذج أو مسارات العمل (pipelines) لتناسب المعيار، فإن الدرجة تقيس التحسين (optimization) وليس القدرة الخام.
تطلع إلى المستقبل
إلى أن تصبح مثل هذه الضمانات معياراً ثابتاً، سيظل أفضل مقياس لمدى فائدة المبرمج الآلي هو أداؤه في المشكلات الفوضوية والواقعية التي يواجهها المطورون يومياً.
الخلاصة: الحصول على درجة أعلى في معيار مُصلح ومستهدف لا يثبت تلقائياً أن وكلاء الذكاء الاصطناعي مستعدون لفوضى الأكواد في العالم الحقيقي؛ فالاختبار الحقيقي يظل هو المشكلات غير المصفاة التي يصارعها المهندسون كل يوم.
