Benchmark · agentic
Multi-SWE-bench
يقيس Multi-SWE-bench ما إذا كان وكيل برمجة يعتمد على الذكاء الاصطناعي قادرًا على حل مشكلات (issues) حقيقية من GitHub عبر العديد من المستودعات ولغات البرمجة، وليس Python فقط. المقياس الرئيسي هو معدل الحل (resolution rate): النسبة المئوية لعينات المهام التي يجعل إصلاحها مجموعة الاختبارات المخفية تنجح.
اقرأ المزيد
- مثال
- مهمة تمثيلية: بالنظر إلى تقرير خطأ حقيقي أو طلب ميزة من مشروع مفتوح المصدر مكتوب بلغة مثل Java أو Go أو Rust أو TypeScript أو JavaScript أو C أو C++، إلى جانب المستودع المسحوب عند الـ commit السابق للإصلاح، يجب على الوكيل إنتاج تصحيح (patch) برمجي يحل المشكلة الموصوفة.
- طريقة التقييم
- تُقيَّم كل عينة على أساس نجاح/فشل عبر التنفيذ. يُطبَّق تصحيح الوكيل على المستودع وتُشغَّل اختبارات المشروع؛ وتُعدّ العينة محلولة فقط إذا نجحت الآن اختبارات FAIL_TO_PASS المحددة وظلّت جميع اختبارات PASS_TO_PASS ناجحة. الدرجة المُبلَّغ عنها هي معدل الحل (العينات المحلولة ÷ الإجمالي)، عادةً عند pass@1، ويمكن تفصيلها حسب اللغة وحسب الصعوبة المُوسومة من الخبراء (easy/medium/hard).
- التحقق
- القبول قائم كليًا على التنفيذ داخل صورة Docker خاصة بكل عينة تعيد إنتاج سلسلة أدوات اللغة والاعتماديات بدقة. يجب أن يُطبَّق التصحيح المُولَّد دون تعارض، ثم تُشغَّل اختبارات fail-to-pass وpass-to-pass؛ لا يوجد تقييم بواسطة نموذج لغوي (LLM) ولا مقارنة نصية بتصحيح المطوّر المرجعي.
- لماذا يهم
- كان SWE-bench مؤثرًا لكنه يقتصر على Python، في حين أن هندسة البرمجيات الواقعية تمتد عبر لغات عديدة. يختبر Multi-SWE-bench ما إذا كانت وكلاء البرمجة تعمّم عبر اللغات على مشكلات أصيلة، مع وسوم صعوبة من الخبراء، مما يمنح إشارة أصعب وأكثر واقعية وأقل تشبّعًا للقدرة العملية على هندسة البرمجيات.
مثال محلول
المهمة
عينة توضيحية بتنسيق Multi-SWE-bench — اللغة: Go، مكتبة صغيرة لمجموعات عامة (generic). problem_statement: «تُرجِع Stack.Pop() على مكدس فارغ القيمة الصفرية مع خطأ nil، مما يُخفي بصمت أخطاء المُستدعي؛ وينبغي بدلًا من ذلك أن تُرجِع القيمة الحارسة ErrEmpty.» يُعطى لك المستودع عند الـ commit الأساسي المعطوب والاختبار الفاشل. FAIL_TO_PASS: TestPopEmptyReturnsError. PASS_TO_PASS: TestPushThenPop، TestLen. قدّم تصحيحًا يجعل الاختبار الفاشل ينجح دون كسر الاختبارات الناجحة.
الحل
--- a/stack.go
+++ b/stack.go
@@ func (s *Stack[T]) Pop() (T, error) {
+ if len(s.items) == 0 {
+ var zero T
+ return zero, ErrEmpty
+ }
n := len(s.items)
v := s.items[n-1]
s.items = s.items[:n-1]
return v, nil
}الشرح
يضيف الإصلاح إلى Pop فحصًا للفراغ يُرجِع القيمة الحارسة ErrEmpty (مع القيمة الصفرية للنوع) تمامًا كما يتوقع TestPopEmptyReturnsError، مع ترك مسار الإخراج الطبيعي دون تغيير كي يستمر نجاح TestPushThenPop وTestLen. التقييم قائم بحتًا على التنفيذ: يطبّق الهيكل (harness) التصحيح في صورة Docker الخاصة بالعينة ويَسِم العينة كمحلولة فقط إذا تحوّل اختبار FAIL_TO_PASS إلى النجاح ولم يتراجع أي اختبار PASS_TO_PASS.
لا توجد درجات موثّقة لهذا الـ Benchmark بعد.