„Inside ByteDance’s Monolith: The Engine Powering Smarter, Faster Content Feeds“ santrauka

Autoriai: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Fudan University Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) SANTRAUKA Didelių ir realaus laiko rekomendacijų sistemos kūrimas yra gyvybiškai svarbus daugeliui verslų, grindžiamų laiku jautriais klientų atsiliepimais, tokių kaip trumpųjų vaizdo įrašų reitingavimas ar internetinė reklama. Nepaisant plačiai naudojamų gamybos lygio gilaus mokymosi sistemų, tokių kaip Ten-sorFlow ar PyTorch, šios bendrosios paskirties sistemos neatitinka verslo poreikių rekomendacijų scenarijuose dėl įvairių priežasčių: viena vertus, sistemų derinimas su statiniais parametrais ir tankiomis rekomendacijų su dinaminėmis ir retomis ypatybėmis skaičiavimais kenkia modelio kokybei; kita vertus, tokios sistemos yra sukurtos su visiškai atskirtu partijų mokymu ir aptarnavimo etapu, nelemdamos modelio sąveikos su klientų atsiliepimais realiuoju laiku. Dėl šių problemų teko iš naujo peržiūrėti tradicinius metodus ir tyrinėti radikaliai skirtingus projektavimo pasirinkimus. Šiame straipsnyje pristatome 1, sistemą, specialiai pritaikytą mokymui internete. Mūsų projektavimą paskatino mūsų taikomųjų darbo krūvių ir gamybos aplinkos stebėjimai, kurie žymiai skiriasi nuo kitų rekomendacijų sistemų. Mūsų indėlis yra daugybinis: pirma, sukūrėme be kolizijų rikiuotės lentelę su optimizavimais, tokiais kaip išnykstančios rikiuotės ir dažnio filtravimas, siekdami sumažinti jos atminties naudojimą; antra, pateikiame gamybai paruoštą internetinio mokymo architektūrą su dideliu atsparumu gedimams; pagaliau, įrodėme, kad sistemos patikimumą galima keisti realaus laiko mokymosi naudai. Monolith sėkmingai integruota į BytePlus Recommend2 produktą. Monolith 1 ĮVADAS Per pastarąjį dešimtmetį matėme rekomendacijų technologijomis paremtų verslų klestėjimą. Siekiant geresnės klientų patirties, personalizuoto turinio teikimas kiekvienam individualiam vartotojui kaip realaus laiko atsakymas yra bendras šių verslo programų tikslas. Siekiant to, vartotojo naujausios sąveikos informacija dažnai naudojama kaip pagrindinis modelio mokymo įėjimas, nes ji geriausiai atspindi vartotojo profilį ir leidžia prognozuoti vartotojo interesus bei būsimus elgesius. Giluminis mokymasis dominavo rekomendacijų modeliuose [ , , , , , ], nes didžiulis vartotojo duomenų kiekis puikiai tinka masinėms duomenimis valdomoms neuroninėms modeliams. Tačiau pastangos panaudoti gilaus mokymosi galią pramoninio lygio rekomendacijų sistemose nuolat susiduria su problemomis, kylančiomis dėl unikalių realaus pasaulio vartotojų elgesio duomenų ypatybių. Šie duomenys drastiškai skiriasi nuo tų, kurie naudojami įprastose gilaus mokymosi problemose, tokiose kaip kalbos modeliavimas ar kompiuterinė rega, dviem aspektais: 5 6 10 12 20 21 (1) Ypatybės daugiausia yra retų, kategorinių ir dinamiškai besikeičiančių; (2) > Mokymo duomenų pagrindinis pasiskirstymas yra nestacionarus, arba kitaip tariant, koncepto poslinkis . Tokie skirtumai sukėlė unikalių iššūkių tyrėjams ir inžinieriams, dirbantiems su rekomendacijų sistemomis. 1.1 Retumas ir dinamiškumas Rekomendacijų duomenyse daugiausia yra retų kategorinių ypatybių, kai kurios iš jų pasitaiko retai. Įprasta praktika jas susieti su aukštadimense rikiuotės erdvėmis sukelia daugybę problemų: • Skirtingai nei kalbos modeliuose, kur žodžio dalių skaičius yra ribotas, vartotojų ir reitinguojamų elementų skaičius yra daug didesnis. Tokia didžiulė rikiuotės lentelė vargu ar tilps į vieno serverio atmintį; • Dar blogiau, tikimasi, kad rikiuotės lentelės dydis laikui bėgant didės, atsirandant vis daugiau vartotojų ir elementų, o tokios sistemos kaip [ , ] naudoja fiksuoto dydžio tankius kintamuosius, kad atspindėtų rikiuotės lentelę. 1 17 Praktiškai daugelis sistemų naudoja mažo susidūrimų tikimybės maišą [ , ] kaip būdą sumažinti atminties naudojimą ir leisti ID augti. Tai grindžiama per daug idealistiškais prietarais, kad ID rikiuotės lentelėje yra pasiskirstę vienodai pagal dažnį, o susidūrimai yra nekenksmingi modelio kokybei. Deja, tai retai būna tiesa realaus pasaulio rekomendacijų sistemoje, kur nedidelė vartotojų ar elementų grupė turi žymiai daugiau pasikartojimų. Organiškai didėjant rikiuotės lentelės dydžiui, didėja maišos rakto susidūrimų tikimybė ir tai pablogina modelio kokybę 3 6 . Todėl gamybos lygio rekomendacijų sistemoms natūraliai reikia galimybės įtraukti kuo daugiau ypatybių į savo parametrus ir gebėti lanksčiai reguliuoti vartotojų ir elementų, kuriuos jos stengiasi saugoti, skaičių. 1.2 Nestacionarus pasiskirstymas Vaizdiniai ir lingvistiniai modeliai vargu ar vystosi šimtmečių laikotarpiu, o tas pats vartotojas, besidomintis viena tema, gali pakeisti savo entuziazmą kiekvieną kitą minutę. Dėl to vartotojų duomenų pagrindinis pasiskirstymas yra nestacionarus, reiškinys, paprastai vadinamas koncepto poslinkiu . Intuityviai tariant, informacija iš naujesnės istorijos gali veiksmingiau prisidėti prie vartotojo elgesio pokyčių prognozavimo. Norint sumažinti koncepto poslinkio poveikį, aptarnavimo modeliai turi būti atnaujinami naujausiais vartotojų atsiliepimais kuo arčiau realaus laiko, kad atspindėtų naujausius vartotojo interesus. Atsižvelgdami į šiuos skirtumus ir pastebėję problemas, kylančias mūsų gamyboje, sukūrėme , didelio masto rekomendacijų sistemą, skirtą šioms problemoms spręsti. Atlikome išsamius eksperimentus, kad patvirtintume ir patobulintume savo projektą gamybos aplinkoje. Monolith gali Monolith (1) Suteikti visą išraiškingumo galią retoms ypatybėms, projektuojant be kolizijų maišos lentelę ir dinaminį ypatybių išmetimo mechanizmą; (2) > Grąžinti aptarnavimo atsiliepimus į mokymą realiuoju laiku su internetiniu mokymu. Šių architektūrinių pajėgumų dėka Monolith nuolat lenkia sistemas, kurios naudoja maišos triukus su kolizijomis, turėdamos panašų atminties naudojimą ir pasiekdamos naujausią aptarnavimo AUC be per didelio mūsų serverių skaičiavimo galios apkrovimo. Likusi straipsnio dalis organizuojama taip. Pirma, 2 skyriuje išsamiai aprašome projektavimo detales, kaip Monolith sprendžia esamus iššūkius su be kolizijų maišos lentelėmis ir realaus laiko mokymu. Eksperimentai ir rezultatai bus pateikti 3 skyriuje, kartu su gamyboje išbandytomis išvadomis ir diskusijomis apie laiko jautrumo, patikimumo ir modelio kokybės kompromisus. 4 skyriuje apibendrinami susiję darbai ir lyginami su Monolith. 5 skyriuje apibendrinamas šis darbas. 2 PROJEKTAVIMAS Monolith bendra architektūra paprastai seka TensorFlow’s distribuotą Darbuotojo- arametrų erverio nustatymą (1 pav. Darbuotojo-PS architektūroje mašinoms skiriamos skirtingos rolės; Darbuotojų mašinos atsako už skaičiavimus pagal grafiką, o PS mašinos saugo parametrus ir juos atnaujina pagal Darbuotojų apskaičiuotus gradientus. P S 2). Rekomendacijų modeliuose parametrai skirstomi į du rinkinius: tankius ir retus. Tankūs parametrai yra giluminio neuroninio tinklo svoriai/kintamieji, o reti parametrai nurodo rikiuotės lenteles, kurios atitinka retas ypatybes. Mūsų projekte tiek tankūs, tiek reti parametrai yra TensorFlow grafiko dalis ir saugomi parametrų serveriuose. Panašiai kaip TensorFlow’s Kintamasis tankiems parametrams, sukūrėme rinkinį labai efektyvių, be kolizijų ir lanksčių HashTable operacijų retoms parametrėms. Kaip priedas prie Tensor-Flow apribojimo, kylantis dėl mokymo ir išvedimo atskyrimo, Monolith lanksčiai plečiama internetinio mokymo sistema yra suprojektuota efektyviai sinchronizuoti parametrus iš mokymo-PS į internetinio aptarnavimo-PS per trumpus intervalus, su modelio atsparumo garantija, suteikta gedimų tolerancijos mechanizmo. 2.1 Maišos lentelė Pirmoji mūsų principas projektuojant retų parametrų atvaizdavimą yra vengti skirtingų ID informacijos sutraukimo į tą pačią fiksuoto dydžio riiduotę. Dinaminio dydžio riiduotės lentelės imitavimas su paruoštu TensorFlow kintamuoju neišvengiamai sukelia ID susidūrimą, kuris pablogėja atsirandant naujiems ID ir didėjant lentelei. Todėl, užuot rėmęsi kintamuoju, sukūrėme naują raktų-vertybių HashTable mūsų retoms parametrėms. Mūsų HashTable naudoja Cuckoo Hashmap [ ] pagrinde, kuri leidžia įterpti naujus raktus be susidūrimo su esamais. Cuckoo Hashing pasiekia blogiausiu atveju 𝑂 (1) laiko sudėtingumą paieškoms ir ištrynimams, ir tikėtiną amortizuotą 𝑂 (1) laiko įterpimams. Kaip parodyta 3 pav. , ji saugo dvi lenteles 𝑇0, 𝑇1 su skirtingomis maišos funkcijomis ℎ0 (𝑥), ℎ1 (𝑥), ir elementas būtų saugomas vienoje iš jų. Bandant įterpti elementą 16 3 𝐴 į 𝑇0, ji pirmiausia bando įterpti 𝐴 į ℎ0 (𝐴); Jei ℎ0 (𝐴) užimta kito elemento 𝐵, ji išstums 𝐵 iš 𝑇0 ir bandys įterpti 𝐵 į 𝑇1 su ta pačia logika. Šis procesas kartosis, kol visi elementai stabilizuosis, arba įvyks perskirstymas, kai įterpimas pateks į ciklą. Atminties naudojimo sumažinimas taip pat yra svarbus mūsų projekto aspektas. Paprastas kiekvieno naujo ID įterpimas į HashTable greitai išeikvos atmintį. Stebėjimai realiuose gamybos modeliuose padėjo padaryti dvi išvadas: (1) ID, kurie pasirodo tik kelis kartus, turi ribotą įtaką modelio kokybės gerinimui. Svarbus pastebėjimas yra tai, kad ID pasiskirsto pagal ilgą uodegą, kur populiarūs ID gali pasitaikyti milijonus kartų, o nepopuliarūs – ne daugiau dešimties kartų. Rikiuotės, atitinkančios šiuos nepopuliarius ID, yra nepakankamai apmokytos dėl nepakankamo mokymo duomenų kiekio, ir modelis negalės atlikti gero įvertinimo remdamasis jais. Galiausiai šie ID greičiausiai neturės įtakos rezultatui, todėl modelio kokybė nenukentės pašalinus šiuos mažo pasikartojimo ID; (2) Senos istorijos duomenys retai prisideda prie dabartinio modelio, nes daugelis jų niekada nebuvo aplankyti. Tai gali būti dėl to, kad vartotojas nebėra aktyvus, arba trumpas vaizdo įrašas yra pasenęs. Šių ID rieduočių saugojimas negali padėti modeliui jokiu būdu, tik veltui ištuštinti mūsų PS atmintį. Remdamiesi šiais pastebėjimais, sukūrėme kelis ypatybių ID filtravimo heuristikus, kad efektyviau panaudotume atmintįHashTable implementacijoje: (1) ID filtruojami prieš juos priimant į rieduočių lenteles. Mes turime du filtravimo metodus: Pirmiausia filtruojame pagal jų pasikartojimų skaičių prieš juos įterpiant kaip raktus, kur pasikartojimų slenkstis yra reguliuojamas hiperparametras, skiriasi kiekvienam modeliui; Be to, naudojame tikimybinius filtrus, kurie padeda dar labiau sumažinti atminties naudojimą; ![#4 pav.: Transliavimo variklis. Informacijos atsiliepimo kilpa iš [Vartotojas → Modelio serveris → Mokymo darbuotojas → Modelio serveris → Vartotojas] užtruks ilgai, sekdama Partijų mokymo keliu, o Internetinis mokymas uždarys kilpą greičiau.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID yra laiku pažymimi ir nustatomi kaip pasibaigę po tam tikro nenaudojimo laikotarpio. Pasibaigimo laikas taip pat yra reguliuojamas kiekvienai rieduočių lentelei, leidžiant atskirti ypatybes, kurių jautrumas istorinei informacijai skiriasi. Mūsų implementacijoje HashTable yra įgyvendinta kaip „TensorFlow“ resursų operacija. Panašiai kaip ir Kintamasis, paieškos ir atnaujinimai taip pat įgyvendinami kaip gimtosios „TensorFlow“ operacijos, siekiant lengvesnio integravimo ir geresnio suderinamumo. 2.2 Internetinis mokymas Monolith sistemoje mokymas yra padalintas į du etapus (1 pav. 1): (1) Partijų mokymo etapas. Šis etapas veikia kaip įprastas TensorFlow mokymo ciklas: kiekviename mokymo žingsnyje mokymo darbuotojas skaito vieną mini-partiją mokymo pavyzdžių iš saugyklos, prašo parametrų iš PS, atlieka priekinę ir atgalinę praeigas ir galiausiai įkelia atnaujintus parametrus į mokymo PS. Šiek tiek skiriasi nuo kitų įprastų gilaus mokymosi užduočių, mes savo duomenų rinkinį mokome tik vieną kartą. Partijų mokymas naudingas mokant istorinius duomenis, kai keičiame savo modelio architektūrą ir perinstaliuojame modelį; (2) Internetinio mokymo etapas. Po to, kai modelis yra įdiegtas internetiniam aptarnavimui, mokymas nesustoja, bet pereina į internetinio mokymo etapą. Užuot skaitęs mini-partijų pavyzdžius iš saugyklos, mokymo darbuotojas naudoja realaus laiko duomenis skraidydamas ir atnaujina mokymo PS. Mokymo PS periodiškai sinchronizuoja savo parametrus su aptarnavimo PS, kurie nedelsiant įsigalioja vartotojo pusėje. Tai leidžia mūsų modeliui interaktyviai prisitaikyti pagal vartotojo atsiliepimus realiuoju laiku. Monolith yra sukurta su galimybe sklandžiai perjungti tarp partijų mokymo ir internetinio mokymo. Tai įgalinama mūsų transliavimo variklio projekto, kaip parodyta 4 pav. 2.2.1 Transliavimo variklis. 4. Mūsų projekte naudojame vieną Kafka [ ] eilę, kad įrašytume vartotojų veiksmus (pvz., Paspaudimas ant elemento ar patiktukas) ir kitą Kafka eilę ypatybėms. Variklio šerdis yra Flink [ ] transliavimo darbas, skirtas internetiniam ypatybių jungimui. Internetinis jungiklis sujungia ypatybes su etiketėmis iš vartotojų veiksmų ir generuoja mokymo pavyzdžius, kurie tada įrašomi į Kafka eilę. Mokymo pavyzdžių eilę naudoja tiek internetinis mokymas, tiek partijų mokymas: 13 4 Internetiniam mokymui mokymo darbuotojas tiesiogiai skaito duomenis iš Kafka eilės; Partijų mokymui duomenų išmetimo darbas pirmiausia išmes duomenis į HDFS [ ]; Kai duomenys HDFS kaupiasi iki tam tikro kiekio, mokymo darbuotojas nuskaito duomenis iš HDFS ir atlieka partijų mokymą. 18 Atnaujinti parametrai mokymo PS bus įkeliami į aptarnavimo PS pagal parametrų sinchronizavimo grafiką. Realiojo pasaulio programose vartotojų veiksmų žurnalas ir ypatybės transliuojamos į internetinį jungiklį (5 pav. be laiko tvarkos garantijos. Todėl naudojame unikalų raktą kiekvienai užklausai, kad vartotojo veiksmas ir ypatybės galėtų teisingai susieti. 2.2.2 Internetinis jungiklis. 5) Vartotojo veiksmo vėlavimas taip pat gali būti problema. Pavyzdžiui, vartotojas gali užtrukti kelias dienas, kol nuspręs nusipirkti elementą, kurį jam rodė prieš kelias dienas. Tai yra iššūkis jungikliui, nes jei visos ypatybės būtų laikomos talpykloje, ji tiesiog netilptų į atmintį. Mūsų sistemoje diskiniame klavišų-vertybių saugykloje saugomos ypatybės, kurios laukia ilgiau nei tam tikrą laikotarpį. Kai atkeliauja vartotojo veiksmų žurnalas, jis pirmiausia ieško vidinėje talpykloje, o tada ieško klavišų-vertybių saugykloje, jei talpyklėje nerandama. Kita problema, kylanti realiojo pasaulio programose, yra ta, kad neigiamų ir teigiamų pavyzdžių pasiskirstymas yra labai nelygus, kur buvusių skaičius gali būti kelis kartus didesnis nei pastarųjų. Siekiant užkirsti kelią teigiamiems pavyzdžiams būti užgožtiems neigiamų, įprasta strategija yra neigiamas mėginių ėmimas. Tai neabejotinai pakeistų apmokyto modelio pagrindinį pasiskirstymą, jį pakreipdama link didesnės teigiamų prognozių tikimybės. Kaip kompensaciją, mes taikome logaritmo santykio korekciją [ ] aptarnavimo metu, užtikrindami, kad internetinis modelis būtų nešališkas originalaus pasiskirstymo vertintojas. 19 Internetinio mokymo metu Monolith mokymo klasteris nuolat gauna duomenis iš internetinio aptarnavimo modulio ir atnaujina parametrus mokymo PS. Kritiškas žingsnis, leidžiantis internetiniam aptarnavimo PS pasinaudoti šiais naujausiais apmokytais parametrais, yra atnaujintų modelio parametrų sinchronizavimas. Gamybos aplinkoje susiduriame su keliais iššūkiais: 2.2.3 Parametrų sinchronizavimas. Internetinio aptarnavimo PS esantys modeliai negali sustoti aptarnauti atnaujinimo metu. Mūsų gamybos modeliai paprastai yra keli terabaitai dydžio, todėl visų parametrų pakeitimas užtrunka. Būtų nepriimtina sustabdyti internetinį PS nuo modelio aptarnavimo atnaujinimo metu, o atnaujinimai turi būti atliekami skraidydami; Viso kelių terabaitų modelio perkėlimas iš mokymo PS į internetinį aptarnavimo PS sukurtų didelį spaudimą tiek tinklo pralaidumui, tiek PS atminties resursams, nes jam priimti reikėtų dvigubai didesnės atminties, nei naujai atvykstančiam modeliui. Kad internetinis mokymas galėtų plėstis iki mūsų verslo scenarijaus masto, Monolith sistemoje sukūrėme laipsnišką, skraidomą periodinio parametrų sinchronizavimo mechanizmą, pagrįstą keliais pastebimais mūsų modelių ypatumais: (1) Reti parametrai dominuoja rekomendacijų modelių dydžio atžvilgiu; (2) > Per trumpą laiko langą tik nedidelė ID dalis yra apmokoma ir jų rieduotės atnaujinamos; (3) > Tankūs kintamieji juda daug lėčiau nei reti rieduotės. Taip yra todėl, kad momentinių optimizatorių momentų kaupimas didinamas milžiniško rekomendacijų mokymo duomenų kiekio, o per vieną duomenų partiją atnaujinama tik kelios retos rieduotės. (1) ir (2) leidžia mums išnaudoti retus atnaujinimus visuose ypatybių ID. Monolith sistemoje mes palaikome paliestų raktų maišos rinkinį, kuris atspindi ID, kurių rieduotės buvo apmokytos nuo paskutinio parametrų sinchronizavimo. Mes perkeliame retų parametrų pogrupį, kurių raktai yra paliestų raktų rinkinyje, su minutės lygio laiko intervalu iš mokymo PS į internetinį aptarnavimo PS. Šis gana mažas papildomų parametrų atnaujinimo paketas yra lengvas tinklo perdavimui ir nesukelia staigaus atminties šuolio sinchronizavimo metu. Mes taip pat išnaudojame (3) toliau mažindami tinklo I/O ir atminties naudojimą, nustatydami agresyvesnį sinchronizavimo grafiką retiems parametrams, o tankius parametrus atnaujindami rečiau. Tai gali mums sukelti situaciją, kai aptarnaujami tankūs parametrai yra gana pasenusi versija, palyginti su reta dalimi. Tačiau toks neatitikimas gali būti toleruojamas dėl priežasties, nurodytos (3), nes nepastebėta jokių akivaizdžių nuostolių. 2.3 Gedimų tolerancija Kaip gamybos sistema, Monolith suprojektuota su galimybe atkurti PS jo gedimo atveju. Įprastas pasirinkimas gedimų tolerancijai yra periodiškai išsaugoti modelio būklę ir atkurti iš naujausio išsaugojimo, kai aptinkamas PS gedimas. Išsaugojimo dažnio pasirinkimas turi du pagrindinius poveikius: (1) Modelio kokybė. Intuityviai tariant, modelio kokybė mažiau nukenčia nuo naujausios istorijos praradimo, didėjant išsaugojimo dažniui. (2) > Skaičiavimo viršutiniai sluoksniai. Milžiniško dydžio modelio išsaugojimas nėra nemokamas. Jis sukelia didelius atminties kopijavimo ir disko I/O. Kaip kompromisas tarp modelio kokybės ir skaičiavimo viršutinių sluoksnių, Monolith kasdien išsaugo visus mokymo PS. Nors PS praras vienos dienos atnaujinimus gedimo atveju, eksperimentų metu nustatėme, kad našumo pablogėjimas yra toleruojamas. Analizuosime PS patikimumo poveikį kitame skyriuje. 3 VERTINIMAS Norėdami geriau suprasti mūsų siūlomo projekto naudą ir kompromisus, atlikome keletą eksperimentų gamybos mastu ir A/B testavimą su gyva aptarnavimo apkrova, kad įvertintume ir patvirtintume Monolith iš skirtingų perspektyvų. Mūsų tikslas yra atsakyti į šiuos klausimus per mūsų eksperimentus: (1) Kiek naudos galime gauti iš be kolizijų HashTable? (2) > Kiek svarbus yra realaus laiko internetinis mokymas? (3) > Ar Monolith parametrų sinchronizavimo projektavimas yra pakankamai patikimas didelio masto gamybos scenarijuje? Šiame skyriuje pirmiausia pristatome mūsų eksperimentines nuostatas, o tada išsamiai aptariame rezultatus ir mūsų išvadas. 3.1 Eksperimentinė sąranka Kaip aprašyta 2.1 skyriuje Monolith rikiuotės lentelės yra įgyvendintos kaip be kolizijų HashTables. Norėdami įrodyti būtinybę vengti kolizijų rikiuotės lentelėse ir kiekybiškai įvertinti mūsų be kolizijų implementacijos naudą, atlikome dvi eksperimentų grupes „Movielens“ duomenų rinkinyje ir mūsų vidiniame gamybos duomenų rinkinyje: 3.1.1 Rikiuotės lentelė. 2.1, (1) ml-25m duomenų rinkinys [ ]. Tai standartinis viešasis filmų reitingų duomenų rinkinys, turintis 25 milijonus reitingų, apimantis maždaug 162 000 vartotojų ir 62 000 filmų. MovieLens 11 • *Etikečių priešapdorojimas*. Originalūs etikečių reitingai nuo 0,5 iki 5,0, o gamyboje mūsų užduotys dažniausiai apima dvejetainius signalus iš vartotojų. Norėdami geriau imituoti mūsų gamybos modelius, konvertavome skalės etiketes į dvejetaines etiketes, laikydami rezultatus ≥ 3,5 kaip teigiamus pavyzdžius, o likusius – kaip neigiamus pavyzdžius. • Modelis ir metrikos. Įgyvendinome standartinį DeepFM modelį, dažnai naudojamą modelį rekomendacijų problemoms spręsti. Jis susideda iš FM komponento ir tankaus komponento (6 pav.). Prognozės vertinamos pagal AUC, nes tai yra pagrindinis realių modelių matavimas. • Rikiuotės kolizijos. Šiame duomenų rinkinyje yra maždaug 160 tūkst. vartotojų ID ir 60 tūkst. filmų ID. Norėdami palyginti su be kolizijų rikiuotės lentelės implementacijos vers