مشفّر بـ17 مليون معامل يختار الأداة خلال 14 مللي ثانية على CPU

تبدو الخطوة الأخيرة في كثير من مسارات LLM متواضعة: اختيار خيار واحد من مجموعة معروفة سلفًا. أي أداة يجب استدعاؤها، وتحت أي وسم يُصنَّف الطلب، وإلى أي مسار يُوجَّه. عادةً يُنفَّذ ذلك عبر prompt إلى نموذج كبير، وهو أسلوب بطيء ومكلف وحساس لترتيب الخيارات. اختبر Tardelli Ronan Coelho Stekel إلى أي حد يمكن تصغير المشفّر لهذه المهمة، ونشر عائلة Crivo المؤلفة من ستة نماذج، من 17 مليون إلى مليار معامل، في متناول الجميع.

أبرز الأرقام: يتفوق نموذجا 68M و150M على مصنِّف DeBERTa-v3 zero-shot بحجم 435M معامل بمقدار 4,9 و5,9 نقطة في الدقة على 209 مهام من System1-Arena، خضعت لتدقيق التداخل مع بيانات التدريب. وعلى 145 مهمة لم تظهر للنماذج أثناء التدريب، تحافظ على مستوى DeBERTa على الأقل. أما أصغر نموذج، 17M، فيستجيب للطلب خلال 14 مللي ثانية بالوسيط على 16 خيط معالجة من CPU. وفي الظروف نفسها يبلغ الزمن الوسيط لمصنِّف DeBERTa 728 مللي ثانية.

قراءة الخيارات معًا أم واحدًا واحدًا

السؤال الثاني في الدراسة أهم لمعماريي الأنظمة. يمكن تغذية المشفّر بجميع الخيارات دفعة واحدة (joint)، أو تقييم كل خيار على حدة مقترنًا بالطلب (per-option). أجرى المؤلف دراسة بثلاث بذور عشوائية (seeds) على نموذج بحجم 32M معامل، على عيّنة مُستبقاة من مجموعة تضم 37 اختبارًا معياريًا (benchmark).

يتفوق per-option بمقدار 5,8 نقطة من المهارة المصحَّحة بالنسبة إلى الصدفة عند تساوي عدد خطوات المُحسِّن (optimizer). وعند تقارب تكاليف التدريب الحسابية تقريبًا، يتقلص الفارق إلى 2,8 نقطة. ويؤكد اختباران معياريان خارجيان اتجاه الأثر، لكن الفارق على المهام غير المرئية ليس ذا دلالة إحصائية.

هذه الميزة ليست دائمة. فهي لا تظهر إلا عند التهيئة انطلاقًا من reranker: إذ يتطابق دخله على شكل زوج «طلب — مرشَّح» مع الطريقة التي يقرأ بها نهج per-option الخيارات. أما إذا بدأ التدريب من مشفّر خام، فلا يمكن التمييز بين النهجين.

ثمن الدقة ونقطة ضعف joint

يتطلب per-option عددًا أكبر من تمريرات المشفّر بمقدار 5–13 مرة. وبحسب الزمن الوسيط لا تتجاوز الخسارة الضعف، لكنها تتخطى أربعة أضعاف بحسب الزمن المتوسط، إذ تضرب قوائم الخيارات الطويلة «ذيل» التوزيع. لهذا السبب اقتصر الإصدار على نماذج joint.

وفي نهج joint عيب مقيس: تغيير ترتيب الخيارات يبدّل 12–23% من الإجابات. أما في نهج per-option فلا توجد هذه التبعية، ولا تتغير الإجابات إطلاقًا. وهذه حجة جدية للإنتاج: ينبغي ألا يؤثر ترتيب الأدوات في القائمة على الاختيار، لكنه يؤثر هنا.

حتى 68M معامل، تتصدر نماذج Crivo فئتها الحجمية على لوحة المتصدرين (leaderboard) العامة. ويجري التقييم على اختبارات خاصة، قريبة في معظمها من توزيع التدريب، ولذلك فهي نتيجة قوية للمهام الشبيهة بمهام التدريب، لكنها لا تضمن انتقال الأداء إلى مهام أخرى.

ماذا في الإصدار

• عائلة Crivo: ستة مشفّرات joint مفتوحة من 17M إلى 1B معامل، ضمن مجموعة على Hugging Face (tardellirs/crivo).
• 68M و150M: تفوق بمقدار 4,9 و5,9 نقطة في الدقة على DeBERTa-v3 (435M، zero-shot) في 209 مهام من System1-Arena.
• 145 مهمة غير مرئية: تعادل مع DeBERTa-v3 على الأقل.
• 17M: زمن وسيط 14 مللي ثانية على 16 خيط معالجة من CPU مقابل 728 مللي ثانية لدى DeBERTa-v3.
• دراسة 32M: per-option أفضل من joint بمقدار 5,8 نقطة عند تساوي الخطوات و2,8 عند تساوي الحوسبة، بثلاث بذور عشوائية و37 اختبارًا معياريًا.
• كلفة per-option: عدد تمريرات أكبر بمقدار 5–13 مرة، وحتى 2× في الزمن الوسيط وأكثر من 4× في الزمن المتوسط.
• الحساسية للترتيب: يتغير 12–23% من إجابات joint عند تبديل ترتيب الخيارات.
• الكود والنتائج منشوران في مستودع crivo-decision-encoders على GitHub.

أين يفيد ذلك

في توجيه الطلبات بين النماذج، واختيار الوكيل (agent) للأداة، والتصنيف ضمن مجموعة مغلقة من الوسوم، توفّر هذه المشفّرات بديلًا رخيصًا عن استدعاء LLM. ويكفي نموذج 17M زمن 14 مللي ثانية على معالج عادي دون GPU، وهذا يغيّر الاقتصاديات: يمكن اتخاذ القرار في كل خطوة من حلقة الوكيل، بدلًا من تجميعه في طلب مستقل مكلف.

والخلاصات العملية كالتالي. إذا كان الثبات مهمًا، فالأجدر إما عشوائية ترتيب الخيارات وحساب متوسط النتائج، وإما استخدام نهج per-option مع القبول بارتفاع زمن الاستجابة في الذيل. وإذا كنتم تدربون هذا الاختيار بأنفسكم، فابدأوا من reranker: فمن مشفّر خام لا يمكن الحصول على مكسب من القراءة واحدًا واحدًا. وقبل التطبيق ينبغي تشغيل النموذج على مهامكم الخاصة: فالتعادل على بيانات غير مرئية يعني «ليس أسوأ من DeBERTa» لا التفوق عليه، وأكبر الفوارق تحققت حيث يقترب التوزيع من توزيع التدريب.