HNSW<\/a><\/noindex> (Hierarchical Navigable Small World graphs). Dit is een hi\u00ebrarchisch model dat in enkele milliseconden de N dichtstbijzijnde vectors voor de gebruiker kan vinden uit een database van miljoenen. Vooraf indexeren we offline al onze documenten. Aangezien de zoekopdracht in de index redelijk snel werkt, kunnen we met een aantal sterke embeddings ook meerdere indexen maken (\u00e9\u00e9n index voor elke embedding) en in real-time naar elk van deze indexen verwijzen.<\/p>\nWe hebben tienduizenden documenten voor elke gebruiker. Dit blijft veel als het gaat om het tellen van alle kenmerken, dus in dit stadium passen we lichte rangschikking toe - een vereenvoudigd model van zware rangschikking met minder kenmerken. Het doel is om te voorspellen welke documenten bovenaan de zware model zullen staan. Documenten met de hoogste voorspelling worden gebruikt in het zware model, dat wil zeggen in de laatste rangschikkingsfase. Deze aanpak maakt het mogelijk om in enkele milliseconden de database van documenten die voor de gebruiker in aanmerking komen van miljoenen tot duizenden te reduceren.<\/p>\n
ALS-stap in runtime<\/h2>\n \nHoe feedback van de gebruiker te verwerken onmiddellijk na de klik?<\/b><\/p>\n
Een belangrijke factor in aanbevelingen is de responstijd op de feedback van de gebruiker. Dit is vooral belangrijk voor nieuwe gebruikers: wanneer iemand net begint met het gebruik van het aanbevelingssysteem, ontvangt hij een ongepersonaliseerde feed van diverse documenten. Zodra hij de eerste klik maakt, moet dit onmiddellijk worden in overweging genomen en moet het systeem zich afstemmen op zijn interesses. Als alle factoren offline worden berekend, wordt een snelle reactie van het systeem onmogelijk door de vertraging. Daarom is het noodzakelijk om de acties van de gebruiker in realtime te verwerken. Voor deze doeleinden gebruiken we de ALS-stap in runtime om de vectorrepresentatie van de gebruiker op te bouwen.<\/p>\n
Laten we aannemen dat we voor alle documenten een vectorrepresentatie hebben. Bijvoorbeeld, we kunnen offline op basis van de tekst van het artikel embeddings bouwen met behulp van ELMo, BERT of andere machine learning-modellen. Hoe kunnen we een vectorrepresentatie van gebruikers in dezelfde ruimte verkrijgen op basis van hun interactie in het systeem?<\/p>\n
Algemeen principe van het vormen en ontleden van de gebruikers-documentmatrix<\/b>Laten we aannemen dat we m gebruikers en n documenten hebben. Voor sommige gebruikers is hun relatie tot bepaalde documenten bekend. Deze informatie kan worden weergegeven in een matrix van m x n: de rijen komen overeen met de gebruikers en de kolommen met de documenten. Aangezien de meeste documenten door de gebruiker niet zijn bekeken, blijven veel cellen in de matrix leeg, terwijl andere gevuld zullen zijn. Voor elk evenement (like, dislike, klik) is er een waarde in de matrix \u2014 maar laten we een vereenvoudigd model beschouwen waarin een like overeenkomt met 1 en een dislike met -1.<\/p>\n
We splitsen de matrix in twee: P (m x d) en Q (d x n), waarbij d de dimensionele representatie is (meestal een klein aantal). Dan komt aan elk object een d-dimensionale vector toe (de gebruiker is een rij in matrix P, het document is een kolom in matrix Q). Deze vectoren zijn de embeddings van de overeenkomstige objecten. Om te voorspellen of een gebruiker een document leuk zal vinden, kunnen we eenvoudigweg hun embeddings vermenigvuldigen.<\/p>\n
\nHier is rui de interactie van gebruiker u met document i, qi de vector van document i, en pu de vector van gebruiker u.<\/p>\n
Dan wordt de optimale vector voor de gebruiker (bij vastgestelde documentvectoren) analytisch bepaald door de oplossing van de overeenkomstige lineaire regressie.<\/p>\n
Dit wordt de 'ALS-stap' genoemd. Het ALS-algoritme houdt in dat we om de beurt een van de matrices (gebruikers en artikelen) fixeren en de andere bijwerken om de optimale oplossing te vinden.<\/p>\n
Gelukkig is het vinden van de vectorrepresentatie van een gebruiker een vrij snelle operatie die in real-time kan worden uitgevoerd met behulp van vectorinstructies. Deze truc maakt het mogelijk om onmiddellijk rekening te houden met de feedback van de gebruiker in de rangschikking. Een vergelijkbare embedding kan ook worden gebruikt in de kNN-index voor een betere selectie van kandidaten.<\/p>\n
Gedistribueerde collaboratieve filtering<\/h2>\n \nHoe doe je incrementele gedistribueerde matrixfactorisatie en vind je snel de vectorrepresentatie van nieuwe artikelen?<\/b><\/p>\n
Content is not the only source of signals for recommendations. Another important source is collaborative information. Good indicators in ranking can traditionally be obtained from the decomposition of the user-document matrix. However, when attempting to carry out such decomposition, we encountered several problems:<\/p>\n
1. We have millions of documents and tens of millions of users. The matrix does not fit entirely on one machine, and the decomposition will take a very long time.
To resolve these issues, we implemented a distributed decomposition of the user-document matrix with frequent incremental updates. How exactly does this work?<\/p>\n
Let\u2019s assume we have a cluster of N machines (N counts in the hundreds) and we want to perform a distributed decomposition of a matrix that does not fit on a single machine. The question is how to execute this decomposition in such a way that, on one hand, each machine has enough data, and on the other hand, the computations are independent? <\/p>\n
Deze truc kan gedurende meerdere tijdperken worden herhaald tot de modelconvergentie, door afwisselend de vaste matrix te wijzigen. Maar zelfs dan kan het ontledigen van de matrix enkele uren duren. En dit lost het probleem niet op dat we snel de embeddings van nieuwe documenten moeten krijgen en de embeddings van die documenten moeten bijwerken waarvoor we tijdens de modelbouw weinig informatie hadden. <\/p>\n
We hebben het implementeren van een snelle incrementele update van het model geholpen. Stel dat we een actuele getrainde model hebben. Sinds de training zijn er nieuwe artikelen verschenen die onze gebruikers hebben bekeken, evenals artikelen die tijdens training weinig interactie hadden. Voor het snel verkrijgen van de embedding van dergelijke artikelen gebruiken we de gebruikersembeddings die tijdens de eerste grote training van het model zijn verkregen, en we doen \u00e9\u00e9n stap ALS om de documentmatrix te berekenen met een vaste gebruikersmatrix. Dit stelt ons in staat om embeddings vrij snel te krijgen - binnen enkele minuten na publicatie van het document - en vaak de embeddings van nieuwe documenten bij te werken.<\/p>\n
Om direct rekening te houden met de acties van de gebruiker bij aanbevelingen, gebruiken we in runtime de offline verkregen gebruikersembeddings niet. In plaats daarvan doen we een stap ALS en verkrijgen we de actuele gebruikersvector.<\/p>\n
Overdracht naar een ander domein<\/h2>\n \nHoe kunnen we de feedback van gebruikers op tekstartikelen gebruiken om een vectorrepresentatie van video te bouwen?<\/b><\/p>\n
Oorspronkelijk raadden we alleen tekstartikelen aan, waardoor veel van onze algoritmes zijn gericht op dit type inhoud. Maar bij het toevoegen van andere soorten inhoud kwamen we de behoefte tegen om de modellen aan te passen. Hoe hebben we deze uitdaging aangepakt aan de hand van video? Een van de opties is om alle modellen vanaf nul opnieuw te trainen. Maar dit kost veel tijd en bovendien zijn sommige algoritmes veeleisend wat betreft de hoeveelheid trainingsdata, die in de eerste momenten van het leven van nieuwe inhoud op de service nog niet in voldoende hoeveelheid aanwezig is.<\/p>\n
We took a different approach and reused text models for videos. In creating vector representations of videos, we utilized the same ALS trick. We took the vector representation of users based on textual articles and implemented an ALS step, using video view information. This allowed us to easily obtain the vector representation of the video. During runtime, we simply calculate the similarity between the user vector derived from text articles and the video vector.<\/p>\n
Conclusie<\/h2>\n \nThe development of the core real-time recommendation system is associated with numerous tasks. We need to quickly process data and apply ML methods for effective use of this data; build complex distributed systems capable of processing user signals and new content units in minimal time; and many other challenges.<\/p>\n
In the current system, the design of which I have described, the quality of recommendations for the user grows with their activity and the duration of their stay on the service. However, therein lies the main challenge: the system struggles to instantly understand the interests of a person who has interacted little with the content. Improving recommendations for new users is our key task. We will continue to optimize algorithms so that relevant content reaches their feeds faster, while irrelevant content is not displayed.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
![\"Hoe](\"\/wp-content\/uploads\/2020\/02\/d63caf9162ca3533548fdef9cd740c24.png\")