Unsloth وLlama 3: كيف تعلّم النموذج استدعاء واجهات API بثبات عبر JSON

أصدر موقع Machine Learning Mastery دليلاً لضبط Llama 3 ضبطاً دقيقاً على استدعاء أدوات (tool calling) خاص بك، باستخدام مكتبة Unsloth بلغة Python. وتُصاغ المشكلة الأساسية في السطر الأول نفسه: يتعامل Llama 3 جيداً مع طيف واسع من المهام، لكن هذه السعة لا تكفي لوكيل (agent) يُفترض أن يُخرج JSON منظماً وموثوقاً لواجهة API محددة. يكفي أن يسقط معامل واحد، أو تظهر عبارة زائدة قبل القوس المعقوف، حتى يفشل استدعاء الدالة. والمتاح لنا من المقال مقطع قصير يعرض صياغة المهمة فقط، لذلك نستعرض أدناه النهج المعتاد في معالجتها، ولا نعيد سرد المقال سطراً بسطر.

لماذا يكسر النموذج العام الاستدعاءات

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

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

ماذا يقدّم Unsloth

Unsloth مكتبة مفتوحة المصدر لتسريع الضبط الدقيق لنماذج LLM. ويعلن مطوّروها تسريعاً حتى 2 مرات وخفضاً في استهلاك ذاكرة الرسوميات حتى 70% مقارنة بالحزمة القياسية. وهذه أرقام المشروع نفسه وليست قياسات مستقلة، وقد تختلف على عتادك. أما الفائدة العملية فتكمن في أمر آخر: يتيح الجمع مع QLoRA الاحتفاظ بالأوزان الأساسية بصيغة 4 بت وتدريب محوّلات LoRA الصغيرة فقط. وفي هذا الوضع يتسع نموذج بـ 8 مليارات معامل لبطاقة رسومات واحدة بذاكرة 16 غيغابايت، مثل T4 في Colab المجاني.

المجموعة المعتادة لهذه المهمة:

• الأساس: Llama 3 8B Instruct
• الطريقة: LoRA أو QLoRA مع تكميم الأوزان الأساسية بدقة 4 بت
• البيانات: أزواج «طلب ← استدعاء دالة» بصيغة JSON مطابقة تماماً لمخطط API الخاص بك
• الحزمة: Python وUnsloth وHugging Face Datasets وTRL (SFTTrainer)
• العتاد: وحدة GPU واحدة بذاكرة 16 غيغابايت أو أكثر
• المخرج: محوّل (adapter) لا يشغل سوى جزء صغير من حجم النموذج الكامل؛ وعند الحاجة يُدمج مع النموذج الأساسي ويُصدَّر بصيغة GGUF لاستخدامه في llama.cpp أو Ollama

أين تكمن المزالق

يتصل الخطر الرئيسي بالبيانات. إذا كُتبت أمثلة التدريب بإهمال، تتعلم النموذج هذا الإهمال بالثقة نفسها. ويجب أن يطابق قالب المحادثة (chat template) أثناء التدريب ما يُستخدم عند الاستدلال (inference)، بما في ذلك الرموز الخاصة في Llama 3. والتباين هنا هو السبب الأكثر شيوعاً لعبارة «اشتغل في الدفتر ولم يشتغل في الإنتاج».

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

المشكلة الثالثة هي التقييم. فخسارة التدريب (loss) لا تقول الكثير عن جودة الوكيل. المطلوب مجموعة اختبار مستبقاة وثلاثة مقاييس: نسبة JSON الصالح نحوياً، ودقة اختيار الدالة، ودقة قيم المعاملات.

التطبيق العملي

ابدأ بحجم صغير. اجمع من 300 إلى 500 مثال عالي الجودة من السجلات الفعلية، وصنّفها وفق المخطط، وأبقِ حتماً من 10 إلى 20% للتحقق. شغّل QLoRA على نموذج 8B وقارن النتيجة بـ Llama 3 الأساسي الذي تتضمن موجّهاته (prompt) مخططات الدوال نفسها. إذا كان التحسن في صلاحية JSON ودقة المعاملات ملحوظاً، فوسّع مجموعة البيانات. وإن لم يكن كذلك، فتحقق من قالب المحادثة وجودة التصنيف.

لا يحل الضبط الدقيق محل constrained decoding. فالتوليد وفق قواعد نحوية أو مخطط JSON يضمن سلامة الصيغة، بينما يتولى الضبط الدقيق الجانب الدلالي: أي دالة تُختار وماذا يوضع في المعاملات. ويعطي الجمع بين النهجين النتيجة الأكثر قابلية للتنبؤ. كما أن Llama 3 لم يعد جديداً بحلول 2026، لكن الوصفة نفسها قابلة للنقل إلى نماذج أخرى يدعمها Unsloth.