Ukurasa wetu wa kwanza wa video sasa unaonyesha seti mpya ya mapendekezo 24 kila unapofanya refresh, kutokana na kubadilisha mfumo kwenda weighted reservoir sampling (A-Res). Mabadiliko haya yaliondoa tatizo la “grid ileile kila wakati” ambalo lilikuwa likisumbua mtiririko wetu wa awali uliopangwa kwa alama (score-sorted feed).

Kwa nini mbinu ya zamani iliharibu uzoefu wa mtumiaji

Kila baada ya saa mbili, tunachukua video zinazovuma zaidi kutoka mikoa minane na kuweka matokeo hayo kwenye jedwali la SQLite. Suluhisho la kawaida lilikuwa kupanga seti nzima—kwa kutumia alama ya uhusiano (relevance score)—na kuchukua 24 za juu zaidi. Mbinu hiyo inahakikisha kuwa vitu vyenye alama za juu zaidi vinaonekana, lakini pia inahakikisha kuwa vinabaki hapo. Klipu moja inayovuma (viral) inaweza kutawala nafasi ya 1 kwa siku nyingi, na watumiaji huona gridi ileile kila wanapofungua upya ukurasa.

Zaidi ya uzoefu wa kuchosha, kupanga jedwali zima kwa kila ombi kunailazimisha SQLite kupakia muundo mkubwa wa muda kwenye kumbukumbu (memory), jambo ambalo ni upotezaji wa rasilimali.

Faida za weighted reservoir sampling kwetu

Weighted reservoir sampling inatatua matatizo mawili kwa wakati mmoja:

  1. Upya wenye upendeleo (Freshness with bias) – nafasi ya video moja kuchaguliwa inategemea uzito wake (kwa mfano, alama ya uhusiano). Video yenye uzito mara mbili zaidi ina uwezekano mara mbili zaidi kuonekana, lakini hakuna kitu kinachohakikishwa nafasi.
  2. Ufanisi wa kumbukumbu (Memory efficiency) – algoriti hii inahifadhi tu "reservoir" yenye ukubwa maalum wa vitu $k$ ($k = 24$ kwa mtiririko wetu). Inachakata mtiririko huo kwa hatua moja tu, hivyo kumbukumbu inabaki kuwa $O(k)$ bila kujali ni kiasi gani cha vitu vinavyokuja.

Wazo kuu ni rahisi. Tunapopitia safu (rows) zinazoingia, tunampa kila kitu funguo ya nasibu (random key) inayojumuisha uzito wake, kisha tunahifadhi vitu $k$ vyenye funguo kubwa zaidi.

Algoriti katika vitendo

Kwa kila video tunafanya:

  1. Tunachagua namba ya nasibu ya usawa $u \in (0, 1)$.
  2. Tunapiga hesabu ya funguo $k = u^{1/\text{weight}}$.
    (Kadiri uzito unavyokuwa mkubwa, ndivyo funguo inayotarajiwa inavyokuwa kubwa zaidi.)
  3. Tunaingiza kitu kwenye min-heap inayohifadhi funguo $k$ za juu zaidi kwa wakati huo.
    Ikiwa heap itazidi ukubwa wa $k$, tunatupa funguo ndogo zaidi.

Mtiririko unapomalizika, heap itakuwa na video 24 ambazo tutaonyesha.

Kushughulikia mipaka ya floating-point

Wakati uzito wa video unakuwa mkubwa sana, $u^{1/\text{weight}}$ hupungua hadi thamani inayoshindana kutofautishwa na 1.0 katika hesabu za double-precision, jambo linalosababisha vitu vingi vizito kushiriki funguo moja na kupoteza nasibu. Suluhisho ni kufanya kazi katika nafasi ya log (log space):

  • Tengeneza log_key = log(u) / weight badala ya fomula ya nguvu (power expression).

Kwa sababu logaritmi hubadilisha kielezi (exponentiation) kuwa kuzidisha, mpangilio wa funguo unahifadhiwa huku ukiepuka tatizo la usahihi (precision cliff). Hesabu hii haichukui gharama yoyote ya ziada.

Orodha ya ukaguzi wa utekelezaji

  • Muundo wa data (Data structure): min-heap (priority queue) yenye ukubwa wa $k$ inahifadhi funguo kubwa kwa ufanisi ($O(\log k)$ kwa kila uingizaji).
  • Aina ya namba (Numeric type): tumia namba za 64-bit floating-point kwa ajili ya $u$ na funguo zinazotegemea log; hutoa usahihi wa kutosha kwa viwango vya kawaida vya uzito.
  • Ukaguzi wa takwimu (Statistical sanity check): fanya jaribio la haraka la Monte-Carlo kwenye seti ndogo ya sampuli. Ikiwa vitu vyenye uzito 10 vinaonekana mara kumi zaidi ya vitu vyenye uzito 1, basi utekelezaji ni sahihi.
  • Mtiririko wa hatua moja (Single-pass streaming): algoriti haihitaji kujua jumla ya idadi ya washiriki mapema, jambo ambalo linaendana vizuri na cursor yetu ya SQLite inayotoa safu moja baada ya nyingine.

Hitimisho

Weighted reservoir sampling inaruhusu huduma ya mapendekezo ya video kuweka ukurasa wake wa kwanza ukiwa mpya, kuheshimu alama za uhusiano, na kutumia kumbukumbu kidogo—yote haya kwa hatua moja tu juu ya maelfu ya washiriki. Kwa kuhamisha hesabu ya funguo kwenye nafasi ya log na kutumia min-heap, mbinu hii inabaki kuwa sahihi na yenye ufanisi mkubwa.