SWE-bench: هل تستطيع النماذج اللغوية حلّ مشكلات GitHub الحقيقية؟

بحلول عام 2023 صارت النماذج اللغوية بارعة جداً في توليد الشيفرة القصيرة. على HumanEval — وهو المعيار المرجعي السائد — كانت النماذج تحلّ أكثر من 90% من المسائل. لكن هذه المسائل في حقيقتها ألغاز بسيطة: اكتب دالة تعكس نصاً، أو تحسب مضروباً، أو تكتشف متناظرة. كل لغز مكتفٍ بذاته ولا يتجاوز بضعة أسطر، ولا يحتاج من النموذج أي إدراك لقاعدة الشيفرة المحيطة.

العمل الهندسي الحقيقي مختلف تماماً. مطوِّر يحاول إصلاح خلل في Django مثلاً قد يحتاج إلى قراءة تقرير المشكلة، ثم التنقّل في قاعدة شيفرة فيها أكثر من 6,000 ملف و400,000 سطر، وفهم كيف تتداخل عشرات الدوال الموزَّعة على وحدات متعددة، ثم كتابة إصلاح يطال عدة ملفات، مع التأكّد من أن مئات الاختبارات القائمة ما زالت تمرّ بنجاح. لم يكن أي معيار مرجعي يُحاكي هذا المستوى من التعقيد — إلى أن جاء SWE-bench.

تبدأ عملية بناء SWE-bench بجمع طلبات السحب من 12 مستودع Python مفتوح المصدر واسع الانتشار — مشاريع مثل Django وscikit-learn وmatplotlib وsympy وpytest. وقع الاختيار على هذه المستودعات تحديداً لأنها تتمتع بصيانة جيدة وإرشادات مساهمة واضحة وتغطية اختبارات شاملة. هذا الجمع الأولي يُنتج نحو 90,000 طلب سحب.

بعد ذلك يمرّ الخطّ بمرحلتَي تصفية. المرحلة الأولى تصفية بالخصائص: تحتفظ فقط بالطلبات التي تحلّ مشكلة مسجّلة على GitHub وتُعدّل ملفات اختبار — وهذا يعني أن المساهم كتب اختبارات تتحقّق من صحة الإصلاح. بهذا ينخفض العدد إلى نحو 11,400 مرشح. المرحلة الثانية تصفية بالتنفيذ: تُثبَّت قاعدة الشيفرة، وتُطبَّق تغييرات طلب السحب، ثم تُشغَّل الاختبارات. لا تنجو إلا الحالات التي ينتقل فيها اختبار واحد على الأقل من «فشل» إلى «نجاح». في النهاية لا يبقى سوى 2,294 مهمة — كل واحدة منها تحدٍّ هندسي موثّق وقابل لإعادة الإنتاج.

كل مهمة في SWE-bench تتألّف من أربعة مكوّنات. أولاً: نصّ المشكلة، وهو بلاغ حقيقي من GitHub — في الغالب تقرير خلل يتضمّن خطوات لإعادة إنتاج المشكلة والسلوك المتوقَّع والسلوك الفعلي. ثانياً: قاعدة الشيفرة، أي المستودع بالكامل عند الإيداع الذي يسبق الإصلاح مباشرة. ثالثاً: على النموذج أن يُنتج ملف رقعة بصيغة .diff يحدّد بدقة الأسطر المُضافة أو المحذوفة أو المُعدَّلة. رابعاً: الاختبارات التي تُقيِّم الرقعة: اختبارات «فشل-إلى-نجاح» تتحقّق من أن الإصلاح يعمل، واختبارات «نجاح-إلى-نجاح» تتأكّد من أن شيئاً آخر لم ينكسر.

الأرقام تستحقّ التأمّل: في المتوسط تحتوي المهمة على قاعدة شيفرة فيها 3,010 ملف و438,000 سطر برمجي، بينما الحلّ المرجعي لا يمسّ سوى 1.7 ملف و3 دوال و32.8 سطر. تخيَّل أنك تبحث عن 33 سطراً وسط 438,000 — الأمر أشبه بالبحث عن فقرة بعينها في كومة من الروايات.

قاعدة الشيفرة النموذجية في SWE-bench تحتوي على مئات الآلاف من الأسطر — أكثر بكثير ممّا تستوعبه نافذة السياق لأي نموذج. فالسؤال المحوري هنا: أي الملفات نُريها للنموذج؟ تختبر الورقة استراتيجيتَي استرجاع.

BM25 (الاسترجاع المتناثر) يعتمد على مطابقة الكلمات المفتاحية بين نصّ المشكلة وملفات الشيفرة لاختيار الأكثر صلة. طريقة عملية لكنها خشنة: في نحو نصف الحالات لا يسترجع BM25 أيّاً من الملفات التي تحتاج فعلاً إلى تعديل. أي أن النموذج يحاول إصلاح شيفرة لم يطّلع عليها أصلاً.

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

لمقارنة النماذج المفتوحة بالنماذج التجارية، أجرى الباحثون ضبطاً دقيقاً لنموذج CodeLlama بحجمَي 7 و13 مليار معامل على مجموعة تدريب منفصلة من 19,000 زوج بلاغ–طلب سحب مأخوذة من 37 مستودع Python إضافياً — منفصلة تماماً عن مجموعة التقييم لتفادي تلوّث البيانات.

يعتمد الضبط الدقيق على تقنية التكييف منخفض الرتبة (LoRA)، التي لا تُعدّل سوى أوزان طبقة الانتباه لتوفير الذاكرة. حُدِّد الطول الأقصى للتسلسلات بـ30,000 رمز، ممّا قلّص بيانات التدريب القابلة للاستخدام إلى نحو 10,000 مثال. نماذج SWE-Llama الناتجة قادرة على معالجة سياقات تتجاوز 100,000 رمز، ويمكن تشغيلها على أجهزة شخصية عادية.

من النتائج المهمة هنا أن SWE-Llama يُقدّم أداءً مقبولاً مع الاسترجاع المرجعي — لأنه يُطابق التوزيع الذي تدرّب عليه — لكنه يتراجع بوضوح مع استرجاع BM25. السبب أن النموذج تعلّم أن يُعدّل كل ملف يُقدَّم له كسياق، فحين يُدرج BM25 ملفات لا علاقة لها بالمشكلة يحاول SWE-Llama تعديلها أيضاً — وهذا انزياح في توزيع السياق يُضعف أداءه بشكل واضح.

النتيجة الرئيسية مُقلقة: مع استرجاع BM25، لا يحلّ Claude 2 سوى 1.96% من مشكلات SWE-bench — وهو الأفضل بين جميع النماذج المُختبَرة. ChatGPT-3.5 لا يتجاوز 0.17%، وGPT-4 يصل إلى 1.31% فقط. حتى SWE-Llama 13b بعد الضبط الدقيق لا يحلّ إلا 0.70%.

مع الاسترجاع المرجعي — أي اختيار مثالي للملفات — يرتفع Claude 2 إلى 4.8% وSWE-Llama 13b إلى 3.97%. وفي إعداد أكثر تساهلاً يُسمّى «المرجعي المطوي» يُعرض فيه فقط الأسطر المُعدَّلة مع هامش 15 سطراً حولها، يصل Claude 2 إلى 5.93%. هذه الأرقام تكشف أن النموذج حتى حين يرى الشيفرة الصحيحة أمامه، يعجز عن فهمها وإصلاحها.

يتراجع الأداء بحدّة كلما طال السياق. المهام التي يقلّ مدخلها عن 20,000 رمز تُحلّ بمعدل أعلى، لكن فوق 100,000 رمز يكاد الأداء يتلاشى. وهذا يتّسق مع ظاهرة «الضياع في الوسط» حيث تفشل النماذج في تحديد المعلومات المطلوبة وسط السياقات الطويلة.

التحليل النوعي يكشف أنماط فشل تتكرّر باستمرار. الرقع التي تولّدها النماذج أقصر بنحو النصف من الحلول البشرية: 19.6 سطراً في المتوسط مقابل 74.5 سطر في الرقع المرجعية. النماذج غالباً تعدّل ملفاً واحداً فقط، بينما الحلول البشرية تمسّ 1.7 ملف وسطياً. ونادراً ما تتجاوز النماذج دالة واحدة.

جذر المشكلة هو ما يمكن تسميته بالنهج «الجشع»: النموذج يعالج العَرَض المباشر المذكور في البلاغ دون أن يأخذ في حسبانه السياق الأوسع لقاعدة الشيفرة. يكتب شيفرة Python بدائية بدل أن يستفيد من الدوال المساعدة والمكتبات الموجودة أصلاً في المستودع. يتجاهل أعراف كتابة الشيفرة مثل الاستيراد النسبي. في المقابل، الحلول البشرية كثيراً ما تتضمّن تحسينات هيكلية وتستبق مشكلات مستقبلية — وهو نوع من التفكير الشمولي لا تملكه النماذج الحالية.

هناك إخفاق كبير آخر: توليد ملفات رقعة بتنسيق سليم. حتى حين يفهم النموذج الإصلاح المطلوب، كثيراً ما يُخرج ملف .patch مشوَّهاً لا يمكن تطبيقه على قاعدة الشيفرة. نسبة تطبيق الرقع بنجاح تتراوح بين 21% لـ ChatGPT-3.5 و67% لـ SWE-Llama 13b في الإعداد المرجعي.

عدة قرارات تصميمية تمنح SWE-bench متانةً واستدامة. أولاً: المعيار قابل للتحديث باستمرار — يمكن لنفس خطّ البناء جمع طلبات سحب جديدة من أي مستودع Python، فيولّد مهام طازجة من مشكلات أُنشئت بعد تاريخ قطع تدريب النموذج — ممّا يضمن أن النموذج لم يرَ الحلّ من قبل. ثانياً: التقييم قائم على التنفيذ الفعلي ومتين — كل مهمة تحتوي وسطياً على 51 اختبار نجاح-إلى-نجاح إلى جانب اختبارات فشل-إلى-نجاح، ممّا يُشكّل حارساً قوياً ضد الرقع التي تُصلح شيئاً وتكسر غيره. ثالثاً: المعيار مفتوح النهاية — على خلاف مهام ملء الفراغ، يستطيع النموذج توليد حلول مبتكرة تختلف كلياً عن الرقعة المرجعية — كل ما يُطلب منه هو اجتياز الاختبارات.

يُقدّم البحث أيضاً SWE-bench Lite: مجموعة فرعية مُنتقاة من 300 مهمة تُركّز على إصلاحات أخطاء وظيفية مستقلة. هذا يمنح الباحثين حلقة تقييم أسرع أثناء تطوير مناهج جديدة، مع الحفاظ على جوهر الصعوبة التي يتميّز بها المعيار.

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