اختبار سلسلة إجراءات تعلم الآلة

كتابة: كريستينا يونغ ترجمة: نضال إمام   مراجعة: أسيل المسعد

دعونا نلقي نظرة على منهجيات الاختبار التقليدية وكيف يمكننا تطبيقها على سلسلة إجراءات (pipelines) البيانات/تعلم الآلة الخاصة بنا.

عندما يتعلق الأمر بمنتجات البيانات، في كثير من الأحيان هناك اعتقاد خاطيء بأن هذه المنتجات لا يمكن اختبارها آلياً. على الرغم من أن بعض أجزاء سلسلة الإجراءات لا يمكن أن تمر عبر طرق الاختبار التقليدية نظرًا لطبيعتها التجريبية والعشوائية (stochastic)، إلا أن معظم هذه الإجراءات يمكنها ذلك. بالإضافة إلى ذلك، يمكن وضع الخوارزميات التي لا يمكن التنبؤ بها من خلال عمليات التحقق المتخصصة.

دعونا نلقي نظرة على منهجيات الاختبار التقليدية وكيف يمكننا تطبيقها على سلسلة إجراءات البيانات/تعلم الآلة الخاصة بنا.

هرم الاختبار (Testing Pyramid)

هرم الاختبار القياسي المبسط يبدو كما يلي:

هذا الهرم هو تمثيل لأنواع الاختبارات التي تستخدم عند إنشاء أي تطبيق. نبدأ بالعديد من اختبارات الوحدة، والتي تختبر وظيفة واحدة بمعزل عن الآخرين. ثم نكتب اختبارات التكامل التي تتحقق مما إذا كان تجميع المكونات المعزولة معًا يعمل كما هو متوقع. أخيرًا نكتب اختبارات واجهة المستخدم (UI) أو اختبارات القبول، والتي تتحقق من أن التطبيق يعمل كما هو متوقع من وجهة نظر المستخدم. عندما يتعلق الأمر بمنتجات البيانات، فإن الهرم لا يختلف كثيرًا. قد نستخدم كل أو بعض هذه المستويات.

لاحظ أن اختبارات واجهة المستخدم تستخدم كثيراً للمنتج، لكن هذه المدونة تركز على الاختبارات الأكثر صلة بسلسلة إجراءات البيانات.

دعونا نلقي نظرة فاحصة على ما يعنيه كل من هذه في سياق تعلم الآلة، وبمساعدة بعض مؤلفي الخيال العلمي (Sci-fi).

اختبارات الوحدة (Unit tests)

“إنه نظام لاختبار أفكارك حول الكون، ومعرفة ما إذا كانت تتطابق” إسحاق عظيموف.

تحتوي معظم التعليمات البرمجية في سلسلة إجراءات البيانات من عملية تنظيف البيانات (data cleaning). كل وظيفة تستخدم للقيام بتنظيف البيانات لها هدف واضح. دعنا نقول، على سبيل المثال، أن إحدى الخصائص التي اخترناها للنموذج الخارجي هي تغيير قيمة بين اليوم السابق والحالي. قد تبدو التعليمات البرمجية إلى حد ما كما يلي:

نحن هنا نعلم أنه بالنسبة لمدخلات معينة نتوقع مخرجات معينة، لذلك يمكننا اختبار ذلك بالتعليمة البرمجية التالية:

لكل جزء من الوظائف المستقلة، يمكنك كتابة اختبار وحدة، مع التأكد من أن كل جزء من عملية تحويل البيانات له التأثير المتوقع على البيانات. بالنسبة لكل جزء من الوظائف، يجب عليك أيضًا التفكير في سيناريوهات مختلفة (هل هناك عبارة if؟ إذاً يجب اختبار جميع العبارات الشرطية). سيتم تشغيل هذه كجزء من سلسلة إجراءات التكامل المستمر (CI) الخاص بك على كل التزام.

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

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

اختبارات الدمج (Integration tests)

لأن “العين المجردة كانت أفضل، بغض النظر عما رأت.” فرانك هربرت.

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

• ينتج عن عملية تنظيف البيانات مجموعة بيانات مناسبة للنموذج
• يمكن تدريب النموذج للتعامل مع البيانات المقدمة إليه وإخراج النتائج (مما يضمن إمكانية إعادة صياغة التعليمات البرمجية في المستقبل)

لذلك إذا أخذنا دالة اختبار الوحدة أعلاه وأضفنا الدالتين التاليتين:

بعد ذلك يمكننا اختبار ما إذا كان دمج الدالات داخل البيانات النظيفة (clean_data) سيؤدي إلى النتيجة المتوقعة باستخدام التعليمات البرمجية التالي:

الآن دعونا نقول إن الشيء التالي الذي سوف نقوم به هو تغذية البيانات أعلاه إلى نموذج الانحدار اللوجستي (logistic regression model):

على الرغم من أننا لا نعرف التوقعات، إلا أنه يمكننا التأكد من أننا ننتج دائمًا نفس القيمة. من المفيد لنا اختبار هذا التكامل لضمان:

• البيانات قابلة للاستهلاك بواسطة النموذج (توجد علامات لكل إدخال، ويتم قبول أنواع البيانات حسب نوع النموذج المختار، وما إلى ذلك)
• نحن قادرون على إعادة صياغة التعليمات البرمجية الخاصة بنا في المستقبل، دون كسر الوظيفة من بدايتها إلى النهاية (end-to-end functionality).

يمكننا أن نضمن أن تكون النتائج هي نفسها دائمًا من خلال توفير نفس قيمة التوليد (seed) للمولد العشوائي. تسمح لك جميع المكتبات الرئيسية بضبط هذه القيمة (Tensorflow خاصةً بعض الشيء، لأنه يتطلب منك تعيينها عبر numpy، فضع ذلك في الاعتبار). يمكن أن يبدو الاختبار كما يلي:

لن تكون هناك العديد من هذه الأنواع من الاختبارات مثل اختبارات الوحدات، لكنها ستظل جزءًا من سلسلة إجراءات CI. يمكنك استخدام هذه الاختبارات للتحقق من الوظيفة من أولها لآخرها لمكون ما وبالتالي اختبار المزيد من السيناريوهات الرئيسية.

التحقق من تعلم الآلة (ML validation)

لماذا ا؟ “نظهر عدم الجدوى المثالية لمعرفة الإجابة على السؤال الخطأ.”  أورسولا لي جوين.

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

عادة ما يتم الجمع بين هذه النتائج مع قواعد العمل الأخرى قبل أن يستهلكها المستخدم أو تطبيق آخر. لهذا السبب، نحتاج إلى التحقق من أن النموذج يحل مشكلة المستخدم ، وليس فقط أن الدقة / f1-score / المقياس الإحصائي الآخر كافية بدرجة عالية.

كيف يساعدنا ذلك؟

• أنه يضمن أن النموذج يساعد المنتج بشكل فعلي على حل المشكلة المطروحة
  • على سبيل المثال، النموذج الذي يصنف لدغة الثعبان على أنها مميته أو لا بدقة 80٪، يصبح نموذجًا غير جيد لأن نسبة الخطأ 20٪ قد تسبب عدم حصول المرضى على العلاج الذي يحتاجونه
• أنه يضمن أن القيم التي ينتجها النموذج منطقية من حيث المجال
  • على سبيل المثال، النموذج الذي يتنبأ بالتغيرات في السعر بدقة 70٪ ليس نموذجًا جيدًا اذا كان السعر النهائي المعروض للمستخدم له قيمة إما منخفضة او مرتفعة جدًا بحيث لا تكون هذه القيمة منطقية في هذا المجال أو السوق
• يوفر طبقة توثيق إضافية للقرارات التي اتخذت، مما يساعد المهندسين على الانضمام إلى الفريق في وقت لاحق
• أنه يوفر إمكانية رؤية مكونات نموذج تعلم الآلة للمنتج بلغة مشتركة يفهمها العملاء ومديري المنتجات والمهندسين بنفس الطريقة

يجب تشغيل هذا النوع من أنواع التحقق (validation) بشكل دوري (إما من خلال سلسلة إجراءات CI أو وظيفة cron) ، ويجب أن تكون نتائجه مرئية للمؤسسة. هذا يضمن أن يكون التقدم المحرز في مكونات علم البيانات مرئي للمؤسسة، ويضمن اكتشاف المشكلات التي تسببها التغييرات أو البيانات التي لا معنى لها في وقت مبكر.

خاتمة

بعد كل شيء ” السحر هو فقط علم لم نفهمه بعد” آرثر سي كلارك.

يمكن اختبار مكونات نماذج تعلم الآلة بطرق مختلفة، مما يوفر لنا المزايا التالية:

• يؤدي إلى منهج قائم على البيانات للتأكد من أن التعليمات البرمجية تقوم بما هو متوقع
• التأكد من أننا نستطيع أن نعيد صناعة (refactor) وتنظيف التعليمات البرمجية دون التأثير على خصائص المنتج
• توثيق الوظائف والقرارات والأخطاء السابقة
• توفير رؤية للتقدم المحرز وحالة مكونات نماذج تعلم الآلة للمنتج

لذلك لا تخف، إذا كان لديك المهارات اللازمة لكتابة التعليمات البرمجية فأنت لديك المهارات اللازمة لكتابة الاختبار واكتساب جميع المزايا المذكورة أعلاه 🙂.

شكرا لجميع الاختبارات!