SWE-bench (benchmark) — معيار SWE-bench

From Systems analysis wiki
Jump to navigation Jump to search

SWE-bench هو معيار (مجموعة من مهام الاختبار) واسع النطاق لتقييم قدرات نماذج اللغة الكبيرة (LLM) في مجال تطوير البرمجيات الآلي وتصحيح أخطائها[1]. تم تطويره من قبل مجموعة من الباحثين من جامعة برينستون ومؤسسات أخرى، وقُدِّم في مؤتمر ICLR 2024[2]. يتميز SWE-bench عن معايير البرمجة التقليدية باستخدامه لمهام حقيقية من واقع ممارسة التطوير: تتضمن مجموعة الاختبار 2294 مهمة، مستندة إلى مهام (issues) مغلقة وتصحيحاتها (pull requests) المقابلة من 12 مستودع Python مفتوح المصدر وشائع على GitHub[1][3]. تحتوي كل مهمة على وصف للمشكلة (issue) وتمنح النموذج وصولاً إلى الشيفرة المصدرية للمشروع المعني؛ هدف النموذج هو إنشاء الحد الأدنى من التغييرات في قاعدة الشيفرة (باتش) التي تصلح المشكلة المحددة[1][3].

المنهجية وميزات التقييم

يحاكي SWE-bench العملية الحقيقية لتطوير البرمجيات. لكل مهمة، يُقدَّم للنموذج نص المشكلة الأصلية من GitHub (issue) ونسخة من شيفرة المستودع قبل تطبيق الإصلاح[4]. يُطلب من النموذج (أو الوكيل القائم عليه) تحليل الشيفرة المصدرية، وفهم طبيعة الخطأ أو التغيير المطلوب، وإجراء التعديلات اللازمة في ملفات الشيفرة لحل المشكلة[4][5]. يتم التحقق من صحة الحل بشكل آلي: ترتبط كل مهمة باختبارات الوحدات الفعلية المأخوذة من الـ pull request الذي أغلق المشكلة. من بين هذه الاختبارات، توجد اختبارات "من الفشل إلى النجاح" (fail-to-pass)، التي تفشل على الشيفرة الأصلية ولكن يجب أن تنجح بعد تطبيق الإصلاح الصحيح، بالإضافة إلى اختبارات الانحدار (pass-to-pass)، التي تنجح في البداية ويجب أن تستمر في النجاح بعد إجراء التغييرات[3]. يتم تطبيق الباتش المقترح من النموذج على الشيفرة، ثم تُشغَّل الاختبارات ذات الصلة: إذا نجحت جميع اختبارات fail-to-pass ولم تتأثر اختبارات pass-to-pass، تُعتبر المهمة محلولة بشكل صحيح[3]. يسمح هذا النهج في التقييم بالتحقق ليس فقط من قدرة النموذج على إنشاء شيفرة صحيحة من الناحية النحوية، بل وأيضًا من قدرته على حل المشكلة المطروحة فعليًا دون الإخلال بالوظائف الحالية. في الوقت نفسه، يجب على النموذج التعامل مع سياق كبير (مستودع شيفرة كامل)، وفهم العلاقات المتبادلة بين المكونات، وتنسيق التغييرات في عدة ملفات في آن واحد[1] — كل هذا أكثر تعقيدًا بكثير من المهام النموذجية لكتابة دالة بناءً على وصف.

في تقييمات SWE-bench، لا تشارك نماذج اللغة الكبيرة (LLM) بمفردها عادةً، بل تشارك أنظمة الوكلاء التي تزود النموذج بأدوات مساعدة (مثل التنقل بين الملفات، تنفيذ الشيفرة، استخدام مصحح الأخطاء، إلخ)[4][6]. يحاكي هذا النظام دورة التطوير الحقيقية: يمكن للنموذج تصفح الملفات بشكل متسلسل، وتشغيل الاختبارات أو النصوص البرمجية، وتحسين الحل تدريجيًا حتى يصل إلى نتيجة ناجحة[4]. ومن الجدير بالذكر أن فعالية حل مهام SWE-bench تعتمد إلى حد كبير على جودة هذه "السقالة" (البنية التحتية للوكيل): يمكن لنفس النماذج الأساسية أن تظهر نتائج مختلفة اعتمادًا على كيفية تنظيم تفاعلها مع المستودع والأدوات[4][7]. وبالتالي، يعمل SWE-bench كمقياس لقدرات النموذج واستراتيجيته لحل المشكلات مجتمعتين، مما يجعل التقييم أقرب إلى ظروف العمل الحقيقية لـمطور ذكاء اصطناعي مستقل[4][7].

إصدارات مجموعة المهام

قدم مؤلفو SWE-bench والمجتمع لاحقًا عدة مجموعات مشتقة لأغراض تقييم مختلفة:

  • SWE-bench Lite — نسخة مخففة من المعيار، تتضمن ~300 مهمة[8]، تم اختيارها لتقليل التعقيد والتكاليف الحاسوبية لاختبار النماذج. تم إنشاء هذه المجموعة الفرعية للتجربة السريعة مع النماذج وتستبعد عمليات التحقق الأكثر استهلاكًا للوقت، مع الحفاظ على تمثيلية للمشكلات الرئيسية[7]. في الأساس، يحتوي إصدار Lite على مهام أبسط وأقصر لإصلاح الأخطاء، وعادةً ما تكون نتائج النماذج على Lite أعلى من المجموعة الكاملة بسبب استبعاد الحالات الأكثر تعقيدًا[7].
  • SWE-bench Verified — مجموعة فرعية تمت تصفيتها من خلال مراجعة يدوية، قُدمت في أغسطس 2024 بالتعاون مع OpenAI[7]. استعان الباحثون بـ93 مطورًا محترفًا لتحليل كل مهمة في المعيار الأصلي واستبعدوا الحالات التي يكون فيها وصف المشكلة الأصلي غامضًا جدًا أو السلوك المطلوب في الاختبارات لا يُستنتج بوضوح من شرط المهمة[7]. كما أُزيلت المهام التي يستحيل حلها عمليًا بسبب مشكلات في البيئة أو اختبارات غير صحيحة[7]. في النهاية، تم تشكيل مجموعة من 500 مهمة مضمونة الحل ومصاغة بشكل صحيح[7]. يهدف SWE-bench Verified إلى توفير تقييم أكثر موثوقية لقدرات النماذج، من خلال إزالة الحالات التي يتم فيها رفض الحل الصحيح بسبب عدم كفاية الاختبارات أو المهمة نفسها[7]. حلت هذه المجموعة محل عينات الاختبار الأصلية لـ SWE-bench (الكاملة و Lite) كمرجع أساسي لمقارنة النماذج[7]. بالإضافة إلى ذلك، نُشرت مع Verified تقييمات لصعوبة المهام (على سبيل المثال، تم تحديد المهام "السهلة" التي يحلها الإنسان في أقل من 15 دقيقة، والمهام "الصعبة" التي تتطلب أكثر من ساعة)[7]، كما أُصدر إطار أدوات جديد قائم على Docker لتشغيل الاختبارات بشكل أكثر استقرارًا وقابلية للتكرار[7].
  • SWE-bench Multimodal — امتداد للمعيار، قُدِّم في يناير 2025، يتضمن مهامًا لا يحتوي وصف المشكلة فيها على نص فقط، بل وأيضًا عناصر مرئية (مثل صور واجهة المستخدم، لقطات شاشة للأخطاء، وما إلى ذلك)[8]. تختبر هذه المجموعة (517 مهمة[8]) قدرة النماذج والوكلاء على فهم واستخدام المعلومات المرئية عند حل مهام البرمجة. يتم تنظيم التقييم على المجموعة متعددة الوسائط بشكل مشابه، ولكنه يتطلب من النموذج قدرات متعددة الوسائط (مثل التعرف على النص في الصور). تم الإبقاء على الجزء الاختباري من SWE-bench Multimodal مغلقًا (مخفيًا) لمنع ملاءمة الحلول للإجابات المعروفة؛ يمكن للمطورين إرسال حلولهم إلى لوحة صدارة (leaderboard) عن بعد لتقييم نماذجهم على هذه المهام[2].

إلى جانب هذه الإصدارات الرئيسية، تشكل نظام بيئي من الأدوات حول SWE-bench: SWE-agent — "وكيل" برمجي مفتوح المصدر لحل المهام، يُظهر نتائج متقدمة على مهام المعيار[2]؛ SWE-smith — إطار عمل لتدريب نماذج-مطورين خاصة؛ SWE-REX — أداة للاستخراج والمعالجة المتقدمة للمعلومات من المستودعات، وغيرها. تهدف هذه المشاريع إلى تبسيط تكرار النتائج ودفع الأبحاث في مجال أنظمة البرمجة المستقلة.

النتائج وتقدم النماذج

عند ظهوره لأول مرة، كشف SWE-bench عن فجوة كبيرة بين نماذج اللغة الكبيرة الحديثة ومهارات المبرمجين ذوي الخبرة. أفاد المؤلفون أن حتى أقوى النماذج في بداية عام 2023 كانت قادرة على حل نسبة قليلة جدًا من المهام: على سبيل المثال، نجح نموذج Claude 2 من شركة Anthropic في حل أقل من 2% من مهام المجموعة الكاملة[1]. أما النموذج الذي دربه مؤلفو المعيار خصيصًا (على أساس LLaMA، وأطلق عليه اسم SWE-Llama) والنماذج المسجلة الملكية مثل GPT-4، فقد تمكنت بشكل أساسي من حل أبسط الأخطاء فقط[1]. أكدت هذه المقاييس الأولية المنخفضة صعوبة SWE-bench وشكلت حافزًا لتطوير أساليب جديدة.

خلال عام 2024، مع ظهور نماذج أكثر تطورًا ومخططات وكلاء محسنة، تحسنت النتائج بشكل كبير. قدم باحثون من جامعة برينستون نظام SWE-agent، الذي يجمع بين GPT-4 والبحث في الشيفرة والتخطيط وأدوات أخرى؛ وقد حقق حوالي 12.5% من المهام المحلولة على المجموعة الكاملة، ليضع معيارًا جديدًا للنماذج الأكاديمية[5]. بحلول منتصف عام 2024، وصلت أفضل الحلول على لوحة الصدارة الرسمية لـ SWE-bench (بما في ذلك الحلول المسجلة الملكية) إلى حوالي 20% من الحلول الناجحة على المعيار الكامل وما يصل إلى 43% على مجموعة Lite المبسطة[7]. يرتبط هذا النمو بتحسين النماذج (مثل ظهور GPT-4 و Claude 2 و 3) وخاصة بتطور "السقالة" (scaffolding) — وهي الاستراتيجيات الخارجية التي تسمح للنموذج بتقسيم المهمة بفعالية إلى خطوات، وقراءة التوثيق، وتشغيل جلسات تصحيح الأخطاء، وما إلى ذلك[7].

بعد إدخال مجموعة Verified في نهاية عام 2024 (التي تم تنقيتها من المهام غير الصحيحة)، ارتفع الأداء المقاس بشكل أكبر. أظهر نموذج GPT-4 (إصدار GPT-4o) على الفور حوالي 33% من الحلول الناجحة على Verified مقارنة بـ ~16% سابقًا على المجموعة الأصلية[7]. وضاعفت أفضل أطر الوكلاء المفتوحة (مثل Agentless) نتيجتها من ~16% إلى 32% على Verified[7]. أكد هذا الافتراض بأن المعيار الأصلي كان يقلل من شأن الأداء إلى حد ما بسبب وجود حالات غير قابلة للحل[7]. في الوقت نفسه، لم يكن تحسن النتائج على Verified مقارنة بـ Lite كبيرًا جدًا (حيث كانت أفضل النماذج تصل بالفعل إلى ~43% على Lite)، وهو أمر منطقي: فقد اختار Lite في الأصل أمثلة أسهل، بينما أزال Verified المهام غير القابلة للتنفيذ ولكنه أبقى على المهام الصعبة[7]. من المهم ملاحظة أن الزيادة في الأداء عند الانتقال إلى Verified حدثت في جميع فئات صعوبة المهام، وليس فقط بسبب إزالة الأصعب منها — أي أن التصفية خلصت المجموعة أيضًا من الحالات غير القابلة للتنفيذ بشكل خفي بين المهام البسيطة نسبيًا[7].

في بداية عام 2025، أظهرت أنظمة الذكاء الاصطناعي الرائدة بالفعل كفاءة قريبة من الكفاءة البشرية على مجموعة المهام التي تم التحقق منها، على الرغم من أن الوصول إلى سقف 100% لا يزال بعيدًا. في يناير 2025، أعلنت شركة Anthropic أن نموذجها الجديد Claude 3.5 Sonnet، بالاقتران مع وكيل محسن، قد حل 49% من مهام SWE-bench Verified[4]، ليحتل المركز الأول مؤقتًا. كما تشارك الشركات التكنولوجية الكبرى والفرق المستقلة بنشاط في المسابقات غير الرسمية على هذا المعيار. على سبيل المثال، طور فريق CodeStory نهجًا متعدد النماذج مع تجربة متغيرات مختلفة ("Midwit Agent")، والذي حقق رقمًا قياسيًا بلغ 62.2% من المهام المحلولة على Verified (بيانات بداية عام 2025)[5][9]. ولوحظ أنه لتحقيق ذلك، كان لا بد من زيادة كبيرة في استهلاك الموارد الحاسوبية في مرحلة استدلال النموذج (ما يسمى inference time scaling)، من خلال تشغيل محاولات حل متعددة واختيار أفضل نتيجة[5]. في المقابل، ورد في مواد OpenAI ذكر لنظام تجريبي يسمى GPT-03، والذي يُزعم أنه تمكن من تجاوز عتبة 70% على Verified مع توسيع نطاق الحوسبة بشكل كافٍ (بيانات غير رسمية)[5]. ومع ذلك، لا يوجد تحقق مستقل لهذه النتائج، ويظل هذا الرقم المرتفع معيارًا للأبحاث المستقبلية أكثر من كونه إنجازًا محققًا.

وفقًا لدراسة أجرتها Microsoft Research (2025)، حتى أحدث النماذج، عند تزويدها بأدوات تصحيح الأخطاء، لا تزال لا تتجاوز حاجز 50% من الإصلاحات الناجحة للأخطاء من SWE-bench Lite[6]. في هذا الاختبار، كان الأفضل هو Claude 3.7 Sonnet بنسبة ~48.4% من المهام المحلولة، بينما حل نظام قائم على GPT-4 (OpenAI 01) حوالي 30%، والنموذج الأخف وزنًا 03-mini لم يحل سوى 22%[6]. تؤكد هذه النتائج أنه على الرغم من التقدم السريع، لا تزال أنظمة الذكاء الاصطناعي الحالية أقل شأنًا من المبرمجين ذوي الخبرة: فبالنسبة للإنسان، لا يمثل حل مثل هذه المهام (مع فهم الشيفرة) صعوبة، بينما غالبًا ما يفشل النموذج في تطبيق أدوات تصحيح الأخطاء بفعالية أو يعاني من نقص في بيانات التدريب التي تعكس عملية إصلاح الأخطاء متعددة الخطوات[6].

القيود والآفاق المستقبلية

أصبح SWE-bench منصة موحدة لتقييم وكلاء البرمجة الأذكياء، ومع ذلك، كشفت الأبحاث أيضًا عن عدد من قيوده. المشكلة الرئيسية هي عدم اكتمال الاختبار: يتم أخذ مجموعة الاختبارات التحققية لكل مهمة من pull request معين، وعادةً ما تتضمن فقط اختبارات الوحدات التي تم تغييرها عند إصلاح الخطأ[3]. كما أظهر تحليل أجرته مجموعة من العلماء من جامعة تشجيانغ وجامعة شتوتغارت (Wang et al. 2025)، فإن تجاهل بقية اختبارات المشروع يمكن أن يخفي عدم صحة بعض الحلول[3]. كشفت إعادة فحص الحلول على المجموعة الكاملة من اختبارات المستودع أن ما متوسطه 7.8% من الباتشات التي تم تمييزها على أنها ناجحة في SWE-bench، في الواقع لا تجتاز اختبارات أخرى في المشروع[3]. يؤدي هذا إلى تضخيم مقياس "المهام المحلولة" بنحو 4-6 نقاط مئوية[3]. وهناك حالة أكثر دقة، وهي عندما يجتاز الباتش الذي تم إنشاؤه جميع الاختبارات الأصلية، ولكنه في نفس الوقت غير مكافئ لحل المطور ويغير سلوك البرنامج بطريقة غير متوقعة. باستخدام تقنية إنشاء حالات اختبار إضافية (منهجية PatchDiff)، كشف الباحثون أن ما يقرب من 30% من الإصلاحات المقترحة من قبل الذكاء الاصطناعي تتصرف بشكل مختلف عن الباتشات المرجعية، وأن حوالي 11% منها خاطئة بشكل قاطع، على الرغم من عدم اكتشافها بواسطة الاختبارات الحالية[3]. وبالتالي، قد يتم المبالغة في تقدير القدرات الحقيقية للنماذج إذا تم الاعتماد فقط على اجتياز مجموعة محدودة من الاختبارات. يقر منشئو SWE-bench بهذه الثغرة ويؤكدون أن المعيار يجب أن يتطور بمرور الوقت: يجب تحسين تغطية الاختبارات، وإضافة فحوصات لعدم وجود آثار جانبية غير مرغوب فيها، وتوسيع مجموعة أنواع المهام[7]. يعد تطوير مثل هذه الأدوات التقييمية جزءًا مهمًا من التحضير لظهور مطوري ذكاء اصطناعي أكثر استقلالية وقوة، وتُظهر تجربة SWE-bench الحاجة إلى الاهتمام الدقيق بجودة المعايير[7].

على الرغم من أن SWE-bench، كونه مجرد مجموعة ثابتة من المهام، لا يغطي جميع جوانب البرمجة تمامًا، إلا أنه أصبح بالفعل المعيار الفعلي (de-facto) للتحليل المقارن لنماذج الشيفرة[3]. يتم استخدامه في الأبحاث العلمية لعرض الأساليب والخوارزميات الجديدة، وكذلك من قبل فرق البحث الصناعية لتقييم إمكانات الأنظمة المصممة لأتمتة البرمجة[3]. يُظهر النمو المستمر للنتائج على SWE-bench خلال الفترة 2023-2025 بوضوح التحسن السريع في قدرات نماذج اللغة الكبيرة في حل مشكلات التطوير العملية. وفي الوقت نفسه، يعمل كمقياس للصعوبة: فحتى مع الاقتراب من حل 50-60% من المهام، لا تزال النماذج بعيدة عن أن تكون بديلاً كاملاً للإنسان، خاصة في ظل محدودية المعلومات والحاجة إلى فهم دقيق للمتطلبات[4][7]. ومع ذلك، فإن التقدم لا يتوقف — فبفضل مبادرات مثل SWE-bench، يرى المجتمع أهدافه وقيوده بوضوح، ويواصل التحرك نحو إنشاء مطور ذكاء اصطناعي متكامل، قادر على فهم وإصلاح الشيفرة البرمجية بشكل مستقل على مستوى خبير بشري[4][7].

روابط خارجية

مراجع

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

ملاحظات

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [١]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [٢]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [٣]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [٤]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [٥]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [٦]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [٧]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [٨]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [٩]
Retrieved from "https://systems-analysis.ru/int/index.php?title=SWE-bench_(benchmark)_—_معيار_SWE-bench&oldid=9046"