HarnessDev: النماذج اللغوية الكبيرة تبني بنيتها التحتية الخاصة
أطلقت ByteDance ومجموعة من الجامعات إطار عمل HarnessDev، وهو إطار يسمح للنماذج اللغوية الكبيرة (LLMs) بكتابة "أنظمة تشغيل الوكلاء" الخاصة بها، والتي تُسمى Agent Harnesses. يمنح الفريق النموذج اللغوي الكبير مجموعة أدوات أولية بسيطة ويتركه يكمل الباقي، مما يوضح كيف يمكن للذكاء الاصطناعي بناء طبقة التحكم التي تدير حلقات استخدام الأدوات الخاصة بها، وخطوات التحقق، ومعالجة الأخطاء — دون الحاجة إلى قيام إنسان بكتابة كل سطر.
لماذا تكمن أهمية بناء الـ harness ذاتياً
تطورت وكلاء الذكاء الاصطناعي (AI agents) من مساعدين يعتمدون على أمر واحد (single-prompt) إلى عمال يقومون بمهام متعددة الخطوات، حيث يستدعون واجهات برمجة التطبيقات (APIs)، ويستعلمون من قواعد البيانات، ويجمعون النتائج معاً. وحتى الآن، كان المطورون يصممون يدوياً كود التنسيق (orchestration code) الذي يخبر النموذج متى يستدعي أداة بحث، وكيف يخزن الحالة الوسيطة، وكيف يتحقق من الإجابة النهائية. يقلب HarnessDev هذا النموذج: حيث يوفر الـ seed harness مجرد هيكل أساسي — وظائف بسيطة للحلقات (looping)، واختيار الأدوات، وتتبع الحالة — ثم يقوم النموذج اللغوي الكبير بتوسيعها لتصبح بيئة تشغيل (runtime) كاملة الميزات.
في الاختبار المرجعي (benchmark) للورقة البحثية، أنتج النموذج 18 harness متميزة، مضيفاً أكثر من 17,000 سطر من الكود إلى الـ seed الأصلي. أدار كل harness دورة الحياة الكاملة للمهمة: تنفيذ الحلقات، واختيار الأداة المناسبة، والحفاظ على السياق، وتتبع الحالة، والتحقق من النتائج، والتعافي من الأخطاء.
التكاليف الخفية التي كشفت عنها الدراسة
تبدو الأرقام مثيرة للإعجاب، لكن المؤلفين يحذرون من أن التنفيذ الخام لا يعني بالضرورة الاستخدام العملي.
- مكونات غير مستخدمة – لم يتم تشغيل جزء كبير من الكود المُنشأ أثناء تنفيذ المهمة الفعلية. فقد كتب النموذج اللغوي الكبير وظائف لم يستدعِها الوكيل أبداً، مما أدى إلى تضخم قاعدة الكود دون تقديم أي قيمة.
- الارتباط بنموذج محدد (Model lock-in) – مالت الـ harnesses إلى أن تكون مضبوطة لتناسب النموذج اللغوي الكبير المحدد الذي أنشأها. وعندما تم تسليم نفس الـ harness إلى نموذج مختلف، انخفض الأداء بشكل ملحوظ، مما يشير إلى أن منطق التحكم المُنشأ تلقائياً يتضمن خصائص فريدة خاصة بالنموذج.
- فجوات التحقق – سجل أحد الـ test harnesses معدل نجاح بنسبة 99% (99 من أصل 100 عملية تشغيل) ولكنه كان صحيحاً بنسبة 48% فقط من الوقت. وبدون عملية تحقق قوية، يمكن للوكيل تقديم إجابات خاطئة بكل ثقة.
- عبء الـ tokens – تباين استخدام الـ tokens (وهو مقياس لتكلفة الحوسبة) بشكل كبير. تطلب أحد الـ harnesses عدد tokens أكثر بـ سبعة أضعاف من غيره لتحقيق نفس النتيجة، مما يثير مخاوف بشأن قابلية التوسع في بيئات الإنتاج.
تسلط هذه النتائج الضوء على الحاجة إلى تصميم منضبط، حتى عندما ينبثق الكود من نموذج لغوي كبير.
ما يجب على المطورين وضعه في الاعتبار
- عامل تصميم الـ harness كبنية هندسية (architecture) – لا تعتمد على النموذج لكي "يعمل فحسب". حدد وحدات (modules) واضحة للتحكم في الحلقات، واختيار الأدوات، ومعالجة الحالة، والتحقق قبل السماح للنموذج اللغوي الكبير بملئها.
- ابنِ نظام تحقق قوياً – أدرج عمليات تحقق صريحة تقارن ادعاء الوكيل بالحقيقة المرجعية (ground truth) أو بنموذج ثانوي. تُظهر دقة الدراسة البالغة 48% رغم معدل النجاح المبلغ عنه ذاتياً بنسبة 99% أن التحقق لا يمكن أن يكون مجرد فكرة لاحقة.
- راقب ميزانيات الـ tokens – يمكن للـ harnesses الأكثر تعقيداً أن تسبب تضخماً في عدد الـ tokens. قم بتحليل متغيرات الـ harness المختلفة في وقت مبكر لتجنب الانفجار المفاجئ في التكاليف الخفية.
- اختبر عبر نماذج مختلفة – قم بتشغيل نفس الـ harness مع عدة واجهات خلفية (back-ends) لنماذج لغوية كبيرة. إذا تدهور الأداء بشكل حاد، فقد تحتاج إلى تصميم أكثر استقلالية عن النموذج (model-agnostic) أو إنشاء harnesses منفصلة لكل نموذج.
الخلاصة: يثبت HarnessDev أن النماذج اللغوية الكبيرة يمكنها صياغة كود التحكم الخاص بها والذي يشبه أنظمة التشغيل.