Machine Learning: تصميم المشروع
آخر تحديث: 2026-08-26
البداية الجيدة نصف المعركة - تصميم النظام يصنع المشروع أو يكسره، لذا ارسم المخطط قبل البناء.
1. ما ستتعلمه
- تحليل المتطلبات: الأهداف التجارية (التنبؤ بالإيرادات الشهرية بـ MAPE < 10%)، قصص المستخدم، وتعاريف المقاييس الأساسية
- بنية البيانات: مصادر البيانات (الطلبات/المستخدمون/المنتجات/السجلات) → بحيرة البيانات → مخزن الميزات
- بنية النموذج: خارطة طريق تطور من خط الأساس (LinearRegression) → المتقدم (XGBoost) → التعلم العميق (MLP)
- بنية النشر: إدارة تجارب MLflow + خدمة استدلال FastAPI + حاوية Docker + المراقبة والتنبيه
- جدولة المشروع وتعاون الفريق: توزيع العمل عبر Alice (هندسة البيانات)، Bob (هندسة ML)، و Charlie (Backend/DevOps)
2. قصة حقيقية من فريق شركة ناشئة
(1) الألم: القفز مباشرة إلى الكود أدى إلى ثلاث إعادات كتابة كاملة
أمر Bob فريقه ببدء البرمجة على الفور. بعد أسبوعين، اكتشفوا أن تصميم مصدر البيانات كان معيبًا واضطروا إلى إعادة بنائه. بعد أربعة أسابيع، وجدوا أن بنية النموذج لم تدعم التنبؤ عبر الإنترنت واضطروا إلى تغييرها مرة أخرى. بعد ثمانية أسابيع، أدركوا أن خطة النشر تجاهلت المراقبة واضطروا إلى إعادة هيكلة مرة أخرى. في مشروع بلا تصميم، كل خطوة هي "مفاجأة".
(2) حل تصميم النظام
يفرض تصميم النظام التفكير في "ما الذي يجب بناؤه" و "كيفية بنائه" مقدمًا - المتطلبات → البيانات → النموذج → النشر → المراقبة، مع خطة واضحة لكل خطوة.
# تصميم المشروع ككود
project_config = {
"name": "SalesPredict",
"goal": "Monthly revenue prediction MAPE < 10%",
"data_sources": ["orders", "users", "products", "ad_logs"],
"model_pipeline": "LinearRegression → XGBoost → MLP",
"deployment": "FastAPI + Docker + MLflow",
"team": {"Alice": "Data Engineering", "Bob": "ML Engineering", "Charlie": "DevOps"},
}
(3) النتيجة: التصميم أولًا، صفر إعادة عمل في التطوير
بعد أن قضى Bob أسبوعًا في تصميم النظام، كانت الأسابيع الثمانية من التطوير خالية من إعادة العمل وتم التسليم في الوقت المحدد. كلف التصميم 10% فقط من إجمالي وقت المشروع، ومع ذلك تجنب أكثر من 50% من مخاطر إعادة العمل.
3. تحليل المتطلبات
(1) تعريف الهدف التجاري
▶ مثال: قالب وثيقة المتطلبات
# المتطلبات كتكوين منظم
requirements = {
"business_goal": "التنبؤ بإيرادات الشهر القادم لكل فئة منتج",
"success_metrics": {
"primary": "MAPE < 10% للتنبؤ بالإيرادات الشهرية",
"secondary": ["MAE < 50 ألف دولار لكل فئة", "زمن انتقال التنبؤ < 100 مللي ثانية"],
},
"user_stories": [
"بصفتني Bob (العمليات)، أريد تنبؤات الإيرادات الشهرية حتى أتمكن من تحسين المخزون",
"بصفتي Alice (مدير الولايات المتحدة)، أريد تنبؤات بالدولار الأمريكي للسوق الأمريكي",
"بصفتي Charlie (مدير الاتحاد الأوروبي)، أريد تنبؤات باليورو للسوق الأوروبي",
"بصفتي CFO، أريد فترات ثقة التنبؤ لتخطيط الميزانية",
],
"constraints": {
"data_latency": "تحديث دفعي يومي بحلول الساعة 6:00 صباحًا",
"prediction_sla": "استجابة API < 100 مللي ثانية p95",
"model_retraining": "إعادة تدريب تلقائية أسبوعية",
"compliance": "GDPR لبيانات مستخدمي الاتحاد الأوروبي",
},
"scope": {
"in_scope": ["3 مناطق سوق", "5 فئات منتجات", "تنبؤات شهرية وأسبوعية"],
"out_of_scope": ["التنبؤ في الوقت الفعلي لكل طلب", "تصنيف المنتجات القائم على الصور"],
},
}
Output:
# Executed successfully
| البُعد | التعريف | هدف SalesPredict |
|---|---|---|
| المقياس الأساسي | مؤشر أداء النموذج | MAPE < 10% |
| المقياس التجاري | قياس القيمة التجارية | تخفيض 20% في تكلفة المخزون |
| SLA | اتفاقية مستوى الخدمة | API < 100 مللي ثانية p95 |
| حداثة البيانات | تردد تحديث البيانات | دفعي يومي |
| الامتثال | القيود التنظيمية | GDPR (بيانات الاتحاد الأوروبي) |
4. بنية البيانات
(1) مصادر البيانات وتدفقها
graph TB
ORDERS[قاعدة بيانات الطلبات<br/>بيانات المعاملات] --> ETL[خط أنابيب ETL<br/>دفعي يومي]
USERS[ملفات تعريف المستخدمين] --> ETL
PRODUCTS[كتالوج المنتجات] --> ETL
ADLOGS[سجلات منصة الإعلان] --> ETL
ETL --> DATALAKE[بحيرة البيانات<br/>S3 / GCS]
DATALAKE --> FEATURE[مخزن الميزات<br/>ميزات مهندسة]
FEATURE --> TRAIN[خط أنابيب التدريب]
FEATURE --> SERVE[طبقة الخدمة<br/>ميزات عبر الإنترنت]
SERVE --> API[API التنبؤ]
▶ مثال: تعريفات مصادر البيانات
data_sources = {
"orders": {
"source": "PostgreSQL (قاعدة بيانات الإنتاج)",
"fields": ["order_id", "user_id", "product_id", "amount_usd", "order_date", "category"],
"volume": "~500 ألف صف/شهر",
"latency": "T+1 (متاح في اليوم التالي)",
},
"users": {
"source": "نظام CRM",
"fields": ["user_id", "region", "segment", "register_date", "lifetime_value"],
"volume": "~50 ألف مستخدم نشط",
"latency": "T+1",
},
"ad_spend": {
"source": "Google Ads + Facebook Ads API",
"fields": ["date", "channel", "campaign", "spend_usd", "impressions", "clicks"],
"volume": "~10 آلاف صف/شهر",
"latency": "T+2",
},
"product_catalog": {
"source": "نظام PIM",
"fields": ["product_id", "category", "price_usd", "margin_pct", "launch_date"],
"volume": "~5 آلاف منتج",
"latency": "تحديث أسبوعي",
},
}
Output:
# Executed successfully
(2) تصميم مخزن الميزات
| مجموعة الميزات | عدد الميزات | تردد التحديث | التخزين |
|---|---|---|---|
| ميزات RFM | 12 | يومي | Parquet (دون اتصال) + Redis (عبر الإنترنت) |
| ميزات الإعلان | 8 | يومي | Parquet |
| ميزات الوقت | 6 | محسوبة في الوقت الفعلي | منطق الكود |
| ميزات الفئة | 5 | جدول أبعاد أسبوعي | Parquet |
| الإحصائيات المجمعة | 10 | يومي | Parquet |
5. بنية النموذج
(1) خارطة طريق تطور النموذج
▶ مثال: تعريف بنية النموذج
model_architecture = {
"stage_1_baseline": {
"model": "LinearRegression + Pipeline",
"expected_r2": "0.72-0.78",
"expected_mape": "12-15%",
"purpose": "إنشاء خط أساس، التحقق من خط أنابيب البيانات",
"timeline": "الأسبوع 1-2",
},
"stage_2_advanced": {
"model": "XGBoost + Feature Engineering",
"expected_r2": "0.85-0.89",
"expected_mape": "8-10%",
"purpose": "نموذج الإنتاج، تحقيق هدف MAPE < 10%",
"timeline": "الأسبوع 3-5",
},
"stage_3_deep_learning": {
"model": "MLP / LSTM (سلسلة زمنية)",
"expected_r2": "0.87-0.92",
"expected_mape": "7-9%",
"purpose": "تحسين تدريجي، التقاط الأنماط الزمنية",
"timeline": "الأسبوع 6-8",
},
}
Output:
# Executed successfully
| المرحلة | النموذج | MAPE | وقت التدريب | الأولوية |
|---|---|---|---|---|
| المرحلة 1 | LinearRegression | 12-15% | <1 دقيقة | P0 |
| المرحلة 2 | XGBoost | 8-10% | ~5 دقائق | P0 |
| المرحلة 3 | MLP/LSTM | 7-9% | ~30 دقيقة | P1 |
(2) استراتيجية التقييم
evaluation_strategy = {
"cv_method": "TimeSeriesSplit(n_splits=5)",
"primary_metric": "MAPE",
"secondary_metrics": ["MAE", "RMSE", "R2"],
"business_alignment": {
"MAPE_10pct": "خطأ التنبؤ ضمن 10% من الإيرادات الفعلية",
"MAE_50k": "متوسط الخطأ المطلق أقل من 50 ألف دولار لكل فئة",
"cost_of_error": "1% MAPE ≈ 100 ألف دولار هدر مخزون سنوي",
},
"ab_testing": {
"duration": "3 أسابيع",
"metric": "MAPE التنبؤ بالإيرادات مقابل الفعلي",
"sample_size": "جميع الفئات، جميع الأسواق",
},
}
6. بنية النشر وأدوار الفريق
(1) بنية النشر
graph TB
CLIENT[تطبيقات العميل] --> NGINX[موازن تحميل Nginx]
NGINX --> API1[عامل FastAPI 1]
NGINX --> API2[عامل FastAPI 2]
API1 --> MODEL[MLflow Model Registry<br/>نموذج الإنتاج]
API2 --> MODEL
API1 --> REDIS[(ذاكرة التخزين المؤقت Redis)]
API2 --> REDIS
MODEL --> MLFLOW[تتبع MLflow<br/>سجل التجارب]
MLFLOW --> MONITOR[مجموعة المراقبة<br/>Prometheus + Grafana]
MONITOR --> ALERT[مدير التنبيهات<br/>اكتشاف الانحراف]
ALERT --> RETRAIN[خط أنابيب إعادة التدريب<br/>Airflow/Dagster]
RETRAIN --> MLFLOW
(2) أدوار الفريق
▶ مثال: سجل المخاطر
risk_register = {
"data_quality": {
"risk": "البيانات الخام بها >5% قيم مفقودة في الميزات الرئيسية",
"probability": "عالية",
"impact": "حرج - نموذج مدرب على بيانات متحيزة",
"mitigation": "فحوصات جودة بيانات تلقائية في خط أنابيب ETL",
"owner": "Alice",
},
"model_overfitting": {
"risk": "XGBoost يفرط في التجهيز على عينات فئات صغيرة",
"probability": "متوسطة",
"impact": "عالية - تعميم ضعيف على أسواق جديدة",
"mitigation": "TimeSeriesSplit CV، تنظيم، توقف مبكر",
"owner": "Bob",
},
"api_latency": {
"risk": "API التنبؤ يتجاوز SLA 100 مللي ثانية تحت الحمل",
"probability": "متوسطة",
"impact": "متوسطة - تدهور تجربة المستخدم",
"mitigation": "ذاكرة تخزين مؤقت Redis للاستعلامات الساخنة، تحديد معدل Nginx",
"owner": "Charlie",
},
}
Output:
# Executed successfully
▶ مثال: جدول المشروع
project_schedule = {
"Week 1-2: البيانات وخط الأساس": {
"Alice": "خط أنابيب ETL، إعداد بحيرة البيانات، فحوصات جودة البيانات",
"Bob": "EDA، هندسة الميزات، خط أساس LinearRegression",
"Charlie": "بيئة التطوير، إعداد MLflow، خط أنابيب CI/CD",
},
"Week 3-5: النموذج المتقدم": {
"Alice": "مخزن الميزات، طبقة الخدمة عبر الإنترنت، مراقبة البيانات",
"Bob": "تدريب XGBoost، ضبط المعاملات، تقييم النموذج",
"Charlie": "هيكل FastAPI، إعداد Docker، اختبار الحمل",
},
"Week 6-8: التعلم العميق والنشر": {
"Alice": "ميزات في الوقت الفعلي، اكتشاف انحراف البيانات",
"Bob": "تجارب MLP/LSTM، تصميم اختبار A/B",
"Charlie": "النشر الإنتاجي، لوحة مراقبة، تنبيه",
},
"Week 9-10: الإطلاق والمراقبة": {
"Alice": "مراقبة خط أنابيب البيانات، التحقق من الميزات",
"Bob": "مراقبة النموذج، خط أنابيب إعادة التدريب",
"Charlie": "تنفيذ اختبار A/B، طرح تدريجي، إعداد الاستجابة",
},
}
Output:
# Executed successfully
| الدور | المسؤول | المسؤوليات | المخرجات |
|---|---|---|---|
| هندسة البيانات | Alice | ETL/بحيرة البيانات/مخزن الميزات | خط أنابيب البيانات + الميزات |
| هندسة ML | Bob | هندسة الميزات/تدريب النموذج/التقييم | أفضل نموذج + سجلات التجارب |
| Backend/DevOps | Charlie | API/النشر/المراقبة | خدمة الإنتاج + المراقبة |
❓ أسئلة شائعة
📖 ملخص
- أعمدة تحليل المتطلبات الثلاثة: أهداف كمية (MAPE < 10%)، قصص المستخدم، والقيود (زمن الانتقال/الامتثال)
- بنية البيانات: مصادر البيانات → ETL → بحيرة البيانات → مخزن الميزات → مساران للتدريب والخدمة
- تطور بنية النموذج: LinearRegression (خط الأساس) → XGBoost (حصان العمل) → MLP/LSTM (مكاسب تدريجية)
- بنية النشر: FastAPI + ذاكرة تخزين مؤقت Redis + موازنة تحميل Nginx + إدارة نماذج MLflow + مراقبة Prometheus
- أدوار الفريق: Alice (هندسة البيانات) + Bob (هندسة ML) + Charlie (DevOps) يتعاونون عبر ثلاثة أدوار
- التصميم أولًا، صفر إعادة عمل في التطوير - 10% من الوقت على التصميم يتجنب 50% من إعادة العمل
📝 تمارين
- أساسي (الصعوبة ⭐): اكتب وثيقة متطلبات لمشروع ML الخاص بك، بما في ذلك الهدف التجاري ومقاييس النجاح وحدود النطاق. تلميح: راجع قالب وثيقة المتطلبات في القسم 3.
- متوسط (الصعوبة ⭐⭐): ارسم مخطط بنية بيانات كامل (Mermaid) لـ SalesPredict، مع تسمية كل مصدر بيانات وخطوة ETL وطريقة تخزين. تلميح: راجع مخطط بنية البيانات في القسم 4.
- تحدٍّ (الصعوبة ⭐⭐⭐): صمم مشروع ML كامل من البداية إلى النهاية - المتطلبات → البيانات → النموذج → النشر → المراقبة → الفريق - وأنتج خطة مشروع قابلة للتنفيذ (مع جدول زمني ومخرجات). تلميح: ادمج جميع عناصر التصميم من الأقسام 3-6.
← الدرس السابق: المراقبة في الإنتاج وانحراف النموذج | الدرس التالي: تطوير المشروع →