معلومات في صورة أسئلة سريعة للشباب الصغير جوا Machine Learning
بقلم: أ.د أحمد النجار
سؤال مهم جدًا..
إيه مشكلة
Split / cross validation of training data
الإجابة..
Split vs Cross Validation
1. Split (Train/Test Split)
• هنا بتقسم الـ dataset مرة واحدة إلى جزئين:
• Training set (مثلاً 80%).
• Testing set (مثلاً 20%).
• العيب الأساسي:
النتيجة ممكن تتأثر بالصدفة (يعني لو البيانات متوزعة بشكل غير متوازن، الأداء ممكن يبان أعلى أو أقل من الحقيقي).
2. Cross Validation (CV)
• أشهر نوع هو K-Fold Cross Validation.
• بتقسم البيانات إلى K أجزاء (Folds)، وكل مرة:
• جزء للتست (Validation).
• باقي الأجزاء للتدريب.
• تكرر العملية K مرات، وكل مرة بتاخد Fold مختلف كـ test.
• في الآخر تاخد متوسط النتائج → ده بيقلل الانحياز (Bias) وبيخلي التقييم أدق.
المشكلة في الخلط بين Split وCross Validation
• بعض الناس بتفتكر إن مجرد split واحد كفاية → وده خطر، لأنه ممكن يدي صورة مضللة عن قوة الموديل.
• في حين إن Cross Validation بياخد كل البيانات تقريباً في التدريب والاختبار بشكل عادل.
• كمان لو حجم البيانات صغير → Cross Validation أفضل بكتير من مجرد split واحد.
• لكن لو البيانات كبيرة جداً → ممكن تستخدم Split عشان السرعة وتوفير الوقت.
الخلاصة..
• Train/Test Split → سريع وبسيط لكن مش دايمًا موثوق.
• Cross Validation → أدق لكنه أبطأ (خصوصًا مع موديلات Deep Learning).
====================
سؤال آخر مهم..
هل في ال training – validation ممكن يحصل مشاكل؟ يعني هل في ال validation بيشوف الداتا بتاعت ال training؟
الإجابة..
السوال دا بنسميه لبّ مشكلة الـ data leakage اللي ناس كتير بتغلط فيها 👇
الفكرة الأساسية:
• Training set → الموديل بيتعلم منه.
• Validation set → بنستخدمه عشان نقيّم الموديل ونشوف أداءه قبل ما نجربه على test data.
المشكلة المحتملة: Leakage
• لو حصل أي تداخل بين الـ training وvalidation (يعني نفس البيانات أو features مشتقة من نفس السجلات ظهرت في الإثنين)، الموديل هيبان إنه شاطر جدًا على الـ validation … لكن في الحقيقة ده غش (overfitting / leakage).
أمثلة عملية للمشاكل:
1. تسريب البيانات:
• لو عملت split بطريقة غلط (مثلاً shuffle=False على بيانات time series).
• أو لو فيه مريض بياناته ظهرت في train وفي validation (في medical datasets).
2. Preprocessing leakage:
• لو عملت Normalization / Scaling / Feature Engineering على كل البيانات قبل ما تقسم.
• الصح → تعملها بعد التقسيم، بحيث تتعلم الـ scaler من الـ training فقط وتطبقه على validation.
3. Overfitting على الـ validation:
• ساعات الباحث يفضل يعدّل الموديل (hyperparameters) لحد ما يجيب أفضل نتيجة على validation.
• هنا validation يتحول شبه training → والنتيجة مش هتبقى معبرة عن أداء الموديل الحقيقي.
• الحل → استخدام Test set مستقل أو Nested Cross Validation.
الخلاصة..
• في الوضع الطبيعي: الـ validation ما يشوفش أي حاجة من training data.
• أي overlap أو تسريب = مشكلة خطيرة في التقييم.
• لازم دايمًا تتأكد إن:
1. الـ split مظبوط (train ≠ validation).
2. أي preprocessing يتعمل جوه الـ training pipeline فقط.
3. تحتفظ بـ test set نهائي ما تلمسه غير مرة واحدة بعد ما تستقر على الموديل.
==================
سؤال آخر..
طيب لو بشتغل على object دا هينفع؟
الإجابة..
لو قصدك على حالة object detection مثلًا:
• آه، نفس القواعد تنطبق: لازم تعمل train/val split مظبوط، بحيث مايبقاش فيه صور مشتركة بين training و validation.
• كمان لو فيه صور متسلسلة (frames من فيديو مثلاً)، متحطش جزء منها في train وجزء في validation → ده يسبب leakage لأن الموديل هيشوف تقريبًا نفس المعلومات.
ولو قصدك على Dataset object في بايثون:
• أيوه بينفع جدًا، سواء بتستخدم scikit-learn, PyTorch, أو TensorFlow.
• كلهم بيدوك إمكانية تقسيم الـ dataset إلى train / validation / test من خلال object أو dataloader، مع ضمان عدم التداخل.
