من جداول الترتيب إلى ملفات السلوك: كيف قيّمت JetBrains نماذج الذكاء الاصطناعي للبرمجة الوكيلة

نشرت JetBrains في 30 أغسطس 2026 تحليلاً لمنهجية تقييم نماذج اللغة الكبيرة المستخدمة داخل وكيل البرمجة Junie، داعية إلى تجاوز الاعتماد على مؤشر واحد هو «معدل الحل» (resolve rate). وترى الشركة أن معرفة ما إذا كان الوكيل قد اجتاز اختبارات المهمة مهمة، لكنها لا تكشف وحدها كيف وصل إلى النتيجة، وكم كلف ذلك، وما إذا كانت الرقعة البرمجية محدودة وقابلة للصيانة.

تستند الفكرة إلى مقارنة أجرتها JetBrains بين Claude Opus 4.7 وGemini 3.5 Flash على معيار خاص بها. حل النموذجان العدد نفسه من المهام، لكن Opus احتاج في المتوسط إلى 184 خطوة وبلغت تكلفة التشغيل 2.79 دولاراً، مقابل 271 خطوة و1.24 دولار لـGemini. النتيجة النهائية المتطابقة لم تعكس اختلافاً واضحاً في مسار التنفيذ أو كفاءة استخدام الأدوات.

ما الذي يخفيه معدل الحل؟

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

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

من النتيجة إلى مسار الوصول إليها

اختبرت JetBrains المنهجية على أربعة معايير تضم 523 مهمة عند مقارنة Claude Opus 4.7 وGemini 3.5 Flash. حل Opus عدد 267 مهمة، بمعدل 51.1%، بينما حل Gemini عدد 254 مهمة، بمعدل 48.6%. وتطابقت النتيجة في 430 مهمة: نجح النموذجان معاً في 214 مهمة وفشلا معاً في 216 مهمة. أما الفارق الفعلي فظهر في 93 مهمة فقط، ما يجعل الفروق السلوكية أكثر أهمية من الفارق الخام في جدول الترتيب.

في مثال لمهمة واحدة نجح فيها النموذجان، بدأ كلاهما بفتح ملف ذي صلة في الخطوة 15، وتوصل إلى السبب الجذري، وأجرى تحققاً شاملاً. لكن Opus استخدم بحثاً أكثر استهدافاً وبدأ التنفيذ بعد 13 خطوة، وأنهى المهمة في 53 خطوة مع ست انتقالات بين الاستكشاف والتنفيذ والتحقق. أما Gemini ففحص الوحدة الكبيرة على نطاق أوسع، وأجرى أول فحص قابل للتنفيذ في الخطوة 30، ولم ينفذ أول تعديل على شيفرة الإنتاج حتى الخطوة 88، ثم احتاج إلى 192 خطوة و34 انتقالاً بين المراحل.

نجح النموذجان في الاختبارات، وعدّلا الملف والرموز نفسيهما اللذين عدلتهما الرقعة المرجعية. لكن Opus لم يلمس ملفات أخرى، في حين امتدت رقعة Gemini إلى أربعة ملفات إضافية، ووصفتها عملية التقييم بأنها واسعة وتتضمن تكراراً ملحوظاً وبعض الهلوسة. وتؤكد JetBrains أن هذا المثال توضيحي وليس نتيجة إحصائية مستقلة.

الفشل ليس حالة واحدة

أظهر تحليل المهام الـ216 التي فشل فيها النموذجان معاً أن أكثر من 85% من الحالات تضمنت، وفق التقييم، تحديداً كاملاً أو جزئياً للسبب الجذري. في إحدى الحالات فهم الوكيلان أن تجاوز النص لحد الرموز تسبب في الخطأ، لكنهما اقتراحا اقتطاع النص بدلاً من تقسيمه إلى أجزاء صحيحة. وفي حالة أخرى أصلحا معامل تنزيل في مسار واحد وفاتا المشكلة نفسها في مسار مرافق.

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

ملفات سلوكية بدلاً من ترتيب واحد

استنتجت JetBrains أن Claude Opus 4.7 كان أكثر ميلاً إلى تحديد السبب الكامن وراء العيوب الغامضة، وحل 53 مهمة أخفق فيها Gemini. لكن 123 من تشغيلاته لم تتضمن أي تحقق قابل للتنفيذ، منها 68 مهمة اعتُبرت محلولة. وترى الشركة أن هذا السلوك قد يترك مخاطر غير مكتشفة تتعلق بالانحدارات أو الحالات الطرفية.

في المقابل، كان Gemini 3.5 Flash أكثر ميلاً إلى تشغيل فحص قابل للتنفيذ واستخدام نتيجته لتحسين الحل عندما يكون السلوك المتوقع واضحاً والمكوّن المسؤول محدداً نسبياً. إلا أنه أظهر مشكلات في التقارب مع الحل وفي الارتكاز إلى المستودع؛ إذ كرر عمليات بحث أو أوامر مكافئة، وقضى خطوات كثيرة على بنية البناء، وكان أكثر اعتماداً على واجهات أو تبعيات أو مسارات أو تجهيزات اختبار غير موثقة. وصُنفت 195 من تشغيلاته، أي 37.3%، على أنها تتضمن هلوسة متوسطة أو شديدة، مقابل 130 لـOpus. كما أظهرت 80 عملية لديه، أو 15.3%، تكراراً كبيراً أو شديداً، مقابل 6.5% لـOpus.

ماذا يعني ذلك عملياً؟

في مقارنة أوسع شملت GPT-5.5 وClaude Opus 4.7 وGemini 3.5 Flash وQwen 3.6 27B FP8 على 522 مهمة مشتركة، حقق GPT-5.5 أعلى معدل حل عند 51.5%، وكان النموذج الوحيد الذي شغّل فحصاً قابلاً للتنفيذ في كل مرة. وتصدر Opus مؤشرات جودة الرقعة، بينما حل Qwen 3.6 27B FP8 نسبة 38.9% من المهام بتكلفة تشغيل تعادل 3% من تكلفة GPT-5.5.

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

تحذر JetBrains من تعميم الملفات السلوكية على النماذج نفسها، لأن النتائج اعتمدت على بنية Junie المحددة. كما أن أحكام المقيمين المعتمدين على نماذج لغة كبيرة ليست «حقيقة مرجعية»، وهي تتأثر بدرجة كبيرة برقعة ذهبية واحدة، مع أن الحلول الصحيحة قد تستخدم ملفات أو طبقات معمارية مختلفة. لذلك يظل معدل الحل أساساً ضرورياً، لكن قيمته تزداد عندما يُرفق بأدلة عن الكفاءة، وجودة التعديل، ومسار العمل، بدلاً من اختزاله في ترتيب إجمالي واحد.