آش شله قلمکار MLOps

یکی از موضوعات جدید و احتمالا جذاب برای اکثر توسعه دهنده ها به خصوص توسعه دهنده های هوش مصنوعی MLOps هست که داره کم کم سازمان هارو هم مجاب میکنه که حتما از نیرو هایی که این تخصص رو دارن استفاده کنن. البته اینکه چرا این موضوع جدید هست برمیگرده به اینکه خود هوش مصنوعی نهایتا سه دهه هست که جاش رو توی کسب و کار ها داره باز میکنه. اما MLOps چیه ؟‌ در واقع بهترین روش های (best practices)‌ پیاده سازی و رنوند های اجرایی برای توسعه ،‌ اجرا و نگهداری سرویس های هوش مصنوعی در یک کسب و کار رو میتونیم حدودا بگیم MLOps که بستر های خدمات ابری و سرویس های پردازش داده میتونن بیان کمکش.این کلمه حاصل اختصار کلمات machine learning operations هست البته اسمش ممکنه شمارو یاد یه هیولای پشمالوی سیاه یک چشم بندازه ولی در واقع عامل موفقیت و بازدهی هر چه بیشتر همه سرویس های هوش مصنوعی شما توی سازمانتون خواهد بود . چرا MLOps ؟ از سال ۲۰۱۲ بعد از ارائه یکی از محصولات image-recognition روی بستر deep learning انفجار هوش مصنوعی آغاز شد و همه شروع به استفاده از این تکنولوژی نوظهور توی بیزینس هاشون کردن. خب قبل از این همه فرایند هایی که توی سایت ها و سرویس های اینترنتی اجرا میشد یک فرایند مشخص برای توسعه و تست و پیاده سازی و پایداری داشت اما مدل کاری الگوریتم های هوش مصنوعی به خصوص شبکه های عصبی با ساختار قبل فرق داشتن . اما فرق های این الگوریتم ها چی هست ؟‌خروجی ممکنه به ازای هر ورودی متفاوت بشه.الگوریتم ها کلی مدل ریاضیاتی و گراف و احتمالات همراه خودشون دارن که به خودی خود فضای رم رو بیشتر از حالت معمول پر میکنه. اجرای این الگوریتم ها منابع زیادی از سیستم عامل و سخت افزار دریافت میکنه.فرایند های توسعه این محصولات خیلی زمان بر ترهمعمولا کند هستن و ارائه سریع جواب به کاربران دردسر های بسیار دارد.تست گرفتن از الگوریتم های هوش مصنوعی هزارتا شرط و شروط داره مانیتور کردن وقایع داخل الگوریتم به خصوص شبکه های عصبی خیلی وقت ها بسیار دشواره.خدانکنه یه چیزی توی الگوریتم کاربکنه ولی بد کار بکنه و ندونی مشکلش دقیقا کجاست!!! و... باید بگم متاسفانه MLOps یک سوپر هیرو نیست که بیاد همه این هارو حل بکنه ولی خب شاید یک شمشیر خیلی خوب باشه برای شما که سوپر هیرو هستید. جنگ های صلیبی سه قبیله (‌ data,back-end,network)‌قبلا بین بچه های شبکه و توسعه دهنده ها دعوا بود همیشه، به خاطر همین اومدن میانجی گری کردن و عنوان شغلی DevOps رو مطرح کردن و مشکلات رو حل کردن.اما وقتی هوش مصنوعی اومد توی مدار تکنولوژی ها یکم کار پیچیده شد و زخم های قدیمی دهن باز کردن که تیم هوش مصنوعی و بکند و شبکه رو چطوری بهم وصل کنیم ؟!!! اما چالش اینجا هم ختم نمیشه و همیشه در توسعه چیز هایی وجود دارند که ما فکرش رو نمیکردیم یا مجموعه داده هایی که از سمت کاربران به سمت ما میاد ممکنه پیشبینی نشده باشند پس مدل های هوش مصنوعی باید دایما بررسی بشن و عمکردشون ارزیابی بشه و باید یک روند بازطراحی ایجاد کنیم که بعد از هر آزمایش و بررسی دقت ، مدل جدید به بیزینس ارائه بشه و دوباره بریم سراغ خطایابی و بهبود. این کار رو اونقدر انجام میدیم که مشتری ها و مسئولین تست نرم افزار دیگه گزارشی از خرابی عملکرد به ما ندهند.نحوه تعامل با آدم فضایی ها یا data scientistها با توجه به زیرساختی که در دست فرد یا تیم MLOps سازمان هست فرایند های زیر باید برای دانشمندان داده پیاده سازی بشود. منابع و مخازن و مجموعه های داده باید برای اون ها ساخته بشه که بردارن و حالش رو ببرند!!! برای train و test و validation مدل ها باید فضای مناسبی طراحی کنند اگر در پس زمینه نیاز به اتصال منابع به هم از جمله نود های GPU و یا پخش کردن پردازش روی چندین CPU هست باید این کار را انجام دهند. باید ساختار به شکلی باشد که bottleneck ها به آن ها اعلام شود . مدل های هوش مصنوعی باید با توجه به ویژگی ها و نحوه کار و تاریخچه هاشون تگ بخورن و نگه داری بشن. سلامت مدل هایی که در لبه پاسخ دهی به کاربران هستند باید دایما چک بشود .یک پایپلاین خودکار برای مدیریت و نگهداری دیتاست ها ، مدل ها و همه تجربیات و دست آورد های تیم دانشمند داده باید طراحی شود . همه نرم افزار ها باید به صورت کانتینر شده قابل جابجایی ، خاموش و روشن شدن باشن همه کانتیر ها باید مدیریت بشوند (‌مثلا با Kubernetes ) باید این نکته را هم اضافه کنم که عزیزان data scientists نیاز به آزادی عمل برای کار با داده ها دارند یعنی باید بتوانند داده ها را از داخل و یا خارج از ساختار داخلی مورد بررسی قرار بدهند اما برچسب گذاری داده ها باید طبق استاندارد های داخلی سازمان باشد . به همین ترتیب این عزیزان نیاز به آزمایش و تکرار دارند تا مدل های خوب تولید کنند . خب حالا که مدل ها توسط data scientists های عزیز طراحی شد نیاز به یک همکاری با ML engineer های عزیزتر داریم که مجموعه داده ها و مدل ها رو از طریق نمونه داده های اولیه، آزمایش بکنند و مثلا اگر با شبکه عصبی سروکار داریم، دل و روده شبکه عصبی رو بکشن بیرون و مانیتورش کنن و ایراداتش رو در بیارن و بهینگی و دقتش رو افزایش بدن. این فرایند نیاز به اتوماسیون و توجه به جزئیات داره تا بتونیم مدل هارو به راحتی تفسیر کنیم و باز تولیدشون کنیم . جانمایی سرویس ها سرویس های هوش مصنوعی قالبا بخش عمده مزیت رقابتی اون میزینس با رقیبشون هستن و این یعنی باید توی ظرف طلا نگه داری بشن. همه ذهن ها با این حرف به سمت حملات سایبری میره اما باید گفت خیر. دغدغه اصلی در نوع طراحی معماری محصولات نرم افزاری هست که هر بیزینس باید متناسب با خودش اون رو درست بکنه . هدف انتخاب نوع دیتابیس یا زبان برنامه نویسی یا استفاده از کدام سرویس برای نمایش داده نیست . بلکه هدف جانمایی و درست چیدن این پازل بی پایان است . میشه قوانین زیادی وضع کرد که برای این کار به ما کمک میکنند که به چند نمونه از آن ها اشاره میکنیم . کانتینر سرویس ها باید از هم جدا باشند و با API با هم ارتباط بگیرند. هر شبکه عصبی یا هر الگوریتمی که بار زیادی دارد و منابع زیاد مصرف میکند در یک کانتینر جدا از دیگری قرار میگیرد حتی اگر پیشنیاز یکدیگر هستند باید نوع طراحی رو تغییر داد تا جدایی پذیر باشند . سرویس های مدیریت فرایند نباید درگیر جزئیات عملکرد الگوریتم ها بشوند . همه تخم مرغ ها نباید در یک سبد قرار بگیرند ،‌چه از نظر فیزیکی چه منطق معماری و پیاده سازی . ساختار backup گیری باید روتین و خودکار هم روی دیتابیس ها اعمال شود و هم روی الگوریتم هایی که ساختار آن ها در حال تغییر است . ( مثلا ساختار های unsupervised learning و reinforcement learning ) حاصل جست و جو های تکراری و کوئری های مشابه به صورت روزانه یا هفتگی (‌بسته به بیزینس) در یک انبار داده ذخیره شود . برای هر مدل هوش مصنوعی حاشیه خطا در نظر بگیرید یعنی بدست بیاورید در چه زمان ها یا شرایطی حدودا الگوریتم بد کار میکند و آن هارا زیر نظر بگیرید تا ایراد کار بدست بیاد . برای همه سرویس ها health check بنویسید تا در صورت بروز ایراد متوجه شوید . سخن پایانیتوسعه نرم افزار باید مهندسی شده باشد یعنی باید در یک چهارچوب و در یک فرایند قرار بگیرد و بتوان ورودی و خروجی مشخص کرد و اندازه گیری کرد . مهندس نرم افزار باید بتواند اندازه دقیقی از مصرف منابع ارائه دهد و با اعداد و نمودار صحبت کند . جزئیات در کار مهندسی بسیار مهم است . مهندس باشید نه لزوما یک برنامه نویس!از توجه و حوصله شما متشکرم .منبع https://blogs.nvidia.com/blog/2020/09/03/what-is-mlops/