ثمة سيناريو شائع بين المؤسسات التي تطبق مفهوم تعلم الآلة في أساليب عملها، حيث تتوافق كل من فرق الأعمال والفرق التقنية على بيان المشكلة العامة لإحدى مهمات تعلم الآلة. الجميع متحمس، حتى إن الفريق التقني يعكف لبضعة أشهر على إجراء التجارب على البيانات المتاحة باستخدام الخوارزميات المختلفة، حتى ينجحوا أخيراً في التوصل إلى إحدى الخوارزميات التي يظنون أنها تحقق أعلى مستويات الأداء وفق المقاييس المتفق عليها. ويعرضون النتائج بكل فخر على إدارة الشركة لدمجها في أحد أساليب عملها، أو لاعتمادها كسمة في أحد منتجات البرمجيات.
اكتشف أكبر محتوى عربي على الإنترنت لتطوير ذاتك وتحسين مهاراتك وجودة حياتك وتحقيق طموحاتك في أسرع وقت، استكشف باقات الاشتراك في مجرة.
ولكن قبل تعميم نموذجهم الخوارزمي، لا بد من مراجعته بمعرفة فريق الحوكمة للتأكد من استيفائه متطلبات إدارة المخاطر، حيث يشترط فريق الحوكمة توثيقاً دقيقاً للمتطلبات التي لم يأخذها الفريق التقني بعين الاعتبار على الإطلاق: هل يمكننا أن نفسر لماذا تستمد الخوارزمية مخرجاتها من مدخلاتها؟ وما الضوابط التي يستخدمها النظام لحماية خصوصية العميل؟ وما مدى ثبات البيانات المدخلة على مدى فترات زمنية طويلة، لاسيما إذا كنا لا نخطط للاحتفاظ بالنموذج سوى لمرة واحدة في الشهر، أو حتى في السنة؟ هل يمكننا التأكد من أن الخوارزمية تفضي إلى نتائج عادلة بين مختلف فئات العملاء المتأثرين بها؟
اقرأ أيضاً في المفاهيم الإدارية: معنى المقايضة
يرد الفريق التقني سريعاً بأن أحداً لم يطلعهم على هذه المتطلبات، لذا لم يضعوها في اعتبارهم أثناء عملية تطوير النموذج، فيبدأ أفراد الفريق التقني من جديد والإحباط يغمرهم، ولكن هذه المرة تقيدهم خيارات الخوارزميات الممكنة والبيانات المدخلة للتأكد من أنها تستوفي متطلبات إدارة المخاطر التي أُعلن عنها مؤخراً، ومن ثم يضيع الوقت والجهد، وتطول الجداول الزمنية، ويتساءل المسؤولون التنفيذيون عن السبب الذي يجعل الأمور تستغرق كل هذا الوقت الطويل، ويتسلل إليهم القلق بشأن التخلف عن اللحاق بركب المنافسين.
ينجم هذا الضعف في التواصل والتنسيق من فجوات المعرفة لدى الأطراف المعنية على المستويين الإداري والتقني بشأن ما يلزم اتخاذه لإنجاح محاولات تطبيق مفهوم تعلم الآلة على أرض الواقع، فضلاً عن أساليب "نموذج الشلال" المتبعة في إدارة المشاريع التقنية. وبما أن المجال لا يزال ناشئاً، يفتقر العديد من مطوري تعلم الآلة إلى الخبرة في إنشاء التطبيقات المؤسسية، كما أن الكثير من الأطراف المعنية بالأعمال الإدارية لا يمتلكون القدر الكافي من المعرفة بتعلم الآلة ليكونوا على علم بالأسئلة التي يجب أن يطرحوها عند تقييم المشاريع وإدارتها. وبالتالي يجب أن يكون أصحاب المشروع على علم بماهية المقايضات والقرارات التي سيواجهونها في أثناء إنشاء أنظمة تعلم الآلة، ومتى ينبغي لهم تقييم هذه المقايضات للحد من الإحباط والجهد المهدر، إذا أرادوا إنجاح الابتكار.
ولنبدأ بماهية هذه المقايضات. غالباً ما يتطلب تطبيق تعلم الآلة في سياق الأعمال التجارية سلسلة من القرارات والمقايضات التي من شأنها أن تؤثر في أداء النموذج، ويكمن جوهر هذه المسألة في بنية خوارزميات تعلم الآلة، التي تستخدم البيانات لتعلم المخططات التقريبية بين المدخلات والمخرجات المفيدة للشركات. ومن خلال البرمجيات المعيارية، يكتب المبرمجون تعليمات محددة تنفذ العمليات ذاتها في كل مرة، حيث تكمن المقايضة في أن هذه التعليمات تقتصر على ما يمكن الإفصاح عنه صراحة في الكود. وفي المقابل يحدد المبرمجون أهداف البرنامج من خلال تعلم الآلة ويكتبون خوارزمية تساعد النظام بكفاءة على تعلم أفضل مخطط للمخرجات والمدخلات من خلال البيانات المتاحة لتحقيق هذا الهدف، بدلاً من اختيار مخطط محدد من البداية. يمكّننا هذا النهج من التعامل مع السيناريوهات التي يصعب فيها كتابة القواعد المحددة (مثل التعرف على الصور، والتحليل النصي، وتوليد سلسلة لقطات الفيديو)، ولكن المقايضة هنا تكمن في أن نظام المخرجات قد يكون غير متوقع أو غير بديهي. ومن هذا المنطلق الاستقرائي تظهر العديد من الفروق الدقيقة في تطبيق أنظمة تعلم الآلة، وخاصة بالنسبة إلى الفرق الإدارية والتقنية التي تعتاد أنظمة الكمبيوتر القائمة على القواعد.
غالباً ما تظهر هذه الفروق الدقيقة في شكل مقايضات يجب على الفرق الإدارية القيام بها خلال عملية تطوير النظام، فعلى سبيل المثال قد تجد الفرق أن الغاية التي تسعى الشركة إلى توقعها أو تعظيمها لا يمكن قياسها بسهولة من خلال البيانات المتاحة، لذا يلجأون إلى بديل قابل للقياس، وهنا ينصب الاهتمام على أن النظام سيتعلم التنبؤ بذلك البديل فقط، وليس الغاية الحقيقية، وكلما كان البديل أكثر انتماءً إلى الغاية بصورة أكبر، قلت الفائدة التي ستعود على العمل التجاري من مخرجات النظام.
ثمة مقايضات أخرى تقيس دقة النموذج في مواجهة بعض الشواغل، مثل قابلية التوضيح، والعدالة، والخصوصية، فإذا كانت الشركة مترددة في اعتماد نموذج دون توضيح كيفية تخطيط المدخلات والمخرجات وسببه، فبإمكان الفريق التقني تقييد مجموعة من الحلول الممكنة للخوارزميات التي تحمل قدراً أكبر من قابلية التوضيح، إلا أن ذلك قد يؤدي إلى خفض مستوى أداء النموذج. وبالمثل، إذا كانت هناك مخاوف داخل الشركة بشأن إمكانية أن ينتج النظام مخرجات غير عادلة إلى بعض شرائح العملاء أو إمكانية أن يكشف النظام عن بيانات حساسة للمستخدمين، فبإمكان الفريق التقني أن يقصروا اهتمامهم على الخوارزميات التي تضمن العدالة والخصوصية، وهذه أيضاً يمكنها أن تؤثر في الأداء.
في بعض الأحيان، تقضي معدلات الأخطاء الملازمة بأفضلية الحد من الخسائر في وقت مبكر، خاصة في السياقات التي ترتفع فيها تكلفة ارتكاب الأخطاء (كإمكانية تضرر سمعة ثقة المستخدم، أو توقع معلومات يقينة من جانب المستخدم)، وبإمكان الفريق التقني أن يستثمر بكثافة في تصميم النظام لتحسين مستوى الدقة أو تضمين العنصر البشري في عملية اتخاذ القرار، ولكن إذا كانت تكاليف هذه الاستثمارات تفوق الفوائد المحتملة، فقد يكون الحد المبكر من الخسائر هو الحل الأمثل.
تعد الفروق بين هذه الاعتبارات دقيقة للغاية، لدرجة أن إدارتها في جلسة عمل واحدة أمر غير ممكن، لذا ينبغي على الجهات المسؤولة عن المشروع، بدلاً من ذلك، أن تُشرك الفرق الإدارية، والفرق المختصة بالمستخدم النهائي، والفرق التقنية، وفرق الحوكمة في مباحثات مكثفة خلال عملية تطوير النظام.
ونحن في شركة "بورياليس أيه آي" (Borealis AI) نقسم هذه العملية إلى المراحل التالية:
1. التصميم: تحديد المشكلة، وتوضيح الجدوى التجارية، والوقوف على قدرة الشركة على تحمُّل الأخطاء، والتحقق من أثر التشريعات –إن وجدت- على الحل المقترح.
2. الاستكشاف: إجراء دراسة جدوى باستخدام البيانات المتاحة، وتحديد ما إذا كانت البيانات متحيزة أم متوازنة، ومناقشة مدى حاجة الشركة إلى قابلية التوضيح. وربما يتطلب الأمر إعادة الكَرَّة مجدداً من مرحلة التصميم، ويتوقف ذلك على إجابات هذه الأسئلة.
3. التنقيح: تطويع النموذج واختباره (أو عدة نماذج بديلة محتملة)، وتقييم أثر تعزيز العدالة والخصوصية على الدقة.
4. البناء والانطلاق: تنفيذ إحدى نسخ النموذج المعدة للاستخدام المكثف، وتحديد عدد المرات التي يتعين فيها إعادة صياغة النموذج، وما إذا كان تخزين مخرجاته ضرورياً أم لا، وأثر هذه المتطلبات على احتياجات البنية التحتية.
5. القياس: توثيق الأداء الحالي للنموذج والتعلم منه، وتقييم صلاحيته للتطبيق في سياقات جديدة، وإضافة ميزات جديدة إليه، ومناقشة سبل التعامل مع أخطاء النموذج والنتائج غير المتوقعة. وربما يتطلب الأمر إعادة الكّرَّة مجدداً من مرحلة البناء والانطلاق، ويتوقف ذلك على إجابات هذه الأسئلة.
نسعى في أثناء مرحلة التصميم، وهذه المرحلة هي الجزء الأول من العملية، إلى تحديد هدف المشروع وترجمة هذا الهدف إلى غاية قابلة للقياس، وتحديد ما إذا كان هناك أثر تجاري كافٍ لتبرير جهود التطوير، ويتمثل الدور الرئيس لهذه المرحلة في تحديد حجم الفجوة بين ما نريد قياسه، وما يمكننا قياسه، والتأكد من مراعاة الشركة للوضوح فيما يخص عواقب وجود فجوة بين النتيجة المرجوة والبديل المتاح. وفي أغلب الأحيان تجد الشركات صعوبات في تحديد المقاييس الدقيقة التي تتطلبها الخوارزميات من أجل تلبية حاجات الشركة أو المستخدم، وهو ما يتسبب في إحباط الفرق التقنية، التي تبحث عن نقطة بداية واضحة لتحديد ما إذا كانت المهمة عملية أم لا. تستطيع الفرق التعامل مع هذه المسألة من خلال إطلاع إدارة الشركة على ما توصلت إليه من نتائج بصورة منتظمة خلال مرحلتي التصميم والاستكشاف، بل وربما إيقاف العمل في المشاريع في مرحلة مبكرة، إذا لزم الأمر، بسبب المخاوف المتوقعة من معدلات الخطأ أو انعدام الجدوى الاقتصادية، فعلى سبيل المثال قد تسعى إحدى شركات المراجعة والمحاسبة أو أحد البنوك إلى أتمتة جزء من عملية الامتثال، ولكنها تقرر في مرحلة مبكرة أن نسبة دقة التنبؤ التي تبلغ 70% تنطوي على مخاطر كبيرة بالنسبة إلى اليقين الذي تفرضه في أساليب عملها.
ويجب معالجة المسائل المتعلقة بقابلية التوضيح، والعدالة، والخصوصية خلال مرحلتي الاستكشاف والتنقيح اللتين تجرب خلالهما الفرق التقنية بدائل مختلفة للنموذج بغرض الوقوف على أفضل أسلوب لحل مشكلة المشروع. وتجدر الإشارة إلى أن الخوارزميات لا تنشأ جميعاً بشكل متساو (حتى الآن على الأقل، فقد يتغير هذا الأمر مع البحوث المستقبلية): فبعضها أكثر قابلية للتوضيح من غيره، وبعضها يسمح بدخول متغيرات للحفاظ على الخصوصية بصورة أكثر سهولة من غيره، ومن ثم فالأهم هو أن تتعرف الفرق التقنية على القيود سلفاً، وليس بعد استثمار الوقت في بناء الخوارزمية التي تفشل في تلبية متطلبات الشركة، لذا، لا بد من إشراك فرق الحوكمة في مناقشة الأمر خلال مرحلتي إجراء دراسة الجدوى وتنقيح النموذج، ولا يعني هذا إلغاء عملية التحقق قبل الإنتاج، ولكن ينبغي لهذه الفرق ألا تنتظر إلى حين انتهاء العملية حتى تشرع في مناقشة الأمر. وأخيراً، قد تكون هناك صعوبة في بعض الأحيان في اتخاذ قرار حول إمكانية التنازل عن الدقة في مقابل تحقيق الخصوصية، أو العدالة، أو قابلية التوضيح إلى أن تمتلك القدرة على قياس حجم الأثر على مستوى أداء النظام، ومن ثم يمكن للفرق التقنية اقتراح بعض الحلول وتقديم بعض الخيارات لمدير الشركة حتى يختار النظام الذي سيُطبَّق في مرحلة الإنتاج.
سيبدو الكثير من هذه المسائل مألوفاً للفرق التي اعتادت تطبيق أساليب أجايل في مشاريع تطوير البرمجيات، وتطرح الطبيعة الاستقرائية لأنظمة تعلم الآلة بعض الأسئلة الجديدة ذات الفوارق الدقيقة، ولكن تبقى مبادئ التواصل المكثف بين مختلف التخصصات أكثر أهمية من أي وقت مضى، ذلك أن نجاح الحل يتطلب في أغلب الأحيان تفاهماً بين الفرق الإدارية، والفرق التقنية، وفرق الحوكمة. وخلافاً للروايات الشائعة، فقد نستنتج من ذلك أن ممارسة تطبيق تعلم الآلة على نحو يلتزم بمبادئ المؤسسة وقيمها هي أرض خصبة للتفكير المنطقي والتواصل، وتتطلب منا إجادة تلك العملية تطبيق المهارات التي تميزنا كبشر.
تمت عملية الاشتراك بنجاح
عذراً،
أنت مشترك مسبقاً بالنشرة البريدية
