Machine Learning: تصميم المشروع

آخر تحديث: 2026-08-26

البداية الجيدة نصف المعركة - تصميم النظام يصنع المشروع أو يكسره، لذا ارسم المخطط قبل البناء.

1. ما ستتعلمه


2. قصة حقيقية من فريق شركة ناشئة

(1) الألم: القفز مباشرة إلى الكود أدى إلى ثلاث إعادات كتابة كاملة

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

(2) حل تصميم النظام

يفرض تصميم النظام التفكير في "ما الذي يجب بناؤه" و "كيفية بنائه" مقدمًا - المتطلبات → البيانات → النموذج → النشر → المراقبة، مع خطة واضحة لكل خطوة.

PYTHON
# تصميم المشروع ككود
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) تعريف الهدف التجاري

▶ مثال: قالب وثيقة المتطلبات

PYTHON
# المتطلبات كتكوين منظم
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:

TEXT 📖 للعرض فقط
# Executed successfully
البُعد التعريف هدف SalesPredict
المقياس الأساسي مؤشر أداء النموذج MAPE < 10%
المقياس التجاري قياس القيمة التجارية تخفيض 20% في تكلفة المخزون
SLA اتفاقية مستوى الخدمة API < 100 مللي ثانية p95
حداثة البيانات تردد تحديث البيانات دفعي يومي
الامتثال القيود التنظيمية GDPR (بيانات الاتحاد الأوروبي)

4. بنية البيانات

(1) مصادر البيانات وتدفقها

100%
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 التنبؤ]

▶ مثال: تعريفات مصادر البيانات

PYTHON
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:

TEXT 📖 للعرض فقط
# Executed successfully

(2) تصميم مخزن الميزات

مجموعة الميزات عدد الميزات تردد التحديث التخزين
ميزات RFM 12 يومي Parquet (دون اتصال) + Redis (عبر الإنترنت)
ميزات الإعلان 8 يومي Parquet
ميزات الوقت 6 محسوبة في الوقت الفعلي منطق الكود
ميزات الفئة 5 جدول أبعاد أسبوعي Parquet
الإحصائيات المجمعة 10 يومي Parquet

5. بنية النموذج

(1) خارطة طريق تطور النموذج

▶ مثال: تعريف بنية النموذج

PYTHON
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:

TEXT 📖 للعرض فقط
# Executed successfully
المرحلة النموذج MAPE وقت التدريب الأولوية
المرحلة 1 LinearRegression 12-15% <1 دقيقة P0
المرحلة 2 XGBoost 8-10% ~5 دقائق P0
المرحلة 3 MLP/LSTM 7-9% ~30 دقيقة P1

(2) استراتيجية التقييم

PYTHON
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) بنية النشر

100%
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) أدوار الفريق

▶ مثال: سجل المخاطر

PYTHON
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:

TEXT 📖 للعرض فقط
# Executed successfully

▶ مثال: جدول المشروع

PYTHON
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:

TEXT 📖 للعرض فقط
# Executed successfully
الدور المسؤول المسؤوليات المخرجات
هندسة البيانات Alice ETL/بحيرة البيانات/مخزن الميزات خط أنابيب البيانات + الميزات
هندسة ML Bob هندسة الميزات/تدريب النموذج/التقييم أفضل نموذج + سجلات التجارب
Backend/DevOps Charlie API/النشر/المراقبة خدمة الإنتاج + المراقبة

❓ أسئلة شائعة

س ما مدى تفصيل تحليل المتطلبات؟
ج يجب أن يتضمن كحد أدنى — 1) هدف تجاري واضح مع مؤشرات أداء كمية؛ 2) قصص المستخدم (من يستخدم ماذا لفعل ماذا)؛ 3) قيود (زمن الانتقال/الامتثال/الميزانية)؛ 4) حدود النطاق (ما هو في الداخل وما هو في الخارج). المتطلبات الغامضة هي السبب الرئيسي لإعادة العمل.
س هل النموذج الأساسي ضروري حقًا؟
ج بالتأكيد. يُنشئ خط الأساس حدًا أدنى للأداء ويتحقق من خط أنابيب البيانات. بدونه، لا يمكنك معرفة ما إذا كان تحسن XGBoost جاء من النموذج أم من إصلاح خط أنابيب البيانات.
س كم عدد الأشخاص الذين يجب أن يكونوا في الفريق؟
ج يحتاج مشروع ML إلى ثلاثة أشخاص على الأقل - واحد للبيانات، وواحد لـ ML، وواحد لـ DevOps. يمكن لشخص واحد متعدد التخصصات العمل أيضًا، لكنه أقل كفاءة ويُنشئ نقطة معرفة واحدة. المهم هو تغطية الأدوار الثلاثة، وليس العدد.
س هل نعمل على البيانات أو النموذج أولًا؟
ج البيانات أولًا. بيانات متسخة + نموذج جيد = نتائج قمامة. اقضِ الأسبوع أو الأسبوعين الأولين في بناء خط أنابيب بيانات موثوق، ثم درب النماذج. كلما اكتشفت مشكلات البيانات مبكرًا، كانت أرخص في الإصلاح.
س كم يجب أن تستمر مرحلة التصميم؟
ج حوالي 10-15% من إجمالي مدة المشروع. قضاء أسبوع في التصميم لمشروع مدته ثمانية أسابيع أمر معقول. تكلفة إعادة العمل من التصميم غير الكافي تتجاوز بكثير تكلفة أسبوع إضافي من التصميم.
س كيف تتأكد من تنفيذ التصميم فعليًا؟
ج يجب أن تتضمن وثيقة التصميم — 1) مخرجات واضحة ومعايير قبول؛ 2) قوالب/هيكل الكود؛ 3) استراتيجية اختبار؛ 4) نقاط تحقق مرحلية. تتحقق كل نقطة من تنفيذ التصميم بشكل صحيح.

📖 ملخص

📝 تمارين

  1. أساسي (الصعوبة ⭐): اكتب وثيقة متطلبات لمشروع ML الخاص بك، بما في ذلك الهدف التجاري ومقاييس النجاح وحدود النطاق. تلميح: راجع قالب وثيقة المتطلبات في القسم 3.
  2. متوسط (الصعوبة ⭐⭐): ارسم مخطط بنية بيانات كامل (Mermaid) لـ SalesPredict، مع تسمية كل مصدر بيانات وخطوة ETL وطريقة تخزين. تلميح: راجع مخطط بنية البيانات في القسم 4.
  3. تحدٍّ (الصعوبة ⭐⭐⭐): صمم مشروع ML كامل من البداية إلى النهاية - المتطلبات → البيانات → النموذج → النشر → المراقبة → الفريق - وأنتج خطة مشروع قابلة للتنفيذ (مع جدول زمني ومخرجات). تلميح: ادمج جميع عناصر التصميم من الأقسام 3-6.

← الدرس السابق: المراقبة في الإنتاج وانحراف النموذج | الدرس التالي: تطوير المشروع →

Web-Tutorial.com

فريق Web-Tutorial التقني

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

100%