این پست وبلاگ توسط Guillermo Ribeiro، Sr. Data Scientist در Cepsa نوشته شده است.
یادگیری ماشینی (ML) به سرعت از یک روند مد روز که از محیط‌های آکادمیک و بخش‌های نوآوری ظهور می‌کند، به ابزاری کلیدی برای ارائه ارزش در بین مشاغل در هر صنعتی تبدیل شده است. این انتقال از آزمایشات در آزمایشگاه ها به حل مسائل دنیای واقعی در محیط های تولیدی دست به دست می شود. MLO ها، یا انطباق DevOps با دنیای ML.
MLOps به ساده‌سازی و خودکارسازی چرخه عمر کامل یک مدل ML کمک می‌کند و تمرکز آن بر مجموعه داده‌های منبع، تکرارپذیری آزمایش، کد الگوریتم ML و کیفیت مدل است.
At سپساما، یک شرکت انرژی جهانی، از ML برای مقابله با مشکلات پیچیده در خطوط کسب و کارمان، از انجام تعمیرات پیش‌بینی‌کننده تجهیزات صنعتی گرفته تا نظارت و بهبود فرآیندهای پتروشیمی در پالایشگاه‌هایمان، استفاده می‌کنیم.
در این پست، نحوه ساخت معماری مرجع خود را برای MLOps با استفاده از خدمات کلیدی AWS زیر بحث می کنیم:
- آمازون SageMaker، سرویسی برای ساخت، آموزش و استقرار مدل های ML
- توابع مرحله AWS، یک سرویس گردش کار تصویری با کد پایین بدون سرور که برای هماهنگی و خودکارسازی فرآیندها استفاده می شود
- پل رویداد آمازون، یک اتوبوس رویداد بدون سرور
- AWS لامبدا، یک سرویس محاسباتی بدون سرور که به شما امکان می دهد کد را بدون تهیه یا مدیریت سرورها اجرا کنید
همچنین توضیح می‌دهیم که چگونه این معماری مرجع را برای راه‌اندازی پروژه‌های جدید ML در شرکت خود اعمال کردیم.
چالش
در طول 4 سال گذشته، چندین خط کسب و کار در سراسر Cepsa پروژه های ML را آغاز کردند، اما به زودی مسائل و محدودیت های خاصی شروع به ظهور کردند.
ما یک معماری مرجع برای ML نداشتیم، بنابراین هر پروژه مسیر پیاده‌سازی متفاوتی را دنبال می‌کرد و آموزش و استقرار مدل موقت را انجام می‌داد. بدون یک روش متداول برای مدیریت کد و پارامترهای پروژه و بدون رجیستری مدل ML یا سیستم نسخه‌سازی، ما قابلیت ردیابی را در میان مجموعه داده‌ها، کدها و مدل‌ها از دست دادیم.
ما همچنین فضایی را برای بهبود در نحوه عملکرد مدل‌ها در تولید تشخیص دادیم، زیرا مدل‌های مستقر را تحت نظر نداشتیم و بنابراین ابزاری برای ردیابی عملکرد مدل نداشتیم. در نتیجه، ما معمولاً مدل‌ها را بر اساس برنامه‌های زمانی بازآموزی می‌کردیم، زیرا معیارهای مناسبی برای تصمیم‌گیری آگاهانه برای بازآموزی نداشتیم.
راه حل
با شروع از چالش‌هایی که باید بر آن غلبه می‌کردیم، یک راه‌حل کلی طراحی کردیم که هدف آن جداسازی آماده‌سازی داده‌ها، آموزش مدل، استنتاج و نظارت بر مدل بود و یک رجیستری مدل متمرکز را ارائه می‌داد. به این ترتیب، ما مدیریت محیط ها را در چندین حساب AWS ساده کردیم، در حالی که قابلیت ردیابی مدل متمرکز را معرفی کردیم.
دانشمندان و توسعه دهندگان داده ما استفاده می کنند AWS Cloud9 (یک IDE ابری برای نوشتن، اجرا، و اشکال زدایی کد) برای بحث و جدل داده و آزمایش ML و GitHub به عنوان مخزن کد Git.
یک گردش کار آموزش خودکار از کد ساخته شده توسط تیم علم داده استفاده می کند مدل های قطار در SageMaker و برای ثبت مدل های خروجی در رجیستری مدل.
یک گردش کار متفاوت استقرار مدل را مدیریت می کند: مرجع را از رجیستری مدل به دست می آورد و با استفاده از یک نقطه پایانی استنتاج ایجاد می کند. ویژگی های میزبانی مدل SageMaker.
ما هر دو مدل آموزش و استقرار گردش کار را با استفاده از توابع Step اجرا کردیم، زیرا چارچوبی انعطاف‌پذیر ارائه می‌کند که امکان ایجاد گردش‌های کاری خاص را برای هر پروژه فراهم می‌کند و خدمات و اجزای مختلف AWS را به روشی ساده هماهنگ می‌کند.
مدل مصرف داده
در Cepsa، ما از مجموعه‌ای از دریاچه‌های داده برای پوشش نیازهای تجاری مختلف استفاده می‌کنیم، و همه این دریاچه‌های داده یک مدل مصرف داده مشترک دارند که پیدا کردن و مصرف داده‌های مورد نیاز را برای مهندسان داده و دانشمندان داده آسان‌تر می‌کند.
برای رسیدگی آسان به هزینه‌ها و مسئولیت‌ها، محیط‌های دریاچه داده کاملاً از برنامه‌های تولیدکننده و مصرف‌کننده داده جدا می‌شوند و در حساب‌های مختلف AWS متعلق به یک سازمان مشترک AWS مستقر می‌شوند.
داده های مورد استفاده برای آموزش مدل های ML و داده های مورد استفاده به عنوان ورودی استنتاج برای مدل های آموزش دیده از دریاچه های داده های مختلف از طریق مجموعه ای از API های تعریف شده با استفاده از دروازه API آمازون، سرویسی برای ایجاد، انتشار، نگهداری، نظارت و ایمن کردن APIها در مقیاس. باطن API استفاده می کند آمازون آتنا (یک سرویس پرس و جو تعاملی برای تجزیه و تحلیل داده ها با استفاده از SQL استاندارد) برای دسترسی به داده هایی که قبلاً در آنها ذخیره شده است سرویس ذخیره سازی ساده آمازون (Amazon S3) و فهرست شده در چسب AWS کاتالوگ داده ها
نمودار زیر یک نمای کلی از معماری MLOps Cepsa ارائه می دهد.
آموزش مدل
فرآیند آموزش برای هر مدل مستقل است و توسط a گردش کار استاندارد توابع مرحله، که به ما برای مدل‌سازی فرآیندها بر اساس نیازهای مختلف پروژه انعطاف‌پذیری می‌دهد. ما یک الگوی پایه تعریف شده داریم که در اکثر پروژه ها مجدداً از آن استفاده می کنیم و در صورت لزوم تنظیمات جزئی را انجام می دهیم. به عنوان مثال، برخی از صاحبان پروژه تصمیم به اضافه کردن گیت‌های دستی برای تأیید استقرار مدل‌های تولید جدید گرفته‌اند، در حالی که سایر صاحبان پروژه مکانیسم‌های تشخیص خطا و امتحان مجدد خود را پیاده‌سازی کرده‌اند.
ما همچنین تغییراتی را روی مجموعه داده های ورودی مورد استفاده برای آموزش مدل انجام می دهیم. برای این منظور از توابع لامبدا استفاده می کنیم که در گردش کار آموزشی ادغام شده اند. در برخی از سناریوها که نیاز به تبدیل داده های پیچیده تری است، کد خود را در آن اجرا می کنیم سرویس کانتینر الاستیک آمازون (Amazon ECS) روشن است AWS Fargate، یک موتور محاسباتی بدون سرور برای اجرای کانتینرها.
تیم علم داده ما اغلب از الگوریتم های سفارشی استفاده می کند، بنابراین ما از این توانایی استفاده می کنیم در آموزش مدل SageMaker از کانتینرهای سفارشی استفاده کنید، با تکیه بر رجیستری ظروف الاستیک آمازون (Amazon ECR)، یک رجیستری کانتینر کاملاً مدیریت شده که ذخیره، مدیریت، اشتراک گذاری و استقرار تصاویر کانتینر را آسان می کند.
اکثر پروژه های ML ما بر اساس کتابخانه Scikit-learn هستند، بنابراین ما استاندارد را گسترش داده ایم. محفظه Scikit-learn SageMaker شامل متغیرهای محیطی مورد نیاز برای پروژه، مانند اطلاعات مخزن Git و گزینه های استقرار.
با این رویکرد، دانشمندان داده ما فقط باید روی توسعه الگوریتم آموزشی تمرکز کنند و کتابخانه های مورد نیاز پروژه را مشخص کنند. وقتی تغییرات کد را به مخزن Git فشار می دهند، سیستم CI/CD ما (جنکینز میزبانی شده در AWS) کانتینر را با کد آموزشی و کتابخانه ها می سازد. این کانتینر به Amazon ECR فرستاده می شود و در نهایت به عنوان پارامتری به فراخوانی آموزشی SageMaker ارسال می شود.
هنگامی که فرآیند آموزش کامل شد، مدل به دست آمده در آمازون S3 ذخیره می شود، یک مرجع در رجیستری مدل اضافه می شود و تمام اطلاعات و معیارهای جمع آوری شده در کاتالوگ آزمایش ها ذخیره می شوند. این امر تکرارپذیری کامل را تضمین می کند زیرا کد الگوریتم و کتابخانه ها به مدل آموزش دیده همراه با داده های مرتبط با آزمایش مرتبط هستند.
نمودار زیر فرآیند آموزش و بازآموزی مدل را نشان می دهد.
استقرار مدل
معماری انعطاف پذیر است و امکان استقرار خودکار و دستی مدل های آموزش دیده را فراهم می کند. گردش کار مدل‌ساز به‌طور خودکار با استفاده از رویدادی که آموزش SageMaker پس از پایان آموزش در EventBridge منتشر می‌کند، فراخوانی می‌شود، اما در صورت نیاز می‌توان آن را به صورت دستی فراخوانی کرد و نسخه مدل مناسب را از رجیستری مدل ارسال کرد. برای اطلاعات بیشتر در مورد فراخوانی خودکار، رجوع کنید به خودکارسازی Amazon SageMaker با Amazon EventBridge.
گردش کار مدل Deployer اطلاعات مدل را از رجیستری مدل بازیابی می کند و از آن استفاده می کند AWS CloudFormation، یک زیرساخت مدیریت شده به عنوان سرویس کد، برای استقرار مدل در یک نقطه پایانی استنتاج بلادرنگ یا انجام استنتاج دسته ای با مجموعه داده ورودی ذخیره شده، بسته به نیاز پروژه.
هر زمان که یک مدل با موفقیت در هر محیطی مستقر شود، رجیستری مدل با یک برچسب جدید به روز می شود که نشان می دهد مدل در حال حاضر در کدام محیط ها اجرا می شود. هر زمان که یک نقطه پایانی حذف می شود، تگ آن نیز از رجیستری مدل حذف می شود.
نمودار زیر گردش کار برای استقرار مدل و استنتاج را نشان می دهد.
آزمایش ها و رجیستری مدل
ذخیره هر آزمایش و نسخه مدل در یک مکان واحد و داشتن یک مخزن کد متمرکز، ما را قادر می سازد آموزش و استقرار مدل را جدا کنیم و از حساب های AWS مختلف برای هر پروژه و محیطی استفاده کنیم.
همه ورودی‌های آزمایش شناسه تعهد کد آموزش و استنتاج را ذخیره می‌کنند، بنابراین ما قابلیت ردیابی کامل کل فرآیند آزمایش را داریم و می‌توانیم به راحتی آزمایش‌های مختلف را با هم مقایسه کنیم. این ما را از انجام کارهای تکراری در مرحله اکتشاف علمی برای الگوریتم‌ها و مدل‌ها باز می‌دارد، و ما را قادر می‌سازد که مدل‌های خود را در هر جایی، مستقل از حساب و محیطی که مدل در آن آموزش داده شده است، مستقر کنیم. این همچنین برای مدل‌هایی که در محیط آزمایشی AWS Cloud9 آموزش دیده‌اند نیز صادق است.
در مجموع، ما خطوط لوله آموزش و استقرار مدل کاملاً خودکار داریم و انعطاف‌پذیری برای اجرای سریع مدل‌های دستی در زمانی که چیزی به درستی کار نمی‌کند یا زمانی که یک تیم به مدلی برای اهداف آزمایشی در محیط دیگری مستقر شده نیاز دارد، داریم.
مورد استفاده دقیق: پروژه YET Dragon
هدف پروژه YET Dragon بهبود عملکرد تولید کارخانه پتروشیمی Cepsa در شانگهای است. برای دستیابی به این هدف، ما فرآیند تولید را به طور کامل مطالعه کردیم و به دنبال مراحل کم کارآمدتر بودیم. هدف ما افزایش کارایی بازده فرآیندها با نگه داشتن غلظت اجزا دقیقاً زیر یک آستانه بود.
برای شبیه‌سازی این فرآیند، ما چهار مدل افزایشی تعمیم‌یافته یا GAM، مدل‌های خطی که پاسخ آنها به توابع صاف متغیرهای پیش‌بینی‌کننده بستگی دارد، برای پیش‌بینی نتایج دو فرآیند اکسیداسیون، یک فرآیند غلظت، و بازده فوق‌الذکر ساختیم. ما همچنین یک بهینه ساز برای پردازش نتایج چهار مدل GAM و یافتن بهترین بهینه‌سازی‌هایی که می‌توان در کارخانه اعمال کرد، ساختیم.
اگرچه مدل‌های ما با داده‌های تاریخی آموزش داده شده‌اند، گاهی اوقات کارخانه می‌تواند تحت شرایطی کار کند که در مجموعه داده آموزشی ثبت نشده است. ما انتظار داریم که مدل‌های شبیه‌سازی ما تحت این سناریوها به خوبی کار نکنند، بنابراین ما همچنین دو مدل تشخیص ناهنجاری را با استفاده از الگوریتم‌های Isolation Forests ساختیم، که تعیین می‌کند نقاط داده تا بقیه داده‌ها چقدر فاصله دارند تا ناهنجاری‌ها را شناسایی کنند. این مدل‌ها به ما کمک می‌کنند چنین موقعیت‌هایی را شناسایی کنیم تا هر زمان که این اتفاق می‌افتد، فرآیندهای بهینه‌سازی خودکار را غیرفعال کنیم.
فرآیندهای شیمیایی صنعتی بسیار متغیر هستند و مدل‌های ML باید به خوبی با عملیات کارخانه هماهنگ شوند، بنابراین بازآموزی مکرر و همچنین قابلیت ردیابی مدل‌های مستقر در هر موقعیت مورد نیاز است. YET Dragon اولین پروژه بهینه‌سازی ML ما بود که دارای یک رجیستری مدل، تکرارپذیری کامل آزمایش‌ها و یک فرآیند آموزش خودکار کاملاً مدیریت شده بود.
اکنون، خط لوله کاملی که یک مدل را وارد تولید می‌کند (تبدیل داده، آموزش مدل، ردیابی آزمایش، ثبت مدل و استقرار مدل) برای هر مدل ML مستقل است. این ما را قادر می‌سازد تا مدل‌ها را به طور مکرر بهبود ببخشیم (مثلاً اضافه کردن متغیرهای جدید یا آزمایش الگوریتم‌های جدید) و مراحل آموزش و استقرار را به محرک‌های مختلف متصل کنیم.
نتایج و پیشرفت های آینده
ما در حال حاضر قادریم شش مدل ML مورد استفاده در پروژه YET Dragon را به طور خودکار آموزش، استقرار و ردیابی کنیم و در حال حاضر بیش از 30 نسخه را برای هر یک از مدل های تولیدی مستقر کرده ایم. این معماری MLOps به صدها مدل ML در پروژه های دیگر در سراسر شرکت گسترش یافته است.
ما قصد داریم به راه‌اندازی پروژه‌های جدید YET بر اساس این معماری ادامه دهیم، که به لطف کاهش زمان راه‌اندازی و اتوماسیون خطوط لوله ML، مدت زمان متوسط پروژه را 25 درصد کاهش داده است. ما همچنین به لطف افزایش بازده و تمرکز که نتیجه مستقیم پروژه YET Dragon است، صرفه جویی در حدود 300,000 یورو در سال تخمین زده ایم.
تکامل کوتاه مدت این معماری MLOps به سمت نظارت بر مدل و آزمایش خودکار است. ما قصد داریم قبل از استقرار یک مدل جدید، کارایی مدل را به طور خودکار در برابر مدل‌های مستقر شده قبلی آزمایش کنیم. ما همچنین در حال کار در اجرای مدل نظارت و نظارت بر رانش داده استنتاج با مانیتور مدل آمازون SageMaker، به منظور خودکارسازی بازآموزی مدل.
نتیجه
شرکت ها با چالش تولید پروژه های ML خود به شیوه ای خودکار و کارآمد روبرو هستند. خودکارسازی چرخه عمر کامل مدل ML به کاهش زمان پروژه کمک می‌کند و کیفیت بهتر مدل و استقرار سریع‌تر و مکرر در تولید را تضمین می‌کند.
با توسعه یک معماری استاندارد MLOps که توسط مشاغل مختلف در سراسر شرکت پذیرفته شده است، ما در Cepsa توانستیم راه‌اندازی پروژه ML را سرعت بخشیم و کیفیت مدل ML را بهبود بخشیم، چارچوبی قابل اعتماد و خودکار ارائه کنیم که تیم‌های علم داده ما بتوانند سریع‌تر نوآوری کنند. .
برای اطلاعات بیشتر در مورد MLOps در SageMaker، مراجعه کنید Amazon SageMaker برای MLOps و سایر موارد استفاده مشتری را در وبلاگ یادگیری ماشین AWS.
درباره نویسندگان
گیرمو ریبیرو خیمنز دانشمند داده Sr در Cepsa با مدرک دکترا است. در فیزیک هسته ای او دارای 6 سال تجربه در پروژه های علم داده، عمدتا در صنعت مخابرات و انرژی است. او در حال حاضر رهبری تیم‌های دانشمند داده در بخش تحول دیجیتال Cepsa را با تمرکز بر مقیاس‌بندی و تولید پروژه‌های یادگیری ماشین بر عهده دارد.
گیرمو منندز کورال یک معمار راه حل در AWS Energy and Utilities است. او بیش از 15 سال تجربه در طراحی و ساخت برنامه های کاربردی SW دارد و در حال حاضر با تمرکز بر تجزیه و تحلیل و یادگیری ماشین، راهنمایی های معماری را به مشتریان AWS در صنعت انرژی ارائه می دهد.
