رتبه‌بندی تبلیغات در Pinterest چطور کار می‌کند؟

نکات کلیدی

• الگوریتم‌های یادگیری ماشین مبتنی بر یادگیری عمیق برای ارائه‌ی پیشنهادهای تبلیغاتی پاسخ‌گو و شخصی‌سازی‌شده به کار گرفته می‌شوند.

• هدف پلتفرم تبلیغاتی این است که در بلندمدت، ارزش را برای کاربران، تبلیغ‌دهندگان و خود پلتفرم به حداکثر برساند.

• قیف تحویل تبلیغات (Ads Delivery Funnel) شامل بازیابی کاندیداها، رتبه‌بندی سنگین (heavyweight ranking)، حراج (auction) و تخصیص (allocation) است تا سرویس‌دهی با تأخیر کم در QPS بالا تضمین شود.

• Pinterest در گذر زمان مدل‌های یادگیری ماشین خود را از رویکردهای سنتی به مدل‌های پیچیده‌تر مثل شبکه‌های عصبی عمیق (DNN) و معماری‌های ترنسفورمر ارتقا داده است که شخصی‌سازی را تقویت می‌کند.

• شیوه‌های قدرتمند MLOps مثل یکپارچه‌سازی و استقرار پیوسته (CI/CD)، نسخه‌بندی مدل، تست و مانیتورینگ، برای تکرار سریع و مؤثر حیاتی هستند.

Aayush Mudgal، مهندس ارشد یادگیری ماشین (Staff Machine Learning Engineer) در Pinterest، در QCon San Francisco 2023 جلسه‌ای با عنوان «بازکردن اینکه رتبه‌بندی تبلیغات در Pinterest چطور کار می‌کند» ارائه داد. در این جلسه، او توضیح داد Pinterest چگونه از یادگیری عمیق و داده‌های عظیم برای ارائه‌ی تبلیغات مرتبط به کاربران استفاده می‌کند.

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

در سخنرانی‌اش، Mudgal روی یک بخش از تجربه تمرکز کرد: نمایش (سروکردن) تبلیغات. او با جزئیات توضیح داد که یادگیری ماشین چگونه برای سروکردن تبلیغات در مقیاس بزرگ به کار می‌رود. سپس درباره‌ی بازارگاه‌های تبلیغاتی و قیف تحویل تبلیغ صحبت کرد و اجزای معمول معماری سرو تبلیغ را مرور کرد و وارد دو مسئله‌ی اصلی شد: بازیابی تبلیغات (ads retrieval) و رتبه‌بندی (ranking). در نهایت، او درباره‌ی مانیتورکردن سلامت سیستم در زمان آموزش مدل صحبت کرد و با برخی چالش‌ها و راه‌حل‌ها برای سرو مدل‌های بزرگ جمع‌بندی کرد.

پیشنهاد محتوا 

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

در عوض، پلتفرم به سیستمی نیاز دارد که بتواند این احتمال را سریع پیش‌بینی کند: در حد صدها میلی‌ثانیه. همچنین باید QPS (تعداد درخواست در ثانیه) بالا را مدیریت کند. در نهایت باید نسبت به تغییر علایق کاربران در طول زمان پاسخ‌گو باشد. برای ثبت همه‌ی این ظرافت‌ها، پلتفرم‌ها باید مطمئن شوند سیستم پیشنهاددهی یک مسئله‌ی بهینه‌سازی چندهدفه (multi-objective optimization) را حل می‌کند.

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

این یک بازار دوطرفه است. پلتفرم‌های تبلیغاتی مثل Pinterest، Meta، Google کمک می‌کنند کاربران با تبلیغ‌دهندگان و محتوای مرتبط ارتباط پیدا کنند. کاربران به پلتفرم می‌آیند تا با محتوا تعامل کنند. تبلیغ‌دهندگان به این پلتفرم‌ها پول می‌دهند تا محتوایشان نمایش داده شود و کاربران با آن درگیر شوند. پلتفرم‌ها می‌خواهند ارزش را برای کاربران، تبلیغ‌دهندگان و خود پلتفرم بیشینه کنند.

بازارگاه‌های تبلیغاتی

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

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

بعد از آن، تبلیغ‌دهندگان محتوای خلاقه یا تصویرشان را هم انتخاب می‌کنند. قبل از نمایش خلاقه، پلتفرم تبلیغاتی باید مشخص کند «نمره احتمال خوب» برای تصمیم‌گیری درباره نمایش این محتوا به یک کاربر چیست. این می‌تواند به‌صورت پیش‌بینی کلیک تعریف شود: با داشتن یک کاربر و مسیر/سفر او در پلتفرم، احتمال اینکه این کاربر روی محتوا کلیک کند چقدر است؟

اما بیشینه‌کردن کلیک‌ها ممکن است بهترین ارتباط را روی پلتفرم ایجاد نکند: ممکن است محتوای اسپمی را ترویج کند. پلتفرم‌ها گاهی پیش‌بینی‌های سایه (shadow predictions) هم دارند مثل «کلیک‌های خوب»، پنهان‌کردن، ذخیره یا بازنشر که تلاش می‌کند مسیر کاربر را به شکل جامع‌تری ثبت کند. در بعضی پلتفرم‌ها ممکن است اهداف تبلیغاتی بیشتری مثل بهینه‌سازی تبدیل هم وجود داشته باشد که تلاش می‌کند فروش بیشتری در وب‌سایت تبلیغ‌دهنده ایجاد کند؛ این سخت است چون تبدیل خارج از پلتفرم اتفاق می‌افتد.

همچنین فرض کنید پلتفرم بخواهد سیستم را به انواع محتوای بیشتری مثل ویدئو و کالکشن‌ها گسترش بدهد. نه‌تنها باید پیش‌بینی‌هایی که اینجا گفته شد را انجام دهد، بلکه باید بفهمد «یک مشاهده خوب ویدئو» در پلتفرم یعنی چه.

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

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

زیرساخت سرو تبلیغات

Mudgal سپس یک نمای کلی سطح بالا از زیرساخت سرو تبلیغات در Pinterest ارائه داد. وقتی یک کاربر با پلتفرم تعامل می‌کند، پلتفرم باید محتوایی را که می‌خواهد به کاربر نشان بدهد واکشی کند. درخواست کاربر از طریق یک load balancer به یک app server وارد می‌شود. سپس به یک ad server ارسال می‌شود که تبلیغاتی را برمی‌گرداند که داخل فید کاربر درج می‌شوند.

شکل ۱: نمای کلی سطح بالا از زیرساخت سرو تبلیغات

ad server باید این کار را با تأخیر بسیار کم انجام دهد، چیزی حدود صدها میلی‌ثانیه از ابتدا تا انتها. ورودی ad server معمولاً نسبتاً کم‌اطلاعات (sparse) است: مثلاً یک user ID، ip address کاربر، و زمان روز.

اولین کار این است که ویژگی‌ها برای این کاربر بازیابی شود. این می‌تواند چیزهایی مثل موقعیت کاربر از روی IP، یا اینکه این کاربر در گذشته چگونه در پلتفرم تعامل کرده را شامل شود. این‌ها معمولاً از یک key-value store گرفته می‌شوند که کلیدش user ID و مقدارها ویژگی‌ها هستند.

وقتی سیستم فضای ویژگی‌ها را غنی‌سازی کرد، این‌ها به مرحله‌ی بازیابی کاندیدا می‌روند؛ مرحله‌ای که تلاش می‌کند از بین میلیاردها آیتم محتوا، بهترین مجموعه کاندیدا را جدا کند و به صدها یا هزاران کاندیدا برسد که می‌توانند به کاربر نمایش داده شوند. سپس این‌ها به یک سرویس رتبه‌بندی (ranking service) ارسال می‌شوند که با مدل‌های سنگین‌تر احتمال تعامل کاربر با محتوا را روی چند هدف پیش‌بینی می‌کند (کلیک، کلیک خوب، ذخیره، بازنشر، پنهان‌کردن).

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

در عوض، این ویژگی‌ها از طریق یک کش محلی in-memory (مثل leveldb) واکشی می‌شوند و برای بیشینه‌کردن cache hit ممکن است از یک لایه‌ی routing خارجی استفاده شود. در نهایت سرویس رتبه‌بندی تبلیغات را به ad server برمی‌گرداند.

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

از ad server، محتوای تبلیغ برگردانده می‌شود و در فید کاربر درج می‌شود. وقتی کاربر با فید تعامل می‌کند، یک سرویس event logging وجود دارد که می‌تواند از Apache Kafka برای ثبت لحظه‌ای همه‌ی این رویدادها استفاده کند. این سرویس بسیار مهم است چون اگر کاربر با تبلیغ تعامل کند یا روی آن کلیک کند، تبلیغ‌دهندگان باید صورتحساب شوند.

علاوه بر این، تبلیغ‌دهندگان باید در زمان واقعی صورتحساب شوند چون آن‌ها سقف بودجه روزانه دارند. اگر پایپ‌لاین لاگ‌برداری عملکرد real-time نداشته باشد، پلتفرم ممکن است از بودجه تبلیغ‌دهنده عبور کند یا نمایش‌های رایگان به تبلیغ‌دهنده بدهد.

پایپ‌لاین event logging همچنین به یک سیستم گزارش‌دهی تغذیه می‌دهد که شامل مانیتورینگ ساعتی یا روزانه است. این سیستم گزارش‌دهی به ویژگی‌های ثبت‌شده هم وصل است، چون پلتفرم‌ها می‌خواهند به تبلیغ‌دهندگان داده‌های عملکرد تبلیغ را نسبت به ویژگی‌هایی مثل کشور، سن یا سایر ویژگی‌ها نشان بدهند. در نهایت، سرویس event logging و feature logger با هم داده‌های آموزشی همه‌ی مدل‌های یادگیری ماشین Pinterest را تشکیل می‌دهند.

قیف تحویل تبلیغات

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

شکل ۲: قیف تحویل تبلیغات

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

بازیابی تبلیغات 

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

یادتان باشد ورودی این سیستم user ID و content ID و ویژگی‌های سطح درخواست است. بازیابی به غنی‌سازی سیگنال نیاز دارد که از چند expander مبتنی بر گراف استفاده می‌کند تا ویژگی‌های اضافی را از key-value feature storeها واکشی کند. مثلاً: یک user ID به ویژگی‌هایی مثل سن، موقعیت، جنسیت، نرخ‌های تعامل قبلی نگاشت می‌شود. به همین شکل، content ID به ویژگی‌های محتوا نگاشت می‌شود که برای کاهش محاسبات و بهبود تأخیر آنلاین از قبل در پایپ‌لاین محاسبه شده‌اند.

شکل ۳: غنی‌سازی سیگنال (Signal Enrichment)

بازیابی یک رویکرد scatter-gather است که چندین مؤلفه را فراخوانی می‌کند. اولی یک فیلتر سبک امتیازدهی (scoring) و هدف‌گیری (targeting) است. Scoring تخمین می‌زند محتوا چقدر ارزشمند است با استفاده از مدل‌های خیلی ساده. Targeting تبلیغات را به زیرمجموعه‌های مشخصی از کاربران محدود می‌کند، بر اساس معیارهایی که تبلیغ‌دهندگان انتخاب کرده‌اند: مثلاً هدف‌گیری تبلیغ بر اساس موقعیت کاربر.

شکل ۴: کوئری استاندارد در زمان بازیابی – Scatter Gather

مرحله بعد درباره بودجه‌بندی و pacing است. اگر یک تبلیغ تمام بودجه‌اش را خرج کرده باشد، نباید بازیابی شود. Pacing مفهوم مرتبطی است: روشی برای پخش‌کردن هزینه تبلیغ در طول زمان. مثلاً اگر تبلیغ بودجه ۱۰۰ دلاری دارد، تبلیغ‌دهنده نمی‌خواهد این ۱۰۰ دلار را در یک ساعت اول خرج کند، چون ممکن است بهترین ارزش را ندهد. پلتفرم‌های تبلیغاتی معمولاً pacing را با الگوهای روزانه ترافیک در پلتفرم هماهنگ می‌کنند.

برای اینکه تنوع تبلیغات حفظ شود، deduping تعداد تبلیغاتی که یک تبلیغ‌دهنده می‌تواند وارد کند را محدود می‌کند: پلتفرم نباید فید را فقط با تبلیغات یک تبلیغ‌دهنده خفه کند. مثلاً فقط top-K کاندیدا برای هر تبلیغ‌دهنده اجازه دارند به مرحله بعد بروند. در نهایت، چون این یک scatter-gather است، ممکن است منابع بازیابی مختلف وجود داشته باشد که نتایج‌شان باید قبل از ارسال به مراحل بعدی با هم ترکیب (blend) شود.

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

در سال ۲۰۱۶، YouTube یک مقاله اثرگذار منتشر کرد که نحوه کار این سیستم‌های بازیابی را تغییر داد، با معرفی Two-Tower Deep Neural Networks. ایده این است که نمایش‌های نهفته از کاربران و محتوا را بر اساس ویژگی‌هایشان یاد بگیرد. این نمایش‌ها و ویژگی‌ها در مدل از هم جدا نگه داشته می‌شوند. اما در نهایت، اگر کاربر با یک آیتم محتوا تعامل داشته باشد، آن نمایش‌ها باید خیلی نزدیک به هم باشند و هدف آموزشی مدل هم همین است.

شکل ۵: Two-Tower DNN

مزیت این مدل این است که embedding تبلیغات می‌تواند از قبل محاسبه شود، کش شود و به صورت آفلاین ایندکس شود. دیتابیس تبلیغات با عبور دادن هر تبلیغ از «برج تبلیغ» مدل، embedding آن را تولید می‌کند و یک ایندکس می‌سازد. وقتی تبلیغ در زمان سرو ایندکس شد، سرور بازیابی فقط لازم است بخش کاربر مدل را اجرا کند و سپس از الگوریتم‌های approximate nearest neighbor مثل HNSW استفاده کند تا تبلیغات مرتبط را در ایندکس دیتابیس تبلیغات پیدا کند.

شکل ۶: استقرار مدل Two Tower (Two Tower Model Deployment)

مدل رتبه‌بندی

بعد نوبت مدل رتبه‌بندی است. از ۲۰۱۴، مدل‌ها ساده بودند مثل رگرسیون لجستیک (logistic regression). مرحله بعد در این تکامل برای اینکه مدل‌ها بیان‌گرتر شوند این بود که Pinterest از راه‌حل‌های ساده به مدل‌های پیچیده‌تر مثل GBDT به‌اضافه رگرسیون لجستیک حرکت کرد.

مدل می‌تواند چهار نوع ویژگی داشته باشد: ویژگی‌های کاربر؛ ویژگی‌های محتوا؛ تعامل بین کاربر و محتوا در تاریخچه؛ و در نهایت، رخدادهایی که در زمان همین نمایش اتفاق می‌افتند. مدل‌ها باید برخی تعاملات غیرخطی بین این ویژگی‌ها را یاد بگیرند و GBDTها در این خوب هستند. همچنین مدل چارچوب رگرسیون لجستیک را نگه می‌دارد که یک مدل خطی است و ویژگی‌های با کاردینالیتی بالا را ثبت می‌کند. توجه کنید که GBDTها با چنین ویژگی‌هایی خوب نیستند.

شکل ۷: مدل‌های Ensemble از نوع GBDT + Logistic Regression

خیلی زود، Pinterest حدود ۶۰ مدل در تولید داشت. مدل‌ها رشد می‌کردند و محصول هم رشد می‌کرد. نگهداری این همه مدل پیچیده شد و چرخه‌های طولانی برای پذیرش یا حذف ویژگی‌ها ایجاد شد که منجر به سیستم‌های غیربهینه می‌شد.

همچنین در همان زمان، سیستم‌های یادگیری ماشین به راحتی از سرو مدل پشتیبانی نمی‌کردند. Pinterest برای آموزش مدل‌ها از یک زبان یا فریم‌ورک متفاوت نسبت به سروکردن استفاده می‌کرد. مثلاً Pinterest با XGBoost آموزش می‌داد، بعد آن را به مدل TensorFlow ترجمه می‌کرد، بعد به C++ (زبان سرو در Pinterest) ترجمه می‌کرد. این رفت‌وبرگشت‌ها در سیستم باعث غیربهینگی و چرخه‌های طولانی‌تر برای توسعه ویژگی‌های جدید می‌شد.

در نهایت، گروه‌های تبلیغ مدام ساخته یا حذف می‌شدند: شاید یک تبلیغ فقط یک یا دو ماه «زنده» باشد. Pinterest نیاز داشت مدل‌ها پاسخ‌گو باشند تا بتوانند روی توزیع‌های داده جدیدی که وارد می‌شوند به شکل افزایشی‌تر آموزش ببینند. اما مدل‌های GBDT ایستا هستند: راهی برای آموزش افزایشی وجود ندارد. شبکه‌های عصبی عمیق (DNN) در مقابل، قابلیت آموزش افزایشی دارند.

مرحله بعدی جایگزین‌کردن GBDT با رویکردهای DNN بود. DNN مزایای زیادی دارد اما مدل‌های پیچیده‌تری هستند. یکی از تغییرهای مهم این بود که الگوریتم‌های یادگیری ماشین سنتی بیشتر به feature engineering دستی تکیه می‌کردند، جایی که مهندسان تعیین می‌کردند کدام دو ویژگی ممکن است مرتبط باشند. مدل‌ها ذاتاً نمی‌توانستند تعاملات ویژگی را خودشان یاد بگیرند. در معماری‌های DNN، مدل می‌تواند این تعامل‌ها را یاد بگیرد.

بیشتر مدل‌های پیشنهاددهی در صنعت معماری چندلایه مشابهی دارند. اول لایه نمایش است، جایی که پلتفرم‌ها ویژگی‌ها را تعریف می‌کنند و اینکه مدل چطور آن‌ها را بفهمد. در این سناریو، برای DNNها پردازش ویژگی خیلی مهم است. اگر مقیاس ویژگی‌ها بین ویژگی‌های مختلف متفاوت باشد، مدل می‌تواند خراب شود؛ پس این لایه شامل منطق برای squashing یا clipping مقادیر، یا نوعی نرمال‌سازی ویژگی‌ها است.

شکل ۸: معماری AutoML در Pinterest

بعد اگر دو ویژگی به هم مرتبط باشند، مدل می‌تواند آن‌ها را با هم خلاصه کند و یک embedding مشترک یاد بگیرد. بعد از آن لایه‌های cross ضربی می‌آیند که تعاملات ویژگی را یاد می‌گیرند، و سپس لایه‌های fully-connected.

یکی دیگر از مزایای DNNها یادگیری چندوظیفه‌ای روی اهداف مختلف است. وزن‌های شبکه بین اهداف مختلف مثل کلیک، repin یا هر معیار دیگر در پلتفرم مشترک است و نیاز به آموزش مدل‌های جداگانه برای هر هدف را از بین می‌برد.

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

برای پیاده‌سازی این، Pinterest به معماری Transformer DNN روی آورد. ترنسفورمرها می‌توانند اطلاعات بسیار قدرتمندی درباره تعاملات ویژگی‌ها رمزگذاری کنند. یک پارامتر کلیدی مدل، حداکثر طول دنباله است. با افزایش طول دنباله، اندازه مدل به صورت مربعی رشد می‌کند، که روی ظرفیت سرو اثر می‌گذارد.

افزایش طول دنباله به مثلاً ۱۰۰ رویداد باعث می‌شود ویژگی‌های پیچیده‌ای که گفته شد عملی نباشند. به جای آن، مدل از ویژگی‌های ساده استفاده می‌کند مثل: آن عمل چیست؟ کاربر کلیک کرد یا نه؟ ویژگی‌های خیلی ساده، اما دنباله طولانی‌تر به مدل ظرفیت بهتری می‌دهد.

جدیدترین معماری مدل برای نمایش کاربر به صورت آفلاین در Pinterest بر پایه یک Transformer encoder به نام PinnerFormer است. این مؤلفه ورودی‌هایی از تعاملات گذشته کاربر می‌گیرد: مثلاً از دیروز تا یک سال قبل. همه این تعاملات به صورت آفلاین رمزگذاری می‌شوند تا برای هر کاربر یک embedding یاد گرفته شود، که سپس می‌تواند به عنوان ورودی ویژگی برای یک مدل DNN پایین‌دستی استفاده شود.

شکل ۹: PinnerFormer: مدل‌سازی دنباله برای نمایش کاربر در Pinterest 

یک ورودی دیگر به آن مدل، دنباله‌ی بلادرنگ (real-time) است که از تعاملات فعلی کاربر می‌آید. ترکیب این دو می‌تواند یاد بگیرد کاربر در پلتفرم چه می‌کند. استفاده از این دنباله‌ها، با الهام از حوزه NLP، چیزی است که سیستم پیشنهاددهی Pinterest را تغذیه می‌کند.

شکل ۱۰: ترکیب دنباله‌های بلند (Combining Long Sequences)

MLOps در Pinterest

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

در گذشته، هر تیم در Pinterest پایپ‌لاین‌های متفاوتی داشت: همه داشتند چرخ یکسان را دوباره طراحی می‌کردند. Pinterest باید این را به شکل مقیاس‌پذیرتری انجام می‌داد. همین‌جا بود که بیشتر iterationها در سال گذشته اتفاق افتاد. Pinterest یک چارچوب یکپارچه ML مبتنی بر PyTorch (به نام MLEnv) ساخت که Docker imageها و سرویس‌های CI/CD سنتی فراهم می‌کند. بخشی که کاربر کد می‌نویسد بسیار کوچک است و ادغام بین مؤلفه‌های مختلف MLOps به صورت یکپارچه از طریق راه‌حل‌های مبتنی بر API انجام می‌شود که به تیم‌ها اجازه می‌دهد سریع‌تر iteration کنند.

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

تست و مانیتورینگ 

اولین گام تست، تست یکپارچگی است. وقتی تغییر کد نوشته می‌شود، Pinterest می‌تواند آن را در محیط production از طریق shadow traffic تست کند تا ببیند اگر این تغییر مستقر شود چه اتفاقی می‌افتد. ثبت خودکار متریک‌ها تضمین می‌کند چیزی در فرایند تست جا نماند. همچنین یک سیستم دیباگ وجود دارد که می‌تواند بازپخش کند یک درخواست مشخص چگونه به نظر می‌رسد با توجه به سرو یک نسخه مشخص از مدل.

گام بعدی درباره این است که کد بعد از merge شدن چگونه منتشر می‌شود. Pinterest فرایند استاندارد canary، staging و production را دنبال می‌کند. هر کدام از این مراحل متریک‌های real-time که برای کسب‌وکار مهم است را مانیتور می‌کند. اگر انحراف روزبه‌روز یا انحراف بین production و یک محیط دیگر وجود داشته باشد، استقرار متوقف می‌شود و به شکل یکپارچه rollback می‌شود.

در نهایت، با وجود همه این حفاظ‌ها، هنوز ممکن است باگ‌ها عبور کنند. همچنین تبلیغ‌دهندگان ممکن است رفتارهای متفاوتی داشته باشند. پس Pinterest مانیتورینگ real-time دارد که الگوهای روزبه‌روز و هفته‌به‌هفته را در سیستم روی ابعاد مختلف ثبت می‌کند، که می‌تواند درآمد، نرخ درج و QPS باشد.

اعتبارسنجی و مانیتورینگ گردش‌کار ML

علاوه بر مانیتورکردن متریک‌های production، گردش‌کارهای ML نیازهای مانیتورینگ اضافی دارند. اولین مرحله نگاه‌کردن به دیتاست‌های آموزشی است که وارد مدل می‌شوند و تعریف پوشش و هشداردهی روی آن‌ها. مثلاً مانیتورکردن ویژگی‌ها و تغییرشان در طول زمان و مطمئن‌شدن از تازه‌بودن ویژگی‌ها.

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

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

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

سرو مدل‌های بزرگ

یک هدف دیگر این است که مطمئن شویم زیرساخت سرو تأخیر پایینی دارد، که به Pinterest اجازه می‌دهد تبلیغات بیشتری را اسکور کند. یک راه برای بهبود تأخیر این است که اگر مدل‌ها پیچیده‌تر هستند به سرو روی GPU مهاجرت کنیم. اگر این گزینه نباشد، تکنیک‌های بهینه‌سازی وجود دارد مثل quantization مدل‌ها یا knowledge distillation برای بهبود تأخیر، معمولاً با هزینه کاهش دقت inference.

جمع‌بندی 

Mudgal یک نمای کلی از سیستم سرو تبلیغات Pinterest و اینکه چطور از ML در مقیاس بزرگ در production استفاده می‌کنند ارائه کرد. او همچنین توضیح داد Pinterest چطور مدل‌هایش را قبل و بعد از استقرار در production مانیتور و تست می‌کند. Mudgal چندین بینش ارائه داد که مخاطبان می‌توانند برای سیستم‌های خودشان به کار بگیرند تا با چالش‌های مشابه مقابله کنند.