MLOps، مراحل و فرایندها (بخش دوم): فرایند دستی

مراحل و فرایندهای MLOps

همانطور که در مقاله «تعریف و لزوم MLOps» گفته شد، میتوان گفت MLOPS به معنای یکپارچه ­سازی توسعه و عملیات سیستم­ های یادگیری ماشین است که در آن تحویل مداوم و خودکارسازی پایپ­لاین ­های یادگیری ماشین انجام می­ شود. در فرایندهای تحویل مداوم MLOPS با سه بحث عمده مواجه هستیم:

  • فعالیت ­های مرتبط با CI  یا Continuous Integration
  • فعالیت­ ها و فرایندهای مرتبط با CD یا Continuous Delivery
  • و بحث CT یا Continuous Testing برای مدل ­های یادگیری ماشین.

از CI/CD/CT در خودکارسازی فرایند ساخت و تحویل مدل به محیط عملیاتی استفاده می شود که شامل گام­ های زیر است (شرح این گام ها در تعریف و لزوم MLOps آمده است):

  • استخراج داده
  • تحلیل و آماده سازی داده
  • آموزش مدل
  • ارزیابی (evaluation)مدل
  • اعتبارسنجی(validation) مدل
  • سرو کردن مدل به یکی از سه حالت زیر:
    • میکروسرویس با REST API برای سرو کردن پیش بینی های آنلاین
    • یک مدل تعبیه شده در یک دستگاه موبایل یا دستگاه لبه
    • بخشی از یک سیستم پیش بینی Batch
  • و مانیتور کردن مدل

سطح خودکارسازی گام ها، بلوع فرایند یادگیری ماشین را نشان می دهد. میزان این خودکارسازی منعکس کننده سرعت یادگیری مدل های جدید با داده جدید، و یا آموزش مدل جدید در پیاده سازی جدید است.

سه سطح از MLOps در ادامه این مجموعه مقالات شرح داده می شود. اولین سطح شامل هیچ نوع خودکارسازی ای در عملیات نیست، و آخرین سطح شامل خودکارسازی پایپلاین های ML و CI/CD است.

 

سطح صفر MLOPS: فرایند دستی

اغلب تیم های نرم افزاری، تیمی از دانشمندان داده (دیتاساینتیست) و محققان یادگیری ماشین دارند که مدل هایی در حد لبه تکنولوژی تولید می کنند. ولی فرایند ساخت و استقرار مدل ها در این تیم ها کاملا دستی است. این سطح، اولین سطح از سطوح بلوغ یا سطح صفر است. دیاگرام زیر این جریان کاری را نشان می ­دهد.

مراحل دستی سرو مدل به عنوان یک سرویس پیش بینی کننده

 

ویژگی های فرایند MLOPS سطح صفر

فرایندهای دستی، تعاملی و مبتنی بر اسکریپت: تمام گام های آنالیز داده، آماده­ سازی، آموزش مدل، و اعتبارسنجی به صورت دستی انجام می شود. نیاز به اجرای دستی، و انتقال دستی از یک مرحله به مرحله دیگر است. این فرایند معمولا با کدهای آزمایشی و اجرای آنها در یک notebook توسط دانشمندان داده، و بصورت تعاملی انجام می شود تا یک مدل قابل استفاده ایجاد شود.

عدم ارتباط میان یادگیری ماشین و عملیات: فرایند به گونه­ ای است که دانشمند داده (که مدل های یادگیری ماشین را می سازد) را از مهندس داده (که مدل را در محصول یکپارچه میکند) مجزا می کند. دانشمندان داده، مدل را به تیم مهندسی برای استقرار روی زیرساخت تحویل می دهند. این تحویل از طریق قرار دادن مدل روی یک محل ذخیره سازی اشتراکی، وارد کردن مدل در مخزن کد، یا آپلود کردن آن روی یک رجیستری مدل انجام می شود. سپس مهندسان که مدل را مستقر می کنند باید فیچرهای موردنیاز را در محیط عملیاتی و با تاخیر پایین تحویل دهند.

دوره های انتشار/ریلیز طولانی و با تکرارهای کم : این فرایند فرض می کند که تیم علم داده، مدل های کمی را با تغییرات کم (بدون نیاز به تغییر پیاده سازی مدل یا آموزش مجدد آن با داده جدید) ارائه می دهد.  در این حالت، یک مدل جدید فقط چندین بار در یک سال ممکن است ارائه شود.

عدم وجود CI: چون فرض بر  این است که تعداد تغییرات در پیاده سازی خیلی محدود است، CI نادیده گرفته می شود. معمولا تست کد، بخشی از notebook یا اسکریپت اجرا است. اسکریپت ها و notebookهایی که مراحل ازمایش را پیاده می کنند معمولا توسط ابزار کنترل کد منبع، مدیریت شده و artifact هایی مانند مدل های آموزش ­دیده، متریک ­های ارزیابی، و مصورسازی تولید می کنند

عدم وجود CD: چون استقرار ورژن های مختلف مدل بصورت دائمی وجود ندارد، CD هم در نظر گرفته نشده است.

منظور از استقرار همان سرویس پیش­ بینی است: بجای استقرار کل سیستم یادگیری ماشین، ققط استقرار مدل های آموزش­ دیده به عنوان یک سرویس پیش ­بینی (مثلا یک میکروسرویس با یک REST API) انجام می شود.  

مانیتورینگ فعال کارایی مدل انجام نمی شود: فرایند، به گونه ای پیاده سازی نشده است که عملکردها و پیش بینی های مدل را لاگ یا دنبال کند. درحالی که برای تشخیص کاهش کارایی مدل (model performance degradation) و دیگر مواردی که منجر به فاصله گرفتن مدل از رفتار مورد انتظار از آن می شود ( model drift)، به این موارد نیاز هست.

تیم مهندسی ممکن است setup پیچیده خود برای پیکربندی API، تست و استقرار شامل امنیت، رگرسیون تست بار و تست canary را در خود داشته باشد. علاوه بر این، استقرار یک نسخه جدید مدل در محیط واقعی، از طریق A/B Testing یا آزمایشات آنلاین، و  پیش از اینکه مدل، تمامی ترافیک درخواست پیش بینی را در دست بگیرد، انجام می شود.

چالش های MLOPS سطح صفر

MLOPS سطح صفر در بسیاری از کسب و کارهایی که در مراحل اولیه استفاده از مدل یادگیری ماشین در use case های خود هستند، مورد استفاده قرار می گیرد. این فرایند دستی و متکی بر دانشمندان داده است و وقتی که مدل ها به ندرت تغییر کنند یا به ندرت آموزش داده شوند، می تواند مفید باشد.

هرچند در واقعیت، چالش های یادگیری ماشین در محیط عملیاتی موجب می شود مدل ها در این محیط به درستی کار نکنند و نیاز به تغییر و آموزش مجدد داشته باشند. در واقع در این حالت، مدل ها نمی توانند با تغییرات در محیط پویا، و یا تغییرات در داده­ ای که محیط را توصیف می کند، سازگار شوند.

به منظور رفع این چالش ها و حفظ صحت (accuracy) مدل در محیط عملیاتی، باید فعالیت های زیر انجام شود:

  • به صورت فعالانه کیفیت مدل در محیط واقعی را مانیتور کنید: مانیتورینگ می تواند کاهش کارایی مدل را تشخیص دهد. این عمل، کلید طلایی در تکرار آزمایش های جدید و آموزش مجدد مدل با داده جدید است.
  • مدل های محیط عملیاتی خود را به صورت دوره ای مجددا آموزش دهید: برای دستیابی به الگوهای جدید و در حال تکامل، باید مدل را با داده های اخیر آموزش دهید. به عنوان مثال توصیه های ارائه شده توسط مدل پیشنهاد دهنده محصولات مُد (fashion)، باید با ترندها و محصولات اخیر بازار سازگار باشد.
  • به صورت مداوم با پیاده سازی های جدید آزمایش کنید تا مدل را بسازید: لازم است پیاده سازی های جدید مثل مدیریت فیچرها، معماری مدل، و هایپرپارامترها را امتحان کنید تا بتوانید از آخرین ایده ها و پیشرفته ترین فناوری ها استفاده کنید. به عنوان مثال اگر تشخیص چهره انجام می دهید، الگوهای چهره ثابت هستند ولی روش های جدید بهتر، می توانند صحت تشخیص را بهبود دهند.

برای رفع چالش های  این مدل دستی، روش های MLOps برای CI / CD و CT مفید هستند. با پیاده سازی یک پایپ لاین آموزش مدل، می توانید CT را فعال کنید، و می توانید یک سیستم CI / CD را برای تست، بیلد و استقرار سریع پیاده سازی های جدید پایپ لاین یادگیری ماشین راه اندازی کنید.

فرایندهای MLOps در سطوح یک تا سه، سعی در پیاده سازی این روش دارند. در مقاله ­های بعدی، به این فرایندها پرداخته می شود.