طرق تحسين كفاءة التجارب العلمية للبيانات: تجنب الأخطاء الشائعة في مرحلة التطوير

تقليص وقت تحقيق القيمة في مشاريع العلوم البيانات: الجزء الأول تعد مرحلة التجربة والتطوير من أكثر المراحل التي يجب أن يتألق فيها علماء البيانات. في هذه المرحلة، يقوم العلماء بتجربة مختلف معالجات البيانات، توليفات الخصائص، واختيارات النماذج وغيرها من العوامل لتحقيق الحل المقترح لتلبية احتياجات الأعمال. تم تدريب علماء البيانات على القيام بهذه التجارب وتقييمها بعناية، ولكن يمكن لهذه المرحلة أن تستغرق وقتًا طويلًا وتهدد بتعثر المشروع قبل أن يبدأ فعليًا. يُعرف الوقت الذي يستغرقه العلماء للانتقال من مرحلة التجربة إلى مرحلة التنفيذ بـ"وقت تحقيق القيمة". ومن خلال تجربتي الشخصية، لاحظت أن الاعتماد الزائد على دفاتر العمل مثل Jupyter Notebooks، وتجربة التجارب بالتوازي بشكل يدوي، وسوء تطبيق أفضل الممارسات البرمجية هي بعض الأسباب التي تجعل التجربة والاستكشاف يستغرقان وقتًا أطول مما ينبغي، مما يعرقل تحقيق القيمة للأعمال. دفاتر العمل: فوائدها وأضرارها يُعد Jupyter Notebooks أحد الأدوات الأساسية لكل علماء البيانات بسبب قدرتها على تشغيل الشفرات البرمجية بشكل تفاعلي، وإنشاء الرسوم البيانية، ودمج الكود مع Markdown. عند بدء مشروع جديد أو التعامل مع مجموعة بيانات جديدة، تكون الخطوات الأولى غالبًا هي تشغيل دفتر عمل، تحميل البيانات، والبدء في استكشافها. لكن يمكن أن يساء استخدام هذه الدفاتر ويدفعها إلى القيام بأعمال لا تناسبها. من أبرز السلوكيات السيئة في استخدام الدفاتر هي تشغيل الكتل البرمجية بطريقة غير متزامنة، تعريف الوظائف داخل الكتل، وتخزين بيانات الاعتماد / المفاتيح API كمتغيرات ثابتة. هذه السلوكيات تؤدي إلى مشكلات عديدة، حيث يصعب اختبار الوظائف للتأكد من صحتها وتطبيق أفضل الممارسات، كما أنها لا يمكن استخدامها خارج الدفتر نفسه. الوظائف المحلية مقابل العالمية بعض علماء البيانات يدركون هذه السلوكيات السيئة ويستخدمون أفضل الممارسات في تطوير الكود، مثل: تحديد الوظائف في دليل محلي: هذا النهج أفضل بكثير من ترك الوظائف محددة داخل الدفتر، ولكنه لا يزال يفتقر إلى شيء مهم. خلال مسيرتك المهنية، ستتعامل مع مشاريع متعددة وستكتب الكثير من الكود. قد تحتاج إلى إعادة استخدام الكود الذي كتبته في مشروع سابق، وهو أمر شائع حيث غالبًا ما يكون هناك تداخل كبير بين الأعمال. مشكلات الصيانة: عند مشاركة الوظائف بطريقة نسخ ولصق من مستودع إلى آخر، يمكن أن ينشأ مشكلات في الصيانة إذا تم العثور على مشكلات في نسخة من هذه الوظائف، يتطلب ذلك جهدًا كبيرًا لإيجاد جميع النسخ الأخرى وتطبيق الإصلاحات. كما يمكن أن تتطلب الوظائف الخاصة تعديلات صغيرة لتغيير استخدامها، مما يؤدي إلى وجود وظائف متعددة تشارك 90% من الكود مع اختلافات طفيفة فقط. تضخم النصوص: هذا النهج يؤدي أيضًا إلى تضخم النصوص البرمجية بوظائف ذات ترابط قليل أو غير مرتبط ببعضها البعض. التركيز على بناء المكونات وليس مجرد الوظائف ماذا أعني بالمكونات؟ فكر في مهمة مثل تنفيذ تقنيات مختلفة لتحضير البيانات قبل إدخالها في النموذج. عليك النظر في جوانب مثل التعامل مع البيانات المفقودة، تسوية البيانات العددية، ترميز البيانات الفئوية، وتوظيف الفئات (إذا كنت تنظر في التصنيف) وغيرها. إذا كنت تريد تجربة جميع هذه الطرق، كيف يمكنك القيام بذلك؟ التعديل اليدوي للكتل البرمجية بين التجارب بسيط ولكنه يصبح كابوسًا إداريًا. كيف يمكنك تذكر الإعداد الذي كان لديك لكل تجربة إذا كنت تكتب فوق الكود باستمرار؟ النهج الأفضل هو كتابة تصريحات شرطية تسهل التبديل بينها. حتى مع هذا الإعداد، لا تزال هناك مشكلات حول إعادة الاستخدام عند تعريفها داخل الدفتر. أوصي بفصل جميع هذه الوظائف في وظيفة غلاف مع وسيطة تسمح لك باختيار المعالجة التي تريد تنفيذها. في هذا السيناريو، لا يحتاج الكود إلى التغيير بين التجارب ويمكن تطبيق الوظيفة في أماكن أخرى. هذه العملية ستساعد في تحسين تدفق عمل العلوم البيانات. بدلاً من إعادة بناء وظائف متشابهة أو نسخ ولصق الكود الموجود مسبقًا، يمكن استخدام مستودع كود يحتوي على مكونات عامة يمكن إعادة استخدامها بسهولة. يمكن فعل ذلك لخطوات مختلفة في عملية تحويل البيانات وربطها معًا لتشكيل وظيفة متماسكة واحدة. الاعتبارات التصميمية عند تنظيم هذا المستودع الكودي للاستخدام، هناك العديد من القرارات التصميمية التي يجب التفكير فيها. التكوين النهائي سيعكس احتياجاتك ومتطلباتك، ولكن بعض الاعتبارات هي: فصل الكود حسب المكونات: لكل مكون دليل منفصل يحتوي على كل الوظائف التي يحتاجها. استخدام فصول تحتوي على جميع الوظائف: يتم تعريف جميع الوظائف في فصل واحد يتعامل مع مكون معين. طريقة تنفيذ واحدة: تحتوي الفصل على طريقة تنفيذ واحدة تقوم بتنفيذ الخطوات. ملاحظة: يمكن التحكم في الوظائف التي تريد أن يقوم بها الفصل بواسطة ملف تكوين. سيتم استكشاف هذا الجانب في مقال لاحق. الوصول إلى الطرق من المستودع بسيط يمكنك بسهولة استيراد وتنفيذ الطرق من هذا المستودع: استيراد الفصل: import data_preparation إنشاء كائن: prep = data_preparation.DataPrep() تنفيذ الطريقة: prep.execute(config_file) المستودع المركزي المحايد يسمح ببناء أدوات قوية تعاونية قد يبدو أن وجود صندوق أدوات لخطوات العلوم البيانات الشائعة فكرة جيدة، لكن لماذا الحاجة إلى مستودع منفصل؟ تم الإجابة جزئيًا على هذا السؤال أعلاه، حيث أن فكرة فصل تفاصيل التنفيذ عن تطبيق الأعمال تشجعنا على كتابة كود أكثر مرونة يمكن إعادة توظيفه في سيناريوهات مختلفة. القوة الحقيقية لهذا النهج تكمن عندما لا تفكر في نفسك فقط، بل في زملائك وزملاء عملك في المنظمة. تخيل حجم الكود الذي ينتج عن جميع علماء البيانات في شركتك. كم من هذا الكود سيكون فريدًا لمشروعهم؟ بالطبع بعضه بالتأكيد، ولكن ليس كل شيء. حجم الكود الذي يتم إعادة تنفيذه سيمر دون أن يلاحظ، ولكنه سيساهم بسرعة كثقب صامت في الموارد. الآن فكر في البدائل حيث يوجد موقع مركزي لادوات علماء البيانات الشائعة. ستتوفر الوظائف التي تغطي خطوات مثل جودة البيانات، اختيار الخصائص، ضبط المعلمات الفائقة وغيرها فورًا لتكون جاهزة للاستخدام. سيوفر هذا الكود المركزي فرصًا لبناء أدوات أكثر موثوقية واستخدامًا عامًا. زيادة عدد المستخدمين تزيد من احتمالية اكتشاف أي مشكلات أو أخطاء، وسوف يفرض استخدام الكود عبر مشاريع متعددة عليه أن يكون أكثر تعميمًا. يحتاج المستودع المركزي إلى مجموعة واحدة فقط من الاختبارات، ويمكن اتخاذ الإجراءات اللازمة لضمان شمولها وكفايتها. كمستخدم لهذه الأدوات، قد يكون هناك حالات حيث الوظائف التي تحتاجها غير موجودة في قاعدة الكود. أو قد يكون لديك تقنية خاصة ترغب في استخدامها ولم يتم تنفيذها. بينما يمكنك اختيار عدم استخدام هذا المستودع الكودي المركزي، لم لا تساهم فيه؟ العمل معًا كفريق أو حتى كشركة بأكملها لبناء مستودع كود مركزي يفتح أبوابًا عديدة. استغلال قوة كل عالم بيانات عندما يساهمون بالتقنيات التي يستخدمونها بشكل روتيني يخلق سيناريو مصدر مفتوح داخليًا يشجع التعاون بين الزملاء لتحقيق هدف تسريع عملية تجربة العلوم البيانات. الخلاصة يهدف هذا المقال إلى بداية سلسلة حيث أتناول الأخطاء الشائعة في العلوم البيانات التي قد تعيق عملية التجربة والتطوير. النتيجة هي زيادة وقت تحقيق القيمة أو فشل المشروع في بعض الحالات. ركزت هنا على طرق كتابة وتخزين الكود بحيث يكون مودوليًا وغير مرتبط بمشروع معين. يمكن إعادة استخدام هذه المكونات عبر مشاريع متعددة مما يسمح بتطوير حلول أسرع وأكثر ثقة في النتائج. يمكن تطوير مثل هذا المستودع الكودي ليكون مفتوح المصدر لجميع أعضاء المنظمة، مما يساعد في بناء أدوات قوية ومرونة ومتينة.