خطوط لوله MLOps با افزودن مراحل آموزش مدل، اعتبارسنجی و نظارت متناسب با گردشهای کاری یادگیری ماشین، CI/CD سنتی را گسترش میدهند. در حالی که CI/CD سنتی بر استقرار کد تمرکز دارد، MLOps نسخهبندی دادهها، ردیابی آزمایش و تشخیص رانش مدل را در کل چرخه عمر ML مدیریت میکند.
گردشهای کاری سرتاسری که برای ساخت، استقرار و نظارت بر مدلهای یادگیری ماشین در محیطهای عملیاتی طراحی شدهاند.
خطوط لوله خودکار که کد برنامه را از طریق ادغام مداوم و شیوههای تحویل مداوم میسازند، آزمایش میکنند و مستقر میکنند.
| ویژگی | خطوط لوله MLOps | CI/CD نرمافزار سنتی |
|---|---|---|
| تمرکز اصلی | چرخه حیات مدل و گردشهای کاری داده | استقرار کد برنامه |
| مراحل کلیدی | اعتبارسنجی دادهها، آموزش، ارزیابی، استقرار، نظارت | ساخت، آزمایش، استقرار |
| نسخهبندی | کد، دادهها، مدلها و ویژگیها | فقط کد و پیکربندی |
| رویکرد تست | دقت مدل، بایاس، رانش و آزمونهای کیفیت دادهها | آزمونهای واحد، ادغام و رگرسیون |
| نیازهای نظارتی | رانش پیشبینی، رانش دادهها، عملکرد مدل | زمان روشن بودن برنامه، خطاها، تأخیر |
| تکرارپذیری | ردیابی آزمایش با پارامترها و مصنوعات | ساخت مصنوعات از کد نسخهبندیشده |
| الزامات محاسباتی | دسترسی به GPU/TPU برای حجم کاری آموزشی | سرورها و اجراکنندههای ساخت استاندارد |
| ابزارهای رایج | MLflow، Kubeflow، SageMaker، Vertex AI | جنکینز، اقدامات گیتهاب، GitLab CI |
| حلقه بازخورد | بازآموزی مداوم بر اساس دادههای جدید | انتشارهای تکراری بر اساس بازخورد کاربر |
خطوط لوله سنتی CI/CD یک مسیر نسبتاً خطی را دنبال میکنند: کد اجرا میشود، در مصنوعات ساخته میشود، آزمایش میشود و در محیط عملیاتی مستقر میشود. خطوط لوله MLOps مراحل اضافی را بر روی این پایه قرار میدهند، از جمله اعتبارسنجی دادهها، مهندسی ویژگی، آموزش مدل و ارزیابی مدل. این مراحل اضافی نشان دهنده این واقعیت است که سیستمهای یادگیری ماشین به کیفیت دادهها و رفتار مدل وابسته هستند، نه فقط صحت کد.
در CI/CD سنتی، نسخهبندی بر روی کد منبع و فایلهای پیکربندی تمرکز دارد که برای بازتولید یک ساخت کافی است. MLOps به چیزهای بسیار بیشتری نیاز دارد: تیمها باید مجموعه دادهها را نسخهبندی کنند، دادههایی را که به آموزش وارد شدهاند، پیگیری کنند، پارامترهای فوق را ثبت کنند و مصنوعات مدل را ذخیره کنند. بدون این نظم، بازتولید نتایج یک مدل تقریباً غیرممکن میشود، به همین دلیل است که ابزارهای ردیابی آزمایش مانند MLflow به بخش اصلی MLOps تبدیل شدهاند.
CI/CD نرمافزاری به آزمایشهای قطعی متکی است که در آنها ورودیها، خروجیهای قابل پیشبینی تولید میکنند. آزمایش MLOps اساساً متفاوت است زیرا مدلها سیستمهای آماری هستند. تیمها آزمایشهایی را برای اعتبارسنجی طرحواره دادهها، انصاف مدل، دقت پیشبینی در مجموعههای ناپایدار و تشخیص سوگیری اضافه میکنند. یک مدل میتواند تمام آزمایشهای سنتی را پشت سر بگذارد، اما اگر توزیع دادههای ورودی تغییر کند، در تولید همچنان ضعیف عمل میکند.
خطوط لوله سنتی، سلامت برنامه را از طریق معیارهایی مانند نرخ خطا، زمان پاسخ و میزان استفاده از CPU رصد میکنند. نظارت بر MLOps با ردیابی سیگنالهای خاص مدل مانند رانش پیشبینی، تغییرات توزیع ویژگیها و معیارهای کسبوکار پاییندستی، فراتر میرود. هنگامی که رانش تشخیص داده میشود، خط لوله میتواند آموزش مجدد خودکار را آغاز کند، چیزی که CI/CD سنتی به ندرت به آن نیاز دارد.
CI/CD استاندارد روی سرورهای ساخت ساده اجرا میشود، زیرا کامپایل و آزمایش کد به ندرت به محاسبات سنگین نیاز دارد. خطوط لوله MLOps اغلب برای آموزش به GPU یا TPU و همچنین ذخیرهسازی مقیاسپذیر برای مجموعه دادههایی که میتوانند به ترابایت برسند، نیاز دارند. به همین دلیل است که اکثر پلتفرمهای MLOps روی Kubernetes یا سرویسهای ابری مدیریتشده ساخته شدهاند که میتوانند سختافزار تخصصی را بر اساس تقاضا ارائه دهند.
CI/CD سنتی عمدتاً متعلق به مهندسان نرمافزار و تیمهای DevOps است. MLOps نیازمند همکاری بین دانشمندان داده، مهندسان ML و کارکنان عملیات است، زیرا این خط لوله شامل آزمایشهای تحقیقاتی و استقرار تولید میشود. این تغییر فرهنگی اغلب بیش از خود ابزار، زمانی که سازمانها شیوههای MLOps را اتخاذ میکنند، اهمیت دارد.
MLOps فقط CI/CD است که مراحل اضافی به آن اضافه شده است.
MLOps اساساً نحوه طراحی خطوط لوله را تغییر میدهد، زیرا مدلها مصنوعات آماری هستند که با گذشت زمان تخریب میشوند. خط لوله باید کیفیت دادهها، نسخهبندی مدل و بازآموزی مداوم را در نظر بگیرد، که CI/CD سنتی هرگز برای مدیریت آنها ساخته نشده بود.
شما میتوانید از ابزارهای سنتی CI/CD مانند Jenkins برای یادگیری ماشین بدون تغییر استفاده کنید.
اگرچه جنکینز میتواند کارهای آموزشی را هماهنگ کند، اما فاقد پشتیبانی بومی برای ردیابی آزمایش، ثبت مدل و نظارت بر رانش است. اکثر تیمها یا جنکینز را به شدت گسترش میدهند یا پلتفرمهای اختصاصی MLOps را برای پر کردن این شکافها اتخاذ میکنند.
به محض اینکه یک مدل مستقر شود، کار تمام است.
مدلهای مستقر شده با دور شدن دادههای دنیای واقعی از توزیعهای آموزشی، دچار افت عملکرد میشوند. خطوط لوله MLOps دقیقاً به این دلیل شامل حلقههای نظارت و آموزش مجدد هستند که نگهداری مدل یک مسئولیت مداوم است، نه یک رویداد یکباره.
خطوط لوله MLOps به طور کامل جایگزین شیوههای DevOps میشوند.
MLOps به جای جایگزینی DevOps، بر روی آن ساخته میشود. رویههای اصلی مانند زیرساخت به عنوان کد، تست خودکار و استقرار مداوم همچنان ضروری هستند. MLOps به سادگی لایههای خاص یادگیری ماشین را به این پایهها اضافه میکند.
دادههای بیشتر همیشه عملکرد مدل را در تولید بهبود میبخشند.
بدون اعتبارسنجی مناسب دادهها و بررسی کیفیت، دادههای جدید میتوانند نویز، بایاس یا تغییرات توزیع را ایجاد کنند که به دقت مدل آسیب میرساند. خطوط لوله MLOps شامل مراحل اعتبارسنجی دادهها هستند که بهطور خاص برای شناسایی این مشکلات قبل از رسیدن به آموزش طراحی شدهاند.
زمانی که خروجی شما کد برنامه با رفتار قطعی و تستهای خوشتعریف است، CI/CD سنتی را انتخاب کنید. زمانی که نیاز به مدیریت مدلهای یادگیری ماشینی دارید که عملکرد آنها به کیفیت دادهها بستگی دارد، نیاز به ردیابی آزمایشها دارد و نیاز به نظارت مداوم برای رانش و تخریب دارد، خطوط لوله MLOps را انتخاب کنید.
این مقایسه به بررسی خدمات وب آمازون و گوگل کلود میپردازد و با تحلیل پیشنهادات خدماتی، مدلهای قیمتگذاری، زیرساخت جهانی، عملکرد، تجربه توسعهدهندگان و موارد استفاده ایدهآل، به سازمانها کمک میکند تا پلتفرم ابری را انتخاب کنند که بهترین تطابق را با نیازهای فنی و تجاری آنها داشته باشد.
محاسبات لبهای یادگیری ماشینی (ML) استنتاج را مستقیماً روی دستگاههای محلی اجرا میکند و تأخیر و استفاده از پهنای باند را کاهش میدهد، در حالی که آموزش یادگیری ماشینی مبتنی بر ابر، از سرورهای قدرتمند از راه دور برای ساخت و اصلاح مدلهای عظیم استفاده میکند. هر رویکرد متناسب با مراحل مختلف چرخه عمر یادگیری ماشینی و تقاضاهای عملیاتی مختلف است.
استراتژیهای ذخیرهسازی در سیستمهای یادگیری ماشین، خروجیهای مدل از پیش محاسبهشده یا دادههای میانی را برای تسریع پرسوجوهای مکرر ذخیره میکنند، در حالی که محاسبات بر اساس تقاضا، هر بار نتایج تازهای تولید میکنند و سرعت را فدای سادگی و سربار ذخیرهسازی کمتر میکنند.
اشکالزدایی سیستمهای توزیعشده، به بررسی خرابیها در چندین ماشین و سرویس شبکهای میپردازد، در حالی که اشکالزدایی سیستم محلی بر مشکلات درون یک ماشین یا برنامه واحد تمرکز دارد. هر رویکرد، ابزارها، مدلهای ذهنی و استراتژیهای متفاوتی را برای جداسازی و حل مؤثر مشکلات میطلبد.
برنامهریزی زیرساخت بلاکچین بر طراحی شبکههای غیرمتمرکز و توزیعشده با دفترکلهای تغییرناپذیر و سازوکارهای اجماع تمرکز دارد، در حالی که برنامهریزی زیرساخت ابری بر ساخت منابع محاسباتی مقیاسپذیر و بر اساس تقاضا از طریق ارائهدهندگان متمرکز مانند AWS، Azure و Google Cloud متمرکز است.
