ساخت یک خط لوله MLOps سرتاسر برای بازرسی کیفیت بصری در لبه - قسمت 1 | خدمات وب آمازون

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

پیاده‌سازی خط لوله MLOps در لبه پیچیدگی‌های بیشتری را معرفی می‌کند که فرآیندهای اتوماسیون، یکپارچه‌سازی و تعمیر و نگهداری را به دلیل افزایش سربار عملیاتی چالش‌برانگیزتر می‌کند. با این حال، استفاده از خدمات هدفمند مانند آمازون SageMaker و AWS IoT Greengrass به شما اجازه می دهد تا این تلاش را به میزان قابل توجهی کاهش دهید. در این مجموعه، ما شما را از طریق فرآیند معماری و ساخت یک خط لوله MLOps یکپارچه برای یک مورد استفاده از بینایی کامپیوتر در لبه با استفاده از SageMaker، AWS IoT Greengrass و کیت توسعه ابری AWS (AWS CDK).

این پست بر روی طراحی کلی معماری خط لوله MLOps تمرکز دارد. قسمت 2 و قسمت 3 تمرکز این سری بر روی اجرای اجزای فردی است. ما یک نمونه پیاده سازی را در همراه ارائه کرده ایم مخزن GitHub تا خودت را امتحان کنی اگر به تازگی با MLOps در لبه AWS شروع کرده اید، به آن مراجعه کنید MLO در لبه با Amazon SageMaker Edge Manager و AWS IoT Greengrass برای یک نمای کلی و معماری مرجع.

مورد استفاده: بازرسی کیفیت برچسب های فلزی

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

تعریف معماری خط لوله

ما اکنون در مورد استفاده خود و مشکل خاص ML که می‌خواهیم به آن بپردازیم، که حول تشخیص شی در لبه می‌چرخد، وضوح پیدا کرده‌ایم. اکنون زمان آن است که یک معماری برای خط لوله MLOps خود پیش نویس کنیم. در این مرحله، ما هنوز به فناوری یا خدمات خاص نگاه نمی کنیم، بلکه به اجزای سطح بالای خط لوله خود نگاه می کنیم. به منظور بازآموزی و استقرار سریع، ما باید کل فرآیند پایان به انتها را خودکار کنیم: از برچسب‌گذاری داده‌ها، آموزش و استنتاج. با این حال، چند چالش وجود دارد که راه‌اندازی خط لوله برای یک لبه را به‌ویژه سخت می‌کند:

• ساخت بخش‌های مختلف این فرآیند به مجموعه‌های مهارتی متفاوتی نیاز دارد. به عنوان مثال، برچسب‌گذاری و آموزش داده‌ها دارای تمرکز قوی بر علم داده است، استقرار لبه به متخصص اینترنت اشیا (IoT) نیاز دارد و خودکارسازی کل فرآیند معمولاً توسط فردی با مجموعه مهارت‌های DevOps انجام می‌شود.
• بسته به سازمان شما، کل این فرآیند حتی ممکن است توسط چندین تیم اجرا شود. برای موارد استفاده ما، ما با این فرض کار می کنیم که تیم های جداگانه مسئول برچسب زدن، آموزش و استقرار هستند.
• نقش‌ها و مجموعه مهارت‌های بیشتر به معنای نیازهای متفاوتی است که به ابزار و فرآیندها می‌رسد. به عنوان مثال، دانشمندان داده ممکن است بخواهند محیط نوت بوک آشنای خود را نظارت کرده و با آن کار کنند. مهندسان MLOps می‌خواهند با استفاده از زیرساخت به عنوان ابزار کد (IaC) کار کنند و ممکن است بیشتر با آن آشنا باشند کنسول مدیریت AWS.

این برای معماری خطوط لوله ما چه معنایی دارد؟

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

بیایید معماری کلی خط لوله MLOps را با جزئیات بررسی کنیم:

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

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

معماری هدف

اکنون که معماری سطح بالا ایجاد شده است، زمان آن رسیده است که یک سطح عمیق تر برویم و ببینیم چگونه می توانیم این را با خدمات AWS بسازیم. توجه داشته باشید که معماری نشان داده شده در این پست فرض می کند که شما می خواهید کنترل کامل کل فرآیند علم داده را در دست بگیرید. با این حال، اگر به تازگی با بازرسی کیفیت در لبه شروع کرده اید، توصیه می کنیم Amazon Lookout for Vision. این روشی را برای آموزش مدل بازرسی کیفیت خود بدون نیاز به ساخت، نگهداری یا درک کد ML ارائه می دهد. برای اطلاعات بیشتر مراجعه کنید Amazon Lookout for Vision اکنون از بازرسی بصری نقص های محصول در لبه پشتیبانی می کند.

با این حال، اگر می خواهید کنترل کامل را در دست بگیرید، نمودار زیر نشان می دهد که یک معماری چگونه می تواند باشد.

مانند قبل، بیایید گام به گام روند کار را طی کنیم و شناسایی کنیم که کدام خدمات AWS با نیازهای ما مطابقت دارد:

1. سرویس ذخیره سازی ساده آمازون (Amazon S3) برای ذخیره داده های تصویر خام استفاده می شود زیرا راه حل ذخیره سازی کم هزینه ای را در اختیار ما قرار می دهد.
2. گردش کار برچسب‌گذاری با استفاده از آن تنظیم می‌شود توابع مرحله AWS، یک موتور گردش کار بدون سرور که هماهنگ کردن مراحل گردش کار برچسب زدن را آسان می کند. به عنوان بخشی از این گردش کار، ما استفاده می کنیم Amazon SageMaker Ground Truth برای خودکارسازی کامل برچسب‌گذاری با استفاده از مشاغل برچسب‌زنی و نیروی انسانی مدیریت شده. AWS لامبدا برای آماده‌سازی داده‌ها، شروع کارهای برچسب‌گذاری و ذخیره برچسب‌ها در آن استفاده می‌شود فروشگاه ویژگی آمازون SageMaker.
3. فروشگاه ویژگی SageMaker برچسب ها را ذخیره می کند. این به ما امکان می‌دهد ویژگی‌های خود را به‌طور مرکزی مدیریت و به اشتراک بگذاریم و قابلیت‌های نسخه‌سازی داده‌های داخلی را در اختیار ما قرار می‌دهد، که خط لوله ما را قوی‌تر می‌کند.
4. ما با استفاده از خط لوله ساخت و آموزش مدل را هماهنگ می کنیم خطوط لوله آمازون SageMaker. با سایر ویژگی های SageMaker مورد نیاز از طریق مراحل داخلی ادغام می شود. مشاغل آموزشی SageMaker برای خودکارسازی آموزش مدل استفاده می شود و مشاغل پردازش SageMaker برای تهیه داده ها و ارزیابی عملکرد مدل استفاده می شود. در این مثال، ما از Ultralytics YOLOv8 بسته پایتون و معماری مدل برای آموزش و صادرات یک مدل تشخیص شی به ONNX فرمت مدل ML برای قابلیت حمل.
5. اگر عملکرد قابل قبول باشد، مدل آموزش دیده در آن ثبت می شود رجیستری مدل آمازون SageMaker با یک شماره نسخه افزایشی پیوست شده است. این به عنوان رابط ما بین مراحل آموزش مدل و استقرار لبه عمل می کند. ما همچنین وضعیت تایید مدل ها را در اینجا مدیریت می کنیم. مشابه سایر سرویس‌های مورد استفاده، کاملاً مدیریت می‌شود، بنابراین ما مجبور نیستیم از زیرساخت‌های خود مراقبت کنیم.
6. گردش کار استقرار لبه با استفاده از توابع مرحله ای، مشابه گردش کار برچسب زدن، خودکار می شود. ما می‌توانیم از ادغام‌های API توابع Step استفاده کنیم تا به راحتی APIهای مختلف خدمات AWS مورد نیاز مانند AWS IoT Greengrass را فراخوانی کنیم تا اجزای مدل جدید ایجاد کنیم و سپس اجزا را در دستگاه لبه مستقر کنیم.
7. AWS IoT Greengrass به عنوان محیط زمان اجرا دستگاه لبه استفاده می شود. چرخه عمر استقرار مدل و اجزای استنتاج ما را در لبه مدیریت می کند. این به ما اجازه می دهد تا به راحتی نسخه های جدید مدل و اجزای استنتاج خود را با استفاده از فراخوانی های ساده API مستقر کنیم. علاوه بر این، مدل‌های ML در لبه معمولاً به صورت مجزا اجرا نمی‌شوند. ما می توانیم از انواع مختلف استفاده کنیم AWS و انجمن اجزای AWS IoT Greengrass را برای اتصال به سایر خدمات ارائه می کند.

معماری مشخص شده شبیه معماری سطح بالای ما است که قبلا نشان داده شده بود. Amazon S3، SageMaker Feature Store و SageMaker Model Registry به عنوان رابط بین خطوط لوله مختلف عمل می کنند. برای به حداقل رساندن تلاش برای اجرا و اجرای راه حل، از خدمات مدیریت شده و بدون سرور تا جایی که ممکن است استفاده می کنیم.

ادغام در یک سیستم قوی CI/CD

برچسب گذاری داده ها، آموزش مدل، و مراحل استقرار لبه هسته اصلی راه حل ما هستند. به این ترتیب، هرگونه تغییر مربوط به کد یا داده های اساسی در هر یک از آن بخش ها باید اجرای جدیدی از کل فرآیند ارکستراسیون را آغاز کند. برای دستیابی به این هدف، ما باید این خط لوله را در یک سیستم CI/CD ادغام کنیم که به ما اجازه می‌دهد تا به طور خودکار تغییرات کد و زیرساخت را از یک مخزن کد نسخه‌سازی شده به تولید مستقر کنیم. مشابه معماری قبلی، استقلال تیم یک جنبه مهم در اینجا است. نمودار زیر نشان می دهد که با استفاده از سرویس های AWS چه شکلی می تواند باشد.

بیایید معماری CI/CD را مرور کنیم:

1. AWS CodeCommit به عنوان مخزن Git ما عمل می کند. برای سادگی، در نمونه ارائه شده ما، بخش‌های متمایز (برچسب‌گذاری، آموزش مدل، استقرار لبه) را از طریق پوشه‌های فرعی در یک مخزن git جدا کردیم. در یک سناریوی واقعی، هر تیم ممکن است از مخازن مختلفی برای هر قسمت استفاده کند.
2. استقرار زیرساخت با استفاده از AWS CDK خودکار می‌شود و هر بخش (برچسب‌گذاری، آموزش و لبه) برنامه AWS CDK خود را دارد تا امکان استقرار مستقل را فراهم کند.
3. از ویژگی خط لوله AWS CDK استفاده می کند AWS CodePipeline برای خودکارسازی زیرساخت و استقرار کد.
4. AWS CDK دو خط لوله کد را برای هر مرحله مستقر می کند: یک خط لوله دارایی و یک خط لوله جریان کار. ما گردش کار را از استقرار دارایی جدا کردیم تا در صورت عدم تغییر دارایی (به عنوان مثال، زمانی که تصاویر جدیدی برای آموزش در دسترس هستند) به ما اجازه دهیم گردش کار را به طور جداگانه شروع کنیم.
   • خط لوله کد دارایی تمام زیرساخت های مورد نیاز برای اجرای موفقیت آمیز گردش کار را به کار می گیرد، مانند هویت AWS و مدیریت دسترسی نقش‌های (IAM)، توابع لامبدا، و تصاویر ظرف مورد استفاده در طول تمرین.
   • خط لوله کد گردش کار، جریان کاری برچسب‌گذاری، آموزش یا استقرار لبه را اجرا می‌کند.
5. خطوط لوله دارایی به طور خودکار در هنگام commit و همچنین هنگامی که خط لوله گردش کار قبلی کامل می شود، راه اندازی می شوند.
6. کل فرآیند بر اساس یک برنامه زمانی با استفاده از یک راه اندازی می شود پل رویداد آمازون قانون برای بازآموزی منظم

با ادغام CI/CD، کل زنجیره انتها به انتها اکنون کاملاً خودکار است. خط لوله هر زمان که کد در مخزن git ما تغییر می کند و همچنین در یک برنامه زمانی برای تطبیق با تغییرات داده ها، فعال می شود.

فکر کردن به آینده

معماری راه حل توضیح داده شده مؤلفه های اساسی برای ایجاد یک خط لوله MLOps سرتاسر در لبه را نشان می دهد. با این حال، بسته به نیاز خود، ممکن است در مورد اضافه کردن قابلیت های اضافی فکر کنید. در زیر چند نمونه آورده شده است:

نتیجه

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

In قسمت 2 از این سری، ما یک سطح عمیق تر کاوش خواهیم کرد و به اجرای این معماری با جزئیات بیشتر، به ویژه برچسب زدن و ساخت مدل نگاه خواهیم کرد. اگر می‌خواهید مستقیماً به کد بروید، می‌توانید کد همراه را بررسی کنید GitHub repo.

---

درباره نویسندگان

مایکل راث یک معمار ارشد راه حل در AWS است که از مشتریان تولید در آلمان برای حل چالش های تجاری آنها از طریق فناوری AWS پشتیبانی می کند. او علاوه بر کار و خانواده به ماشین های اسپرت علاقه مند است و از قهوه ایتالیایی لذت می برد.

یورگ وورله یک معمار راه حل در AWS است که با مشتریان تولیدی در آلمان کار می کند. جورج با علاقه به اتوماسیون به عنوان توسعه‌دهنده نرم‌افزار، مهندس DevOps و مهندس قابلیت اطمینان سایت در زندگی قبل از AWS کار کرده است. فراتر از ابر، او یک دونده جاه طلب است و از اوقات با کیفیتی با خانواده اش لذت می برد. بنابراین اگر چالش DevOps دارید یا می خواهید برای اجرا بروید: به او اطلاع دهید.

یوهانس لانگر یک معمار ارشد راه حل در AWS است که با مشتریان سازمانی در آلمان کار می کند. یوهانس علاقه زیادی به استفاده از یادگیری ماشینی برای حل مشکلات واقعی کسب و کار دارد. یوهانس در زندگی شخصی خود از کار در پروژه های بهبود خانه و گذراندن وقت در خارج از منزل با خانواده خود لذت می برد.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/