تصنيف نماذج الذكاء الاصطناعي للبرمجة

تقديرات تحريرية — وليست نتائج SWE-bench رسمية

هذه القيم تقديرات تحريرية من benchr، محددة في حقل benchmarks_estimated داخل models.json. تُعرض لسياق التخطيط فقط، بلا ترتيب وبلا حساب «الجودة لكل دولار».

ما الذي يقيسه SWE-bench Verified فعلاً

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

لا يقيس البنشمارك السرعة أو زمن الاستجابة أو المهام غير البرمجية أو أداء النموذج تحت مراجعة مطوّر مستمرة. قد ينجح نموذج أقل درجة في بيئة يراجع فيها المطوّر كل تعديل، بينما تفيد الدرجة الأعلى أكثر في المسارات المستقلة.

قراءة التصنيف: بُعد التكلفة

في جدول النتائج المنشورة من المزوّدين، يقسم عمود «الجودة لكل دولار» نتيجة SWE-bench المنشورة على سعر الإدخال المدرج. وهو مرشّح مشتق بسيط لا تنبؤ بتكلفة الإنتاج. وتُستبعد التقديرات التحريرية من الترتيب ومن هذا الحساب.

للإصلاح المستقل للأكواد على نطاق واسع، السؤال المهم ليس فقط «من يحقق أعلى درجة» بل «عند أي معدل فشل تكلّف فجوة الجودة أكثر من فجوة السعر». راجع مقارنة GPT-5 مقابل Opus 4.8 لذلك التحليل.

المنهجية

لا يضم الجدول المرتّب إلا النتائج المسجلة في البيانات كأرقام منشورة من المزوّد. وحين لا تتوفر نتيجة منشورة قابلة للمقارنة، يظهر تقدير benchr التحريري — إن وُجد — في جدول منفصل غير مرتّب وبوسم ظاهر. ولا يدّعي الموقع امتلاك أدلة خاصة أو «تقييمات داخلية» غير منشورة.

كيف تتحقق من نموذج برمجة قبل التبديل

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

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

لماذا تهم ملاءمة المستودع

تتفاوت نماذج البرمجة حسب اللغة، وحجم المستودع، وجودة الاختبارات، ومقدار السياق المحيط الذي تحتاجه. قد تخفي درجة البنشمارك تلك الفروق. قبل نقل الحركة، اختر عينة من مشكلات مستودعاتك الخاصة: خطأ بسيط واحد، ومشكلة اعتمادية واحدة، وإعادة هيكلة واحدة، واختبار فاشل واحد بسجلات مضلِّلة، ومشكلة واحدة تتطلب قراءة الوثائق. هذه المجموعة الصغيرة تكشف أنماط الفشل أسرع من تصنيف عام.

تحقق أيضاً من سلوك الأدوات. بعض النماذج تكتب إصلاحات ممتازة لكنها تتعثر مع أوامر الطرفية، أو التنقل بين الملفات، أو رسائل الـ commit الموجزة. إذا كان وكيل البرمجة لديك يعتمد على تلك السلوكيات، فقيّم سير العمل الكامل بدل الإصلاح النهائي فقط.

نقطة عملية أخيرة: احتفظ بمجموعة انحدار صغيرة بعد اختيار نموذج. قد تغيّر نماذج البرمجة سلوكها حين يُحدّث المزوّدون التوجيه، أو إعدادات الاستدلال، أو أسماء النماذج البديلة. إعادة تشغيل شهرية على نفس المشكلات ستخبرك هل ما زال النموذج يستحق مكانه في خط إنتاجك.