تنقد هذه الورقة موثوقية معايير قياس وكلاء استخدام الحاسوب الحالية من خلال تحديد العيوب المنهجية في بناء المهام، والملاحظة، والتسجيل التي تؤدي إلى أحكام فشل خاطئة، وتقترح إطاراً تشخيصياً وقواعد تصميم لتحسين دقة التقييم.
تخيل أنك تشاهد مسابقة طبخ عالية المخاطر على التلفاز. من المفترض أن يقوم الحكام بتذوق الأطباق لتحديد الفائز. ولكن ماذا لو كان الحكام يستخدمون اختبار تذوق معطلاً؟ ماذا لو كانت الوصفة التي يتبعونها مكتوبة بحبر يختفي، أو أن الفرن الذي يستخدمونه هو في الواقع لعبة لا تسخن؟ في عالم الذكاء الاصطناعي، وتحديداً "وكلاء استخدام الكمبيوتر" (البوتات الذكية التي يمكنها النقر، والكتابة، وتصفح الويب تماماً مثل البشر)، نواجه مشكلة مماثلة. يتم اختبار هذه البوتات لمعرفة ما إذا كانت قادرة على أداء وظائف حقيقية، مثل تقديم الإقرارات الضريبية أو حجز الرحلات الجوية. ومع ذلك، فإن "بطاقات تسجيل الدرجات" التي نستخدمها لتقييمهم غالباً ما تكون معيبة. فقد تعطي درجة رسوب لبوت قام بعمل رائع بالفعل، أو قد تغفل عن حقيقة أن البوت فشل لأن الاختبار نفسه كان معطلاً. هذه الورقة البحثية تشبه قصة بوليسية حيث يحقق المؤلفون في سبب قيام بطاقات التسجيل هذه بتضليلنا.
الورقة التي تحمل عنوان "كيف تخطئ المعايير المرجعية في تقييم وكلاء استخدام الكمبيوتر"، تجادل بأن الطريقة التي نختبر بها هذه البوتات حالياً معيبة للغاية. وجد المؤلفون أنه عندما يحصل البوت على نتيجة "فشل" (FAIL)، فهناك احتمال كبير ومفاجئ بأن النتيجة خاطئة في الواقع. وفي تحقيقهم في 150 حالة محددة حيث تم تصنيف البوتات كفاشلة، اكتشفوا أن 15.3% من أحكام "الفشل" تلك كانت أخطاءً.
إليك كيف حدثت هذه الأخطاء:
القاضي كان شديد التدقيق (10.7%): في بعض الأحيان فعل البوت الشيء الصحيح، لكن الفاحص الآلي كان جامداً للغاية. كان الأمر يشبه إخفاق قاضٍ لشيف لأنه استخدم سكيناً مختلفاً قليلاً عن السكين المذكور في بطاقة الوصفة، رغم أن الطعام كان مذاقه مثالياً.
الاختبار كان معطلاً (4.7%): في بعض الأحيان لم يستطع البوت إنهاء المهمة لأن بيئة الاختبار كانت معطلة. كان الأمر يشبه مطالبة شيف بخبز كعكة في فرن لا يعمل. لقد فشل البوت، ولكن ليس لأنه سيء في الطبخ؛ بل لأن المطبخ كان معطلاً.
نظر المؤلفون أيضاً إلى البوتات التي فشلت بالفعل. ووجدوا أن الأسباب الرئيسية لم تكن عادةً بسبب نقر البوت على الزر الخطأ (وهو ما يشبه اليد الخرقاء). بدلاً من ذلك، فشلت البوتات في الغالب لأنها علقت في حلقة مفرغة من التخطيط السيئ أو لأنها لم تدرك أن أفعالها لا تؤتي ثمارها (مثل الشيف الذي يستمر في تحريك قدر فارغ بالفعل).
تقترح الورقة أننا لا يمكننا فقط النظر إلى رقم واحد، مثل "معدل النجاح"، لنعرف ما إذا كان الذكاء الاصطناعي جيداً أم لا. هذا الرقم يخفي الكثير من الأسرار. بدلاً من ذلك، نحن بحاجة إلى بناء اختبارات أصعب في الكسر، واستخدام حكام أكثر ذكاءً يفهمون طرقاً مختلفة لحل المشكلات، وتوفير تسجيلات فيديو كاملة للاختبارات حتى نتمكن من رؤية أين سارت الأمور بشكل خاطئ بالضبط. الهدف هو التوقف عن إعطاء البوتات درجة رسوب لأشياء ليست خطأها، ومساعدتنا على فهم ما يحتاجون لتعلمه حقاً ليصبحوا مساعدين مفيدين حقاً.
ملخص تقني: كيف تخطئ الاختبارات المعيارية في تقييم وكلاء استخدام الحاسوب
1. بيان المشكلة
يتم نشر وكلاء استخدام الحاسوب (CUAs) بشكل متزايد للتنقل عبر واجهات الويب وتشغيل برامج سطح المكتب. ومع ذلك، يعتمد تقييمهم بشكل كبير على "أوراكل" (oracles) نصية هشة أو مبرمجة مسبقًا تقوم بفحص الحالات النهائية، أو الروابط (URLs)، أو حقول الـ DOM. وهذا يخلق "فجوة بين النشر والقياس"، لا سيما مع تطور المهام من حلقات قصيرة إلى سير عمل طويل الأمد وعابر للتطبيقات.
تتمثل المشكلة الجوهرية المحددة في أن درجة الاختبار المعياري ليست ملاحظة مباشرة للقدرة، بل هي نتاج خط إنتاج معقد. هذا الخط معرض لأربعة أنماط فشل متميزة تشوه التقييم:
بناء المهام: مهام قديمة، أو تعليمات مسربة، أو بيئات معطلة (مثل: بيانات اعتماد منتهية الصلاحية، أو تغير في المواقع الحية).
التسجيل (Scoring): مقيمون يرفضون الحلول البديلة الصحيحة أو يكافئون الصحة السطحية التي تم تحقيقها عبر طرق مختصرة غير صالحة.
التقرير: معدلات النجاح الإجمالية التي تحجب الأسباب المحددة للفشل، مما يمنع التحسينات الهندسية المستهدفة.
إن دمج هذه المشكلات المتميزة في فئة واحدة وهي "فشل الوكيل" يؤدي إلى سوء ترتيب الأنظمة وتوجيه الجهود الهندسية بشكل خاطئ.
2. المنهجية
يقترح المؤلفون إطار عمل موثوقية رباعي المراحل لتقييم وكلاء استخدام الحاسوب (CUA): بناء المهمة، بيئة التنفيذ، التسجيل، والتقرير. وللتحقق من صحة هذا الإطار، أجروا تدقيقًا تجريبيًا لـ 150 مسارًا مسجلًا بدرجة فشل من خمسة اختبارات معيارية تشمل التنقل عبر الويب، وسير العمل المؤسسي، والتحكم في سطح المكتب (OSWorld، WebArena، VisualWebArena، WorkArena، وAssistantBench).
إجراء التدقيق
العينات: تم اختيار المسارات التي سجلت مكافأة تراكمية قدرها صفر (فشل - FAIL).
التوسيم (Labeling): قام حكمان من نماذج اللغة الكبيرة المدعومة بالرؤية (GPT-5.5 وClaude Sonnet) بمراجعة المسارات الكاملة بشكل مستقل، بما في ذلك الاستدلال، الإجراءات، ولقطات الشاشة. وقد تم ضبط أحكامهما بواسطة مجموعتين بشريتين راجعتا مجموعة فرعية من البيانات دون معرفة مسبقة بالنتائج.
منطق القرار:
المرحلة 1 (صحة الحكم): تحديد ما إذا كان "الفشل" هو فشل حقيقي للوكيل، أم خطأ سلبي من المقيم (الوكيل نجح ولكن تم رفضه)، أم مهمة معطلة (مشاكل في البيئة/المواصفات)، أم حالة غير واضحة.
المرحلة 2 (التشخيص): بالنسبة لحالات الفشل الحقيقية، تم تطبيق تصنيف تشخيصي ثلاثي المستويات (مقتبس من MAST) لتحديد موقع أول فشل حاسم:
المستوى 1 (التخطيط/المواصفات): انتهاكات، حلقات تكرارية، أو ميزات متخيلة.
المستوى 2 (التنفيذ/التجذر): إحداثيات غير صحيحة، فقدان الحالة، أو أخطاء في وسائط الأدوات.
المستوى 3 (التحقق/التغذية الراجعة): إنهاء مبكر، تفويت التحقق، أو تكرار أعمى للتغذية الراجعة (عمليات لا تؤدي لنتيجة - no-ops).
3. النتائج الرئيسية
موثوقية الحكم
كشف التدقيق أن 15.3% من أحكام "الفشل" المسجلة كانت غير صحيحة.
10.7% كانت أخطاء سلبية من المقيم: أكمل الوكيل المهمة، لكن النص البرمجي أو الفاحص رفض بدائل صحيحة (على سبيل المثال، رفض مطابقة النصوص في WebArena لإجابات دلالية صحيحة).
4.7% كانت مهام معطلة: كانت المهمة غير قابلة للتحقيق بسبب مشاções في البيئة (مثل: محركات بحث معطلة، جدران CAPTCHA، أو ملفات نظام فارغة في الآلة الافتراضية).
3.3% ظلت غير واضحة بسبب نقص الأدلة المنشورة.
تشخيصات الفشل
من بين 122 حالة فشل حقيقية للوكيل، أخفت نسبة النجاح الرقمية توزيعًا منحرفًا لأنواع الأخطاء:
المستوى 3 (التحقق/التغذية الراجعة): 39.3% من حالات الفشل. الفئة الفرعية المهيمنة كانت التكرار الأعمى للتغذية الراجعة (29.5%)، حيث كرر الوكلاء الإجراءات رغم عدم تغير حالة الشاشة.
المستوى 1 (التخطيط/المواصفات): 35.2% من حالات الفشل، مدفوعة بانتهاكات المواصفات وحلقات التخطيط.
المستوى 2 (التنفيذ/التجذر): 13.9% فقط من حالات الفشل.
تأثير القدرة على الملاحظة: أدى حذف لقطات الشاشة من بيانات التدقيق إلى تقليل القدرة على اكتشاف الأخطاء السلبية وخفض الاتفاق بين الحكام، مما يثبت أن المسارات التي تتضمن لقطات الشاشة ضرورية للتدقيق الصحيح.
4. الإرشادات التصميمية والمساهمات
بناءً على هذه النتائج، يستخلص البحث قواعد تصميمية خاصة بكل مرحلة لضمان موثوقية الاختبارات المعيارية لوكلاء استخدام الحاسوب:
بناء المهمة: الانتقال نحو "مجمعات مهام حية" مع تحديث إجرائي لمنع التشبع. يجب تأليف المهام من قبل خبراء في المجال لضمان الصلاحية المهنية، ويجب إصدار نسخ (versioning) للمهام/البيئات/الأوراكل معًا.
البيئة: يجب تثبيت وتوضيح حزمة التنفيذ (نظام التشغيل، إصدارات التطبيقات، الهياكل الداعمة) لضمان قابلية التكرار. كما يجب التصريح بحدود الاسترجاع بوضوح لمنع التلوث.
التسجيل (Scoring): يجب أن تختبر الفواحص بالضبط ما تعلنه المهمة، مع قبول جميع الحلول الصالحة ضمن النطاق المحدد. يجب أن ينتقل التسجيل من فحوصات النتيجة فقط إلى حكام معايرين يعتمدون على القواعد (rubrics) لتقييم العملية.
التقرير: يجب أن تنشر الاختبارات المعيارية مسارات كاملة الأدلة (لقطات الشاشة، مدخلات ومخرجات الأدوات، الطوابع الزمنية) جنبًا إلى جنب مع الدرجات. يجب أن تتضمن التقارير تشخيصًا لموقع الفشل ومرحلة العملية، وليس فقط معدلات النجاح الإجمالية. بالإضافة إلى ذلك، يجب التعامل مع زمن الاستجابة (معدلات تجاوز الموعد النهائي) والتكلفة (الدولارات لكل نجاح مُتحقق منه) كمعايير أساسية.
5. الأهمية والنطاق
يجادل البحث بأن حكم فشل وكيل استخدام الحاسوب يستوجب عدم الثقة عندما تتعارض أدلة إعادة التشغيل مع الفاحص أو تكشف عن ظروف غير صالحة للمهمة. ويرى أن الاعتماد الحالي على معدلات النجاح الرقمية يحجب الطبيعة الحقيقية لمحدودية الوكلاء، لا سيما في التحقق والتخطيط.
النطاق والقيود:
تقتصر الادعاءات التجريبية على تقييم واجهة المستخدم الرسومية (GUI) عبر الويب، سطح المكتب، وسير العمل المؤسسي.
يغطي التدقيق 150 مسارًا؛ ورغم أن حجم العينة متواضع، إلا أن فترات الثقة الواسعة لا تزال تشير إلى أن أخطاء المقيم تحدث بمعدل ملموس.
تركز الدراسة على الأخطاء السلبية (النجاحات المفقودة) ولا تقدر الأخطاء الإيجابية (الوكلاء الذين نجحوا خطأً)، حيث تم أخذ عينات من المسارات المسجلة بالفشل فقط.
لا يقترح البحث بنيات جديدة للوكلاء، بل يدعو إلى إصلاح في كيفية بناء وتفسير بنية التقييم التحتية لدعم الحوكمة القائمة على الأدلة.