الوقت قضى على نموذج التعلم الآلي الخاص بي!

سمعنا جميعًا الإحصائية التي تقول إن 90%، 88%، 87%، 85% أو نسبة مذهلة من نماذج التعلم الآلي لا تصل أبدًا إلى مرحلة الإنتاج. بصراحة تامة، ليس لدي أدنى فكرة عن كيفية حساب شخص ما لهذا الرقم، وأنا في حيرة من أمري تمامًا مثل هذا الشخص. لكن هذا ليس بيت القصيد. من الناحية المثالية، هذا الرقم يهم أقل بكثير من لماذا العديد من الشركات تكافح لاستخلاص قيمة تجارية من التعلم الآلي- حتى الآن!

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

بينما يُعد التعلم الآلي التطبيقي مجالًا حديثًا نسبيًا وتوجد مشكلات في كل جزء تقريبًا من مسار العمل، كان هناك موضوع واحد مدوٍ وبارز برز من محادثاتنا -

التأخير الزمني في وبين كل خطوة من خطوات بناء وإطلاق نماذج التعلم الآلي، يقلل من ثقة ومعنويات فرق الهندسة والقيادة مما يقضي على نماذج التعلم الآلي!

في عالم البرمجيات، اعتدنا على اتخاذ قرارات مبنية على البيانات. نريد رؤية النتائج بسرعة، وإجراء اختبارات A/B، وتبرير التكاليف، وإذا لم يحقق المشروع عائد استثمار (RoI) كافيًا في فترة معقولة من الوقت، يُعلّمنا أن ننهيه فورًا. و الوقت هو أحد الأشياء التي يستهلكها التعلم الآلي (ML) بكثرة! هذا ينطبق على الشركات على اختلاف أنواعها، وإن كان ذلك لأسباب مختلفة-

1. الشركات الناشئة في مراحلها المبكرة (من مرحلة التأسيس "Seed" حتى السلسلة C)
2. الكيانات الضخمة التقليدية مثل وولغرينز، تارجت، سيمنز
3. عمالقة التكنولوجيا مثل أوبر، أمازون، نتفليكس وغيرها.

دعونا ندرس هذا بالتفصيل.

الشركات الناشئة في مراحلها المبكرة

غالبًا ما يتطلب بناء ونشر مسارات التعلم الآلي (Machine Learning pipelines) مجموعة متنوعة من المهارات-

1. فهم حالة الاستخدام التجاري — عادةً مدراء المنتجات
2. مسارات تسجيل ومعالجة البيانات — عادةً مهندسو البيانات
3. تجربة النماذج وبناؤها — عادةً علماء البيانات
4. إنشاء واجهات برمجة تطبيقات الاستدلال (Inference APIs) ونشرها — عادةً مهندسو التعلم الآلي (ML Engineers)
5. توسيع نطاق النماذج، وتجهيزها، ومسارات الإنتاج — عادةً فريق DevOps
6. أطر عمل اختبار A/B، المراقبة وإمكانية الملاحظة، مسارات إعادة التدريب

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

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

الشركات العملاقة التقليدية مثل وولغرينز وتارغت

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

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

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

بدون ملاحظات من مستخدم الأعمال، كيف يعرف عالم البيانات -

• هل يحل نموذجهم المشكلة التي طلبها مستخدم الأعمال أم أن القصد ضاع في الترجمة؟
• هل يفتقدون بعض الشروط الحدودية الحاسمة التي إذا فاتتهم ستجعل العميل غاضبًا جدًا؟
• هل يستخدمون أي مصادر بيانات قد تُدخل تحيزات في النموذج أو تضر ببعض شرائح المستخدمين سلبًا؟

حتى لو سارت كل الأمور المذكورة أعلاه على ما يرام - من يدري على وجه اليقين أن الحدس الأولي لمستخدم الأعمال كان صحيحًا؟ الملاحظات النهائية لن تأتي إلا من المستخدم النهائي. ولكن كيف توصل النموذج إلى يد المستخدم النهائي؟

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

عمالقة التكنولوجيا مثل أوبر وأمازون

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

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

1. هذه هي المكتبات الأكثر شيوعًا التي نتوقع من علماء البيانات استخدامها
2. طالما يستخدم عالم البيانات خوارزميات "جاهزة"، فإن كل شيء يعمل بسلاسة، ولكن إذا أرادوا تطوير نموذجهم الخاص، فسيتعين عليهم القيام بالخطوات X و Y و Z.

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

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

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

الخلاصة والخطوات التالية

برز هذا الموضوع المتعلق بنماذج تعلم الآلة التي تستغرق "وقتًا طويلاً جدًا" لأسباب مختلفة بوضوح في جميع محادثاتنا مع المستخدمين.

1. الشركات الناشئة التي لا تملك جميع الموارد البشرية ومجموعة الأدوات، وليس لديها الكثير من الوقت للتكرار واكتشاف الحل الأمثل - تكتفي بالأنظمة القائمة على القواعد عندما تتخلى عن مشاريع تعلم الآلة!
2. الشركات التقليدية الكبيرة التي تواجه تحديات تنظيمية تتخلى عن مشاريع تعلم الآلة لأنها استغرقت وقتًا طويلاً لتتحقق وغالبًا ما تفشل في تحقيق تأثير تجاري مبرر.
3. شركات التكنولوجيا الحديثة التي لديها منصات MLOps محسّنة للإنتاج ولكن ليس كثيرًا للتجريب المفتوح، ينتهي بها المطاف بالاعتماد على الخوارزميات والمكتبات المدعومة "الجاهزة". وإلا فإن استغلال الإمكانات الكاملة لتعلم الآلة سيستغرق وقتًا طويلاً جدًا.

لقد دهشنا لرؤية هذا الموضوع المشترك عبر هذا الطيف الواسع من الشركات -

إن استغراق نماذج تعلم الآلة وقتًا طويلاً جدًا وتأخر التأثير التجاري ودورات التغذية الراجعة هو أحد الأسباب الرئيسية لعدم رؤية الكثير من نماذج تعلم الآلة النور.

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

لا ندعي أن لدينا حلاً كاملاً للمشكلة بعد، لكننا نعمل عليه. نتحدث مع أشخاص أذكياء ونكتشف كيف يمكننا تخفيف هذه المشكلة إن لم يكن حلها بالكامل.

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

يمكن التواصل معي شخصيًا عبر: nikunjbjj@gmail.com. وإليك حسابات LinkedIn الخاصة بي وبمؤسسي الشركة المشاركين-

• نيكُنج باجاج
• أبهيشيك تشودري
• أنوراغ غوتغوتيا

نُشرت هذه المدونة لأول مرة على Medium في https://medium.com/@nikunjbajaj/time-killed-my-ml-model-48521fad6c4 في 30 أغسطس 2021