HuggingGPT: كيف يقود ChatGPT فريقاً من النماذج المتخصّصة على Hugging Face

الملاحظة التي بنى عليها HuggingGPT بسيطة لكنها قوية: كل نموذج على Hugging Face مُرفَق بوصف نصّي يشرح ما يفعله. نموذج اكتشاف الأجسام يقول «أكتشف الأجسام في الصور»، ونموذج تحويل النص إلى كلام يقول «أحوّل النص إلى صوت». هذه الأوصاف مكتوبة بلغة طبيعية — وهذا بالضبط ما يُتقنه النموذج اللغوي الكبير.

السؤال الذي طرحه المؤلّفون: ماذا لو وضعنا أوصاف النماذج هذه في موجّه ChatGPT وتركناه يلعب دور الموزّع؟ المستخدم يصف ما يريد بكلام عادي، وChatGPT يقرأ أوصاف النماذج ويختار المناسب منها ويستدعيها بالترتيب الصحيح ويربط مخرجاتها ببعضها. بهذا تتحوّل اللغة نفسها إلى طبقة وسيطة — الصمغ الذي يربط بين محرّك التفكير ومئات النماذج المتخصّصة.

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

لنأخذ مثالاً عملياً. يُرسل المستخدم طلباً مثل «اكتشف وضعية الشخص في هذه الصورة، ثم ولّد صورة جديدة لفتاة تقرأ بنفس الوضعية، ثم صِف الصورة الجديدة بصوت مسموع». أول ما يفعله HuggingGPT هو تمرير هذا الطلب إلى ChatGPT ليُفكّكه إلى قائمة مهام فرعية بصيغة JSON. كل مهمة تحمل نوعاً (مثل «اكتشاف وضعية» أو «تحويل نص إلى كلام»)، ومعرّفاً فريداً، وقائمة اعتماديات تربطها بمهام سابقة، ومدخلات تُحدّد ما تعمل عليه.

الترابط بين المهام هو المفتاح. في المثال السابق، مهمة توليد الصورة لا تستطيع أن تبدأ قبل أن تنتهي مهمة اكتشاف الوضعية وتُخرج نتيجتها. لحل هذه المشكلة يستخدم HuggingGPT وسماً خاصاً اسمه <resource>: أثناء التخطيط، إذا احتاجت المهمة الثانية مخرج الأولى، تُكتَب مدخلاتها على شكل <resource>-1 كعنصر نائب. وحين يحين وقت التنفيذ، يُستبدل هذا العنصر تلقائياً بالمخرج الحقيقي — سواء كان ملف صورة أو نصاً.

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

بعد أن تصبح خطة المهام جاهزة، يأتي السؤال: أيّ نموذج بالتحديد يُنفّذ كل مهمة؟ المشكلة أن Hugging Face تضمّ آلاف النماذج، ووضعها جميعاً في الموجّه يتجاوز نافذة السياق المتاحة. الحل هو تصفية على مرحلتين.

المرحلة الأولى: تصفية بحسب نوع المهمة — إذا كانت المهمة اكتشاف أجسام، لا يُعرض إلا نماذج اكتشاف الأجسام. المرحلة الثانية: ترتيب النماذج المتبقّية بحسب عدد التنزيلات — كمؤشر تقريبي على الجودة والموثوقية — واختيار أعلى K نموذج فقط. أوصاف هذه النماذج المرشّحة (الاسم والبيانات الوصفية ووصف الوظيفة) تُوضع في الموجّه، ويختار ChatGPT الأنسب بينها ويُخرج اختياره ككائن JSON مع مبرّراته.

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

الآن وقد تحدّد لكل مهمة نموذجها، يبدأ التنفيذ الفعلي. التحدّي هنا هو إدارة تدفق البيانات بين المهام: حين تحتاج مهمة لاحقة مخرج مهمة سابقة، يستبدل HuggingGPT العناصر النائبة <resource>-task_id بالمخرجات الحقيقية قبل إطلاقها.

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

على صعيد البنية التحتية، يتبع HuggingGPT استراتيجية هجينة: النماذج كثيرة الاستخدام أو الثقيلة تعمل على خوادم محلية لتقليل زمن الاستجابة، بينما النماذج الأقل شيوعاً تعمل عبر واجهة الاستدلال السحابية لـ Hugging Face. الأولوية للنقاط المحلية، ولا يلجأ النظام إلى السحابة إلا حين لا يكون النموذج منشوراً محلياً.

حين تنتهي جميع النماذج من عملها، يجمع HuggingGPT مخرجاتها المُهيكلة — مربعات الإحاطة مع درجات الثقة، والصور المُولَّدة، والنصوص المنسوخة، وتوزيعات الإجابات — ويُعيدها إلى ChatGPT مرفقة بسجل التنفيذ الكامل. مهمة ChatGPT هنا هي صياغة كل هذه النتائج في إجابة واحدة بلغة طبيعية تردّ على طلب المستخدم الأصلي.

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

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

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

النتائج تكشف فجوة واضحة في القدرات. حقّق GPT-3.5 دقة 52.6% على المهام المفردة، وF1 بقيمة 51.9 على المهام المتسلسلة، و50.5 نقطة على مهام الرسم البياني — وهو تفوّق كبير على النماذج المفتوحة مثل Alpaca-7b (دقة 6.5%) وVicuna-7b (دقة 23.9%). واللافت أنه حتى GPT-4 لم يتجاوز 41.4% دقة على المهام المتسلسلة في مجموعة بيانات مُعنونة بشرياً لطلبات شديدة التعقيد، وهذا يوضّح أن التخطيط الموثوق لا يزال تحدياً حقيقياً.

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

التقييم البشري على 130 طلباً متنوعاً أكّد هذه النتائج: GPT-3.5 نجح في إنتاج خطة قابلة للتنفيذ في 91.2% من الحالات، لكن معدل النجاح الإجمالي — أي أن الاستجابة النهائية فعلاً حلّت المشكلة — كان 63.1%. النماذج المفتوحة تخلّفت بفارق كبير، إذ لم يتجاوز Alpaca-13b نسبة 6.9% نجاح.

يعترف المؤلفون بأربع نقاط ضعف جوهرية. الأولى أن كل شيء مرهون بجودة التخطيط — إذا أخطأ ChatGPT في فهم الطلب أو رسم اعتمادية غير صحيحة، ينهار الأنبوب كله ولا توجد آلية تصحيح ذاتي. الثانية هي زمن الاستجابة: كل طلب يمرّ بعدة استدعاءات لـ النموذج اللغوي (استدعاء للتخطيط، واستدعاء لكل عملية اختيار نموذج، واستدعاء لتوليد الاستجابة)، فضلاً عن وقت الاستدلال في النماذج المتخصّصة نفسها. الثالثة أن نافذة السياق تُحدّد سقف أوصاف النماذج التي يمكن حشرها في الموجّه، فتضيق مساحة الاختيار. الرابعة أن مخرجات النموذج اللغوي عشوائية بطبيعتها — قد يُنتج أحياناً JSON غير صالح أو يختار نموذجاً غير مناسب، فتقع أخطاء وقت التشغيل.

الإسهام الأعمق لـ HuggingGPT ليس النظام بحدّ ذاته، بل النمط المعماري الذي أرساه: افصل محرّك التفكير (النموذج اللغوي) عن محرّكات التنفيذ (النماذج المتخصّصة)، ودع اللغة الطبيعية تكون البروتوكول بينهما. هذا النمط صار في كل مكان اليوم — من استدعاء الدوال في ChatGPT إلى استخدام الأدوات في Claude إلى أُطر الوكلاء مفتوحة المصدر. الفكرة ببساطة أن النموذج اللغوي لا يحتاج أن يكون نموذج رؤية أو نموذج كلام — يكفي أن يعرف متى يستدعي واحداً منها. وهذه أصبحت الركيزة الأساسية لـ الذكاء الاصطناعي الوكيلي.