Replit تطلق ViBench 2.0: أفضل نموذج يُخرج منتجًا يعمل بالكامل في 65% من عمليات البناء

قدّمت منصة Replit، التي يبني مستخدموها منتجات كاملة دون كتابة سطر برمجي واحد، اختبار ViBench 2.0 للمهام الطويلة في تطوير البرمجيات. يبدأ الوكيل من مشروع فارغ، ويتلقى المتطلبات وظيفةً تلو أخرى ضمن محادثة واحدة، وعليه في النهاية أن يسلّم منتج ويب يعمل. ولا يُفحص المنتج باختبارات الوحدات، بل بالطريقة التي يختبره بها المستخدم: عبر المتصفح، وبعد الطلب الأخير فقط. والنتيجة غير مريحة لرواد السوق: فأفضل نموذج، GPT-6.1 Sol، يجتاز ما يصل إلى 98% من خطط الاختبار، لكنه يبني منتجًا خاليًا من العيوب في 64,7% فقط من عمليات البناء.

كيف صُمّم الاختبار

يضم ViBench 2.0 ما مجموعه 17 منتج ويب متكاملًا، صُمّمت على غرار خدمات معروفة: Amazon وAsana وDiscord وFigma وGitHub وGoogle Docs وJira وUber. ينمو كل منتج عبر 9–18 طلبًا، ومجموع الطلبات 241. فعلى سبيل المثال، يبني الوكيل أولًا تطبيقًا لطلب سيارات الأجرة، ثم يتلقى تباعًا رسوم الإلغاء، والسائقين الذين يملكون عدة سيارات، وأرباح الرحلة، والدفع المنقسم. وتعتمد كل وظيفة جديدة على الشيفرة التي كتبها الوكيل بنفسه، وقد تتجاوز المحادثة 200 ألف رمز (توكن). ولا توجد أي تغذية راجعة بعد كل مرحلة، بينما يجب أن تصمد الوظائف القديمة أمام جميع التعديلات اللاحقة.

يتولى فحص النتيجة وكيل متصفح: يشغّل Chromium حقيقيًا عبر Playwright وينفّذ 544 خطة اختبار. وتفحص 85% من الخطط عدة وظائف معًا، مثل التأكد من أن أرباح السائق تحتسب الرسوم ولا تتعطل بسبب الدفع المنقسم. ولا تُحتسب عملية البناء ناجحة (pass@1) إلا إذا اجتازت جميع الخطط. وهذا مقياس صارم عن قصد: فالمستخدم الذي لا يقرأ الشيفرة يعني له «يعمل تقريبًا» أنه «لا يعمل».

الشروط واحدة لجميع النماذج: وكيل مبني على OpenHands SDK مزوّد بطرفية ومحرر ملفات، ومستوى استدلال متوسط، وبحد أقصى 300 خطوة وساعتين لكل مرحلة. اختُبرت ست نماذج مغلقة هي GPT-6.1 Sol وGPT-6 Astra وOpus 5.5 وSonnet 5.5 وGrok 4.7 وGemini 3.8 Flash، وثلاثة نماذج مفتوحة هي DeepSeek V4.1 Flash وKimi K3 وGLM 5.3. بنى كل نموذج كل منتج أربع مرات، فبلغ المجموع 612 عملية بناء.

الفجوة بين «شبه جاهز» و«جاهز»

تبدو المراكز الثلاثة الأولى كما يلي: Sol بنسبة 64,7% في pass@1، وAstra بنسبة 60,3%، وOpus 5.5 بنسبة 48,5%. وتتراوح نسبة الخطط المجتازة لديها بين 93,7% و98,0%. ومن بين 84 عملية بناء فاشلة وصلت إلى مرحلة الفحص، أخفقت 42 في خطة واحدة بالضبط، وأخفقت 62 في خطتين على الأكثر. وبنى Astra منتجًا واحدًا على الأقل يعمل بالكامل في 16 مهمة من أصل 17، وSol في 15، وOpus في 13. أما المنتج الوحيد الذي لم ينجح أي من النماذج الرائدة في بنائه ولو مرة واحدة من 36 محاولة فهو نسخة Figma: إذ تعطّل فيها التحرير المشترك والتراجع عن الإجراءات.

وما زالت النماذج المفتوحة بعيدة عن هذا المستوى: فلم تجتز أي عملية بناء من عملياتها البالغة 204 جميع الخطط. ومع ذلك تتفاوت في نسبة الخطط المجتازة: فقد حقق DeepSeek V4.1 Flash نسبة 77,4% وجاء ضمن نقطتين من Sonnet 5.5، بينما تبلغ كلفته نحو 60% من كلفته.

يتفاوت السعر والسرعة بدرجة كبيرة. تكلّف عملية البناء من $2,5 إلى $89,9، وتستغرق من 26 دقيقة إلى أكثر من أربع ساعات. وتكلّف Astra نحو سبعة أضعاف Sol، مع أن الفارق في pass@1 أقل من خمس نقاط. ويبني Opus أسرع بمقدار 2,4 مرة من Sol (73 دقيقة) مع عدد رموز خرج أقل بنسبة 6% فقط، ويربط المؤلفون ذلك بسرعة الاستدلال (inference).

وتيرة التقدم سريعة. ففي ثلاثة إصدارات من خط نماذج واحد، ارتفع pass@1 على المنتجات العامة من 3% إلى 53%، وانخفضت كلفة البناء بأكثر من النصف. كما أن pass@1 لا يرتفع بشكل ملحوظ إلا عندما تتجاوز نسبة الخطط المجتازة نحو 70%.

إلى أي مدى يمكن الوثوق بالمقيِّم

أضعف حلقة في هذا النظام هي المقيِّم القائم على الذكاء الاصطناعي، وقد فحصه المؤلفون بشكل منفصل. ففي التقييم الواحد يُسقط خطأً خطة سليمة في 0,2% من الحالات، ولذلك تُعاد مراجعة الخطط الراسبة حتى خمس مرات، إلى أن تتطابق ثلاثة تقييمات. أما حالات «النجاح» الخاطئة فهي أقل شيوعًا: فقد أعاد GPT-6.1 Sol فحص 477 خطة اعتمدها Opus، وبعد المراجعة اليدوية تبيّن أن 4 فقط (0,8%) كانت خاطئة. ومن بين 34 خطأً برمجيًا أُدخلت عمدًا، منها 24 دقيقة (مثل مبلغ يختلف بسنت واحد)، اكتشف المقيِّم جميعها. وكشف تدقيق 178 خطة راسبة عن 13 حكمًا خاطئًا وموضعين كانت فيهما المواصفات ناقصة. وصُحّح كل ذلك قبل الإصدار، أما الإخفاقات الـ159 الباقية فهي أخطاء برمجية حقيقية.

شغّل فريق Fireworks الاختبار بشكل مستقل عن Replit: إذ نفّذه بأمر واحد لكل نموذج ودون أي تعديل. وكل الأرقام الواردة في المقال مأخوذة من هذه التشغيلات.

القيود والخلاصة العملية

تتوافر للعموم ثمانية منتجات مع أداة التشغيل والمقيِّم؛ أما المنتجات التسعة الأخرى فمخفية كي لا تُدرَّب النماذج على هذه المهام، وتُحتسب النتائج المستقلة على المنتجات الـ17 كلها. والمقيِّم والوكيل «المُغذّي» (seeding) في التجارب هما Opus 5.5، ما قد يؤثر نظريًا في التقييمات، مع أن مقيِّمًا ثانيًا لم يؤكد ذلك في معظم الحالات. كما أن الاختبار صُمّم وفق قرارات Replit بشأن النماذج التي تدمجها، ولذلك يعكس سيناريوهاتها تحديدًا: منتجات ويب تُبنى من الصفر، لا العمل على قاعدة شيفرة تخص طرفًا آخر.

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