AWS تستعرض كيفية ضبط Amazon Nova عبر Nova Forge SDK وSageMaker Jobs

عرضت AWS سيناريو عمليًا لتخصيص نماذج Amazon Nova عبر Nova Forge SDK وAmazon SageMaker AI. يمرّ الفريق في الدليل بالدورة الكاملة: من التقييم الأساسي للنموذج، مرورًا بـ SFT وRFT، وصولًا إلى إطلاق endpoint خاص للاستدلال (inference).

السيناريو والبيانات

تقدّم AWS أداة Nova Forge SDK بوصفها طبقة تزيل الجزء الأكثر مللًا في تخصيص LLM: إعداد البنية التحتية، واختيار الصور (images)، والتحقق من الإعدادات، وتشغيل وصفات التدريب. وبدلًا من بناء خط المعالجة (pipeline) يدويًا، يحصل المطوّر على مجموعة مكوّنات جاهزة لتحميل مجموعة البيانات، وتحويل صيغتها، وإطلاق job في SageMaker، ثم تقييم النتيجة.

لا يعتمد المقال على مثال تجريبي بسيط، بل على مهمة تطبيقية واضحة: التصنيف الآلي لأسئلة Stack Overflow بحسب جودتها. اعتمدت AWS في التجربة على مجموعة بيانات Stack Overflow Question Quality التي تضم 60 ألف سؤال للفترة 2016–2020، واختارت منها عشوائيًا 4700 سجل. كان على النموذج أن يصنّف كل سؤال في إحدى ثلاث فئات: HQ أو LQ_EDIT أو LQ_CLOSE. خُصّص 3500 مثال لـ SFT و500 للتقييم، واستُخدم لـ RFT 700 مثال متخصص إضافي، أُضيفت إليها كل سجلات SFT البالغة 3500 كي لا يفقد النموذج صيغة الإجابة التي تعلّمها.

كيف جرى التدريب

تنقسم التجربة إلى أربع خطوات: تقييم خط الأساس (baseline) لنموذج Nova 2.0 المدرَّب مسبقًا، ثم الضبط الخاضع للإشراف (supervised fine-tuning)، يليه الضبط بالتعلم المعزَّز (reinforcement fine-tuning)، وأخيرًا النشر على Amazon SageMaker AI Inference. لتحميل ملفات CSV والتحقق من المخطط وتحويل البيانات تستخدم AWS الفئة CSVDatasetLoader، ولتشغيل العمليات الحسابية تستخدم SMTJRuntimeManager.

يعمل SFT في المثال على أربع نسخ من ml.p5.48xlarge، وتستطيع الأداة التحقق مسبقًا من توافق البيئة والمعاملات، لتفادي اكتشاف الأخطاء بعد بدء الـ job.

• يوضح خط الأساس (baseline) سلوك النموذج دون ضبط إضافي
• يعلّم SFT النموذج الصيغة الصحيحة ونمط الإجابة الخاص بالمجال
• يُحسّن RFT الحل عبر دالة المكافأة (reward)
• يمكن إجراء النشر إما في Bedrock أو في SageMaker

أضافت AWS لـ RFT دالة مكافأة بسيطة عبر Lambda: +1 للفئة الصحيحة و-1 للفئة الخاطئة. أُطلق الضبط فوق نقطة حفظ (checkpoint) SFT على نسختين من ml.p5.48xlarge، وجاء التشغيل قصيرًا: 40 خطوة فقط. كما حدّد الفريق طول المخرجات وأضاف عقوبة KL كي لا يبتعد النموذج كثيرًا عن السلوك الذي ثبّته SFT. أي أن الأداة هنا ليست مجرد غلاف للتشغيل، بل نقطة موحّدة لإعداد البيانات والتدريب والسجلات والنشر.

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

الجزء الأكثر فائدة في المقال هو الأرقام. أظهر نموذج Nova 2.0 الأساسي نسبة 13% فقط في exact match على مهمة ثلاثية الفئات، كان التخمين العشوائي فيها سيحقق نحو 33,3%. وحتى عند تجاهل إسهاب الإجابات واستخراج وسم الفئة فقط من النص، بلغت الدقة 52,2%. وتفسّر AWS ذلك بمشكلتين: كان النموذج يميل بإفراط إلى كتابة شروحات طويلة بدلًا من وسم واحد، وكان منحازًا نحو الإجابة HQ بصرف النظر عن الجودة الفعلية للسؤال.

بعد SFT قصير ارتفع exact match إلى 77,2%، وارتفعت دقة التصنيف حسب الوسوم المستخرجة إلى 79,0%. أضافت المرحلة التالية، RFT، تحسنًا أصغر: ارتفع exact match إلى 78,8%، وquasi-EM إلى 80,6%، وF1 إلى 78,8%. لم يكن الكسب بعد مرحلة التعلم المعزَّز كبيرًا، لكنه كان ثابتًا في معظم المقاييس الرئيسية تقريبًا.

وتشير AWS بشكل منفصل إلى أن BLEU شبه عديم الفائدة في مثل هذه المهمة: فعندما يجيب النموذج برمز (token) واحد مثل HQ أو LQ_CLOSE، يكون من الأهم النظر إلى exact match وF1 بدلًا من تداخل n-grams.

ماذا يعني ذلك

لا تحاول AWS بيع نموذج آخر فحسب، بل مسارًا أقصر إلى ضبطه للاستخدام التطبيقي. وإذا كانت Nova Forge SDK تغطي فعلًا التحقق والتشغيل والمراقبة والنشر في واجهة واحدة، فسيكون من الأسهل على الفرق اختبار فرضياتها على مجموعات بيانات متخصصة دون «مهمة MLOps» مستقلة مع كل تكرار.