Minu nimi on Pavel Parkhomenko, olen ML-arendaja. Selles artiklis tahan rääkida Yandex.Dzeni teenusest ja jagada tehnilisi täiustusi, mille rakendamine on võimaldanud suurendada soovituste kvaliteeti. Postitusest saad teada, kuidas leida miljonite dokumentide hulgast kasutajale kõige asjakohasemad vaid mõne millisekundi jooksul; kuidas teha suurt maatriksi pidevat lagundamist (miljonitest veergudest ja kümnetest miljonitest ridadest), et uued dokumendid saaksid oma vektori kätte kümnete minutite jooksul; kuidas taaskasutada kasutaja-artikli maatriksi lagundamist, et saada hea vekt esitus video jaoks.
Meie soovituste põhjalik andmebaas sisaldab miljoneid erineva formaadi dokumente: tekstilisi artikleid, mis on loodud meie platvormil ja välisveebidest, videoid, narratiive ja lühipostitusi. Sellise teenuse arendamine on seotud hulga tehniliste väljakutsetega. Siin on mõned neist:
- Jagada arvutusülesandeid: kõik rasketööd teha off-line ning reaalajas täita ainult mudelite kiiret rakendamist, et tagada vastamine 100–200 ms jooksul.
- Kiirelt arvestada kasutaja tegevusi. Selleks on oluline, et kõik sündmused jõuaksid koheselt soovituste süsteemi ja mõjutaksid mudelite töö tulemusi.
- Teha uudistevoog nii, et see kohandub uute kasutajate käitumisega kiiresti. Süsteemi just sisenenud inimesed peavad tunnetama, et nende tagasiside mõjutab soovitusi.
- Kiirealt mõista, kellele soovitada uut artiklit.
- Olla reaktiivne pidevale uue sisu ilmnemisele. Igapäevaselt ilmub kümneid tuhandeid artikleid, ja paljusid neist iseloomustab piiratud eluiga (näiteks uudised). See eristab neid filmidest, muusikast ja muust pikaajalist ja kallistest sisutootmisest.
- Teadmiste edastamine ühelt domeenilt teisele. Kui soovitusüsteemis on koolitatud mudelid tekstilistele artiklitele ja me lisame sinna video, on võimalik olemasolevaid mudeleid taaskasutada, et uue tüüpi sisu paremini järjestada.
Kannan ette, kuidas me need probleemid lahendasime.
Kandidaatide valik
Kuidas vähendada mitmeid millisekunde, arvestades miljonite dokumentide hulka tuhandete võrra, praktiliselt kvaliteedi hindamist halvendamata?
Oletame, et oleme koolinud palju ML-mudeleid, genereerinud nende alusel tunnuseid ja koolinud veel ühe mudeli, mis järjestab dokumente kasutaja jaoks. Kõik oleks hästi, kuid ei saa niisama lihtsalt võtta ja arvutada kõiki tunnuseid kõigi dokumentide jaoks reaalajas, kui neid on miljoneid, ning soovitusi on vaja pakuda 100–200 ms jooksul. Ülesanne on valida miljonite seast mõni alamhulk, mis järjestatakse kasutajale. Seda etappi tuntakse tavaliselt kandidaatide valikuna. Sellele esitatakse mitmeid nõudeid. Esiteks peab valik toimuma väga kiiresti, et järjestamiseks jääks võimalikult palju aega. Teiseks, vähendades järjestatavate dokumentide arvu, peame maksimaalselt säilitama kasutajale asjakohased dokumendid.
Meie kandidaatide valimise printsip on evolutsiooni käigus arenenud ja praeguseks oleme jõudnud mitmeastmelise skeemini:
Esiteks jagatakse kõik dokumendid gruppidesse, ja igast grupist võetakse kõige populaarsemad dokumendid. Grupiks võivad olla veebisaidid, teemad, klastrid. Iga kasutaja jaoks valitakse tema ajaloost lähtuvalt kõige lähedasemad grupid ning neist võetakse kõige paremad dokumendid. Kasutame ka kNN-indekseerimist, et reaalajas leida kasutajale kõige lähedasemad dokumendid. KNN-indekeerimist on erinevaid meetodeid ja meil toimib parimal viisil (Hierarchical Navigable Small World graphs). See on hierarhiline mudel, mis võimaldab leida kasutajale miljonite andmebaasist N lähimat vektorit vaid mõne millisekundi jooksul. Eelnevalt indekseerime kogu meie dokumentide baasi off-line. Kuna indeksi otsing töötab üsna kiiresti, siis olemasolevate tugeva embeddi pingutustega on võimalik luua mitu indeksit (iga embedding jaoks üks indeks) ja pöörduda nende poole reaalajas.
Meil on käsil kümneid tuhandeid dokumente iga kasutaja jaoks. See on endiselt palju, et kõikide omaduste arvestamine oleks võimalik, seega rakendame sellel etapil kerget järjestamiseks — kergema mudeli, millel on vähem omadusi, raske järjestamise jaoks. Ülesanne on ennustada, millised dokumendid on raske mudeli jaoks tippude seas. Dokumendid, millel on kõige kõrgem ennustus, kasutatakse raske mudeli puhul, st viimases järjestamise etapis. See lähenemine võimaldab kümnetes millisekundites piirata kasutaja jaoks kaalutletud dokumentide arvu miljonist tuhandeteni.
ALS-i samm tööajal
Kuidas arvesse võtta kasutaja tagasisidet kohe pärast klikki?
Rekomendatsioonide puhul on oluline tegur kasutaja tagasiside reaktsiooniaeg. See on eriti oluline uute kasutajate jaoks: kui inimene hakkab just soovitussüsteemi kasutama, saab ta mitmekesise, mitte-personaliseeritud dokumendi voogu. Kui ta on teinud esimese klik, tuleb see kohe arvesse võtta ja kohandada tema huve vastavalt. Kui kõik tegurid arvutatakse offline, muutub süsteemi kiire reaktsioon viivituste tõttu võimatuks. Seetõttu on vajalik kasutaja tegevuse reaalajas töötlemine. Nende eesmärkide saavutamiseks kasutame ALS-i sammu tööajal kasutaja vektorite esitamiseks.
Oletame, et meil on kõigi dokumentide vektoriline esitamine. Näiteks saame offline-is artikli teksti põhjal luua sisestusi ELMo, BERTi või teiste masinõppe mudelite abil. Kuidas saada kasutajate vektoriline esitamine samas ruumis nende süsteemis toimuva interaktsiooni põhjal?
Kasutaja-dokumendi matrici koostamise ja lagunemise üldine põhimõteOletame, et meil on m kasutajat ja n dokumenti. Mõnedest kasutajatest on teada nende suhtumine teatud dokumentidesse. Seda teavet saab esitada m x n maatriksina: read vastavad kasutajatele ja veerud dokumentidele. Kuna enamikku dokumentidest ei ole inimene näinud, jääb suurem osa maatriksi kelladest tühjaks, teised aga täidetakse. Iga sündmuse (meeldib, ei meeldi, klik) jaoks on maatriksis ette nähtud mingi väärtus — aga arutame lihtsustatud mudelit, kus meeldib on 1 ja ei meeldi on -1.
Laguneme maatriksi kaheks: P (m x d) ja Q (d x n), kus d on vektorilise esitamise dimensioon (tavaliselt on see väike number). Seega vastab igale objektile d-mõõtmeline vektor (kasutajale — rida maatriksis P, dokumendile — veerg maatriksis Q). Need vektorid ongi vastavate objektide esitused. Et ennustada, kas kasutajale meeldib dokument, võib lihtsalt korrutada nende esitused.
Üks võimalik maatriksi lagunemise meetod on ALS (Alternating Least Squares). Optimeerime järgmise kaotuse funktsiooni:
Siin rui on kasutaja u interaktsioon dokumendiga i, qi on dokumendi i vektor, pu on kasutaja u vektor.
Siis optimaalse keskmise ruutvektor kasutajast (fikseeritud dokumendi vektorite korral) määratakse analüütiliselt vastava lineaarse regressiooni lahendamise abil.
Seda nimetatakse "ALS-i sammuks". Ja ALS-i algoritm seisneb selles, et me fikseerime vaheldumisi ühe maatriksi (kasutajate ja artiklite) ja värskendame teise, leides optimaalse lahenduse.
Õnneks on kasutaja vektorilise esituse leidmine üsna kiire protsess, mida saab teha tööajal, kasutades vektoralgebraga seotud juhiseid. See trikk võimaldab kohe arvesse võtta kasutaja tagasisidet järjestamises. Sama esitust saab kasutada ka kNN-indeksis kandidaatide valiku parendamiseks.
Jaotatud koostööpõhine filtreerimine
Kuidas teha inkrementaalset jaotatud maatriksi faktoriseerimist ja kiiresti leida uute artiklite vektorilised esitused?
Sisu ei ole ainus signaalide allikas soovituste jaoks. Teine oluline allikas on koostööpõhine teave. Head omadused järjestamises saame traditsiooniliselt kasutaja-dokumendi maatriksi lagundamise kaudu. Kuid proovides teha sellist lagundamist, seisame silmitsi probleemidega:
1. Meil on miljoneid dokumente ja kümneid miljoneid kasutajaid. Maatriks ei mahtunud täielikult ühele masinale, ja lagunemine takes palju aega.
2. Suurema osa sisust on süsteemis lühike eluiga: dokumendid jäävad asjakohaseks vaid paariks tunniks. Seetõttu on vajalik nende vektorilise esitluse võimalikult kiire loomine.
3. Kui dokument avaldatakse kohe, ei suuda seda piisav arv kasutajaid hinnata. Seetõttu on selle vektori esitus tõenäoliselt halva kvaliteediga.
4. Kui kasutaja annab meeldimise või mitte-meeldimise, ei saa me seda kohe arvesse võtta jaotuses.
Nende probleemide lahendamiseks rakendasime jaotatud kasutaja-dokumentide maatriksi, millel on sagedased jooksva ajakohastamise uuendused. Kuidas see täpselt töötab?
Oletame, et meil on N masina klaster (N on sadades) ja soovime teha jaotatud maatriksi, mis ei mahtunud ühe masinasse. Kuidas seda jaotust teostada, et igas masinas oleks piisavalt andmeid ja samal ajal oleks arvutused sõltumatud?
Kasutame eespool kirjeldatud ALS- jaotuse algoritmi. Vaatame, kuidas teostada ALS-i ühte sammu jaotatult — ülejäänud sammud sarnanevad sellele. Oletame, et meil on kinnitatud dokumendi maatriks ja soovime koostada kasutaja maatriksi. Selle jaoks jagame selle N osaks ridade kaupa, iga osa sisaldab umbes sama palju ridu. Saadame igasse masinasse vastavate ridade mitte-tühjad rakud, samuti dokumendi embeddingi maatriksi (täielikult). Kuna selle suurus ei ole liiga suur ja kasutaja-dokumendi maatriks on tavaliselt väga harv, mahtuvad need andmed tavalisel masinalse.
Seda trikki saab korrata mitme ajastu jooksul, kuni mudel konvergub, vaheldumisi muutes fikseeritud maatriksit. Kuid isegi siis võib maatriksi lahtiütlemine kesta mitu tundi. Ja see ei lahenda probleemi, et tuleb kiiresti saada uute dokumentide embeddingeid ja uuendada nende embeddingeid, mille kohta oli mudeli koostamise hetkel vähe teavet.
Meie abi oli mudeli kiire jooksva ajakohastamise rakendamine. Oletame, et meil on praegu koolitatud mudel. Alates selle treenimisest on ilmunud uusi artikleid, millega meie kasutajad on suhelnud, ja artikleid, millel treenimise ajal oli vähe suhtlemist. Nende artiklite embeddinge kiireks hankimiseks kasutame kasutajate embeddingeid, mis on saadud mudeli esimese suurte õppimise käigus, ja teeme ühe ALS-i sammu, et arvutada dokumendi maatriks fikseeritud kasutaja maatriksi juures. See võimaldab embeddinge üsna kiiresti hankida — paar minutit pärast dokumenti avaldamist — ja tihti uuendada värskeid dokumentide embeddinge.
Selleks, et soovitustes arvesse võtta inimese tegevust, ei kasuta me jooksva ajal offline režiimis saadud kasutaja embeddinge. Selle asemel teeme ALS-i sammu ja saame kasutaja aktuaalse vektori.
Töötamine teise domeeni laiendamisega
Kuidas kasutada kasutaja tagasisidet tekstiliste artiklite jaoks, et koostada video vektorite esitus?
Alguses soovitasime ainult tekstilisi artikleid, seega on paljud meie algoritmid seadistatud selle tüübi sisu jaoks. Kuid kui lisasime uut tüüpi sisu, seisis meil silmitsi mudelite kohandamise vajadus. Kuidas me lahendasime seda probleemi video näitel? Üks võimalus oleks olnud kõik mudelid nullist üle koolitada. Kuid see on aeganõudev ning osa algoritme nõuab koolitusandmete mahu osas, mille hulk ei ole uue tüübi sisu jaoks alguses piisav.
Me läksime teist teed ja taaskasutasime tekstide mudeleid video jaoks. Video vektorite esituse loomisel aitas meid sama ALS-i trikk. Võtsime tekstiliste artiklite alusel saadud kasutajate vektorid ja tegime ALS-i sammu, kasutades video vaatamise teavet. Nii saime vaevata video vektorite esitluse. Ja jooksva ajal arvutame lihtsalt lähedust tekstiliste artiklite alusel saadud kasutaja vektori ja video vektori vahel.
Kokkuvõte
Reaalajas soovitussüsteemi arendamine toob kaasa hulgaliselt ülesandeid. Andmete kiire töötlemine ja ML-mudelite rakendamine, et neid andmeid tõhusalt kasutada; keerukate jaotatud süsteemide loomine, mis suudavad minimaalses ajas töötlema kasutaja signaale ja uusi sisuühikuid; ja palju muid ülesandeid.
Praeguses süsteemis, mille seadet ma kirjeldasin, kasvab soovituste kvaliteet koos kasutaja tegevuse ja teenuses viibimise kestusega. Kuid siin peitub ka peamine väljakutse: süsteemil on raske koheselt mõista inimese huve, kes on vähe sisu tarbinud. Uute kasutajate soovituste paranemine on meie peamine ülesanne. Me jätkame algoritmide optimeerimist, et asjakohane sisu jõuaks kiiremini tema ajajoonele ja ebaasjakohane ei kuvata.
Allikas: habr.com
