در این مقاله به بررسی دقیق نحوه کارکرد الگوریتم تویتر و سیستم پیشنهاد محتوا در بخش فور یو میپردازیم تا به رشد پیج شما کمک کند.
الگوریتم X یا همان توییتر سابق، بسیار پیچیدهتر از این تصور ساده است که «هر پستی لایک بیشتری داشته باشد، بیشتر دیده میشود».
با بررسی معماری منتشرشده از سیستم پیشنهاد محتوای X میتوان دید که For You از چند مرحله مختلف تشکیل شده است؛ از پیدا کردن پستهای مناسب گرفته تا پیشبینی رفتار کاربر، امتیازدهی، کنترل تنوع محتوا و در نهایت بررسی محدودیتهای Visibility.
نکته مهم این است که X الزاماً به دنبال پیدا کردن محبوبترین پست موجود نیست.
هدف اصلی سیستم این است که تشخیص دهد:
از میان پستهای موجود، کدام محتوا در این لحظه برای این کاربر مشخص مناسبتر است؟
به همین دلیل ممکن است یک پست برای یک کاربر در ابتدای For You ظاهر شود اما همان پست برای شخص دیگری اصلاً نمایش داده نشود.
در ادامه مرحلهبهمرحله بررسی میکنیم که این سیستم چگونه کار میکند.
یکی از مهمترین بخشهای سیستم پیشنهاد محتوا، پیشبینی رفتار احتمالی کاربر است.
به جای اینکه فقط تعداد لایک یا Repost یک پست بررسی شود، مدل تلاش میکند تخمین بزند اگر پست به یک کاربر مشخص نمایش داده شود، احتمال انجام رفتارهای مختلف چقدر است.
برای مثال:
در نتیجه هر پست لزوماً یک امتیاز ثابت ندارد.
ارزش یک پست میتواند برای کاربران مختلف متفاوت باشد.
فرآیند نمایش یک پست در For You را میتوان به شکل ساده اینطور تصور کرد:
کاربر
↓
بررسی رفتارها و علایق قبلی
↓
پیدا کردن پستهای کاندید
↓
حذف گزینههای نامناسب
↓
پیشبینی واکنش کاربر
↓
رتبهبندی پستها
↓
اعمال محدودیتهای تنوع
↓
Visibility Filtering
↓
نمایش در For You
بنابراین قبل از اینکه یک پست در Feed ظاهر شود، چند مرحله مختلف روی آن انجام میشود.
اولین مرحله مهم Candidate Generation است.
تعداد پستهایی که در X منتشر میشوند بسیار زیاد است.
سیستم نمیتواند برای ساخت Feed هر کاربر، تمام پستهای موجود را تکتک بررسی و رتبهبندی کند.
به همین دلیل ابتدا یک مجموعه محدودتر از پستها انتخاب میشود.
به این پستها Candidate گفته میشود.
Candidate Generation در واقع مرحلهای است که سیستم میپرسد:
چه پستهایی اصلاً ارزش دارند وارد مرحله بررسی و رتبهبندی شوند؟
کاندیدها بهطور کلی میتوانند از دو منبع اصلی وارد شوند:
بخش دوم برای سیستم For You اهمیت بسیار زیادی دارد.
یکی از نامهایی که در معماری X دیده میشود Thunder است.
Thunder به بخشی از سیستم مربوط میشود که محتوای حسابهایی را پیدا میکند که کاربر از قبل آنها را Follow کرده است.
فرض کنید یک کاربر ۵۰۰ حساب را دنبال میکند.
تمام پستهای این ۵۰۰ حساب نمیتوانند همزمان وارد Feed شوند.
Thunder کمک میکند از میان محتوای منتشرشده توسط این حسابها، گزینههای مناسبتری بهعنوان Candidate انتخاب شوند.
به زبان ساده میتوان گفت:
Thunder
=
محتوای داخل شبکه Followهای کاربر
اما For You فقط بر اساس حسابهای Followشده ساخته نمیشود.
بخش مهمتر ماجرا زمانی شروع میشود که X میخواهد محتوایی را از حسابهایی پیدا کند که کاربر هنوز آنها را دنبال نمیکند.
یکی از مهمترین بخشهایی که در سیستم پیشنهاد محتوای X دیده میشود Phoenix است.
Phoenix در دو مرحله مهم نقش دارد:
هدف آن این است که از روی رفتارهای قبلی یک کاربر تشخیص دهد احتمالاً چه نوع محتوایی برای او جذاب خواهد بود.
برای این کار رفتارهای مختلف کاربر میتوانند مورد توجه قرار بگیرند؛ برای مثال:
این اطلاعات کمک میکنند یک نمایش عددی از علایق کاربر ساخته شود.
در سیستمهای یادگیری ماشین نمیتوان مفاهیمی مثل «علاقه به برنامهنویسی» یا «علاقه به هوش مصنوعی» را مستقیماً به مدل داد.
برای همین اطلاعات به مجموعهای از اعداد تبدیل میشوند.
به این نمایش عددی Embedding گفته میشود.
برای مثال ممکن است رفتار یک کاربر نشان دهد که بیشتر با محتواهای مربوط به این موضوعات تعامل دارد:
Python
Linux
Docker
AI
Backend
مدل این الگوی رفتاری را به یک بردار عددی تبدیل میکند.
از طرف دیگر خود پستها نیز میتوانند Embedding مخصوص به خود را داشته باشند.
در نتیجه سیستم میتواند بررسی کند که Embedding یک پست تا چه اندازه به Embedding علایق کاربر نزدیک است.
در بخش Retrieval مربوط به Phoenix از معماریای به نام Two-Tower استفاده میشود.
Two-Tower یکی از ساختارهای رایج در سیستمهای Recommendation است.
در این روش دو بخش وجود دارد.
یک بخش اطلاعات مربوط به کاربر را تبدیل به یک بردار میکند:
User
↓
User Embedding
بخش دیگر اطلاعات مربوط به محتوا را تبدیل به بردار میکند:
Post
↓
Post Embedding
سپس شباهت میان این دو بررسی میشود.
User Embedding
↓
Similarity
↑
Post Embedding
اگر دو بردار به یکدیگر نزدیک باشند، احتمال اینکه محتوا برای آن کاربر مناسب باشد بیشتر میشود.
این سیستم یکی از دلایلی است که ممکن است در For You پستی از یک حساب کاملاً ناشناس ببینید.
یکی دیگر از بخشهای جالب معماری X، SimClusters است.
ایده اصلی SimClusters بسیار ساده است:
کاربرانی که با محتواهای مشابه تعامل دارند، احتمالاً علایق مشترکی هم دارند.
برای مثال تصور کنید تعداد زیادی از کاربران به صورت مرتب با محتواهای مربوط به موارد زیر تعامل داشته باشند:
Python
Linux
Docker
AI
Backend
سیستم میتواند این کاربران را به عنوان یک خوشه رفتاری در نظر بگیرد.
اگر کاربر دیگری نیز رفتار مشابهی داشته باشد، احتمال بیشتری وجود دارد که محتواهای محبوب این Cluster به او پیشنهاد شوند.
در واقع الگوریتم فقط بررسی نمیکند شما چه کسانی را Follow کردهاید.
بلکه سعی میکند تشخیص دهد از نظر رفتاری به چه گروههایی از کاربران نزدیکتر هستید.
از این ساختار میتوان یک نتیجه مهم برای تولیدکنندگان محتوا گرفت.
اگر یک حساب بیشتر درباره چند موضوع مرتبط محتوا منتشر کند، الگوریتم احتمالاً راحتتر میتواند تشخیص دهد محتوای آن برای چه گروهی مناسب است.
برای مثال حسابی که معمولاً درباره:
محتوا منتشر میکند، هویت موضوعی مشخصتری نسبت به حسابی دارد که هر روز درباره یک موضوع کاملاً متفاوت صحبت میکند.
این موضوع به سیستم کمک میکند حساب را بهتر به Cluster مناسب مرتبط کند.
بعد از Candidate Generation ممکن است صدها یا حتی هزاران پست برای یک کاربر پیدا شده باشند.
در این مرحله سیستم باید تصمیم بگیرد:
کدام پستها باید بالاتر نمایش داده شوند؟
اینجا مرحله Ranking وارد میشود.
Phoenix برای هر پست احتمال چند رفتار مختلف را محاسبه میکند.
مثلاً:
P(Like)
P(Reply)
P(Repost)
P(Share)
P(Follow)
P(Block)
P(Report)
حرف P در اینجا مخفف Probability یا احتمال است.
برای مثال:
P(Reply) = 0.18
یعنی مدل تخمین میزند که احتمال Reply کردن این کاربر به این پست حدود ۱۸ درصد است.
بعد از پیشبینی احتمال رفتارهای مختلف، برای هر رفتار یک Weight یا وزن در نظر گرفته میشود.
فرمول سادهشده میتواند چیزی شبیه این باشد:
Score =
P(Like) × LikeWeight
+
P(Reply) × ReplyWeight
+
P(Share) × ShareWeight
+
P(Follow) × FollowWeight
-
P(Report) × ReportWeight
در سیستم واقعی Signalهای بیشتری وجود دارند، اما منطق کلی همین است.
یعنی مدل ترکیبی از احتمال رفتارهای مثبت و منفی را بررسی میکند و در نهایت یک Score برای محتوا میسازد.
خیر.
یکی از نکات قابل توجه در تنظیمات منتشرشده این است که رفتارهای مختلف وزن یکسانی ندارند.
نمونهای از وزنهای مشاهدهشده:
| رفتار | وزن |
|---|---|
| Like | +0.5 |
| Reply | +5 |
| Repost | +1 |
| Share | +2 |
| ارسال در DM | +5 |
| Copy Link | +20 |
| Quote | +5 |
| Follow Author | +4 |
| Click | +0.4 |
| Open Link | +0.2 |
سیگنالهای منفی نیز وزنهای قابل توجهی دارند:
| رفتار منفی | وزن |
|---|---|
| Not Interested | -43.2 |
| Block | -31.2 |
| Mute | -58.8 |
| Report | -234 |
این اعداد نشان میدهند سیستم رفتارهای مختلف را یکسان ارزیابی نمیکند.
اما باید در تفسیر آنها دقت کرد.
با دیدن وزنها ممکن است این نتیجه گرفته شود:
Like = 0.5
Reply = 5
پس:
1 Reply = 10 Likes
اما این نتیجه درست نیست.
دلیل آن این است که Weight مستقیماً در تعداد واقعی Like یا Reply ضرب نمیشود.
سیستم ابتدا احتمال انجام هر رفتار توسط یک کاربر مشخص را پیشبینی میکند.
مثلاً:
احتمال Like × 0.5
+
احتمال Reply × 5
+
احتمال Follow × 4
-
احتمال Report × 234
بنابراین این اعداد باید به عنوان وزن متغیرهای یک مدل Ranking در نظر گرفته شوند، نه جدول تبدیل Like به Reply.
یکی از موارد جالب در وزنهای منتشرشده، مقدار بالای Copy Link است.
در نگاه اول ممکن است عجیب به نظر برسد که Copy کردن لینک از Like وزن بیشتری داشته باشد.
اما از نظر رفتار کاربر، این موضوع قابل توضیح است.
Like یک رفتار بسیار ساده است.
کاربر فقط روی یک دکمه کلیک میکند.
اما وقتی کاربری لینک یک پست را Copy میکند، احتمالاً قصد دیگری دارد.
مثلاً ممکن است بخواهد:
در نتیجه Copy Link میتواند Signal قویتری درباره ارزش محتوا باشد.
یعنی محتوا فقط برای یک Like سریع جذاب نبوده، بلکه کاربر تصمیم گرفته آن را به جایی دیگر منتقل کند.
Reply نیز یکی از Signalهای مهم Ranking است.
محتوایی که باعث ایجاد گفتوگو شود، میتواند احتمال Reply بیشتری ایجاد کند.
برای مثال جمله زیر احتمالاً بحث زیادی ایجاد نمیکند:
JavaScript زبان محبوبی است.
اما اگر سؤال کمی بازتر مطرح شود:
اگر امروز برنامهنویسی Backend را از صفر شروع میکردید، Node.js را انتخاب میکردید یا Django؟
احتمال بیشتری وجود دارد که کاربران پاسخ دهند.
البته این موضوع به معنی ایجاد بحث مصنوعی یا استفاده افراطی از Clickbait نیست.
چون سیستم فقط Signalهای مثبت را بررسی نمیکند.
Rage Bait به محتوایی گفته میشود که عمداً به شکلی نوشته میشود که کاربران را عصبانی کند.
هدف معمولاً این است که افراد برای مخالفت وارد بخش Reply یا Quote شوند.
در چنین شرایطی ممکن است:
Reply ↑
Quote ↑
اما همزمان رفتارهای دیگری نیز افزایش پیدا کنند:
Mute ↑
Block ↑
Not Interested ↑
Report ↑
با توجه به وزن بالای برخی سیگنالهای منفی، ممکن است نتیجه نهایی بر خلاف انتظار تولیدکننده محتوا باشد.
بنابراین از معماری سیستم میتوان برداشت کرد که X صرفاً به دنبال Engagement بیشتر نیست.
نوع Engagement نیز اهمیت دارد.
یکی دیگر از رفتارهایی که Phoenix پیشبینی میکند Follow Author است.
یعنی سیستم بررسی میکند:
احتمال اینکه این کاربر بعد از دیدن این پست، نویسنده را Follow کند چقدر است؟
این Signal از نظر منطقی نیز قابل درک است.
اگر یک محتوا آنقدر برای کاربر ارزشمند باشد که بعد از دیدنش تصمیم بگیرد نویسنده را دنبال کند، احتمالاً آن پست توانسته رضایت قابل توجهی ایجاد کند.
در نتیجه محتوایی که فقط Like ایجاد میکند الزاماً با محتوایی که باعث Follow نویسنده میشود ارزش یکسانی ندارد.
همه Signalها نیاز به کلیک ندارند.
یکی دیگر از اطلاعاتی که در سیستم مشاهده میشود مدت زمانی است که کاربر روی یک محتوا میماند.
اصطلاحاتی مانند اینها در سیستم وجود دارند:
مثلاً دو پست را در نظر بگیرید.
کاربر پست اول را در حدود:
0.3 ثانیه
رد میکند.
اما روی پست دوم:
20 ثانیه
توقف میکند و آن را میخواند.
حتی اگر Like یا Reply ثبت نشود، رفتار دوم اطلاعات بیشتری درباره علاقه واقعی کاربر در اختیار الگوریتم قرار میدهد.
به همین دلیل Threadهای مفید، نمودارها، تصاویر اطلاعاتی، متنهای خواندنی و ویدیوها میتوانند Attention Signalهای مهمی ایجاد کنند.
در Pipeline سیستم فیلتری با نام AgeFilter وجود دارد.
همانطور که از نام آن مشخص است، این بخش سن پست را بررسی میکند.
در یکی از تنظیمات منتشرشده، در یکی از مسیرهای For You پستهایی که بیشتر از حدود ۴۸ ساعت از انتشار آنها گذشته باشد از Candidateها خارج میشوند.
این موضوع به معنی حذف پست پس از ۴۸ ساعت نیست.
پست همچنان میتواند:
اما ممکن است در بعضی مسیرهای Recommendation دیگر به عنوان Candidate در نظر گرفته نشود.
نتیجه مهم این است که عملکرد اولیه یک پست اهمیت زیادی دارد.
یکی دیگر از قسمتهای جالب سیستم Author Diversity است.
فرض کنید X تشخیص دهد پنج پست یک نویسنده برای یک کاربر بسیار مناسب هستند.
بدون سیستم Diversity، ممکن است Feed کاربر به این شکل شود:
پست نویسنده A
پست نویسنده A
پست نویسنده A
پست نویسنده A
پست نویسنده A
این تجربه احتمالاً برای کاربر مناسب نیست.
به همین دلیل الگوریتم تلاش میکند Feed را از نظر نویسنده نیز متنوع نگه دارد.
در کد پارامتری مانند:
AuthorDiversityDecay
دیده میشود.
Decay در اینجا به معنی کاهش تدریجی است.
بنابراین اگر چند پست متوالی از یک نویسنده Candidate شوند، ممکن است امتیاز پستهای بعدی کاهش پیدا کند.
نتیجه این است که انتشار تعداد زیادی پست در زمان بسیار کوتاه، لزوماً باعث نمیشود همه آنها پشت سر هم وارد For You کاربران شوند.
یکی از اصطلاحات مهم در سیستم پیشنهاد محتوای X، OON است.
OON مخفف:
Out Of Network
است.
یعنی محتوایی که از حسابهایی میآید که کاربر آنها را Follow نکرده است.
در مقابل، پستهای حسابهایی که کاربر دنبال کرده است داخل Network قرار میگیرند.
بخش بزرگی از قابلیت Discovery در For You به همین محتوای Out Of Network مربوط میشود.
این موضوع دلیل مهمی برای امکان Viral شدن حسابهای کوچک است.
یک حساب الزاماً به ۱۰۰ هزار Follower نیاز ندارد تا پستش توسط ۱۰۰ هزار نفر دیده شود.
اگر سیستم تشخیص دهد یک پست با علایق یک Cluster مشخص از کاربران هماهنگ است، میتواند آن را برای افراد خارج از شبکه نویسنده نیز نمایش دهد.
یکی دیگر از اجزایی که در سورس دیده میشود سیستمی با نام:
user-cred-v2
است.
این بخش به اعتبار شبکهای حسابها مرتبط است و از ساختارهایی شبیه PageRank استفاده میکند.
PageRank را میتوان با این ایده ساده توضیح داد:
همه ارتباطها ارزش یکسان ندارند؛ اینکه چه کسی به شما مرتبط است نیز اهمیت دارد.
در شبکه اجتماعی نیز منطق مشابهی میتواند وجود داشته باشد.
فقط تعداد Followerها اهمیت ندارد.
کیفیت و نوع حسابهایی که با شما ارتباط یا تعامل دارند نیز میتواند مهم باشد.
برای همین:
10,000 Follower ضعیف
الزاماً از:
1,000 Follower واقعی و مرتبط
ارزش بیشتری ندارد.
یکی از مهمترین نکات در معماری X تفاوت میان Ranking و Visibility است.
Ranking تصمیم میگیرد:
این پست در چه جایگاهی از Feed قرار بگیرد؟
اما Visibility سؤال متفاوتی دارد:
آیا این محتوا در این بخش اصلاً اجازه نمایش دارد؟
این دو مرحله از یکدیگر جدا هستند.
در سیستم Visibility خروجیهایی مانند این دیده میشود:
ALLOW
INTERSTITIAL
DROP
یعنی محتوا اجازه دارد به شکل عادی نمایش داده شود.
یعنی قبل از نمایش محتوا ممکن است یک مرحله واسط یا هشدار به کاربر نشان داده شود.
مثلاً:
این محتوا ممکن است حساس باشد.
یعنی محتوا در آن Context از نمایش کنار گذاشته میشود.
بنابراین حتی اگر یک پست از نظر Ranking امتیاز خوبی داشته باشد، ممکن است Visibility اجازه توزیع گسترده آن را ندهد.
اصطلاح Shadowban معمولاً زمانی استفاده میشود که صاحب یک حساب احساس میکند محتوای او بدون اخطار مشخص، کمتر از قبل دیده میشود.
اما معماری سیستم نشان میدهد که کاهش Visibility میتواند از چند لایه مختلف ایجاد شود.
ممکن است مشکل مستقیماً مربوط به Ranking نباشد.
برای مثال یک محتوا یا Account میتواند تحت تأثیر Safety یا Visibility Filtering قرار بگیرد.
به همین دلیل افت Reach همیشه به این معنی نیست که:
الگوریتم پست را ضعیف ارزیابی کرده است.
ممکن است موضوع به محدودیتهای دیگری مربوط باشد.
Label را میتوان یک برچسب سیستمی یا ماشینی برای طبقهبندی محتوا دانست.
برای مثال ممکن است یک محتوا Labelهایی در دستههای زیر دریافت کند:
Spam
Adult Content
Violence
Sensitive Media
Abusive Behavior
داشتن Label الزاماً به معنی حذف محتوا نیست.
بسته به نوع Label و شرایط، ممکن است:
این موضوع بار دیگر نشان میدهد که Ranking تنها عامل تعیینکننده Reach نیست.
خیر.
این نکته بسیار مهم است.
انتشار بخشی از سورس سیستم Recommendation به این معنی نیست که میتوان دقیقاً پیشبینی کرد یک پست چه تعداد Impression خواهد گرفت.
بخشهایی از سیستم همچنان عمومی نیستند.
از جمله قسمتهایی از:
X همچنین میتواند A/B Testهای مختلف انجام دهد.
در نتیجه ممکن است همه کاربران دقیقاً تنظیمات یا رفتار یکسانی از سیستم مشاهده نکنند.
بنابراین سورس منتشرشده را بهتر است نقشهای از معماری سیستم Recommendation بدانیم، نه فرمول قطعی برای Viral شدن.
مهمترین نکته این است که Like تنها Signal سیستم نیست.
X رفتارهای مختلفی را بررسی میکند.
Signalهای مثبت میتوانند شامل مواردی مانند این باشند:
Reply
Quote
Share
DM Share
Copy Link
Follow
Dwell
در طرف مقابل رفتارهای منفی نیز اهمیت زیادی دارند:
Not Interested
Mute
Block
Report
بنابراین محتوایی که صرفاً Engagement زیادی ایجاد میکند الزاماً بهترین عملکرد را ندارد.
مهم است نوع تعامل ایجادشده نیز مثبت باشد.
اگر بخواهیم کل سیستم را در یک مفهوم خلاصه کنیم، تفاوت اصلی اینجاست:
الگوریتم فقط سؤال نمیکند:
این پست چند Like گرفته است؟
بلکه تلاش میکند پاسخ دهد:
با توجه به رفتار قبلی این کاربر، اگر این پست را به او نشان دهم احتمالاً چه واکنشی خواهد داشت؟
For You یک Feed ثابت و یکسان برای همه نیست.
برای هر کاربر، مجموعهای از Candidateها انتخاب میشود، رفتار احتمالی او نسبت به آنها پیشبینی میشود، Signalهای مثبت و منفی وزن میگیرند، محدودیتهایی مانند Freshness و Author Diversity اعمال میشوند و در نهایت Visibility نیز بررسی میشود.
نتیجه این فرآیند Feedی است که تا حد زیادی برای همان کاربر ساخته شده است.
پس شاید دقیقترین توصیف برای الگوریتم X این باشد:
X الزاماً دنبال محبوبترین محتوا نیست؛ تلاش میکند محتوایی را پیدا کند که احتمال میدهد برای هر کاربر مشخص، در همان لحظه ارزش بیشتری داشته باشد.
هنوز نظری ثبت نشده است.
برای ارسال نظر وارد شوید.