سير العمل في الترميز بالذكاء الاصطناعي الوكيل باستخدام النماذج الصغيرة

حسنًا.

مرحبًا،

اسمي "خوسيه"، وأنا هنا مع "إيان" و"زوي".

جميعنا نعرف النماذج اللغوية الكبيرة.

نستخدمها في كل شيء: العثور على الوصفات، وتلخيص فيديوهات على YouTube، والترميز.

هناك نماذج لغوية كبيرة جدًا، مثل نماذج Gemini، قادرة على تنفيذ مهام مذهلة حقًا، ولكن في هذه المحاضرة، سنتحدّث عن النماذج اللغوية الصغيرة.

وهي أيضًا نماذج لغوية كبيرة لأنّ أي نموذج يحتوي على 4 مليار مَعلمة لا يمكن أن يكون صغيرًا، ولكننا سنميّز بينهما من الآن فصاعدًا، أي بين النماذج الرائدة والنماذج اللغوية الصغيرة، أو الصاروخ والدراجة.

سنناقش النماذج الصغيرة ليس بالضرورة كبديل للنماذج الرائدة، بل كعامل مكمّل لها.

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

للتحضير لهذه الجلسة، أجريتُ العديد من الاختبارات، وكان أحدها عبارة عن مجموعة بيانات تتضمّن 200 مهمة متوسطة وصعبة باستخدام ما يقرب من 131 مليون رمز مميز بتكلفة أقل من 9 دولارات.

استخدمتُ Gemma 4 لهذا الغرض، لذا كان بإمكاني تنزيله وتشغيله على جهازي الخاص مجانًا، ولكنني شغّلته على بوابة تجارية لإجراء مقارنة عادلة.

إذًا، كم تبلغ تكلفة النموذج الرائد؟

ويكون ذلك أكثر بحوالي 20 إلى 200 مرة حسب تخزين الرموز المميّزة مؤقتًا وعوامل أخرى.

لذا، قد لا تكون الدراجة أسرع وسيلة نقل، ولكنها بالتأكيد الأكثر كفاءة.

هذا صحيح.

والآن، السؤال البديهي هو ما الفرق في الجودة والدقة؟

في مجموعة البيانات هذه تحديدًا، يمكن لـ Gemma 4 حلّ %53 من المهام.

وهذا يعني شيئين.

إذا كنت تستخدم نموذجًا رائدًا لتنفيذ هذه المهام على اليمين، قد يكون ذلك مبالغًا فيه.

وإذا كنت تستخدم نموذجًا صغيرًا لتنفيذ هذه المهام على اليمين، عليك توجيه النموذج نحو حلّ أو استخدام نموذج أكبر.

في هذه الجلسة، نريد مساعدتك في الاستفادة بشكل أكبر من كل رمز مميّز.

ستشرح لك "زوي" كيفية اختيار نموذج صغير، وسيتحدث "إيان" عن نماذج Gemma لتفهم كيفية التفكير في ما يمكن أن تتيحه لك.

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

والآن، أترك الكلمة لـ "زوي".

شكرًا جزيلاً يا "خوسيه".

لذا، فإنّ استخدام نموذج واحد لكل شيء يشبه إلى حد ما استخدام مطرقة ثقيلة لكسر حبة جوز، أليس كذلك؟

إنّه فعّال، ولكنّه غير متناسب بعض الشيء.

لذا، عند التفكير في النماذج الصغيرة، يبدو الأمر وكأنّك توسّع مجموعة أدواتك.

لمعرفة ما عليك إدخاله في مهام سير العمل، عليك فتح مجموعة الأدوات والاطّلاع على ما هو متاح ومواصفاتها ومزاياها.

لذا، لاختيار النماذج الصغيرة، يجب أن تعرفها.

ونوع النموذج الذي يتبادر إلى ذهن معظم الأشخاص عند التفكير في نموذج لغوي هو نموذج لغوي ذاتي الانحدار.

وهذا النموذج ذاتي الانحدار لأنّه يستند إلى إدخال مقسّم إلى رموز مميّزة، ويختار الرمز المميّز التالي الأكثر احتمالاً من قائمة من الرموز المميّزة المرشّحة.

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

لذا، يمكننا العمل بشكل غير خطي.

يتبع نموذج الانتشار النهج نفسه، ولكنه يعمل على مجموعة من الرموز المميّزة في كل مرة.

يبدو الأمر تقريبًا مثل رسم تخطيطي يتم التركيز عليه.

وفي هذه الحالة، يعمل DiffusionGemma على أجزاء من 256 رمزًا مميزًا في المرة الواحدة.

وبالتالي، ستحصل على بطاقة تعمل على المجموعة بأكملها، ما يتيح لك إنشاء النتائج بوقت استجابة أقل.

حسنًا، تتضمّن مجموعة أدواتنا نماذج يمكنها الكتابة، أليس كذلك؟

إجابة خاطئة.

بشكل أساسي، تحوّل نماذج التضمين العناصر، مثل الصور أو النصوص أو أي مفهوم آخر، إلى متجهات.

وهذا يتيح لنا تحويل الإحداثيات إلى مساحة ذات أبعاد عالية تتيح لنا مقارنة عنصرَين من الناحية المفاهيمية.

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

لهذا السبب، تصبح القدرة على التحقّق من ارتباط مفهومَين ببعضهما بعضًا مجرّد عملية حسابية بسيطة بدلاً من تمرير النموذج، وهو ما يمكن القول إنّه أيضًا عملية حسابية بسيطة، ولكن هذا النموذج يتجاوز ذلك، أليس كذلك؟

وهناك نماذج أصغر حجمًا ومتخصّصة قادرة على تنفيذ مهمة واحدة، وتؤديها بشكل جيد جدًا.

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

حسنًا، هناك الكثير من الخيارات، أليس كذلك؟

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

إذًا، كيف يمكن اختيار نموذج صغير؟

لنبدأ بفتح مجموعة أدوات من النماذج الصغيرة المفتوحة المصدر التي يمكن تشغيلها على الجهاز، وهي نماذج Gemma.

حان دورك الآن، "إيان".

شكرًا لك، "زوي".

كما ذكر "خوسيه" في البداية، يمكن للنموذج اللغوي الصغير تنفيذ حوالي %50 من المهام تلقائيًا.

ولكن لماذا قد تختار نموذجًا محليًا على وجه التحديد؟

لذا، يتلخص الأمر في أربعة أشياء.

الأولى هي الخصوصية.

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

والثاني هو وقت الاستجابة.

لذلك، عندما يتم تحميل النموذج فعليًا في الذاكرة، سواء كانت ذاكرة الرسومات أو الذاكرة الموحّدة، ستحصل على ردّ فور انتهاء عملية الحوسبة.

وبالتالي، لا يتم إرسال الطلبات ذهابًا وعودة إلى الخوادم، ما يقلّل من وقت الاستجابة.

التالي هو التكلفة الهامشية الصفرية.

وبالتالي، تكون النماذج فعّالة من حيث التكلفة عندما تتمكّن من التحكّم في مكان تشغيلها.

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

ولن يتطلّب ذلك أي تكلفة، ولن تكون هناك أي تكاليف مفاجئة لواجهة برمجة التطبيقات في هذا الجزء.

وأخيرًا، الميزة الرابعة هي التشغيل بلا إنترنت.

تخيَّلوا أنّه يمكنكم استخدام هذه الميزة على متن طائرة أو قطار أو حافلة أو في مترو الأنفاق، أو في أي مكان يتوفّر فيه النموذج على جهازكم.

يبدو ذلك رائعًا، ولكن هناك نوعان من العوامل الرئيسية التي نحتاج إلى مراعاتها عند اتخاذ هذه القرارات.

الأول هو الذاكرة، والثاني هو السرعة.

إذا نظرنا إلى هذا المخطّط البياني، وإلى النموذجَين في الأسفل، أي 26B و31B، نلاحظ أنّ كليهما يتطلّب أكثر من 50 غيغابايت من ذاكرة الوصول العشوائي للفيديو ليعمل بتنسيق BF16، وهو تنسيق تكميم 16 بت.

لذا، يكمن التحدي هنا في أنّ هذا النموذج لن يتناسب مع الكثير من الأجهزة.

لذا، نستخدم عملية تُسمى "التقدير" لتقليص هذه الدقة إلى 4 بت في قيمة عائمة.

الآن أصبح الأمر أكثر منطقية.

نحن نتحدث عن 14 غيغابايت و17 غيغابايت، أليس كذلك؟

يمكن الآن تشغيل هذا النموذج على جهاز Mac بذاكرة موحّدة.

التحدي هنا هو أنّه في عملية التكميم العادية بعد التدريب، عند ضغط هذه الأوزان، ستفقد بعض الدقة في النموذج مقارنةً بالنموذج الأساسي، ولدينا أسلوب لمكافحة ذلك.

ويُعرف هذا التدريب باسم "التدريب المستند إلى التكميم".

وعندما نفعل ذلك، يتم تدريب النموذج على أنّه سيكون بهذه الأحجام الأصغر، وبالتالي يكون هناك فقدان أقل مقارنةً بذلك.

وبالتالي، نحصل على انخفاض بنسبة %75 في متطلبات ذاكرة الوصول العشوائي، ويمكن الآن تشغيل النموذج على هذه الأجهزة.

ونحن نخطو خطوة أخرى إلى الأمام.

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

لذلك، لدينا نوع من حقيبة التكميم المختلطة.

وبالتالي، ينخفض حجم نموذج Gemma E2B من 11.4 غيغابايت إلى 1.1 غيغابايت.

لذلك، أصبح الأمر الآن أكثر منطقية على الهواتف المتوسطة إلى العالية المواصفات.

المعيار التالي هو السرعة.

لذا، عند استخدام نموذج الانحدار الذاتي، كما ذكرت "زوي"، يتم توقُّع المجموعة التالية من الرموز المميّزة.

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

لذا، يمكنكم استخدام تقنية تُعرف باسم "فك الترميز التخميني".

ما سيحدث هو أنّ Gemini سيستخدم نموذجًا أصغر لصياغة المحتوى من أجل توقُّع عدد من الرموز المميّزة التي يتم التحقّق منها بعد ذلك من خلال نموذج أكبر.

ويعود السبب في نجاح ذلك في بنية Gemma 4 إلى أنّها تتشارك ذاكرة التخزين المؤقت نفسها لـ KV.

لذا، يمكنكم اعتبار ذلك بمثابة الذاكرة القصيرة المدى للنموذج.

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

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

لذا، يعتمد ذلك قليلاً على المهمة التي تؤديها.

لذلك، لا يعمل هذا بشكل جيد في أشياء مثل الكتابة الإبداعية، لأن هناك المزيد من التباين، ولكنه يعمل بشكل جيد للغاية في أشياء يمكن التنبؤ بها مثل هياكل JSON والترميز.

إذًا، كيف يمكنك تقييم أحد هذه النماذج؟

لذا، فإنّ الإجراء الأكثر وضوحًا الذي قد تتّخذه هو الاطّلاع على مقياس أداء، مثل LiveCodeBench أو MMLU، والاطّلاع على النتيجة.

لكنّ ذلك لن يقدّم لكم سوى مؤشر عام حول قدرات النموذج.

ما عليك فعله حقًا هو تقييم المجموعة الكاملة التي يتم تشغيلها فيها.

هذا هو النموذج الذي تستخدمه، والأوزان ونهج التكميم، وهو استنتاج وقت التشغيل، لذا قد تستخدم شيئًا مثل llama.cpp أو Ollama أو LiteRT، ونظام توجيه الوكلاء الذي تستخدمه، سواء كان مثل Pi أو OpenCode أو Antigravity، ثم نافذة السياق، وهي نوع من المساحة لجميع البيانات التي تريد أن يتمكن نموذجك من معالجتها.

ويؤدي الجمع بين كل هذه الأمور إلى تحديد ما إذا كان المشروع قابلاً للتنفيذ.

على سبيل المثال، كنّا نُجري بعض الاختبارات باستخدام Gemma 4 على Android Bench، وكنّا نستخدم إصدار Ollama بسياق تلقائي يبلغ 32 ألفًا.

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

لذا، من خلال زيادة السياق من 32 ألف إلى 256 ألف، أصبح بإمكانه الآن الاحتفاظ بذلك في الذاكرة، وأصبح النموذج قادرًا على اجتياز هذا الاختبار المحدد.

وقد شهدنا تضاعفًا في معدّل النجاح في هذه المهمة تحديدًا.

لذا، يوضح هذا أن واحدًا من هذه العوامل الصغيرة يمكن أن يكون له تأثير كبير على ما إذا كان هذا النموذج مناسبًا أم لا.

إذًا، كيف يمكنك إجراء تقييماتك الخاصة؟

إليك ثلاثة اقتراحات سريعة.

أولاً، يمكنك استخدام سجلّ Git، أي مجموعة من طلبات السحب الناجحة التي لديك، واستخدامها كمدخلات للنموذج ومعرفة مدى جودة أدائه في هذه الطلبات.

بعد ذلك، تحتاج إلى أداة تقييم حتمية تساعدك في تقييم ما إذا كان ناتج النموذج صحيحًا أم لا.

لدينا مثالان جيدان على ذلك.

لدينا برنامج تجميع واختبارات وحدة.

أيًا كان ما يتم إنشاؤه، يمكنك تشغيله من خلال ذلك، وسيخبرك بنوع النجاح/الفشل فيما يتعلق بما إذا كنت قد حققت نجاحًا من هذه المهمة المحددة.

والثالث هو مسارات السجلّ.

لذلك، عند تشغيل وكيل، يجب أن تكون قادرًا على تتبُّع السلوكيات المختلفة التي يتّبعها الوكيل، ومعرفة أين ينجح وأين يفشل، ويمكنك استخدام ذلك لتقييم مدى قدرة النموذج على التفاعل واستخدام الأدوات.

وأريد منكم محاولة تغيير صياغة السؤال من "هل هذا النموذج ذكي مثل هذا النموذج الرائد الكبير؟"

إلى، "هل هذه المهمة ممكنة على هذا الجهاز بهذا التكوين المحدد؟"

ولمعرفة ذلك، ابتكرنا إطار عمل يُسمى "هل وصلنا؟"

أو AWTY.

ويتمحور هذا الإطار حول تقييم هذه المهام المختلفة على هذا المحور من حيث مدى جاهزيتها.

أي النموذج نفسه ومحرّك الاستنتاج المستخدَم ومجموعة الاختبار وإعدادات الأجهزة

وسيخبرك ذلك ما إذا كنت مستعدًا بعد.

على سبيل المثال، قد تبحث في مدى موثوقية هذه المهمة المحددة.

إذا قمت بتشغيله، كما تعلم، 10 مرات متتالية، فهل يفعل الشيء نفسه في كل مرة؟

قد تكون مهتمًا بوقت الاستجابة.

ربما تحتاج إلى أن يكون ردًا في الوقت الفعلي.

لذا، كما تعلم، ما هي حدودك مثل سرعة القيام بالمهمة؟

وبعد ذلك، قد تبحث في متطلبات ذاكرة الوصول العشوائي (RAM).

لذا، لا يقتصر الأمر على ذاكرة الوصول العشوائي (RAM) التي يمتلكها الجهاز، بل يشمل أيضًا ذاكرة الوصول العشوائي (RAM) التي يمكن استخدامها، والتطبيقات والأدوات الأخرى التي ستحتاج أيضًا إلى تشغيلها على هذا الجهاز.

لذا، هل يمكنك استخدام %50 أو %10 فقط من ذاكرة الوصول العشوائي؟

وستحصل على هذا النوع النهائي من نتيجة الاستعداد للتمرّن.

لذا، إذا كان لونه أخضر، فهذا يعني أنّ الإعداد جاهز للاستخدام.

إذا كان برتقاليًا أو أصفر أو أحمر، يعني ذلك أنّه عليك تغيير بعض الإعدادات.

قد تحتاج إلى مسرّع أسرع لتقليل وقت الاستجابة، أو إلى نموذج أكبر وأكثر قدرة.

لذا، أقترح عليك إلقاء نظرة على هذا.

لدينا نسخة حصرية في الوقت الحالي ونودّ معرفة رأيك بشأن مدى فائدة هذه الأداة.

ستشرح "زوي" المزيد عن كيفية إعداد بعض التقييمات لاحقًا، ولكن سأترك الكلمة الآن لـ "خوسيه" الذي سيعرض لكم طريقة سريعة جدًا لبدء استخدام Gemma 4.

شكرًا لك يا "إيان".

لذا، أسرع طريقة لتجربة Gemma 4 اليوم هي على الأرجح من خلال Android Studio.

لذا، سأوضّح لك كيفية إجراء ذلك.

لننتقل إلى الكمبيوتر المحمول.

هيا بنا

إذا انتقلتُ إلى صفحة "مقدّمو النماذج" في الإعدادات واخترتُ Gemma، سأحصل على فكرة واضحة عن حجم كل نموذج.

ما عليّ سوى تنزيل النماذج على محرك الأقراص الثابتة.

يؤدي ذلك إلى فتح خادم llama.cpp أو تشغيله، ويتم ضبطه بشكل صحيح من البداية.

ويمكنك أيضًا استخدام خادم llama.cpp الخاص بك أو Ollama أو LM Studio، أيًا كان ما تريده.

لذلك، ما عليك سوى الانتقال إلى هنا وإضافة موفّر محلي.

ومن المنطقي أيضًا استخدام النماذج الصغيرة من خلال مقدّم خدمة عن بُعد.

لذا، يمكنك إضافة نموذج هنا، طالما أنّه متوافق مع OpenAI أو Anthropic، يمكنك ربطه.

حسنًا، لنرَ.

الآن، بالمناسبة، الطريقة التي تختارون بها نموذجًا في "استوديو Android" هي من خلال هذه القائمة المنسدلة، بالطبع.

لذا، اخترتُ نموذج Gemma 4 26B، ويمكنني أن أسأل: "ما هو ViewModel؟"

حسنًا

لذلك، من المهم جدًا تذكُّر أنّه عند تغيير النموذج، يتم إرسال المحادثة بأكملها مرة أخرى إلى النموذج الجديد من البداية.

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

لنعد الآن إلى الشرائح وإلى "زوي" للتعرّف على مهام سير العمل المختلفة التي يمكن تنفيذها باستخدام النماذج الصغيرة.

شكرًا جزيلاً لك يا "خوسيه"، وشكرًا لك يا "إيان" على النظرة العامة حول نماذج Gemma، وما إذا كنّا قد وصلنا إلى هدفنا أم لا.

لقد اطّلعنا على أنواع النماذج ومواصفاتها، والآن علينا فهم بعض أنواع المهام التي يمكنها تنفيذها.

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

أليس كذلك؟

هذه بعض الأمور التي أنا متأكد من أنّ الجميع يفعلونها، حتى بدون أن يدركوا ذلك على الأرجح.

لكنني أود أن أشجعك، أو أود أن أشجعك على التفكير في ما هو أبعد من ذلك، أليس كذلك؟

بما أنّ النماذج الصغيرة يمكن أن تكون مفتوحة الأوزان وتعمل على الجهاز، ما الذي يمكن أن يوفّر لك الوقت؟

أليس كذلك؟

نحن نتحدث عن عدم استخدام الصاروخ، فلماذا نستخدم دماغًا لذلك؟

لذا، إذا تمكّنا من تجاوز ذلك، فما هي بعض الأشياء التي يمكن أن تفعلها النماذج الصغيرة؟

ما هي بعض مهام سير العمل التي يمكنك إدخالها فيها والتي يمكن أن تسهل حياتك وتمنحك المزيد من القدرة على القيام بأشياء، كما تعلم، ربما تريد القيام بالمزيد منها؟

على سبيل المثال، التأكّد من أنّ مستنداتك محدّثة دائمًا بالتغييرات التي أجريتها، أو التأكّد من أنّ لديك اختبارات تراجع تلقائية تشكّل جزءًا من عملية التحقّق قبل الإرسال، أو حتى التأكّد من أنّ السياق الذي قد يتلقّاه الوكيل كجزء من مهام سير العمل محسَّن له، ويعمل بشكل أسرع.

هذه بعض الأمثلة، أليس كذلك؟

وفي نهاية المطاف، لا حدود لما يمكن تحقيقه إلى حدّ ما، أو أنّ البنية هي الحدّ الأقصى، وهناك الكثير من الأمور التي يمكن التفكير في كيفية تنفيذها.

ولكن، بعد الحصول على المواصفات والأدوات وسير العمل، هل ما زلت غير متأكد من أين تبدأ؟

هذا هو الغرض من معايير الأداء.

وكما قال "إيان"، فإنّ قائمة الصدارة العامة، خاصةً تلك الخاصة بلغة Python، لن تخبرك كثيرًا عمّا إذا كان النموذج الصغير سيكون مفيدًا لسير العمل على Android.

تمامًا مثل مثقاب الحوائط الجافة، قد لا يخبرك كثيرًا عن مثقاب الخرسانة.

لكن يجب أن تستثمر في عمليات التقييم الخاصة بك.

يجب أن تستثمر في اختبار البنية الخاصة بك، ولكن قبل القيام بذلك، قد لا ترغب في وضع جميع الموارد.

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

وهناك ثلاثة أشياء يجب أن تنظر إليها كلما قمت بتقييم المعيار، أليس كذلك؟

قد يبدو الأمر معقدًا بعض الشيء، ولكن في الأساس، أول شيء يجب معرفته هو نوع المهمة التي يؤديها هذا النموذج، أليس كذلك؟

مدى تحديدها

هل يشبه نوع المهمة التي ستعطيها له؟

والثاني هو نطاق المهمة.

هل هي كتابة المستندات، أم حل طلبات المراجعة، أم شيء يشبه نوع الوظيفة التي لديك؟

وأخيرًا، هل يشبه تعقيد النظام التعقيد الذي ستقدّمه؟

وهنا يمكننا أن نرى سبب عدم تمثيل معيار Python لنظام Android بشكل جيد.

لهذا السبب، أنشأنا Android Bench، وهو مقياس أداء يغطي منظومة Android المتكاملة والعمل على Android.

يتضمّن الإصدار الأول 100 مهمة Android بحجم طلب دمج، ويمكنكم تشغيله بأنفسكم اليوم من خلال Harbor لاختبار أي مجموعة من الوكلاء والنماذج والمهارات.

نطلق الإصدار 2.0 مع مهام أكثر تعقيدًا وطويلة الأمد لفهم قدرات النماذج الرائدة في العمل في وظائف مثل تلك التي تمنحها لها اليوم.

سأترك الكلمة الآن لـ "خوسيه" ليعرض لكم النتائج التي حصلنا عليها من خلال هذا النموذج وبعض الطرق التي يمكنكم من خلالها تحسين العمل باستخدام النماذج الصغيرة.

حسنًا، شكرًا لك يا "زوي".

حسنًا، لنلقِ نظرة على المهام التي يمكن لنموذج صغير حلّها، وتلك التي يواجه صعوبة في تنفيذها.

ولنحدّد بشكل عشوائي أربع فئات من المهام: صغيرة ومتوسطة وكبيرة وطويلة المدى.

المهام الطويلة المدى هي مهام قد يستغرق إكمالها أيامًا أو أسابيع.

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

على الأقل في محاولة واحدة.

سنتحدث عن ذلك لاحقًا.

حسنًا، مهام صغيرة.

وهي وظائف تتطلب قراءة وكتابة ملف أو ملفين، ولا تتطلب الكثير من المعرفة.

على سبيل المثال، النماذج الصغيرة جيدة جدًا في Compose، على الأقل في أساسيات Compose.

لذا، أشياء مثل يجب أن يكون هناك 8 dp بين العناصر، أو استخدام سمة بدلاً من الألوان ذات الترميز الثابت، أو استخراج السلاسل.

هذه المهام سهلة جدًا بالنسبة إلى نموذج صغير.

ومع ذلك، يتناول هذا الموضوع موضوعًا أكثر تقدمًا، لكن المهمة لا تزال سهلة.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

تكمن الصعوبة، في هذه الحالة، في النطاق، وليس في المعرفة.

يخبرنا الطلب بالدالة المركّبة التي يجب تحسينها والمشكلة التي تواجهها، وهي إعادة تركيبها في كل إطار.

لذا، يسهّل ذلك المهمة حتى بالنسبة إلى نموذج صغير، مثل Gemma 4.

استغرق الأمر في هذه الحالة 3 دقائق، وهو تغيير من سطر واحد.

حسنًا.

أعتقد أنّنا كوّنّا فكرة جيدة عن النموذج الصغير.

لنلقِ نظرة على م- عذرًا، على مهمة صغيرة.

لنلقِ نظرة على المهام المتوسطة.

من المفترض أن تتمكّن النماذج الصغيرة من تنفيذ معظمها.

في هذه المهمة، من تطبيق Pocket Casts، يكون وكيل المستخدم مفقودًا من طلب، وهناك أيضًا خطأ في منطق إعادة المحاولة.

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

لكنها مرّت.

استغرق الأمر 10 دقائق.

وعدّل ثلاثة ملفات.

وبالمناسبة، بلغت تكلفة ذلك 6 سنتات من خلال OpenRouter.

والآن، لنلقِ نظرة على مهمة تعذّر تنفيذها من مجموعة البيانات نفسها.

هذا مثال على تطبيق Now in Android مع تقرير أو طلب شامل إلى حد ما، ولكنه لا يذكر اسم فئة أو ملف، لذا يحتاج الوكيل إلى بذل المزيد من الجهد لفهم بنية التطبيق وطبقة البيانات وآلية المزامنة وما إلى ذلك. لذا، في هذه الحالة تحديدًا، فشل الوكيل.

تم تنفيذ كل شيء بشكل صحيح تقريبًا، ولكن تم افتراض أنّ قيمة المزامنة الأولية ستكون -1، ولكنّها في الواقع 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

انتهيت!

كان من الممكن اكتشاف هذا الخطأ إذا قام الوكيل بتشغيل اختبار الوحدة، واختبارات الوحدة الحالية.

يوضّح ذلك كيف أنّ النماذج الأصغر حجمًا تتوقف عادةً قبل النماذج الرائدة.

لقد طلبنا من موظف الدعم حلّ المشكلة، وليس التحقّق منها.

لذلك، ربما ينبغي لنا تعديل المهمة بحيث تحتوي على خطوة تحقق.

سنتحدث عن ذلك بعد قليل أيضًا.

حسنًا، لنتحدّث عن المهام الكبيرة.

وفقًا لهذا التعريف، ينجح حوالي نصف المهام الكبيرة في كل مرة.

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

ولكن هناك بعض الحالات التي عندما تنظر إلى ما حدث بالفعل، تدرك أن النموذج كان بنسبة 90 أو 90 في المائة هناك.

لذا، لنختَر أحدها.

اخترت هذا الاختبار لأنّه غير مستقر.

ويجتاز الاختبار حوالي نصف الوقت الذي يتم تشغيله فيه.

لذلك، أعتبر أنّ هذا النموذج هو في طليعة ما يمكن أن يقدّمه نموذج صغير.

أو على الأقل، نموذج من شهر أبريل.

يتعلّق الأمر بتحليل عناوين URL غير الصحيحة في مكتبة Coil.

كما ترون، وصف طلب الدمج شامل جدًا، وهذا أمر رائع، ولكنه لم يتضمن أحد المتطلبات.

لذا، لنلقِ نظرة سريعة عليه.

تحققت جميع عمليات التشغيل من ترميزات وأخطاء عناوين URL النموذجية، ولكن بعضها فقط، نصفها، أضاف اختبارات للأحرف المشفرة بشكل سيئ، بحيث تكون حالة الاختبار هناك.

أما تلك التي لم تنجح، فلم تجتَز التقييم.

إذًا، جميع عمليات التشغيل مثالية تقريبًا، ولكن هذا يثبت مرة أخرى أنّ النماذج الصغيرة لا تبذل دائمًا جهدًا إضافيًا.

فهي تتّبع التعليمات، ولكنّها لا تحاول إبهارك كما تفعل النماذج الرائدة.

هل تعرف كيف يمكنك تحديد الجهد في الوكيل في الوقت الحالي؟

يُرجى العلم أنّ هذه القيمة تكون منخفضة جدًا عند استخدام نموذج صغير.

لذا، لنعرّف المهام الكبيرة بأنّها تلك التي يمكن أن تنجزها النماذج الصغيرة في حوالي %50 من الوقت، وهو ما يمكن أن يحقّقه نموذج Gemma 4 31B مقارنةً بمجموعة بيانات Android Bench v1، وهو ما تحدّثت عنه "زوي" سابقًا.

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

بالتأكيد، وهذه الأمور لا تتطلّب أي جهد على الإطلاق.

أولاً، إذا كنت تستخدم نموذجًا مثل Gemma 4 محليًا كما ذكر "إيان"، تأكَّد من إعداده بشكل صحيح.

على سبيل المثال، إذا كنت تستخدم Ollama لعرض Gemma 4، يتم ضبطه تلقائيًا على قدرة استيعاب تبلغ 32,000 رمز مميّز، في حين أنّه يتيح في الواقع ثمانية أضعاف ذلك.

بالطبع، إذا كنت تستخدم Gemma 4 من خلال استوديو Android، لن تحتاج إلى ضبطه.

ويتم ضبطه بشكل صحيح تلقائيًا.

في مجموعة التقييمات التي أجريناها، أدى تفعيل السياق الكامل إلى زيادة النتائج من %26 إلى %53.

بعد ذلك، استخدِم Android CLI، وهي أداة سطر أوامر Android، خاصةً للبحث في المستندات.

لا ينطبق ذلك دائمًا، لأنّ النماذج جيدة جدًا في الأساسيات، ولكن عندما تستخدم واجهة برمجة تطبيقات جديدة أو متخصّصة، يكون توفّر المستندات أمرًا أساسيًا.

وهذا أفضل بكثير من استخدام أدوات بحث الويب، حسب تجربتنا.

بعد ذلك، أضِف تلميحات التحقّق.

لقد تحدثنا عن هذا.

أخبِر النموذج بكيفية إجراء الاختبارات، وأنواع الاختبارات المتاحة، وكيفية إدارة المحاكيات، وما إلى ذلك. يمكنك إجراء ذلك في ملف AGENTS.md، ما يجعل التعليمات متاحة لجميع الوكلاء، ولكن هذا أمر جيد على أي حال.

يجب أن يكون لديك.

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

لقد حاولنا تشغيل هذه المعايير باستخدام OpenCode، وكان أداؤه أقل بكثير من pi، ربما لأنه يستخدم أوصاف أدوات أكبر ومطالبات النظام.

بعد ذلك، أضف المهارات، ولكن قم أيضًا بإزالة المهارات.

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

إذًا، ماذا عن المهام الطويلة المدى؟

وهي مهام تشمل عشرات الملفات، وتتطلّب اتخاذ قرارات معمارية مهمة، وعادةً ما يتم التعامل معها من خلال نموذج تفكير يضع خطة ويبدأ مجموعة من الوكلاء الفرعيين الذين ينفّذون المهام المختلفة.

ومن الأمثلة على المهام الطويلة المدى نقل تطبيق كامل من XML إلى Compose، أو إنشاء تطبيق معقّد من الصفر، أو تحويل التطبيقات التي تعمل على عدّة منصات إلى تطبيقات Android أصلية.

إذا نظرنا إلى نتائج Android Bench V2، الذي يركّز حصريًا على المهام الطويلة المدى، نرى أنّ النماذج الرائدة تحقّق نتائج تتراوح بين %3 و%40.

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

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

لنرَ كيف يمكننا القيام بذلك.

لنعد إلى "زوي".

شكرًا جزيلاً يا "خوسيه".

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

لذا، يمكن أن يساعدك التنسيق، على سبيل المثال، في عدم حظرك أبدًا، أليس كذلك؟

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

يمكنك أيضًا الحصول على إجابات أفضل من خلال التنسيق.

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

يمكنك أيضًا إعداد مجلس تنفّذ فيه أنواع مختلفة من النماذج، أو نماذج مختلفة، المهمة نفسها في الوقت نفسه، ثم تقييم الردود المختلفة وكيفية تأثير الأوزان والتحيزات لكل نموذج على النتيجة.

يمكنك أيضًا استخدام نموذج منفصل لنفترض أنّه للاختبارات.

لذا، يشبه ذلك مراجعة الزملاء.

ويمكنك رؤية ذلك من خلال هذا.

وأخيرًا، يمكن أن تساعدك عملية التنسيق في تحقيق الكفاءة من حيث التكلفة من خلال إجراءات مثل التتالي.

يمكنك إعدادها يدويًا، فيمكنك ضبط نموذج واحد للتخطيط، ونموذج آخر للتنفيذ، ونموذج آخر للاختبارات.

هناك طرق متعددة لإجراء ذلك، إما على السحابة الإلكترونية أو يمكنك إعداد خادم وكيل LiteLLM لإجراء ذلك محليًا.

أو يمكنك استخدام مصنِّف لتوجيه الطلب تلقائيًا إلى النوع المناسب من النماذج استنادًا إلى الطلب، وهي فكرة الوكيل التي ذكرها "إيان"، ولكنّها تلقائية.

لنختتم بالعودة إلى السؤال الذي طرحه "خوسيه" في بداية الجلسة، وهو: ما الفرق في الجودة والدقة بين النماذج الصغيرة والنماذج الرائدة؟

والإجابة كما هو الحال مع العديد من الأشياء في علوم الكمبيوتر هي، هذا يعتمد.

ومع ذلك، هذا شيء أنا كما تعلم، أود أن أعود معك إلى أن هذا شيء يمكنك هندسته.

هذا شيء يمكنك إحداث فرق فيه اعتمادًا على كيفية إعداده واعتمادًا على كيفية اللعب بالقطع.

إذًا، الخطوة الأولى هنا هي اختيار الأداة المناسبة، أليس كذلك؟

هناك أنواع متعددة من الأدوات.

التعرّف عليها واستكشافها، أليس كذلك؟

وبعد ذلك، يمكنك معرفة الوظائف المناسبة لهم أو حتى الوظائف التي يمكنهم القيام بها.

والنصيحة الثانية هي التأكّد من ضبط النطاق الذي يتلقّاه النموذج لتنفيذ المهمة.

على سبيل المثال، تعليمات المهمة، وتوفير السياق المناسب للمهمة فقط، وطرق التحقّق من عمله.

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

وفي النهاية، عليك العمل على إعداد أو إنشاء تقييماتك الخاصة.

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

ولكن الأهم من ذلك هو أنّه يمكنك مواصلة الاستكشاف والإنشاء والاستمتاع، أليس كذلك؟

ويمكنكم البدء في ذلك اليوم من خلال إعداد قائمة مختصرة من النماذج من خلال Android Bench والنتائج التي حصلتم عليها، أو البدء باستخدام Gemma 4 على استوديو Android اليوم.

لذا، شكرًا جزيلاً لك.