المراجعة والاختبار النهائيّ

عشر وحدات لبناء ثقافة عمليّة على Gradio، من دالّة Python وحيدة إلى مساعد لغويّ منشور على مساحة Hugging Face مع بثّ وأمثلة وقائمة انتظار وجمع ملاحظات. هذه هي الدورة مُكثَّفة، ثمّ الخيوط التي تعبرها، ثمّ مقارنة صريحة مع Streamlit من الدورة 38.

الدورة في لمحة

الوحدة	الجوهر الواجب حفظه
1. الواجهة والمدخلات والمخرجات	gr.Interface يُطابق أنواع Python بمكوّنات (str → Textbox، Image → gr.Image)؛ مصنّف صور في عشرة أسطر
2. مكوّنات النصّ والصورة والصوت والفيديو	كلّ مكوّن يستقبل صيغة محدّدة (مصفوفة NumPy، مسار، معدّل عيّنات)؛ خطأ الصيغة يُنتج استثناءات صامتة
3. Blocks: التخطيط والأحداث	gr.Blocks يُتيح صفوفًا وأعمدة وأحداث نقر وتغيير؛ gr.State يحمل حالة بين النداءات
4. الواجهات الحوارية	gr.ChatInterface يعطي محادثة كاملة في تسعة أسطر؛ رسالة النظام واتّجاه RTL يُضبطان صراحة
5. البثّ التدريجي للردود	مولّد Python مع yield يعرض الحرف الأوّل في 0,1 ثانية؛ الإحساس بالسرعة أهمّ من السرعة
6. الأمثلة والتخزين المؤقّت	examples يجعل العرض قابلًا للاستكشاف؛ cache_examples="lazy" يخفّف كلفة النقر الأوّل
7. قائمة الانتظار والتزامن	queue(default_concurrency_limit, max_size) يمنع نفاد الذاكرة عند خمسة مستخدمين
8. رابط المشاركة المؤقّت	share=True يعطي نفقًا عامًّا لمدّة 72 ساعة؛ يُكشف ما على جهازك، فلا يُستعمل مع بيانات حسّاسة
9. النشر على مساحة Hugging Face	مستودع Git مع app.py وrequirements.txt وأسرار؛ CPU basic مجّانيّ ينام بعد 48 ساعة
10. مشروع مساعد لغويّ	كلّ الميزات مجتمعة على gpt-4o-mini؛ قراءة كلفة صريحة قبل نشر الرابط

الخيوط التي تعبر الدورة

الدالّة هي القلب، لا الواجهة. يبدأ الجميع بالسؤال «كيف أبني الواجهة؟» ثمّ يكتشفون أنّ الجواب هو «اكتب دالّة Python نظيفة، ثمّ سلّمها إلى Gradio». الواجهة تنبع من التوقيع: مُدخلات الدالّة تُصير مكوّنات الإدخال، ومُرجَعاتها تُصير مكوّنات العرض. هذه الفلسفة تعبر الوحدات الأولى وتُبرَّر عمليًّا في العاشرة: كلّ ما بنيناه هو تراكم توابع حول دالّة repondre واحدة.

الإحساس بالسرعة يهزم السرعة نفسها. جواب من 200 رمز في 4 ثوانٍ يبدو معطوبًا إذا وصل دفعة واحدة، ويبدو ذكيًّا يُفكّر إذا بُثّ رمزًا رمزًا. الوحدة 5 تُظهر هذه القاعدة على مولّدات Python، والوحدة 10 تُطبّقها على نموذج لغويّ حقيقيّ. الفارق التقنيّ سطر yield واحد؛ الفارق الإدراكيّ الفرق بين «عرض جادّ» و«عرض مشكوك فيه».

قائمة الانتظار قيد بنيويّ، لا تفصيل ضبط. بلا queue() مع concurrency_limit صريح، الطلب الخامس يُحمّل نُسخة خامسة من النموذج، فتنفد ذاكرة GPU وينهار الخادم للجميع. الوحدة 7 تُقدّم هذا كقرار معماريّ يحسم قبل النشر، لا كخيار تحسين بعديّ. مساحة Hugging Face على CPU basic تحتاج حدًّا بين 2 و4 حسب النموذج؛ الرقم يُقاس بسكربت اختبار حمل قبل مشاركة الرابط.

المشاركة سطر واحد، وثمنها معرفة ما يُكشف. share=True مغرٍ لأنّه يُنتج رابطًا عامًّا في ثانيتين؛ لكنّه يفتح نفقًا إلى جهازك مع كلّ ما يعنيه ذلك من مسارات ملفّات ومتغيّرات بيئة وقواعد بيانات محلّيّة. الوحدة 8 تفكّك متى يُستعمل (عرض داخليّ سريع، مراجعة عميل قصيرة) ومتى يُتجنّب (بيانات هويّة، أسرار API، جهاز مشترك). الاختيار قرار أمن، لا قرار راحة.

النشر على Hugging Face حياة العرض بعد المحادثة. رابط share=True يموت بعد 72 ساعة؛ المساحة تعيش سنوات بعنوان دائم. الوحدة 9 تُقدّم المساحة كامتداد طبيعيّ للمشروع لا كخطوة اختياريّة، مع إدارة الأسرار (OPENAI_API_KEY في Secrets، لا في app.py) ودورة النوم التي تُوفّر الحساب حين لا يوجد زوّار.

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

Gradio مقابل Streamlit (الدورة 38)

الدورتان تُقدّمان أدوات بناء واجهات ويب بـPython، لكنّ فلسفتهما مختلفة. الاختيار يعتمد على المشروع، لا على «الأفضل» المطلق:

المعيار	Gradio	Streamlit
المُنطلق الفلسفيّ	«لُف دالّة Python بواجهة تلقائيًّا»	«اكتب سكربت من الأعلى إلى الأسفل، أُعِد تشغيله عند كلّ تغيير»
المستهدف الأوّل	عروض نماذج ML، ودردشات، ومداخلات وسائط	لوحات بيانات، وتقارير تفاعليّة، وأدوات تحليل
المكوّنات الجاهزة	ChatInterface، بثّ تدريجيّ، مكوّنات صور وصوت مُعدّة	جداول ورسوم Plotly/Altair عميقة، بطاقات مقاييس
نموذج التنفيذ	حدث → نداء دالّة → تحديث خرج	إعادة تشغيل كاملة للسكربت عند كلّ تفاعل
البثّ التدريجي (Streaming)	أصليّ عبر مولّدات Python وyield	متاح لكن أقلّ سلاسة (st.write_stream منذ 2024)
الاستضافة الرسميّة المجّانيّة	Hugging Face Spaces (تكامل ممتاز)	Streamlit Community Cloud
نضج الأتمتة	gr.load() لتحميل نموذج Hugging Face في سطر	يحتاج شفرة يدويّة
مناسب لـ	مصنّف صور، محرّر صور، مساعد لغويّ، عرض نموذج صوت	لوحة KPI، مستكشف بيانات، تقرير تفاعليّ

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

قائمة المراجعة قبل الامتحان

• ماذا يُرجع gr.Image(type="numpy") مقابل gr.Image(type="filepath")؟
• كيف يعمل gr.State بين نداءات في gr.Blocks، ولماذا لا يكفي متغيّر عامّ في Python؟
• ما الفارق بين مولّد يُنتج جزءًا جديدًا وآخر يُنتج التراكم الكامل عند البثّ؟
• ما أثر cache_examples="lazy" مقابل True مقابل False، ومتى يُختار كلّ منها؟
• ما الفرق بين default_concurrency_limit وmax_size في queue()، وكيف يُقاسان تجريبيًّا؟
• ما الذي يفعله share=True تقنيًّا، وما الذي يُكشف على الشبكة؟
• ما الملفّات الدنيا لمساحة Hugging Face، وأين يُوضع مفتاح API؟
• في المشروع النهائيّ: كم تبادلًا شهريًّا يسمح به سقف 20 دولارًا على gpt-4o-mini؟

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

يتضمّن الامتحان 40 سؤالًا تشمل الوحدات العشر: أنواع Python والمكوّنات المناسبة (1، 2)، إدارة الحالة والأحداث في Blocks (3)، بناء واجهة حوارية بحدّ أدنى مقبول (4)، صحّة مولّد البثّ (5)، اختيار أمثلة مفيدة ومنطق التخزين المؤقّت (6)، حسابات قائمة الانتظار والتزامن (7)، ما يُكشف بالضبط عند share=True (8)، دورة نوم المساحة وإدارة الأسرار (9)، ثمّ قرارات المشروع الكامل (كلفة، حدود، جمع ملاحظات — 10).

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

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

قبل أن تبدأ

راجع الجدول أعلاه، واسأل نفسك عن كلّ سطر: «كيف سأثبت أنّ فهمي صحيح؟». إن استطعت أن تشرح لماذا البثّ يُغيّر إحساس المستخدم، ولماذا يجب تحديد concurrency_limit صراحة، ومتى لا تستعمل share=True، فأنت مستعدّ. حظًّا موفّقًا!

الخلاصة

• Gradio يختصر الطريق بين نموذج يعمل داخل دفتر Jupyter ومستخدم يستطيع تجربته اليوم؛ عشر أسطر تكفي لواجهة أولى.
• البنية تنمو مع الحاجة: من gr.Interface إلى gr.Blocks إلى gr.ChatInterface، ثمّ بثّ وأمثلة وقائمة انتظار، دون بناء بنية معقّدة قبل حاجة حقيقيّة.
• المشاركة والنشر خطوتان مختلفتان: share=True لعرض عابر، ومساحة Hugging Face لعنوان دائم؛ لكلّ منهما مقاييس أمن وكلفة خاصّة.
• العرض ليس إنتاجًا: Gradio مثاليّ للتعليم والمراجعة والتحقيق المبكّر، ويُترك ما بعده لخدمات إنتاج مبنيّة على FastAPI أو ما شابه.
• الاختيار بين Gradio وStreamlit قرار مشروع لا قرار موضة: نماذج ML ودردشات مع Gradio، ولوحات بيانات وتقارير تفاعليّة مع Streamlit.

بعد هذا الفصل، خطوتك الطبيعيّة هي الدورة 40 (مشروع القبطة النهائيّة) لبناء مسار كامل، أو العودة إلى الدورة 20 (MLOps) لإتمام رحلة العرض إلى الإنتاج. وفّقك الله في الامتحان!

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

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

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

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

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