پس از صحبت با مهندسین یادگیری ماشین و زیرساخت در شرکت‌های بزرگ اینترنتی در سراسر ایالات متحده، اروپا و چین، متوجه دو گروه از شرکت‌ها شدم. یک گروه سرمایه گذاری قابل توجهی (صدها میلیون دلار) در زیرساخت انجام داده است تا امکان یادگیری ماشین در زمان واقعی را فراهم کند و قبلاً بازده سرمایه گذاری خود را دیده است. گروهی دیگر هنوز در تعجب هستند که آیا ML بلادرنگ ارزشی دارد یا خیر.
به نظر می رسد در مورد معنای واقعی ML اتفاق نظر کمی وجود دارد، و بحث عمیق زیادی در مورد نحوه انجام آن در صنعت وجود ندارد. در این پست، می‌خواهم آنچه را که پس از صحبت با ده‌ها شرکتی که این کار را انجام می‌دهند، آموخته‌ام به اشتراک بگذارم.
دو سطح یادگیری ماشین بلادرنگ یا Real time وجود دارد که در این پست به آنها می پردازم.
سطح 1: سیستم ML شما پیش بینی ها را در زمان واقعی انجام می دهد (پیش بینی های آنلاین).
سطح 2: سیستم شما می تواند داده های جدید را ترکیب کند و مدل شما را در زمان واقعی به روز کند (یادگیری مستمر).
من از «مدل» برای اشاره به مدل یادگیری ماشین و «سیستم» برای اشاره به زیرساخت اطراف آن، از جمله خط لوله داده و سیستم‌های نظارت استفاده می‌کنم.
سطح 1: پیش بینی های آنلاین - سیستم شما می تواند پیش بینی ها را در زمان واقعی انجام دهد
زمان واقعی در اینجا به ترتیب میلی ثانیه تا ثانیه تعریف شده است.
Use case
برای برنامه های کاربردی تأخیر اهمیت دارد. در سال 2009، آزمایش‌های گوگل نشان داد که افزایش تأخیر جستجوی وب 100 تا 400 میلی‌ثانیه، تعداد جستجوهای روزانه به ازای هر کاربر را 0.2 درصد به 0.6 درصد کاهش می‌دهد. در سال 2019، Booking.com دریافت که افزایش 30 درصدی تأخیر حدود 0.5 درصد در نرخ تبدیل هزینه دارد - «هزینه ای مرتبط برای کسب و کار ما».
مهم نیست که مدل‌های ML شما چقدر عالی هستند، اگر پیش‌بینی‌ها فقط میلی‌ثانیه طول بکشد، کاربران روی چیز دیگری کلیک می‌کنند.
مشکلات پیش بینی دسته ای
یکی از راه حل ها اجتناب از انجام پیش بینی های آنلاین است. می‌توانید پیش‌بینی‌ها را به صورت دسته‌ای آفلاین ایجاد کنید، آنها را ذخیره کنید (مثلاً در جداول SQL)، و در صورت نیاز پیش‌بینی‌های از پیش محاسبه‌شده را بیرون بکشید.
این می تواند زمانی کار کند که فضای ورودی محدود باشد - شما دقیقاً می دانید که برای چند ورودی ممکن پیش بینی کنید. یک مثال زمانی است که باید برای کاربران خود توصیه هایی برای فیلم ایجاد کنید - دقیقاً می دانید تعداد کاربران چقدر است. بنابراین شما مجموعه ای از توصیه ها را برای هر کاربر به صورت دوره ای، مانند هر چند ساعت یکبار، پیش بینی می کنید.
بسیاری از برنامه‌ها برای محدود کردن فضای ورودی کاربر خود، کاربران خود را مجبور می‌کنند به جای وارد کردن پرس و جوهای وحشی، از بین دسته‌ها انتخاب کنند. به عنوان مثال، اگر به تریپ ادوایزر بروید، به جای اینکه بتوانید وارد هر مکانی شوید، ابتدا باید یک منطقه شهری از پیش تعریف شده را انتخاب کنید.
این رویکرد محدودیت های زیادی دارد. نتایج تریپ‌ادوایزر در دسته‌های از پیش تعریف‌شده‌شان، مانند «رستوران‌ها» در «سان‌فرانسیسکو» خوب است، اما وقتی سعی می‌کنید سؤالات عجیبی مانند «رستوران‌های تایلندی با رتبه بالا در دره هایس» را وارد کنید، بسیار بد هستند.
محدودیت‌های ناشی از پیش‌بینی‌های دسته‌ای حتی در شرکت‌های پیشرفته‌تر از نظر فناوری مانند نتفلیکس وجود دارد. بگویید، اخیراً فیلم‌های ترسناک زیادی تماشا کرده‌اید، بنابراین وقتی برای اولین بار وارد نتفلیکس می‌شوید، فیلم‌های ترسناک بر توصیه‌ها غالب می‌شوند. اما امروز احساس خوبی دارید، بنابراین «کمدی» را جستجو می‌کنید و شروع به مرور دسته‌بندی کمدی می‌کنید. نتفلیکس باید کمدی های بیشتری را در لیست توصیه های خود به شما نشان دهد، درست است؟ اما تا دفعه بعدی که توصیه‌های دسته‌ای ایجاد نشود، نمی‌تواند فهرست را به‌روزرسانی کند.
در دو مثال بالا، پیش‌بینی‌های دسته‌ای منجر به کاهش تجربه کاربر (که به شدت با تعامل/حفظ کاربر همراه است)، و نه شکست‌های فاجعه‌بار منجر می‌شود. نمونه‌های دیگر عبارتند از رتبه‌بندی تبلیغات، رتبه‌بندی هشتگ پرطرفدار توییتر، رتبه‌بندی اخبار فیسبوک، تخمین زمان ورود و غیره.
همچنین برنامه های بسیاری وجود دارند که بدون پیش بینی های آنلاین، منجر به شکست های فاجعه آمیز می شوند یا فقط کار نمی کنند. به عنوان مثال می توان به تجارت با فرکانس بالا، وسایل نقلیه خودران، دستیارهای صوتی، باز کردن قفل تلفن با استفاده از صورت/اثرانگشت، تشخیص سقوط برای مراقبت از سالمندان، تشخیص تقلب و غیره اشاره کرد. شناسایی یک تراکنش تقلبی که 3 ساعت پیش اتفاق افتاده است هنوز بهتر از عدم شناسایی آن است. به هیچ وجه، اما توانایی تشخیص آن در زمان واقعی می تواند از بروز آن جلوگیری کند.
تغییر از پیش‌بینی‌های دسته‌ای به پیش‌بینی‌های زمان واقعی به شما امکان می‌دهد از ویژگی‌های پویا برای پیش‌بینی‌های مرتبط‌تر استفاده کنید. ویژگی‌های استاتیک اطلاعاتی هستند که به آرامی یا به ندرت تغییر می‌کنند - سن، جنسیت، شغل، محله، و غیره. ویژگی‌های پویا ویژگی‌هایی هستند که بر اساس آنچه در حال حاضر اتفاق می‌افتد - آنچه در حال تماشای آن هستید، چیزی که دوست داشته‌اید، و غیره. دانستن علایق کاربر در حال حاضر به سیستم‌های شما اجازه می‌دهد تا توصیه‌هایی بسیار مرتبط‌تر با آنها ارائه کنند.
راه حل ها
برای اینکه سیستم شما بتواند به صورت آنلاین پیش بینی کند، باید دو جزء داشته باشد:
استنتاج سریع: مدلی که می تواند پیش بینی هایی به ترتیب میلی ثانیه انجام دهد
خط لوله بلادرنگ: خط لوله ای که می تواند داده ها را پردازش کند، آن را در مدل وارد کند و پیش بینی را در زمان واقعی برگرداند.
استنتاج (inference )سریع
هنگامی که یک مدل خیلی بزرگ است و برای پیش‌بینی خیلی طول می‌کشد، سه رویکرد وجود دارد:
1. مدل‌ها را سریعتر کنید (بهینه‌سازی استنتاج)
به عنوان مثال. عملیات ادغام، توزیع محاسبات، بهینه سازی ردپای حافظه، نوشتن هسته های با کارایی بالا با هدف قرار دادن سخت افزارهای خاص و غیره.
2. مدل ها را کوچکتر کنید (فشرده سازی مدل)
در اصل، این خانواده از تکنیک‌ها، کوچکتر کردن مدل‌ها برای جا دادن آنها بر روی دستگاه‌های لبه است. کوچکتر کردن مدل‌ها اغلب باعث می‌شود آنها سریعتر کار کنند. رایج‌ترین و عمومی‌ترین تکنیک برای فشرده‌سازی مدل، کوانتیزاسیون است، به عنوان مثال. استفاده از شناورهای 16 بیتی (نیم دقت) یا اعداد صحیح 8 بیتی (نقطه ثابت) به جای شناورهای 32 بیتی (دقت کامل) برای نمایش وزن مدل شما. در حالت شدید، برخی از نمایش 1 بیتی (شبکه های عصبی وزن دودویی)، به عنوان مثال، تلاش کرده اند. BinaryConnect و Xnor-Net. نویسندگان Xnor-Net از Xnor.ai، استارت‌آپ متمرکز بر فشرده‌سازی مدل که توسط اپل به قیمت 200 میلیون دلار خریداری شده بود، منصرف شدند.
یکی دیگر از تکنیک های محبوب تقطیر دانش () است - یک مدل کوچک (دانشجو) برای تقلید از یک مدل بزرگتر یا مجموعه ای از مدل ها (معلم) آموزش می بیند. حتی اگر دانش آموز اغلب با یک معلم از پیش آموزش دیده آموزش می بیند، ممکن است هر دو نیز همزمان آموزش ببینند. یکی از نمونه‌های شبکه مقطری (distilled network) که در تولید استفاده می‌شود DistilBERT است که اندازه مدل BERT را تا 40 درصد کاهش می‌دهد در حالی که 97 درصد از قابلیت‌های درک زبان خود را حفظ می‌کند و 60 درصد سریعتر است.
تکنیک‌های دیگر عبارتند از هرس (پیدا کردن پارامترهایی که کمترین فایده را برای پیش‌بینی‌ها دارند و آنها را روی 0 قرار می‌دهیم) و فاکتورسازی با رتبه پایین (تعویض فیلترهای پیچشی بیش از حد پارامتریک با بلوک‌های فشرده برای کاهش تعداد پارامترها و افزایش سرعت). برای تجزیه و تحلیل دقیق به بررسی فشرده سازی و شتاب مدل برای شبکه های عصبی عمیق (چنگ و همکاران 2017) مراجعه کنید.
تعداد مقالات تحقیقاتی در مورد فشرده سازی مدل در حال افزایش است. تاسیسات خارج از قفسه در حال گسترش هستند. Awesome Open Source فهرستی از 121 مدل برتر پروژه متن باز فشرده سازی دارد.
3. سخت افزار را سریعتر بسازید
این یکی دیگر از حوزه های تحقیقاتی است که در حال رونق است. شرکت‌های بزرگ و استارت‌آپ‌ها به طور یکسان در حال رقابت برای توسعه سخت‌افزاری هستند که به مدل‌های ML بزرگ اجازه می‌دهد استنباط، حتی آموزش را سریعتر هم در فضای ابری و به‌ویژه در دستگاه‌ها انجام دهند. IDC پیش‌بینی می‌کند که تا سال 2020، ترکیب دستگاه‌های لبه و تلفن همراه که استنتاج انجام می‌دهند، در مجموع به 3.7 میلیارد واحد خواهد رسید و 116 میلیون واحد دیگر نیز آموزش را انجام می‌دهند.
خط لوله بلادرنگ
فرض کنید یک برنامه اشتراک گذاری سواری دارید و می خواهید تراکنش های تقلبی را شناسایی کنید. پرداخت با استفاده از کارت های اعتباری سرقت شده وقتی صاحب اعتبار واقعی پرداخت‌های غیرمجاز را کشف می‌کند، با بانک خود اختلاف پیدا می‌کند و شما باید هزینه‌ها را بازپرداخت کنید. برای به حداکثر رساندن سود، کلاهبرداران ممکن است چندین سواری را پشت سر هم یا از چندین حساب فراخوانی کنند. در سال 2019، تاجران تخمین می زنند که تراکنش های تقلبی به طور متوسط 27 درصد از فروش آنلاین سالانه آنها را تشکیل می دهد. هرچه شناسایی کارت اعتباری دزدیده شده بیشتر طول بکشد، پول بیشتری از دست خواهید داد.
برای تشخیص تقلبی بودن یک تراکنش، بررسی آن تراکنش به تنهایی کافی نیست. شما باید حداقل به تاریخچه اخیر کاربر درگیر در آن تراکنش، سفرها و فعالیت‌های اخیر درون برنامه‌ای، تراکنش‌های اخیر کارت اعتباری و سایر تراکنش‌هایی که در همان زمان اتفاق می‌افتند، نگاهی بیندازید.
برای دسترسی سریع به این نوع اطلاعات، می‌خواهید تا حد امکان آنها را در حافظه نگه دارید. هر بار که رویدادی که برای شما مهم است رخ می‌دهد - کاربر مکانی را انتخاب می‌کند، سفری را رزرو می‌کند، با راننده تماس می‌گیرد، سفر را لغو می‌کند، کارت اعتباری اضافه می‌کند، کارت اعتباری را حذف می‌کند و غیره - اطلاعات مربوط به آن رویداد به حافظه شما می‌رود. ذخیره سازی. تا زمانی که مفید هستند (معمولاً به ترتیب روز) در آنجا می ماند و سپس یا به ذخیره سازی دائمی می رود (مثلاً S3) یا دور انداخته می شود. رایج ترین ابزار برای این کار آپاچی کافکا با جایگزین هایی مانند Amazon Kinesis است. کافکا یک ذخیره‌سازی جریان است: داده‌ها را همانطور که جریان می‌یابد ذخیره می‌کند.
داده‌های جریانی با داده‌های ثابت متفاوت است - داده‌هایی که قبلاً در جایی به طور کامل وجود دارند، مانند فایل‌های CSV. هنگام خواندن از فایل‌های CSV، می‌دانید که کار چه زمانی تمام شده است. جریان داده هرگز تمام نمی شود.
هنگامی که راهی برای مدیریت داده های جریان یافتید، می خواهید ویژگی هایی را برای ورودی مدل های ML خود استخراج کنید. علاوه بر ویژگی‌های داده‌های جریانی، ممکن است به ویژگی‌هایی از داده‌های استاتیک نیز نیاز داشته باشید (این حساب چه زمانی ایجاد شده است، رتبه‌بندی کاربر چیست و غیره). شما به ابزاری نیاز دارید که به شما امکان می دهد داده های جریانی و همچنین داده های استاتیک را پردازش کرده و آنها را از منابع داده های مختلف به یکدیگر بپیوندید.
پردازش جریانی در مقابل پردازش دسته ای
مردم معمولاً از "پردازش دسته ای" برای اشاره به پردازش داده های ایستا استفاده می کنند زیرا می توانید آنها را به صورت دسته ای پردازش کنید. این با «پردازش جریانی» که هر رویداد را هنگام ورود پردازش می‌کند، مخالف است. پردازش دسته ای کارآمد است - می توانید از ابزارهایی مانند MapReduce برای پردازش مقادیر زیادی داده استفاده کنید. پردازش جریانی سریع است زیرا می‌توانید هر قطعه داده را به محض رسیدن پردازش کنید. رابرت متزگر، یکی از اعضای PMC در Apache Flink، مخالفت کرد که پردازش جریان می‌تواند به اندازه پردازش دسته‌ای کارآمد باشد، زیرا دسته‌ای یک مورد خاص از جریان است.
پردازش داده‌های جریانی دشوارتر است زیرا حجم داده‌ها نامحدود است و داده‌ها با نرخ‌ها و سرعت‌های متغیر وارد می‌شوند. وادار کردن یک پردازنده جریانی برای پردازش دسته ای آسان تر از انجام پردازشگر دسته ای است.
آپاچی کافکا مقداری ظرفیت برای پردازش جریانی دارد و برخی از شرکت ها از این ظرفیت در بالای ذخیره سازی جریان کافکا خود استفاده می کنند، اما پردازش جریان کافکا در توانایی خود برای مقابله با منابع داده های مختلف محدود است. تلاش هایی برای گسترش SQL، زبان پرس و جوی محبوبی که برای جداول داده های ایستا در نظر گرفته شده است، برای مدیریت جریان های داده انجام شده است [1، 2]. با این حال، محبوب ترین ابزار برای پردازش جریان، Apache Flink با پشتیبانی بومی برای پردازش دسته ای است.
در روزهای اولیه تولید یادگیری ماشینی، بسیاری از شرکت‌ها سیستم‌های ML خود را بر روی خط لوله داده MapReduce/Spark/Hadoop موجود ساختند. وقتی این شرکت‌ها می‌خواهند استنتاج بلادرنگ انجام دهند، باید خط لوله جداگانه‌ای برای جریان داده ایجاد کنند.
داشتن دو خط لوله مختلف برای پردازش داده‌های شما یکی از دلایل رایج ایجاد اشکال در تولید ML است، به عنوان مثال. تغییرات در یک خط لوله به درستی در خط لوله دیگر تکرار نمی شود و منجر به استخراج دو مجموعه از ویژگی های مختلف توسط دو خط لوله می شود. این امر به ویژه در صورتی رایج است که دو خط لوله توسط دو تیم مختلف نگهداری شوند، به عنوان مثال. تیم توسعه خط لوله دسته ای را برای آموزش حفظ می کند در حالی که تیم استقرار خط لوله جریان را برای استنباط حفظ می کند. شرکت هایی از جمله Uber و Weibo تعمیرات اساسی زیرساخت ها را انجام داده اند تا خطوط لوله پردازش دسته ای و جریانی خود را با Flink یکسان کنند.
رویداد محور در مقابل درخواست محور
دنیای نرم افزار در دهه گذشته به سمت میکروسرویس ها رفته است. ایده این است که منطق کسب و کار خود را به اجزای کوچک تقسیم کنید - هر جزء یک سرویس مستقل است - که می تواند به طور مستقل نگهداری شود. صاحب هر مؤلفه می تواند بدون نیاز به مشورت با بقیه سیستم، آن مؤلفه را به سرعت به روز کرده و آزمایش کند.
میکروسرویس‌ها اغلب با REST، مجموعه‌ای از روش‌ها که به این میکروسرویس‌ها امکان برقراری ارتباط را می‌دهد، دست به دست می‌شوند. REST APIهای درخواست محور هستند. یک سرویس گیرنده (سرویس) درخواست هایی را ارسال می کند تا به سرور خود از طریق روش هایی مانند POST و GET دقیقاً بگوید چه کاری انجام دهد و سرور آن با نتایج پاسخ می دهد. یک سرور باید به درخواست برای ثبت نام گوش دهد.
از آنجایی که در دنیای درخواست محور، داده ها از طریق درخواست ها به سرویس های مختلف مدیریت می شوند، هیچ کس دید کلی از نحوه جریان داده ها در کل سیستم ندارد. یک سیستم ساده با 3 سرویس را در نظر بگیرید:
A در دسترس بودن درایورها را مدیریت می کند
B تقاضای سواری را مدیریت می کند
C بهترین قیمت ممکن را پیش بینی می کند تا هر بار که مشتریان درخواست سواری می کنند نشان دهد
از آنجایی که قیمت ها به در دسترس بودن و تقاضا بستگی دارد، خروجی سرویس C به خروجی های سرویس A و B بستگی دارد. اول، این سیستم به ارتباطات بین سرویسی نیاز دارد: C برای پیش بینی ها باید پینگ A و B را انجام دهد، A باید پینگ B را انجام دهد تا بداند آیا رانندگان بیشتری را بسیج کنید و پینگ C کنید تا بدانید چه انگیزه ای به آنها بدهید. دوم، هیچ راه آسانی برای نظارت بر اینکه چگونه تغییرات در منطق A یا B بر عملکرد سرویس C تأثیر می‌گذارد، یا ترسیم جریان داده برای اشکال‌زدایی در صورت کاهش ناگهانی عملکرد سرویس C وجود ندارد.
با تنها 3 سرویس، همه چیز در حال پیچیده شدن است. تصور کنید که صدها، اگر نه هزاران سرویس مانند آنچه شرکت های بزرگ اینترنتی دارند، داشته باشید. ارتباطات بین سرویسی منفجر می شود. ارسال داده‌ها به‌صورت حباب‌های JSON از طریق HTTP - روشی که معمولاً درخواست‌های REST انجام می‌شود - نیز کند است. انتقال داده بین سرویس می تواند به یک گلوگاه تبدیل شود و کل سیستم را کند کند.
به جای داشتن 20 سرویس پینگ سرویس A برای داده، چه می شود اگر هر زمان که رویدادی در سرویس A رخ می دهد، این رویداد به یک جریان پخش می شود، و هر سرویسی که از A داده می خواهد می تواند در آن جریان مشترک شود و آنچه را که نیاز دارد انتخاب کند؟ اگر جریانی وجود داشته باشد، همه سرویس‌ها بتوانند رویدادهای خود را پخش کنند و مشترک شوند؟ این مدل pub/sub: public & subscribe نام دارد. این همان چیزی است که راه حل هایی مانند کافکا به شما اجازه می دهد. از آنجایی که تمام داده ها از طریق یک جریان جریان می یابد، می توانید یک داشبورد برای نظارت بر داده های خود و تغییر آن در سراسر سیستم خود راه اندازی کنید. از آنجایی که بر اساس رویدادهایی است که توسط سرویس‌ها پخش می‌شوند، این معماری رویداد محور است.
معماری مبتنی بر درخواست برای سیستم‌هایی که بیشتر به منطق متکی هستند تا داده به خوبی کار می‌کند. معماری رویداد محور برای سیستم هایی که داده های سنگینی دارند بهتر عمل می کند.
چالش ها
بسیاری از شرکت‌ها از پردازش دسته‌ای به پردازش جریانی، از معماری درخواست محور به معماری رویداد محور تغییر می‌کنند. برداشت من از صحبت با شرکت های بزرگ اینترنتی در ایالات متحده و چین این است که این تغییر در ایالات متحده هنوز کند است، اما در چین بسیار سریعتر است. پذیرش معماری استریم با محبوبیت کافکا و فلینک گره خورده است. رابرت متزگر به من گفت که بارهای کار یادگیری ماشینی بیشتری را با Flink در آسیا نسبت به ایالات متحده مشاهده کرده است. Google Trends برای "Apache Flink" با این مشاهدات سازگار است.
دلایل زیادی وجود دارد که چرا پخش جریانی محبوب‌تر نیست.
شرکت ها مزایای پخش جریانی را نمی بینند
سیستم آنها در مقیاسی نیست که ارتباطات بین خدماتی یک گلوگاه باشد.
آنها برنامه هایی ندارند که از پیش بینی های آنلاین بهره مند شوند.
آنها برنامه هایی دارند که ممکن است از پیش بینی های آنلاین سود ببرند، اما هنوز این را نمی دانند زیرا قبلاً هرگز پیش بینی آنلاین انجام نداده اند.
سرمایه گذاری اولیه بالا در زیرساخت
به روز رسانی زیرساخت گران است و می تواند برنامه های موجود را به خطر بیندازد. مدیران ممکن است تمایلی به سرمایه گذاری برای ارتقای زیرساخت های خود نداشته باشند تا امکان پیش بینی آنلاین فراهم شود.
تغییر ذهنی
تغییر از پردازش دسته ای به پردازش جریانی نیاز به یک تغییر ذهنی دارد. با پردازش دسته ای، می دانید که چه زمانی یک کار انجام می شود. با پردازش جریانی، هرگز انجام نمی شود. شما می توانید قوانینی مانند دریافت میانگین تمام نقاط داده در 2 دقیقه گذشته ایجاد کنید، اما اگر رویدادی که 2 دقیقه پیش رخ داده است با تأخیر مواجه شود و هنوز وارد جریان نشده باشد، چه؟ با پردازش دسته ای می توانید جداول کاملاً مشخصی داشته باشید و به آنها بپیوندید، اما در استریم جدولی برای پیوستن وجود ندارد، پس انجام عملیات اتصال روی دو جریان به چه معناست؟
ناسازگاری پایتون
پایتون زبان یادگیری ماشینی است در حالی که کافکا و فلینک روی جاوا و اسکالا اجرا می شوند. معرفی استریم ممکن است ناسازگاری زبان را در جریان کار ایجاد کند. Apache Beam یک رابط پایتون در بالای Flink برای برقراری ارتباط با جریان‌ها ارائه می‌کند، اما همچنان به افرادی نیاز دارید که بتوانند با جاوا/اسکالا کار کنند.
هزینه پردازش بالاتر
پردازش دسته ای به این معنی است که می توانید از منابع محاسباتی خود به نحو احسن استفاده کنید. اگر سخت افزار شما قادر به پردازش 1000 نقطه داده در یک زمان است، استفاده از آن برای پردازش تنها 1 نقطه داده در یک زمان بیهوده است.
سطح 2: یادگیری مستمر - سیستم شما می تواند داده های جدید را ترکیب کرده و در زمان واقعی به روز رسانی کند
زمان واقعی در اینجا به ترتیب دقیقه تعریف شده است
تعریف "یادگیری مستمر"
من از «یادگیری مستمر» به جای «آموزش آنلاین» یا «یادگیری آنلاین» استفاده کردم، زیرا دو عبارت اخیر باعث می‌شود مردم به یادگیری از هر نقطه داده‌ای ورودی فکر کنند. شرکت های بسیار بسیار کمی واقعاً این کار را انجام می دهند زیرا:
این روش از فراموشی فاجعه‌بار رنج می‌برد - شبکه‌های عصبی با یادگیری اطلاعات جدید، ناگهان اطلاعات آموخته‌شده قبلی را فراموش می‌کنند.
اجرای یک مرحله یادگیری تنها در یک نقطه داده می‌تواند گران‌تر از یک دسته داده باشد (این را می‌توان با داشتن سخت‌افزار به اندازه کافی قدرتمند برای پردازش دقیقاً یک نقطه داده کاهش داد).
حتی اگر یک مدل با هر نقطه داده ورودی در حال یادگیری باشد، به این معنی نیست که وزن‌های جدید بعد از هر نقطه داده مستقر می‌شوند. با درک محدود فعلی ما از نحوه یادگیری الگوریتم های ML، مدل به روز شده باید ابتدا ارزیابی شود تا ببینیم چقدر خوب عمل می کند.
برای اکثر شرکت‌هایی که به اصطلاح آموزش آنلاین یا یادگیری آنلاین انجام می‌دهند، مدل‌های آنها به صورت میکرو دسته‌ای یاد می‌گیرند و پس از مدت زمان مشخصی ارزیابی می‌شوند. تنها پس از ارزیابی عملکرد آن به عنوان رضایت بخش، مدل به طور گسترده تر گسترش می یابد. برای Weibo، چرخه تکرار آنها از یادگیری تا استقرار به روز رسانی مدل 10 دقیقه است.
یادگیری ماشین با Flink در Weibo (Qian Yu، Flink Forward 2020)
با این حال، یادگیری مستمر در مورد فرکانس بازآموزی نیست، بلکه نحوه آموزش مجدد مدل است.
اکثر شرکت‌ها آموزش مجدد بدون تابعیت انجام می‌دهند – این مدل هر بار از ابتدا آموزش داده می‌شود. یادگیری مستمر به معنای اجازه دادن به آموزش حالتی است - مدل به آموزش بر روی داده های جدید (تنظیم دقیق) ادامه می دهد.
هنگامی که زیرساخت شما برای انجام تمرینات حالت دار تنظیم شد، فرکانس تمرین فقط یک دکمه برای چرخاندن است. می‌توانید مدل‌های خود را هر ساعت یکبار، روزی یکبار به‌روزرسانی کنید، یا هر زمان که سیستم شما تغییر توزیع را تشخیص داد، می‌توانید مدل‌های خود را به‌روزرسانی کنید.
از Use casesاستفاده کنید
TikTok فوق العاده اعتیاد آور است. راز آن در سیستم‌های توصیه آن نهفته است که می‌توانند تنظیمات برگزیده شما را به سرعت یاد بگیرند و ویدیوهایی را که احتمالاً در آینده تماشا خواهید کرد، پیشنهاد می‌کنند، و به کاربرانش تجربه اسکرول باورنکردنی می‌دهند. این امکان وجود دارد زیرا ByteDance، شرکت پشتیبان TikTok، زیرساخت کاملی را راه‌اندازی کرده است که به سیستم‌های توصیه‌کننده آنها اجازه می‌دهد تنظیمات برگزیده کاربر («نمایه‌های کاربر» در زبان خود) را در زمان واقعی بیاموزند.
سیستم های توصیه کاندیدای عالی برای یادگیری مداوم هستند. آنها برچسب های طبیعی دارند - اگر کاربر روی توصیه ای کلیک کند، پیش بینی درستی است. همه سیستم های توصیه به یادگیری مستمر نیاز ندارند. ترجیحات کاربر برای مواردی مانند خانه‌ها، اتومبیل‌ها، پروازها، هتل‌ها بعید است از دقیقه‌ای به دقیقه دیگر تغییر کند، بنابراین یادگیری مداوم سیستم‌ها منطقی نیست. با این حال، ترجیحات کاربر برای محتوای آنلاین - ویدئوها، مقالات، اخبار، توییت‌ها، پست‌ها، میم‌ها - می‌تواند خیلی سریع تغییر کند ("من فقط خواندم که اختاپی گاهی اوقات بدون دلیل ماهی را مشت می‌کند و اکنون می‌خواهم ویدیویی از آن ببینم"). از آنجایی که اولویت‌ها برای محتوای آنلاین در زمان واقعی تغییر می‌کنند، سیستم‌های تبلیغاتی نیز برای نمایش تبلیغات مرتبط باید در زمان واقعی به‌روزرسانی شوند.
یادگیری مداوم برای سازگاری سیستم ها با رویدادهای نادر بسیار مهم است. خرید آنلاین در جمعه سیاه را در نظر بگیرید. از آنجایی که جمعه سیاه تنها یک بار در سال اتفاق می‌افتد، به هیچ وجه آمازون یا سایر سایت‌های تجارت الکترونیک نمی‌توانند داده‌های تاریخی کافی برای یادگیری نحوه رفتار کاربران در آن روز به دست آورند، بنابراین سیستم‌های آنها باید به طور مداوم در آن روز بیاموزند تا سازگار شوند.
یا زمانی که شخصی معروف چیزی احمقانه را توییت می کند، جستجوی توییتر را در نظر بگیرید. به عنوان مثال، به محض انتشار خبر "محوطه سازی کل چهار فصل"، بسیاری از مردم به جستجوی "محوطه سازی کل" می پردازند. اگر سیستم شما بلافاصله یاد نگیرد که "محوطه سازی کلی" در اینجا به کنفرانس مطبوعاتی اشاره دارد، کاربران شما توصیه های باغبانی زیادی دریافت خواهند کرد.
یادگیری مداوم همچنین می تواند به مشکل شروع سرد کمک کند. کاربری به تازگی به برنامه شما ملحق شده است و شما هنوز هیچ اطلاعاتی در مورد او ندارید. اگر ظرفیت هر شکلی از یادگیری مداوم را ندارید، باید تا دفعه بعدی که مدل شما به صورت آفلاین آموزش داده شود، توصیه های عمومی را به کاربران ارائه دهید.
راه حل ها
از آنجایی که یادگیری مستمر هنوز نسبتاً جدید است و اکثر شرکت هایی که این کار را انجام می دهند هنوز به طور عمومی در مورد آن با جزئیات صحبت نمی کنند، هیچ راه حل استانداردی وجود ندارد.
یادگیری مستمر به معنای "بدون آموزش دسته ای" نیست. شرکت هایی که با موفقیت از یادگیری مستمر استفاده کرده اند نیز مدل های خود را به صورت آفلاین به صورت موازی آموزش می دهند و سپس نسخه آنلاین را با نسخه آفلاین ترکیب می کنند.
چالش ها
یادگیری مستمر با چالش های زیادی مواجه است، هم از نظر نظری و هم عملی.
نظری
یادگیری مستمر بسیاری از چیزهایی را که در مورد یادگیری ماشینی یاد گرفته‌ایم در ذهن خود تغییر می‌دهد. در کلاس‌های یادگیری ماشین مقدماتی، احتمالاً به دانش‌آموزان نسخه‌های مختلفی از «مدل خود را با تعداد کافی دوره تا زمان همگرایی آموزش دهید» آموزش داده می‌شود. در یادگیری مستمر، هیچ دوره ای وجود ندارد - مدل شما هر نقطه داده را فقط یک بار می بیند. چیزی به نام همگرایی هم وجود ندارد. توزیع داده های اساسی شما همچنان در حال تغییر است. هیچ چیز ثابتی برای همگرایی وجود ندارد.
چالش نظری دیگر برای یادگیری مستمر، ارزیابی مدل است. در آموزش دسته‌ای سنتی، مدل‌های خود را بر روی مجموعه‌های تست ثابت ارزیابی می‌کنید. اگر یک مدل جدید در همان مجموعه آزمایشی بهتر از مدل موجود عمل کند، می گوییم مدل جدید بهتر است. با این حال، هدف از یادگیری مستمر این است که مدل خود را با داده های دائما در حال تغییر تطبیق دهید. اگر مدل به‌روزرسانی‌شده شما اکنون برای سازگاری با داده‌ها آموزش دیده است، و می‌دانیم که داده‌های اکنون با داده‌های گذشته متفاوت است، استفاده از داده‌های قدیمی برای آزمایش مدل به‌روزرسانی‌شده‌تان منطقی نیست.
سپس چگونه بفهمیم که مدل آموزش داده شده بر روی داده های 10 دقیقه گذشته بهتر از مدل آموزش داده شده بر روی داده های 20 دقیقه قبل است؟ ما باید این دو مدل را بر اساس داده های فعلی مقایسه کنیم. آموزش آنلاین نیاز به ارزیابی آنلاین دارد، اما ارائه مدلی که برای کاربران آزمایش نشده است مانند دستور العملی برای فاجعه به نظر می رسد.
به هر حال بسیاری از شرکت ها این کار را انجام می دهند. مدل‌های جدید ابتدا تحت آزمایش‌های آفلاین قرار می‌گیرند تا مطمئن شوند که فاجعه‌بار نیستند، سپس به‌صورت آنلاین به موازات مدل‌های موجود از طریق یک سیستم آزمایش پیچیده A/B ارزیابی می‌شوند. تنها زمانی که یک مدل در برخی معیارها بهتر از یک مدل موجود نشان داده شود، شرکت به آن اهمیت می دهد که می تواند گسترده تر استقرار یابد. (من را در انتخاب یک معیار برای ارزیابی آنلاین شروع نکنید).
کاربردی
هنوز زیرساخت های استانداردی برای آموزش آنلاین وجود ندارد. برخی از شرکت‌ها به معماری استریم با سرورهای پارامتری همگرا شده‌اند، اما به غیر از آن، شرکت‌هایی که آموزش آنلاین انجام می‌دهند که من با آنها صحبت کرده‌ام، مجبورند بسیاری از زیرساخت‌های خود را در خانه بسازند. من تمایلی به بحث آنلاین درباره این موضوع ندارم زیرا برخی از شرکت‌ها از من خواستند که این اطلاعات را محرمانه نگه دارم زیرا آنها در حال ساخت راه‌حل‌هایی برای آنها هستند - این مزیت رقابتی آنهاست.
مسابقه MLOps بین ایالات متحده و چین
من در مورد مسابقه هوش مصنوعی بین ایالات متحده و چین مطالب زیادی خوانده ام، اما به نظر می رسد بیشتر مقایسه ها بر روی تعداد مقالات تحقیقاتی، پتنت ها، استنادات و بودجه متمرکز است. تنها پس از اینکه شروع به صحبت با شرکت های آمریکایی و چینی در مورد یادگیری ماشینی بلادرنگ کردم، متوجه تفاوت خیره کننده ای در زیرساخت های MLOps آنها شدم.
تعداد کمی از شرکت های اینترنتی آمریکایی اقدام به یادگیری مستمر کرده اند و حتی در بین این شرکت ها، یادگیری مستمر برای مدل های ساده ای مانند رگرسیون لجستیک استفاده می شود. برداشت من از صحبت مستقیم با شرکت‌های چینی و صحبت با افرادی که با شرکت‌های هر دو کشور کار کرده‌اند این است که یادگیری مداوم در چین رایج‌تر است و مهندسان چینی مشتاق‌تر برای انجام این پرش هستند. می توانید برخی از گفتگوها را اینجا و اینجا ببینید
نتیجه
یادگیری ماشینی در زمان واقعی انجام می شود، چه آماده باشید چه نباشید. در حالی که اکثر شرکت‌ها هنوز در حال بحث هستند که آیا استنتاج آنلاین و یادگیری مستمر ارزش دارد، برخی از کسانی که این کار را به درستی انجام می‌دهند قبلاً بازده سرمایه‌گذاری را مشاهده کرده‌اند و الگوریتم‌های بلادرنگ آنها ممکن است عامل اصلی کمک‌کننده باشد که به آنها کمک می‌کند جلوتر باشند. رقبای آنهامن افکار بسیار بیشتری در مورد یادگیری ماشین بلادرنگ دارم، اما این پست در حال حاضر طولانی است. اگر علاقه مند به گپ زدن در این مورد هستید، تماس بگیرید!
قدردانی
این پست ترکیبی از گفتگوهای بسیاری با مهندسان و دانشگاهیان فوق العاده زیر است. مایلم از رابرت متزگر، نیل لارنس، ساوین گویال، ژنژونگ ژو، ویل تولوس، دات تران، هان شیائو، هین لو، لدیو آگو، پیتر اسکوموروچ، پیرو مولینو، دانیل یائو، جیسون اسلایت، بکت کین، تین لی تشکر کنم. ، آبراهام استاروستا، ویل دیدریک، کالب کایزر، میگل راموس.
چندین نفر دیگر هم هستند که انتخاب کرده اند ناشناس بمانند. بدون آنها، این پست ناقص خواهد بود.
با تشکر از لوک متز برای اولین خواننده شگفت انگیز!
من می خواهم زمان زیادی را به یادگیری اختصاص دهم. من امیدوارم که گروهی از افراد با علایق مشابه را پیدا کنم و با هم یاد بگیریم. در اینجا برخی از موضوعاتی است که می خواهم یاد بگیرم:
ML در لبه (تلفن، تبلت، مرورگر)
پیش بینی های آنلاین و یادگیری مستمر برای یادگیری ماشین
MLO ها به طور کلی
