پروژه‌های ML به تیم‌هایی با اعضایی نیاز دارند که دارای طیف وسیعی از مهارت‌ها، تخصص و مسئولیت‌های مرتبط با یادگیری ماشین هستند. اینها رایج ترین نقش هایی هستند که در تیم های معمولی ML یافت می شوند:
| نقش | دانش و مهارت | قابل تحویل اصلی |
|---|---|---|
| مدیر محصول ML | مدیران محصول ML درک عمیقی از نقاط قوت و ضعف ML و فرآیند توسعه ML دارند. آنها با همکاری با تیم ML، کاربران نهایی و سایر ذینفعان، مشکلات تجاری را با راه حل های ML تراز می کنند. آنها چشم انداز محصول را ایجاد می کنند، موارد استفاده و الزامات را تعریف می کنند و پروژه ها را برنامه ریزی و اولویت بندی می کنند. | سند الزامات محصول (PRD). |
| مدیریت مهندسی | مدیران مهندسی با تعیین، برقراری ارتباط و دستیابی به اولویت های تیم به اهداف تجاری دست می یابند. مانند مدیران محصول ML، آنها راه حل های ML را با مشکلات تجاری هماهنگ می کنند. آنها انتظارات واضحی از اعضای تیم تعیین می کنند، ارزیابی عملکرد را انجام می دهند و به پیشرفت شغلی و حرفه ای کمک می کنند. | طراحی اسناد، طرح های پروژه و ارزیابی عملکرد. |
| دانشمند داده | دانشمندان داده از تجزیه و تحلیل کمی و آماری برای استخراج بینش و ارزش از داده ها استفاده می کنند. آنها به شناسایی و آزمایش ویژگی‌ها، مدل‌های اولیه و کمک به تفسیرپذیری مدل کمک می‌کنند. | گزارش ها و تجسم داده ها که از طریق تجزیه و تحلیل آماری به سوالات تجاری پاسخ می دهد. |
| مهندس ML | مهندسان ML مدل های ML را طراحی، می سازند، تولید می کنند و مدیریت می کنند. آنها مهندسان نرم افزار قوی با درک عمیق از فن آوری های ML و بهترین شیوه ها هستند. | مدل مستقر با کیفیت پیش‌بینی کافی برای دستیابی به اهداف تجاری. |
| مهندس داده | مهندسان داده خطوط لوله داده را برای ذخیره، تجمیع و پردازش مقادیر زیادی داده ایجاد می کنند. آنها زیرساخت ها و سیستم هایی را برای جمع آوری و تبدیل داده های خام به فرمت های مفید برای آموزش و ارائه مدل توسعه می دهند. مهندسان داده مسئول داده ها در کل فرآیند توسعه ML هستند. | خطوط لوله داده کاملاً تولید شده با نظارت و هشدار لازم. |
| مهندس عملیات توسعه دهنده (DevOps). | مهندسان DevOps زیرساخت های سرویس دهی مدل های ML را توسعه، استقرار، مقیاس بندی و نظارت می کنند. | یک فرآیند خودکار برای سرویس دهی، نظارت، آزمایش و هشدار در مورد رفتار یک مدل. |
پروژه های موفق ML دارای تیم هایی هستند که هر نقش به خوبی نشان داده شده است. در تیم های کوچکتر، افراد باید مسئولیت های چند نقش را بر عهده بگیرند.
تمرینات تیمی را ایجاد کنید
از آنجایی که نقش‌ها، ابزارها و چارچوب‌ها در توسعه ML بسیار متفاوت است، ایجاد شیوه‌های مشترک از طریق مستندسازی فرآیند عالی بسیار مهم است. به عنوان مثال، یک مهندس ممکن است فکر کند که فقط گرفتن داده های مناسب برای شروع آموزش یک مدل کافی است، در حالی که یک مهندس مسئول تر تأیید می کند که مجموعه داده به درستی ناشناس است و ابرداده و منشأ آن را مستند می کند. اطمینان از اینکه مهندسان تعاریف مشترکی را برای فرآیندها و الگوهای طراحی به اشتراک می گذارند، سردرگمی را کاهش می دهد و سرعت تیم را افزایش می دهد.
مستندات فرآیند
اسناد فرآیند باید ابزارها، زیرساخت‌ها و فرآیندهایی را که تیم برای توسعه ML استفاده می‌کند، تعریف کنند. اسناد فرآیند خوب به همسو کردن اعضای جدید و فعلی تیم کمک می کند. آنها باید به انواع سوالات زیر پاسخ دهند:
- داده ها برای مدل چگونه تولید می شوند؟
- چگونه داده ها را بررسی، اعتبارسنجی و تجسم کنیم؟
- چگونه یک ویژگی یا برچسب ورودی را در داده های آموزشی تغییر دهیم؟
- چگونه خط لوله تولید داده، آموزش و ارزیابی را سفارشی کنیم؟
- چگونه می توانم معماری مدل را برای تطبیق با تغییرات در ویژگی های ورودی یا برچسب ها تغییر دهم؟
- چگونه نمونه های تست را بدست آوریم؟
- برای قضاوت در مورد کیفیت مدل از چه معیارهایی استفاده خواهیم کرد؟
- چگونه مدل های خود را در تولید عرضه کنیم؟
- چگونه متوجه می شویم که آیا مشکلی در مدل ما وجود دارد؟
- مدل های ما به چه سیستم های بالادستی وابسته هستند؟
- چگونه SQL خود را قابل نگهداری و استفاده مجدد کنم؟
سوالات احتمالی بیشتر
مدلآیا می توانم مدل ها را بر روی مجموعه داده های مختلف در یک خط لوله، مانند تنظیم دقیق، آموزش دهم؟
چگونه یک مجموعه داده آزمایشی جدید را به خط لوله خود اضافه کنم؟
چگونه می توانم پیش بینی مدل را در یک نمونه دست ساز بررسی کنم؟
چگونه می توانم نمونه هایی را که در آن مدل اشتباه کرده است، پیدا، بررسی و تجسم کنم؟
چگونه تعیین کنم که کدام ویژگی بیشترین مسئولیت را برای یک پیش بینی داده شده دارد؟
چگونه بفهمم کدام ویژگی بیشترین تأثیر را بر پیش‌بینی‌های یک نمونه معین دارد؟
چگونه می توانم پیش بینی های مدل را روی یک مجموعه داده یا نمونه انتخابی محاسبه یا ترسیم کنم؟
چگونه می توانم معیارهای استاندارد را برای پیش بینی های مدل خود در یک مجموعه داده انتخابی محاسبه کنم؟
چگونه معیارهای سفارشی را توسعه و محاسبه کنم؟
چگونه مدل خود را با سایر مدل های آفلاین مقایسه کنم؟
آیا می توانم متاآنالیز را برای ارزیابی مدل های متعدد در یک محیط توسعه واحد انجام دهم؟
آیا می توانم مدل فعلی را با مدل 10 ماه قبل مقایسه کنم؟
فکر می کنم یک مدل خوب ایجاد کردم. چگونه می توانم آن را در مرحله تولید راه اندازی کنم؟
چگونه می توانم تأیید کنم که مدل جدید من به درستی در حال تولید است؟
آیا می توانم تاریخچه ارزیابی مدل ها را در طول زمان دریافت کنم؟
چگونه می توانم بفهمم که مشکلی در مدل وجود دارد؟
به من یک صفحه/اشکال اختصاص داده شده است که در آن چیزی در مورد مدل ذکر شده است. باید چکار کنم؟
چگونه می توانم خط لوله تولید/آموزش/ارزیابی داده را سفارشی کنم؟
چه زمانی و چگونه باید یک خط لوله کاملا جدید ایجاد کنم؟
من برای تولید برخی از داده ها به SQL نیاز دارم. کجا باید بذارمش؟
سرویس مدل ما چگونه کار می کند؟ آیا نمودار وجود دارد؟
مدل من به چه سیستم های بالادستی بستگی دارد که باید از آن آگاه باشم؟
من نمی توانم چیزی را بفهمم. با چه کسی (و چگونه) باید تماس بگیرم؟
یادت باشه
آنچه "بهترین شیوه های ML" را تشکیل می دهد می تواند بین شرکت ها، تیم ها و افراد متفاوت باشد. به عنوان مثال، برخی از اعضای تیم ممکن است Colabs آزمایشی را به عنوان تحویل اصلی در نظر بگیرند، در حالی که دیگران مایلند در R کار کنند. برخی ممکن است به مهندسی نرم‌افزار علاقه داشته باشند، دیگران فکر می‌کنند نظارت مهمترین چیز است، با این حال شخص دیگری از چیزهای خوب آگاه است. شیوه های تولید ویژگی را انجام می دهد اما می خواهد از Scala استفاده کند. هرکسی از منظر خود "حق" است و اگر به درستی هدایت شود، ترکیب نیروگاهی خواهد بود. اگر نه، می تواند یک آشفتگی باشد.
ایجاد ابزارها، فرآیندها و زیرساخت هایی که تیم قبل از نوشتن یک خط کد از آنها استفاده می کند، می تواند تفاوت بین شکست پروژه پس از دو سال یا راه اندازی موفقیت آمیز یک چهارم زودتر از برنامه باشد.
ارزیابی های عملکرد
با توجه به ابهام و عدم قطعیت ذاتی در ML، مدیران افراد باید انتظارات روشنی را تعیین کنند و زودتر قابل تحویل را تعریف کنند.
هنگام تعیین انتظارات و محصولات قابل تحویل، در نظر بگیرید که در صورت عدم موفقیت یک پروژه یا رویکرد، چگونه ارزیابی می شوند. به عبارت دیگر، مهم است که عملکرد یک عضو تیم به طور مستقیم با موفقیت پروژه مرتبط نباشد. برای مثال، غیرمعمول نیست که اعضای تیم هفته ها را صرف بررسی راه حل هایی کنند که در نهایت ناموفق هستند. حتی در این موارد، کد با کیفیت بالا، مستندات کامل و همکاری موثر آنها باید به ارزیابی آنها کمک کند.