نموذج تعلم آلة مؤثر - كم يمكن أن يكون صعبًا؟

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

ومع ذلك، غالبًا ما يتم التغاضي عن عاملين يمكن أن يعرضا هذا المشروع للخطر:

1. ما إذا كانت هناك بيانات كافية لبناء نموذج يمكنه بالفعل زيادة التخصيص بنسبة 5%
2. الاستثمار المطلوب لبناء ونشر هذا النموذج الذي يوفر هذا التأثير بشكل مستمر.

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

عرض وقت التسليم المقدر للمستخدم لتطبيق توصيل طعام

سير العمل لإخراج هذا النموذج سيشمل الفرق التالية:

بلورة فكرة المشروع

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

جمع البيانات

يبدأ علماء البيانات بجمع البيانات التاريخية لجميع الطلبات التي تم إجراؤها وأوقات تسليمها.

• في بعض الحالات، قد لا تكون البيانات السابقة مسجلة بشكل صحيح - تسجيل البيانات وجمعها أولاً (فريق المنتج، فريق هندسة البيانات).
• في بعض الحالات المحظوظة قد تكون هذه البيانات متاحة بسهولة
• في كثير من الحالات، سيتطلب ذلك كتابة مسارات ETL للحصول على البيانات بالتنسيق الصحيح. سيقوم فريق هندسة البيانات بكتابة المسارات (pipelines) للحصول على البيانات بالتنسيق المطلوب.

تحليل البيانات

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

هندسة الميزات

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

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

تدريب النموذج

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

خدمة النموذج

بمجرد بناء النموذج، يجب استضافته كخدمة مصغرة (microservice) أو كعملية استدلال دفعي (batch inference job). في حالتنا لتوقع وقت التسليم، يجب أن تكون هذه خدمة فورية عبر الإنترنت - لذا من المنطقي نشرها كخدمة ذاتية التوسع (autoscaling service). في هذه الحالة، يتدخل مهندس تعلم الآلة الذي يأخذ النموذج، ويغلفه في خدمة Flask أو FastAPI ويبني صورة Docker. ثم يقوم مهندس تعلم الآلة بمساعدة فريق DevOps بنشره كخدمة مصغرة على البنية التحتية.

دمج المنتج

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

مراقبة النموذج

بمجرد نشر النموذج واستخدامه في المنتج، سنحتاج إلى مقاييس حول النموذج المنشور.

1. مراقبة النظام: يتضمن ذلك مقاييس مثل وحدة المعالجة المركزية، والذاكرة، وزمن استجابة واجهة برمجة التطبيقات، والأخطاء، وأعطال النموذج، ويتم ذلك عادةً باستخدام Prometheus / Grafana أو حلول مدفوعة مثل Datadog / New Relic. سيتم استخدام هذا من قبل فرق الهندسة والمنتج وعلم البيانات.

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

للحصول على مراقبة كاملة للنموذج، سيتطلب ذلك جهودًا كبيرة من فرق علم البيانات والهندسة وعمليات التطوير (DevOps).

الأتمتة الكاملة

بمجرد ترتيب جميع عمليات المراقبة، سيرغب عالم البيانات بشكل مثالي في أتمتة حلقة إعادة التدريب الكاملة. سيتطلب ذلك إطار عمل لتنسيق خطوط الأنابيب مثل Kubeflow أو Airflow.

تقييم التأثير التجاري:

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

لتلخيص الأمر تقريبًا، يشمل هذا 5 أصحاب مصلحة:

1. مدير المنتج / فريق الأعمال
2. فريق هندسة البيانات
3. فريق علم البيانات
4. فريق هندسة تعلم الآلة
5. فريق هندسة الواجهة الخلفية
6. فريق DevOps

تستغرق العملية الشاملة بسهولة أكثر من 2-3 أشهر في أي شركة، ويمكن أن تصل أحيانًا إلى 6 أشهر للنماذج القليلة الأولى. ويرجع ذلك إلى تعدد أصحاب المصلحة المعنيين وتعدد مجموعات المهارات المطلوبة، مما يجعل تحقيق تأثير تعلم الآلة يستغرق الكثير من الوقت والاستثمار الأولي الكبير.

لم نتحدث بعد عن بعض جوانب قابلية التوسع والموثوقية المتضمنة في العملية. نأمل أن نغطي بعض الجوانب أدناه في مقال مستقبلي.

1. توفير البنية التحتية
2. عملية CI / CD
3. تجريب النماذج بما في ذلك اختبار A/B.
4. قابلية توسع البنية التحتية.
5. اختيار منهجية النشر.

الحل هنا هو أتمتة الأجزاء القابلة للأتمتة، وتوفير الاستقلالية لعالم البيانات/مهندس تعلم الآلة لأداء معظم الخطوات دون الحاجة لتعلم جميع الأدوات المعنية. يجري الكثير من العمل في هذا المجال، ونأمل أن يصبح بناء نموذج تعلم آلة مؤثر، في غضون سنوات قليلة، سهلاً مثل بناء صفحة هبوط اليوم!