SoL-Pi ينقل كفاءة وكيل البرمجة إلى طبقة التشغيل المحيطة

SoL-Pi طبقة كفاءة جديدة لوكيل البرمجة مفتوح المصدر Pi، أصدرها باحثون من NVIDIA وNTU وMIT في 21 سبتمبر. التحول الرئيسي فيها معماري: فبدلا من تغيير النموذج أو وكيل Pi نفسه، تغيّر الطبقة المحيطة التي يعمل داخلها الوكيل. ويذكر المؤلفون أنه، في تقييم EdgeBench المؤلف من 51 مهمة، يخفض التكوين الكامل من SoL-Pi حركة الرموز بنسبة 44.7% إلى 49.0%، ويخفض تكلفة API بنحو 33%، مع الاحتفاظ بنحو 94% من متوسط نتيجة Pi.

من تغييرات النموذج إلى تغييرات طبقة التشغيل

يستهدف العمل نقطة ضغط مألوفة في وكلاء البرمجة: فتفاعلهم المتكرر مع البيئات يمكن أن يولد سجلات طويلة، وملاحظات مكررة، واستدعاءات مكلفة للنموذج. ولا تدعي SoL-Pi أنها تقدم نموذج برمجة جديدا. بل توصف بأنها إضافة بترخيص MIT تعمل مع إصدار غير معدل من Pi. وقد استخدمت الاختبارات المعلنة Pi 0.85.1 وNode.js 22.19 أو أحدث.

هذا التمييز مهم لأن تحسين الكفاءة في وكلاء البرمجة يمكن أن يحدث على مستويات عدة. يمكن لموفر النموذج أن يغير النموذج. ويمكن لمطور الوكيل أن يبدل منطق التخطيط أو استخدام الأدوات. ويمكن لمشغل معيار قياس أن يقيس الأداء الشامل في بيئة ثابتة. تقع SoL-Pi في الطبقة الثانية المحيطة بالوكيل، لكن الأرقام المنشورة تظل نتائج معيار قياس معلنة من المؤلفين، وليست قياسات مستقلة.

استخدم الباحثون عملية بحث آلي بالذكاء الاصطناعي للعثور على آليات كفاءة. ووفقا للورقة، استكشفت تلك العملية 152 اتجاها عبر ست عائلات، و535 بيئة قابلة للتنفيذ، وأكثر من 3,000 تشغيل، وأكثر من 60,000 تفاعل بين الوكيل والبيئة. ومن ذلك البحث بقيت أربع آليات: Action Fusion وOnline Context Compact وObservationPack وEvidence-Preserving Reducer.

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

أربع آليات حول Pi

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

تعالج Online Context Compact السياق المحمول خلال تشغيل الوكيل. فكثيرا ما تراكم وكلاء البرمجة معلومات أثناء فحص الملفات، وتشغيل الأوامر، ورصد المخرجات، ومراجعة الخطط. ويشير موقع الآلية المعلن في SoL-Pi إلى أنها تضغط السياق أثناء التشغيل، بهدف خفض حركة الرموز مع الحفاظ على معلومات كافية ليواصل الوكيل حل المهام. أما ObservationPack فهي آلية أخرى من جانب طبقة التشغيل؛ ويدل اسمها على الاهتمام بكيفية تغليف الملاحظات القادمة من البيئة قبل وصولها إلى الوكيل.

في حلقة وكيل البرمجة، يمكن أن تكون الملاحظات الخام مطولة، أو مكررة، أو رديئة البنية بالنسبة إلى استدعاء النموذج التالي. وتعد ObservationPack جزءا من الحزمة التي يقول المؤلفون إنها تخفض حركة الرموز، لكن المعطيات المختصرة لا تدعم وصفا أدق لاختيارات التنسيق فيها. أما Evidence-Preserving Reducer فهي الآلية الرابعة التي بقيت. ويبرز اسمها مفاضلة مركزية في ضغط أنظمة الوكلاء: فتقليل النص يمكن أن يزيل معلومات يتبين لاحقا أنها مطلوبة. وبالحفاظ على الأدلة، توضع هذه الآلية كحاجز ضد ضغط الأساس الذي تقوم عليه القرارات وإزالته.

ما تظهره أرقام معايير القياس

على EdgeBench، تتمثل النتيجة الرئيسية التي أعلنها المؤلفون في خفض حركة الرموز بنسبة 44.7% إلى 49.0% للحزمة الكاملة من SoL-Pi. ويذكر التقييم نفسه انخفاضا بنحو 33% في تكلفة API. وبما أن تكلفة API ترتبط باستدعاءات النموذج واستخدام الرموز، فالنتيجة متسقة مع هدف النظام: تقليل مقدار النص وفائض التفاعل المرسل عبر حلقة الوكيل، مع الحفاظ على جزء كبير من نتيجة معيار القياس.

رقم الأداء المحتفظ به مهم أيضا. يذكر المؤلفون أن SoL-Pi يحتفظ بنحو 94% من متوسط نتيجة Pi في تقييم EdgeBench المؤلف من 51 مهمة. وهذا لا يعني أن الأداء لم يتغير، كما أنه ليس تحققا مستقلا. بل يعني أنه، في الشروط التي أعلنها المؤلفون، جاءت التخفيضات من جانب طبقة التشغيل مع خسارة مقاسة في النتيجة مقارنة بـ Pi، مع الحفاظ رغم ذلك على معظم متوسط النتيجة.

يوفر Terminal-Bench 4 نقطة بيانات ثانية معلنة وبشكل مختلف. هناك، حلت SoL-Pi عدد 15 مهمة مقارنة بـ 18 مهمة لـ Pi، مع خفض التكلفة الإجمالية بنسبة 26.3%. وتعرض هذه النتيجة المفاضلة بشكل أوضح: عدد أقل من المهام المحلولة مقابل تكلفة إجمالية أدنى. كما تحذر من قراءة خفض التكلفة على EdgeBench باعتباره مكسبا عاما بلا مقابل عبر معايير القياس.

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

الدلالات العملية والحدود

الدلالة العملية هي أن مشغلي وكلاء البرمجة قد يجدون موضعا آخر للبحث عن الكفاءة: طبقة تشغيل البيئة. فإذا كانت الملاحظات المتكررة، والسياق المطول، وأنماط الإجراءات غير الفعالة من محركات التكلفة الرئيسية، فيمكن لغلاف محيط أن يقلل الاستخدام من دون تغيير إصدار الوكيل نفسه. ويكتسب ترخيص MIT الخاص بـ SoL-Pi وتوافقها مع Pi غير المعدل أهمية هنا لأنهما يجعلان النهج إضافة قابلة للفصل لا تصميما لوكيل متفرع.

في الوقت نفسه، تبقى الأدلة محدودة بمعايير القياس المعلنة. أرقام EdgeBench نتائج أبلغ عنها المؤلفون على 51 مهمة. وأرقام Terminal-Bench 4 أبلغ عنها المؤلفون أيضا وتظهر عددا أقل من المهام المحلولة مقارنة بـ Pi. وكانت عملية البحث الآلي واسعة بالأرقام المقدمة، لكنها لا تحل محل التكرار المستقل. وتظهر الأرقام مفاضلة معلنة بين الكفاءة والأداء ضمن اختبارات محددة؛ لكنها لا تثبت أن كل أعباء عمل وكلاء البرمجة ستشهد خفض التكلفة نفسه أو النتيجة المحتفظ بها نفسها.

النقطة الأوسع منهجية. تعيد SoL-Pi صياغة جزء من تحسين وكلاء البرمجة بوصفه هندسة لطبقة التشغيل: التحكم في الإجراءات، وضغط السياق، وتغليف الملاحظات، وتقليل الأدلة من دون إسقاط المعلومات اللازمة للتصرف. والنتيجة البارزة هي تكلفة API أقل بنحو الثلث على EdgeBench كما أعلن المؤلفون، لكن السؤال الأطول بقاء هو ما إذا كان يمكن قياس هذه الآليات من جانب طبقة التشغيل باتساق عبر الوكلاء والنماذج والمهام، من دون إخفاء أنماط الفشل خلف الضغط.