"ByteDance monolitas: protingesnius, greitesnius turinio kanalus maitinanti sistema"

```html 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) ABSTRAKTAS Sukurti mastelinius ir realaus laiko rekomendacijų sistemos yra gyvybiškai svarbu daugeliui verslų, grindžiamų laiko jautriais klientų atsiliepimais, pavyzdžiui, trumpų vaizdo įrašų reitingavimui ar internetiniams skelbimams. Nepaisant plačiai paplitusių gamybos lygio giliosios mokymosi sistemų, tokių kaip Ten-sorFlow ar PyTorch, diegimo, šios bendrosios paskirties sistemos neatitinka verslo poreikių rekomendacijų scenarijuose dėl įvairių priežasčių: viena vertus, sistemų derinimas remiantis statiškais parametrais ir tankiomis rekomendacijų sąskaitomis su dinamiškais ir retais bruožais kenkia modelio kokybei; kita vertus, tokios sistemos yra sukurtos taip, kad partijos mokymo ir aptarnavimo etapai būtų visiškai atskirti, neleidiant modeliui realiu laiku bendrauti su klientų atsiliepimais. Šios problemos privertė mus iš naujo nagrinėti tradicinius metodus ir ieškoti radikaliai skirtingų projektavimo pasirinkimų. Šiame straipsnyje pristatome 1, sistemą, pritaikytą internetiniam mokymui. Mūsų dizainas buvo grindžiamas mūsų taikomųjų darbo krūvių ir gamybos aplinkos stebėjimais, kurie atspindi reikšmingą nukrypimą nuo kitų rekomendacijų sistemų. Mūsų indėlis yra daugialypis: pirma, sukūrėme be kolizijų įterptųjų lentelę su optimizavimais, tokiais kaip galiojantys įterptieji elementai ir dažnio filtravimas, siekdami sumažinti jos atminties naudojimą; antra, pateikiame paruoštą gamybai internetinio mokymo architektūrą su dideliu atsparumu gedimams; galiausiai įrodėme, kad sistemos patikimumas gali būti keičiamas į realaus laiko mokymąsi. Monolith sėkmingai integruota į BytePlus Recommend2 produktą. Monolith 1 ĮVADAS Per pastarąjį dešimtmetį pastebėjome rekomendacijų technologijomis paremtų verslų klestėjimą. Siekiant pagerinti klientų patirtį, kiekvienam vartotojui tiekti personalizuotą turinį realiu laiku yra įprastas šių verslo programų tikslas. Siekiant šio tikslo, informaciją iš naujausios vartotojo sąveikos dažnai naudojame kaip pagrindinį modelio mokymo įvestį, nes tai geriausiai atspindi vartotojo profilį ir leidžia prognozuoti vartotojo interesus bei būsimus veiksmus. Gilioji mokymosi metodika dominuoja rekomendacijų modeliuose [ , , , , , ], nes didžiulis vartotojų duomenų kiekis puikiai tinka masinėms duomenimis grindžiamoms neuroninėms modeliams. Tačiau pastangos panaudoti giliosios mokymosi jėgą pramoninio lygio rekomendacijų sistemose nuolat susiduria su problemomis, kylančiomis dėl unikalių realaus pasaulio vartotojų elgsenos duomenų charakteristikų. Šie duomenys dviem aspektais drastiškai skiriasi nuo duomenų, naudojamų tradiciniuose giliosios mokymosi uždaviniuose, tokiuose kaip kalbos modeliavimas ar kompiuterinė rega: 5 6 10 12 20 21 (1) Bruožai dažniausiai yra reti, kategoriniai ir dinamiškai besikeičiantys; (2) Pagrindinis mokymo duomenų pasiskirstymas yra ne stacionarus, kitaip tariant, konceptualus poslinkis [8]. Tokie skirtumai kelia unikalius iššūkius tyrėjams ir inžinieriams, dirbantiems su rekomendacijų sistemomis. 1.1 Retumas ir dinamiškumas Rekomendacijų duomenys daugiausia apima retus kategorinius bruožus, kai kurie iš kurių pasirodo retai. Įprasta praktika juos susieti su aukštadimensiniu įterptųjų erdvių, sukeliančiu 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ė įterptųjų lentelė vargu ar tilps į vieno prieglobos atmintį; • Dar blogiau, tikimasi, kad įterptųjų lentelės dydis didės laikui bėgant, kai bus priimama daugiau vartotojų ir elementų, o tokios sistemos kaip [ , ] naudoja fiksuoto dydžio tankias kintamąsias, kad atspindėtų įterptųjų lentelę. 1 17 Praktiškai daugelis sistemų naudoja mažai kolizijų turinčią maišą [ , ] kaip būdą sumažinti atminties naudojimą ir leisti didėti ID. Tai priklauso nuo per daug idealistinio privalomo ID įterptųjų lentelėje pasiskirstymo pagal dažnį, ir kolizijos yra nekenksmingos modelio kokybei. Deja, tai retai pasitaiko realaus pasaulio rekomendacijų sistemose, kur nedidelė vartotojų ar elementų grupė turi žymiai daugiau pasikartojimų. Organiškai augant įterptųjų lentelės dydžiui, maišymo rakto kolizijų tikimybė didėja ir kenkia modelio kokybei 3 6 [3]. Todėl natūralus reikalavimas gamybos lygio rekomendacijų sistemoms yra gebėti užfiksuoti kuo daugiau bruožų savo parametruose, taip pat turėti galimybę lanksčiai koreguoti vartotojų ir elementų skaičių, kuriuos jie bando registruoti. 1.2 Ne-stacionarus pasiskirstymas Vizualiniai ir lingvistiniai modeliai beveik nesivysto per šimtmečius, o tas pats vartotojas, besidomintis viena tema, gali pakeisti savo entuziazmą kiekvieną minutę. Dėl to vartotojų duomenų pasiskirstymas yra ne stacionarus, reiškinys, dažnai vadinamas konceptualiu poslinkiu [8]. Intuityviai, informacija iš neseniai praeities gali efektyviau prisidėti prie vartotojo elgsenos pokyčių prognozavimo. Norint sumažinti konceptualaus poslinkio poveikį, aptarnavimo modeliai turi būti atnaujinami iš naujų vartotojų atsiliepimų kuo arčiau realaus laiko, kad atspindėtų naujausius vartotojo interesus. Atsižvelgdami į šiuos skirtumus ir stebėdami problemas, kylančias mūsų gamyboje, sukūrėme , didelės apimties rekomendacijų sistemą, skirtą spręsti šias problemas. Atlikome išsamius eksperimentus, kad patikrintume ir tobulintume savo dizainą gamybos aplinkoje. Monolith gali: Monolith (1) Suteikti visą išraiškingumo galią retiems bruožams, kuriant be kolizijų maišymo lentelę ir dinaminio bruožų išmetimo mechanizmą; (2) Grąžinti aptarnavimo atsiliepimus į mokymą realiu laiku su internetiniu mokymu. Dėl šių architektūrinių gebėjimų Monolith nuolat viršija sistemas, kurios naudoja maišymo triukus su kolizijomis, naudojant panašų atminties kiekį, ir pasiekia pažangiausią internetinio aptarnavimo AUC be per didelio serverių skaičiavimo galios apkrovimo. Likusi straipsnio dalis yra organizuojama taip. Pirma, išsamiai aprašome dizaino detales, kaip Monolith sprendžia esamas problemas su be kolizijų 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 kai kuriomis diskusijomis apie laiko jautrumo, patikimumo ir modelio kokybės kompromisus. 4 skyriuje apibendrinama susijusi literatūra ir lyginama su Monolith. 5 skyriuje apibendrinamas šis darbas. 2 DIZAINAS Bendra Monolith architektūra paprastai seka TensorFlow paskirstytą Darbuotojo- arametrų erverio nustatymą (1 pav. Darbuotojo-PS architektūroje mašinoms priskiriamos skirtingos rolės; Darbuotojų mašinos atsako už skaičiavimus, kaip apibrėžta grafike, o PS mašinos saugo parametrus ir atnaujina juos pagal Darbuotojų apskaičiuotus gradientus. P S ). Rekomendacijų modeliuose parametrai yra suskirstyti į du rinkinius: tankius ir retus. Tankūs parametrai yra svoriai/kintamieji giliojoje neuroninėje tinkle, o reti parametrai reiškia įterptųjų lenteles, atitinkančias retus bruožus. Mūsų dizaine tiek tankūs, tiek reti parametrai yra TensorFlow grafiko dalis ir saugomi parametrų serveriuose. Panašiai kaip TensorFlow kintamasis tankiems parametrams, sukūrėme rinkinį labai efektyvių, be kolizijų ir lanksčių „HashTable“ operacijų retiems parametrams. Kaip papildymas TensorFlow apribojimams, kylantiems dėl mokymo ir išvedimo atskyrimo, Monolith elastingai mastelinis internetinis mokymas yra sukurtas efektyviai sinchronizuoti parametrus iš mokymo-PS į internetinį aptarnavimo-PS per trumpus intervalus, su modelio atsparumo garantija, teikiama gedimų toleravimo mechanizmo. 2.1 Maišymo lentelė Pirmasis mūsų retų parametrų atvaizdavimo dizaino principas yra vengti informacijos iš skirtingų ID sutraukimo į tą pačią fiksuoto dydžio įterptąją erdvę. Dinaminio dydžio įterptųjų lentelių imitavimas naudojant „TensorFlow Variable“ neišvengiamai veda prie ID kolizijos, kuri sustiprėja atsiradus naujiems ID ir padidėjus lentelei. Todėl, užuot grindžiant ant „Variable“, sukūrėme naują „HashTable“ raktų-verčių poroms skirtą mūsų retiems parametrams. Mūsų „HashTable“ naudoja „Cuckoo Hashmap“ [ ] po gaubtu, kuris palaiko naujų raktų įterpimą nekonflikuojant su esamais. Cuckoo maišymas pasiekia blogiausiu atveju 𝑂 (1) laiko sudėtingumą paieškoms ir ištrynimams, ir tikimasi amortizuoto 𝑂 (1) laiko įterpimams. Kaip parodyta 3 pav. ji palaiko dvi lenteles 𝑇0, 𝑇1 su skirtingomis maišymo funkcijomis ℎ0 (𝑥), ℎ1 (𝑥), ir elementas būtų saugomas vienoje iš jų. Įterpiant elementą 16 , 𝐴 į 𝑇0, jis pirmiausia bando įdėti 𝐴 į ℎ0 (𝐴); Jei ℎ0 (𝐴) yra užimta kitu elementu 𝐵, jis išstums 𝐵 iš 𝑇0 ir bandys įterpti 𝐵 į 𝑇1 su ta pačia logika. Šis procesas bus kartojamas, kol visi elementai stabilizuosis, arba įvyks pakartotinis maišymas, kai įterpimas susidurs su ciklu. Atminties naudojimo sumažinimas taip pat yra svarbus mūsų dizaino aspektas. Naivus metodas įterpiant kiekvieną naują ID į „HashTable“ greitai išeikvos atmintį. Stebėjimai realiose gamybos modeliuose veda prie dviejų išvadų: (1) ID, kurie pasirodo tik kelis kartus, turi ribotą poveikį modelio kokybei gerinti. Svarbus pastebėjimas yra tai, kad ID pasiskirsto ilgą uodegą, kur populiarūs ID gali pasikartoti milijonus kartų, o nepopuliarūs pasirodo ne daugiau kaip dešimt kartų. Įterptieji elementai, atitinkantys šiuos nepopuliarius ID, yra nepakankamai apmokyti dėl mokymo duomenų trūkumo, o modelis negalės pateikti geros prognozės remdamasis jais. Galų gale, šie ID greičiausiai neturės įtakos rezultatui, todėl modelio kokybė nenukentės pašalinus šiuos ID su mažais pasikartojimais; (2) Senesni ID iš tolimos istorijos retai prisideda prie dabartinio modelio, nes daugelis jų niekada nebuvo naudojami. Tai gali atsitikti dėl vartotojo, kuris nebėra aktyvus, arba trumpo vaizdo įrašo, kuris yra pasenęs. Šių ID įterptųjų elementų saugojimas negali padėti modeliui jokiu būdu, išskyrus PS atminties švaistymą. Remiantis šiais pastebėjimais, sukūrėme keletą funkcijų ID filtravimo heuristikų, kad efektyviau naudotumėme „HashTable“ atmintį: (1) ID yra filtruojami prieš juos priimant į įterptųjų lenteles. Turime du filtravimo metodus: Pirmiausia filtruojame pagal jų pasikartojimus prieš juos įterpiant kaip raktus, kur pasikartojimų slenkstis yra keičiamas hiperparametras, skiriasi kiekvienam modeliui; Be to, naudojame probabistinį filtrą, kuris padeda dar labiau sumažinti atminties naudojimą; ![#Figure 4: Streaming Engine. Informacijos grįžtamojo ryšio ciklas [Vartotojas → Modelio serveris → Mokymo darbuotojas → Modelio serveris → Vartotojas] užtruks ilgai, jei naudosite partijos mokymo kelią, o internetinis mokymas užbaigs ciklą greičiau.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID yra pažymimi laiku ir nustatomi kaip nebegaliojantys po tam tikro neaktyvumo laikotarpio. Galiojimo laikas taip pat yra keičiamas kiekvienai įterptųjų lentelėms, kad būtų galima atskirti bruožus, kurių jautrumas istorinei informacijai skiriasi. Mūsų įgyvendinime „HashTable“ yra įgyvendinta kaip „TensorFlow“ išteklių operacija. Panašiai kaip ir „Variable“, paieškos ir atnaujinimai taip pat yra įgyvendinti kaip natyvios „TensorFlow“ operacijos, kad būtų lengviau integruoti ir geriau suderinama. 2.2 Internetinis mokymas „Monolith“ sistemoje mokymas skirstomas į du etapus (1 pav. ): (1) Partijos mokymo etapas. Šis etapas veikia kaip įprastas „TensorFlow“ mokymo ciklas: kiekviename mokymo žingsnyje mokymo darbuotojas skaito mokymo pavyzdžių mini-partiją iš saugyklos, prašo parametrų iš PS, atlieka priekinę ir atgalinę skaičiavimus ir galiausiai perduoda atnaujintus parametrus į mokymo PS. Šiek tiek skiriasi nuo kitų įprastų giliosios mokymosi užduočių, mes apmokome savo duomenų rinkinį tik vieną kartą. Partijos mokymas yra naudingas mokant istorinius duomenis, kai keičiame modelio architektūrą ir pakartotinai mokome modelį; (2) Internetinio mokymo etapas. Kai modelis yra įdiegtas internetiniam aptarnavimui, mokymas nesustoja, bet pereina į internetinio mokymo etapą. Užuot skaitęs mini-partijos pavyzdžius iš saugyklos, mokymo darbuotojas apdoroja realaus laiko duomenis „on-the-fly“ ir atnaujina mokymo PS. Mokymo PS periodiškai sinchronizuoja savo parametrus su aptarnavimo PS, kurie nedelsiant įsigalios vartotojo pusėje. Tai leidžia mūsų modeliui interaktyviai prisitaikyti pagal vartotojo atsiliepimus realiu laiku. „Monolith“ yra pastatytas su galimybe sklandžiai perjungti partijos ir internetinį mokymą. Tai leidžia mūsų srauto variklio dizainas, iliustruotas 4 pav. 2.2.1 Srauto variklis. . ] eilutę, kad žurnaluotume vartotojų veiksmus (pvz., paspaudimą ant elemento ar „patinka“), ir kitą „Kafka“ eilutę funkcijoms. Variklio branduolys yra „Flink“ [ ] srauto darbas internetiniam funkcijų sujungimui. Internetinis jungiklis sujungia funkcijas su etiketėmis iš vartotojų veiksmų ir generuoja mokymo pavyzdžius, kurie tada įrašomi į „Kafka“ eilutę. Mokymo pavyzdžių eilutę vartoja tiek internetinis, tiek partijos mokymas: Mūsų dizaine naudojame vieną „Kafka“ [ 13 4 Internetiniam mokymui, mokymo darbuotojas tiesiogiai skaito duomenis iš „Kafka“ eilutės; Partijos mokymui, duomenų išpylimo darbas pirmiausia išpils duomenis į HDFS [ ]; Kai HDFS duomenys sukaups tam tikrą kiekį, mokymo darbuotojas gaus duomenis iš HDFS ir atliks partijos mokymą. 18 Atnaujinti parametrai mokymo PS bus perduodami į aptarnavimo PS pagal parametrų sinchronizavimo grafiką. Realaus pasaulio programose vartotojų veiksmų žurnalas ir funkcijos yra perduodamos į internetinį jungiklį (5 pav. 2.2.2 Internetinis jungiklis. ) be laiko tvarkos garantijos. Todėl mes naudojame unikalų kiekvieno prašymo raktą, kad vartotojo veiksmai ir funkcijos galėtų teisingai susieti. 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 pasiūlyta prieš kelias dienas. Tai yra iššūkis jungikliui, nes jei visos funkcijos liks talpykloje, jos tiesiog netilps į atmintį. Mūsų sistemoje diskiniame raktų-verčių saugykloje naudojama saugoti funkcijas, kurios laukia ilgesnį nei tam tikras laikotarpis. Kai atvyksta vartotojo veiksmo žurnalas, jis pirmiausia ieško atminties talpykloje, o tada ieško raktų-verčių saugyklos, jei talpykla nerasta. ] aptarnavimo metu, užtikrindami, kad internetinis modelis būtų nešališkas pradinio pasiskirstymo vertintojas. Kita problema, kylanti realiame pasaulyje, yra ta, kad neigiamų ir teigiamų pavyzdžių pasiskirstymas yra labai nelygus, kur buvusiųjų skaičius gali būti kelis kartus didesnis nei pastarųjų. Siekiant išvengti teigiamų pavyzdžių, per didelio neigiamų skaičiaus, įprasta strategija yra neigiamas atrankas. Tai neabejotinai pakeistų apmokyto modelio pagrindinį pasiskirstymą, derinant jį link didesnės teigiamų prognozių tikimybės. Kaip pataisymą, mes naudojame log-aritmo korekciją [ 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 sustoti aptarnavimo metu atnaujinant. Mūsų modeliai gamyboje paprastai yra kelių terabaitų dydžio, todėl pakeisti visus parametrus užtrunka. Būtų nepriimtina sustabdyti internetinį PS nuo modelio aptarnavimo atnaujinimo proceso metu, ir atnaujinimai turi būti atliekami „on-the-fly“; Perdavus kelių terabaitų modelį iš mokymo PS į internetinį aptarnavimo PS, tai sukeltų didelį spaudimą tiek tinklo pralaidumui, tiek PS atminties naudojimui, nes reikia dvigubo modelio dydžio atminties, kad būtų galima priimti naujai atvykstantį modelį. Kad internetinis mokymas galėtų plėstis iki mūsų verslo scenarijaus dydžio, „Monolith“ sukūrėme laipsnišką nuolatinio parametrų sinchronizavimo mechanizmą, pagrįstą keliais pastebėtais mūsų modelių ypatumais: (1) Rekomendacijų modelių dydį dominuoja reti parametrai; (2) > Per trumpą laiko langą tik nedidelė ID dalis yra apmokoma ir jų įterptieji elementai atnaujinami; (3) Tankūs kintamieji juda daug lėčiau nei reti įterptieji elementai. Taip yra todėl, kad judesio pagrindu veikiančiuose optimizatoriuose, judesio kaupimasis tankiems kintamiesiems yra padidinamas dėl didžiulio rekomendacijų mokymo duomenų dydžio, o tik keli reti įterptieji elementai gauna atnaujinimus vienoje duomenų partijoje. (1) ir (2) leidžia mums išnaudoti retus atnaujinimus visuose funkcijų ID. „Monolith“ sistemoje palaikome paliestų raktų maišymo rinkinį, atspindintį ID, kurių įterptieji elementai buvo apmokyti nuo paskutinio parametrų sinchronizavimo. Mes perduodame retų parametrų pogrupį, kurių raktai yra paliestų raktų rinkinyje, su minutės lygio laiko intervalu iš mokymo PS į internetinį aptarnavimo PS. Šis palyginti mažas papildomo parametrų atnaujinimo paketas yra lengvas tinklo perdavimui ir nesukelia staigaus atminties padidėjimo 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 lemti situaciją, kai aptarnaujami tankūs parametrai yra palyginti pasenusi versija, palyginti su reta dalimi. Tačiau toks neatitikimas gali būti toleruojamas dėl priežasčių, nurodytų (3), nes nepastebėta jokių akivaizdžių nuostolių. 2.3 Gedimų toleravimas Kaip gamybos sistema, „Monolith“ yra sukurta taip, kad galėtų atkurti PS, jei ji sugenda. Įprastas gedimų toleravimo pasirinkimas yra periodiškai atvaizduoti modelio būseną ir atkurti iš naujausio atvaizdo, kai aptinkamas PS gedimas. Atvaizdavimo dažnumo pasirinkimas turi du didelius poveikius: (1) Modelio kokybė. Intuityviai, modelio kokybė mažiau nukenčia nuo neseniai prarastos istorijos, padidinus atvaizdavimo dažnį. (2) Skaičiavimo antkainis. Kelių terabaitų modelio atvaizdavimas nėra nemokamas. Tai sukelia didelius atminties kopijavimo ir disko I/O. Kaip kompromisas tarp modelio kokybės ir skaičiavimo antkainio, „Monolith“ kiekvieną dieną atvaizduoja visus mokymo PS. Nors PS gedimo atveju praras vienos dienos atnaujinimą, eksperimentų metu nustatėme, kad našumo pablogėjimas yra toleruojamas. Kito skyriaus analizę atliksime dėl PS patikimumo poveikio. 3 VERTINIMAS Norint geriau suprasti mūsų siūlomo dizaino teikiamą naudą ir kompromisus, atlikome kelis eksperimentus gamybos mastu ir A/B testus su tiesiogine aptarnavimo srautu, kad įvertintume ir patvirtintume „Monolith“ iš skirtingų aspektų. Šiais eksperimentais siekiame atsakyti į šiuos klausimus: (1) Kiek galime naudos gauti iš be kolizijų maišymo lentelės? (2) Kiek svarbus yra realaus laiko internetinis mokymas? (3) Ar „Monolith“ parametrų sinchronizavimo dizainas yra pakankamai patikimas didelio masto gamybos scenarijuje? Šiame skyriuje pirmiausia pristatome eksperimentines nuostatas, o paskui išsamiai aptariame rezultatus ir mūsų išvadas. 3.1 Eksperimentinė sąranka Kaip aprašyta 2.1 skyriuje „Monolith“ įterptųjų lentelės yra įgyvendintos kaip be kolizijų maišymo lentelės. Norėdami įrodyti būtinybę vengti kolizijų įterptųjų lentelėse ir kiekybiškai įvertinti mūsų be kolizijų įgyvendinimo naudą, atlikome dvi eksperimentų grupes „Movielens“ duomenų rinkinyje ir mūsų vidiniame gamybos duomenų rinkinyje: 3.1.1 Įterptųjų lentelių rinkinys. , (1) ml-25m duomenų rinkinys [ ]. Tai standartinis viešas duomenų rinkinys filmų vertinimams, apimantis 25 milijonus vertinimų, susijusių su maždaug 162 000 vartotojų ir 62 000 filmų. MovieLens 11 • . Originalios etiketės yra vertinimai nuo Etikečių paruošimas 0,5 iki 5,0, o gamyboje mūsų užduotys daugiausia yra gauti dvejetainius signalus iš vartotojų. Norėdami geriau imituoti mūsų gamybos modelius, konvertavome skalės etiketes į dvejetaines, laikydami balas ≥ 3,5 kaip teigiamus pavyzdžius, o likusius – neigiamais. • Modelis ir metrika. Įgyvendinome standartinį „DeepFM“ [ ] modelį, dažnai naudojamą rekomendacijų uždaviniuose. Jį sudaro FM komponentas ir tankus komponentas (6 pav.). Prognozės vertinamos pagal AUC [2], nes tai yra pagrindinis realių modelių matavimo rodiklis. 9 • Įterptųjų