نوشته های mahdi sharifloo

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

mahdi sharifloo — Thu, 21 Jul 2022 16:31:55 +0430

یکی از موضوعات جدید و احتمالا جذاب برای اکثر توسعه دهنده ها به خصوص توسعه دهنده های هوش مصنوعی 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/

تصمیم‌گیری به شرط چاقو

mahdi sharifloo — Sat, 12 Oct 2019 11:55:21 +0330

توی هر در یه هزینه ای هست و یه جایزه اگر اولین انتخاب جایزه خوبی داشته باشه و هزینه کم ، آیا دوباره یک در دیگه رو باز میکنید؟ برعکسش چطور؟ماه ها بود یکی از مشکلاتم رو هر روز میدیدم که توانایی تصمیم قطعی گرفتنم به شدت جای کار داره و توش ضعیفم.اول پذیرفتم مسئله اصلی خودمم و رفتم پیش اقا مجید. باورم نمیشد با چندتا سوال مجید منوچهری بتونم یه الگوریتم واسه حل کردن خودم پیدا کنموقتی مشکل رو پیدا کردم ازم پرسید اسمش رو چی میزارم منم گفتم:( انتخاب ...)با عمیقتر نگاه کردن فهمیدم موضوع فقط <انتخاب> نیست و به مشکل ریشه ای تری بر خوردم به اسم (تصمیم گیری ) بیاید یه نگاهی به تصمیم گیری بندازیم.ادم ها وقتی دو موضوع ارزشی جلوشونه که یکی رو باید انتخاب کنن معمولا دچار خطاهای زیادی میشن که احتمالا شنیدید:نقد رو ول کنم نسیه رو بچسبم ? نکن!!!ممکن بعدا فرصت بهتری گیرت بیاد...از اونجایی که عادت دارم همیشه منطق انسانی رو با منطق ماشین ها مقایسه کنم و یه مدل ازش بیرون بکشم، اگر نگاهی به تصمیم‌گیری ماشینی بیاندازیم معمولا ماشین ها باید کم هزینه ترین و با ارزش ترین گزینه رو انتخاب کنن (مسئله کوله پشتی). اما تو فرایند های انسانی ابعاد مسئله اونقدر زیاده که گاهی اوقات تصمیماتت به حماقت یا به زرنگی ختم میشه که یا از تو یه ننگ میسازه یا باعث افتخارت میشه.حالا بیایم مفهوم زمان رو هم به آشِ شَلَمْشولبامون اضافه کنیم. وقتی فرصتمون کمه و باید زود تصمیم بگیریم عمدتا خراب میکنیم یا کاملا تصادفی انتخاب میکنیم .یه سریا به حس هاشون احترام میزارن و با هر تصمیمی که حس میکنن بهتره میرن جلویه سریا عقل رو ارزشی میدونن و به تصمیماتش اعتماد میکنن اما تصمیمگیری معمولا باید ترکیبی از هر دو باشه که البته اگر واحد زمان وجود نداشت همه چیز قابل حل بود پس تو واحد زمان باید یه سری ثابت هایی هم اضافه کنیم تا بتونیم بهتر به فرمول تصمیم گیری اعتماد کنیم .اون ثابت ها تجربیات دیگرانه که قبلا تصمیم مشابهی رو گرفتن و نتیجه دیدن. اما اینجا یه خطر هم وجود داره چون ممکنه شروع کنیم به پرسیدن و نظر خواستن و استقلالمون رو تو تصمیمگیری فدای نظرات دیگران کنیم یا برای اثبات خودمون به دیگران، تصمیم بگیریم نه به خاطر خودمون. دوباره بیاید قضیه رو ماشینی نگاه کنیم. تو ماشین ها اشتباهات قابل توجیه هستن چون طبق الگوریتم، ماشین بهترین انتخاب رو داشته، هرچند اشتباه بوده. اما بین ادما به تعداد انسان ها الگوریتم انتخاب وجود داره ینی ممکنه دوتا ادم تو یک شرایط مشخص دوتا تصمیم جدا بگیرن یا حتی جالب تر اینکه هردو یک تصمیم رو به دلایل مختلف بگیرن پس لزوما نمیشه تصمیمی رو محکوم کرد یا تشویق کرد؛ به قول آقا مجید : ( انتخاب همیشه ارزشمنده و لایق تحسین).تقریبا هر روز درگیر این تصمیمگیری هستیم هرچند یه برهه هایی از زمان خیلی جدی و استراتژیکه و یه جاهایی در حد اینکه امشب شام املت بخورم یا تخم مرغ. حالا بیاید به مدل الگوریتمی که من باهاش خودمو حل میکنم نگاه کنیم: پاک کردن پیشفرض ها و بایاس ها خودت رو در مقابل خودت بزار و از بیرون به خودت نگاه کنتا زمانی که به نتیجه رضایت بخشی نرسیدی از خودت بپرس(حلقه) :۱- چی باعث میشه نتونی تصمیم قطعی بگیری؟ ۲- چرا چنین مشکلی داری ?۳- چطور میتونی حلش بکنی؟۴- چقدر حاضری برای هر تصمیم هزینه بدی؟۵- هزینه هر تصمیم چقدره ؟۶- پاداش هر تصمیم چقدره ؟۷- به نظرت انتخاب بهینه تری میتونی ایجاد کنی؟۸- آدم هایی که قبلا شرایط مشابهت رو داشتن چه تصمیم گرفتن و چه نتیجه ای دیدن؟۹- با توجه به مسئله، سوالی که فکر میکنی باید پرسیده بشه رو اضافه کنبا توجه به مهم بودن هر پرسش یه وزن بهشون بده #((مثلا اگر هزینه حل مشکل برات خیلی مهمه به پرسش هزینه وزن بیشتری بده یا مثلا اگر انجام دادن اون تصمیم خیلی سخته وزن سوال <چطور میتونی حلش کنی؟> رو زیاد کن.))فرض کن بین دو انتخاب موندی و سکه میندازی. بدون نگاه کردن به نتیجه از خودت بپرس دوست داری شیر اومده باشه یا خط؟ در نهایت کافیه که خروجی این الگوریتم رو کنار هم بزارید و ببینید که همه کار هایی که کردید فقط یه بازی الکی بوده :)شما قبل از این که این همه فرایند رو طی کنید تصمیمتون رو گرفته بودید فقط یه دلیل برای پذیرفتنش میخواستید که اون هم میتونید لا به لای نتیجه ها پیدا کنید.موفق باشید : )