شراكة بين IBM وKaggle لإطلاق لوحة متصدرين مستمرة لعمليات الترحيل في ScarfBench

أفادت مذكرة فنية من IBM Research نُشرت في 27 أكتوبر 2026 بأن IBM وKaggle تتعاونان لإطلاق لوحة متصدرين عامة تُحدَّث باستمرار لمعيار ScarfBench، وهو معيار IBM المفتوح لتقييم وكلاء البرمجة في عمليات ترحيل أطر عمل Java المؤسسية.

ScarfBench، وهو اختصار لعبارة «معيار إعادة هيكلة التطبيقات المستقلة»، يختبر قدرة الوكيل على التعامل مع تطبيق مؤسسي غير مألوف بلغة Java، وترحيله بين أطر Jakarta EE وQuarkus وSpring، مع ضمان استمرار عمل البرنامج بعد الترحيل. ويتحقق المعيار من أن التطبيقات المُنشأة تُبنى وتبدأ وتواصل العمل كما هو متوقع، باستخدام أحمال عمل مركزة وتطبيقات كاملة على حد سواء. وقد طرحت IBM معيار ScarfBench في وقت سابق من عام 2026 بوصفه معيارًا قابلًا لإعادة الإنتاج لعمليات الترحيل المدعومة بالذكاء الاصطناعي؛ وتناول الإعلان الأصلي، المنشور في 11 مارس 2026، سبعة مكونات، من بينها تطبيقات مؤسسية تحقّق مطورون من عملها ضمن أطر العمل الثلاثة، وأحمال عمل مركزة تعزل جوانب مثل سلوك الاستمرارية وحقن التبعيات، وتطبيقات كاملة تجمع طبقات معمارية متعددة، والتحقق الآلي من البناء وبدء التشغيل، واختبارات سلوكية تتحقق من سلوك وقت التشغيل والتكافؤ الوظيفي. وذكر الإعلان أن مطورين ذوي خبرة نفّذوا كل حمل عمل يدويًا وتحققوا منه، للتأكد من التكافؤ الوظيفي والاستخدام المألوف لأطر العمل.

التعاون بين IBM وKaggle

في إطار الشراكة، استشارت Kaggle شركة IBM بشأن تصميم المعيار والتقييم، وأعادت إنتاج ScarfBench وتشغيله بصورة مستقلة على منصتها الخاصة، مع رعاية تكاليف الحوسبة، كما ستتولى صيانة المعيار على المدى الطويل. ووصفت IBM نقاط قوة الفريقين بأنها متكاملة: فقد طوّرت ScarfBench لتحديث تطبيقات Java المؤسسية، فيما توفر Kaggle بنية تحتية مستقلة للتقييم وصيانة مستمرة للوحة المتصدرين.

النتائج عبر 204 مهمة ترحيل

يقيّم ScarfBench نظامًا قائمًا على الوكلاء، لا نموذجًا لغويًا منفردًا؛ إذ تعكس كل نتيجة اقتران نموذج بإطار عمل لوكيل برمجي يحدد كيفية تفاعل النموذج مع مستودع الشيفرة وبيئة التطوير. ونبّهت IBM إلى ضرورة قراءة النتائج على أنها نتائج للنموذج وإطار الوكيل معًا، لا قياسات للنموذج الأساسي وحده.

في 204 مهام ترحيل وعشرة إعدادات جرى تقييمها تجمع بين نموذج وإطار وكيل، تصدّر Gemini 4 Argon، باستخدام إطار Antigravity، المقياس الأساسي لاختبارات الدخان بنسبة 75.2%، وفقًا لما أوردته IBM. وجاء بعده Claude Opus 5.5 مع Claude Code بنسبة 70.5%، ثم Claude Opus 5 مع Claude Code بنسبة 69.8%. وتُستخدم درجة اختبارات الدخان مقياسًا للوحة المتصدرين؛ وهي تمنح درجات جزئية وتولي وزنًا أكبر لمجموعات الاختبار الأوسع. أما وفق المقياس الأكثر صرامة، أي اجتياز جميع الاختبارات، فسجّل Claude Opus 5.5 مع Claude Code أعلى معدل، بلغ 72.1%، متقدمًا بفارق ضئيل على Gemini 4 Argon مع Antigravity، الذي حقق 71.1%.

بحسب المنشور، ظل الترتيب في الصدارة على حاله عند إجراء تحليل الحساسية. ولم تحصل أربع من أصل 204 مهام على أي رصيد في الاختبارات السلوكية من أي إعداد؛ وقد أدى استبعادها إلى رفع الدرجات المطلقة من دون تغيير المتصدرين: إذ سجل Gemini 4 Argon مع Antigravity نسبة 79.4%، تلاه Claude Opus 5.5 مع Claude Code بنسبة 74.5%، ثم Claude Opus 5 مع Claude Code بنسبة 73.7%. وأشارت IBM إلى أن المجال لا يزال واسعًا للتحسن حتى مع أقوى توليفة، إذ لم ينجح أي إعداد في اجتياز أكثر من نحو ثلاثة أرباع عمليات الترحيل بالكامل.

مواضع نجاح الإعدادات وإخفاقها

أفادت IBM بأن أكبر فجوة في التقييم كانت بين الشيفرة التي تُبنى والبرمجيات التي تعمل على النحو الصحيح. وبعد استبعاد المهام الأربع التي لم تحرز فيها أي إعدادات نقاطًا، نجح كل من Claude Opus 5 مع Claude Code، وGemini 4 Argon مع Antigravity، وGemini 3.8 Flash مع mini-swe في بناء 100% من المهام، كما نجحت ثمانية من الإعدادات العشرة في بناء 97% منها على الأقل. في المقابل، تجاوز الفارق بين درجات اختبارات الدخان 50 نقطة. ومن بين التطبيقات التي نُشرت بنجاح، تراوحت نسبة اجتياز الاختبارات بالكامل في الإعدادات المتصدرة بين نحو 63% و76%، بينما تراجعت النسبة إلى 53% لدى Kimi K3 مع kimi-code، وإلى 42% لدى Gemini 3.1 Pro مع OpenHands، وإلى 26% لدى Gemma 4 26B-A4B مع mini-swe.

صنّفت IBM عدد 745 تشغيلًا فاشلًا: كان 535 منها، أي نحو 72%، إخفاقات سلوكية في وقت التشغيل، حيث بُني التطبيق وغالبًا ما بدأ تشغيله، لكنه أخفق في التحقق السلوكي. وشملت هذه المجموعة 304 حالات عدم تطابق في المحتوى أو التأكيدات، و210 حالات فقدان لمسار أو ظهور خطأ 404، و21 خطأً صريحًا من نوع HTTP 500 أو 405. وشكّلت إخفاقات الترجمة أو التغليف نحو 20% من عمليات التشغيل الفاشلة، بواقع 152 حالة، فيما بلغت حالات التعطل عند بدء التشغيل أو بسبب حقن التبعيات نحو 8%، بواقع 58 حالة.

يعرض المنشور أمثلة على مستوى المهام. ففي concurrency-taskcreator-quarkus-to-jakarta، سجّل Claude Opus 5 مع Claude Code نتيجة 0/6، بعدما أعادت نقطة النهاية /taskinfo عبارة «لم يُعثر على الملف» وأخفق اختبار يتوقع استجابة HTTP 405. وفي address-book-jakarta-to-quarkus، سجّل GPT-6 Astra مع Codex نتيجة 2/10، بعدما أعادت صفحتا القائمة والإنشاء استجابة HTTP 404. وفي cargotracker-jakarta-to-spring، أبقى Gemini 3.8 Flash مع mini-swe على إعدادات JSF/JoinFaces في التطبيق المستهدف على Spring Boot، وأخفق أثناء بدء التشغيل عند إنشاء مكوّن facesContext. أما في cart-spring-to-jakarta، فقد أخفق النشر باستخدام GPT-6 Astra مع Codex لأن نوع التغليف الذي خلّفته عملية الترحيل لم يكن مدعومًا في بيئة تشغيل Liberty المستهدفة.

أفادت IBM بأن الكفاءة تفاوتت أيضًا باختلاف الإعدادات. ففي المهام الـ200 المتبقية بعد استبعاد المهام وفقًا لتحليل الحساسية، تراوح وسيط عدد الجولات بين 32 مع Claude Opus 5 وClaude Code و79 مع Gemini 3.8 Flash وmini-swe، بينما بلغ 64 مع Claude Opus 5.5 وClaude Code. وفي الحالات التي أبلغت فيها أطر التشغيل عن التكلفة، وشملت إعدادات Claude Code وCodex وmini-swe وkimi-code، تراوحت تكلفة كل مهمة محلولة بين 1.25 دولارًا مع GPT-6.1 Sol وCodex و10.10 دولارات مع Claude Opus 5.5 وClaude Code؛ أما أطر Antigravity وqwen-code وOpenHands، فلم تُصدر أرقامًا للتكلفة لكل تشغيل.

تتيح لوحة صدارة ScarfBench عرضًا عامًا لهذه النتائج. ولن يكون تقديم النماذج علنًا متاحًا عند الإطلاق، لكن IBM قالت إن ذلك مدرج ضمن خططها.