قوانین یادگیری ماشین:

بهترین روش ها برای مهندسی ML

مارتین زینکویچ

این سند برای کمک به افرادی که دانش اولیه در زمینه یادگیری ماشینی دارند کمک می‌کند تا از بهترین شیوه‌های Google در یادگیری ماشینی استفاده کنند. این یک سبک برای یادگیری ماشین ارائه می دهد، شبیه به Google C++ Style Guide و سایر راهنماهای محبوب برنامه نویسی عملی. اگر در کلاس یادگیری ماشین شرکت کرده اید، یا یک مدل یادگیری ماشینی ساخته یا کار کرده اید، پس زمینه لازم برای خواندن این سند را دارید.

مارتین زینکویچ 10 قانون مورد علاقه خود را در یادگیری ماشین معرفی می کند. برای یادگیری تمام 43 قانون به ادامه مطلب بروید!

اصطلاحات

در بحث ما در مورد یادگیری ماشینی موثر، اصطلاحات زیر بارها و بارها مطرح خواهند شد:

  • مثال : چیزی که می‌خواهید درباره آن پیش‌بینی کنید. به عنوان مثال، ممکن است یک صفحه وب باشد که می‌خواهید آن را به عنوان «درباره گربه‌ها» یا «نه درباره گربه‌ها» طبقه‌بندی کنید.
  • برچسب : پاسخی برای یک کار پیش‌بینی، یا پاسخی که توسط یک سیستم یادگیری ماشینی تولید می‌شود، یا پاسخ مناسبی که در داده‌های آموزشی ارائه می‌شود. برای مثال، برچسب یک صفحه وب ممکن است "درباره گربه ها" باشد.
  • ویژگی : ویژگی یک نمونه مورد استفاده در یک کار پیش بینی. به عنوان مثال، یک صفحه وب ممکن است دارای ویژگی "حاوی کلمه "گربه" باشد.
  • ستون ویژگی : مجموعه ای از ویژگی های مرتبط، مانند مجموعه همه کشورهای ممکن که کاربران ممکن است در آنها زندگی کنند. یک مثال ممکن است دارای یک یا چند ویژگی در یک ستون ویژگی باشد. "ستون ویژگی" اصطلاحات خاص گوگل است. یک ستون ویژگی در سیستم VW (در یاهو/مایکروسافت)، یا یک فیلد به‌عنوان «فضای نام» نامیده می‌شود.
  • مثال : یک نمونه (با ویژگی های آن) و یک برچسب.
  • مدل : نمایش آماری یک کار پیش بینی. شما یک مدل را بر روی مثال ها آموزش می دهید و سپس از مدل برای پیش بینی استفاده می کنید.
  • متریک : عددی که به آن اهمیت می دهید. ممکن است مستقیماً بهینه شود یا نباشد.
  • هدف : معیاری که الگوریتم شما سعی در بهینه سازی آن دارد.
  • خط لوله : زیرساختی که یک الگوریتم یادگیری ماشین را احاطه کرده است. شامل جمع‌آوری داده‌ها از قسمت جلو، قرار دادن آن در فایل‌های داده آموزشی، آموزش یک یا چند مدل، و صادرات مدل‌ها به تولید است.
  • نرخ کلیک درصدی از بازدیدکنندگان یک صفحه وب که روی پیوندی در یک تبلیغ کلیک می کنند.

نمای کلی

برای ساخت محصولات عالی:

یادگیری ماشین را مانند مهندس بزرگی که هستید انجام دهید، نه مانند کارشناس بزرگ یادگیری ماشینی که نیستید.

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

  1. اطمینان حاصل کنید که خط لوله شما از انتها به انتها محکم است.
  2. با یک هدف معقول شروع کنید.
  3. ویژگی های عقل سلیم را به روشی ساده اضافه کنید.
  4. اطمینان حاصل کنید که خط لوله شما محکم می ماند.

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

هنگامی که ترفندهای ساده را تمام کردید، یادگیری ماشینی پیشرفته ممکن است واقعاً در آینده شما باشد. بخش پروژه های یادگیری ماشین فاز III را ببینید.

این سند به شرح زیر تنظیم شده است:

  1. بخش اول باید به شما کمک کند تا بفهمید آیا زمان مناسبی برای ساختن یک سیستم یادگیری ماشینی است یا خیر.
  2. بخش دوم در مورد استقرار اولین خط لوله شما است.
  3. بخش سوم درباره راه‌اندازی و تکرار در حین افزودن ویژگی‌های جدید به خط لوله، نحوه ارزیابی مدل‌ها و انحراف خدمات آموزشی است.
  4. بخش پایانی درباره این است که وقتی به یک فلات رسیدید چه کاری باید انجام دهید.
  5. پس از آن، فهرستی از کارهای مرتبط و یک ضمیمه با پیشینه ای در مورد سیستم هایی که معمولاً به عنوان نمونه در این سند استفاده می شوند، وجود دارد.

قبل از یادگیری ماشینی

قانون شماره 1: از راه اندازی یک محصول بدون یادگیری ماشین نترسید.

یادگیری ماشین جالب است، اما نیاز به داده دارد. از نظر تئوری، می‌توانید داده‌ها را از یک مشکل دیگر بگیرید و سپس مدل را برای یک محصول جدید تغییر دهید، اما این احتمالاً عملکرد اکتشافی اولیه را کاهش می‌دهد. اگر فکر می کنید که یادگیری ماشین 100٪ به شما کمک می کند، یک اکتشافی 50٪ شما را به آنجا می رساند.

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

قانون شماره 2: ابتدا معیارها را طراحی و اجرا کنید.

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

  1. گرفتن مجوز از کاربران سیستم زودتر آسان تر است.
  2. اگر فکر می کنید در آینده ممکن است چیزی نگران کننده باشد، بهتر است همین الان اطلاعات تاریخی را بدست آورید.
  3. اگر سیستم خود را با در نظر گرفتن ابزار دقیق متریک طراحی کنید، در آینده اوضاع برای شما بهتر خواهد شد. به طور خاص، شما نمی خواهید خود را در جستجوی رشته ها در سیاهه های مربوط به ابزار سنجش معیارهای خود بیابید!
  4. متوجه خواهید شد که چه چیزهایی تغییر می کنند و چه چیزی ثابت می ماند. به عنوان مثال، فرض کنید می خواهید مستقیماً کاربران فعال یک روزه را بهینه کنید. با این حال، در طول دستکاری های اولیه سیستم، ممکن است متوجه شوید که تغییرات چشمگیر تجربه کاربر این معیار را به طور قابل توجهی تغییر نمی دهد.

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

با آزادی عمل بیشتر در مورد جمع آوری معیارها، می توانید تصویر وسیع تری از سیستم خود به دست آورید. متوجه مشکلی شده اید؟ یک متریک برای ردیابی آن اضافه کنید! در مورد تغییرات کمی در آخرین نسخه هیجان زده هستید؟ یک متریک برای ردیابی آن اضافه کنید!

قانون شماره 3: یادگیری ماشین را به جای یک اکتشافی پیچیده انتخاب کنید.

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

ML فاز اول: اولین خط لوله شما

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

قانون شماره 4: مدل اول را ساده نگه دارید و زیرساخت را درست انجام دهید.

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

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

انتخاب ویژگی های ساده اطمینان از اینکه:

  • ویژگی ها به درستی به الگوریتم یادگیری شما می رسند.
  • مدل وزن های معقول را یاد می گیرد.
  • ویژگی ها به درستی به مدل شما در سرور می رسد.

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

قانون شماره 5: زیرساخت را مستقل از یادگیری ماشین آزمایش کنید.

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

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

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

قانون شماره 6: هنگام کپی کردن خطوط لوله مراقب داده های از دست رفته باشید.

اغلب ما یک خط لوله را با کپی کردن یک خط لوله موجود ایجاد می کنیم (یعنی برنامه نویسی فرقه بار )، و خط لوله قدیمی داده هایی را که برای خط لوله جدید نیاز داریم حذف می کند. برای مثال، خط لوله Google Plus What's Hot پست‌های قدیمی‌تر را حذف می‌کند (زیرا تلاش می‌کند پست‌های تازه را رتبه‌بندی کند). این خط لوله برای استفاده برای Google Plus Stream کپی شد، جایی که پست‌های قدیمی‌تر هنوز معنادار هستند، اما خط لوله همچنان پست‌های قدیمی را حذف می‌کرد. الگوی رایج دیگر این است که فقط داده هایی را ثبت کنید که توسط کاربر دیده شده است. بنابراین، اگر بخواهیم الگوبرداری کنیم که چرا یک پست خاص توسط کاربر دیده نمی شود، این داده ها بی فایده است، زیرا همه نمونه های منفی حذف شده اند. مشکل مشابهی در Play رخ داد. در حین کار بر روی Play Apps Home، خط لوله جدیدی ایجاد شد که شامل نمونه هایی از صفحه فرود برای Play Games بود، بدون هیچ ویژگی برای ابهام زدایی که هر نمونه از کجا آمده است.

قانون شماره 7: اکتشافی ها را به ویژگی ها تبدیل کنید یا آنها را به صورت خارجی مدیریت کنید.

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

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

هنگام استفاده از اکتشافی در یک سیستم ML به پیچیدگی اضافه شده توجه داشته باشید. استفاده از روش های اکتشافی قدیمی در الگوریتم جدید یادگیری ماشین شما می تواند به ایجاد یک انتقال روان کمک کند، اما به این فکر کنید که آیا راه ساده تری برای انجام همان اثر وجود دارد یا خیر.

نظارت

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

قانون شماره 8: نیازهای تازه بودن سیستم خود را بدانید.

اگر مدلی یک روزه داشته باشید چقدر عملکرد را کاهش می دهد؟ یک هفته؟ یک ربع؟ این اطلاعات می تواند به شما در درک اولویت های نظارت خود کمک کند. اگر در صورت به روز نشدن مدل برای یک روز کیفیت محصول قابل توجهی را از دست بدهید، منطقی است که یک مهندس به طور مداوم آن را تماشا کند. اکثر سیستم‌های ارائه تبلیغات، هر روز تبلیغات جدیدی دارند و باید روزانه به‌روزرسانی شوند. به عنوان مثال، اگر مدل ML برای جستجوی Google Play به‌روزرسانی نشود، می‌تواند در کمتر از یک ماه تأثیر منفی بگذارد. برخی از مدل‌های What's Hot در Google Plus هیچ شناسه پستی در مدل خود ندارند، بنابراین می‌توانند این مدل‌ها را به ندرت صادر کنند. مدل‌های دیگری که دارای شناسه‌های پست هستند، بیشتر به‌روزرسانی می‌شوند. همچنین توجه داشته باشید که تازگی می تواند در طول زمان تغییر کند، به خصوص زمانی که ستون های ویژگی از مدل شما اضافه یا حذف می شوند.

قانون شماره 9: مشکلات را قبل از صادرات مدل ها شناسایی کنید.

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

درست قبل از اینکه مدل را صادر کنید، بررسی های سلامت عقل را انجام دهید. به طور خاص، مطمئن شوید که عملکرد مدل در داده‌های ذخیره شده معقول است. یا، اگر نگرانی‌های دائمی با داده‌ها دارید، مدلی را صادر نکنید. بسیاری از تیم‌هایی که به طور مداوم مدل‌ها را به کار می‌گیرند، ناحیه زیر منحنی ROC (یا AUC) را قبل از صادرات بررسی می‌کنند. مشکلات مربوط به مدل‌هایی که صادر نشده‌اند به یک هشدار ایمیل نیاز دارند، اما مشکلات مربوط به مدل‌های روبرو ممکن است نیاز به صفحه داشته باشند. بنابراین بهتر است قبل از تأثیرگذاری بر کاربران صبر کنید و مطمئن شوید.

قانون شماره 10: مراقب شکست های خاموش باشید.

این مشکلی است که بیشتر برای سیستم های یادگیری ماشینی رخ می دهد تا سایر انواع سیستم ها. فرض کنید جدول خاصی که در حال پیوست شدن است دیگر به روز نمی شود. سیستم یادگیری ماشین تنظیم می‌شود و رفتار به‌طور معقول خوب ادامه می‌یابد و به تدریج تحلیل می‌رود. گاهی اوقات می‌توانید جدول‌هایی را پیدا کنید که ماه‌ها قدیمی هستند، و یک تازه‌سازی ساده عملکرد را بیش از هر راه‌اندازی دیگری در آن سه‌ماهه بهبود می‌بخشد! پوشش یک ویژگی ممکن است به دلیل تغییرات پیاده‌سازی تغییر کند: برای مثال یک ستون ویژگی می‌تواند در 90 درصد نمونه‌ها پر شود و ناگهان به 60 درصد از نمونه‌ها کاهش یابد. Play زمانی میزی داشت که به مدت 6 ماه بیات مانده بود، و تازه کردن جدول به تنهایی باعث افزایش 2٪ در نرخ نصب شد. اگر آمار داده ها را ردیابی کنید، و همچنین به صورت دستی داده ها را در مواردی بررسی کنید، می توانید این نوع خرابی ها را کاهش دهید.

قانون شماره 11: به صاحبان ستون های ویژگی و مستندات بدهید.

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

اولین هدف شما

شما معیارها یا اندازه‌گیری‌های زیادی درباره سیستمی دارید که به آن اهمیت می‌دهید، اما الگوریتم یادگیری ماشین شما اغلب به یک هدف نیاز دارد، عددی که الگوریتم شما در تلاش برای بهینه‌سازی آن است. من در اینجا بین اهداف و معیارها تمایز قائل می شوم: متریک هر عددی است که سیستم شما گزارش می دهد، که ممکن است مهم باشد یا نباشد. قانون شماره 2 را نیز ببینید.

قانون شماره 12: بیش از حد فکر نکنید که کدام هدف را مستقیماً بهینه سازی می کنید.

شما می خواهید پول در بیاورید، کاربران خود را خوشحال کنید و دنیا را به مکانی بهتر تبدیل کنید. تعداد زیادی معیار وجود دارد که به آنها اهمیت می دهید، و باید همه آنها را اندازه گیری کنید ( قانون شماره 2 را ببینید). با این حال، در اوایل فرآیند یادگیری ماشینی، متوجه افزایش همه آنها خواهید شد، حتی آنهایی که مستقیماً آنها را بهینه نمی کنید. به عنوان مثال، فرض کنید به تعداد کلیک ها و زمان صرف شده در سایت اهمیت می دهید. اگر برای تعداد کلیک ها بهینه سازی کنید، احتمالاً شاهد افزایش زمان صرف شده خواهید بود.

بنابراین، آن را ساده نگه دارید و در مورد متعادل کردن معیارهای مختلف زیاد فکر نکنید، در حالی که هنوز می توانید به راحتی همه معیارها را افزایش دهید. با این حال، این قانون را زیاد دور نگیرید: هدف خود را با سلامت نهایی سیستم اشتباه نگیرید (به قانون شماره 39 مراجعه کنید). و، اگر متوجه شدید که متریک مستقیماً بهینه‌سازی شده را افزایش می‌دهید، اما تصمیم به راه‌اندازی ندارید، ممکن است نیاز به بازنگری عینی باشد.

قانون شماره 13: یک معیار ساده، قابل مشاهده و قابل انتساب برای اولین هدف خود انتخاب کنید.

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

ساده‌ترین چیز برای مدل‌سازی، رفتار کاربر است که مستقیماً مشاهده می‌شود و به عملکرد سیستم نسبت داده می‌شود:

  • آیا این لینک رتبه بندی شده کلیک شده است؟
  • آیا این شی رتبه بندی شده دانلود شد؟
  • آیا این شیء رتبه‌بندی‌شده بازارسال/پاسخ داده شد/ایمیل شد؟
  • آیا این شی رتبه بندی شده رتبه بندی شده است؟
  • آیا این شیء نشان داده شده به عنوان هرزنامه / هرزه نگاری / توهین آمیز علامت گذاری شده است؟

در ابتدا از مدل سازی اثرات غیر مستقیم خودداری کنید:

  • آیا کاربر روز بعد بازدید کرده است؟
  • کاربر چه مدت از سایت بازدید کرده است؟
  • کاربران فعال روزانه چه کسانی بودند؟

جلوه‌های غیرمستقیم معیارهای بسیار خوبی را ایجاد می‌کنند و می‌توانند در آزمایش A/B و در هنگام تصمیم‌گیری برای راه‌اندازی استفاده شوند.

در نهایت، سعی نکنید یادگیری ماشین را به این نتیجه برسانید:

  • آیا کاربر از استفاده از محصول راضی است؟
  • آیا کاربر از تجربه راضی است؟
  • آیا محصول سلامت کلی کاربر را بهبود می بخشد؟
  • این چه تاثیری بر سلامت کلی شرکت خواهد داشت؟

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

قانون شماره 14: شروع با یک مدل قابل تفسیر، اشکال زدایی را آسان تر می کند.

رگرسیون خطی، رگرسیون لجستیک و رگرسیون پواسون مستقیماً توسط یک مدل احتمالی انگیزه می‌شوند. هر پیش بینی به عنوان یک احتمال یا یک مقدار مورد انتظار قابل تفسیر است. این باعث می‌شود که اشکال‌زدایی آن‌ها نسبت به مدل‌هایی که از اهداف (از دست دادن صفر-یک، تلفات لولای مختلف و غیره) استفاده می‌کنند که مستقیماً دقت طبقه‌بندی یا عملکرد رتبه‌بندی را بهینه کنند، آسان‌تر می‌کند. به عنوان مثال، اگر احتمالات در آموزش از احتمالات پیش بینی شده در کنار هم یا با بازرسی سیستم تولید منحرف شود، این انحراف می تواند مشکلی را آشکار کند.

برای مثال، در رگرسیون خطی، لجستیک یا پواسون، زیرمجموعه‌هایی از داده‌ها وجود دارد که میانگین انتظارات پیش‌بینی‌شده با برچسب میانگین برابری می‌کند (کالیبره‌شده یک لحظه یا فقط کالیبره‌شده) . این درست است با فرض اینکه شما هیچ نظمی ندارید و الگوریتم شما همگرا شده است و در کل تقریباً درست است. اگر یک ویژگی دارید که برای هر مثال 1 یا 0 است، مجموعه 3 نمونه که در آن ویژگی 1 است کالیبره می شود. همچنین، اگر یک ویژگی دارید که برای هر مثال 1 است، مجموعه همه نمونه‌ها کالیبره می‌شوند.

با مدل‌های ساده، مقابله با حلقه‌های بازخورد آسان‌تر است ( قانون شماره 36 را ببینید). اغلب، ما از این پیش‌بینی‌های احتمالی برای تصمیم‌گیری استفاده می‌کنیم: به عنوان مثال، رتبه‌بندی پست‌ها در کاهش ارزش مورد انتظار (یعنی احتمال کلیک/دانلود/غیره). با این حال، به یاد داشته باشید زمانی که زمان انتخاب مدل برای استفاده فرا می رسد، تصمیم بیشتر از احتمال داده های داده شده به مدل اهمیت دارد (به قانون شماره 27 مراجعه کنید).

قانون شماره 15: فیلتر هرزنامه و رتبه بندی کیفیت را در یک لایه سیاست جدا کنید.

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

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

ML فاز دوم: مهندسی ویژگی

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

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

قانون شماره 16: برای راه اندازی و تکرار برنامه ریزی کنید.

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

  • شما در حال ارائه ویژگی های جدید هستید.
  • شما در حال تنظیم منظم و ترکیب ویژگی های قدیمی به روش های جدید هستید.
  • شما در حال تنظیم هدف هستید.

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

قانون شماره 17: با ویژگی های مشاهده شده و گزارش شده به جای ویژگی های آموخته شده شروع کنید.

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

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

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

قانون شماره 18: با ویژگی هایی از محتوا که در زمینه ها تعمیم می یابد، کاوش کنید.

اغلب یک سیستم یادگیری ماشین بخش کوچکی از یک تصویر بسیار بزرگتر است. به عنوان مثال، اگر پستی را تصور کنید که ممکن است در خبرهای داغ مورد استفاده قرار گیرد، بسیاری از افراد قبل از اینکه پستی در خبرهای داغ نشان داده شود، پلاس یک، اشتراک‌گذاری مجدد یا نظر روی آن می‌گذارند. اگر آن آمار را به یادگیرنده ارائه دهید، می‌تواند پست‌های جدیدی را که هیچ داده‌ای برای آنها در زمینه بهینه‌سازی ندارد، تبلیغ کند. YouTube Watch Next می‌تواند از تعداد تماشاها یا تماشاهای مشترک (تعداد دفعاتی که یک ویدیو پس از تماشای ویدیوی دیگر تماشا شده است) از جستجوی YouTube استفاده کند. همچنین می توانید از رتبه بندی صریح کاربران استفاده کنید. در نهایت، اگر یک کنش کاربری دارید که به عنوان برچسب از آن استفاده می‌کنید، دیدن آن عملکرد روی سند در زمینه‌ای متفاوت می‌تواند یک ویژگی عالی باشد. همه این ویژگی‌ها به شما امکان می‌دهند تا محتوای جدید را وارد متن کنید. توجه داشته باشید که این مربوط به شخصی‌سازی نیست: ابتدا بفهمید که آیا کسی محتوا را در این زمینه می‌پسندد، سپس بفهمید چه کسی آن را بیشتر یا کمتر دوست دارد.

قانون 19: در صورت امکان از ویژگی های بسیار خاص استفاده کنید.

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

قانون شماره 20: ترکیب و اصلاح ویژگی های موجود برای ایجاد ویژگی های جدید به روش های قابل درک برای انسان.

روش های مختلفی برای ترکیب و تغییر ویژگی ها وجود دارد. سیستم‌های یادگیری ماشینی مانند TensorFlow به شما امکان می‌دهند داده‌های خود را از طریق تبدیل‌ها از قبل پردازش کنید. دو رویکرد استاندارد "گسسته سازی" و "تقاطع" هستند.

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

صلیب ها دو یا چند ستون ویژگی را ترکیب می کنند. یک ستون ویژگی، در اصطلاح تنسورفلو، مجموعه‌ای از ویژگی‌های همگن است (مثلاً {مرد، زن}، {ایالات متحده، کانادا، مکزیک}، و غیره). ضربدر یک ستون ویژگی جدید با ویژگی‌هایی است که به عنوان مثال، {male, women} × {US, Canada, Mexico} است. این ستون ویژگی جدید حاوی ویژگی (مرد، کانادا) خواهد بود. اگر از TensorFlow استفاده می کنید و به TensorFlow می گویید که این متقاطع را برای شما ایجاد کند، این ویژگی (مرد، کانادا) در نمونه هایی وجود دارد که نشان دهنده مردان کانادایی است. توجه داشته باشید که یادگیری مدل هایی با تلاقی سه، چهار یا بیشتر ستون های ویژگی پایه، به حجم زیادی از داده نیاز دارد.

صلیب هایی که ستون های ویژگی بسیار بزرگ ایجاد می کنند ممکن است بیش از حد مناسب باشند. به عنوان مثال، تصور کنید که در حال انجام نوعی جستجو هستید، و یک ستون ویژگی با کلمات در پرس و جو دارید، و یک ستون ویژگی با کلمات در سند دارید. می‌توانید اینها را با یک ضربدر ترکیب کنید، اما در نهایت ویژگی‌های زیادی خواهید داشت ( قانون شماره 21 را ببینید).

هنگام کار با متن دو گزینه وجود دارد. شدیدترین محصول نقطه ای است. یک محصول نقطه ای در ساده ترین شکل خود به سادگی تعداد کلمات مشترک بین پرس و جو و سند را می شمارد. سپس این ویژگی می تواند گسسته شود. روش دیگر تقاطع است: بنابراین، ما یک ویژگی خواهیم داشت که اگر و فقط در صورت وجود کلمه "pony" در سند و پرس و جو وجود داشته باشد، و ویژگی دیگری که اگر و فقط در صورت وجود کلمه "the" وجود داشته باشد، خواهیم داشت. هم در سند و هم در پرس و جو

قانون شماره 21: تعداد وزن ویژگی هایی که می توانید در یک مدل خطی یاد بگیرید تقریباً با مقدار داده ای که دارید متناسب است.

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

  1. اگر روی یک سیستم رتبه بندی جستجو کار می کنید و میلیون ها کلمه مختلف در اسناد و درخواست وجود دارد و 1000 نمونه برچسب دار دارید، باید از محصول نقطه ای بین ویژگی های سند و پرس و جو، TF-IDF ، و نیم استفاده کنید. ده ها ویژگی دیگر بسیار مهندسی شده توسط انسان. 1000 نمونه، ده ها ویژگی.
  2. اگر میلیون‌ها مثال دارید، ستون‌های ویژگی سند و پرس و جو را با استفاده از منظم‌سازی و احتمالاً انتخاب ویژگی قطع کنید. این میلیون ها ویژگی را در اختیار شما قرار می دهد، اما با تنظیم کردن، تعداد کمتری خواهید داشت. ده میلیون نمونه، شاید صد هزار ویژگی.
  3. اگر میلیاردها یا صدها میلیارد مثال دارید، می‌توانید با استفاده از انتخاب ویژگی و منظم‌سازی، از ستون‌های ویژگی با نشانه‌های سند و پرس و جو عبور کنید. شما یک میلیارد نمونه و 10 میلیون ویژگی خواهید داشت. تئوری یادگیری آماری به ندرت محدودیت‌های محکمی را ارائه می‌کند، اما راهنمایی عالی برای یک نقطه شروع ارائه می‌کند.

در پایان، از قانون شماره 28 استفاده کنید تا تصمیم بگیرید از چه ویژگی هایی استفاده کنید.

قانون شماره 22: ویژگی هایی را که دیگر از آنها استفاده نمی کنید پاک کنید.

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

هنگام در نظر گرفتن اینکه چه ویژگی هایی را اضافه کنید یا نگه دارید، پوشش را در نظر داشته باشید. چند نمونه تحت پوشش این ویژگی است؟ به عنوان مثال، اگر برخی از ویژگی‌های شخصی‌سازی دارید، اما تنها 8 درصد از کاربران شما دارای ویژگی‌های شخصی‌سازی هستند، چندان مؤثر نخواهد بود.

در عین حال، برخی از ویژگی‌ها ممکن است از وزن خود بالاتر بروند. به عنوان مثال ، اگر شما یک ویژگی دارید که فقط 1 ٪ از داده ها را در بر می گیرد ، اما 90 ٪ از نمونه هایی که دارای ویژگی هستند مثبت هستند ، این یک ویژگی عالی برای اضافه کردن خواهد بود.

تجزیه و تحلیل انسانی از سیستم

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

قانون شماره 23: شما یک کاربر نهایی معمولی نیستید.

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

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

اگر واقعاً می خواهید بازخورد کاربر داشته باشید ، از روش شناسی تجربه کاربر استفاده کنید . در اوایل یک فرآیند ، شخصیت های کاربر ایجاد کنید (یک توضیحات در تجربیات کاربر طراحی بیل Buxton است) و آزمایش قابلیت استفاده را انجام دهید (یک توضیحات در استیو کروگ است که باعث نمی شود من فکر کنم ). شخص کاربر شامل ایجاد یک کاربر فرضی است. به عنوان مثال ، اگر تیم شما همه مرد است ، ممکن است به طراحی یک شخصیت کاربر 35 ساله زن (کامل با ویژگی های کاربر) کمک کند ، و به نتایج حاصل از آن به جای 10 نتیجه برای 25 تا 40 ساله نگاه کنید نرها آوردن افراد واقعی برای تماشای واکنش خود به سایت شما (به صورت محلی یا از راه دور) در آزمایش قابلیت استفاده نیز می تواند چشم انداز تازه ای را برای شما به ارمغان بیاورد.

قانون شماره 24: دلتا را بین مدل ها اندازه گیری کنید.

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

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

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

قانون شماره 26: در خطاهای اندازه گیری شده به دنبال الگوهای باشید و ویژگی های جدیدی ایجاد کنید.

فرض کنید که یک مثال آموزشی را مشاهده می کنید که مدل "اشتباه" شده است. در یک کار طبقه بندی ، این خطا می تواند یک مثبت کاذب یا منفی کاذب باشد. در یک کار رتبه بندی ، خطا می تواند یک جفت باشد که مثبت در رده پایین تر از یک منفی قرار گرفت. مهمترین نکته این است که این نمونه ای است که سیستم یادگیری ماشین می داند که اشتباه کرده است و در صورت فرصت می خواهد برطرف شود. اگر ویژگی را به مدل ارائه دهید که به آن اجازه می دهد خطا را برطرف کند ، مدل سعی در استفاده از آن خواهد داشت.

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

هنگامی که مثالهایی دارید که مدل اشتباه کرده است ، به دنبال روندهایی باشید که خارج از مجموعه ویژگی فعلی شما باشد. به عنوان مثال ، اگر به نظر می رسد سیستم در حال تخریب پست های طولانی تر است ، پس طول پست را اضافه کنید. در مورد ویژگی هایی که اضافه می کنید خیلی خاص نباشید. اگر می خواهید طول پست را اضافه کنید ، سعی نکنید حدس بزنید که چه وسیله ای طولانی است ، فقط یک دوجین ویژگی اضافه کنید و LET مدل بفهمد با آنها چه کاری باید انجام دهد (به قانون شماره 21 مراجعه کنید). این ساده ترین راه برای به دست آوردن آنچه می خواهید است.

قانون شماره 27: سعی کنید رفتار نامطلوب مشاهده شده را کمیت کنید.

برخی از اعضای تیم شما از خواص سیستمی که دوست ندارند ، ناامید می شوند که توسط عملکرد ضرر موجود اسیر نمی شوند. در این مرحله ، آنها باید هر کاری را که لازم است انجام دهند تا چنگال های خود را به شماره های جامد تبدیل کنند. به عنوان مثال ، اگر آنها فکر کنند که بسیاری از "برنامه های GAG" در جستجوی بازی نشان داده می شوند ، می توانند رأی دهندگان انسانی برنامه های GAG را شناسایی کنند. (شما می توانید در این حالت از داده های انسانی استفاده کنید زیرا بخش نسبتاً کمی از نمایش داده ها بخش بزرگی از ترافیک را تشکیل می دهد.) اگر مسائل شما قابل اندازه گیری است ، می توانید از آنها به عنوان ویژگی ها ، اهداف یا معیارها استفاده کنید. قانون کلی " اندازه گیری اول ، بهینه سازی دوم " است.

قانون شماره 28: توجه داشته باشید که رفتار کوتاه مدت یکسان به معنای رفتار بلند مدت یکسان نیست.

تصور کنید که شما یک سیستم جدید دارید که به هر DOC_ID و EXACT_QUERY نگاه می کند ، و سپس احتمال کلیک برای هر Doc را برای هر پرس و جو محاسبه می کند. می فهمید که رفتار آن تقریباً با سیستم فعلی شما در هر دو طرف و آزمایش A/B یکسان است ، بنابراین با توجه به سادگی آن ، آن را راه اندازی می کنید. با این حال ، متوجه می شوید که هیچ برنامه جدیدی نشان داده نمی شود. چرا؟ خوب ، از آنجا که سیستم شما فقط یک سند را بر اساس تاریخچه خود با آن پرس و جو نشان می دهد ، هیچ راهی برای یادگیری اینکه باید یک سند جدید نشان داده شود وجود ندارد.

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

آموزش و پرورش

SKEW آموزش و پرورش تفاوت بین عملکرد در طول آموزش و عملکرد در طول خدمت است. این شکاف می تواند ناشی از:

  • اختلاف بین نحوه رسیدگی به داده ها در آموزش و خدمت به خطوط لوله.
  • تغییر در داده ها بین هنگام آموزش و هنگام خدمت.
  • یک حلقه بازخورد بین مدل و الگوریتم خود.

ما سیستم های یادگیری ماشین تولید را در Google مشاهده کرده ایم که در خدمت آموزش است که بر عملکرد تأثیر منفی می گذارد. بهترین راه حل این است که صریحاً آن را رصد کنید تا تغییر سیستم و داده ها بدون توجه به آن معرفی نشوند.

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

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

قانون شماره 30: داده های نمونه برداری از وزن ، به طور خودسرانه آن را رها نکنید!

هنگامی که داده های زیادی دارید ، وسوسه ای برای گرفتن پرونده های 1-12 وجود دارد و پرونده ها را 13-99 نادیده می گیرید. این یک اشتباه است. اگرچه داده هایی که هرگز به کاربر نشان داده نشده اند ، کاهش نمی یابد ، اما وزن اهمیت برای بقیه بهترین است. اهمیت وزن به این معنی است که اگر تصمیم می گیرید که می خواهید نمونه X را با احتمال 30 ٪ نمونه کنید ، به آن وزن 10/3 بدهید. با توجه به وزن ، تمام خصوصیات کالیبراسیون مورد بحث در قانون شماره 14 هنوز هم وجود دارد.

قانون شماره 31: مراقب باشید که اگر به داده های جدول در زمان آموزش و زمان خدمت می پیوندید ، داده های موجود در جدول ممکن است تغییر کند.

بگویید که با یک جدول حاوی ویژگی هایی برای آن اسناد (مانند تعداد نظرات یا کلیک) به IDS Doc می پیوندید. بین آموزش و زمان خدمت ، ویژگی های جدول ممکن است تغییر کند. پیش بینی مدل شما برای همان سند ممکن است بین آموزش و خدمت متفاوت باشد. ساده ترین راه برای جلوگیری از این نوع مشکل ، ورود به ویژگی ها در زمان خدمت است (به قانون شماره 32 مراجعه کنید). اگر جدول فقط به آرامی در حال تغییر است ، می توانید جدول را ساعتی یا روزانه نیز به عکس فوری کنید تا داده های منطقی را ببندید. توجه داشته باشید که این هنوز مسئله را به طور کامل حل نمی کند.

قانون شماره 32: در هر زمان ممکن ، از کد بین خط لوله آموزش و خط لوله سرویس خود استفاده کنید.

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

قانون شماره 33: اگر مدلی را بر اساس داده ها تا 5 ژانویه تولید می کنید ، از 6 ژانویه و بعد از آن مدل را روی داده ها آزمایش کنید.

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

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

در یک کار فیلتر ، مثالهایی که به صورت منفی مشخص می شوند به کاربر نشان داده نمی شوند. فرض کنید شما یک فیلتر دارید که 75 ٪ از نمونه های منفی را در خدمت مسدود می کند. ممکن است شما وسوسه شوید که داده های آموزشی اضافی را از مواردی که به کاربران نشان داده شده است ، ترسیم کنید. به عنوان مثال ، اگر کاربر یک ایمیل را به عنوان هرزنامه ای که فیلتر شما از آن استفاده می کند ، علامت گذاری کند ، ممکن است بخواهید از آن یاد بگیرید.

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

توجه داشته باشید که اگر فیلتر شما 95 ٪ از مثالهای منفی یا بیشتر را مسدود می کند ، این رویکرد کمتر قابل استفاده می شود. با این وجود ، اگر می خواهید عملکرد خدمت را اندازه گیری کنید ، می توانید یک نمونه حتی تر از آن را تهیه کنید (مثلاً 0.1 ٪ یا 0.001 ٪). ده هزار مثال برای تخمین عملکرد کاملاً دقیق است.

قانون شماره 35: از مشکلات ذاتی در مشکلات رتبه بندی مراقب باشید.

هنگامی که الگوریتم رتبه بندی خود را به اندازه کافی اساسی تغییر می دهید که نتایج مختلف نشان داده می شود ، داده هایی را که الگوریتم شما در آینده مشاهده می کند ، به طور موثری تغییر داده اید. این نوع skew ظاهر می شود ، و شما باید مدل خود را در اطراف آن طراحی کنید. چندین رویکرد متفاوت وجود دارد. این رویکردها همه راه هایی برای به نفع داده هایی است که مدل شما قبلاً دیده است.

  1. از ویژگی های بیشتری استفاده کنید که بر خلاف آن ویژگی هایی که فقط برای یک پرس و جو در آن قرار دارند ، نمایش داده شد. به این ترتیب ، این مدل از ویژگی هایی که مخصوص یک یا چند نمایش داده شده در مورد ویژگی هایی است که برای همه نمایش داده ها تعمیم می یابد ، طرفداری می کند. این روش می تواند به جلوگیری از نشت نتایج بسیار محبوب در نمایش داده های بی ربط کمک کند. توجه داشته باشید که این مخالف توصیه های متعارف تر در مورد تنظیم منظم بیشتر در ستون های ویژگی با مقادیر منحصر به فرد تر است.
  2. فقط به ویژگی های دارای وزن مثبت اجازه می دهد. بنابراین ، هر ویژگی خوب بهتر از ویژگی "ناشناخته" خواهد بود.
  3. ویژگی های فقط اسناد را ندارید. این یک نسخه شدید شماره 1 است. به عنوان مثال ، حتی اگر یک برنامه داده شده بدون در نظر گرفتن پرس و جو ، بارگیری محبوب باشد ، شما نمی خواهید آن را در همه جا نشان دهید. نداشتن ویژگی های اسناد فقط این ساده را حفظ می کند. دلیل اینکه شما نمی خواهید یک برنامه محبوب خاص را در همه جا نشان دهید ، مربوط به اهمیت دستیابی به همه برنامه های مورد نظر است. به عنوان مثال ، اگر کسی به جستجوی "برنامه تماشای پرندگان" بپردازد ، ممکن است "پرندگان عصبانی" را بارگیری کند ، اما مطمئناً این هدف آنها نبود. نمایش چنین برنامه ممکن است نرخ بارگیری را بهبود بخشد ، اما نیازهای کاربر را در نهایت ناراضی می کند.

قانون شماره 36: از حلقه های بازخورد با ویژگی های موقعیتی خودداری کنید.

موقعیت محتوا به طور چشمگیری بر میزان تعامل کاربر با آن تأثیر می گذارد. اگر یک برنامه را در موقعیت اول قرار دهید ، بیشتر روی آن کلیک می شود ، و متقاعد می شوید که احتمالاً کلیک می شود. یکی از راه های مقابله با این امر ، اضافه کردن ویژگی های موقعیتی ، یعنی ویژگی های مربوط به موقعیت محتوا در صفحه است. شما مدل خود را با ویژگی های موقعیتی آموزش می دهید ، و به عنوان مثال ، به عنوان مثال ، ویژگی "1stposition" را به شدت می آموزد. بنابراین مدل شما برای مثال با "1stposition = true" به سایر عوامل وزن کمتری می دهد. سپس در خدمت به شما هیچ نمونه ای از ویژگی های موقعیتی را ارائه نمی دهید ، یا همه ویژگی های یکسان را به آنها می دهید ، زیرا قبل از تصمیم گیری برای نمایش آنها ، نامزدها را به ثمر می رسانید.

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

قانون شماره 37: اندازه گیری آموزش/خدمت Skew.

چندین مورد وجود دارد که می تواند به طور کلی به معنای کلی باشد. علاوه بر این ، می توانید آن را به چندین قسمت تقسیم کنید:

  • تفاوت عملکرد در داده های آموزش و داده های نگهدارنده. به طور کلی ، این همیشه وجود خواهد داشت ، و همیشه بد نیست.
  • تفاوت بین عملکرد در داده های نگهدارنده و داده های "روز بعدی". باز هم ، این همیشه وجود خواهد داشت. شما باید تنظیم خود را تنظیم کنید تا حداکثر عملکرد روز بعد را به حداکثر برسانید. با این حال ، قطرات زیادی در عملکرد بین داده های نگهدارنده و داده های روز بعد ممکن است نشان دهد که برخی از ویژگی ها عملکرد مدل حساس به زمان و احتمالاً تخریب کننده هستند.
  • تفاوت عملکرد در داده های "روز بعد" و داده های زنده. اگر یک مدل را به عنوان مثال در داده های آموزش و همان مثال در خدمت استفاده کنید ، باید دقیقاً همان نتیجه را به شما بدهد (به شماره 5 مراجعه کنید). بنابراین ، اختلاف در اینجا احتمالاً نشانگر خطای مهندسی است.

ML فاز III: رشد آهسته ، پالایش بهینه سازی و مدلهای پیچیده

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

قانون شماره 38: اگر اهداف غیرقابل توصیف به این مسئله تبدیل شده اند ، وقت خود را برای ویژگی های جدید تلف نکنید.

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

قانون شماره 39: تصمیمات راه اندازی یک پروکسی برای اهداف بلند مدت محصول است.

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

حقیقت این است که دنیای واقعی سیاه چال ها و اژدها نیست: هیچ "نقاط ضربه ای" وجود ندارد که سلامت محصول شما را مشخص کند. این تیم باید از آماری که جمع می کند استفاده کند تا سعی کند پیش بینی کند که سیستم در آینده چقدر خوب خواهد بود. آنها باید در مورد تعامل ، 1 روزه کاربران فعال (DAU) ، 30 DAU ، درآمد و بازده سرمایه گذاری تبلیغ کننده مراقبت کنند. این معیارهایی که در تست های A/B به خودی خود قابل اندازه گیری هستند ، فقط برای اهداف طولانی مدت پروکسی هستند: رضایت کاربران ، افزایش کاربران ، رضایت از شرکا و سود ، که حتی در این صورت می توانید پروکسی هایی را برای داشتن یک محصول مفید و با کیفیت و یک در نظر بگیرید شرکت پر رونق از پنج سال دیگر.

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

آزمایش کنید کاربران فعال روزانه درآمد/روز
الف 1 میلیون 4 میلیون دلار
ب 2 میلیون 2 میلیون دلار

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

علاوه بر این ، هیچ متریک نگرانی نهایی تیم را پوشش نمی دهد ، "محصول من از کجا 5 سال دیگر خواهد بود"؟

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

قانون شماره 40: گروههای موسیقی را ساده نگه دارید.

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

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

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

شما برخی از اطلاعات جمعیت شناختی در مورد کاربر را اضافه کرده اید. شما اطلاعاتی در مورد کلمات موجود در سند اضافه کرده اید. شما اکتشاف الگو را پشت سر گذاشته اید و تنظیم منظم را تنظیم کرده اید. شما با پیشرفت بیش از 1 ٪ در معیارهای اصلی خود در چند چهارم ، راه اندازی را مشاهده نکرده اید. حالا چی؟

وقت آن است که شروع به ساختن زیرساخت ها برای ویژگی های مختلف متفاوت ، مانند تاریخچه اسنادی که این کاربر در روز گذشته ، هفته یا سال به آن دسترسی داشته است یا داده های یک خاصیت متفاوت است. از موجودات Wikidata یا چیز داخلی برای شرکت خود استفاده کنید (مانند نمودار دانش Google). از یادگیری عمیق استفاده کنید. شروع به تنظیم انتظارات خود در مورد میزان بازگشت سرمایه در سرمایه گذاری کنید و تلاش های خود را بر این اساس گسترش دهید. مانند هر پروژه مهندسی ، شما باید از مزایای اضافه کردن ویژگی های جدید در برابر هزینه افزایش پیچیدگی استفاده کنید.

قانون شماره 42: انتظار نداشته باشید که تنوع ، شخصی سازی یا ارتباط آن به همان اندازه که فکر می کنید با محبوبیت ارتباط داشته باشند.

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

مشکل این است که معمولاً ضرب و شتم سخت است.

توجه داشته باشید که اگر سیستم شما در حال اندازه گیری کلیک ، زمان صرف شده ، ساعت ، +1s ، reshares ، et cetera است ، شما محبوبیت محتوا را اندازه گیری می کنید. تیم ها گاهی سعی می کنند یک مدل شخصی را با تنوع یاد بگیرند. برای شخصی سازی ، آنها ویژگی هایی را اضافه می کنند که به سیستم امکان شخصی سازی (برخی از ویژگی های نشان دهنده علاقه کاربر) یا متنوع سازی را می دهد (ویژگی هایی که نشان می دهد این سند دارای ویژگی های مشترک با سایر اسناد برگشتی مانند نویسنده یا محتوا است) ، و می دانند که این موارد ویژگی ها نسبت به آنچه انتظار دارند وزن کمتری دارند (یا گاهی اوقات نشانه ای متفاوت).

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

قانون شماره 43: دوستان شما تمایل دارند که در بین محصولات مختلف یکسان باشند. علایق شما تمایل به وجود ندارد.

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

اسناد زیادی در مورد یادگیری ماشین در Google و همچنین خارجی وجود دارد.

قدردانی ها

با تشکر از دیوید وستبروک ، پیتر برانت ، ساموئل ایونگ ، چنیو ژائو ، لی وی ، میشالیس پوتامیاس ، ایوان روزن ، باری روزنبرگ ، کریستین رابسون ، جیمز پین ، تال شکد ، تووشار چاندرا ، مصطفی ایزیر ، ارمیا هارمسن ، کنندینوس کاتسیاپیس ، گلن وسون ، Dan Duckworth ، Shishir Birmiwal ، Gal Elidan ، Su Lin Wu ، Jaihui Liu ، Fernando Pereira و Hrishikesh Aradhye برای بسیاری از اصلاحات ، پیشنهادات و نمونه های مفیدی برای این سند. همچنین ، به لطف کریستن لفور ، سودا باسو و کریس برگ که به نسخه قبلی کمک کردند. هرگونه خطا ، حذف و یا (gasp!) عقاید غیرقابل انکار خود من است.

ضمیمه

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

نمای کلی یوتیوب

YouTube یک سرویس ویدیویی جریان است. تیم های صفحه اصلی YouTube Watch Next و YouTube از مدل های ML برای رتبه بندی توصیه های ویدیویی استفاده می کنند. تماشای فیلم های بعدی را برای تماشای بعد از بازی در حال حاضر توصیه می کند ، در حالی که صفحه اصلی فیلم ها را به کاربرانی که در صفحه اصلی مرور می کنند توصیه می کند.

نمای کلی Google Play

Google Play مدل های بسیاری دارد که مشکلات مختلفی را حل می کند. بازی جستجو ، پخش صفحه اصلی توصیه های شخصی ، و برنامه های "کاربران نیز نصب کرده اند" همه از یادگیری ماشین استفاده می کنند.

نمای کلی Google Plus

Google Plus از یادگیری ماشین در موقعیت های مختلف استفاده شده است: رتبه بندی پست ها در "جریان" پست هایی که توسط کاربر دیده می شود ، رتبه بندی پست های "چه داغ" (پست هایی که اکنون بسیار محبوب هستند) ، رتبه بندی افرادی که می شناسید ، و et cetera. Google Plus تمام حساب های شخصی را در سال 2019 تعطیل کرد و در تاریخ 6 ژوئیه 2020 با جریانهای Google برای حساب های تجاری جایگزین شد.