فصل الإشارة عن الضجيج في تقييمات البرمجة

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

لقد حققنا مؤخرًا في كيف أن أحد أكثر معايير البرمجة استخدامًا على نطاق واسع، وهو SWE-bench Verified، كانت لديه عيوب هيكلية ومشكلات جوهرية في تداخل البيانات، ووجدنا أن التقييم لم يعد يوفر إشارةً ذات معنى بشأن قدرات تطوير البرمجيات. في ذلك الوقت، شجعنا المجتمع الأوسع على الانتقال إلى SWE-Bench Pro.

صُمم SWE-Bench Pro⁠(يفتح في نافذة جديدة) لتحسين SWE-bench Verified عبر اختبار النماذج على آفاق زمنية أطول ومهام برمجية أكثر واقعية، بهدف تتبع قدرات البرمجة الوكيلة بشكل أفضل. وكما في SWE-bench Verified، تُستمد المهام برمجيًا من سجل تغييرات الميزات في مجموعة من المستودعات العامة والخاصة. يُطلب من النماذج تنفيذ حل يجتاز اختبارات جديدة لميزة ما، من دون تخطي الوظائف القائمة. في التقسيم العام المؤلف من 731 مهمة، تحسنت النماذج الرائدة من معدل اجتياز قدره 23.3% إلى 80.3% خلال ثمانية أشهر.

ومنذ ذلك الوقت، تدقيقًا مماثلاً على SWE-Bench Pro، حيث قمنا بمراجعة مجموعة البيانات باستخدام منظومة برمجية لتحليل نقاط البيانات. وراجعت هذه المنظومة محاولات النموذج لإنجاز المهمة، وبيانات تعريف المهمة، وآثار الفشل، لرصد عيوب تقييم محتملة. ثم قُيّمت كل مهمة مرصودة عبر عدة جولات يجريها محققون وكلاء، وخضعت لمراجعة مستقلة من خمسة مهندسي برمجيات متمرسين، مع إحالة نقاط الخلاف لمزيد من التحقيق.

اندَرَجت المشكلات أساسًا في أربع فئات:

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

تشير نتائجنا إلى صعوبة إعداد معايير صعبة لكنها عادلة، وإلى تزايد فائدة الوكلاء في إجراء فحوصات قابلة للتوسع لجودة البيانات. في ضوء هذه النتائج، نقدر أن نحو 30% من مهام SWE-bench Pro معطوبة، وننصح مطوري النماذج بفحص النتائج بعناية.

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

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

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

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

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

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

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

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

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

نأمل أن يطور مجتمع التقييم الأوسع معايير جديدة يبنيها مطورو برمجيات متمرسون خصيصًا لاختبار قدرات النماذج. يمكن لهذا النهج أن يحافظ على المعيار العالي والواقعية اللذين نريد بهما قياس قدرات النماذج، كما يتيح إشرافًا بشريًا أفضل طوال العملية. نظرًا إلى المشكلات التي كشفها هذا التحليل، فإننا نسحب توصيتنا السابقة باعتماد SWE-Bench Pro.

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