Filter by دسته‌ها
chatGTP
ابزارهای هوش مصنوعی
اخبار
گزارش
تیتر یک
چندرسانه ای
آموزش علوم داده
اینفوگرافیک
پادکست
ویدیو
دانش روز
آموزش‌های پایه‌ای هوش مصنوعی
اصول هوش مصنوعی
یادگیری بدون نظارت
یادگیری تقویتی
یادگیری عمیق
یادگیری نیمه نظارتی
آموزش‌های پیشرفته هوش مصنوعی
بینایی ماشین
پردازش زبان طبیعی
پردازش گفتار
چالش‌های عملیاتی
داده کاوی و بیگ دیتا
رایانش ابری و HPC
سیستم‌‌های امبدد
علوم شناختی
دیتاست
رویدادها
جیتکس
کاربردهای هوش مصنوعی
کتابخانه
اشخاص
شرکت‌های هوش مصنوعی
محصولات و مدل‌های هوش مصنوعی
مفاهیم
کسب‌و‌کار
تحلیل بازارهای هوش مصنوعی
کارآفرینی
هوش مصنوعی در ایران
هوش مصنوعی در جهان
مقاله
 چرا یادگیری ماشین به کابوس تبدیل شده؟

چرا یادگیری ماشین به کابوس تبدیل شده؟

زمان مطالعه: 5 دقیقه

فرض کنید یکی از مهندسان یادگیری ماشین شرکت آمازون هستید. تیمتان به تازگی یک مدل قیمت‌گذاری (RNN) Recurrent Neural Network جدید منتشر کرده تا فرایند قیمت‌گذاری بر اساس نوع خرید افراد، به صورت خودکار انجام شود. شما و همکاران‌تان زحمات زیادی کشیده و بارها این مدل را آزمایش کرده‌اید. حالا تلاش دو ساله شما به بار نشسته و پیش‌بینی می‌شود سالیانه یک میلیون دلار سودآوری داشته باشد. این موفقیت، تا حدی شما را به وجد آورده که می‌خواهید تعطیلات را در مکانی مجلل و گران‎قیمت جشن بگیرید. اما در راه سفر به باهاماس، خبر بدی دریافت می‌کنید. مدل یادگیری ماشین‌تان دچار سوءعملکرد شده و قیمت‌گذاری کالاها را اشتباه انجام داده است. هر کاری از دست‌تان برمی‌آید انجام می‌دهید تا مشکل را حل کنید، اما خیلی دیر شده و سیستم کالاها را تحویل داده است. مدل یادگیری ماشین شما، به شرکت 3 میلیون دلار ضرر زده است.روز بعد، با تمام قوا تصمیم به رفع مشکل می‌گیرید و مجدداً مدل را آزمایش می‌کنید. به نظر نمی‌رسد مشکل خاصی وجود داشته باشد. آیا توزیع قیمت تغییر یافته؟ آیا فرایند آماده‌سازی داده دچار مشکل شده؟ کیفیت داده پایین آمده؟ از تمام توان ذهن‌تان بهره می‌گیرید تا علت مشکلات را پیدا کنید، اما به هیچ سرنخی نمی‌رسید. بنابراین، تصمیم می‌گیرید جریان سرازیری داده‌ها از هر ماشین‌های مجازی را و فایل‌های مختلف config تفکیک کرده، مدل را از نو بسازید و آزمایش‌ها را یک به یک انجام دهید. در فرایند انجام این کارها، یادتان می‌رود نسخه‌ها را به‌روزرسانی کنید و سرانجام، پس از چند شب بی‌خوابی مشکلات را حل می‌کنید.

به هزینه تصمیمات مصلحت‌آمیز، بدهی فنی Technical debt گفته می‌شود که در مدت اجرای کُد گرفته می‌شوند. دلیل این تصمیم، متوسل شدن به مسیرهای میانبری است که می‌تواند در انتشار اولیه نرم‌افزارها و بازاریابی سریع، سود کوتاه‌مدت به همراه داشته باشد. «وارد کانینگهام» در سال 1992 این اصطلاح را ابداع کرد تا نیاز سهامدار به ریفکتور (refactor) را توضیح دهد. این اصطلاح در صنعت توسعه نرم‌افزار به کار برده می‌شود و به این معناست که توسعه‌دهنده به جای صرف زمان زیاد و یافتن بهترین راه حل در طول فرایند کدنویسی، از راه‌حل فوری و آسانی به منظور حل موقت یک مسئله استفاده ‌کند؛ در عوض متعهد می‌شود زمانی را در آینده برای یافتن راه‌حل اساسی و کاربردی اختصاص دهد.
به‌طور مشابه، در هوش مصنوعی و یادگیری ماشین نیز به افزایش بدهی فنی تمایل داریم و برای حل مسائل، استفاده از مسیرهای میانبر و کوتاه را در دستور کار خود قرار می‌دهیم. اگر برای کارمان ضرب‌الاجل فوری تعیین کرده‌ باشند، به‌کارگیری این نوع راه‌حل‌ها را امری مناسب و ضروری می‌دانیم. اما گاهی این اقدامات هزینه‌های سنگینی به بار می‌آورد. لزوماً همه بدهی‌ها به ضرر ما تمام نمی‌شوند، اما بدهی‌های پرداخت‌نشده می‌توانند بار سنگینی روی دوش‌مان بگذارند.

سیستم یادگیری ماشین ناپایداریادگیری ماشین ناپایدار

سیستم قیمت‌گذاری را تصور کنید که از سیستم «مدیریت رابطه مشتری» یا «CRM» برای پیاده‌سازی استراتژی قیمت‌گذاری استفاده می‌کند. کیفیت این سیستم قیمت‌گذاری تا حد زیادی به داده‌هایی بستگی دارد که از سیستم CRM به دست می‌آیند. بنابراین، نادیده گرفتن ویژگی‌ها می‌تواند تمامی نتایج را در یادگیری ماشین دچار اختلال کند. حالا فرض کنید این سیستم با ویژگی‌های بسیار زیادی سروکار دارد. در این شرایط، مدل یادگیری ماشین شما در بهترین حالت شکننده و ناپایدار عمل خواهد کرد و در بدترین حالت نیز انتظار می‌رود جریان سرازیری داده با مشکل جدی روبه‌رو شود.
این مسئله در شرکت‌های نوپای هوش مصنوعی به یک هنجار تبدیل شده، چرا که آن‌ها سرعت‌عمل بالایی برای آماده‌سازی محصولات و ارائه به سهام‌داران خود نشان می‌دهند. یکی از همکاران ما در یک شرکت نوپای هوش مصنوعی اعلام کرد که هیچ‌گاه از ابزارهای مدیریت «Dec Ops»، مشکل‌یاب (Jira) و «Git» برای توسعه سیستم‌های یادگیری ماشین خود استفاده نکرده‌اند. این مسئله برای ما خیلی شگفت‌آور بود، چرا که بسیاری از شرکت‌های دیگر نیز بدون مدیریت مناسب بدهی فنی و ابزارهای «Dec Ops» وارد حوزه یادگیری ماشین و هوش مصنوعی می‌شوند. «Dec Ops» در مهندسی نرم‌افزار اهمیت فراوانی دارد، اما «MLOPs» برای ابزارهای یادگیری ماشین جدایی‌ناپذیر است.

چهار مشکل بزرگ در یادگیری ماشینیادگیری ماشینی

1. درهم‌تنیدگی Entanglement

سیستم‌های یادگیری ماشین (ML) به ماشین‌هایی گفته می‌شود که با داده سروکار دارند. فرض کنید مدل قیمت‌گذاریِ شما عملکرد بسیار خوبی در قیمت‌گذاری همۀ محصولات داشته باشد، به جز جاروبرقی و شما با افزایش حساسیت قیمت‌گذاری وسایلِ مخصوص تمیزکاری، جاروبرقی را قیمت‌گذاری کرده‌اید. بعد متوجه می‌شوید این قیمت‌گذاری با قیمت ماشین ظرفشویی همخوانی ندارد. شیوه توزیع قیمت دستگاه‌های جاروبرقی قابل کاربرد در توزیع قیمت دستگاه شستشوی ظرف نیست. حالا باید قانون جدیدی وضع کنید که شاید سایر کالاها و محصولات را تحت‌تاثیر قرار دهد. شما به درهم‌تنیدگیِ داده‌ها و درون‌بینی پی می‌برید.

2. خطوط لوله پیچیده Complex Pipelines

سیستم‌های هوش مصنوعی و یادگیری ماشین از خطوط لوله گردشکار بسیار متفاوتی تشکیل شده‌اند که مسئول انجام کارهای پیچیده‌ای هستند. سیستم یادگیر شما بوسیله تعدا زیادی مهندس ساخته خواهند شد و این سیستم‌ها با منابع داده‌ای و تعداد زیادی از سیستم‌های دیگر پیوند دارند.
باید کارهای زیادی را در خطوط لوله مناسبِ یادگیری ماشین طراحی کرد. از جمله این کارها می‌توان به تولید داده، ETL، تصدیق داده‌ها، نظارت بر عملکرد و… اشاره کرد. مدلِ شما به زودی به سطح بالایی از پیچیدگی می‌رسد که نداشتن عملیات استاندارد و ابزارهای مناسب باعث می‌شود برای اِعمال تغییرات ساده در سیستم‌های مختلف، به چندین ساعت زمان نیاز داشته باشید. پس خطوط لوله پیچیده باعث کُند شدن فعالیت‌های مهندسیِ شما می‌شود که اگر از شیوه برخورد با این وضعیت درک خوبی نداشته باشید، باید برای اِعمال تغییرات ساده، چندین ساعت زمان صرف کنید.

3. حلقه‌های بازخورد پنهان

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

4. وابستگی شکننده به داده

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

پرداخت بدهی‌های فنی یادگیری ماشینبدهی‌های فنی یادگیری ماشینی

بدهی فنی دردسرهای زیادی دارد. هنگامی که به عنوان مهندس داده در «Visa» و گوگل مشغول به کار بودم، می‌بایست از وجود یک خط لوله قابل‌اطمینان استفاده می‌کردم که از شفافیت بالایی برخوردار باشد. پس به نوعی عملیات استاندارد نیاز داشتم تا جنبه‌های فنی و داده‌ایِ یادگیری ماشین را پوشش دهد. در ضمن، می‌بایست از عدم کاهش کیفیت در طی زمان اطمینان حاصل می‌کردم. سه راهکار برای کاهش بدهی فنی «MLOps» وجود دارد که در زیر اشاره خواهیم کرد:

1. کدها و داده‌ها را آزمایش کنید.
آزمایش کردن یکی از مهم‌ترین و ناخوشایندترین کارها در بخش فن‌آوری است. هدف از این کار، محدودسازی و کاهش بدهی فنی و اطمینان حاصل کردن از کیفیت تولید یادگیری ماشین است. ما در «DevOps» دو نوع آزمایش را یاد گرفتیم: آزمایش واحد (یعنی آزمایش کردن یک کارکرد) و آزمایش یکپارچگی (یعنی آزمایش کردن کارکردهای یکپارچه). با این حال، در «MLOps» نیاز به راه‌اندازی فرایند canary داریم تا کیفیت خط لوله یادگیری ماشین را آزمایش کنیم.

2. آموزش، آزمایش و سازگاری مقادیر.
وقتی مشغول آموزشِ مدل‌هایتان هستید، از داده‌های log استفاده می‌کنید. با این حال، در فرایند تولید باید با داده‌های زنده سروکار داشته باشید که شاید بنا به مسائل زیادی از قبیل سری زمانی، کیفیت دوربین (عکس)، زبان و… به مقادیر متفاوتی دست پیدا کنید. بنابراین، همواره باید حواس‌تان به هر دو نوع داده مذکور باشد تا کیفیت تضمین شود.

3. به صورت محافظه‌کارانه امتیاز دهید.
باید به هر مرحله از آزمایش مدل یادگیری ماشین خود امتیاز دهید. امتیازهای سلامت خط لوله را در چهار بخش مختلف به کار ببرید:

  • زیرساخت یادگیری ماشین: باید کیفیت جریان داده‌های پایین‌رو و بالارو آزمایش شود.
  • توسعه مدل یادگیری ماشین: باید از طریق آزمایش مطمئن شویم که مدل حاوی ویژگی‌های نامناسب نیست.
  • ویژگی‌ها و نمونه‌گیری: باید از طریق آزمایش مطمئن شویم که توزیع ویژگی‌ها با انتظارات‌مان همخوانی دارد.
  • اجرای سیستم‌های یادگیری ماشین: باید کیفیت کد‌ها و داده‌ها را بسنجیم. کلیه این مراحل برای تضمین کارآییِ مدل اهمیت زیادی دارند.

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

میانگین امتیاز / 5. تعداد ارا :

مطالب پیشنهادی مرتبط

اشتراک در
اطلاع از
0 نظرات
بازخورد (Feedback) های اینلاین
مشاهده همه دیدگاه ها
[wpforms id="48325"]