GenUI-Harness يرفع أداء نموذج 4B من 9,33% إلى 58% في Pass@3 ويتفوق على Claude Opus 5

اقترح فريق من المؤلفين على arXiv منظومة GenUI-Harness، وهي إطار متعدد الوكلاء لا يجيب فيه النموذج عن الطلب المعقد بفقرة نصية، بل بواجهة مؤقتة تضم نماذج إدخال وقوائم وخيارات لضبط المعلمات. بعد التدريب بالتعلم المعزز ارتفع أداء نموذج بـ4 مليارات معلمة في Pass@3 من 9,33% إلى 58,00%، وتفوق على Claude Opus 5 الذي سجّل 46,67%. وفي استطلاع شمل مراجعين، انخفض متوسط طول الحوار من 3,4 إلى 1,2 جولة.

وكيلان بدل محادثة واحدة

البنية بسيطة. يتولى Tool Agent البحث عن المعلومات وتنفيذ المهام: يصل إلى قواعد البيانات ويستدعي الأدوات. أما GUI Coder Agent فيدرس الطلب والنتيجة، ويحدد مواضع الغموض، ثم يكتب شيفرة الواجهة الأمامية لواجهة منظَّمة. إذا طلب المستخدم «تغيير الرحلة»، فلا يطرح الوكيل خمسة أسئلة توضيحية متتالية، بل يعرض نموذجًا يضم خيارات حقيقية من قاعدة البيانات.

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

كيف تُدرَّب نماذج برمجة الواجهات

يتمثل الجانب الهندسي الأساسي في العمل في كيفية تدريب GUI Coder باستخدام RL. وهنا مشكلتان، ولكل منهما حل خاص.

الأولى: المكافأة القابلة للتحقق على واجهة تفاعلية تتطلب تنفيذًا فعليًا للشيفرة، وهذا مكلف. لذلك طوّر المؤلفون Dynamic UX، وهي حزمة خفيفة توفر في بيئة معزولة واحدة (sandbox) التفاعل الديناميكي وجمع المكافآت.

الثانية: عندما يمنح LLM يعمل حَكَمًا المكافأة، يتعلم النموذج سريعًا خداعه. وللتصدي لـreward hacking اقترح المؤلفون Reward Auditor، وهو مكافأة فوقية (meta-reward). يراقب هذا المكوّن توزيع المكافآت، ويستخلص أنماطًا تشخيصية، ويجمعها في معيار تقييم موحّد ومواصفات للتقييم. ولا يبقى الحَكَم ثابتًا أثناء التدريب.

المعيار والأرقام

للتحقق أنشأ المؤلفون UI-TAU Bench. يقوم المعيار على 10 قواعد بيانات مجالية حقيقية من مصادر مفتوحة، ويستند إلى صيغة Tau-Bench الخاصة باستخدام الأدوات (tool use). وتتوافر نسختان: Lite (300 مهمة) وFull (1000 مهمة).

• متوسط التحسن في Pass@3 مقارنةً بـsmolagents على Lite: 4,48 نقطة مئوية.
• نموذج 4B بعد التدريب في GenUI-Harness: من 9,33% إلى 58,00% في Pass@3.
• Claude Opus 5 على المعيار نفسه: 46,67%.
• المتانة: يحافظ النظام على أدائه مع الطلبات الغامضة والواضحة على حد سواء.
• استطلاع المراجعين: يتقلص الحوار من 3,4 إلى 1,2 جولة.

تُظهر نسبة 9,33% التي بدأ بها نموذج 4B مدى صعوبة المهمة على النسخة الأساسية غير المتخصصة. ويشير القفز إلى 58% إلى أن RL مع تدقيق المكافآت يمنح أكثر مما يمنحه حجم النموذج. لكن المقارنة تجري على معيار أنشأه المؤلفون أنفسهم ضمن صيغتهم الخاصة، ولم تُدرَّب النماذج الرائدة (frontier) خصيصًا عليه. ويبدو التحسن البالغ 4,48 نقطة مئوية مقارنةً بـsmolagents أكثر تواضعًا بكثير من قفزة نموذج 4B، ومن المفيد أن يُنظر إلى هذين الرقمين معًا. كما أن استطلاع المراجعين لا يغني عن تجربة مع مستخدمين عاديين. والمؤلفون أنفسهم يحصرون استنتاجاتهم في «السيناريوهات المقيَّمة المعتمدة على قواعد البيانات».

أين يفيد هذا عمليًا

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

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

حتى الآن هذه ورقة من الإصدار v1 من النسخة الأولية (preprint)، وما زال يتعين التحقق من الشيفرة وإمكانية إعادة إنتاج النتائج والسلوك على بيانات خارج المجالات العشرة.