معيار Alibaba الجديد: وكلاء الذكاء الاصطناعي ينجزون جزءًا من المتطلبات لا المهمة كاملة

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

مهام من جلسات حقيقية لا من بيانات اصطناعية

يُبنى كثير من اختبارات وكلاء البرمجة بصورة اصطناعية: تُكسر صفحة مرجعية ويُطلب إصلاحها، أو تُعطى مجموعة تعديلات محددة مسبقًا. اختار مؤلفو Co-Design Bench طريقًا مختلفًا. فقد أخذوا طلبات من جلسات مستخدمين حقيقية، وحذفوا المكرر منها، وأبقوا ما فيه ما يمكن التحقق منه. وأعادوا لكل مهمة بناء التطبيق القابل للتشغيل بحالته «قبل التعديل»، إضافة إلى سجل الجلسة والمرفقات.

يتضمن الاختبار مسارين:

• Multimodal Editing (ME) — تعديلات محلية: التنسيق والبنية والمحتوى. يملك الوكيل صفحة ومنطقة محددة وطلبًا، وأحيانًا مع صورة أو مقطع صوتي أو فيديو أو مستند. مثال: يظهر في إيصال مبلغ، ويجب تحديثه بصورة متسقة في الجدول وفي الملخصات النهائية. • Repository Editing (RE) — تغييرات متسقة في مستودع الواجهة الأمامية: المكوّنات والمسارات (routes) والحالة (state) وتدفق البيانات. مثال: محرر لمقاطع الفيديو الرياضية، يجب فيه تحديد عدد المقاطع ومدتها، ومحاذاة الخط الزمني (timeline) عند تغيير مقياس العرض، وإعادة تفعيل الإدراج بعد حذف مقطع أو تقسيمه.

تُقيَّم المهام في ثلاثة اتجاهات: فهم السياق (Grounded Understanding)، وتحويل الواجهة (UI Transformation)، وتنفيذ الوظائف (Functional Implementation).

قبل إدراج التطبيق في المجموعة، يجب أن يُبنى ويعمل داخل حاوية ويُعرض في Playwright (أداة لأتمتة المتصفح). واستُبعدت المهام التي تحتاج إلى خدمات خارجية غير متاحة. ورُتّبت الطلبات بحسب الصعوبة وقابلية التحقق ومؤشرات إخفاقات سابقة، مثل إعادة الصياغة والتراجع عن التعديلات. بعد ذلك صاغ الخبراء الطلبات بوضوح وكتبوا معايير القبول المخفية.

كيف يجري التحقق دون شيفرة مرجعية

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

يجري التحقق على عدة خطوات:

• أولًا، ينظر وكيل المقيِّم إلى التطبيق النهائي: الفرق في الشيفرة المصدرية، والصفحات المعروضة، والإجراءات المسجّلة في المتصفح. ولا يثبت المعالج (handler) الموجود في الشيفرة شيئًا إذا كان المستخدم لا يستطيع الوصول إليه عبر الواجهة. • بعد ذلك يتلقى مدقّق LLM منفصل الأحكام والأدلة المجمّعة ويحاول دحضها. فيبحث عن الشيفرات الوهمية (stubs)، والإجابات المضمّنة في الشيفرة، ونقاط الدخول التي لا يمكن الوصول إليها، والأعطال عند مدخلات أخرى، وحالات عدم المطابقة للطلب. • يشترط التدقيق الإلزامي نجاح العرض ووجود لقطات شاشة للادعاءات البصرية، وسجلات إجراءات المتصفح للادعاءات التفاعلية. وإذا غابت الأدلة، يُوقف التقييم قبل احتساب النقاط.

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

ماذا أظهرت النماذج العشرة

شُغّلت عشرة نقاط نهاية (endpoints) لنماذج عبر منظومة وكلاء موحّدة: يستطيع الوكيل الاطلاع على الشيفرة وتعديل الملفات وبناء التطبيق وتشغيله. وتُستخلص من النتائج عدة خلاصات.

• تتباعد بوضوح نسبة المعايير المنفّذة عن نسبة المهام المحلولة بالكامل. فالمستخدم الذي نُفّذ له معظم طلبه يظل يحصل على سيناريو لا يعمل. • يختلف ترتيب النماذج بين المسارين: فالأفضل في التعديلات المحلية ليس بالضرورة الأفضل في تعديلات المستودع. • لدى النماذج العشرة جميعها، تكون اكتمالية التنفيذ أسوأ في مهام المستودع التي تضم ثلاثة أو أربعة أنواع من التغييرات (البنية والأسلوب والتفاعلية والمحتوى) منها في المهام التي تضم نوعًا أو نوعين.

وأظهر المؤلفون بشكل منفصل أن نمط التشغيل يغيّر التقييم. ففي مهام WebCompass-edit، رفع الانتقال من محاولة واحدة إلى النمط الوكيلي المزوّد بأدوات متوسط نسبة الوظائف المنفّذة بوضوح، مع أن معيار التقييم (rubric) والمحكِّم والعرض بقيت كما هي. ومعنى ذلك أن أرقام الاختبارات التي تعتمد أنماط تشغيل مختلفة لا يمكن مقارنتها مباشرة.

ويقارن المؤلفون Co-Design Bench بمعايير أخرى. فـ Design2Code وWebSight-Test وWebRenderBench تختبر تحويل لقطة الشاشة إلى شيفرة. ويضيف IWR-Bench فيديو التفاعل. ويختبر WebGen-Bench وFrontendBench مواقع أُنشئت من الصفر. أما DesignBench وMT-Web2Code وWebCompass وFronTalk فتتناول التعديلات والحوار. وتأخذ SWE-bench وSWE-bench Multimodal وSWE-Lancer مهامها من GitHub والعمل الحر. وتكمن جِدّة Co-Design Bench في الجمع بين الجلسات الحقيقية والمرفقات متعددة الوسائط وحالة المصدر القابلة للتشغيل والتحقق دون مرجع والمدقّق الخصامي.

أما بالنسبة إلى الفرق التي تعتمد وكلاء البرمجة، فالخلاصة عملية. فمقياس «نسبة البنود المجتازة» يبالغ في تقدير الجاهزية: الأهم احتساب نسبة المهام المنجزة بالكامل، والنظر بصورة منفصلة إلى التعديلات المعقدة متعددة المكوّنات. ومن المفيد، عند فحص شيفرة الذكاء الاصطناعي، اشتراط أدلة مثل لقطات الشاشة وتسجيلات الإجراءات في المتصفح. فالشيفرة الظاهرة في الفرق (diff) لا تثبت أن الوظيفة تعمل.