RSIHub يجمع 4 طرق لتطوير الوكلاء في إطار عمل واحد: حتى +13.5 نقطة مئوية

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

تطوير الوكيل كمجموعة أجزاء قابلة لإعادة الترتيب

تعمل عملية تطوير الوكلاء على النحو التالي: ينفّذ الوكيل المهام، ويجمع النظام ملاحظات التقييم، ثم يعيد اعتمادًا عليها كتابة الأوامر (prompts) أو المهارات أو الأدوات أو مخطط التنسيق. الفكرة بسيطة، لكن تطبيقاتها تُصمَّم عادةً لتناسب ورقة بحثية بعينها، ولا تتوافق مع بعضها.

في RSIHub تُوصَف الطريقة بوصفها «وصفة». تتكوّن الوصفة من عوامل (operators) قابلة لإعادة الاستخدام، وتعلن صراحةً أي الموارد يمكن تغييره. وتتولى المنصة كل ما عدا ذلك: التنفيذ والتقييم والتعافي من الأعطال وتتبّع أصل المرشحين (lineage). ولا يكتب الباحث سوى سياسة التطور، أي أنه يقرر ما الذي يخضع للطفرة ومن يبقى.

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

أربع طرق على أساس واحد

نفّذ المؤلفون الطرق دون إجراء أي تعديل على نواة الإطار. وبقيت كل الخصوصيات داخل الوصفات والعوامل. وهذا هو الاختبار العملي الرئيسي لقابلية التركيب.

• AHE — أول طريقة لتطوير الوكلاء أُعيد إنتاجها.
• Hyperagents — نهج للوكلاء الذين يعدّلون أنفسهم.
• A-Evolve — طريقة لتطوير الوكلاء قائمة على الملاحظات المرتدة.
• GEPA — طريقة للتحسين عبر التأمل في نتائج التنفيذ.

جاءت بيئة التقييم على النحو التالي:

• هياكل الوكلاء: MiniSWE وCodex.
• المعايير: Terminal Bench 2 (مهام في الطرفية) وτ³ Banking (سيناريوهات مصرفية).
• الظروف: إعدادات ثابتة للنموذج والمقيِّم، حتى يتحدد الفارق بطريقة التطوير وحدها.
• المقياس الرئيسي: pass@1 الإجمالي.
• أفضل نتيجة: +13.5 نقطة مئوية في pass@1.

حيث تخالف الأرقام التوقعات

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

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

ما العمل بهذه النتائج

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

وتنبع القواعد العملية من النتائج نفسها. احتفظوا بعيّنة محجوزة وقيّموا عليها، لا على مهام التحسين وحدها. ولا تعتمدوا على ترتيب معيار واحد. واحفظوا lineage لكل مرشح لتعرفوا أي تغيير أعطى المكسب. الشيفرة مفتوحة على GitHub (simple-agent-lab/RSIHub)، وقد حصد المشروع 186 نجمة، ويدعو المؤلفون إلى المساهمة بطرق تطوير ومعايير جديدة. وإذا ظهرت وصفات جديدة في المنظومة، فسيملك المجتمع وسيلة مشتركة للتحقق من أيها يعمل خارج حدود ورقة بحثية واحدة.