تقنية Bridged Self-Distillation تعلّم النماذج الصغيرة الاستدلال من أي معلّم، حتى عبر API

تواجه عملية تقطير الاستدلال من نموذج قوي إلى نموذج صغير مشكلتين منذ وقت طويل. الأولى أن الطالب لا يستطيع تكرار حلول المعلّم. والثانية أن احتمالات الرموز لدى المعلّم إما غير متوافقة مع مفرداته، وإما غير متاحة أصلًا. يقترح مؤلفو ورقة Bridged Self-Distillation (BSD) مخططًا موحّدًا يغطي ثلاثة سيناريوهات دفعة واحدة: معلّم بـ tokenizer مطابق، ومعلّم بـ tokenizer مختلف، ونموذج مغلق خلف API. ولا يُطلب من المعلّم سوى أمر واحد: إخراج نص الاستدلال.

أين يفشل التقطير المعتاد

يقوم تقطير on-policy على منطق واضح. يولّد الطالب الإجابات بنفسه، ويقيّمها المعلّم، فيجري التدريب على التوزيع الذي ينتجه الطالب فعليًا. وهذا يزيل الفجوة بين بيانات التدريب وسلوك النموذج عند الاستدلال (inference). لكن لهذه الطريقة قيودًا.

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

كيف تتجاوز BSD عدم توافق الرموز

الفكرة أن يُستبعد المعلّم من الحلقة ولا يبقى فيها سوى نصّه. يكتب معلّم خارجي مسبقًا أثر استدلال (reasoning trace)، ويمكن فعل ذلك دون اتصال ومرة واحدة فقط. يصبح هذا الأثر سياقًا مميّزًا (privileged context).

بعد ذلك تعمل نسختان من النموذج نفسه. يولّد الطالب الـ rollouts دون الوصول إلى الأثر، كما سيفعل في المهام الحقيقية. أما النسخة الثانية، وهي self-teacher، فتتلقى الأثر نفسه ضمن سياقها وتقيّم هذه الـ rollouts تحديدًا. يُعبَّر عن التقييم في فضاء رموز الطالب نفسه، ولذلك تختفي مشكلة توافق المفردات: يقارن النموذج نفسه بنفسه، مرة مع التلميح ومرة بدونه.

ويتخذ المدقّق (verifier) القرار النهائي. يُستخدم التوجيه على مستوى الرموز من self-teacher لتصحيح التحديثات في الـ rollouts الفاشلة. أما المحاولات الناجحة فتؤكدها إشارة النتيجة الخارجية، وتحصل المحاولات الخاطئة على تلميح موضعي يبيّن أين انحرف الاستدلال.

لا يُطلب من المعلّم الخارجي سوى النص، ولذلك تكون إجراءات التدريب واحدة في جميع السيناريوهات. ولا حاجة إلى إعادة كتابة خط المعالجة (pipeline) لكل زوج من النماذج.

ما المعروف عن الإعداد والنتائج

• ثلاثة سيناريوهات للمعلّم: tokenizer مشترك، وtokenizers مختلفة، وAPI مغلق.
• المدخل من المعلّم: نص الاستدلال فقط، ويمكن توليده دون اتصال.
• الأدوار: يولّد الطالب الـ rollouts بلا سياق، ويقيّمها self-teacher (نسخة من الطالب مع الأثر).
• الإشارة: توجيه على مستوى الرموز إضافةً إلى الحكم النهائي للمدقّق.
• الاستخدام: تصحيح التحديثات في الـ rollouts الفاشلة.
• النتيجة بحسب ما يذكره المؤلفون: تحسّن BSD النموذج الأساسي وتتفوق على الطرق المرجعية المصمَّمة لكل سيناريو على حدة.
• الكود منشور على GitHub ضمن حساب TUMLegalTech.

لمن تفيد هذه الطريقة الآن

تكمن القيمة العملية الأساسية في أن الطريقة تلغي الاعتماد على البنية الداخلية للمعلّم. يمكن لفريق يريد رفع مستوى نموذج مفتوح صغير في الرياضيات أو البرمجة أو أي مجال آخر قابل للتحقق أن يأخذ الـ traces من أي نموذج frontier عبر API عادي. ولا يحتاج لذلك إلى اللوجيتات ولا إلى tokenizer متوافق ولا إلى اتفاقات خاصة مع المزوّد.

الميزة الثانية تتعلق بالتكلفة. تُولَّد الـ traces دون اتصال ومرة واحدة، ولذلك لا حاجة إلى إبقاء المعلّم الباهظ في حلقة التدريب. فهو يتقاضى ثمن النص فقط، بينما يجري الجزء الأكبر من الحوسبة على النموذج الصغير نفسه.

والقيد واضح أيضًا: يعتمد المخطط على المدقّق. وحيث يمكن التحقق من الإجابة آليًا (مسائل ذات نتيجة قاطعة، واختبارات للكود)، تنسجم الطريقة مع المهمة بشكل طبيعي. أما المهام المفتوحة التي لا نتيجة قابلة للتحقق فيها، فسيتعيّن التفكير في بديل للمدقّق.

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