خط لوله MLOPS کاملاً خودکار – قسمت 2

هدف

در پست وبلاگ قبلی خود ، ما شروع به کشف آموزش یک مدل پیش بینی با استفاده از داده های مصرف شده از طریق Sagemaker کردیم. در این پست نهایی ، ما با جزئیات جزئیات نظارت و بازآموزی خودکار برای مدل مستقر ، ارائه خط لوله کاملاً خودکار MLOPS خود را تکمیل خواهیم کرد و اطمینان حاصل می کنیم که عملکرد آن بهینه باقی مانده است.

کل کد منبع نسخه ی نمایشی در مخزن پروژه در GitHub در دسترس عموم است.

مدل و معماری

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

نظارت بر مدل

CodePipeline AWS برای استقرار منابع نظارت به محض انتقال نقطه پایان Sagemaker به حالت “IN_SERVICE” (مرجع 4) به طور خودکار تحریک می شود.

Sagemaker قابلیت های نظارت بر مدل داخلی را که توسط چارچوب ما استفاده شده است ، فراهم می کند. چهار نوع مانیتور مختلف وجود دارد که می توانند فعال و پیکربندی شوند: کیفیت داده ها ، کیفیت مدل ، توضیح مدل و تعصب مدل.

در این نسخه ی نمایشی ، ما فقط از کار نظارت بر کیفیت مدل استفاده می کنیم (به مستندات AWS مراجعه کنید) ، که شامل دو شغل پردازش ساژیمر (مرجع 5) است:

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

داشبورد مدل Sagemaker در کلیه مشاغل نظارت و نتایج آنها دید:

محدودیت ها

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

1. ساخته شده برای مجموعه داده های جدولی: مجموعه داده برای نظارت داخلی باید با یک قالب دقیق مطابقت داشته باشد. برای پرداختن به این موضوع ، ما یک خط لوله Sagemaker سفارشی به نام “جمع آوری داده ها” ایجاد کردیم که اسکریپت پایتون را قبل از برنامه نظارت بر مدل اجرا می کند ، تا مجموعه داده های Timeseries خود را با فرمت صحیح تطبیق دهیم. این خط لوله اضافی در خط لوله نظارت ادغام شده و به عنوان بخشی از آن مستقر می شود.
2. بدون معیارهای سفارشی: مانیتورینگ داخلی فقط تعداد معدودی از معیارها را برای محاسبه دقت مدل برای مجموعه داده های جدولی فراهم می کند. در Timeseries USECase ، ما نیاز به استفاده از یک متریک متفاوت برای تعیین اینکه آیا مدل هنوز عملکرد خوبی دارد یا آیا نیاز به آموزش مجدد دارد یا خیر. ما یک گام اضافی به خط لوله “جمع آوری داده ها” خود اضافه کردیم که اسکریپت پایتون دیگری را برای محاسبه متریک سفارشی اجرا می کند. نتیجه سپس به یک متریک CloudWatch سفارشی منتقل می شود و این امکان را فراهم می کند که توسط سایر خدمات AWS خوانده شود.
3. براساس برنامه: اجرای نظارت داخلی در خارج از برنامه Cron امکان پذیر نیست و پیوند آن را قبل یا بعد از سایر مشاغل و ایجاد اتوماسیون در اطراف آن دشوار می کند.
4. هشدارها رویدادهایی ایجاد نمی کنند: هشدارهای موجود در داشبورد نظارت بر مدل Sagemaker ، حوادث واقعی AWS را ایجاد نمی کنند ، و این باعث می شود که با تحریک فرآیندهای اتوماتیک ، واکنش به نتایج دقت مدل ضعیف را غیرممکن می کنند. از آنجا که ما قبلاً متریک CloudWatch سفارشی را در محل خود داشتیم ، یک زنگ هشدار CloudWatch را اضافه کردیم که متریک را در برابر آستانه بررسی می کند و به ما این امکان را می دهد تا به طور خودکار بازآموزی مدل را تحریک کنیم.

بازآفرینی مدل

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

1. نظارت: همانطور که در بالا توضیح داده شد ، ما از ترکیبی از یک کار خط لوله Sagemaker استفاده کردیم که یک متریک سفارشی را به عنوان متریک CloudWatch سفارشی و زنگ CloudWatch تحت فشار قرار داد.
2. عملکرد لامبدا: هنگامی که دقت مدل از زیر آستانه پایین می آید ، یک تابع Lambda توسط زنگ CloudWatch ایجاد می شود. این عملکرد کل چرخه عمر MLOP را آغاز می کند. در اولین مرحله “ساخت مدل” ، خط لوله مدل را بازیابی می کند. پس از آموزش ، معیارها قابل تأیید هستند و اگر نسخه مدل جدید بهتر از نسخه قبلی عمل کند ، می توان آن را به صورت دستی تأیید کرد.
3. داشبورد CloudWatch: یک داشبورد CloudWatch سفارشی تنظیم شده است تا آستانه فعلی (آبی) ، مدل دقت مدل (نارنجی) را نشان دهد و مواردی که عملکرد Lambda را بازآفرینی مدل (نقاط سبز) اجرا کرد.

نتیجه گیری و درسهای آموخته شده

1. آزمایش در مقابل عملکرد: یک درس مهم اهمیت انتقال از آزمایش به عمل است. تیم پلتفرم باید اطمینان حاصل کند که یک پلتفرم علوم داده قوی برای آزمایش در دسترس است. با این حال ، پس از پایان مرحله آزمایش ، دانشمندان داده باید از آزمایشگاه یا نوت بوک خود خارج شوند و کد خود را عملیاتی کنند.
2. خدمات غنی از ویژگی ها: AWS Sagemaker ثابت می کند که ابزاری قدرتمند است و بسیاری از ویژگی ها را برای آزمایش های علوم داده و عملیاتی سازی ارائه می دهد. مجموعه جامع آن به ساده سازی گردش کار از توسعه تا استقرار کمک می کند و آن را به یک دارایی ارزشمند برای تیم های علوم داده تبدیل می کند.
3. محدودیت های نظارت: نظارت داخلی Sagemaker محدودیت هایی دارد. این برنامه در درجه اول برای مجموعه داده های جدولی طراحی شده است و فقط معیارهای دقت کلاسیک را ارائه می دهد. علاوه بر این ، سیستم هشدار رویدادهایی را ایجاد نمی کند ، که می تواند یک اشکال برای تیم هایی باشد که به راه حل های نظارت پویاتر نیاز دارند.
4. خیلی بیشتر برای کشف: سفر ما با Sagemaker نشان داده است که هنوز چیزهای بیشتری برای کشف وجود دارد. این پلتفرم ویژگی های نظارت اضافی مانند کیفیت داده ها و تشخیص رانش داده را ارائه می دهد ، که ما هنوز به طور کامل آن را بررسی نکرده ایم. این ابزارها می توانند بینش های عمیق تری و کنترل بهتری بر عملکرد مدل در تولید ارائه دهند.

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