FrontierCS 2 يختبر 12 وكيل ذكاء اصطناعي في مهام البحث والتطوير: الأفضل اجتاز 58%

يطرح معيار FrontierCS 2 سؤالًا تتجنبه الصناعة عادةً: هل يستطيع وكيل LLM أن يقدّم مساهمة تستحق نشر ورقة علمية، لا أن يحل مسألة تعليمية فحسب؟ تتألف المجموعة من 48 مهمة مفتوحة في 13 مجالًا. ومن بين 12 وكيلًا خضعوا للاختبار، يجتاز الأفضل، Claude Opus 5.5، 58% من عمليات تشغيله. وفي 16 مهمة لم تنجح أي عملية تشغيل، أي أن النتيجة صفرية في ثلث المجموعة.

كيف تتحول الورقة العلمية إلى امتحان

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

يتلقى الوكيل مستودعًا يعمل لكن دون الجزء الأساسي، وعليه أن يستعيده أو يتفوق عليه. تغطي المهام 13 مجالًا، منها أنظمة تعلّم الآلة والحوسبة عالية الأداء وقواعد البيانات والأمن والروبوتات وغيرها. وإلى جانب المهام الـ48 المنشورة، لدى FrontierCS 2 مجموعة مغلقة تضم أكثر من 100 مهمة سيُعلن عنها لاحقًا. وهي حماية من الإفراط في التكيّف مع المعيار العام: فما لم يره الوكيل لا يمكنه ضبط أدائه عليه.

بيئة بحثية بدل محاولة واحدة

كانت المعايير المفتوحة السابقة تعطي الوكيل نص المسألة وتقيّم برنامجًا واحدًا بعد انتهاء التشغيل. أما FrontierCS 2 فيغيّر الصيغة: يعمل الوكيل داخل بيئة بحثية ويمكنه إرسال تصحيح (patch) في أي لحظة. وعن كل تصحيح يعيد الحَكَم تقييمًا على مجموعة التطوير (development)، أي إشارة يمكن بها تحسين الحل تدريجيًا، كما يفعل الإنسان.

وفي الوقت نفسه يظل المقيّم نفسه ومجموعة الاختبارات النهائية المؤجلة والحل المرجعي مغلقة. يُفحص الإرسال النهائي على مجموعة مخفية ويُقارن بالمرجع. يمكن للوكيل أن يكيّف حله مع المقياس الظاهر، لكن الفحص سيجري على بيانات لم يطّلع عليها.

الدرجة العالية لا تعني الاجتياز

أهم ما في النتائج ليس رقم 58%، بل الفرق بين الدرجة والاجتياز. فمعظم عمليات التشغيل التي تفوقت على المرجع في مجموع الدرجة النهائية لم تجتز مع ذلك، إذ أخفقت في مقياس منفرد أو في حِمل عمل منفرد. وهذه صورة مألوفة في أعمال الأنظمة. فتحسين قاعدة بيانات أو نواة HPC يسرّع سيناريو ويُفسد آخر لا فائدة منه في بيئة الإنتاج، والمعيار يأخذ ذلك في الحسبان.

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

المعطيات الرئيسية

• 48 مهمة مفتوحة في 13 مجالًا، إضافة إلى مجموعة مغلقة من أكثر من 100 مهمة
• 12 وكيلًا خضعوا للاختبار
• أفضل نتيجة: Claude Opus 5.5، بنسبة 58% من عمليات التشغيل المجتازة
• 16 مهمة لم تنجح فيها أي عملية تشغيل
• يستطيع الوكيل إرسال التصحيحات في أي لحظة ويحصل على تقييم على مجموعة التطوير
• المقيّم ومجموعة الاختبارات النهائية والمرجع مخفية عن الوكيل

ما الذي ينبغي أن تنتبه إليه الفرق التي تبني الوكلاء

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