الوحدة 11 — المراجعة والاختبار

بعد عشر وحدات، لدينا نموذج بحجم 2.1 مِيغا مضغوطًا يعمل في 18 مِلّي ثانية على هاتف اقتصاديّ ويستهلك 30 مِلّي جول لكلّ استدلال، مندمج في تطبيق موبايل يعمل دون شبكة على Android وiOS معًا. هذا ما وُعِد به في الوحدة 1، وهذا ما تحقّق. تُعيد هذه الوحدة تجميع ما تعلّمناه في هيكل واحد قابل للاستدعاء عند بدء أيّ مشروع نشر على الحافة، ثمّ تُعلن الاختبار الذي يفتح الشهادة.

قراءة عرضيّة لكلّ وحدة

كلّ وحدة تركت أثرًا مقيسًا على النموذج النهائيّ. لنراجعها بترتيب المنطق:

الوحدة 1 — القيود على الجهاز. أعلنّا أربع ميزانيّات صريحة: ذاكرة (200 مِيغا للتطبيق)، حساب (60 مِلّي ثانية للاستدلال)، طاقة (40 مِلّي جول)، وغياب شبكة كامل. هذه الأرقام لم تُذكر مرّة أخرى، لكنّها وجّهت كلّ قرار لاحق.

الوحدة 2 — التحويل. مررنا من plantvillage_mobilenetv2.keras إلى .tflite عبر TFLiteConverter، وشرحنا لماذا يُختصر عدد العوامل من ألف وخمسمئة إلى مئة وثلاثين. البيانات الوصفيّة والتوقيعات جعلت النموذج قابلًا للاستعمال بلا وثيقة جانبيّة.

الوحدة 3 — التكميم بعد التدريب. ثلاث استراتيجيّات (المدى الديناميكيّ، int8 الكامل، float16) قُورنت بأرقام. اخترنا int8 الكامل، فانتقلنا من 14 مِيغا إلى 3.5 بخسارة 0.9 نقطة دقّة.

الوحدة 4 — التدريب الواعي بالتكميم (QAT). الحلّ الثاني عند فشل PTQ. لم نحتَجه على MobileNetV2 α=1.0، لكن أظهرنا الفارق على نموذج أصغر (α=0.35) حيث QAT يوفِّر ثلاث نقاط دقّة.

الوحدة 5 — التقليم. أوزان قريبة من الصفر تُصفَّر بجدولة تدريجيّة. الملفّ الخام لا يتقلّص، لكن بعد ضغط gzip، تقليم 50 % يُخفض التحميل من 3.5 إلى 2.1 مِيغا.

الوحدة 6 — المفسّر والمفوَّضون. خمسة مفوَّضين (XNNPACK، GPU، NNAPI، Core ML، Hexagon)، وقاعدة اختيار بسيطة. اختيار نموذجنا: NNAPI على Android، Core ML على iOS. الرجوع الآمن إلى CPU تلقائيّ.

الوحدة 7 — Android. Task Library هي المسار الافتراضيّ، والمفسّر الخام للحالات الخاصّة. معالجة إطار الكاميرا مع CameraX، والخيوط الخلفيّة عبر كوروتين. اختبار التطابق خادم ↔ عميل قبل النشر.

الوحدة 8 — iOS. CocoaPods مع TensorFlowLiteSwift، والمفسّر الخام هو الواجهة الأساسيّة. Core ML أسرع على iPhone إن كان التطبيق حصريًّا لـApple. أذون الكاميرا في Info.plist بلغة واضحة.

الوحدة 9 — القياس. Benchmark Tool مع 200 استدلال بعد 20 إحماء، ووسائط مئويّة لا متوسّطات. الطاقة تُقاس بـBattery Historian أو monsoon. اختبار على ثلاث فئات من الهواتف لكشف الفوارق الفئويّة.

الوحدة 10 — المشروع الختاميّ. تجميع كلّ الاستراتيجيّات في تطبيق واحد: PTQ int8 + تقليم 50 % + NNAPI/Core ML، مع تحديث النموذج عن بُعد بأمان (SHA-256، Wi-Fi فقط)، وسجلّ محلّيّ مُشفَّر.

شجرة قرارات التحسينات

هذه الشجرة تُلخِّص « متى أستعمل أيّ استراتيجيّة » في أربع أسئلة:

هل النموذج فوق الميزانيّة (الحجم أو الزمن)؟
├── لا  → لا تُحسِّن. الأداء الحاليّ يكفي.
│
└── نعم
    ├── الفارق أقلّ من 4x؟
    │   └── ابدأ بـPTQ (المدى الديناميكيّ ثمّ int8 الكامل)
    │
    └── الفارق أكبر من 4x؟
        ├── هل الدقّة تفقد أكثر من 2 نقاط بعد PTQ int8؟
        │   ├── لا  → التزم بـPTQ int8. زد التقليم إن أردت خفض التحميل.
        │   │
        │   └── نعم → طبِّق QAT (يُسترجع أغلب النقاط). إن لم يكفِ:
        │              └── قلِّل حجم النموذج (MobileNetV2 α=0.5 مثلًا)
        │                  ثمّ أعِد PTQ + QAT.
        │
        └── هل تستهدف عتادًا يفرض int8 صافيًا؟
            └── QAT إلزاميّ (EdgeTPU، بعض NPU).

الاختيار بين المفوَّضين يتّبع الشجرة الثانية:

النموذج بـfloat32/float16؟
├── نعم → GPU Delegate على Android، Core ML على iOS
│
└── لا (int8)
    ├── Android → NNAPI + الرجوع الآمن إلى CPU
    │
    └── iOS → Core ML Delegate (أو Core ML أصليّ عبر تحويل النموذج)

الأخطاء الشائعة التي تجنّبناها

كلّ خطأ من هذه الأخطاء رأيناه في الميدان مرارًا، والدورة كلّها بُنيَت لتفاديها:

1. بدء العمل بلا ميزانيّة: النموذج يُبنى في السحابة بدقّة عالية، ثمّ يُكتشف أنّه لا يعمل على الهاتف. الحلّ في الوحدة 1: الميزانيّة قبل النموذج.
2. جَمْع تمثيليّ مشوَّه: مئة صورة سوداء أو من صنف واحد يُنتج تكميمًا مشوَّهًا. الحلّ في الوحدة 3: صور من توزيعة الإنتاج الحقيقيّة.
3. تفعيل SELECT_TF_OPS بلا داعٍ: يُضخِّم المكتبة من مِيغا واحد إلى 15، ويُعطِّل GPU. الحلّ في الوحدة 2: إعادة كتابة العوامل النادرة.
4. تجاهل معاملات التكميم (scale وzero_point): مخرَجات عشوائيّة صامتة. الحلّ في الوحدة 6: قراءة input_details واستعمالها.
5. إنشاء مفسّر جديد لكلّ استدلال: مئات المِلّي ثواني ضائعة. الحلّ في الوحدة 6: إنشاء واحد عند بدء التطبيق.
6. معالجة مسبقة مختلفة بين الخادم والعميل: النموذج يعمل لكنّ الدقّة تنخفض 10 نقاط. الحلّ في الوحدة 7: اختبار تطابق قبل النشر.
7. قياس بلا إحماء: أوّل استدلال عشرة أضعاف الوسيط. الحلّ في الوحدة 9: تجاهل أوّل 20.
8. اختبار على هاتف الفريق فقط: أرقام لا تصمد أمام هاتف المستخدم. الحلّ في الوحدة 9: ثلاث فئات على الأقلّ.
9. تحديث النموذج بلا تحقّق: مهاجم يستطيع تسميم النموذج. الحلّ في الوحدة 10: SHA-256 والاستبدال الذرّيّ.
10. أذون كاميرا غامضة: iOS يُلغي التطبيق فورًا. الحلّ في الوحدة 8: NSCameraUsageDescription بلغة واضحة.

اللغة الحديثة: LiteRT

في نهاية 2024، Google أعادت تسمية المكتبة إلى LiteRT (Lightweight Runtime). الأسباب رسميّة: التركيز على الاستدلال بلا التزام بمحرِّك تدريب بعينه، وفتح المكتبة لنماذج غير TensorFlow (PyTorch عبر JAX أو ONNX). لكنّ:

• الملفّات الثنائيّة تحتفظ باسم .tflite
• الواجهة البرمجيّة العلنيّة تبقى TensorFlow Lite في CocoaPods وGradle
• الوثائق تستعمل التسميتَين بالتبادل
• أدوات المجتمع (وثائق، أسئلة StackOverflow) تُهيمن عليها « TensorFlow Lite »

نصيحة عمليّة: افهم LiteRT كتسمية جديدة لواجهة قديمة. لا تُعيد كتابة تطبيقك، لكن كن جاهزًا لأن ترى الاسمَين في المراجع القادمة.

ما بعد هذه الدورة

خمس مسارات تكميليّة لمن يريد التعمّق:

• LiteRT for LLMs: تشغيل نماذج لغة صغيرة (Gemma 2B) على الهاتف. الدورة 28 « النماذج الصغيرة والتقطير » تقدّم الأساس.
• Edge TPU على Coral: عتاد استدلال مخصَّص من Google، أسرع من NNAPI بعشر أضعاف على نماذج int8 مُختارة.
• MediaPipe: طبقة أعلى فوق TFLite لبناء أنابيب رؤية سريعة (كشف يد، وجه، وضعيّة).
• ONNX Runtime Mobile: بديل من Microsoft يعمل مع نماذج PyTorch مباشرة، مماثل في المزايا.
• TensorFlow Federated: تدريب النموذج على أجهزة المستخدمين بلا نقل بيانات إلى الخادم، خطوة أبعد في الخصوصيّة.

الاختبار وشهادة الإتمام

الآن حان الوقت لاختبار الفهم. الاختبار يتكوّن من 40 سؤالًا مسحوبة عشوائيًّا من بنك يحوي 48 سؤالًا مصمَّمًا خصّيصًا لهذه الدورة. الأسئلة تغطّي الوحدات العشر كلّها، بتوزيع تقريبيّ: خمسة أسئلة لكلّ وحدة. الأنماط:

• مواقف عمليّة: النموذج يفشل، ما التشخيص؟ الاستدلال يستهلك طاقة زائدة، أين المشكلة؟
• قراءة أرقام: جدول قياسات، أيّ خيار مبرَّر؟
• قرارات مفاضلة: PTQ أم QAT هنا؟ NNAPI أم GPU؟
• أخطاء شائعة: أذون iOS، تدفّق حسابيّ في Swift، جَمْع تمثيليّ مشوَّه.

كلّ سؤال يتضمّن أربع خيارات، واحد فقط منها صحيح، وشرح مفصَّل يظهر بعد الإجابة (يُفيد حتّى إن أصبت).

عتبة النجاح: 70 % (28 إجابة صحيحة من أصل 40). في حال الفشل، يمكن الإعادة حتّى خمس مرّات في نافذة 24 ساعة، والأسئلة تُختلط في كلّ مرّة فلا تعود الأسئلة نفسها.

في حال النجاح، تُصدَر شهادة الإتمام فورًا، مصحوبة بمعرِّف فريد يمكن التحقّق منه عبر رابط عموميّ. الشهادة تحمل اسمك، وعنوان الدورة، وتاريخ الإصدار، والمهارات المُكتسبة (الوحدات العشر بالعناوين).

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

الامتحان النهائي

هل أنت مستعدّ لاعتماد هذه الدورة؟

40 سؤالًا تُختار عشوائيًّا من بنك أسئلة الدورة · حدّ النجاح 70 % · شهادة PDF قابلة للتحقّق تُصدَر فورًا عند النجاح.

ابدأ الامتحان

يلزم تسجيل الدخول إلى حسابك في InSkillML مع اشتراك نشط. يمكنك أيضًا بدء الامتحان من دوراتي.