یادگیری ماشین صنعتی: 10 اصل طراحی

یادگیری ماشین صنعتی: 10 اصل طراحی

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

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

در این مقاله، من به طور خلاصه 10 اصل را در مورد نحوه برنامه ریزی یادگیری ماشین صنعتی به گونه ای که بتوان به راحتی در یک برنامه کاربردی/سرویس ادغام کرد، بر اساس متدولوژی 12-عاملی App توضیح داد. پیشنهاد شده توسط تیم Heroku. ابتکار من افزایش آگاهی از این تکنیک است که می تواند به بسیاری از توسعه دهندگان و افراد علم داده کمک کند.

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

اصل 1: پایه یک کد

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

این اصل می گوید: یک پایگاه کد و تعداد زیادی استقرار دارند.

Git می تواند هم در تولید و هم در تحقیق و توسعه (R&D) استفاده شود که در آن اغلب استفاده نمی شود.

به عنوان مثال، در مرحله تحقیق و توسعه، می‌توانید با روش‌ها و مدل‌های مختلف پردازش داده، تعهدات را ترک کنید تا سپس بهترین را انتخاب کنید و به راحتی کار با آن را ادامه دهید.

ثانیاً، در تولید این یک چیز غیرقابل جایگزین است - شما باید دائماً به چگونگی تغییر کد خود نگاه کنید و بدانید کدام مدل بهترین نتایج را ایجاد کرده است، کدام کد در پایان کار کرد و چه اتفاقی افتاد که باعث توقف کار یا شروع به تولید نتایج نادرست شد. . این چیزی است که commit ها برای آن هستند!

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

اصل 2: ​​وابستگی ها را به وضوح اعلام و جدا کنید

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

• وابستگی ها را به وضوح اعلام کنید، یعنی فایلی که شامل تمام کتابخانه ها، ابزارها و نسخه های آنهاست که در پروژه شما استفاده می شود و باید نصب شود (مثلاً در پایتون این کار را می توان با استفاده از Pipfile یا requirement.txt انجام داد. پیوندی که به خوبی اجازه می دهد تا بفهمد: realpython.com/pipenv-guide)
• در طول توسعه، وابستگی ها را به طور خاص برای برنامه خود جدا کنید. نمی خواهید دائماً نسخه ها را تغییر دهید و مثلاً Tensorflow را دوباره نصب کنید؟

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

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

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

برای مثال، request.txt شما ممکن است به شکل زیر باشد:

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

اصل 3: تنظیمات

بسیاری داستان‌هایی را شنیده‌اند که افراد توسعه‌دهنده مختلف به‌طور تصادفی کد را با گذرواژه‌ها و کلیدهای دیگر از AWS در مخازن عمومی در GitHub آپلود کردند و روز بعد با بدهی 6000 دلار یا حتی 50000 دلار از خواب بیدار شدند.

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

یک جایگزین برای این، ذخیره تنظیمات در متغیرهای محیطی است. می توانید در مورد متغیرهای محیطی بیشتر بخوانید اینجا.

نمونه هایی از داده هایی که معمولاً در متغیرهای محیطی ذخیره می شوند:

• نام های دامنه
• URL ها/URI های API
• کلیدهای عمومی و خصوصی
• مخاطبین (پست، تلفن و غیره)

به این ترتیب، در صورت تغییر متغیرهای پیکربندی، نیازی به تغییر مداوم کد ندارید. این به صرفه جویی در زمان، تلاش و هزینه شما کمک می کند.

به عنوان مثال، اگر از Kaggle API برای انجام آزمایش‌ها استفاده می‌کنید (برای مثال، نرم‌افزار را دانلود کنید و مدل را از طریق آن اجرا کنید تا در هنگام اجرا آزمایش کنید که مدل به خوبی کار می‌کند)، کلیدهای خصوصی Kaggle، مانند KAGGLE_USERNAME و KAGGLE_KEY، باید باشند. در متغیرهای محیطی ذخیره می شود.

اصل 4: خدمات شخص ثالث

ایده در اینجا این است که برنامه را به گونه ای ایجاد کنیم که هیچ تفاوتی بین منابع محلی و شخص ثالث از نظر کد وجود نداشته باشد. برای مثال، می‌توانید MySQL محلی و شخص ثالث را به هم متصل کنید. همین امر در مورد API های مختلف مانند Google Maps یا Twitter API نیز صدق می کند.

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

بنابراین، به‌عنوان مثال، به‌جای اینکه هر بار مسیر فایل‌های دارای مجموعه داده‌ها را در داخل کد مشخص کنید، بهتر است از کتابخانه pathlib استفاده کنید و مسیر مجموعه داده‌ها را در config.py اعلام کنید، به طوری که مهم نیست از چه سرویسی استفاده می‌کنید (برای به عنوان مثال، CircleCI)، برنامه توانست با در نظر گرفتن ساختار سیستم فایل جدید در سرویس جدید، مسیر مجموعه داده ها را پیدا کند.

اصل 5. ساخت، انتشار، زمان اجرا

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

1. صحنه مجامع. شما کد لخت خود را با منابع فردی به یک بسته به اصطلاح تبدیل می کنید که حاوی تمام کدها و داده های لازم است. این بسته اسمبلی نام دارد.
2. صحنه رها کردن - در اینجا ما پیکربندی خود را به اسمبلی متصل می کنیم که بدون آن نمی توانیم برنامه خود را آزاد کنیم. اکنون این نسخه کاملاً آماده راه اندازی است.
3. بعد صحنه می آید تحقق. در اینجا ما برنامه را با اجرای فرآیندهای لازم از زمان انتشار خود آزاد می کنیم.

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

برای وظیفه انتشار، سرویس‌های مختلفی ایجاد شده‌اند که در آن‌ها می‌توانید فرآیندهایی را بنویسید تا خودتان در یک فایل .yml اجرا کنید (به عنوان مثال، در CircleCI این config.yml است تا از خود فرآیند پشتیبانی کند). Wheely در ایجاد بسته هایی برای پروژه ها عالی است.

می توانید بسته هایی را با نسخه های مختلف مدل یادگیری ماشین خود ایجاد کنید و سپس آنها را بسته بندی کنید و به بسته های لازم و نسخه های آنها مراجعه کنید تا از توابعی که از آنجا نوشته اید استفاده کنید. این به شما کمک می کند یک API برای مدل خود ایجاد کنید و بسته شما می تواند به عنوان مثال در Gemfury میزبانی شود.

اصل 6. مدل خود را به صورت یک یا چند فرآیند اجرا کنید

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

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

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

برای اجرای مدل به صورت چندین پردازش، می توانید یک فایل .yml ایجاد کنید که در آن فرآیندهای لازم و ترتیب آنها را مشخص کنید.

اصل 7: قابلیت بازیافت

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

یعنی فرآیند شما با مدل باید:

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

اصل 8: استقرار/ادغام مداوم

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

بنابراین، این اصل بیان می کند که محیط توسعه شما باید تا حد امکان به محیط تولید شما نزدیک باشد.

این اجازه خواهد داد:

1. زمان انتشار را ده ها برابر کاهش دهید
2. تعداد خطاهای ناشی از ناسازگاری کد را کاهش دهید.
3. این همچنین باعث کاهش حجم کار کارکنان می شود، زیرا توسعه دهندگان و افرادی که برنامه را به کار می گیرند اکنون یک تیم هستند.

ابزارهایی که به شما امکان می دهند با آن کار کنید CircleCI، Travis CI، GitLab CI و دیگران هستند.

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

تفاوت ها را به حداقل برسانید!!!

اصل 9. سیاهههای مربوط به شما

گزارش‌ها (یا «Logs») رویدادهایی هستند که معمولاً در قالب متن ضبط می‌شوند و در برنامه (جریان رویداد) رخ می‌دهند. یک مثال ساده: "2020-02-02 - سطح سیستم - نام فرآیند." آنها به گونه ای طراحی شده اند که توسعه دهنده می تواند به معنای واقعی کلمه ببیند که هنگام اجرای برنامه چه اتفاقی می افتد. او پیشرفت فرآیندها را می بیند و می فهمد که آیا آن چیزی است که خود توسعه دهنده در نظر داشته است یا خیر.

این اصل بیان می کند که شما نباید لاگ های خود را در سیستم فایل خود ذخیره کنید - فقط باید آنها را به صفحه "خروجی" کنید، به عنوان مثال، این کار را در خروجی استاندارد سیستم انجام دهید. و به این ترتیب امکان نظارت بر جریان در ترمینال در حین توسعه وجود خواهد داشت.

یعنی اصلا نیازی به ذخیره لاگ نیست؟ البته که نه. برنامه شما نباید این کار را انجام دهد - آن را به خدمات شخص ثالث بسپارید. برنامه شما فقط می‌تواند گزارش‌ها را به یک فایل یا ترمینال خاص برای مشاهده هم‌زمان ارسال کند یا آن را به یک سیستم ذخیره‌سازی داده‌های عمومی (مانند Hadoop) ارسال کند. خود برنامه شما نباید لاگ ها را ذخیره کند یا با آنها تعامل داشته باشد.

اصل 10. تست کنید!

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

تست‌ها را می‌توان با استفاده از pytest ایجاد کرد، و اگر یک کار رگرسیون/طبقه‌بندی دارید، با استفاده از یک مجموعه داده کوچک آزمایش می‌شود.

فراموش نکنید که برای مدل‌های یادگیری عمیق یک دانه تنظیم کنید تا دائماً نتایج متفاوتی تولید نکنند.

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

من همچنین سعی خواهم کرد از اصول جالبی استفاده کنم که هر کسی در صورت تمایل می تواند در نظرات بگذارد.

منبع: www.habr.com