HNSW<\/a><\/noindex> (Hierarchical Navigable Small World graphs). Dette er en hierarkisk model, der g\u00f8r det muligt at finde N n\u00e6rmeste vektorer for brugeren fra en millionbase p\u00e5 f\u00e5 millisekunder. Forud for dette indekserer vi offline hele vores dokumentbase. Da s\u00f8gning i indekset fungerer ret hurtigt, kan man ved at have flere kraftige embeddings lave flere indekser (\u00e9n for hver embedding) og tilg\u00e5 hver af dem i realtid.<\/p>\nVi har titusindvis af dokumenter til hver bruger. Det er stadig mange at t\u00e6lle alle egenskaber, s\u00e5 p\u00e5 dette tidspunkt anvender vi en let rangering - en forenklet model af tung rangering med f\u00e6rre egenskaber. Opgaven er at forudsige, hvilke dokumenter der vil v\u00e6re i toppen hos den tunge model. Dokumenter med den h\u00f8jeste forudsigelse vil blive brugt i den tunge model, dvs. p\u00e5 det sidste rangeringstrin. Denne tilgang g\u00f8r det muligt at reducere m\u00e6ngden af dokumenter, der overvejes for brugeren, fra millioner til tusinder p\u00e5 blot nogle f\u00e5 millisekunder.<\/p>\n
ALS-trin i runtime<\/h2>\n \nHvordan tager man h\u00f8jde for brugerens feedback straks efter et klik?<\/b><\/p>\n
En vigtig faktor i anbefalinger er responstiden p\u00e5 brugerfeedback. Dette er is\u00e6r vigtigt for nye brugere: n\u00e5r en person f\u00f8rst begynder at bruge anbefalingssystemet, f\u00e5r han en upersonlig str\u00f8m af forskellige tematiske dokumenter. S\u00e5 snart han foretager sit f\u00f8rste klik, skal dette straks tages i betragtning, og systemet skal tilpasse sig hans interesser. Hvis man beregner alle faktorer offline, vil hurtig respons fra systemet blive umulig p\u00e5 grund af forsinkelser. Derfor er det n\u00f8dvendigt at behandle brugerens handlinger i realtid. Til disse form\u00e5l bruger vi ALS-trinnet i runtime til at opbygge en vektorrepr\u00e6sentation af brugeren.<\/p>\n
Antag, at vi har en vektorrepr\u00e6sentation for alle dokumenter. For eksempel kan vi offline opbygge indlejringer baseret p\u00e5 tekstindholdet i artiklen ved hj\u00e6lp af ELMo, BERT eller andre maskinl\u00e6ringsmodeller. Hvordan kan vi f\u00e5 brugerens vektorrepr\u00e6sentation i det samme rum baseret p\u00e5 deres interaktion i systemet?<\/p>\n
Den generelle metode til dannelse og nedbrydning af brugerdokumentmatrixen<\/b>Lad os sige, at vi har m brugere og n dokumenter. For nogle brugere kender vi deres forhold til nogle dokumenter. S\u00e5 kan denne information repr\u00e6senteres i en matrix m x n: r\u00e6kkerne svarer til brugerne, og kolonnerne svarer til dokumenterne. Da de fleste dokumenter aldrig er blevet set af en person, vil st\u00f8rstedelen af matrixens celler forblive tomme, mens andre vil v\u00e6re udfyldt. For hver h\u00e6ndelse (like, dislike, klik) i matrixt er der foreskrevet en bestemt v\u00e6rdi - men lad os overveje en forenklet model, hvor et like svarer til 1, og et dislike til -1.<\/p>\n
Lad os opdele matrixen i to: P (m x d) og Q (d x n), hvor d er dimensionen af den vektorm\u00e6ssige repr\u00e6sentation (normalt et lille tal). S\u00e5 vil hver objekt have en d-dimensionel vektor (brugerens r\u00e6kke i matrixen P, dokumentets kolonne i matrixen Q). Disse vektorer vil v\u00e6re indlejringerne af de tilsvarende objekter. For at forudsige, om et dokument vil blive bestemt som v\u00e6rende godt af brugeren, kan vi blot multiplicere deres indlejringer.<\/p>\n
\nHer er rui interaktionen mellem bruger u og dokument i, qi er dokument i's vektor, pu er bruger u's vektor.<\/p>\n
S\u00e5 den optimale vektor for brugeren (givet de faste dokumentvektorer) findes analytisk ved at l\u00f8se den relevante line\u00e6re regression.<\/p>\n
Dette kaldes \"ALS-trinnet\". Selve ALS-algoritmen best\u00e5r i, at vi skiftevis fasts\u00e6tter en af matrixerne (brugere og artikler) og opdaterer den anden, og finder den optimale l\u00f8sning.<\/p>\n
Heldigvis er det en ret hurtig operation at finde brugerens vektorrepr\u00e6sentation, som kan udf\u00f8res ved runtime ved hj\u00e6lp af vektorinstruktioner. Dette trick tillader os med det samme at tage h\u00f8jde for brugerens feedback i rangeringen. Den samme indlejring kan ogs\u00e5 bruges i kNN-indekset for at forbedre udv\u00e6lgelsen af kandidater.<\/p>\n
Fordelt kollaborativ filtrering<\/h2>\n \nHvordan laver man inkrementel distribueret matrixfaktorisering og hurtigt finder den vektorm\u00e6ssige repr\u00e6sentation af nye artikler?<\/b><\/p>\n
Indhold er ikke den eneste kilde til signaler for anbefalinger. En anden vigtig kilde er samarbejdsinformation. Gode indikatorer for rangering kan traditionelt opn\u00e5s ved at nedbryde bruger-dokument-matricen. Men n\u00e5r vi fors\u00f8gte at udf\u00f8re en s\u00e5dan nedbrydning, st\u00f8dte vi p\u00e5 problemer:<\/p>\n
1. Vi har millioner af dokumenter og titusinder af millioner af brugere. Matricen kan ikke opbevares p\u00e5 \u00e9n enkelt maskine, og nedbrydningen vil v\u00e6re meget langvarig.
For at l\u00f8se de n\u00e6vnte problemer har vi implementeret en distribueret nedbrydning af bruger-dokument-matricen med hyppige inkrementelle opdateringer. Hvordan fungerer det pr\u00e6cist?<\/p>\n
Antag, at vi har et cluster af N maskiner (N t\u00e6lles i hundreder), og vi \u00f8nsker at udf\u00f8re en distribueret nedbrydning af matricen, som ikke kan opbevares p\u00e5 \u00e9n maskine. Sp\u00f8rgsm\u00e5let er, hvordan vi udf\u00f8rer denne nedbrydning, s\u00e5 der p\u00e5 den ene side er tilstr\u00e6kkeligt med data p\u00e5 hver maskine, og p\u00e5 den anden side at beregningerne forbliver uafh\u00e6ngige? <\/p>\n
Denne metode kan gentages i flere epoker indtil modelkonvergens, ved skiftevis at \u00e6ndre den faste matrix. Men selv da kan matrixfaktoriseringen tage flere timer. Og det l\u00f8ser ikke problemet med, at vi hurtigt skal generere embedding af nye dokumenter og opdatere embeddingene af de dokumenter, som havde lidt information under modeltr\u00e6ningen. <\/p>\n
Vi blev hjulpet af implementeringen af en hurtig inkrementel opdatering af modellen. Lad os antage, at vi har en nuv\u00e6rende tr\u00e6net model. Siden dens tr\u00e6ning er der kommet nye artikler, som vores brugere har interageret med, samt artikler som under tr\u00e6ningen havde lidt interaktioner. For hurtigt at generere embedding af s\u00e5danne artikler bruger vi brugerembeddingene, der blev opn\u00e5et under den f\u00f8rste store tr\u00e6ning af modellen, og udf\u00f8rer et ALS-trin for at beregne dokumentmatrixen med en fast bruger-matrix. Dette g\u00f8r det muligt at f\u00e5 embedding ret hurtigt - inden for f\u00e5 minutter efter offentligg\u00f8relsen af dokumentet - og ofte opdatere embedding af friske dokumenter.<\/p>\n
For at anbefalingerne straks tager h\u00f8jde for menneskelige handlinger, bruger vi ikke bruger-embedding opn\u00e5et offline i runtime. I stedet udf\u00f8rer vi et ALS-trin og f\u00e5r den aktuelle brugervektor.<\/p>\n
Overf\u00f8rsel til et andet dom\u00e6ne<\/h2>\n \nHvordan kan man bruge feedback fra brugere af tekstartikler til at opbygge en vektorisk repr\u00e6sentation af video?<\/b><\/p>\n
Oprindeligt anbefalede vi kun tekstartikler, s\u00e5 mange af vores algoritmer er skr\u00e6ddersyet til denne type indhold. Men ved tils\u00e6tning af indhold af en anden type st\u00f8dte vi p\u00e5 behovet for at tilpasse modellerne. Hvordan l\u00f8ste vi denne opgave i forbindelse med video? En mulighed er at gentr\u00e6ne alle modeller fra bunden. Men det tager tid, desuden er nogle af algoritmerne kr\u00e6vende, hvad ang\u00e5r st\u00f8rrelsen af tr\u00e6ningsdatas\u00e6ttet, som endnu ikke er tilstr\u00e6kkeligt for det nye indholds type i de f\u00f8rste \u00f8jeblikke af dets liv p\u00e5 tjenesten.<\/p>\n
Vi tog en anden tilgang og genbrugt tekstmodeller til video. I skabelsen af vektorrepr\u00e6sentationer for video hjalp den samme ALS-trick os. Vi tog brugerens vektorrepr\u00e6sentation baseret p\u00e5 tekstartikler og udf\u00f8rte et ALS-tr\u00e6k ved at bruge videoafspilningsdata. S\u00e5dan fik vi nemt vektorrepr\u00e6sentationen for video. Og i runtime beregner vi blot n\u00e6rheden mellem brugerens vektor, der er opn\u00e5et p\u00e5 baggrund af tekstartikler, og videoens vektor.<\/p>\n
Konklusion<\/h2>\n \nUdviklingen af kernen i det realtidsanbefalingssystem er forbundet med mange opgaver. Det er n\u00f8dvendigt hurtigt at behandle data og anvende ML-metoder for effektivt at udnytte disse data; opbygge komplekse distribuerede systemer, der kan behandle brugerens signaler og nye indholdsenheder p\u00e5 kort tid; og mange andre opgaver.<\/p>\n
I det nuv\u00e6rende system, hvis enhed jeg har beskrevet, vokser kvaliteten af anbefalinger for brugeren i takt med deres aktivitet og opholdstid i tjenesten. Men naturligvis ligger den st\u00f8rste udfordring her: systemet har sv\u00e6rt ved straks at forst\u00e5 en persons interesser, som har haft lidt interaktion med indholdet. Forbedring af anbefalinger til nye brugere er vores n\u00f8gleopgave. Vi vil forts\u00e6tte med at optimere algoritmerne, s\u00e5 relevant indhold hurtigere n\u00e5r brugerens feed, mens irrelevant indhold ikke vises.habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u041f\u0430\u0440\u0445\u043e\u043c\u0435\u043d\u043a\u043e, \u044f ML-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e\u0431 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u042f\u043d\u0434\u0435\u043a\u0441.\u0414\u0437\u0435\u043d \u0438 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f\u043c\u0438, \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u043b\u043e \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0439. \u0418\u0437 \u043f\u043e\u0441\u0442\u0430 \u0432\u044b \u0443\u0437\u043d\u0430\u0435\u0442\u0435, \u043a\u0430\u043a \u0432\u0441\u0435\u0433\u043e \u0437\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u0438\u043b\u043b\u0438\u0441\u0435\u043a\u0443\u043d\u0434 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c \u0441\u0440\u0435\u0434\u0438 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u043e\u0432 \u043d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u0440\u0435\u043b\u0435\u0432\u0430\u043d\u0442\u043d\u044b\u0435 \u0434\u043b\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f; \u043a\u0430\u043a \u0434\u0435\u043b\u0430\u0442\u044c \u043d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u043e\u0435 \u0440\u0430\u0437\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043c\u0430\u0442\u0440\u0438\u0446\u044b (\u0441\u043e\u0441\u0442\u043e\u044f\u0449\u0435\u0439 \u0438\u0437 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u0441\u0442\u043e\u043b\u0431\u0446\u043e\u0432 \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":71853,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-71852","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/d63caf9162ca3533548fdef9cd740c24.png\")