مدیریت پروژه های یادگیری ماشین – انجمن DEV

مقدمه
مشاوره و آموزش های فنی زیادی به صورت آنلاین در مورد مهندسی AI، ML یا پروژه های مرتبط با علم داده وجود دارد، اما توصیه های عملی بسیار کمی در مورد نحوه برنامه ریزی، مدیریت و اجرای کارآمد آنها در دسترس است. این مقاله مجموعهای از ابزارها و فرآیندهایی را پیشنهاد میکند که تیمهای ML میتوانند از آنها استفاده کنند.
مشکل
گارتنر ادعا می کند که 85 درصد از پروژه های هوش مصنوعی به دلایل مختلفی از جمله، اما نه محدود به موارد زیر، با شکست مواجه می شوند:
- ناتوانی در ارسال یک محصول دارای ML به تولید
- ارسال محصولاتی که مشتریان از آنها استفاده نمی کنند
- استقرار محصولات معیوب که مشتریان به آنها اعتماد ندارند
- ناتوانی در تکامل و بهبود سریع مدل ها در تولید
در حالی که تقریباً تمام پروژههای مهندسی نرمافزار میتوانند پیچیده باشند، پروژههای هوش مصنوعی و ML به دلیل عنصر ذاتی عدم قطعیت، چالشبرانگیز هستند. این واقعیت که این پروژه ها اساساً بر اساس فرضیه هایی هستند که ممکن است شکست بخورند.
در مهندسی نرمافزار سنتی، پروژهها معمولاً شامل پیادهسازی نیازمندیهای کاملاً تعریفشده هستند که در آن ورودیها به خروجیهای قابل پیشبینی منجر میشوند. موفقیت چنین پروژه هایی در درجه اول به درستی کد و رعایت مشخصات بستگی دارد. چیزهایی که می توان از طریق برنامه ریزی و اجرای “خوب” مدیریت کرد.
در مقابل، پروژه های ML با فرضیه ای در مورد الگوهای موجود در داده ها شروع می شوند. به عنوان مثال، یک پروژه ML ممکن است این فرض را مطرح کند که ویژگیهای خاصی میتوانند یک نتیجه را پیشبینی کنند، مانند ریزش مشتری یا توصیههای محصول. این فرضیه از طریق توسعه و آموزش یک مدل آزمایش می شود. با این حال، هیچ تضمینی وجود ندارد که ویژگیهای انتخاب شده، معماری مدل یا دادههای موجود، فرضیه را تایید کنند. این مدل ممکن است آنطور که انتظار می رود عمل نکند و منجر به نتایجی شود که می توانند نابهینه یا شکست های آشکار باشند. از این رو، علیرغم دقیقترین برنامهریزیها، مسائل پیشبینینشده همچنان میتواند به وجود بیاید که بازتاب قانون مورفی است: “هر چیزی که ممکن است اشتباه شود، اشتباه خواهد شد” (ادوارد آ. مورفی جونیور).
انگیزه این مقاله اجتناب از مشکلات نیست، بلکه یافتن آنها در اسرع وقت است. شکست سریع برای یافتن سریعتر راه حل مناسب.
کشف مشکل
اولین قدم برای پروژه ML، مانند هر پروژه دیگری، کشف و تعریف مشکل است.
کشف مجموعهای از فعالیتهاست که به ما کمک میکند مشکل، فرصت و راهحلهای بالقوه را بهتر درک کنیم. ساختاری برای هدایت عدم قطعیت از طریق فعالیتهای سریع، با زمان، و تکراری که سهامداران و مشتریان مختلف را درگیر میکند، فراهم میکند.
همانطور که در Lean Enterprise (O’Reilly) به صراحت بیان شده است، فرآیند ایجاد یک چشم انداز مشترک همیشه با تعریف واضح مشکل شروع می شود، زیرا داشتن بیانیه مشکل واضح به تیم کمک می کند تا روی آنچه مهم است تمرکز کند و حواس پرتی را نادیده بگیرد.
برای پروژههای ML، درک مشکل نه تنها برای دیدن راهحلهای مبتنی بر ML/AI مهم است، بلکه مهمتر این است که ببینیم چرا به آن نیاز است؟ چرا با رویکرد سنتی نمی توان مشکل را حل کرد؟
مشکل فناوریهای نوظهور این است که وقتی در چرخه گارتنر Hype در اوج انتظارات متورم قرار دارند، همه از آنها انتظار دارند که هر کاری را انجام دهند. و ما اکنون در زمانی زندگی می کنیم که هوش مصنوعی، به ویژه هوش مصنوعی مولد، همانطور که در نمودار بالا نشان داده شده است، در اوج انتظارات متورم است. بنابراین، برای یافتن بهترین راه حل برای مشکل داده شده، نیاز به تجزیه و تحلیل دقیق نیاز است.
برخی از ابزارهایی که می توانند به صاحبان محصول در تیم های یادگیری ماشین در این مرحله از پروژه ها کمک کنند به شرح زیر است:
فرآیند طراحی الماس دوگانه
تیمهای یادگیری ماشین مؤثر (O’ Reilly) پیشنهاد میکند که علاوه بر زمینه ML، یکی از ابزارهایی که میتواند برای هر سناریوی حل مسئله مفید باشد، فرآیند طراحی دابل الماس است.
چهار مرحله برای فرآیند وجود دارد:
-
كشف كردن: مشکل را درک کنید نه اینکه صرفاً آن را فرض کنید. این شامل صحبت کردن و گذراندن وقت با افرادی است – به عنوان مثال، مشتریان و کاربران – که تحت تأثیر این مشکل هستند.
-
تعريف كردن: بینش جمع آوری شده از مرحله کشف می تواند به تعریف چالش یا مشکل به روشی متفاوت کمک کند.
-
توسعه/طراحی:
پاسخ های متفاوتی را برای مشکل مشخص شده ایجاد کنید، به دنبال الهام گرفتن از جای دیگر و طراحی مشترک با طیف وسیعی از افراد مختلف باشید. -
ارائه: راهحلهای مختلف را در مقیاس کوچک آزمایش کنید، راهحلهایی را که جواب نمیدهند را رد کنید و راهحلهایی را که جواب میدهند بهبود بخشید.
اصل کلی تفکر واگرا و سپس همگرا در ابتدا در مسئله و سپس فضای راه حل تقریباً در هر سناریوی حل مسئله قابل اجرا است و همچنین ممکن است متوجه شوید که از این مدل برای اجرای جلسات، نوشتن کد یا برنامه ریزی یک مهمانی شام استفاده می کنید!
علاوه بر این، ابزار دیگری که در همان کتاب برای کشف محصول ML پیشنهاد شده است، Data Product Canvas است، ابزاری که چارچوب مناسبی برای اتصال تمام نقاط بین جمعآوری داده، تلاشهای ML و ایجاد ارزش فراهم میکند.
هر دوی این ابزارها، فرآیند طراحی الماس دوتایی و بوم محصول داده، مصنوعاتی را تولید میکنند که تیم را در طول اجرا مطلع و راهنمایی میکند.
Fail Fast، Pivot Fast Execution
هنگامی که درک درستی از مشکلی که باید حل شود را به دست می آوریم، تمرکز خود را بر روی تحویل تغییر می دهیم که چالش های منحصر به فرد خود را دارد زیرا کسب و کارها و مشتریان اغلب انتظارات روشنی ندارند یا درک درستی از آنچه محصول ML می تواند به دست آورد را ندارند زیرا:
- پیش بینی عملکرد یک سیستم ML با داده های موجود دشوار است.
- در طول ایده پردازی محصول؛
- ما ممکن است ایده هایی را تصور کنیم که از نظر فنی غیرممکن هستند.
- یا، ممکن است تا زمانی که آزمایشها را انجام ندادهایم و نمونههای اولیه کاربردی را توسعه دهیم، از این که کدام ویژگیها امکانپذیر است، بیاطلاع باشیم.
بنابراین، اتخاذ استراتژی شکست سریع و چرخش سریع ضروری است:
-
نمونه سازی سریع: با مدل های ساده و نمونه های اولیه برای آزمایش سریع فرضیه ها شروع کنید. از این نتایج اولیه برای هدایت توسعه بیشتر به جای سرمایه گذاری هنگفت در راه حل های پیچیده استفاده کنید.
-
تست و اعتبارسنجی مکرر: به طور منظم مدلها را روی دادههای اعتبارسنجی آزمایش کنید تا مشکلات را زودتر تشخیص دهید. اجرای آزمایش خودکار برای عملکرد مدل، اطمینان از ارزیابی دقیق هر تغییر.
-
تکرارهای کوچک: پروژه را به کارهای کوچکتر و قابل مدیریت یا اسپرینت تقسیم کنید. هر تکرار باید چیزی را ارائه دهد که بتوان آن را آزمایش و ارزیابی کرد و حلقههای بازخورد مکرری را ارائه کرد.
-
نقشه راه انعطاف پذیر: یک نقشه راه پروژه منعطف را حفظ کنید که امکان تغییرات را بر اساس بینش یا داده های جدید فراهم می کند. سفت بودن می تواند مانع از توانایی چرخش در زمانی که چیزی کار نمی کند، شود.
-
بازخورد اولیه کاربر: در صورت امکان، بازخورد اولیه را از کاربران نهایی یا ذینفعان دریافت کنید. بینش آنها می تواند مسائل عملی را آشکار کند و تنظیماتی را که ارتباط و اثربخشی پروژه را بهبود می بخشد راهنمایی کند.
-
نظارت و هشدار خودکار: پیاده سازی ابزارهای نظارتی برای ردیابی عملکرد مدل در تولید. هشدارهای خودکار برای کاهش عملکرد می تواند به شناسایی سریع زمانی که به یک محور یا بازآموزی نیاز است کمک کند.
-
تجزیه و تحلیل پس از مرگ: پس از هر بار تکرار یا سرعت، یک تجزیه و تحلیل کامل پس از مرگ انجام دهید تا بفهمید چه چیزی و چرا اشتباه شده است. از این بینش ها برای اطلاع از محورها و پیشرفت های آینده استفاده کنید.
آشنا به نظر می رسد؟ ما به عنوان مهندس چه چیز دیگری می دانیم که ذاتاً با عوارض سر و کار دارد و به تکرارهای کوچک، بازخورد اولیه کاربر و نقشه راه قابل تنظیم قابل انعطاف نیاز دارد؟ اسکرام. بنابراین آیا می توان از اسکرام برای پروژه های AI/ML استفاده کرد؟ آره:
اسکرام FTW
در اینجا یک راهنمای گام به گام برای پیاده سازی Scrum در پروژه های ML آورده شده است:
مرحله 1: تیم اسکرام را تشکیل دهید
- مالک محصول (PO): مسئول تعریف ویژگی ها و الزامات پروژه ML، مدیریت انباشت محصول و اطمینان از ارائه ارزش توسط تیم.
- اسکرام مستر (SM): فرآیندهای اسکرام را تسهیل می کند، موانع را از بین می برد و تضمین می کند که تیم به اصول اسکرام پایبند است.
- تیم توسعه: شامل دانشمندان داده، مهندسان ML، توسعه دهندگان نرم افزار و احتمالاً کارشناسان حوزه است. این تیم متقابل و مشارکتی است.
مرحله 2: بک الگ محصول را تعریف کنید
بک لاگ محصول برای یک پروژه ML شامل تمام وظایف و ویژگی های مورد نیاز برای دستیابی به اهداف پروژه است. این ممکن است شامل موارد زیر باشد:
- وظایف جمع آوری و پیش پردازش داده ها
- انتخاب مدل و آزمایش های آموزشی
- وظایف مهندسی ویژگی
- ارزیابی و اعتبارسنجی مدل
- وظایف استقرار و نظارت
- اسناد و وظایف گزارش
حتی اگر صاحب محصول در اینجا مسئول ایجاد اقلام عقب مانده محصول است، با استفاده از ابزارهای کشف که در بالا ذکر شد، تیم اسکرام می تواند با اطمینان از پاسخ به سؤالات زیر به اصلاح آنها کمک کند:
- آیا ما انگیزه های پشت استراتژی های جمع آوری داده های خود را مستند کرده ایم؟
- آیا رویکرد ما به جمع آوری داده ها با اهداف و الزامات پروژه همسو است؟
- آیا شکاف یا مشکلی در روند جمع آوری داده های فعلی وجود دارد؟
- چگونه به طور سیستماتیک زیرساخت خط لوله داده را برای پشتیبانی از مراحل بعدی پروژه ایجاد خواهیم کرد؟
- آیا خط لولهای خواهیم داشت که به دادهها، تبدیل و دسترسی به تیم مدلسازی رسیدگی کند؟
- آیا میتوانیم به تنگناهایی در خط لوله دادههای خود فکر کنیم که باید بعداً برطرف شوند؟
- چگونه میخواهیم مخازن مدل و زیرساختهای نسخهسازی را برای تمام مصنوعات پروژه ایجاد کنیم؟
- آیا مخازن راه اندازی شده و آماده استفاده هستند؟
- آیا تیم به طور مداوم از این مخازن برای ردیابی نسخههای مدلها، مجموعه دادهها و کد استفاده میکند؟
- آیا ما مخازن مدل و زیرساخت های نسخه سازی را برای تمام مصنوعات پروژه ایجاد کرده ایم؟
- آیا مخازن راه اندازی شده و آماده استفاده هستند؟
- آیا تیم به طور مداوم از این مخازن برای ردیابی نسخههای مدلها، مجموعه دادهها و کد استفاده میکند؟
همچنین تیم اسکرام می تواند ابزارهای زیر را که می تواند در عملیات مهندسی ML کمک کند، بررسی کند:
- 25 ابزار برتر MLOps
- بهترین ابزارهای گردش کار و ارکستراسیون خط لوله
مرحله 3: Sprint را برنامه ریزی کنید
اسپرینت در پروژه های ML می تواند بین 2-4 هفته طول بکشد. تیم اسکرام میتواند تصمیم بگیرد که میخواهد به چه چیزی برسد، آیا اسپرینت فقط برای مدیریت دادهها و ایجاد خط لوله داده مناسب برای پروژه است یا برای اجرای یک آموزش. در طی برنامهریزی اسپرینت، تیم مواردی را از بکلوگ محصول انتخاب میکند تا در طول اسپرینت روی آنها کار کند. این موارد باید به وظایف کوچکتر و قابل مدیریت تقسیم شوند (اسپرینت عقب ماندگی).
مرحله 4: Sprint را اجرا کنید
در طول دوی سرعت، تیم بر روی وظایف انتخاب شده کار می کند. مراسم اصلی اسکرام عبارتند از:
- استند آپ های روزانه: جلسات کوتاه روزانه که در آن اعضای تیم درباره کارهایی که دیروز انجام دادهاند، برنامهریزیشان برای انجام امروز و موانعی که با آنها مواجه هستند، صحبت میکنند. این به حفظ شفافیت و رسیدگی سریع به مسائل کمک می کند.
- بررسی های اسپرینت: در پایان هر دوی سرعت، تیم کار تکمیل شده را به ذینفعان نشان می دهد. این می تواند شامل ارائه یک مدل آموزش دیده، نمایش ویژگی های جدید یا به اشتراک گذاری معیارهای عملکرد باشد.
- دوی سرعت گذشته نگر: پس از بررسی اسپرینت، تیم در مورد اینکه چه چیزی خوب بود، چه چیزی خوب نبود و چگونه فرآیندها را می توان برای سرعت بعدی بهبود داد، فکر می کند.
مرحله 5: مدیریت و اولویت بندی بک لاگ
مالک محصول به طور مداوم بک لاگ محصول را اصلاح می کند، وظایف را بر اساس بازخورد از بررسی های اسپرینت، تغییرات در نیازمندی های پروژه و بینش های جدید اولویت بندی می کند. این ممکن است شامل موارد زیر باشد:
- افزودن منابع داده جدید
- تنظیم الزامات مدل
- ترکیب بازخورد از ذینفعان یا کاربران
مرحله 6: توسعه و اعتبار سنجی تکراری
پروژه های ML از چرخه های تکراری توسعه، آزمایش و اعتبار سنجی سود می برند. در طول هر دوی سرعت، تیم می تواند روی جنبه های خاصی تمرکز کند:
- اسپرینت های اولیه: جمع آوری داده ها، پاکسازی و تجزیه و تحلیل داده های اکتشافی (EDA).
- سرعت های میانی: نمونه سازی، آموزش و اعتبار سنجی اولیه مدل. با الگوریتم ها و فراپارامترهای مختلف آزمایش کنید.
- اسپرینت های بعدی: تنظیم مدل، اعتبارسنجی گسترده و استقرار.
مرحله 7: یک رویکرد سریع شکست خورده، سریع محوری را اتخاذ کنید
روشهای زیر را برای همسویی با روش شکست سریع و سریع محوری ترکیب کنید:
- نمونه سازی سریع: برای آزمایش سریع فرضیه ها و جمع آوری نتایج اولیه با مدل های ساده شروع کنید.
- بازخورد مستمر: به طور منظم عملکرد مدل را با استفاده از داده های اعتبارسنجی و بازخورد کاربر ارزیابی کنید.
- نقشه راه انعطاف پذیر: آماده باشید تا بر اساس داده های جدید، بازخوردها یا تغییرات در جهت پروژه حرکت کنید. بر این اساس اهداف عقب مانده و اسپرینت را به روز کنید.
مثال (تولید شده از chatGPT): پیاده سازی Scrum برای یک سیستم توصیه مبتنی بر ML
- اسپرینت 1: جمع آوری و کاوش داده ها
- Tasks: Collect user interaction data, clean the dataset, perform EDA.
- Deliverable: Cleaned dataset, initial insights from EDA.
- اسپرینت 2: توسعه مدل پایه
- Tasks: Implement a simple collaborative filtering model, evaluate its performance.
- Deliverable: Baseline model, performance metrics.
- اسپرینت 3: بهبود و اعتبارسنجی مدل
- Tasks: Experiment with different algorithms (e.g., content-based filtering), validate models with cross-validation.
- Deliverable: Improved model, comparative performance metrics.
- اسپرینت 4: استقرار و نظارت
- Tasks: Deploy the model, set up monitoring and feedback loops.
- Deliverable: Deployed model, monitoring dashboard.
- اسپرینت 5: پالایش و تکرار
- Tasks: Incorporate user feedback, fine-tune the model, address any performance issues.
- Deliverable: Refined model, updated metrics based on real-world usage.
با اتخاذ Scrum، پروژههای ML میتوانند از فرآیندهای توسعه ساختاریافته و تکرار شونده بهره ببرند که بهبود مستمر، انعطافپذیری و توانایی واکنش سریع به بینشها و تغییرات جدید را ممکن میسازد.
ابزارهای بیشتر
بوم فرضیه
بوم دیگری که به بیان سیستماتیک و آزمایش ایدههای ما در چرخههای سریع و پیگیری یادگیریها در طول زمان کمک میکند، بوم فرضیه است:
بیشتر در مورد آن اینجا بخوانید
مدل معماری نرم افزار C4
مدل C4 چارچوبی برای تجسم معماری سیستم های نرم افزاری در 4 سطح جزئیات است. زمینه، ظرف، مؤلفه و کد.
برای مهندسان تیمهای ML، استفاده از مدل C4 میتواند به شفافسازی معماری و طراحی سیستمهای ML کمک کند، و اطمینان حاصل کند که همه ذینفعان درک روشنی از نحوه ساختار سیستم و نحوه تعامل اجزای آن دارند. به عنوان مثال، در اینجا خلاصه ای مختصر از به کارگیری مدل C4 در مهندسی ML آورده شده است:
سطح 1: نمودار زمینه
- شناسایی موجودیت های خارجی: کاربران (به عنوان مثال، دانشمندان داده، کاربران نهایی) و سیستم های خارجی (به عنوان مثال، منابع داده، API).
- تعریف سیستم ML: مرزهای سیستم و هدف اصلی را مشخص کنید (مثلاً موتور توصیه).
سطح 2: نمودار کانتینر
- کانتینرها را شناسایی کنید: سرویس ML، جذب داده، آموزش مدل، ذخیره سازی داده، رابط کاربری.
- تعریف تعاملات: جریان های داده و تماس های API بین کانتینرها را شرح دهید.
سطح 3: نمودار مؤلفه
- ظروف تجزیه: به اجزاء تقسیم می شود (به عنوان مثال، پیش پردازش داده، آموزش مدل).
- تعریف تعاملات: تعاملات درون هر ظرف را مشخص کنید.
سطح 4: نمودار کد (اختیاری)
- پیاده سازی جزییات: نمایش کلاس ها و متدها برای اجزای کلیدی.
بیشتر در مورد آن اینجا بخوانید
از اینجا به کجا برویم
در این مقاله من برخی از ابزارها و فرآیندهایی را به اشتراک گذاشته ام که ممکن است به تیم های ML کمک کند. من می خواهم دو کتاب را که می توانند بخوانند بیشتر توصیه کنم:
-
تیم های موثر یادگیری ماشین (O’ Reilly)
-
مدیریت پروژه های یادگیری ماشین (Manning)
امیدواریم این مقاله مفید باشد. لطفاً نظرات خود را در نظرات زیر به اشتراک بگذارید.