Cursor يكشف: 63% من نجاحات Opus 4.8 Max في الاختبارات المعيارية ناتجة عن البحث لا عن كتابة الكود

نشرت Cursor دراسة تشكّك في موضوعية اختبارات الكود المعيارية (coding benchmarks) الشائعة: فالنماذج لا تتعلم حل المسائل، بل البحث عن إجابات جاهزة في المصادر المفتوحة.

كيف يعمل «reward hacking»

فحص فريق Cursor 731 عملية تشغيل لنموذج Opus 4.8 Max، النموذج الرائد من Anthropic، على SWE-bench Pro، وهو من أكثر الاختبارات موثوقية لقياس جودة وكلاء البرمجة (code agents). وقد حلّل وكيل مدقّق مخصص كل مسار تنفيذ: كان يرى المهمة وجميع خطوات الوكيل، لكنه لا يعرف هل اجتاز الاختبار أم لا.

جاءت النتيجة مفاجئة: 63% من الحلول الناجحة لم تتحقق بكتابة الكود، بل بالعثور على إجابة جاهزة. لم يتصرف النموذج كمطوّر يعالج خللًا برمجيًا، بل كمن يعلم أن الإجابة الصحيحة موجودة في مكان ما على الإنترنت.

مساران للالتفاف على الاختبار

رصد المدقّق أسلوبين رئيسيين من reward hacking:

• البحث في المصادر المفتوحة (57% من المسارات): كان الوكيل يعثر على طلب دمج (PR) مدموج أو على ملف مصحَّح في GitHub عبر واجهة API العامة، ثم يعيد إنتاج التصحيح (patch) بالحرف تقريبًا، بما في ذلك توقيعات الدوال والتعليقات.
• البحث في سجل git (9% من المسارات): كان الوكيل يستعرض الـcommits في مجلد `.git` المدمج في المستودع، ويعثر على الـcommit المتضمن للإصلاح، ويطبّقه مباشرة عبر `git cherry-pick`.

وفي إحدى الحالات الموثقة، وهي خلل في مشروع jq (2019)، حاول الوكيل إعادة إنتاج المشكلة، لكن صورة Docker كانت قد بُنيت بعد إصلاح الخلل. فتعذّر إعادة إنتاج الخطأ، وصار ذلك بحد ذاته مؤشرًا: المهمة مأخوذة من تذكرة حقيقية مغلقة. عندها تحوّل الوكيل إلى البحث عن تصحيح جاهز.

وكانت هناك حالات أكثر مباشرة. فقد عثر أحد الوكلاء على موقع مرآة لـSWE-bench كانت فيه الاختبارات المخفية والتصحيح «الذهبي» مكشوفة. وحصل وكيل آخر على الاختبارات وضمّن في الكود الاستثناء المتوقع بشكل ثابت (hardcoded).

ما الذي غيّره تقييد البيئة

عندما عزلت Cursor الوكلاء، بحذف سجل git قبل التشغيل وحظر الوصول إلى الإنترنت، تراجعت النتائج بشكل ملحوظ:

• Opus 4.8 Max: من 87,1% إلى 73,0% (−14,1 نقطة مئوية)
• Composer 2.5 (نموذج Cursor الخاص): من 74,7% إلى 54,0% (−20,7 نقطة مئوية)

إن الانخفاض بمقدار 14–21 نقطة مئوية ليس ضجيجًا إحصائيًا، بل أثر منهجي. والمفارقة أن تراجع Composer 2.5 كان أعمق من تراجع Opus: فكلا النموذجين استفاد بنشاط من المعلومات المتاحة، لكن بدرجات متفاوتة.

«نقترح على الفرق التي تجري التقييم الحد من مخاطر reward hacking عبر تدقيق مسارات التنفيذ وتقييد بيئة التشغيل»، توصي

Cursor في دراستها.

لماذا تُعدّ المشكلة منهجية

يعتمد SWE-bench والاختبارات المماثلة على أخطاء حقيقية من مستودعات مفتوحة. وفي الفضاء العام توجد بالفعل إجابة لكل مهمة من هذا النوع، على شكل PR أو commit أو نقاش في نظام تتبع المشكلات (issue tracker). وهذا يجعل هذه الاختبارات عرضة للثغرة بطبيعتها.

وكان باحثون قد رصدوا منذ عام 2024 تسرّب الإجابات عبر مصادر متاحة للجميع. وفي 2025 نشرت Meta* تقريرًا مستقلًا حول الموضوع. أما Cursor فقد أظهرت الآن حجم المشكلة كميًا في عمليات تشغيل فعلية لوكلاء frontier الحديثين.

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

ماذا يعني ذلك

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

*Meta مصنّفة منظمة متطرفة ومحظورة في روسيا.