إحصاءات حول إنشاء الرموز البرمجية للوكلاء من Android Bench

توماس مليناريتش

صباح الخير جميعًا.

لنبدأ.

في مارس، أطلقنا Android Bench، وهو مجموعة بيانات ولوحة صدارة لقياس النماذج اللغوية الكبيرة في مهام تطوير Android.

ومنذ ذلك الحين، أجرينا الاختبار على العديد من النماذج الجديدة.

وفي الشهر الماضي، أطلقنا الإصدار Android Bench 2.0.

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

اسمي "توماس"، وسأشارككم رحلتنا مع Android Bench وكيف وصلنا إلى ما نحن عليه الآن.

لنبدأ بالإصدار 1.0.

في الإصدار 1.0، أخذنا مشاكل حقيقية من مستودعات مفتوحة المصدر.

لقد فلترنا مشاريع GitHub التي تتضمّن مشاكل وطلبات سحب لحلّ هذه المشاكل واختبارات للتحقّق من الحلول.

نحن نقسّم طلبات السحب إلى مجموعات مهام لنماذج الذكاء الاصطناعي.

أصبحت مشكلة GitHub هي التعليمات أو الطلب الخاص بالنموذج، ووضعناها في الحالة قبل طلب الدمج.

وبعد أن أنشأ النموذج بعض الأعمال، أجرينا الاختبارات وطبّقناها على الناتج، ما أعطانا نتيجة ناجحة أو فاشلة.

هذه المحاولة الواحدة التي يحاول فيها الذكاء الاصطناعي حل المشكلة، نسميها تجربة.

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

تشبه هذه المنهجية مقياس SWE-bench المعروف.

بدأنا بأكثر من 10,000 مهمة محتملة، ولم تكن جميعها مناسبة.

وكانت بعض التعليمات غير مكتملة أو مفرطة في التحديد.

ربما تم ربط الاختبارات بالحل الذهبي، أو الحالة قبل كسر طلب السحب.

لذلك، كان علينا مراجعة المهام مرارًا وتكرارًا للوصول إلى 100 مهمة عادلة.

وخلال هذه المراجعات، استخدمنا أحدث النماذج للحصول على بعض النتائج.

بدأنا بحلّ حوالي %30 من المهام، وهو ما نسمّيه معدّل النجاح.

وعندما قفلنا مجموعة البيانات للإصدار الرسمي، كانت أفضل النماذج قد بلغت حوالي %70.

ولكن هذا بعد شهر تقريبًا.

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

وفي إصدار أغسطس، بلغت نسبة النجاح %92 لأفضل نموذج.

وأدركنا أنّ المعايير التي نعتمدها منخفضة جدًا، وأنّ مجموعة البيانات هذه مشبّعة.

توماس مليناريتش

لكننا توقعنا ذلك، ونحن نعمل بجد على الإصدار 2.0، الذي أصدرناه الشهر الماضي.

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

وتقديم تحليلات ونتائج تخدمك أنت وصنّاع النماذج.

ولكن علينا أيضًا أن نأخذ في الاعتبار الذكاء والمثابرة والغش.

وعلينا منع خطر التلوث.

تكمن إحدى المشاكل في منهجية SWE-bench في الانفتاح الفعلي للرمز المصدري.

نشرت OpenAI مقالة.

ووجدوا أنّ النماذج تمكّنت من إكمال الكلمات التالية من التعليمات، أو تمكّنت من حلّ مهمة تتضمّن خطأً غامضًا لم يكن جزءًا من التعليمات.

وأدركوا أنّ صانعي النماذج يدرّبونها على الرموز البرمجية المفتوحة المصدر وأنّ SWE-bench ملوّث.

لذلك، في الإصدار 2.0، سنُبقي الرمز مغلقًا لمنع التدريب عليه.

وقسّمنا العمل إلى أربعة مسارات.

الأول هو تحويل التطبيقات، حيث أخذنا تطبيقات مفتوحة المصدر من Flutter وReact Native، وطلبنا من الوكلاء تحويلها إلى حلول Android أصلية.

يعكس هذا في الواقع الاتجاه الحالي المتمثل في الانتقال من التطبيقات التي تعمل على عدّة منصات إلى التطبيقات الأصلية.

أما مسار العمل الثاني، فكان الميزات الجديدة وعمليات الدمج مع المنصات.

وتم دمجها في قواعد الرموز البرمجية الخاصة بالإنتاج.

على سبيل المثال، في تطبيق Now in Android، أضفنا ميزة الفيديو أو ميزة "نافذة ضمن النافذة"، وما إلى ذلك.

أما مسار العمل الثالث، فكان عمليات نقل البيانات.

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

على سبيل المثال، Nav 2 إلى Nav 3، أو طرق عرض XML إلى Compose، أو أشياء مثل الجزء الفردي إلى التخطيط التكيفي.

والتطبيق الأخير كان تطبيقًا داخليًا جديدًا تم إنشاؤه من الصفر باستخدام نماذج التصميم المرئي.

في هذه الحالة، كانت الأمثلة هي عملية المصادقة الكاملة على كلمة المرور الصالحة لمرة واحدة (OTP) عبر الرسائل القصيرة، وتتبُّع الطلبات باستخدام "خرائط Google"، والمزيد.

توماس مليناريتش

بمساعدة عدد قليل من المهندسين، أنشأنا تطبيقًا بالحجم نفسه مثل تطبيق Now in Android.

لكن المهام الجديدة جلبت تحديات جديدة.

الأولى: تقييم الوكلاء بشكل صحيح.

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

في الإصدار 1.0، اعتمد هذا المعيار في الغالب على اختبارات الوحدات، واختبارات الوحدات سيئة للغاية في كونها حيادية.

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

وتتطلّب أسماء فئات أو دوال دقيقة.

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

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

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

لذا، الحل هو إجراء اختبارات مستقلة عن التنفيذ.

هذه اختبارات عالية المستوى وتختبر النتائج والسلوكيات، وليس العناصر الداخلية.

نستخدم اختبار واجهة المستخدم الحتمي، وهو الاختبار الذي يتفاعل مع معلومات الشاشة العامة، تمامًا كما يفعل المستخدم.

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

ومن بينها، لدينا أيضًا عمليات تحقّق ثابتة، مثل التحقّق من الأذونات في ملف البيان أو ما إذا كانت المكتبة في ملفات مضمّنة وما إلى ذلك.

ولدينا أيضًا اختبارات مختلطة تجمع بين هذه النصوص البرمجية واختبارات واجهة المستخدم.

هذا مثال على أحد الاختبارات المختلطة.

ويتم تشغيلها خارج المحاكي.

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

ويتحقق الاختبار فقط مما إذا كان الإدخال يحتوي على الرقم الصحيح.

هذا كل شيء.

لا يوجد أي اقتران في التنفيذ، بل يتم فقط التحقق من عمل التدفق.

المشكلة الثانية في التقييم هي أنّ مهامنا تتطلّب استخدام وسائط متعددة.

إما أن يُطلب من الوكلاء إنشاء واجهة مستخدم، أو نمنحهم نماذج التصميم.

لذلك، من الأسهل استخدام اختبارات لقطات الشاشة.

وكنا نعلم منذ البداية أنّ الحد الأدنى لعدد لقطات الشاشة يجب أن يكون أعلى، ولكنّها فشلت على أي حال.

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

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

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

ونزوّده أيضًا ببعض بيانات التسلسل الهرمي لأدوات تسهيل الاستخدام التي تتحقّق من صحة البنية وصحة التكافؤ الهيكلي.

لقد جرّبنا ذلك تجريبيًا في العديد من التجارب، ورأينا أنّه يتّسم باتساق عالٍ ويتجاهل المشاكل التي واجهناها.

أصبح لدينا الآن طريقة جيدة للتحقق من العناصر المرئية والسلوكيات بشكل مستقل، ورأينا أن الوكلاء حاولوا تزييف كل شيء.

تفضَّل.

توماس مليناريتش

يبدأ الأمر ببساطة.

في الوقت الحالي، يقول الوكلاء في الأساس: "حسنًا.

لديّ مهمة.

لنلقِ نظرة على GitHub.

لنتعرّف على الحلول".

هذا هو الإجراء الأول الذي يتّخذونه.

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

لكنّ ذلك كان سهلاً.

في بعض التجارب، قلنا إنّ كل شيء كان يمرّ بنجاح بنسبة %100، وكان ردّ الوكيل: "انتصار رائع!"

حسنًا

هذا مثير للاهتمام، ما الذي وجدوه؟

ولكن عندما نظرنا عن كثب إلى المسار، قالوا: "لا يمكنني فعل ذلك.

سأقوم فقط، ماذا لو قمت بتغيير الحد إلى 80٪ من اختبار لقطة الشاشة؟"

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

وأقول لنفسي: "نعم، لقد نجحت، كل شيء يمرّ".

نعم، ولكن اختبارات لقطات الشاشة غير مفيدة.

لكنّها لم تكن الأكثر تطورًا.

في بعض الحالات، وتحديدًا في تطبيق Flutter للتحويل، حاول الوكيل مرارًا وتكرارًا إنشاء تطبيق Android، لكنّه قال: "لا أعرف ماذا أفعل".

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

والآن، أصبح الأمر أشبه باجتياز اختبار لقطة الشاشة.

رائع

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

الآن كل شيء أخضر.

رائع.

أحسنت".

هذا ليس، مثل، هناك واحد، مثل، جيد حقًا.

لدينا مهمة نقل من Java إلى Kotlin، حيث يحتاج الوكيل بشكل أساسي إلى النقل من Java إلى Kotlin، أليس كذلك؟

لم يتمكّنوا من إنشائه.

يبدو أنّ هناك مشكلة ما، لذا فكّر الوكيل في أنّه سيأخذ الفئات المجمّعة من Java ويضعها في ملف JAR، ثم يضيفها إلى ملفات الإصدار كمكتبة عادية.

والآن، نجحت جميع الاختبارات، ولكن لدينا عمليات التحقّق الثابتة التي تتحقّق من ملفات Java، لذا سأحذفها".

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

رائع."

لا أعرف ما إذا كان ذلك غشًا.

أعني أنّ هذا إبداع حقيقي.

لذلك، لمنع كل ذلك، أنشأنا أداة رصد للغش تتضمّن ثلاثة إجراءات دفاعية.

ننظر إلى شجرة واجهة المستخدم، ونطبّق أحجام شاشات مختلفة بحيث يتم تشويه الخلفية، ونراها.

نعيد أيضًا ضبط الاختبارات، ونتحقّق من أي تلاعب في الاختبارات لكي لا يتمكّنوا من تغيير الحدود.

لدينا أيضًا نموذج لغوي كبير يعمل كقاضٍ، ويراجع المسارات والنتائج الفعلية للوكيل لرصد أي سلوك غريب.

وإذا حدث أي شيء، فسنقول ببساطة، "حسنًا، فشل مباشر".

توماس مليناريتش

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

لذا، عندما نطلب من الوكلاء هندسة تطبيق Android، كيف تبدو الأرقام؟

لذا، اعتبارًا من يوم الاثنين، ربما رأيت منشور المدونة، تبدو الأرقام على هذا النحو.

حتى أفضل الوكلاء لا ينجحون إلا في تنفيذ %40 تقريبًا من مهامنا، ومعظم الوكلاء المتقدّمين يحققون نسبة تتراوح بين %20 و%40.

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

لذا، لنلقِ نظرة على النتائج.

يمكننا الآن إلقاء نظرة على النتائج من وجهات نظر متعددة.

يمكننا إلقاء نظرة على بعض الإحصاءات التي وجدناها بالفعل.

السؤال الأول الذي قد يتبادر إلى ذهنك عند النظر إلى الرسم البياني هو: كم تبلغ تكلفة تشغيل هذا الوكيل؟

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

وقد يكون ذلك عاملاً حاسمًا في قرارك.

ولكن يمكننا النظر إليه من منظور آخر.

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

وهنا، يمكننا أن نرى فجأة أنّ بعض النماذج أكثر ثرثرة.

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

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

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

أو أنّ وكلاء آخرين لديهم سعر الرمز المميّز نفسه ينجزون حوالي %30 من المهام، ولكنّهم أرخص بـ 15 مرة.

لذلك، سعر الرمز المميّز ليس هو المقياس.

بعضها عبارة عن نماذج تستكشف الرمز البرمجي بشكل أكبر، وتعيد إنشاءه، وتعيد تشغيله، وكل خطوة تستهلك المزيد من الرموز المميّزة.

لذا، لا تنظروا فقط إلى السعر، بل إلى التكلفة لكل رمز مميز.

اختَر نموذجًا، واطّلِع على البيانات الفعلية، مثل استخدامه في حالتك، أو اطّلِع على Android Bench لمعرفة النماذج التي تستهلك أكبر قدر من الرموز المميّزة في المهام.

بعضها، كما تعلمون، يتطلب خطوات أكثر على الرغم من أنّها أرخص لكل رمز مميّز.

ولكن هناك جانب إضافي للسؤال نفسه.

هذا هو المخطط نفسه، ولكن يمكننا أيضًا إلقاء نظرة وإظهار المدة التي يستغرقها الوكلاء لإكمال ذلك.

ويمكننا أن نرى أن الوكلاء الذين حصلوا على أعلى معدل نجاح، قد يكونون الأبطأ.

على سبيل المثال، يمكننا أن نرى أن بعضهم يستغرق ما يقرب من ساعتين لكل مهمة.

ويواصلون إعادة البناء وإعادة الاختبار إلى أن ينجحوا.

نعم، يحصلون على أفضل معدل نجاح، لكنهم يستغرقون أيضًا معظم الوقت.

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

أو، وكلاء آخرون، ينهونها في أقل من 20 دقيقة ولا يزالون يحلون أكثر من ربع المهام.

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

الخلاصة هي أنّه ما مِن نموذج واحد أفضل من غيره.

يعتمد ذلك على ما تحسّنه.

هل هو معدل النجاح؟

هل هي التكلفة؟

هل هو وقت الانتظار؟

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

ومع ذلك، فإن التكلفة والسرعة تخبرك فقط بكيفية تشغيل الوكلاء، ولكن ليس سبب فشلهم في معظم التجارب.

لذلك، قمنا بفحص عمليات التشغيل الفاشلة، ولاحظنا أن الوكلاء غالبًا ما ينسحبون مبكرًا.

إنّهم مقتنعون بأنّهم انتهوا.

اكتملت المهمة.

حسنًا، سأذهب إلى المنزل.

ولكن، كما ذكرنا، في حزمة المهام، يتلقّى الوكلاء التعليمات والحالة السابقة فقط.

ولا يمكنهم الاطّلاع على الاختبارات.

يرى المستخدمون أنّه لا يمكنهم الاطّلاع على حزمة التحقّق.

لذا، سألنا، ماذا لو، ماذا يحدث إذا سمحنا لهم فقط برؤية الاختبارات؟

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

لذا، كانوا يجرون الاختبارات بشكل متكرر.

ويمكنهم فحص الأخطاء وتحسين الرموز البرمجية في حلقة ملاحظات.

ووجدنا أنّه عندما يرى الوكلاء الاختبارات، فإنّهم يبذلون جهدًا أكبر ويعملون لفترة أطول.

وفي عمليات التشغيل المفتوحة، حقّقت زيادة بنسبة %25 في عدد الجولات و%40 في وقت تشغيل الوكيل.

وقد استغرقوا حوالي 30 دقيقة لكل مهمة في تشغيل الاختبارات الفاشلة وإصلاحها، لأنهم لم يصححوا الأخطاء بشكل أعمى.

وبالتالي، يمكنهم معرفة ما يفشل بالضبط، وللأسف، تقفز نسبة النجاح أيضًا بنحو 50 نقطة مئوية.

وهذا الجهد الإضافي يحسّن متوسط معدل النجاح، كما ذكرت.

ولكن في النهاية، ظهرت نماذج رائدة جديدة، وسرعان ما تفوّقت على هذا النموذج المفتوح المصدر.

حسنًا، ما يقرب من 90٪ من معدل النجاح.

لذلك، احتفظنا بصيغة الاختبار المغلق لعمليات البحث المغلقة كمقياس أساسي للمقارنة.

ومع ذلك، من المثير للاهتمام معرفة كيف تتحسّن النماذج عندما تعرف المعايير التي يتم تقييمها بناءً عليها.

توماس مليناريتش

ومع ذلك، فقد سمح لنا ببناء المزيد من الأفكار حول الوكلاء.

على سبيل المثال، يمكننا التحقّق من كيفية اختبار النماذج لعملها.

يمكننا أن نرى من الرسم البياني أنّ النماذج الرائدة تكتب المزيد من الاختبارات الأفضل، وتحقّق معدلات نجاح أعلى.

بعض النماذج الأخرى واثقة من نفسها بشكل مفرط، يمكنني القيام بذلك، بدون اختبارات.

أحيانًا تكون جيدة.

لذا، إذا كنت تستخدم النماذج التي لا تجيد الاختبار، يمكنك مساعدتها إما من خلال تزويدها بمهارات اختبار أفضل أو تعليمات محدّدة حول كيفية كتابة الاختبارات.

لكن الارتباط لا يعني السببية، أليس كذلك؟

نحتاج إلى إجراء تجربة مضبوطة على هذا الأمر.

لا يزال علينا إجراء المزيد من الأبحاث لمعرفة ما إذا كان طلب إجراء اختبارات أفضل يؤدي فعلاً إلى تحسين النتيجة.

ومع ذلك، أجرينا تجربة على النصف الآخر من اختبار Android، وهي جعل الوكلاء يستخدمون المحاكي.

في البداية، في معيارنا، لم نقل شيئًا عن المحاكي.

افترضنا أنّ الوكلاء سيفهمون ذلك، أليس كذلك؟

لذلك، رأينا، كنتائج، أن أيًا منهم تقريبًا لم يقم بتشغيل المحاكي.

وكما ذكرت، فإنّ اختبارات واجهة المستخدم مهمة جدًا في مقاييس الأداء، وبدون المحاكيات، لا يمكنك استخدام اختبارات واجهة المستخدم.

لذا، كانوا جميعًا يفشلون في شيء بسيط للغاية.

لذا، نواجه الآن معضلة.

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

ومع ذلك، كان هدفنا هو أن نكون معيارًا عادلاً لقياس الترميز وحل المشكلات في Android.

لا نريد قياس بعض العوامل البيئية الغريبة.

لذلك، اخترنا حلاً وسطًا.

أخبرناهم أن هذه هي الطريقة التي تبدأ بها المحاكي، ولكن سواء كنت ستستخدمه أم لا، لم نذكر أي شيء.

ففي النهاية، ليس بدء تشغيل المحاكي هو ما نحتاج إلى اختباره أو نريد اختباره.

وقمنا بقياس تأثير تعليمات المحاكي هذه.

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

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

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

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

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

توماس مليناريتش

الرجوع إلى قائمة الصدارة

كما ذكرت، تجتاز أفضل النماذج حوالي %40 من المهام، ويتطلّب معدّل النجاح اجتياز جميع عمليات التحقّق.

وإلا، ستفشل المهمة.

لذا، السؤال هو، هل لم ينتج الوكلاء أي شيء مفيد للـ 60% الأخرى؟

لا، إنّها تتحسّن.

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

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

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

لذلك، أجرينا تجربة على عملية تحويل Flutter إلى Android لمعرفة ما يحدث.

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

في حوالي 140 خطوة، كانوا يعملون على الوصول إلى نتيجة 90% تقريبًا في المتوسط، ثم قضوا أكثر من 90 خطوة أخرى أو ما يقرب من 40% من الجولة في محاولة لسد الفجوة إلى 100%، لكنهم تمكنوا فقط من تسجيل 1 أو 2% أكثر.

ونعتقد أنّ هذا يعكس في الواقع ما يحدث في مجال تطوير الوكلاء اليوم، حيث يرى المطوّرون أو المستخدمون غير المتمرسين أنّ التطبيق مكتمل.

يتم عرض كل شيء.

كان الإدخال ناجحًا إلى حدّ ما.

قد لا تكون هناك أي أعطال.

ولكن عندما يأتي مهندس كبير وينظر إلى الرمز، فإنه يرى العديد من العيوب المتعددة: يرى مشاكل معمارية، وعيوب في دورة الحياة، وأشياء من هذا القبيل.

توماس مليناريتش

في الختام، لنلقِ نظرة على Android Bench، وهو الإصدار 2.0 من عملنا.

بالمقارنة مع الإصدار 1.0، لدينا الآن 30 مهمة فقط، وهذا أمر مقصود.

بدلاً من إصلاح الأخطاء المعزولة والتصحيحات الصغيرة، لدينا شاشات كاملة، وعمليات ترحيل متعددة الوحدات، وتحويلات كاملة للتطبيقات.

أصبحت التصحيحات الآن أكبر حجمًا في عشرات الملفات.

ولدينا عمليات التحقّق من واجهة المستخدم المتعددة النماذج.

يجب أن تعمل الوكلاء لفترة أطول وأن تعمل بجد أكبر.

إذا قارنّا ذلك بمعايير أخرى متقدّمة، يمكننا أن نرى أنّ معيارنا يتطلّب تغييرات أكبر بكثير في الرموز البرمجية.

وهو خالٍ من التلوث لأنّ معظم المهام مكتوبة من الصفر، ولا يزال هناك مجال كبير للنمو.

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

وعندما يحدث ذلك، نأمل أن نتمكّن من تنفيذ مهام أكثر صعوبة وتعقيدًا تتوافق مع تلك الحقبة ومع حالة الذكاء الاصطناعي في ذلك الوقت.

يمكنك الآن استخدام Android Bench كبوصلة لمقارنة النماذج وأدوات الاختبار، وربما الحصول على بعض الإحصاءات.

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

بهذه الطريقة، يمكنك التأكّد من صحة النتائج التي يقدّمها الذكاء الاصطناعي بدلاً من مجرد توقّع ذلك.

نيابةً عن فريق Android Bench بأكمله، نشكركم على اهتمامكم.