Minu nimi on Pavel Parkhomenko, olen ML-arendaja. Selles artiklis soovin rääkida Yandex Zen teenuse ülesehitusest ning jagada tehnilisi täiustusi, mille rakendamine on võimaldanud parandada soovituste kvaliteeti. Artiklist saad teada, kuidas leida miljonite dokumentide hulgast kasutajale kõige asjakohasemad vaid mõne millisekundi jooksul; kuidas teha suurt maatriksi pidevat lagundamist (mis koosneb miljonitest veergudest ja kümnetest miljonitest ridadest), et uued dokumendid saaksid oma vektori kätte vaid tundide jooksul; kuidas taaskasutada kasutaja-artikli maatriksi lagundamist, et saada head vekt esindust videode jaoks.
Meie soovitusbaas sisaldab miljoneid erineva formaadiga dokumente: tekstilised artiklid, mis on loodud meie platvormil ja saadud välistelt veebisaitidelt, videod, narratiivid ja lühikesed postitused. Sellise teenuse arendamine on seotud mitmete tehniliste väljakutsetega. Siin on mõned neist:
- Jagada arvutusülesandeid: kõik rasked operatsioonid teostada offline, samas kui reaalajas teostatakse ainult mudelite kiire rakendamine, et vastata 100-200 ms jooksul.
- Kiirelt arvestada kasutaja tegevusi. Selleks on vajalik, et kõik sündmused edastataks kohe soovitussüsteemi ja mõjutaksid mudelite töö tulemusi.
- Luua selline feed, et uued kasutajad saaksid kiiresti kohanduda oma käitumisega. Just süsteemi tulnud inimesed peaksid tundma, et nende tagasiside mõjutab soovitusi.
- Kiirelt mõista, kellele soovitada uut artiklit.
- Operatiivselt reageerida pidevale uue sisu ilmumisele. Igapäevaselt ilmub kümneid tuhandeid artikleid, millest paljudel on piiratud eluiga (näiteks uudised). See eristab neid filmidest, muusikast ja muust pikaajalise elueaga ja kallist loovusest.
- Üksnes teadmiste üleviimine ühelt domeenialalt teisele. Kui soovitussüsteemis on koolitatud mudeleid tekstiliste artiklite jaoks ja lisame sinna videod, saab olemasolevaid mudeleid taaskasutada, et uue tüüpi sisu paremini järjestada.
Räägin, kuidas me neid väljakutseid lahendasime.
Kandidaatide valimine
Kuidas vähendada mitmesuguste dokumentide arvu tuhandete võrra mõne millisekundi jooksul, kahjustamata praktiliselt järjestamise kvaliteeti?
Oletame, et oleme koolitanud palju masinõppe mudeleid, genereerinud nende põhjal tunnuseid ja koolitanud veel ühe mudeli, mis järjestab dokumente kasutaja jaoks. Kõik on hästi, kuid ei saa lihtsalt võtta ja arvutada kõiki tunnuseid kõigi dokumentide jaoks reaalajas, kui neid dokumente on miljoneid, ja soovitusi tuleb teha 100-200 ms jooksul. Ülesanne on valida miljonitest mingisugune alamhulk, mis järjestatakse kasutaja jaoks. Seda etappi kutsutakse tavaliselt kandidaadi valimiseks. Sellele esitatakse mitmeid nõudeid. Esiteks, valik peab toimuma väga kiiresti, et järjestamiseks jääks võimalikult palju aega. Teiseks, oluliselt vähendades järjestamiseks vajalike dokumentide arvu, peame maksimaalselt säilitama kasutaja jaoks asjakohased dokumendid.
Meie kandidaadi valimise põhimõte on evolutsiooniliselt arenenud ja hetkel oleme jõudnud mitmeastmelisse skeemi:
Esmalt jagatakse kõik dokumendid gruppidesse ning igast grupist valitakse välja kõige populaarsemad dokumendid. Grupiks võivad olla veebilehed, teemad või klastrid. Iga kasutaja jaoks valitakse tema ajaloo põhjal välja kõige sobivamad grupid ja nendest valitakse juba parimad dokumendid. Kasutame ka kNN-indeksit, et leida reaalajas kõige lähemal asuvad kasutajale dokumendid. kNN-indeksi koostamiseks on mitu meetodit, millest meie puhul töötab kõige paremini (Hierarchical Navigable Small World graphs). See on hierarhiline mudel, mis võimaldab mõne millisekundi jooksul leida miljonite dokumentide hulgast kasutajale N lähimat vektorit. Eelnevalt indekseerime kogu oma dokumentide baasi offline. Kuna otsimine indeksis toimub suhteliselt kiiresti, on võimalik mõne tugeva embedding'i olemasolul luua mitu indeksi (igale embedding'ile üks indeks) ja pöörduda igaühe poole reaalajas.
Meil on iga kasutaja jaoks kümneid tuhandeid dokumente. See on endiselt palju, et arvestada kõiki tunnuseid, seega rakendame sellel etapil kerget retsensiooni — lihtsustatud mudeli rasket retsensiooni väiksema tunnuste arvuga. Ülesanne on ennustada, millised dokumendid saavad raskes mudelis tippu. Dokumente, millel on kõrgeim ennustus, kasutatakse rasketes mudelites, st retsensiooni viimases etapis. See lähenemine võimaldab kümnete millisekundite jooksul vähendada kasutaja jaoks kaalutavate dokumentide arvu miljonist tuhande juurde.
ALS'etapp reaalajas
Kuidas arvesse võtta kasutaja tagasisidet kohe pärast kliki tegemist?
Oluline tegur soovitustes on reaktsiooniaeg kasutaja tagasisidele. See on eriti oluline uute kasutajate jaoks: kui inimene hakkab just soovitussüsteemi kasutama, saab ta mitmekesise teema ühtse sisu. Niipea, kui ta teeb esimese kliki, on oluline kohe arvestada seda ja kohandada oma huve. Kui kõik tegurid arvutatakse väljas, muutub süsteemi kiire reageerimine võimatuks viivituse tõttu. Seetõttu on vaja reaalses ajas töötleda kasutaja tegevusi. Selleks kasutame ALS etappi reaalajas, et luua kasutaja vekt esitus.
Oletame, et kõikide dokumentide jaoks on meil vekt esitus. Näiteks saame väljas artikli teksti põhjal luua embedde ELMo, BERT või muude masinõppe mudelite abil. Kuidas saame saada kasutajate vekt esitus sama ruumi põhjal nende tegevuste põhjal süsteemis?
Kasutaja-dokumendi maatriksi loomise ja lagundamise üldine põhimõteOletame, et meil on m kasutajat ja n dokumenti. Mõne kasutaja kohta on teada nende suhe mõne dokumendi suhtes. Sellist teavet saab esitada m x n maatriksina: read vastavad kasutajatele ja veerud dokumentidele. Kuna enamik dokumente on kasutajad näinud, jääb suurem osa maatriksi rakkudest tühjaks, samas kui teised täidetakse. Iga sündmuse (meeldimise, mitte-meeldimise, kliki) puhul on maatriksis ette nähtud mingi väärtus – kuid vaatame lihtsustatud mudelit, kus meeldimise korral on väärtus 1, mitte-meeldimise korral aga -1.
Jagame maatriksi kaheks: P (m x d) ja Q (d x n), kus d on vekt esitus suurus (tavaliselt väike number). Siis vastab igale objektile d-mõõtmeline vektor (kasutajale – rida maatriksis P, dokumendile – veerg maatriksis Q). Need vektorid on vastavate objektide embedid.
Üks võimalik maatriksi jagamise meetod on ALS (Alternating Least Squares). Optimeerime järgmist kaotusefunktsiooni:
Siin rui on kasutaja u suhtlemine dokumendiga i, qi on dokumendi i vektor, pu on kasutaja u vektor.
Siis leiame optimaalse kasutaja vektori (fikseeritud dokumentide vektorite puhul) analüütiliselt, lahendades vastava lineaarse regressiooni.
Seda nimetatakse "ALS-i sammuks". ALSi algoritm seisneb selles, et me fikseerisime ühe maatriksi (kasutajate ja artiklite) ning uuendame teist, leides optimaalse lahenduse.
Õnneks on kasutaja vekt esitus leidmine üsna kiire operatsioon, mida saab teha käitusaja jooksul, kasutades vektori juhiseid. See nipp võimaldab kohe arvestada kasutaja tagasisidet järjestuses. Sama embeddit saab kasutada ka kNN-indeksis kandidaatide valiku parandamiseks.
Jaotatud koostööfilter
Kuidas teha inkrementeeritud jaotatud maatriksi faktoreerimist ja kiiresti leida uute artiklite vektorite esitusi?
Sisu ei ole ainus signaalide allikas soovituste jaoks. Teiseks oluliseks allikaks on koostöönformatsioon. Häid märke reitingus saab traditsiooniliselt kätte kasutaja-dokumendi maatriksi lahutamisest. Kuid sellist lahutamist proovides kohtasime mitmeid probleeme:
1. Meil on miljoneid dokumente ja kümneid miljoneid kasutajaid. Maatriks ei mahu täies ulatuses ühte masinasse, ning lahutamine kestab väga kaua.
2. Suurema osa sisu eluaeg on lühike: dokumendid jäävad aktuaalseks vaid paariks tunniks. Seetõttu on oluline kiiresti luua nende vektoriline esitus.
3. Kui lahutame kohe pärast dokumendi avaldamist, ei jõua seda piisavalt palju kasutajaid hinnata. Seega on selle vektoriline esitus suure tõenäosusega kehv.
4. Kui kasutaja on andnud meeldimise või mittetunnustamise, ei saa me seda kohe lahutamisel arvesse võtta.
Nende probleemide lahendamiseks rakendasime hajutatud kasutaja-dokumendi maatriksi lahutamist sagedaste inkrementaalsete uuendustega. Kuidas see täpselt töötab?
Kujutame ette, et meil on N masinat (N loetleb sada) ja me soovime nende peal teha hajutatud lahutamist maatriksist, mis ei mahu ühte masinasse. Küsimus on, kuidas teostada seda lahutamist nii, et igas masinas oleks piisavalt andmeid ja samas oleks arvutused omavahel sõltumatud?
Kasutame eespool kirjeldatud ALS lahutamisalgoritmi. Vaatleme, kuidas teostada hajutatult ühte ALS sammu – ülejäänud sammud on sarnased. Oletame, et meie dokumentide maatriks on fikseeritud ja me tahame luua kasutajate maatriksi. Selleks jagame selle N osaks ridade kaupa, iga osa sisaldab umbkaudu sama arvu ridasid. Saadame igasse masinasse vastavate ridade mitte-tühjad lahtrid ning samuti dokumentide sisu embedimisi (täielikult). Kuna selle suurus on väike ja kasutaja-dokumendi maatriks on tavaliselt tugevalt hõre, mahtuvad need andmed tavalisse masinasse.
Selline trikk on võimalik korrata mitme ajastu jooksul mudeli konvergentsini, vaheldumisi muuta fikseeritud maatriksit. Kuid isegi siis võib maatriksi lagundamine kesta mitu tundi. See ei lahenda probleemi, et on vaja kiiresti saada uute dokumentide sisendit ja värskendada neid sisendeid, mille kohta oli mudeli koostamisel vähe teavet.
Aitasime kaasa kiire inkrementaalse mudeli uuendamise rakendamisele. Oletame, et meil on praegune treenitud mudel. Alates selle treenimisest on ilmunud uusi artikleid, millega meie kasutajad on suhtlemiseks tegelenud, samuti artikleid, millega treenimise ajal oli vähe suhtlemisi. Selliste artiklite kiireks sisendi saamiseks kasutame kasutajate sisendeid, mis saadi esimesel suurel mudeli treenimisel, ja teeme ühe sammu ALS, et arvutada dokumentide maatriks fikseeritud kasutajate maatriksi juures. See võimaldab saada sisendeid üsna kiiresti — mõne minuti jooksul pärast dokumendi avaldamist — ja sageli värskendada värskeid dokumente.
Et soovitustes arvestataks kohe inimtegevust, ei kasuta me jooksuaegadel offline'is saadud kasutajate sisendeid. Selle asemel teeme sammu ALS ja saame praeguse kasutaja vektori.
Ülekandmine teise domeeni
Kuidas kasutada kasutajate tagasisidet tekstilistele artiklitele, et luua videote vektorseisund?
Alguses soovitasime ainult tekstilisi artikleid, seega on paljud meie algoritmid kohandatud just selle sisu tüübi jaoks. Kuid kasutades teist tüüpi sisu, seisisime silmitsi vajadusega mudelite kohandamiseks. Kuidas me selle ülesande lahendasime video näitel? Üks võimalus on kõiki mudeleid nullist uuesti treenida. Kuid see on aeganõudev ja mõned algoritmid on treeningu valimi mahu suhtes nõudlikud, millest ei ole esimese hetkeni uuetüüpi sisu jaoks piisavas mahus.
Me läksime teist teed ja kasutasime videote jaoks tekstimudeleid uuesti. Video vekt esinduste loomisel aitas meid ikka see sama ALS trikk. Võtsime kasutajate vekt esinduse tekstipõhiste artiklite alusel ning tegime ALS sammu, kasutades video vaatamise teavet. Nii saime vaevata video vekt esinduse. Ja jooksuajal arvutame lihtsalt sarnasuse kasutaja vektoriga, mis on saadud tekstipõhistest artiklitest, ja video vektoriga.
Kokkuvõte
Reaalajas soovitussüsteemi tuumik arendamine on seotud paljude ülesannetega. Andmeid tuleb kiiresti töödelda ja rakendada ML- meetodeid nende efektiivseks kasutamiseks; ehitada keerulisi jaotatud süsteeme, mis suudavad minimaalse aja jooksul töödelda kasutajate signaale ja uusi sisuüksusi; ja palju teisi ülesandeid.
Praeguses süsteemis, mille ma kirjeldasin, kasvab soovituste kvaliteet kasutaja jaoks koos tema aktiivsuse ja teenuses viibimise kestusega. Kuid loomulikult peitub siinkohal ka peamine keerukus: süsteemil on raske okamõista inimese huve, kes on vähe sisu suhtes interakteerunud. Uute kasutajate soovituste parandamine on meie peamine ülesanne. Jatkame algoritmide optimeerimist, et asjakohane sisu jõuaks kiiremini tema voogu ja ebaasjakohane ei kuvataks.
Allikas: habr.com
