سیستم‌های توصیه‌گر و رتبه‌بندی جستجو در برنامه‌های کاربردی بزرگ‌مقیاس دنیای واقعی - InfoQ

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

مومتا باتاچاریا یک دانشمند ارشد تحقیقاتی در نتفلیکس (Netflix) است، جایی که او بر روی توسعه مدل‌های یادگیری ماشین در مقیاس بزرگ برای سیستم‌های جستجو و توصیه کار می‌کند. قبل از نتفلیکس، او دانشمند ارشد کاربردی در Etsy بود. او به طور فعال به عنوان کمیته برنامه‌ها برای WebConf خدمت کرده است و یک بازبین برای کنفرانس‌هایی مانند RecSys، SIGIR، WebConf، AAAI و مجلات مختلف است.

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

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

انگیزه

فکر می‌کنم این یک راز نیست که بیشتر محصولات، به‌ویژه محصولات B2C، دارای سیستم‌های جستجو و توصیه داخلی هستند. چه خدمات پخش ویدئو مانند نتفلیکس (Netflix)، خدمات پخش موسیقی مانند Spotify، پلتفرم‌های تجارت الکترونیکی مانند Etsy، آمازون (Amazon)، معمولاً دارای نوعی سیستم توصیه و نوعی سیستم جستجو هستند. کاتالوگ‌ها در هر یک از این محصولات همیشه در حال رشد هستند. پایگاه کاربری در حال رشد است. پیچیدگی این مدل‌ها و این معماری و این سیستم‌های کلی همچنان در حال رشد است.

تمام این گفتگو با مثال‌ها سعی در ایجاد انگیزه در مورد آنچه برای ساخت یکی از این سیستم‌های توصیه یا جستجوی بزرگ در مقیاس تولید لازم است، دارد. واقعیت هر یک از محصولات B2C، کسب‌وکار به مشتری، این است که تقریباً شبیه به، اغلب بسته به محصول، می‌تواند ۱۰۰ میلیون کاربر به علاوه وجود داشته باشد، مانند نتفلیکس (Netflix) بیش از ۲۸۰ میلیون کاربر دارد، ۱۰۰ میلیون محصول به علاوه. به طور کلی، رتبه‌بندی برای این تعداد کاربر، این تعداد محصول با تأخیر قابل قبول، تقریباً غیرممکن است. ترفندهایی وجود دارد که ما در صنعت انجام می‌دهیم تا همچنان ارتباط مواردی را که به کاربران خود نشان می‌دهیم حفظ کنیم، اما بتوانیم در زمانی که ارائه خدمات طول می‌کشد واقع‌بین باشیم.

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

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

سپس کل سیستم ارزیابی آفلاین وجود دارد. از چه نوع معیارهایی باید استفاده کنیم؟ آیا باید از معیارهای رتبه‌بندی استفاده کنیم؟ آیا باید از انسان در حلقه، مانند حاشیه‌نویسی انسانی برای ارزیابی کیفیت و غیره استفاده کنیم؟ سپس جنبه تعصبات وجود دارد که وقتی سیستمی را مستقر می‌کنیم، همه کاربران ما نتایج آن سیستم را می‌بینند. یک تعصب انتخابی وجود دارد که در آن حلقه می‌شود. چگونه معمولاً این موضوع را با افزودن برخی از داده‌های اکتشافی برطرف می‌کنیم. چگونه می‌توانیم این داده‌های اکتشافی را تنظیم کنیم در حالی که به عملکرد مدل ضربه نمی‌زنیم؟ سپس یک جزء استنتاج وجود دارد که پس از آموزش مدل، می‌خواهیم آن را مستقر کنیم و سپس استنتاج را در محدوده تأخیر، توان عملیاتی، هزینه محاسباتی، GPU و غیره قابل قبول انجام دهیم؟ در نهایت، هر تجربه‌ای به طور معمول در یک محصول B2C، ما آن را نیز آزمایش A/B می‌کنیم.

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

توصیه: یک مورد استفاده نتفلیکس (Netflix)

اکنون بیایید یک مورد استفاده توصیه از نتفلیکس (Netflix) را در نظر بگیریم. در نتفلیکس (Netflix)، وقتی کاربری وارد نتفلیکس (Netflix) می‌شود، معمولاً چیزهای زیادی برای تماشا وجود دارد و ما اغلب در تحقیقات کاربری خود می‌شنویم، گاهی اوقات احساس غرق شدن می‌کنیم. چگونه چیزی را که می‌خواهم در حال حاضر تماشا کنم پیدا کنم؟ نتفلیکس (Netflix) اغلب توصیه‌های زیادی در صفحه اصلی دارد. فقط احساس غرق شدن می‌کنیم. یکی از رویکردهایی که اعضای ما اتخاذ می‌کنند این است که اغلب به جستجو می‌روند و سپس چیزی را تایپ می‌کنند. به عنوان مثال، در اینجا، یک کمدی استندآپ (stand-up comedy) به من نشان دهید. نتایج حاصل از این سیستم‌های رتبه‌بندی جستجو یا شخصی‌سازی شده‌اند یا فقط مربوط به پرس و جو هستند. فکر می‌کنم ۶۰٪ از کاربران ما در تلویزیون هستند و تایپ پرس و جو هنوز یک کار بسیار خسته‌کننده است. فقط برای ایجاد انگیزه در مورد مورد استفاده جستجو، بیشتر کشف هنوز در صفحه اصلی در نتفلیکس (Netflix) اتفاق می‌افتد، اما ۲۰٪ تا ۳۰٪ از کشف از طریق جستجو اتفاق می‌افتد، که پس از صفحه اصلی دومین مورد است. یک مقاله خوب وجود دارد که در مورد چالش‌های جستجو در زمینه نتفلیکس (Netflix) که در اینجا لینک شده است صحبت می‌کند.

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

بازگشت به جنبه عضوی که از صفحه اصلی به جستجو می‌آید و مجبور است این پرس و جو طولانی را روی یک ریموت تلویزیون تایپ کند، که بسیار خسته‌کننده است. چه می‌شود اگر بتوانیم پیش‌بینی کنیم که عضو قصد جستجو دارد و قبل از اینکه عضو نیاز به شروع تایپ داشته باشد، توصیه‌ها را به‌روزرسانی کنیم؟ به همین دلیل است که این مثال خاص را به عنوان یک مورد استفاده توصیه معرفی می‌کنم، حتی اگر بعد از کلیک بر روی صفحه جستجو باشد. در داخل، ما به آن پیش از پرس و جو (pre-query) اشاره می‌کنیم، اما در صنعت اغلب به عنوان سیستم‌های بدون پرس و جو (no-query systems) نیز از آن یاد می‌شود. این یک بوم توصیه شخصی‌سازی شده است که همچنین در تلاش است تا قصد جستجو را برای یک عضو ثبت کند. در اینجا، بگذارید کمی بیشتر هدف از این بوم را انگیزه دهم. در یک عصر پنج‌شنبه، خانم M در تلاش است تا تصمیم بگیرد که آیا به نتفلیکس (Netflix)، HBO، Hulu و غیره می‌رود.

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

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

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

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

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

در نهایت، این سرور سپس یک تماس بی‌درنگ با سیگنال‌های درون جلسه و همچنین اطلاعات تاریخی به مدل آنلاین برقرار می‌کند که در جایی میزبانی می‌شود. این مدل آنلاین قبلاً آموزش داده شده و میزبانی شده است، اما قادر است این سیگنال‌های بی‌درنگ را برای پیش‌بینی دریافت کند. در نهایت، این مدل سپس یک لیست رتبه‌بندی شده از نتایج را در یک تأخیر بسیار قابل قبول برمی‌گرداند. در این حالت، تأخیر کمتر از ۴۰ میلی‌ثانیه است و در نهایت نتایج را به کلاینت ارسال می‌کند. در این فرآیند، ما همچنین تعامل سرور، تعامل کلاینت را در ورود به سیستم ذخیره می‌کنیم تا آموزش مدل آفلاین در آینده اتفاق بیفتد. یک مقاله در RecSys در مورد این موضوع خاص وجود دارد. اگر علاقه بیشتری دارید، می‌توانید عمیق‌تر بگردید. این معماری کلی است.

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

جالب‌تر این است که پلتفرم‌های مختلف، نمی‌دانم آیا این مورد برای شرکت‌های دیگر هم وجود دارد یا خیر. در این مورد خاص، پلتفرم‌های مختلف الگوهای تماس سرور متفاوتی داشتند. چگونه می‌توانید این الگوهای تماس سرویس را درک کنید و با مهندسان و تیم‌های زیرساخت همکاری کنید تا آن را تغییر دهید و اطمینان حاصل کنید که تأخیر مدل و تأخیر سرتاسری در محدوده قابل قبولی است که عضو متوجه نشود که این همه عمل در چند میلی‌ثانیه انجام می‌شود. البته، SLA توان عملیاتی بسته به پلتفرم، بسته به منطقه و غیره حتی مهم‌تر می‌شود. از آنجایی که ما می‌خواهیم استنتاج بی‌درنگ مطلق را برای ثبت سیگنال‌های مرور درون جلسه کاربر انجام دهیم، مجبور شدیم حافظه پنهان را حذف کنیم. هر نوع حافظه پنهان باید حذف می‌شد یا TTL باید خیلی کاهش می‌یافت. این سه جزء واقعاً کار مانند این را از توصیه‌های سنتی‌تر متمایز می‌کرد که در آن می‌توانید توصیه‌ها را برای یک عضو از قبل واکشی کنید. شما می‌توانید محاسبات آفلاین را انجام دهید.

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

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

این جایی است که قصد کوتاه‌مدت عضو در حال ثبت است، جایی که در زمان واقعی، ما می‌دانیم که آیا عضو در این عنوان یک لیست اضافه کرده است یا این عنوان را لایک کرده است یا برخی از عنوان‌ها را لایک نکرده است. سیگنال منفی نیز فوق‌العاده مهم است. این بلافاصله می‌رود و در طول زمان استنتاج وارد مدل می‌شود و به مدل اجازه می‌دهد تا بین کوتاه‌مدت و بلندمدت معامله کند. ما در اینجا ملاحظات معماری داریم تا بین کوتاه‌مدت و بلندمدت معامله کنیم. متاسفانه، این چیزی است که من نتوانستم در مورد آن صحبت کنم. من فقط این فکر را به شما می‌دهم که مهم است که بین کوتاه‌مدت و بلندمدت در این معماری مدل معامله کنید. به طور کلی، با این بهبود استنتاج بی‌درنگ مطلق و همچنین معماری مدل که سیگنال مرور درون جلسه را در خود جای داده است، ما در حالت آفلاین بیش از ۶٪ بهبود را دیدیم و در حال حاضر ۱۰۰٪ در تولید است. همه کاربران نتفلیکس (Netflix)، وقتی به بوم پیش از پرس و جو (pre-query) می‌روید، این مدلی است که توصیه شما را نشان می‌دهد.

در اینجا یک مثال واقعی وجود دارد. این توصیه اولیه هنگام شروع جلسه کاربر بود. این روی یک کاربر آزمایشی است. سپس عضو رفت و دسته‌ای از مرورها را در صفحه اصلی انجام داد و مرورهایی را در نمایش‌ها و فیلم‌های نقش اصلی زن انجام داد. سپس آنها به صفحه بدون پرس و جو (no-query) یا پیش از پرس و جو (pre-query) بازگشتند و توصیه آنها بلافاصله در آن جلسه به‌روزرسانی شد تا نمایش‌هایی مانند Emily in Paris، New Girl و غیره داشته باشد که دارای شخصیت اصلی زن هستند. سپس آنها دوباره به صفحه دسته‌بندی یا صفحه اصلی بازگشتند و برخی از نمایش‌های مربوط به آشپزی یا پخت را انجام دادند. در نهایت، در همان جلسه، وقتی به صفحه جستجو بازگشتند، توصیه آنها بلافاصله تغییر کرد. می‌توانید ببینید که ترکیبی از هر سه است. فقط همه چیز را به هم نزنید تا نمایش پخت باشد یا چیزی شبیه به آن. این جایی است که معامله بین ترجیح کوتاه‌مدت و بلندمدت وارد بازی می‌شود. شما می‌خواهید آنچه را که عضو در جلسه انجام می‌دهد ثبت کنید، اما نمی‌خواهید کل توصیه را فقط با آن قصد کوتاه‌مدت تحت تأثیر قرار دهید.

چالش‌ها و ملاحظات دیگر

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

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

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

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

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

خلاصه نکات

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