وكيل بحجم 8B لنظام iOS يتفوق على Gemini-3.5-Flash في UINavBench ويتعادل مع Gemini-3.1-Pro

اقترح فريق من الباحثين طريقة لتدريب نماذج صغيرة على التنقل في الواجهات لا بالاعتماد على عروض مسجّلة، بل عبر التفاعل المباشر مع تطبيقات iOS الحقيقية. وقد تفوق الوكيل الناتج، البالغ 8 مليارات معامل، في UINavBench على Gemini-3.5-Flash وQwen3.8-27B، وهو معيار لتطبيقات iOS الحقيقية يتحقق من النجاح عبر VLM بدور الحكم، وتعادل مع Gemini-3.1-Pro. أما في AndroidWorld، أي على نظام تشغيل مختلف لم يرَه الوكيل أثناء التدريب، فنسبة نجاحه أعلى بنحو سبعة أضعاف من نسبة النموذج الأساسي بعد SFT.

لماذا يُقسَّم الوكيل إلى مخطِّط و«مُحدِّد الهدف»؟

المشكلة التي يبدأ منها البحث يعرفها كل من حاول بناء وكلاء واجهات المستخدم (UI). فالنماذج الحدودية (frontier) تتعامل جيدًا مع التنقل على الشاشة، لكن تكلفة المهمة الواحدة قد تبلغ أحيانًا عدة دولارات، وهذا مكلف جدًا للاستخدام اليومي. أما النماذج الصغيرة المدرَّبة عبر SFT أو التعلم المعزز دون اتصال (offline RL) فتحفظ المسارات الموجودة في بيانات التدريب. وحين يعرض التطبيق شاشة غير متوقعة، لا يعرف هذا الوكيل كيف يعود إلى المسار.

قسّم المؤلفون النظام إلى جزأين. يطّلع المخطِّط على لقطة الشاشة، ويحتفظ بسجل الخطوات السابقة، ثم يُخرج الخطوة الحالية وخطة بعيدة المدى عبر سلسلة من الاستدلال. وبعد ذلك يحوّل نموذج منفصل للربط (grounding) هذه الخطوة إلى إجراء محدد وإحداثيات اللمس. الربط مهمة شبه حتمية (deterministic)، ويحلّها SFT العادي جيدًا. لذلك لا يُنفَق التعلم المعزز المكلف إلا على المخطِّط. ينطلق المخطِّط من Qwen3-VL-8B-Instruct بعد تدريبه على مسارات بشرية، منها المجموعة العامة GUIOdyssey لسيناريوهات التنقل بين التطبيقات. ويملك المخطِّط أيضًا إجراءً للاستيضاح: فإذا صيغت المهمة بشكل ناقص، يمكنه أن يسأل المستخدم عن تفضيلاته.

مكافأة لكل خطوة وتثبيت الناقد

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

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

الابتكار الثاني هو GiGPPO. تقدّر هذه الطريقة قيمة الحالة مع مراعاة مكافآت من حالات متشابهة بصريًا في مسارات متوازية. وهذا يثبّت الناقد (critic). ويؤكد المؤلفون الفرق عن GiGPO، التي يُحسب فيها خط الأساس على حالات متكررة بدقة تامة: ففي بيئتهم تكاد هذه الحالات تكون فريدة دائمًا. لذلك تمرَّر الإشارة عبر دالة قيمة قابلة للتدريب. ووفقًا للمؤلفين، تسرّع كل من المكافأة الكثيفة وGiGPPO التقارب، والنتيجة أفضل من SFT ومن التعلم المعزز بمكافأة نهائية وحيدة.

البنية التحتية: 512 جهاز iPhone افتراضيًا

يتطلب التعلم المعزز عبر الإنترنت عددًا هائلًا من التفاعلات الحقيقية. فبنى المؤلفون مجموعة من أجهزة iOS الافتراضية السحابية، تُدار عبر VNC بمجموعة إجراءات مثل tap وswipe وtype وlong press وhome وwait. يُعدّ كل جهاز مرة واحدة: تُثبَّت التطبيقات، ويُسجَّل الدخول إلى Apple ID، وتُؤخذ لقطة (snapshot). ثم تنتهي كل حلقة بالرجوع إلى اللقطة بدل إعادة إنشاء الجلسة، وتستغرق إعادة التشغيل نحو 10 ثوانٍ. تعمل 512 حلقة في وقت واحد، ولكل منها جهازها الخاص. ويزعم المؤلفون أن هذا أول تدريب واسع النطاق لوكلاء UI يجري بالكامل على أجهزة iOS حية مع تطبيقات حقيقية.

ما الذي ينبغي أخذه في الحسبان

هذه نسخة أولية (preprint)، ولا يتضمن الوصف المتاح نسب نجاح دقيقة في المعايير، ولذلك تشير عبارة «نحو سبعة أضعاف» إلى القاعدة المنخفضة لـSFT في AndroidWorld، لا إلى سقف مطلق. ويعتمد التقييم في UINavBench على VLM بدور الحكم، بينما تصدر مكافآت التدريب عن LLM بدور الحكم، ما يعني أن أخطاء الحكمين قد تؤثر في التدريب وفي القياس معًا. وقد أُجريت المقارنة مع Gemini على معيار محدد لتطبيقات iOS الحقيقية، وليس بالضرورة أن تنسحب على أي مهام.

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