SwipeGen: Bridging the Execution Gap in GUI Agents via Human-like Swipe Synthesis
تقدم هذه الورقة SwipeGen، وهي أداة لتخليق تفاعلات السحب المتنوعة التي تشبه تفاعلات البشر، وSwipeBench، وهو معيار لتقييمها، لمعالجة تنفيذ السحب الجامد الذي يحد من أداء وكلاء واجهة المستخدم الرسومية الحاليين في السيناريوهات الواقعية.
تخيل عالماً يمكن فيه لهاتفك أن يفهم أوامرك الصوتية ويتنقل عبر تطبيقاتك نيابة عنك، يضغط على الأزرار ويكتب النصوص تماماً كما تفعل أنت. هذا هو الوعد الذي يقدمه "وكيل واجهة المستخدم الرسومية"، وهو نوع من الذكاء الاصطناعي المصمم للتفاعل مع الشاشات بالطريقة التي يفعلها البشر. لسنوات، علم الباحثون هذه الأنظمة كيفية التعرف على الأيقونات، وقراءة النصوص، والنقر على أهداف محددة. ومع ذلك، ظلت هناك فجوة حرجة؛ فبينما استطاعت هذه الوكلاء الإشارة والنقر بدقة متزايدة، إلا أنها عانت بشدة من أكثر الإيماءات شيوعاً على الإطلاق — وهي "السحب" (المرور بالإصبع). وسواء كان الأمر يتعلق بالتمرير عبر موجز إخباري، أو ضبط شريط مستوى الصوت، أو إظهار خيارات القائمة المخفية، فإن اليد الرقمية للآلة كانت غالباً ما تتحرك بدقة ميكانيكية جامدة تفشل في تفعيل استجابة الشاشة. هذا القصور يعني أنه حتى أكثر الوكلاء ذكاءً قد يعلقون، غير قادرين على إكمال مهام بسيطة تتطلب الحركة الانسيابية لإصبع بشري.
وضع فريق من الباحثين في جامعة فودان (Fudan University) هدفاً لحل هذه المشكلة المحددة عبر طرح سؤال جوهري: لماذا تفشل الآلات في السحب بينما يجد البشر ذلك طبيعياً للغاية؟ اكتشفوا أن المشكلة لم تكن في نقص الذكاء، بل في نقص البيانات وسوء فهم كيفية عمل عملية السحب. فالأنظمة الحالية تم تدريبها على مجموعات بيانات تهيمن عليها النقرات البسيطة، حيث تعامل كل تفاعل كنقطة واحدة على الشاشة. لكن السحب ليس نقطة؛ بل هو رحلة. إنه يتضمن مكاناً للبدء، واتجاهاً، ومسافة، وسرعة. وجد الباحثون أن الوكلاء الحاليين، الذين يحاولون تخمين إحداثي واحد، غالباً ما يخطئون الهدف تماماً لأنهم لم يفهموا أن سرعة السحبة أو نقطة البداية الدقيقة يمكن أن تغير النتيجة. ولإصلاح ذلك، بنوا أداة جديدة تسمى "SwipeGen"، وهي نظام مؤتمت مصمم لتعليم الآلات كيفية السحب عبر توليد آلاف الأمثلة لإيماءات تشبه حركات البشر.
بدأت العملية بترك النظام يستكشف تطبيقات الهاتف المحمول بمفرده، تماماً كما يفعل المستخدم. تنقل عبر الشاشات، محدداً المناطق التي يمكن تمريرها، مثل قوائم الصور أو صفوف الأيقونات. وبمجرد العثور على منطقة قابلة للتمرير، لم يكتفِ النظام بالتخمين؛ بل جرب بطريقة منهجية طرقاً مختلفة للسحب. اختبر عمليات سحب تبدأ من مركز الشاشة، ومن الحواف، وبالتحرك للأعلى، والأسفل، واليسار، واليمين، وبسرعات مختلفة. والأهم من ذلك، أن النظام راقب الشاشة قبل وبعد كل محاولة. إذا تسببت السحبة في تحريك المحتوى أو تغييره، فقد سجل النظام ذلك كنجاح، ملتقطاً الإحداثيات الدقيقة، والاتجاه، والمدة التي جعلت ذلك ممكناً. وإذا لم تستجب الشاشة، فقد تم استبعاد المحاولة. سمحت هذه الدورة من التجربة، والمراقبة، والتسجيل للفريق ببناء مكتبة ضخمة من تفاعلات السحب الناجحة، كاملة مع أوصاف باللغة الطبيعية تشرح ما حققته كل إيماءة.
ومع امتلاك هذه المكتبة الجديدة من البيانات، درب الباحثون نسخة جديدة من نموذج الذكاء الاصطناعي الخاص بهم، وأطلقوا عليه اسم "GUISwiper". لم يعلموا النموذج فقط كيفية العثور على زر، بل فهم فيزياء عملية السحب. كانت النتائج مذهلة؛ فعند اختبار النموذج على مجموعة جديدة من التطبيقات التي لم يسبق له رؤيتها، نجح "GUISwiper" في تنفيذ إجراءات السحب بشكل أفضل بأكثر من مرتين ونصف من النماذج الرائدة السابقة. وبينما تمكنت النماذج القديمة من إكمال حوالي ربع مهام السحب فقط بشكل صحيح، نجح النموذج الجديد في أكثر من 60 بالمائة منها. والأهم من ذلك، أثبت الباحثون أن تعليم الآلة كيفية السحب لم يجعلها أسوأ في المهام الأخرى؛ فقد ظل النموذج جيداً في تحديد الأزرار وقراءة النصوص، مما أظهر قدرته على تعلم الإيماءات المعقدة دون فقدان قدرته على فهم تخطيط الشاشة.
كما سلطت الدراسة الضوء على أن العقبة الكبرى أمام هؤلاء الوكلاء لم تكن في فهم "ماذا" يجب أن يفعلوا، بل في معرفة "كيفية" القيام بذلك. وجد الباحثون أنه عندما يفشل النموذج، يكون ذلك عادةً لأنه بدأ السحبة من المكان الخاطئ أو تحرك ببطء شديد بحيث لم يحفز استجابة الشاشة، وليس لأنه اختار الاتجاه الخاطئ. ومن خلال التركيز على تفاصيل التنفيذ — البداية الدقيقة، والنهاية، وسرعة الحركة — جسروا الفجوة بين منطق الآلة الجامد والحدس الانسيابي للمستخدم البشري. يشير هذا العمل إلى أنه لكي يتقن الذكاء الاصطناعي العالم الرقمي حقاً، يجب ألا يتعلم الرؤية فحسب، بل أن يتحرك بنفس الدقة والتوقيت الذي يتمتع به البشر الذين صُمم لخدمتهم. إن القدرة على السحب بفعالية لم تعد مجرد ميزة ثانوية؛ بل هي متطلب أساسي لأي وكيل يأمل في التنقل عبر شاشاتنا بسلاسة اليد البشرية.
ملخص تقني: SwipeGen
بيان المشكلة
على الرغم من انتشار وكلاء واجهة المستخدم الرسومية (GUI) المدعومين بنماذج الرؤية واللغة (VLMs)، إلا أن هذه الأنظمة تفشل بشكل متكرر في تحقيق قدرات تفاعلية مرضية في السيناريوهات الواقعية. ومن خلال التحليل التجريبي، حدد المؤلفون السبب الجذري لهذا القصور وهو التنفيذ الجامد لعمليات السحب (swipe execution).
تعتمد وكلاء الواجهات الرسومية الحالية بشكل أساسي على استراتيجيات تفاعل متمحورة حول المكونات (component-centric)، حيث تربط الأوامر اللغوية الطبيعية بإحداثيات مستهدفة محددة (مثل النقر على زر). ومع ذلك، تختلف عمليات السحب جوهرياً عن النقرات:
الطبيعة غير المرتبطة بنقطة ارتكاز (Non-anchored Nature): غالباً ما تحدث عمليات السحب فوق مناطق عامة (مثل خلاصات المحتوى) بدلاً من مكونات محددة.
تعقيد تعدد المعلمات (Multi-Parameter Complexity): على عكس النقرات، تتطلب عملية السحب الصالحة التنبؤ المتزامن بعدة معلمات: موضع البداية، موضع النهاية، الاتجاه، والمدة (السرعة).
ندرة وعدم اكتمال البيانات: تميل مجموعات بيانات الواجهات الرسومية الحالية بشدة نحو النقرات ومدخلات النصوص (76.4%–94.9% من التفاعلات). علاوة على ذلك، فإن تعليقات السحب (swipe annotations) الشحيحة المتاحة غالباً ما تفتقر إلى معلمات التنفيذ الحرجة (مثل الاتجاه الصريح أو المدة)، مما يمنع نماذج VLMs من تعلم توليد مسارات سحب صالحة وقابلة للتنفيذ.
وبناءً على ذلك، يعاني الوكلاء الحاليون في إجراء التعديلات الدقيقة (مثل أشرطة التمرير/sliders) واستكشاف المحتوى (مثل التمرير في خلاصات المحتوى)، مما يؤدي إلى فشل المهام بشكل متكرر.
المنهجية: SwipeGen
لمعالجة نقص بيانات السحب المتنوعة والقابلة للتنفيذ والمشابهة للسلوك البشري، يقترح المؤلفون SwipeGen، وهو مسار مؤتمت لتخليق تفاعلات السحب دون الاعتماد على أوامر بشرية محددة مسبقاً. يتكون المسار من خمس وحدات أساسية:
استكشاف الواجهة الرسومية (GUI Exploration): يستخدم استراتيجية البحث في العمق أولاً (DFS) للتنقل بشكل منهجي عبر تطبيقات الهاتف المحمول، وتسجيل مسارات التفاعل لاكتشاف حالات شاشات متنوعة.
تحديد الأهداف القابلة للتمرير (Scrollable Target Identification):
المكونات: تحديد العناصر القابلة للتمرير الصريحة (مثل أشرطة التمرير أو RecyclerViews) عبر التحليل الاستدلالي لهياكل XML.
المناطق: استخدام نموذج VLM (Qwen3-VL-4B-Instruct) لاستنتاج المناطق القابلة للتمرير (مثل خلاصات المحتوى أو شبكات الأيقونات) التي تفتقر إلى عقد هرمية صريحة، وذلك بناءً على التخطيط البصري والوظيفة الدلالية.
تمثيل السحب الموحد (Unified Swipe Representation): تعريف عملية السحب باستخدام أربع معلمات صريحة لضمان التوافق مع أدوات الأتمتة اللاحقة (ADB، UIAutomator، Appium):
موضع البداية: نقطة انطلاق الإيماءة.
موضع النهاية: نقطة انتهاء الإيماءة.
الاتجاه: مُعلق عليه صراحة (مثل أعلى، أسفل) لتسهيل التعلم، بدلاً من مجرد استنتاجه من الإحداثيات.
المدة: وهي بالغة الأهمية للتحكم في السرعة، خاصة لعمليات السحب على مستوى المنطقة حيث تحدد السرعة مسافة التمرير.
توليد السحب المرشحة (Candidate Swipe Generation):
بالنسبة لـ المكونات، يتم توليد المرشحين بناءً على صندوق الإحاطة (bounding box) ونسبة العرض إلى الارتفاع للمكون، مع مدة زمنية ثابتة.
بالنسبة لـ المناطق، يتم توليد المرشحين عن طريق الإزاحة (offsetting) من مركز المنطقة إلى حدودها، مع أخذ عينات من مدد زمنية سريعة (150 مللي ثانية) وبطيئة (500 مللي ثانية) لمحاكاة التحكم البشري خشن الحبيبات.
التحقق من صحة السحب (Swipe Validity Verification): تنفيذ عمليات السحب المرشحة والتحقق من فعاليتها عبر مقارنة لقطات الشاشة قبل وبعد التفاعل. يتم الاحتفاظ فقط بعمليات السحب التي تُحدث تغييراً بصرياً ملموساً (يُقاس باختلاف شدة البكسل داخل المنطقة المستهدفة).
توليد وصف السحب (Swipe Description Generation): استخدام نموذج VLM لتوليد أوامر لغوية طبيعية على مستوى الخطوة تصف عملية السحب التي تمت، بناءً على التغييرات البصرية والمعلمات، مما يخلق مجموعة بيانات تدريب متعددة الوسائط.
المساهمات الرئيسية
تحديد نقطة الاختناق: الورقة هي الأولى التي تحدد استراتيجية تنفيذ السحب المتمحورة حول المكونات والجامدة كعائق رئيسي يحد من قدرات التفاعل لوكلاء الواجهات الرسومية الحاليين.
مسار SwipeGen: صمم المؤلفون وأصدروا أول مسار مؤتمت لتخليق تفاعلات سحب متنوعة تشبه سلوك البشر، مما يعالج ندرة بيانات السحب عالية الجودة.
SwipeBench: تقديم أول اختبار مرجعي مصمم خصيصاً لتقييم جودة تنفيذ السحب في وكلاء الواجهات الرسومية، ويضم 382 تفاعلاً صالحاً من 16 تطبيق هاتف محمول خارج النطاق (OOD).
GUISwiper: نموذج VLM تم ضبطه بدقة (fine-tuned) باستخدام بيانات مستخلصة من SwipeGen، مما يثبت إمكانية تحسين قدرات السحب دون تدهور أداء التمركز (grounding) العام في الواجهات الرسومية.
النتائج التجريبية
قيم المؤلفون GUISwiper مقابل عدة نماذج أساسية رائدة (بما في ذلك Qwen2.5-VL، وUI-R1، وUI-TARS، وMAI-UI) عبر ثلاثة اختبارات مرجعية:
تنفيذ السحب (SwipeBench): حقق GUISwiper نسبة نجاح بلغت 61.25%، مما يمثل تحسناً بمقدار 2.46 ضعفاً مقارنة بالنموذج الأساسي Qwen2.5-VL (24.87%)، وتفوق على جميع النماذج الأساسية الأخرى. وقد نجح في إكمال 23 مهمة فشلت فيها جميع النماذج الأساسية، خاصة تلك التي تتضمن التمرير طويل المدى والتنقل في الخلاصات.
قدرة التمركز (ScreenSpot): لم يؤدِ الضبط الدقيق باستخدام بيانات SwipeGen إلى تدهور أداء التمركز العام. حقق GUISwiwa 85.83% دقة، متفوقاً على نموذجه الأساسي (75.80%) ومنافساً للنماذج الصناعية مثل UI-TARS (84.25%).
تنفيذ المهام من البداية إلى النهاية (AndroidWorld): حقق GUISwiper معدل نجاح في المهام بنسبة 40.52%، متفوقاً على النماذج ذات الحجم المماثل والنماذج الأساسية الأكبر (مثل Qwen2.5-VL-72B بنسبة 35.00%). كشف تحليل آثار التنفيذ أن تنفيذ السحب الموثوق أمر بالغ الأهمية للمهام التي تتطلب تنقلاً طويل الأمد خارج الشاشة.
الأهمية والادعاءات
تزعم الورقة أن عدم القدرة على تنفيذ عمليات السحب بفعالية هو قصور حرج وتم التغاضي عنه في وكلاء الواجهات الرسومية الحاليين. ومن خلال تقديم SwipeGen، أثبت المؤلفون أن:
تخليق البيانات أمر قابل للتطبيق: يمكن تخليق بيانات سحب عالية الجودة وقابلة للتنفيذ تلقائياً دون وسم يدوي، مما يتغلب على ندرة آثار التفاعل البشري.
السحب والتمركز يكملان بعضهما البعض: تعزيز قدرات السحب على مستوى المنطقة لا يأتي على حساب التمركز على العناصر؛ حيث يمكن تحسين كليهما معاً.
سد فجوة التنفيذ: يؤدي تحسين قدرة تنفيذ السحب بشكل محدد إلى تحسين الأداء مباشرة في مهام أتمتة الواجهات الرسومية المعقدة، مما يؤكد ضرورة الانتقال لما وراء نماذج التفاعل المتمحورة حول المكونات.
يقر المؤلفون بوجود قيود، مشيرين إلى أن تعريفهم لـ "الشبه بالبشر" يركز على المواءمة مع تأثير المهمة بدلاً من إعادة إنتاج الخصائص الحركية الدقيقة (مثل انحناء المسار)، وأن طريقة التحقق لديهم تعتمد على مقارنة البكسل الخفيفة. ويُقترح كعمل مستقبلي دمج آثار تفاعل المستخدم الحقيقي لنمذجة أكثر دقة وتوسيع الاختبارات المرجعية لتغطية تطبيقات أكثر تنوعاً.