Deep Neural Networks for YouTube Recommendations စာတမ်း အကြောင်း သိကောင်းစရာ

Sai Htaung Kham
11 min readJan 30, 2021

--

ကျွန်တော် စာမရေးဖြစ်တာ တော်တော်ကြာသွားပါပြီ တတ်သိပညာရှင်များ နေကောင်းကျန်းမာကြပါရဲ့လားချင်ဗျာ... COVID-19 ကြီးလည်း အခြေအနေမကောင်းသေးတော့ ကျွန်တော်တို့ တတ်နိုင်တဲ့ ဘက်ကနေ ရောဂါကြီး မကူးအောင်မ ပြန့်အောင် ကူညီကြရအောင်ဗျာ...

(၁) မိတ်ဆက်ခြင်း

ဒီတစ်ခေါက် ကျွန်တော် မိတ်ဆက်ပေးချင်တာကတော့ Recommendation System (မြန်မာလို အကြံပေးတဲ့စနစ် (ဝါ) မိတ်ဆက်ပေးတဲ့ စနစ်) အကြောင်လေးပဲဖြစ်ပါတယ်။ Recommendation System ဆိုတာကတော့ ကျွန်တော်တို့ E-Commerce (Online shopping စသည်) မှာ တော်တော်များများ တွင်တွင်ကျယ်ကျယ်အသုံးပြုနေတဲ့ စနစ်ပဲဖြစ်ပါတယ်။

ဥပမာ အနေနဲ့ ဖော်ပြပေးရမယ်ဆိုရင် ကျွန်တော်တို့ Online ကနေ ပစ္စည်း တစ်ခု ဝယ်ပြီးပြီ၊ နောက်ထပ်ကျွန်တော်တို့ ကြိုက်နိုင်မယ့် ပစ္စည်းတွေက ဘာတွေဖြစ်မှာလဲ စတာတွေကို အကြံပေး၊ မိတ်ဆက်ပေးတဲ့ စနစ်တွေပဲဖြစ်ပါတယ်။ ကျွန်တော်တို့ အပြင်ဆိုင်မှာ နံပြားသွားဝယ်တယ်ဆိုပါဆို့။ ဒီလိုဆိုရင် ဆိုင်ရှင်ကမေးလိမ့်မယ် "မောင်လေး ညီမလေးတို့ လက်ဖက်ရည်မဝယ်ဘူးလား။ ဒီနေ့လက်ဖက်ရည် အရမ်းကောင်းတယ်နော် ခုဏကမှ ဖျော်ထားတာ ရှယ်ပဲ။" စတဲ့ အကြံပေး မိတ်ဆက်ပေးတတ်ကြပါတယ်။ ဒါကတော့ လက်တွေ့ အပြင်ဆိုင်တွေမှာ ဆိုင်ရှင် ဝန်ထမ်းတွေက ရှိနေသေးတဲ့အတွက်ကြောင့် ပြဿနာ မရှိပေမယ့် အခုလို Online Shopping ပြောင်းပြီး ရောင်းလာကြပြီဆိုရင် ကျွန်တော်တို့ Customer တစ်ယောက်ချင်းစီ ဘယ်လို အကြံပေးမှာလဲ၊ ဘယ်လို ထိရောက်တဲ့ Service ပေးမှာလဲ၊ ပစ္စည်းပေါင်း ထောင်ကျော် သောင်းကျော် ရှိလာရင်ရော ဘယ်ပစ္စည်းက ဘယ် Customer နဲ့ လိုက်ဖက်လဲ၊ သင့်တော်မှုရှိလဲ၊ စတဲ့ လဲပေါင်း များစွာ ကျွန်တော်တို့ ခေါင်းထဲမှာ ပေါ်လာပါလိမ့်မယ်။ ဒီနေရာမှာတော့ တကယ့်လို့ Customer ရဲ့ အကြိုက်ကိုသိပြီး သင့်တော်တဲ့ ပစ္စည်းတွေကို မိတ်ဆက်ပေးနိုင်မယ်ဆိုရင် ကျွန်တော်တို့ Online Shopping ရောင်းအားဟာ သိသိသာသာ တိုးတက်သွားမှာ သေချာပါတယ်။ ဒီတော့ ကျွန်တော်တို့ သန်းပေါင်းများစွာသော Customer ကို သန်းပေါင်းများစွာသော ပစ္စည်းကနေ Customer တစ်ဦးချင်း တစ်ယောက်ချင်းရဲ့ အကြိုက်နဲ့ လိုက်ဖက် ကိုက်ညီမယ့် စနစ်ကို တီထွင်ဖို့ ကွန်ပျူတာ ပညာရှင်တော့ ကြိုးပမ်းလာကြပါတယ်။ အခုဆိုရင်တော့ အဲ့စနစ်ကို တီထွင်ပြီး လက်ရှိမှာလည်း အောင်အောင်မြင်မြင် အသုံးပြုနေကြပါပြီ။

Spotify Recommender System

အပေါ်ကပုံ ကတော့ ကျွန်တော် ကြိုက်နိုင်မယ့် သီချင်းတွေကို Spotify က မိတ်ဆက်ပေးတဲ့ စာမျက်နှာပဲ ဖြစ်ပါတယ်။ သူကတော့ ကျွန်တော် အရင်က ဘာတွေ နားထောင်ခဲ့လဲ၊ ဘယ်လို သီချင်းမျိုးကို ကြိုက်လဲ စတဲ့ ကျွန်တော့် အကြိုက်တွေကို မှတ်သားထားပြီး ကျွန်တော် ကြိုက်နိုင်မယ့် သီချင်းတွေကို အကြံပေး မိတ်ဆက်ပေးတဲ့ စနစ်တွေပဲဖြစ်ပါတယ်။ ဒီလို မိတ်ဆက်ပေး အကြံပေးတာတွေက နောက်ကွယ်ကနေ လူတွေက လုပ်ပေးနေတာ မဟုတ်ပါဘူး။ AI လို့ခေါ်တဲ့ အသိဥာဏ်တုတွေက လုပ်ပေးနေတာပါ။ AI နဲ့ ပတ်သက်တာကိုတော့ ကျွန်တော့် အရင်က Post တွေကို လေ့လာဖတ်ရှုနိုင်ပါတယ် ခင်ဗျာ။

ဒီ Post မှာတော့ တတ်သိတဲ့ ပညာရှင်တွေအနေနဲ့ Neural Network နဲ့ သူနဲ့ သက်ဆိုင်တဲ့ အခြေခံတွေ သိရှိပြီးသားလို့ ကျွန်တော် ယူဆပြီး ရေးသားပါမယ်။ ဒီ Post ကတော့ Engineer တွေအတွက် (Machine Learning Engineer) တွေအတွက် ရည်ရွယ်ပြီး ရေးသားမှာ ဖြစ်တဲ့အတွက် Machine Learning နဲ့ နီးစပ်မှု မရှိရင်တော့ နားလည်ရတာ ခက်ခဲပါလိမ့်မယ်။ ဒါကိုတော့ စာဖတ်တဲ့ တတ်သိပညာရှင်များ နားလည်ခွင့်လွှတ်ပေးပါလို့ မေတ္တာရပ်ခံချင်ပါတယ်ခင်ဗျာ။

စာတမ်းရဲ့ မူရင်းကိုတော့ ဒီကနေ ယူဖတ်နိုင်ပါတယ်ခင်ဗျာ။

ဒီစာတမ်းကတော့ ၂၀၁၆ ခုနှစ်ကထုတ်ထားတဲ့ စာတမ်းဖြစ်ပြီး ဟောင်းနေပေမယ့် စိတ်ဝင်စားဖို့ တော်တော်ကောင်းပါတယ်။ ကျွန်တော် ဒီစာတမ်းကို ဖတ်ပြီး ကျွန်တော် နားလည်တဲ့ ရှုတောင့်ကနေ ဆွေးနွေးသွားမှာ ဖြစ်တဲ့အတွက် အမှားပါရင် Comment မှာ ရေးသားပြီး အမှားပြင်ပေးကြဖို့ တောင်းဆိုပါတယ်ခင်ဗျ။

(၂) လက်ရှိ Recommender System တွေမှာ ကြုံရတဲ့ အခက်အခဲများ

From paper

ကျွန်တော်တို့ Recommender System လို့ပြောလိုက်ရင် Github မှာ Open Source လုပ်ထားတဲ့ Recommender System တွေ အများကြီးရှိပါတယ်။ Recommender System တော်တော်များများဟာ သူနဲ့ သက်ဆိုင်တဲ့ လုပ်ဆောင်ချက်တွေ ရှိကြပြီး ဘယ်် Recommender System ကို သုံးမှာလဲ ဆိုတာကို Engineer က ရွေးချယ်ကြရပါတယ်။

ဥပမာပြောရရင်

  • ပစ္စည်း သောင်းချီထဲကနေ လက်ရှိ Customer က ကြိုက်နိုင်မယ့် ပစ္စည်းကို ရွေးတာမျိုး (Candidate Generation လို့ခေါ်ပါတယ်)
  • ‌ပစ္စည်း ရာချီထဲကနေ ပစ္စည်း ဆယ်ဂဏန်းလောက်ကို ရွေးချယ်ပြီး Customer ဆီကို အကြံပေးတာမျိုး (Ranking လုပ်တယ်လို့်ခေါ်ပါတယ်)

စတဲ့ လုပ်ဆောင်ချက်တွေ မတူညီကြလို့ အသုံးပြုတဲ့ Recommender System တွေလည်း ကွဲပြားမှုတွေရှိကြပါတယ်။ တချို့ Recommender System တွေဆိုရင် အဲ့ဒီလုပ်ဆောင်ချက် (၂) မျိုးလုံးကို လုပ်ဆောင်ပေးနိုင်တာတွေလည်းရှိကြပါတယ်။ အခု ကျွန်တော်မိတ်ဆက်မယ့် YouTube Recommender စာတမ်းကတော့ အဲ့ဒီ လုပ်ဆောင်ချက် (၂) မျိုးလုံးကို အထောက်အကူပြုတဲ့ Design နဲ့ ဖန်တီးထားတာပဲ ဖြစ်ပါတယ်။

နောက် ပြဿနာတစ်ခုကတော့ လက်ရှိ Open Source လုပ်ထားတဲ့ Recommender System တော်တော်များများဟာ Development Environment (သို့) Testing Environment မှာ ကောင်းကောင်း အလုပ်လုပ်နိုင်ကြပေမယ့် တကယ်တမ်း Production Environment မှာ Deploy လုပ်ရင် အဆင်မပြေတာတွေ အလုပ်မလုပ်တာတွေ စတဲ့ ပြဿနာ အမျိုးမျိုးနဲ့ ကြုံတွေ့ကြရတတ်ပါတယ်။

ဒီစာတမ်းထဲမှာ ဖော်ပြထားတဲ့ အဓိက ပြဿနာ (၂) ရပ်ကတော့

(၁) အသုံးပြုတဲ့ Customer အရေအတွက် သန်းနဲ့ချီများလာတဲ့ အချိန်

(၂) Online မှာ တင်ရောင်းမယ့် ပစ္စည်း သန်းနဲ့ချီများလာပြီဆိုရင် Production မှာ Scale မဖြစ်တာ (Server ပေါ် Memory, CPU, Loading စတဲ့ ပြဿနာတွေကြောင့် တင်လို့မရတာ) စတဲ့ ပြဿနာတွေနဲ့ ကြုံတွေ့ရတတ်ကြပါတယ်။

နောက်တစ်ချက်ကတော့ User နဲ့ Item (တင်ရောင်းမယ့် ပစ္စည်း) တွေရဲ့ Dataset ဟာ အရမ်း Sparse ဖြစ်နေတဲ့ အတွက် User, Item relationship တွေကို Recommender System က သေသေချာချာ Learning မလုပ်နိုင်တဲ့ ပြဿနာပဲဖြစ်ပါတယ်။

YouTube ဟာ Online Video Platform ဖြစ်တဲ့အတွက်ကြောင့် YouTube Recommender System ဟာ စက္ကန့်နဲ့အမျှ Video အသစ်တွေကို Upload လုပ်နေတဲ့ အတွက်ကြောင့် အဲ့ဒီ Upload လုပ်လိုက်တဲ့ Video အသစ်တွေကို အချိန်နဲ့ တပြေးညီ သူနဲ့ သက်ဆိုင်တဲ့ User ဆီကို အကြံပေးနိုင်ဖို့ လိုအပ်လာပါတယ်။ အဲ့ဒါကိုတော့ Paper မှာ သူတို့ ဘယ်လို ဖြေရှင်းထားလဲဆိုတာ စိတ်ဝင်စားစွာ လေ့လာနိုင်မှာဖြစ်ပါတယ်။

From paper

(၃) YouTube Recommender System ကို ခွဲခြမ်းစိတ်ဖြာခြင်း

YouTube Recommender System မှာ အဓိက အပိုင်း (၂) ပိုင်းခွဲထားပါတယ်။ ပထမ အပိုင်းကတော့ Candidate Generation အပိုင်းဖြစ်ပြီး ဒုတိယ အပိုင်းကတော့ Ranking လုပ်တဲ့ အပိုင်းပဲဖြစ်ပါတယ်။

Candidate Generation

ဥပမာ User မောင်မောင် ဟာ YouTube ကို ဖွင့်လိုက်ပြီ သူ့အတွက် ပထမဆုံးမြင်ရမယ့် Video ကို ဘယ်လိုရွေးချယ်ပြီး ပြပေးမှာလဲပေါ့။ ဒီလို သန်းပေါင်းများစွာသော Video တွေထဲကမှ မောင်မောင်အတွက်ရွေးချယ်ပြီး ပြပေမယ့် ပထမ အဆင့်ကတော့ Candidate Genration အပိုင်းတွေပဲဖြစ်ပါတယ်။

Candidate Generation ဟာ သန်းပေါင်းများစွာသော Video တွေထဲမှာ ရာဂဏန်းလောက် Video ကို ရွေးထုတ်ပေးပါမယ်။ ဒါဆို Candidate Generation Model ကို ဘယ်လို တည်ဆောက်ကြပါလိမ့်ပေါ့။ ဒါကတော့ ကျွန်တော်တို့ Neural Network based Matrix Factorization အမျိုးအစားကို အသုံးပြုထားပါတယ်။ ဒီနေရာမှာ Matrix Factorization အကြောင်းနားလည်ပြီးသားလို့ ယူဆပါ့မယ်။ Matrix Factorizaion ရဲ့ အဓိက လုပ်ဆောင်ချက်ကတော့ ဘယ် User ဟာ ဘယ် Item ကို ဘယ်လောက် Level (Scoring) အထိ ကြိုက်တယ်ဆိုတဲ့ လုပ်ဆောင်ချက်တွေကို ခန့်မှန်းပေးတဲ့ Model လို့ ဆိုပြန်လည်း မမှားပါဘူး။ ဒီလို ခန့်မှန်းတဲ့ လုပ်ဆောင်ချက်တွေကို လုပ်ဆောင်တဲ့ နေရာမှာ အရေးကြီးတာကတော့ Input data ပါ။ YouTube အတွက် အဓိက အသုံးပြုခဲ့တဲ့ Input data တွေကတော့ Video ID, Search Query, Demographic information စတဲ့ အချက်အလက်တွေကို အသုံးပြုထားတယ်လို့ ဆိုထားပါတယ်။

Matrix Factorization ကနေ ရလာတဲ့ အရေးပါတဲ့ Output ကို ပြောရမယ်ဆိုရင် သက်ဆိုင်ရာ User အတွက် Item တွေရဲ့ Scoring တွေ အပြင် Learned User နဲ့ Item Embedding တွေပဲဖြစ်ပါတယ်။ ဒီလို Learned Embedding တွေဟာ တခြား Transfer learning တွေ မှာ အသုံးပြုနိုင်သလို နောက်ဆက်လက်ဖော်ပြပေးမယ့် Re-ranking အပိုင်းမှာလည်း အသုံးဝင်ပါသေးတယ်။

သူတို့ရဲ့ Candidate Generation ကို Training လုပ်တဲ့အချိန်မှာ ကျွန်တော့်အတွက် စိတ်ဝင်စားတဲ့ရလဒ်အနေနဲ့ကတော့ Offline Evaluation မှာ သုံးတဲ့ နည်းဗျူဟာ နဲ့ Online Serving မှာ သုံးတဲ့နည်းဗျူဟာတွေ ကွာခြားနေတာ တွေ့ရပါတယ်။ စာတမ်းအရကတော့ Offline Evaluation မှာ Precision ကို အဓိကထားပြီး Model ကို Training လုပ်တယ်၊ Online evaluation အတွက် Model Tunning လုပ်ဖို့ကတော့ A/B testing ကို အသုံးပြုတယ်လို့ ဆိုထားပါတယ်။ နောက်ပြီး Offline နဲ့ Online ရလဒ်တွေက တိုက်ရိုက် သက်ရောက်မှု မရှိဘူးလို့ဆိုပြန်ပါတယ်။ ဒီတော့ ကျွန်တော်တို့ တွေ့လိုက်တာကတော့ Recommender System တစ်ခုကို Design ဆွဲတဲ့ အချိန်မှာ လွယ်လွယ်နဲ့ လုပ်လို့မရဘူးဆိုတာ လေ့လာတွေ့ရှိနိုင်ပါတယ်။

Candidate Generation တွေမှာ သက်ဆိုင်ရာ User အတွက် Item ကို မိတ်ဆက်ပေးဖို့ Scoring ကို ဘယ်လို တွက်ကြပါလိမ့်

From paper

ကျွန်တော်တို့ Scoring တွက်တဲ့အချိန်မှာ Machine Learning Engineer တွေအတွက် အကျွမ်းတဝင် ဖြစ်ပြီးသား Softmax Formula လေးကို အသုံးပြုထားတာ တွေ့ရပါတယ်။ ဒီနေရာမှာ Softmax အကြောင်းသိပြီးသားလို့ ယူဆပါမယ်။ အတိုချုပ်ပြောရရင် Softmax ဟာ Multi Classification အတွက် သက်ဆိုင်ရင်ရာ Class တွေရဲ့ Probability ကို တွက်ပေးတဲ့ Formula ပဲဖြစ်ပါတယ်။ အဲဒီ Class တွေ အားလုံးရဲ့ Probability ကို ပေါင်းလိုက်ရင် 1 ပြန်ရပါမယ်။ ဒီတော့ ဒီ Formula ကနေ ရလာတဲ့ Probability ကို Scoring အဖြစ် အသုံးပြုနိုင်ပါတယ်။

ဒီ Candidate Generation ကနေ ကျွန်တော်တို့ ရလာတဲ့ ရလဒ်အနေနဲ့ကတော့ User, Content Embedding နဲ့ Video Embedding တွေပဲဖြစ်ပါတယ်။ User နဲ့ Content pair ကို Model ထဲ Input လုပ်နိုင်မယ့်ဆိုရင် ကျွန်တော်တို့ သက်ဆိုင်ရာ Video နဲ့ Scoring ကို ရလာမှာဖြစ်ပါတယ်။

ဥပမာ

Input အနေနဲ့ဆိုရင်

User -> မောင်မောင်

Content -> [search query~avenger, geographic~Myanmar, age~28, etc… ]

Output အနေနဲ့ကတော့

Video -> [“Avenger End Game”~ 0.6, “Infinity War” ~ 0.3,…, “Mr.Bean” ~0.002] စသည်။

စာတမ်းထဲမှာတော့ ကျွန်တော့်အတွက် စိတ်ဝင်စားတဲ့ အချက်တစ်ခုပြောရမယ်ဆိုရင် သူတို့က Explicit Feedback (like, unlinke) ကို မသုံးဘဲ Implicit Feedback (watch time) ကို အသုံးပြုထားတာကို တွေ့ရပါတယ်။ အဓိက အကြောင်းရင်းကတော့ Explicit Feedback တွေသည် Sparse data တွေ ဖြစ်တဲ့အတွက်ကြောင့်ရယ် နောက်တစ်ခုက Explicit Feedback အရေအတွက်ထက် Implicit Feedback အရေအတွက်များနေတာကို တွေ့ရလို့ Explicit Feedback အစား Implicit Feedback data တွေကို သုံးထားတယ်လို ဆိုပါတယ်။

နောက်စိတ်ဝင်စားစရာ တစ်ခုကတော့ ကျွန်တော်တို့ Machine Learning Engineer တော်တော်များများ သိပြီးသားဖြစ်တဲ့ Extreme Multiclass ပြဿနာပဲဖြစ်ပါတယ်။ ကျွန်တော်တို့ Classification လုပ်မယ့် Class အရေအတွက်ဟာများလာလေလေ Computation Speed ဟာ ကြာလေလေပါပဲ။ ဒီပြဿနာ ဆိုရင်တော့ ကျွန်တော်တို့ NLP Problem မှာ အများဆုံးကြုံရတဲ့ ပြဿနာပါ။ သန်းပေါင်းများစွာသော Vocabulary ကို Training လုပ်တဲ့ အချိန်မှာ Predict လုပ်ပြီး Objective Function ကို Optimize လုပ်တဲ့ နေရာမှာ ဘယ်လိုမှ ရှေ့တိုးလို့မရနိုင်တဲ့ Computation Delay တွေ ကြုံရမှာ ကျိမ်းသေပါတယ်။

From paper

အပေါ်က Formula ကို ပြန်ကြည့်ရင် ကျွန်တော်တို့ သက်ဆိုင်ရင် User တစ်ယောက်အတွက် Candidate Generation Model ကို Train လုပ်တဲ့အချိန်မှာ Video အားလုံးအတွက် sum(e**v.u) ကို ပြန်တွက်ပေးရပါတယ်။ YouTube လို Online Platform အတွက် User သန်းချီ နဲ့ Video သန်းချီရှိတဲ့ အတွက်ကြောင့် အကြမ်းဖျင်းပြောရရင် Scroing အတွက် (သန်း * သန်း) ကြိမ် Calculation တွက်ရပါတယ်။ ဒီတော့ Training မှာ အရမ်းကို နှေးပါတယ်။ ဒါကို ဖြေရှင်းဖို့အတွက် စာတမ်းမှာတော့ NLP ရဲ့ Concept ကို ငှားပြီး နာမည်ကြီးကြတဲ့ Softmax Approximating နည်းဗျူဟာကို အသုံးပြုသွားပါတယ်။ Softmax Approximating နည်းဗျူဟာမှာ အမျိုးမျိုးရှိတဲ့အပြင် သူတို့ စမ်းသပ်မှု ပြုလုပ်ခဲ့တဲ့ Approach (၂) ခုကတော့ Hierarchical Softmax နဲ့ Sampling-based Approach ဖြစ်တဲ့ Negative Sampling နည်းဗျူဟာကို အသုံးပြုခဲ့ပါတယ်။

စာတမ်းအရဆိုရင်တော့ Hierarchical Approach ဟာ သူတို့ Dataset နဲ့ Model အတွက် ကောင်းကောင်းအလုပ်မလုပ်ဘူးလို့ ဆိုထားပါတယ်။ Negative Sampling နည်းဗျူဟာကတော့ သူတို့ Candidate Generation အတွက် အသင့်တော်ဆုံးလို့ ဆိုထားပါတယ်။ ဒီနေရာမှာ Softmax Approximation အကြောင်းကို ရှင်းမပြတော့ပါဘူး။ နောက် Post တွေမှာ ရှင်းပြပါ့မယ် လိုအပ်ရင်။

ဒီတော့ Training မှာ အဆင်ပြေသွားပေမယ့် Serving လုပ်တဲ့အပိုင်းမှာ ကျိန်းသေ မဖြစ်မနေ Probability ကို ပြန်တွက်ရမှာပါ။ ဒါမှ ဘယ် User အတွက် ဘယ် Video က ဘယ်လောက် Score ရှိတယ်ဆိုတာ သိနိုင်မှာ ဖြစ်ပါတယ်။ ခုဏက ပြဿနာ နဲ့ ခပ်ဆင်ဆင်ပါပဲ။ Serving မှာ User တစ်ယောက်၊ အယောက် တစ်ရာ အတွက် Computation Speed ဟာ မြန်ဆန်ကောင်းမြန်ဆန်နိုင်တယ် ဆိုပေမယ့် YouTube လို Plateform မှာ User သန်းနဲ့ချီရှိနေတဲ့ အတွက် YouTube website ကို ဖွင့်တဲ့အချိန်မှာ Loading ကြာတာ၊ အဝိုင်းလည်တာကနေ မတက်တာတို့ကို ဘယ် User မှ ကြိုက်မယ် မထင်ပါဘူး။ ကျွန်တော်ကိုယ်တိုင်လည်း အတူတူပါပဲ။ HD လောက်ကြည့်လိုက်ရမှ စိတ်ကျေနပ်တဲ့ အုပ်စုထဲပါပါတယ်။

ဒါဆိုရင် ဒီပြဿနာကို ဘယ်လိုဖြေရှင်းခဲ့လည်းပေါ့။ စာတမ်းအရဆိုရင်တော့ Approximate Neighbor Search (သို့) Nearest Neighbor Search နည်းဗျူဟာကို အသုံးပြုခဲ့ပါတယ်။ Nearest Neighbor Search အကြောင်းကို နည်းနည်းပြောပြပေးရမယ်ဆိုရင် အလုပ်လုပ်ပုံကတော့ ကျွန်တော်တို့ Clustering Algorithm မျိုးနဲ့ ဆင်တူတယ်လို့ ပြောလို့ရပါတယ်။ လူပိန်းနာလည်အောင်ပြောတာပါ။ အလုပ်လုပ်ပုံ အသေးစိတ်ကိုတော့ အင်တာနက်မှာ ရှာကြည့်ကြပါ။ ဒီနေရာမှာ ကျွန်တော်တို့ User, Content Embedding နဲ့ Video Embedding ရှိထားတဲ့အတွက်ကြောင့် ဒီ Hyperspace Embedding တွေကို အသုံး ပြုပြီး Nearest Neighbor Search Algorithm က ဘယ် User Embedding Space ဟာ ဘယ် Video Embedding Space နဲ့ နီးနေတယ် စတဲ့ Scoring နဲ့ Candidate list တွေကို ပြန်ထုတ်ပေးမှာ ဖြစ်တဲ့အတွက်ကြောင့် Deep Neural Network Candidate Generation နဲ့ တူညီတဲ့ ဆင်တူရလဒ်တွေ ရလာမှာ ဖြစ်ပါတယ်။ စာတမ်းမှာ Online testing (A/B test) တွေ့ရှိချက်အရ ပြောရရင် DNN candidate model နဲ့ Nearest Neighbor Search ရဲ့ရလဒ်က သိပ်မကွာဘူးလို့ဆိုပါတယ်။

ကျွန်တော့် အတွေ့ အကြုံအရပြောရရင်တော့ Production ကို Deploy မလုပ်ခင် Nearest Neighbor Search တွေမှာ Parameters ရှိတဲ့အတွက်ကြောင့် Default မဟုတ်ဘဲ Parameters တွေကို သေသေချာချာ Tunning လုပ်ခြင်းအားဖြင့် ရလဒ်ကောင်းတွေ ရနိုင်ပါတယ်။

Feature Engineering တွေကို သူတို့ ဘယ်လို လုပ်ကြပါလိမ့်

From paper

YouTube အတွက် Feature တွေတော့ သူတို့ မှာရှိတဲ့ Data မှန်သမျှနီးပါးကို အသုံးပြုထားတယ်လို့ ဆိုထားပါတယ်။ ဥပမာအားဖြင့် user history, user geographic location, gender, age, search queries, etc စသည့် features တွေကို အသုံးပြုထားပါတယ်။ အပေါ်က ပုံကတော့ ကြည့်ရတာ တော်တော်ကို ရှင်းနေပြီ ဖြစ်တဲ့အတွက်ကြောင့် ကျွန်တော် မရှင်းတော့ပါဘူး။

စိတ်ဝင်စားစရာတစ်ခုကတော့ User တစ်ယောက်ဟာ Video တစ်ခုကို Upload လုပ်လိုက်ပြီဆိုရင် အဲ့ဒီ Upload လုပ်လိုက်တဲ့ Video သည် ဘယ်အချိန်မှာ ကြည့်ရှုသူ ဘယ်လောက် ရှိနိုင်မှာလဲ စတဲ့ အချက်အလက်တွေကို လေ့လာနိုင်ဖို့အတွက် “Age Feature” ကို Engineering လုပ်ထားတဲ့ ပုံစံကို ရှင်းပြထားပါသေးတယ်။ ဒီနေရာမှာ Age Feature ဟာ Upload လုပ်ပြီးသား Video ရဲ့ သက်တမ်း (Freshness) ကို ဆိုလိုတာပါ။ ဒီ ပြဿနာဟာ Recommender System တော်တော်များများမှာ ကြုံရတဲ့ ပြဿနာပါ။ Video အသစ်ဖြစ်တဲ့အတွက် Recommender System ဟာ အဲ့ဒီ Video အကြောင်းကို သေသေချာချာ နားမလည်တာကတစ်မျိုး၊ ကြည့်ရှူသူ user အရေအတွက်ကလည်း နည်းနေတာ (သို့မဟုတ်) ခုမှ Upload လုပ်တော့ ကြည့်ရှုသူမရှိသေးတာလည်း ဖြစ်နိုင်ပါတယ်။ အဲ့ဒီတော့ အဲ့လို Video တွေကို Recommend လုပ်သင့်လား မလုပ်သင့်လား စတာတွေ ဆုံးဖြတ်ဖို့ ခက်ခဲလာပါတယ်။ အဲ့ဒီလို ပြဿနာမျိုးကိုတော့ Recommender System မှာ Cold Start Problem လို့ခေါ်ပါတယ်။ စာတမ်းမှာတော့ Cold Start Problem ကို Age Feature နဲ့ ဖြေရှင်းထာပါတယ်။

Age Feature ဆိုတာကတော့ ရှင်းရှင်းလေးပါပဲ။ လက်ရှိ Video ဟာ ဘယ်လောက် သက်တမ်းရှိပြီလဲ ဆိုတာကို ဖော်ပြဖို့ Feature ပါ။

From paper

ဒီနေရာမှာ အပြာလိုင်းကတော့ Age Feature မပါဘဲ Training လုပ်ရင် Model ရဲ့ ရလဒ်ဖြစ်ပြီး၊ အနီလိုင်းကတော့ Age Feature သုံးထားတဲ့ Model၊ အပြာလိုင်းကတော့ လက်ရှိ Video တစ်ခုအတွက်အမှန်တကယ် Data ရဲ့ Trend ဖြစ်ပါတယ်။ ဒီ Graph ကို ကြည့်ခြင်းအားဖြင့် Age Feature ပါတဲ့ Model ဟာ တကယ့်ဖြစ်ပေါ်နေတဲ့ Data ရဲ့ ရလဒ်နဲ့ ဆင်တူတယ်လို့ပြောရပါလိမ့်မယ်။

နောက်စိတ်ဝင်စားစရာတစ်ခုကတော့ Serving လုပ်တဲ့ အချိန်မှာ Age Feature ကို သုည သို့မဟုတ် အနှုတ် တန်ဖိုးကို Setting ထည့်တာပဲဖြစ်ပါတယ်။

Training Dataset နဲ့ Holdout Dataset ကိုပြုလုပ်တဲ့အချိန်မှာ စာတမ်းမှာဖော်ပြတဲ့ Model အရဆိုရင် Training လုပ်ရင်း Future information တွေကို သေသေချာချာ Predict လုပ်နိုင်ဖို့ အောက်ဖော်ပြပါ နည်းလမ်းကို အသုံးပြုခဲ့ပါတယ်။

From paper

YouTube လို Website မှာ Video တွေကို Episode သို့မဟုတ် Channel တွေရှိနေတဲ့အတွက်ကြောင့် Holdout Dataset ကို Design လုပ်တဲ့နေရာမှာ Asymmetric co-watch probabilities signal တွေကို ပါအောင် Design လုပ်ရပါတယ်။ ပုံရဲ့ ဘယ်ဘက်ကတော့ သာမန် Recommender System ရဲ့ Holdout Dataset Design လုပ်ပုံဖြစ်ပြီး ညာဘက်ကတော့ YouTube ရဲ့ Holdout Dataset Design လုပ်ပုံပဲဖြစ်ပါတယ်။ ညာဘက်ကို သေချာကြည့်ပါ။ StN-3…StN-1, WtN-2…WtN(Label) ဆိုတာ မြင်ရမှာပါ။ ပြောချင်တာကတော့ Label ကို Create မလုပ်ခင် Label ရဲ့ အရှေ့က Information တွေ အရေးပါကြောင်းပြောချင်တာပါ။ ဒါမှ Model ဟာ Asymmetric co-watch probabilities တွေကို သေသေချာချာ လေ့လာအသုံးချနိုင်မယ် ဆိုတဲ့ အချက်ပါပဲ။

နောက်တစ်ခုကတော့ Feature တွေများလေလေ Model Prediction ပိုကောင်းလေလေလို့ စာတမ်းက ဖော်ပြထားပါသေးတယ်။

From paper

MAP တန်ဖိုးကြီးလေလေ Model Performance ပိုကောင်းလေလို့ မှတ်ယူပါ။

Candidate Generation အပိုင်းရဲ့ နောက်ဆုံး ဆွေးနွေးချက်တစ်ခုကတော့ Deep Neural Network ရဲ့ Depth ပိုများတာဟာ Depth နည်းတာထက်စာရင် Performance ပိုကောင်းကြောင်းဖော်ပြထားပါသေးတယ်။ ဒီနေရာမှာ Depth ဆိုတာကတော့ အောက်ဖော်ပြပါပုံရဲ့ အနီရောင် ဘောင်ခတ်ထားတဲ့ အပိုင်းကို ဆိုလိုတာပါ။

YouTube ရဲ့ နောက်တစ်ပိုင်းဖြစ်တဲ့ Ranking အပိုင်းကို ဆက်ပြီးဆွေးနွေးပါမယ်

From Paper

Ranking အပိုင်းမှာတော့ Candidate Generation ကနေထွက်လာတဲ့ ရာဂဏန်းလောက်ရှိတဲ့ Video ကို သက်ဆိုင်ရာ User အတွက် ဘယ် Video က အသင့်တော်ဆုံးလဲ ဆိုတာကို ရွေးချယ်ရမယ့် အပိုင်းပဲဖြစ်ပါတယ်။ ဒီအပိုင်းမှာတော့ Input ဝင်လာမယ့် Video အရေအတွက်ဟာ Candidate Generation ထက် အဆပေါင်းများစွာ နည်းနေတဲ့အတွက် Ranking Model ကို Input အနေနဲ့ သွင်းမယ့် Features တွေကတော့ ကိုယ့်စိတ်ကြိုက်သလောက် များများ သွင်းလို့ရပါတယ်။ Candidate Generation အပိုင်းထက်စာရင် Computation အချိန်က အဆမတန် နည်းသွားလို့ပဲဖြစ်ပါတယ်။ (သန်းဂဏန်း ကနေ ရာဂဏန်း ပြောင်းသွားလို့ပါ။)

Ranking Model ရဲ့ Architecture ကတော့ Candidate Generation နဲ့ဆင်တူပါတယ်။ ကွဲသွားတာကတော့ Softmax Classification အစား Weighted Linear Regression ကို သုံးသွားတဲ့ အပိုင်းပဲဖြစ်ပါတယ်။ Ranking ကို Tunning လုပ်မယ့် Objective Function အနေနဲ့ကတော့ သက်ဆိုင်တဲ့ User တစ်ယောက်မှာ သက်ဆိုင်တဲ့ Video ကို ဘယ်လောက်ကြာကြာ ကြည့်မှာလဲ ဆိုတာကို ခန့်မှန်းမယ့် Objective Function ဖြစ်သွားပါတယ်။ အဲဲ့လို ခန့်မှန်းပြီးရလာတဲ့ Video Score ပေါ်မူတည်ပြီး User ဆီကို အကြံပေး၊ မိတ်ဆက်ပေးမှာ ဖြစ်ပါတယ်။

ဒီနေရာမှာ စိတ်ဝင်စားဖို့ကောင်းတာ တစ်ခုကတော့ click rate (User ဟာ အဲ့ဒီ Video link ကို Click လုပ်မှာလား မလုပ်ဘူးလား)ကို Input အနေနဲ့ မယူဘဲ Video Watch Time ကို ယူပြီးတွက်ထားတာ ဖြစ်ပါတယ်။ Click Rate ကို ယူပြီးတွက်ရင် “clickbias” ရှိနိုင်တယ်ဆိုပြီး စာတမ်းထဲမှာ ဖော်ပြထားပါတယ်။

From paper

Paper ထဲမှာတော့ Feature engineering တွေကို ဘယ်လို လုပ်သွားတယ်။ စတာတွေ အကျယ်တစ်ဝန့် ရှင်းပြထားပါတယ်။ ဒီ Paper ကတော့ တော်တော်ကြာပြီ ဖြစ်တဲ့အတွက် သူတို့ရှင်းပြထားတဲ့ Feature Engineering နည်းတော်တော်များများဟာ လက်ရှိ Machine Learning Engineer တွေ သိထားပြီးသားလို့ ယူဆပါတယ်။ ဘာတွေလည်းဆိုတော့ Hyperplane transformation တွေ၊ Normalization အကြောင်းတွေ၊ Continuous feature နဲ့ Discrete feature တွေကို ဘယ်လို ကိုင်တွယ်ဖြေရှင်းတာတွေ ပြီးတော့ Model weights တွေကို နည်းအောင် Share weighting တွေ လုပ်တာတွေ ရှင်းပြထားပါတယ်။ အဲ့အပိုင်းတွေ စိတ်ဝင်စားရင်တော့ Paper ကို ဝင်ဖတ်ကြဖို့ တိုက်တွန်းပါရစေ။ ကျွန်တော်ကတော့ ထပ်ပြီးမရှင်းတော့ပါဘူး။

Ranking Model အပိုင်းမှာ ကျွန်တော့် အတွက် စိတ်အဝင်စားဆုံး အပိုင်းကတော့ Ranking Score ကို တွက်တဲ့ အပိုင်းပဲဖြစ်ပါတယ်။ Ranking Score ကိုတော့ Weighted Logistic Regression ကို အသုံးပြုပြီး Model က Expected Watch Time (Video ကို ဘယ်လောက်ကြာကြာ ကြည့်မှာလဲ) ဆိုတဲ့ Odds ကို Learning လုပ်စေတဲ့ အပိုင်းပဲဖြစ်ပါတယ်။

ဒီနေရာမှာ Logistic Regression ကို Input လုပ်တဲ့ Weight တွက်ပုံတွက်နည်းကတော့ User က Video link ကို click လုပ်ပြီး ဘယ်လောက်ကြာကြာ ကြည့်ခဲ့လည်း ပေါ်မူတည်ပြီး Score ကိုတွက်ပါတယ်။ Scoring တွက်ပုံတွက်နည်းကတော့ စာတမ်းမှာ အသေးစိတ် မရှင်းထားပါဘူး။ ဒါပေမယ့် တွက်တဲ့ နည်းတွေ အမျိုးမျိုးရှိနိုင်တဲ့ အပြင် တွက်ရတာလည်း အဲ့လောက်ထိ မရှုပ်ဘူးလို့တော့ ကျွန်တော်ထင်ပါတယ်။ Negative impression (non-click video) တွေကိုတော့ တန်းတူ weight ပေးထားပါတယ်။ ဥပမာ 1 ဆိုပါစို့။ ဒါဆိုရင် Positive impression ရဲ့ weight ကတော့ ကျိန်းသေ 1 ထက်များရမှာပါ။

Expected watch time ရဲ့တွက်ပုံတွက်နည်း အသေးစိတ်ကိုတော့ စာတမ်းမှာ သေသေချာချာ မဖော်ပြထားပါဘူး။ E[T](1+P) နဲ့ညီတယ်ဆိုပြီးပြောသွားပါတယ်။ ပြီးတော့ ထူးခြားတာ တစ်ခုကတော့ Serving လုပ်တဲ့အချိန်မှာ Ranking Score ကိုတော့ e**x နဲ့ တွက်တယ်လို့ ပြောသွားပါတယ်။

Training and Serving Calculation

ကျွန်တော်တို့ ပုံမှန်ဆိုရင် Training နဲ့ Serving လုပ်တဲ့အချိန််မှာ Classification score ပဲဖြစ်ဖြစ် Regression value ပဲဖြစ်ဖြစ် တွက်တဲ့အချိန်မှာ အသုံးပြုခဲ့တဲ့ Formula က တူရမှာပါ။ ဒါပေမယ့် YouTube ရဲ့ Ranking Model မှာတော့ သုံးခဲ့တဲ့ Formula တွေ ကွဲပြားနေတာ တွေ့ရပါတယ်။ Weighted Logistic Regression, e** (Wx+b), Expected Watch Time နဲ့ Odds တွေက ဘယ်လို ပတ်သက်နေတာလဲဆိုတာ စိတ်ဝင်စားစရာပါပဲ။ ဒီတော့ အဲ့အပိုင်းကို ကျွန်တော် ဆွေးနွေးသွားချင်ပါတယ်။

ကျွန်တော်တို့ YouTube Ranking Mode concept တွေကို နားလည်ဖို့ အရင်ဆုံး Logistic Regression Formula ကို ပြန်ကြည့်ရအောင်ဗျာ။

Logistic Regression Formula

ကျွန်တော်တို့ အားလုံးသိပြီးသားပါ။ အပေါ်က Formula ကို တန်ဖိုးထည့်လိုက်ရင် [0,1] ကြား ရလဒ်ကို ရကြမှာပါ။

Odds ဆိုတာကတော့ ဖြစ်စဉ်တစ်ခုရဲ့ ဖြစ်ပေါ်နိုင်ချေ အချိုး (သို့) ဖြစ်ပေါ်နိုင်ချေ ရလဒ် ကိုဖော်ပြတာပါ။

Odds ရဲ့ Formula ပါ

ကျွန်တော်တို့ Odds ကို log ယူလိုက်ရင် Logit ရပါတယ်။

Logit definition

ကျွန်တော်တို့ Linear Regression မှာဆိုရင် Equation (1) လို အရေးအသားကို တွေ့ဖူးကြမှာပါ။

Equation (1) ရဲ့ ရလဒ်သည် -inf ကနေ +inf ထိဖြစ်နိုင်ပါတယ်။ နောက်တစ်ခု logit ကလည်း သူ့ရဲ့ ရလဒ်သည် -inf ကနေ +inf ထိဖြစ်နိုင်ပါတယ်။

ဒီတော့ တစ်ကယ်လို့သာ Equation (1) နဲ့ Equation (2) ကို ညီတယ်လို့ ယူဆလိုက်ရင် Equation (3) ရလာမှာပါ။

Equation (3) မှာ p တန်ဖိုးကို ရှာလိုက်ရင် Equation (4) ရလာမှာပါ။ Equation (4) သည် Logistic Regression, equation (5) နဲ့ တူပါတယ်။ ဒီတော့ ကျွန်တော်တို့ Linear Regression ကနေ Logistic Regression ပြောင်းလဲလာပုံကို တွက်ပြီးသားဖြစ်ပါတယ်။ ဒီတော့ p ဖြစ်တဲ့ Ground Truth တန်ဖိုးရဲ့ Probability space ကို ကျွန်တော်တို့ Backpropagation algorithm အသုံးပြုပြီး Approximation Sampling လုပ်လို့ရပါတယ်။

Training မှာ အသုံးပြုလိုက်တဲ့ Loss function သည် Equation (5) ကို Modified လုပ်ထားတဲ့ Weighted Logistic Regression ပဲဖြစ်ပါတယ်။

ဒီတော့ Odd တန်ဖိုးကို ရှာလိုက်ခြင်းအားဖြင့် ကျွန်တော်တို့ YouTube ရဲ့ Serving formulat ကို ရပါတယ်။

Odds = e**Wx+b

တစ်နည်းအားဖြင့်ပြောရရင် YouTube ရဲ့ Serving Function သည် Odds (Expected Watch Time) ကိုရှာတာပဲ ဖြစ်ပါတယ်။

ဒါနဲ့ Expected watch time E(T) နဲ့ Odds သည် ဘယ်လို ပတ်သက်ဆက်နွယ်နေပါလိမ့်။

ကျွန်တော်တို့ Odds ရဲ့ အဓိပ္ပါယ်ဖွင့်ဆိုချက်ကို ပြန်ကြည့်ရအောင်။

Odds ဆိုတာကတော့ ဖြစ်စဉ်တစ်ခုရဲ့ ဖြစ်ပေါ်နိုင်ချေ အချိုး (သို့) ဖြစ်ပေါ်နိုင်ချေ ရလဒ် ကိုဖော်ပြတာပါ။

Weighted Logistic Regression မှာ အသုံးပြုခဲ့တဲ့ Positive weight (w) သည် အဲ့ဒီ Positive video အတွက် positive weight (w) ဆ ပိုပြီး ဖြစ်ပေါ်စေနိုင်တယ် ဆိုတဲ့ အဓိပ္ပါယ် သက်ရောက်ပါတယ်။ လွယ်လွယ်ပြောရရင် Negative Impression ထက် Positive Impression ကို ပိုလိုချင်တဲ့အတွက် positive weight ကို Negative weight ထက်များအောင် ထည့်မယ်ဆိုတဲ့ သဘောပါ။ ဒီတော့ Odds formula သည် အောက်ဖော်ပြပါအတိုင်း ပြောင်းလဲထားပါတယ်။

စာတမ်းထဲမှာ ဖော်ပြထားတာကတော့ p (user က video link ကို click နိုင်မယ့် ဖြစ်နိုင်ချေ) တန်ဖိုးသည် အရမ်းကို နည်းပါတယ်။ (သန်းချီသော Video ထဲကနေ video တစ်ခုကို click နှိပ်မယ့် အခွင့်အရေး အလွန်ကို နည်းတယ် မဟုတ်လားခင်ဗျ။)

ဒါကြောင့် Odds formula ကို ဆက်ပြီးပြောင်းပါက အောက်ဖော်ပြပါ Formula ကိုရရှိမှာ ဖြစ်ပါတယ်။

ဒီနေရာမှာ YouTube သည် weight (wi) ကို Viewing Time နဲ့တွက်ထားတဲ့အတွက်ကြောင့် ကျွန်တော်တို့ wi အစား Ti လို့ပြောင်းရေးလို့ရပါတယ်။

Viewing Time (Ti) နဲ့ Video link ကို click နိုင်တဲ့ Probability ကို မြှောက်ထားတာ ဖြစ်တဲ့အတွက်ကြောင့် ရလာတဲ့ ရလဒ်သည် အဲ့ဒီ Video ကို ဘယ်လောက်ကြာကြာ ကြည့်နေတယ်ဆိုတဲ့ Expected watching time, E(Ti) ပဲဖြစ်ပါတယ်။

ဒါကြောင့် Serving မှာ တွေ့ရတဲ့ e**Wx+b သည် E(T)၊ တစ်နည်းအားဖြင့် Expected Watching Time ကိုတွက်တာပဲဖြစ်ပါတယ်။

ဒီတော့ တတ်သိပညာရှင်တွေအနေနဲ့ YouTube ရဲ့ Ranking Model တွက်ပုံတွက်နည်းလေး နားလည် သဘောပေါက်ကြပြီလို့ မျှော်လင့်ပါတယ်။

နောက်ဆုံးအနေနဲ့ကတော့ Ranking Model မှာ Candidate Generation Model လို Deep Neural Network ရဲ့ Depth ကို သူတို့ စမ်းထားပါတယ်။ Depth များတဲ့ Model သည် Depth နည်းတဲ့ Model ထက် performance ပိုကောင်းကြောင်း စာတမ်းမှာ ဖော်ပြထားပါတယ်။

weighted, per-user loss တန်ဖိုးနည်းလေ ပိုကောင်းလေလို့ အဓိပ္ပါယ်ရပါတယ်။

ဟုတ်ပါပြီဗျာ ဒီလောက်ဆိုရင်တော့ ကျွန်တော်တို့ YouTube ရဲ့ Recommender System အလုပ်လုပ်ပုံ အကြမ်းဖျင်းတော့ နားလည် သဘောပေါက်ပြီလို့ ယူဆပါတယ်ခင်ဗျ။ ဒီ စာတမ်းကတော့ ၂၀၁၆ ခုနှစ်က ထုတ်ထားတဲ့ စာတမ်းဖြစ်တဲ့အတွက်ကြောင့် လက်ရှိ YouTube Recommender System သည် ဒီထက်မက ပိုကောင်းတဲ့ နည်းစနစ်တွေ အသုံးပြုနေတယ်ဆိုတာ ကျိန်းသေပါတယ်။

ဘယ်လိုပဲဖြစ်ဖြစ် တတ်သိပညာရှင်များအနေနဲ့တော့ YouTube ရဲ့ Recommender System အလုပ်လုပ်ပုံကို အနည်းနဲ့အများ နားလည်ကြမယ်လို့ ယူဆပါတယ်။ အသေးစိတ် အချက်အလက်ကို သိချင်ရင်တော့ စာတမ်းကို ဖတ်ကြပါလို့ တိုက်တွန်းပါရစေ ခင်ဗျာ။

နောက် Post မှာ ပြန်လည်ဆုံစည်းကြပါမယ်နော်... ကျေးဇူးပါခင်ဗျာ...

--

--

Sai Htaung Kham

Research Engineer working on AI. Make things work beyond its limitation.