Nimeni on Pavel Parkhomenko, olen ML-kehittäjä. Tässä artikkelissa haluan puhua Yandex.Zen-palvelun rakenteesta ja jakaa teknisiä parannuksia, joiden toteuttaminen on mahdollistanut suositusten laadun parantamisen. Tästä viestistä opit löytämään käyttäjälle tärkeimmät asiakirjat miljoonien asiakirjojen joukosta muutamassa millisekunnissa. kuinka suuren matriisin (joka koostuu miljoonista sarakkeista ja kymmenistä miljoonista riveistä) jatkuva hajottaminen niin, että uudet asiakirjat saavat vektorin kymmenissä minuuteissa; kuinka käyttää uudelleen käyttäjäartikkelimatriisin hajottamista hyvän vektoriesityksen saamiseksi videolle.
Suositustietokanta sisältää miljoonia erimuotoisia asiakirjoja: alustallamme luotuja ja ulkoisilta sivustoilta poimittuja tekstiartikkeleita, videoita, kertomuksia ja lyhyitä postauksia. Tällaisen palvelun kehittämiseen liittyy lukuisia teknisiä haasteita. Tässä muutama niistä:
- Jaa laskentatehtävät: tee kaikki raskaat toiminnot offline-tilassa ja suorita reaaliajassa vain mallien nopea sovellus ollaksesi vastuussa 100-200 ms:sta.
- Ota nopeasti huomioon käyttäjän toimet. Tätä varten on välttämätöntä, että kaikki tapahtumat toimitetaan välittömästi suosittelijalle ja vaikuttavat mallien tuloksiin.
- Tee syötteestä niin, että uusille käyttäjille se mukautuu nopeasti heidän käyttäytymiseensä. Juuri järjestelmään liittyneiden tulisi tuntea, että heidän palautteensa vaikuttaa suosituksiin.
- Ymmärrä nopeasti, kenelle suositella uutta artikkelia.
- Reagoi nopeasti jatkuvaan uuden sisällön syntymiseen. Joka päivä julkaistaan kymmeniä tuhansia artikkeleita, ja monilla niistä on rajoitettu elinikä (esimerkiksi uutiset). Tämä erottaa ne elokuvista, musiikista ja muusta pitkäikäisestä ja kalliista luotavasta sisällöstä.
- Siirrä tietoa alueelta toiselle. Jos suositusjärjestelmässä on koulutettuja malleja tekstiartikkeleille ja lisäämme siihen videota, voimme käyttää olemassa olevia malleja uudelleen, jotta uudentyyppinen sisältö sijoittuu paremmin.
Kerron teille, kuinka ratkaisimme nämä ongelmat.
Ehdokkaiden valinta
Kuinka vähentää tarkasteltavien asiakirjojen määrää tuhansia kertoja muutamassa millisekunnissa ilman, että sijoituksen laatu heikkenee käytännössä?
Oletetaan, että olemme kouluttaneet monia ML-malleja, luoneet ominaisuuksia niiden pohjalta ja kouluttaneet toisen mallin, joka luokittelee asiakirjat käyttäjälle. Kaikki olisi hyvin, mutta et voi vain ottaa ja laskea kaikkia merkkejä kaikille asiakirjoille reaaliajassa, jos näitä asiakirjoja on miljoonia, ja suositukset on rakennettava 100-200 ms: ssa. Tehtävänä on valita miljoonien joukosta tietty osajoukko, joka sijoitetaan käyttäjälle. Tätä vaihetta kutsutaan yleensä ehdokkaiden valinnaksi. Sille on useita vaatimuksia. Ensinnäkin valinnan on tapahduttava hyvin nopeasti, jotta itse sijoitukseen jää mahdollisimman paljon aikaa. Toiseksi, koska olemme vähentäneet huomattavasti sijoitettavien asiakirjojen määrää, meidän on säilytettävä käyttäjän kannalta merkitykselliset asiakirjat mahdollisimman täydellisesti.
Ehdokkaiden valintaperiaatteemme on kehittynyt, ja tällä hetkellä olemme päässeet monivaiheiseen järjestelmään:
Ensinnäkin kaikki asiakirjat jaetaan ryhmiin, ja suosituimmat asiakirjat otetaan kustakin ryhmästä. Ryhmät voivat olla sivustoja, aiheita, klustereita. Jokaiselle käyttäjälle valitaan hänen historiansa perusteella häntä lähimmät ryhmät ja niistä poimitaan parhaat dokumentit. Käytämme kNN-indeksiä myös valitsemaan reaaliajassa käyttäjää lähinnä olevia asiakirjoja. KNN-indeksin muodostamiseen on useita menetelmiä; meidän toimimme parhaiten (Hierarkkiset navigoitavat pienen maailman kaaviot). Tämä on hierarkkinen malli, jonka avulla voit löytää N lähintä vektoria käyttäjälle miljoonien tietokannasta muutamassa millisekunnissa. Indeksoimme ensin koko asiakirjatietokantamme offline-tilassa. Koska haku hakemistosta toimii melko nopeasti, voit luoda useita indeksejä (yksi hakemisto jokaiselle upotukselle) ja käyttää niitä reaaliajassa, jos upotuksia on useita.
Meillä on edelleen kymmeniä tuhansia asiakirjoja jokaista käyttäjää kohti. Tämä on vielä paljon kaikkien ominaisuuksien laskemiseen, joten tässä vaiheessa käytämme kevyttä ranking-mallia - kevyttä, raskasta ranking-mallia, jossa on vähemmän ominaisuuksia. Tehtävänä on ennustaa, mitkä dokumentit raskaalla mallilla on kärjessä. Korkeimman ennustajan omaavia asiakirjoja käytetään raskaassa mallissa, eli rankingin viimeisessä vaiheessa. Tämän lähestymistavan avulla voit pienentää käyttäjälle harkittujen asiakirjojen tietokantaa miljoonista tuhansiin kymmenissä millisekunneissa.
ALS-askel suoritusaikana
Kuinka ottaa huomioon käyttäjäpalaute heti napsautuksen jälkeen?
Tärkeä tekijä suosituksissa on vastausaika käyttäjien palautteeseen. Tämä on erityisen tärkeää uusille käyttäjille: kun henkilö vasta alkaa käyttää suositusjärjestelmää, hän saa ei-personoimattoman syötteen eri aiheisiin liittyvistä asiakirjoista. Heti kun hän tekee ensimmäisen napsautuksen, sinun on otettava tämä välittömästi huomioon ja mukauduttava hänen etuihinsa. Jos lasket kaikki tekijät offline-tilassa, nopea järjestelmän vastaus tulee mahdottomaksi viiveen vuoksi. On siis välttämätöntä käsitellä käyttäjän toimia reaaliajassa. Näihin tarkoituksiin käytämme ALS-vaihetta ajon aikana rakentaaksemme käyttäjän vektoriesityksen.
Oletetaan, että meillä on vektoriesitys kaikille asiakirjoille. Voimme esimerkiksi rakentaa upotuksia offline-tilassa artikkelin tekstin perusteella käyttämällä ELMo-, BERT- tai muita koneoppimismalleja. Kuinka voimme saada vektoriesityksen käyttäjistä samassa tilassa perustuen heidän vuorovaikutukseensa järjestelmässä?
Yleinen periaate käyttäjä-asiakirjamatriisin muodostamiseksi ja hajottamiseksiOlkoon meillä m käyttäjää ja n dokumenttia. Joidenkin käyttäjien suhteen tiettyihin asiakirjoihin tiedetään. Sitten nämä tiedot voidaan esittää mxn-matriisina: rivit vastaavat käyttäjiä ja sarakkeet vastaavat asiakirjoja. Koska henkilö ei ole nähnyt suurinta osaa asiakirjoista, suurin osa matriisisoluista jää tyhjiksi, kun taas toiset täyttyvät. Jokaiselle tapahtumalle (tykkää, en pidä, napsauta) annetaan jokin arvo matriisissa - mutta tarkastellaan yksinkertaistettua mallia, jossa tykkääminen vastaa arvoa 1 ja ei pidä -1.
Jaetaan matriisi kahdeksi: P (mxd) ja Q (dxn), missä d on vektoriesityksen ulottuvuus (yleensä pieni luku). Sitten jokainen objekti vastaa d-ulotteista vektoria (käyttäjälle - rivi matriisissa P, dokumentille - sarake matriisissa Q). Nämä vektorit ovat vastaavien objektien upotuksia. Voit ennustaa, pitääkö käyttäjä dokumentista, yksinkertaisesti moninkertaistamalla niiden upotukset.
Yksi mahdollisista tavoista hajottaa matriisi on ALS (Alternating Least Squares). Optimoimme seuraavan häviöfunktion:
Tässä rui on käyttäjän u vuorovaikutus asiakirjan i kanssa, qi on asiakirjan i vektori, pu on käyttäjän u vektori.
Sitten optimaalinen käyttäjävektori keskineliövirheen kannalta (kiinteille dokumenttivektoreille) löydetään analyyttisesti ratkaisemalla vastaava lineaarinen regressio.
Tätä kutsutaan "ALS-vaiheeksi". Ja itse ALS-algoritmi on, että korjaamme vuorotellen yhden matriiseista (käyttäjät ja artikkelit) ja päivitämme toista löytääksemme optimaalisen ratkaisun.
Onneksi käyttäjän vektoriesityksen löytäminen on melko nopea toimenpide, joka voidaan tehdä ajon aikana vektoriohjeiden avulla. Tämän tempun avulla voit ottaa käyttäjien palautteen välittömästi huomioon sijoituksessa. Samaa upotusta voidaan käyttää kNN-indeksissä ehdokasvalinnan parantamiseksi.
Hajautettu yhteistyösuodatus
Kuinka tehdä inkrementaalinen hajautettu matriisifaktorointi ja löytää nopeasti uusien artikkeleiden vektoriesitykset?
Sisältö ei ole ainoa suositussignaalien lähde. Toinen tärkeä lähde on yhteistyötieto. Hyvät luokitusominaisuudet saadaan perinteisesti käyttäjä-asiakirjamatriisin hajotuksesta. Mutta kun yritimme tehdä tällaista hajotusta, kohtasimme ongelmia:
1. Meillä on miljoonia asiakirjoja ja kymmeniä miljoonia käyttäjiä. Matriisi ei mahdu kokonaan yhdelle koneelle, ja hajoaminen kestää hyvin kauan.
2. Suurin osa järjestelmän sisällöstä on lyhytikäinen: asiakirjat pysyvät merkityksellisinä vain muutaman tunnin. Siksi on välttämätöntä rakentaa niiden vektoriesitys mahdollisimman nopeasti.
3. Jos rakennat hajotuksen heti dokumentin julkaisun jälkeen, riittävä määrä käyttäjiä ei ehdi arvioimaan sitä. Siksi sen vektoriesitys ei todennäköisesti ole kovin hyvä.
4. Jos käyttäjä pitää tai ei pidä, emme voi heti ottaa tätä huomioon hajotuksessa.
Näiden ongelmien ratkaisemiseksi otimme käyttöön hajautetun hajautuksen käyttäjä-asiakirjamatriisista useilla asteittaisilla päivityksillä. Kuinka se tarkalleen ottaen toimii?
Oletetaan, että meillä on N koneen klusteri (N on sadoissa) ja haluamme tehdä niille hajautetun matriisin, joka ei sovi yhteen koneeseen. Kysymys kuuluukin, miten tämä hajottaminen suoritetaan niin, että toisaalta jokaisesta koneesta on riittävästi tietoa ja toisaalta niin, että laskelmat ovat riippumattomia?
Käytämme edellä kuvattua ALS-hajotusalgoritmia. Katsotaanpa, kuinka yksi ALS-vaihe suoritetaan hajautetusti - loput vaiheet ovat samanlaisia. Oletetaan, että meillä on kiinteä asiakirjojen matriisi ja haluamme rakentaa matriisin käyttäjistä. Tätä varten jaamme sen N osaan rivillä, jokainen osa sisältää suunnilleen saman määrän rivejä. Lähetämme jokaiselle koneelle vastaavien rivien ei-tyhjät solut sekä asiakirjan upotusmatriisin (kokonaan). Koska sen koko ei ole kovin suuri ja käyttäjä-asiakirjamatriisi on yleensä hyvin harva, nämä tiedot mahtuvat tavalliseen koneeseen.
Tämä temppu voidaan toistaa useiden aikakausien ajan, kunnes malli konvergoi, vuorotellen kiinteää matriisia yksitellen. Mutta silloinkin matriisin hajoaminen voi kestää useita tunteja. Eikä tämä ratkaise ongelmaa, että sinun täytyy nopeasti vastaanottaa upotukset uusista asiakirjoista ja päivittää niiden upotukset, joista mallia rakennettaessa oli vähän tietoa.
Nopeiden inkrementaalisten mallipäivitysten käyttöönotto auttoi meitä. Oletetaan, että meillä on tällä hetkellä koulutettu malli. Hänen koulutuksestaan lähtien on ollut uusia artikkeleita, joiden kanssa käyttäjämme ovat olleet vuorovaikutuksessa, sekä artikkeleita, joissa on ollut vähän vuorovaikutusta koulutuksen aikana. Saadaksemme nopeasti tällaisten artikkelien upotukset, käytämme mallin ensimmäisen suuren harjoittelun aikana saatuja käyttäjien upotuksia ja teemme yhden ALS-vaiheen dokumenttimatriisin laskemiseksi kiinteällä käyttäjämatriisilla. Näin voit vastaanottaa upotuksia melko nopeasti - muutaman minuutin kuluessa asiakirjan julkaisemisesta - ja usein päivittää uusimpien asiakirjojen upotukset.
Suositusten antamiseksi otamme välittömästi huomioon ihmisten toimet, emmekä käytä ajon aikana offline-tilassa hankittuja käyttäjien upotuksia. Sen sijaan teemme ALS-vaiheen ja hankimme todellisen käyttäjävektorin.
Siirrä toiselle verkkotunnukselle
Kuinka käyttää käyttäjien palautetta tekstiartikkeleista videon vektoriesityksen rakentamiseen?
Alun perin suosittelimme vain tekstiartikkeleita, joten monet algoritmeistamme on räätälöity tämäntyyppiseen sisältöön. Mutta kun lisäsimme muuntyyppistä sisältöä, kohtasimme tarpeen mukauttaa malleja. Kuinka ratkaisimme tämän ongelman videoesimerkin avulla? Yksi vaihtoehto on kouluttaa kaikki mallit uudelleen alusta. Mutta tämä kestää kauan, ja osa algoritmeista vaatii koulutusnäytteen kokoa, jota ei ole vielä saatavilla tarvittavassa määrin uudentyyppiselle sisällölle sen elinkaaren ensimmäisinä hetkinä palvelussa.
Menimme toiseen suuntaan ja käytimme tekstimalleja uudelleen videossa. Sama ALS-temppu auttoi meitä luomaan videoiden vektoriesitystä. Otimme vektoriesityksen käyttäjistä tekstiartikkelien perusteella ja teimme ALS-vaiheen käyttämällä videonäkymätietoja. Joten saimme helposti vektoriesityksen videosta. Ja ajon aikana laskemme yksinkertaisesti tekstiartikkeleista saadun käyttäjävektorin ja videovektorin välisen läheisyyden.
Johtopäätös
Reaaliaikaisen suositusjärjestelmän ytimen kehittämiseen liittyy monia haasteita. Sinun on käsiteltävä tietoja nopeasti ja käytettävä ML-menetelmiä käyttääksesi näitä tietoja tehokkaasti. rakentaa monimutkaisia hajautettuja järjestelmiä, jotka pystyvät käsittelemään käyttäjän signaaleja ja uusia sisältöyksiköitä mahdollisimman lyhyessä ajassa; ja monia muita tehtäviä.
Nykyisessä järjestelmässä, jonka suunnittelua kuvailin, suositusten laatu käyttäjälle kasvaa hänen aktiivisuutensa ja palvelussa oleskelun pituuden myötä. Mutta tietysti tässä piilee suurin vaikeus: järjestelmän on vaikea ymmärtää välittömästi sellaisen henkilön etuja, jolla on vähän vuorovaikutusta sisällön kanssa. Uusien käyttäjien suositusten parantaminen on keskeinen tavoitteemme. Jatkamme algoritmien optimointia, jotta henkilön kannalta olennainen sisältö pääsee hänen syötteensä nopeammin, eikä asiaankuuluvaa sisältöä näytetä.
Lähde: will.com