"Inside ByteDance’s Monolith: Variklis, sukuriantis protingesnes, greitesnes turinio naujienas"

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 Sukurti masteliniu ir realaus laiko rekomendacine sistema yra gyvybiškai svarbu daugeliui verslų, kuriuos lemia laiko jautrus klientų atsiliepimas, pavyzdžiui, trumpų vaizdo įrašų reitingavimas ar internetiniai skelbimai. Nepaisant plačiai paplitusių gamybos mastelio gilios mokymosi sistemų, tokių kaip „TensorFlow“ ar „PyTorch“, šios bendrosios paskirties sistemos neatitinka verslo poreikių rekomendacijų scenarijuose dėl įvairių priežasčių: viena vertus, sistemų derinimas pagal statinius parametrus ir tankius skaičiavimus, skirtus rekomendacijoms su dinaminiais ir retais požymiais, kenkia modelio kokybei; kita vertus, tokios sistemos sukurtos taip, kad partijų mokymo ir aptarnavimo etapai būtų visiškai atskirti, neleisiant modeliui realiu laiku sąveikauti su klientų atsiliepimais. Šios problemos paskatino mus iš naujo nagrinėti tradicinius metodus ir tyrinėti radikaliai skirtingus projektavimo pasirinkimus. Šiame straipsnyje pristatome 1, sistemą, pritaikytą internetiniam mokymui. Mūsų projektavimą lėmė mūsų taikomųjų programų darbo krūvių ir gamybos aplinkos stebėjimai, kurie žymi reikšmingą nukrypimą nuo kitų rekomendacijų sistemų. Mūsų indėlis yra daugialypis: pirma, sukūrėme be kolizijų veikiančią įterpimo lentelę su optimizavimu, pvz., išnykstančiais įterpiais ir dažnio filtravimu, kad sumažintume jos atminties naudojimą; antra, pateikiame gamybai paruoštą internetinio mokymo architektūrą su dideliu atsparumu gedimams; galiausiai įrodėme, kad sistemos patikimumą galima paaukoti dėl mokymosi realiu laiku. „Monolith“ sėkmingai integruota į „BytePlus Recommend2“ produktą. Monolith 1 ĮVADAS Pastarąjį dešimtmetį pastebėjome rekomendacijų technologijomis varomų verslų klestėjimą. Siekiant geresnės klientų patirties, personalizuoto turinio teikimas kiekvienam vartotojui kaip realaus laiko atsakymas yra bendras šių verslo programų tikslas. Šiuo tikslu naujausia vartotojo sąveika dažnai naudojama kaip pagrindinis duomenų šaltinis modeliui mokyti, nes tai geriausiai atspindi vartotojo profilį ir leidžia prognozuoti vartotojo interesus bei būsimus veiksmus. Gilusis mokymasis dominuoja rekomendacijų modeliuose [ , , , , , ], nes didžiulis vartotojo duomenų kiekis puikiai tinka masinėms duomenų valdomoms neuroninėms modeliams. Tačiau pramoninio lygio rekomendacijų sistemose, siekiant išnaudoti giliojo mokymosi galią, nuolat kyla problemų dėl unikalių realaus pasaulio vartotojo elgsenos duomenų savybių. Šie duomenys drastiškai skiriasi nuo tų, kurie naudojami tradiciniuose giliojo mokymosi uždaviniuose, tokiuose kaip kalbos modeliavimas ar kompiuterinė rega, dviem aspektais: 5 6 10 12 20 21 (1) Požymiai daugiausia yra reti, kategoriniai ir dinamiškai besikeičiantys; (2) Mokymo duomenų pagrindinė pasiskirstymas yra nejonestatonarus, kitaip tariant, Koncepcijos dreifas . Tokie skirtumai kelia unikalių iššūkių tyrėjams ir inžinieriams, dirbantiems su rekomendacijų sistemomis. 1.1 Retumas ir dinamiškumas Rekomendacijų duomenys daugiausia sudaryti iš retų kategorinių požymių, kai kurie iš kurių pasirodo retai. Įprasta praktika juos susieti su didelio matmenų įterpimo erdve sukelia daugybę problemų: • Skirtingai nei kalbos modeliuose, kur žodžių dalių skaičius yra ribotas, vartotojų ir reitinguojamų elementų skaičius yra daug kartų didesnis. Tokia didžiulė įterpimo lentelė vargu ar tilptų į vieno serverio atmintį; • Dar blogiau, tikimasi, kad įterpimo lentelės dydis laikui bėgant didės, nes bus įtraukiama daugiau vartotojų ir elementų, o tokios sistemos kaip [ , ] naudoja fiksuoto dydžio tankias kintamąsias, kad atspindėtų įterpimo lentelę. 1 17 Praktiškai daugelis sistemų naudoja mažų kolizijų maišą [ , ] kaip būdą sumažinti atminties naudojimą ir leisti didinti ID. Tai grindžiama per daug idealistišku prielaida, kad ID įterpimo lentelėje pasiskirsto vienodai pagal dažnį, o kolizijos nekenkia modelio kokybei. Deja, tai retai pasitaiko realaus pasaulio rekomendacijų sistemoje, kur nedidelė vartotojų ar elementų grupė turi žymiai daugiau pasikartojimų. Organiškai didėjant įterpimo lentelės dydžiui, didėja maišymo kolizijų tikimybė ir tai pablogina modelio kokybę 3 6 . Todėl gamybos mastelio rekomendacijų sistemoms natūraliai reikia gebėti užfiksuoti kuo daugiau požymių savo parametruose ir taip pat turėti galimybę lanksčiai reguliuoti vartotojų ir elementų skaičių, kuriuos jie stengiasi saugoti. 1.2 Nejonestatonarus pasiskirstymas Vizualiniai ir kalbiniai modeliai beveik nesikeičia per šimtmečius, o tas pats vartotojas, besidomintis viena tema, gali pakeisti savo entuziazmą kas minutę. Dėl to vartotojo duomenų pagrindinė pasiskirstymas yra nejonestatonarus, reiškinys, dažnai vadinamas Koncepcijos dreifu . Intuityviai, informacija iš neseniai praeities labiau prisideda prie vartotojo elgsenos pokyčių prognozavimo. Siekiant sumažinti Koncepcijos dreifo poveikį, aptarnavimo modeliai turi būti atnaujinami iš naujausių vartotojų atsiliepimų kuo arčiau realaus laiko, kad atspindėtų naujausią vartotojo interesą. Atsižvelgiant į šiuos skirtumus ir stebint mūsų gamyboje kylančias problemas, sukūrėme , didelio mastelio rekomendacijų sistemą, skirtą šioms problemoms spręsti. Atlikome išsamius eksperimentus, kad patikrintume ir tobulintume savo projektavimą gamybos aplinkoje. Monolith gali Monolith (1) Suteikti visą išraiškingumo galią retiems požymiams projektuojant be kolizijų veikiančią maišymo lentelę ir dinaminį požymių pašalinimo mechanizmą; (2) Grąžinti aptarnavimo atsiliepimus į mokymą realiu laiku su internetiniu mokymu. Šios architektūrinės galimybės „Monolith“ nuolat viršija sistemų, naudojančių maišymo triukus su kolizijomis, panaudodamos panašią atminties vietą ir pasiekia naujausią internetinio aptarnavimo AUC nenaudodamos mūsų serverių skaičiavimo galios. Likusi straipsnio dalis organizuojama taip. Pirma, mes išsamiai apibūdiname projekto detales, kaip „Monolith“ sprendžia esamus iššūkius su be kolizijų veikiančia maišymo lentelėmis ir realaus laiko mokymu 2 skyriuje. Eksperimentai ir rezultatai bus pateikti 3 skyriuje, kartu su gamyboje išbandytomis išvadomis ir tam tikromis diskusijomis apie kompromisus tarp laiko jautrumo, patikimumo ir modelio kokybės. 4 skyriuje apibendrinamas susijęs darbas ir lyginamas su „Monolith“. 5 skyriuje apibendrinamas šis darbas. 2 PROJEKTAVIMAS Bendra „Monolith“ architektūra paprastai seka „TensorFlow“ paskirstytojo darbuotojo- arametrų erverio nustatymą (1 pav. „Worker-PS“ architektūroje mašinoms priskiriami skirtingi vaidmenys; Darbuotojų mašinos yra atsakingos už grafikų nustatytų skaičiavimų atlikimą, o PS mašinos saugo parametrus ir atnaujina juos pagal Darbuotojų apskaičiuotus gradientus. P S 2). Rekomendacijų modeliuose parametrai skirstomi į dvi dalis: tankius ir retus. Tankūs parametrai yra neuroninio tinklo svoriai/kintamieji, o reti parametrai reiškia įterpimo lenteles, atitinkančias retus požymius. Mūsų projekte tiek tankūs, tiek reti parametrai yra „TensorFlow“ grafiko dalis ir saugomi parametrų serveriuose. Panašiai kaip „TensorFlow“ tankių parametrų kintamasis, sukūrėme rinkinį labai efektyvių, be kolizijų veikiančių ir lanksčių „HashTable“ operacijų retiems parametrams. Kaip papildymas „TensorFlow“ apribojimui, kylantiems dėl mokymo ir išvadų atskyrimo, „Monolith“ lanksčiai mastelio internetinis mokymas yra sukurtas efektyviai sinchronizuoti parametrus iš mokymo-PS į internetinio aptarnavimo-PS per trumpus intervalus, o modelio tvirtumas užtikrinamas atsparumo gedimams mechanizmu. 2.1 Maišymo lentelė Pirmasis principas kuriant retų parametrų reprezentaciją yra vengti skirtingų ID informacijos sutalpinimo į tą pačią fiksuoto dydžio įterpimo lentelę. Dinamiško dydžio įterpimo lentelės imitavimas naudojant „TensorFlow Variable“ neišvengiamai sukelia ID koliziją, kuri padidėja atsiradus naujiems ID ir augant lentelės dydžiui. Todėl, užuot statę ant „Variable“, sukūrėme naują raktų-verčių „HashTable“ savo retiems parametrams. Mūsų „HashTable“ naudoja „Cuckoo Hashmap“ [ ] pagrindą, kuris palaiko naujų raktų įterpimą nekonflikuodamas su esamais. „Cuckoo Hashing“ pasiekia blogiausiu atveju 𝑂 (1) laiko sudėtingumą paieškoms ir ištrynimams, o tikėtiną amortizuotą 𝑂 (1) laiką įterpimams. Kaip parodyta 3 pav. jis palaiko dvi lenteles 𝑇0, 𝑇1 su skirtingomis maišymo funkcijomis ℎ0 (𝑥), ℎ1 (𝑥), ir elementas būtų saugomas vienoje iš jų. Bandant įterpti elementą 16 3, 𝐴 į 𝑇0, pirmiausia bandoma įterpti 𝐴 į ℎ0 (𝐴); Jei ℎ0 (𝐴) užimtas kitu elementu 𝐵, 𝐵 būtų pašalinamas iš 𝑇0 ir bandoma įterpti 𝐵 į 𝑇1 pagal tą pačią logiką. Šis procesas kartojamas, kol visi elementai stabilizuojasi, arba atliekamas perskirstymas, kai įterpimas patenka į ciklą. Atminties naudojimo sumažinimas taip pat yra svarbus mūsų dizaino aspektas. Paprastas kiekvieno naujo ID įterpimo į „HashTable“ metodas greitai išeikvos atmintį. Stebėjimai realiose gamybos modeliuose davė dvi išvadas: (1) ID, kurie pasirodo tik kelis kartus, turi ribotą poveikį modelio kokybei. Svarbus pastebėjimas yra tai, kad ID pasiskirsto ilgosiomis uodegomis, kur populiarūs ID gali pasikartoti milijonus kartų, o nepopuliarūs – ne daugiau kaip dešimt kartų. Įterpimai, atitinkantys šiuos retai pasitaikančius ID, yra nepakankamai apmokyti dėl nepakankamo mokymo duomenų kiekio, o modelis negalės gerai įvertinti jų pagrįstas. Galų gale, šie ID greičiausiai neturės įtakos rezultatui, todėl modelio kokybė nenukentės pašalinus šiuos mažai pasikartojančius ID; (2) Senesni ID iš tolimos istorijos retai prisideda prie dabartinio modelio, nes daugelis jų niekada neaplankomi. Tai gali būti dėl to, kad vartotojas nebėra aktyvus, arba trumpas vaizdo įrašas yra pasenęs. Saugojant šių ID įterpimus, modelis negali padėti, tik veltui ištuštinti mūsų PS atmintį. Remdamiesi šiais pastebėjimais, sukūrėme kelis požymių ID filtravimo heuristikus, kad „HashTable“ būtų įdiegtas efektyviau naudojant atmintį: (1) ID filtruojami prieš juos įleidžiant į įterpimo lenteles. Turime du filtravimo metodus: Pirmiausia filtruojame pagal jų pasikartojimų skaičių prieš juos įterpiant kaip raktus, kur pasikartojimų riba yra nustatoma, ir skiriasi kiekvienam modeliui; Papildomai naudojame tikimybini filtrą, kuris padeda dar labiau sumažinti atminties naudojimą; ![#Figure 4: Streaming Engine. Informacijos grįžtamasis ryšys nuo [Vartotojas → Modelio Serveris → Mokymo Darbuotojas → Modelio Serveris → Vartotojas] užtruktų ilgai, keliaujant Partijų Mokymo keliu, o Internetinis Mokymas uždarytų ciklą akimirksniu.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID yra laiku ir nustatomi kaip pasibaigę po tam tikro laikotarpio neaktyvumo. Pasibaigimo laikas taip pat yra nustatomas kiekvienai įterpimo lentelei, leidžiant atskirti požymius su skirtingu jautrumu istorinei informacijai. Mūsų implementacijoje „HashTable“ yra įdiegtas kaip „TensorFlow“ išteklių operacija. Panašiai kaip „Variable“, paieškos ir atnaujinimai taip pat įgyvendinami kaip gimtosios „TensorFlow“ operacijos, kad būtų lengviau integruoti ir geriau suderinamos. 2.2 Internetinis mokymas „Monolith“ 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 galinį pralaidą, ir galiausiai perduoda atnaujintus parametrus į mokymo PS. Šiek tiek skiriasi nuo kitų įprastų giliojo mokymosi uždavinių, mes tik vieną kartą apmokome mūsų duomenų rinkinį. Partijų mokymas yra naudingas mokant istorinius duomenis, kai mes keičiame modelio architektūrą ir apmokome modelį iš naujo; (2) Internetinio mokymo etapas. Po to, kai modelis yra dislokuotas internetiniam aptarnavimui, mokymas nesustoja, bet pereina į internetinio mokymo etapą. Užuot skaitęs mini-partijos pavyzdžius iš saugyklos, mokymo darbuotojas naudoja realaus laiko duomenis iš karto ir atnaujina mokymo PS. Mokymo PS periodiškai sinchronizuoja savo parametrus su aptarnavimo PS, kurių poveikis vartotojo pusėje įsigalioja nedelsiant. Tai leidžia mūsų modeliui interaktyviai prisitaikyti prie vartotojo atsiliepimų realiu laiku. „Monolith“ yra pastatytas su galimybe sklandžiai pereiti tarp partijų mokymo ir internetinio mokymo. Tai leidžia mūsų suprojektuotas srautinio perdavimo variklis, iliustruotas 4 pav. 2.2.1 Srautinio perdavimo variklis. 4. Mūsų projekte naudojame vieną „Kafka“ [ ] eilutę vartotojų veiksmams registruoti (pvz., Paspausti elementą ar pamėgti elementą ir pan.) ir kitą „Kafka“ eilutę požymiams. Variklio šerdis yra „Flink“ [ ] srautinio perdavimo užduotis internetiniam požymių sujungimui. Internetinis sujungiklis sujungia požymius su etiketėmis iš vartotojo veiksmų ir generuoja mokymo pavyzdžius, kurie tada įrašomi į „Kafka“ eilutę. Mokymo pavyzdžių eilutę vartoja tiek internetinis, tiek partijų mokymas: 13 4 Internetiniam mokymui, mokymo darbuotojas tiesiogiai skaito duomenis iš „Kafka“ eilutės; Partijų mokymui, duomenų išmetimo užduotis pirmiausia išmes duomenis į HDFS [ ]; Po to, kai HDFS sukaups tam tikrą kiekį duomenų, mokymo darbuotojas gaus duomenis iš HDFS ir atliks partijų mokymą. 18 Atnaujinti parametrai mokymo PS bus perduoti į aptarnavimo PS pagal parametrų sinchronizavimo tvarkaraštį. Realiose programose vartotojo veiksmų žurnalas ir požymiai perduodami į internetinį sujungiklį (5 pav. be garantijos chronologine tvarka. Todėl naudojame unikalų raktą kiekvienai užklausai, kad vartotojo veiksmai ir požymiai galėtų teisingai susieti. 2.2.2 Internetinis sujungiklis. 5) Vartotojo veiksmo vėlavimas taip pat gali būti problema. Pavyzdžiui, vartotojas gali užtrukti kelias dienas, kol nuspręs nusipirkti prekę, kuri jam buvo parodyta prieš kelias dienas. Tai yra iššūkis sujungikliui, nes jei visi požymiai būtų laikomi talpykloje, tai tiesiog netilptų į atmintį. Mūsų sistemoje, diske veikianti raktų-verčių saugykla naudojama požymiams, kurie laukia ilgesnį nei tam tikrą laikotarpį, saugoti. Kai atvyksta vartotojo veiksmų žurnalas, jis pirmiausia ieško vidinėje atminties talpykloje, o tada ieško raktų-verčių saugykloje, jei talpykloje trūksta. Kita problema, kylanti realiose 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 atlikti neigiamą atranką. Tai neabejotinai pakeistų apmokyto modelio pagrindinį pasiskirstymą, derinant jį link didesnės teigiamų prognozių tikimybės. Kaip vaistą, aptarnavimo metu taikome logaritmo koeficientų korekciją [ ], 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. Svarbus žingsnis, leidžiantis internetiniam aptarnavimo PS pasinaudoti šiais naujai apmokytais parametrais, yra atnaujintų modelio parametrų sinchronizavimas. Gamybos aplinkoje susiduriame su keliais iššūkiais: 2.2.3 Parametrų sinchronizavimas. Modeliai internetiniame aptarnavimo PS negali nustoti 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 iš karto; Viso kelių terabaitų modelio perkėlimas iš mokymo PS į internetinio aptarnavimo PS sudarytų didelį spaudimą tiek tinklo pralaidumui, tiek PS atminties vietai, nes reikia dvigubai didesnio modelio dydžio atminties, kad būtų galima priimti naujai atvykstantį modelį. Kad internetinis mokymas galėtų būti mastelis iki mūsų verslo scenarijaus dydžio, sukūrėme inkrementinį, realiu laiku periodišką parametrų sinchronizavimo mechanizmą „Monolith“, pagrįstą keliais pastebimais mūsų modelių ypatumais: (1) Reti parametrai dominuoja rekomendacijų modelių dydžiu; (2) Per trumpą laiko intervalą apmokomi tik nedidelis ID pogrupis ir jų įterpimai atnaujinami; (3) Tankūs kintamieji juda daug lėčiau nei reti įterpimai. Taip yra todėl, kad momentinių optimizatorių metu momentų kaupimąsi tankiems kintamiesiems didina milžiniškas rekomendacijų mokymo duomenų dydis, o vienoje duomenų partijoje gauna atnaujinimus tik keli reti įterpimai. (1) ir (2) leidžia mums išnaudoti retus atnaujinimus visuose požymių ID. „Monolith“ palaikome suvestą paveiktų raktų rinkinį, atspindintį ID, kurių įterpimai buvo apmokyti nuo paskutinio parametrų sinchronizavimo. Perduodame retų parametrų pogrupį, kurių raktai yra paveiktų raktų rinkinyje, su minučių lygio laiko intervalu iš mokymo PS į internetinio aptarnavimo PS. Šis santykinai mažas inkrementinių parametrų atnaujinimų paketas yra lengvas tinklo perdavimui ir nesukels staigaus atminties padidėjimo sinchronizavimo metu. Taip pat išnaudojame (3) toliau mažindami tinklo I/O ir atminties naudojimą, nustatydami agresyvesnę sinchronizavimo tvarkaraštį retiems parametrams, o tankius parametrus atnaujindami rečiau. Tai gali mums suteikti situaciją, kai aptarnaujami tankūs parametrai yra santykinai pasenusi versija, palyginti su reta dalimi. Tačiau tokia netolygumą galima toleruoti dėl priežasties, nurodytos (3), nes nepastebėta akivaizdžių nuostolių. 2.3 Atsparumas gedimams Kaip gamybos sistema, „Monolith“ suprojektuotas taip, kad būtų galima atkurti PS, jei jis nepavyks. Įprastas atsparumo gedimams pasirinkimas yra periodiškai kurti modelio būsenos momentinę kopiją ir atkurti ją iš naujausios momentinės kopijos, kai aptinkamas PS gedimas. Momentinės kopijos dažnio pasirinkimas turi du pagrindinius poveikius: (1) Modelio kokybė. Intuityviai, modelio kokybė mažiau nukenčia nuo neseniai prarastos istorijos, padidėjus momentinių kopijų dažniui. (2) Skaičiavimo antkainis. Kelių terabaitų modelio momentinės kopijos kūrimas nėra nemokamas. Tai sukelia didelius atminties kopijavimo ir disko I/O darbus. Kaip kompromisas tarp modelio kokybės ir skaičiavimo antkainio, „Monolith“ kasdien kuria momentines visas mokymo PS kopijas. Nors PS atveju prarandama vienos dienos atnaujinimas, per mūsų eksperimentus nustatėme, kad kokybės pablogėjimas yra toleruojamas. Poveikį PS patikimumui analizuotume kitame skyriuje. 3 VERTINIMAS Norint geriau suprasti mūsų siūlomo projekto teikiamus privalumus ir kompromisus, atlikome keletą gamybos mastelio eksperimentų ir A/B testą su gyva aptarnavimo srautų, kad įvertintume ir patikrintume „Monolith“ įvairiais aspektais. Mūsų eksperimentais siekiame atsakyti į šiuos klausimus: (1) Kiek naudos galime gauti iš be kolizijų veikiančios „HashTable“? (2) Koks svarbus yra realaus laiko internetinis mokymas? (3) Ar „Monolith“ parametrų sinchronizavimo projektavimas yra pakankamai tvirtas didelio mastelio gamybos scenarijuje? Šiame skyriuje pirmiausia pristatysime mūsų eksperimentinius nustatymus, o tada detaliai aptarsime rezultatus ir mūsų išvadas. 3.1 Eksperimentiniai nustatymai Kaip aprašyta 2.1 skyriuje „Monolith“ įterpimo lentelės yra įdiegtos kaip be kolizijų veikiančios „HashTables“. Norėdami įrodyti, kad reikia vengti įterpimo lentelių kolizijų 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 Įterpimo lentelė. 2.1, (1) ml-25m duomenų rinkinys [ ]. Tai standartinis viešas filmų vertinimų duomenų rinkinys, turintis 25 milijonus vertinimų, apimantis maždaug 162 000 vartotojų ir 62 000 filmų. MovieLens 11 • Pradinės etiketės yra vertinimai nuo Etikečių paruošimas. 0,5 iki 5,0, o gamyboje mūsų užduotys dažniausiai gauna dvejetainius signalus iš vartotojų. Norėdami geriau imituoti mūsų gamybos modelius, konvertuojame skalės etiketes į dvejetaines etiketes, laikydami balus ≥ 3,5 kaip teigiamus pavyzdžius, o likusius – kaip neigiamus pavyzdžius. • Modelis ir metrika. Įgyvendinome standartinį „DeepFM“ [ ] modelį, dažnai naudojamą rekomendacijų problemų modelį. Jis susideda iš FM komponento ir tankaus komponento (6 pav.). Prognozės vertinamos pagal AUC, nes tai yra pagrindinis realių modelių matavimas. • Į 9