Evaluating RL Explainability Methods by How Much They Help Fix Bugs in Agents
تقترح هذه الورقة EvalXRL، وهو معيار مرجعي جديد يقيم أساليب التعلم المعزز القابل للتفسير (XRL) بناءً على فائدتها العملية في مساعدة وكيل برمجة يعتمد على النماذج اللغوية الكبيرة (LLM) لتشخيص وإصلاح وكلاء التعلم المعزز المتعطلين بشكل تكراري، متجاوزاً بذلك المقاييس التقليدية إلى تقييم مغلق الحلقة ومدفوع بالنتائج.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالم الذكاء الاصطناعي، هناك مجال متنامٍ مخصص لجعل أنظمة تعلم الآلة مفهومة. هذه الأنظمة، التي تُسمى غالباً "وكلاء" (agents)، تتعلم اتخاذ القرارات من خلال تجربة أفعال مختلفة ورؤية ما يحدث، وهي عملية تُعرف باسم "التعلم التعزيزي". في بعض الأحيان، تعمل هذه الوكلاء بشكل مثالي، ولكن في أحيان أخرى تفشل بطرق غريبة، حيث تقع في حلقات مفرغة أو تتخذ خيارات تبدو غير عقلانية تماماً. وعندما يحدث هذا، يحتاج المطورون إلى معرفة السبب؛ فهم بحاجة إلى تفسيرات لا تكتفي بوصف ما فعله الوكيل فحسب، بل يحتاجون إلى فهم الأسباب الكامنة وراء ذلك حتى يتمكنوا من إصلاح المشكلة. لسنوات طويلة، حاول الباحثون قياس مدى جودة هذه التفسيرات عبر سؤال الناس عما إذا كانوا يشعرون بالفهم، أو عبر التحقق مما إذا كان التفسير يتطابق مع الرياضيات الداخلية للكمبيوتر. لكن الشعور بالفهم ليس هو نفسه القدرة الفعلية على إصلاح آلة معطلة.
يقترح مقترح جديد من فريق من الباحثين طريقة أكثر عملية للحكم على أدوات التفسير هذه. فبدلاً من سؤال الناس عن شعورهم، يقترحون اختبار ما إذا كانت التفسيرات تساعد المبرمج بالفعل في إصلاح وكيل معطل. الفكرة الجوهرية بسيطة: إذا كان التفسير مفيداً حقاً، فيجب أن يساعد شخصاً ما على تحديد الخطأ المحدد في الكود وإصلاحه، مما يؤدي إلى آلة أفضل أداءً. ينقل هذا النهج التركيز من النظريات المجردة للفهم إلى نتيجة وظيفية ملموسة. يطلق الباحثون على الاختبار المقترح اسم "EvalXRL". وهو مصمم ليكون معياراً قياسياً تُوضع فيه طرق التفسير المختلفة تحت الاختبار النهائي: هل يمكنها مساعدة وكيل برمجيات في العث ورتق خطأ (bug) في وكيل برمجيات آخر؟
لقد صمم الباحثون تجربة منضبطة حيث يقومون بتعطيل وكلاء التعلم التعزيزي عمداً. إنهم ينشئون أخطاءً محددة ومعروفة في الكود، مثل تغيير كيفية تلقي الوكيل للمكافآت أو تعديل البيئة التي يعمل فيها. على سبيل المثال، قد يبرمجون وكيلاً يبحث عن الكنوز ليعطي قيمة للعملات الصغيرة أكثر من الكبيرة، أو قد يخدعون نظام تحكم في حركة المرور لإنشاء طوابير طويلة من السيارات لمجرد جعل حركة المرال تبدو سريعة في ثانية واحدة. وبمجرد تعطيل هؤلاء الوكلاء، يقدم الباحثون مبرمج ذكاء اصطناعي، وهو نموذج لغوي كبير مدرب على كتابة وإصلاح البرمجيات. يُمنح هذا المبرمج إمكانية الوصول إلى الوكيل المعطل وأداة تفسير محددة. وتتمثل مهمة المبرمج في استخدام الأداة لمعرفة الخطأ، ومن ثم كتابة الكود لإصلاحه.
التجربة مُعدة كحلقة مغلقة. المبرمج لا يكتفي بالنظر إلى تفسير واحد والتخمين، بل يمكن للمبرمج أن يطلب من أداة التفسير معلومات، ويحلل الإجابة، ويصيغ نظرية جديدة حول ما هو معطل، ثم يطلب من الأداة مرة أخرى بسؤال أو إعداد مختلف. هذه العملية المتبادلة تحاكي كيف قد يعمل المهندس البشري، حيث يختبر الفرضيات حتى يتم حل المشكلة. يستخدم الباحثون بيئة كمبيوتر معزولة (sandbox) لضمان عدم قدرة المبرمج على الغش عبر البحث عن الإجابات على الإنترنت؛ فالطريقة الوحيدة التي يمكن للمبرمج من خلالها النجاح هي استخدام أداة التفسير بفعالية. ويُقاس نجاح كل طريقة تفسير بمدى جودة أداء الوكيل بعد الإصلاح. فإذا بدأ الوكيل في العمل بشكل صحيح وتحقيق درجات عالية، تُعتبر أداة التفسير ناجحة. أما إذا ظل الوكيل معطلاً أو أصبح أسوأ، فتُعتبر الأداة أقل فائدة.
يخطط الفريق لاختبار مجموعة متنوعة من طرق التفسير، بدءاً من الخرائط المرئية التي تسلط الضوء على الأجزاء المهمة من صورة ما، وصولاً إلى الأوصاف النصية التي تشرح سبب اتخاذ الوكيل لقرار معين. وسيقارنون هذه الطرق مقابل طرفين متطرفين: "خط الأساس" حيث لا يملك المبرمج أي أداة تفسير ويجب عليه التخمين بناءً على الكود الخام، وحالة "المرجع" حيث يُقال للمبرمج ببساطة ما هو الخطأ بلغة واضحة. يسمح هذا الإعداد لهم برؤية ما إذا كانت أدوات التفسير تقدم أي قيمة حقيقية تتجاوز مجرد امتلاك الكود المصدري، ومدى اقترابها من السيناريو المثالي المتمثل في معرفة الإجابة فوراً.
لدى الباحثين ثلاثة توقعات رئيسية لكيفية سير هذا المعيار القياسي. أولاً، يشتبهون في أنه لن تكون هناك أداة تفسير واحدة هي الأفضل في إصلاح كل أنواع الأخطاء؛ فقد تكون بعض الأدوات رائعة في العثور على الأخطاء المتعلقة بكيفية حساب المكافآت، بينما قد تكون أدوات أخرى أفضل في رصد المشكلات المتعلقة بكيفية إدراك الوكيل لبيئته. وهذا يعني أن المجال يحتاج إلى مجموعة متنوعة من الأدوات بدلاً من حل واحد شامل. ثانياً، يتوقعون أنه حتى عندما يتم إخبار المبرمج بالضبط ما هو الخطأ، فقد لا يتمكن دائماً من إصلاحه بشكل مثالي، وهذا سيظهر أن تشخيص المشكلة ليس سوى نصف المعركة؛ إذ إن هندسة الحل الفعلي غالباً ما تكون الجزء الأصعب. وأخيراً، وهو أمر قد يكون مفاجئاً، يتوقعون أن بعض أدوات التفسير قد تجعل الأمور أسوأ؛ فقد تعطي الأداة تفسيراً واثقاً ولكنه مضلل يرسل المبرمج في المسار الخاطئ، مما يتسبب في إصلاح الجزء الخطأ من الكود. وهذا سيثبت أن التفسير المكتوب جيداً ليس دائماً تفسيراً مفيداً.
هذا المقترح هو حالياً خطة لدراسة مستقبلية، وليس مجموعة مكتملة من النتائج. يعرض الباحثون تصميمهم وفرضياتهم على المجتمع العلمي لجمع الملاحظات قبل إجراء التجربة الكاملة. إنهم يطلبون المدخلات حول ما إذا كانت أنواع الأخطاء التي اختاروها هي الأكثر أهمية للممارسين، وما إذا كان استخدام مبرمج ذكاء اصطناعي يعد بديلاً عادلاً لمهندس بشري. كما يقرون بأنه بينما يتميز مبرمجو الذكاء الاصطناعي بالسرعة وقلة التكلفة، إلا أنهم قد لا يفكرون تماماً مثل البشر. ومع ذلك، يجادلون بأنه مع أتمتة المزيد من الأعمال الهندسية، يصبح فهم كيفية مساعدة هذه الأدوات لوكلاء الذكاء الاصطناعي في إصلاح وكلاء ذكاء اصطناعي آخرين أمراً بالغ الأهمية في حد ذاته.
الهدف النهائي من هذا العمل هو نقل مجال الذكاء الاصطناعي القابل للتفسير بعيداً عن التقييمات الذاتية ونحو الإثبات الوظيفي الموضوعي. ومن خلال قياس النجاح بناءً على القدرة على إصلاح نظام معطل، يأمل الباحثون في إنشاء معيار يوضح بوضوح أي طرق التفسير مفيدة حقاً. إذا نجح نهجهم، فقد يوفر طريقة موثوقة لتصنيف العديد من الأدوات المتاحة حالياً، مما يساعد المطورين على اختيار الأداة المناسبة للمهمة. إنه يقدم مساراً نحو مستقبل لا نسأل فيه فقط عما إذا كان الذكاء الاصطناعي منطقياً بالنسبة لنا، بل عما إذا كان يساعدنا في بناء أنظمة أفضل وأكثر موثوقية.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.