RiseHarness يعلّم وكلاء الطرفية إصلاح غلافهم التشغيلي دون إعادة تدريب

قد ينجح وكيل الطرفية في حل مهمة من المحاولة الأولى ويفشل فيها في الثانية، مع أن النموذج والتعليمات (prompt) والإعدادات لم تتغير. هذا التذبذب بالذات هو ما يستهدفه RiseHarness، وهو إطار ورد في ورقة بحثية ضمن Hugging Face Daily Papers، ويعيد كتابة الغلاف التشغيلي للوكيل (harness) على دورات متتالية مع تجميد كامل لأوزان النموذج. لا يورد المؤلفون في الملخص نتائج رقمية، ولذلك لا يمكن تقييم سوى المنهج نفسه، وهو منهج عملي إلى حد بعيد.

الفجوة بين «القدرة» و«الأداء الموثوق»

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

لذلك لا يطارد RiseHarness المهام التي لا يستطيع النموذج حلها أبدًا. ما يهمّه هو المهام «المتقلبة» (flipping tasks)، أي تلك التي تضم تشغيلاتها نتائج ناجحة وفاشلة معًا. يصبح التشغيل الناجح مرجعًا يُقارن به التشغيل الفاشل. وبهذا يسهل التمييز بين مشكلة منهجية في الغلاف وسوء الحظ.

كيف تعمل الدورة

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

ولربط الملاحظات بالشيفرة الفعلية، يُستخدم Harness Handbook. فهو يطابق الأدلة المستخلصة من التشغيلات مع سلوك الغلاف وشيفرته المصدرية. يساعد ذلك على اكتشاف المشكلات المتكررة في الآليات المشتركة بين مهام كثيرة، بدلًا من ترقيع حالات فردية.

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

ما المعروف عن المنهج

• لا تتغير أوزان النموذج، ويجري تحسين الغلاف وحده.
• وحدة التكييف هي نموذج بعينه، وليست «وكيلًا مجردًا بوجه عام».
• تُمنح الأولوية للمهام ذات النتائج المختلطة في ظل الإعدادات نفسها.
• مصدرا الإشارة: مسارات تنفيذ الوكيل وتتبّعات مراقب وقت التشغيل.
• لا تُقبل التعديلات إلا بعد الفحوص السلوكية وإعادة التشغيل.
• التقييم: النجاح والموثوقية عبر نماذج مختلفة، وتجارب الاستئصال (ablations) على تتبّعات التنفيذ وعلى البحث الخارجي، وانتقال التحسينات إلى معايير أداء غير مألوفة مع النموذج نفسه.

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

ما الذي يمكن الاستفادة منه عمليًا

ثلاثة أمور مفيدة للفرق التي تبني وكلاء البرمجة ووكلاء الطرفية. أولًا، قياس الاستقرار وليس pass@1 وحده: شغّلوا كل مهمة عدة مرات، وتابعوا بشكل منفصل المهام التي تعطي نتائج مختلطة. ثانيًا، سجّلوا الأحداث الداخلية للغلاف إلى جانب إجراءات النموذج. فمن دون تتبّعات التنفيذ والتغذية الراجعة وقرارات الإنهاء، يتحول تحليل الفشل إلى تخمين. ثالثًا، أعيدوا النظر في الغلاف عند تغيير النموذج: فبحسب منطق المؤلفين، لا يلزم أن تناسب الآليات التي عملت جيدًا مع نموذج ما نموذجًا آخر.

والقيود واضحة أيضًا. فالمنهج يتطلب كثيرًا من إعادة التشغيل، أي ميزانية حوسبة كبيرة، ويعتمد على جودة المراقب. أما مدى انسجام الآليات «المستعارة» بعد تكييفها مع بعضها، فستكشفه تجارب الاستئصال في النص الكامل. لكن الفكرة نفسها تبدو عملية: جزء من عدم موثوقية الوكلاء يكمن في الغلاف، ويمكن إصلاحه هندسيًا دون المساس بالأوزان.