Dag Allemaal! Mijn naam is Sasha, ik ben CTO en medeoprichter van LoyaltyLab. Twee jaar geleden gingen mijn vrienden en ik, net als alle arme studenten, 's avonds bier kopen in de dichtstbijzijnde winkel vlakbij ons huis. We waren erg boos dat de winkelier, wetende dat we bier zouden komen halen, geen korting bood op chips of crackers, terwijl dit zo logisch was! We begrepen niet waarom deze situatie zich voordeed en besloten ons eigen bedrijf te starten. Geef jezelf als bonus elke vrijdag korting op diezelfde fiches.

En het kwam allemaal op het punt waarop ik materiaal over de technische kant van het product presenteerde NVIDIA AV. We delen ons werk graag met de gemeenschap, daarom publiceer ik mijn rapport in de vorm van een artikel.

Introductie

Net als iedereen aan het begin van het traject zijn we begonnen met een overzicht van hoe aanbevelingssystemen worden gemaakt. En de meest populaire architectuur bleek het volgende type te zijn:

Het bestaat uit twee delen:

1. Selectie van kandidaten voor aanbevelingen met behulp van een eenvoudig en snel model, meestal een samenwerkingsmodel.
2. Ranking van kandidaten met een complexer en trager contentmodel, waarbij rekening wordt gehouden met alle mogelijke kenmerken in de data.

Hierna zal ik de volgende termen gebruiken:

• kandidaat/kandidaat voor aanbevelingen — een gebruikersproductpaar dat mogelijk kan worden opgenomen in de aanbevelingen tijdens de productie.
• kandidatenextractie/extractor/kandidaatextractiemethode — een proces of methode om “aanbevelingskandidaten” uit de beschikbare gegevens te extraheren.

De eerste stap omvat meestal het gebruik van verschillende varianten van collaboratief filteren. Het meest populair - ALS. Het is verrassend dat de meeste artikelen over aanbevelingssystemen pas in de eerste fase verschillende verbeteringen aan samenwerkingsmodellen onthullen, maar dat niemand veel over andere steekproefmethoden praat. Voor ons werkte de aanpak om alleen samenwerkingsmodellen te gebruiken en verschillende optimalisaties daarmee niet met de kwaliteit die we verwachtten, dus hebben we ons specifiek op dit onderdeel in onderzoek verdiept. En aan het einde van het artikel zal ik laten zien hoeveel we ALS, wat onze basislijn was, hebben kunnen verbeteren.

Voordat ik verder ga met het beschrijven van onze aanpak, is het belangrijk op te merken dat er bij realtime aanbevelingen, wanneer het belangrijk voor ons is om rekening te houden met gegevens die 30 minuten geleden plaatsvonden, er eigenlijk niet veel benaderingen zijn die in de vereiste tijd kunnen werken. Maar in ons geval hoeven we niet vaker dan één keer per dag aanbevelingen te verzamelen, en in de meeste gevallen één keer per week, wat ons de mogelijkheid geeft om complexe modellen te gebruiken en de kwaliteit op verschillende manieren te verbeteren.

Laten we als basis nemen welke statistieken alleen ALS laat zien over de taak om kandidaten te extraheren. De belangrijkste statistieken die we monitoren zijn:

• Precisie - het aandeel correct geselecteerde kandidaten uit de steekproef.
• Recall is het percentage kandidaten dat zich heeft voorgedaan ten opzichte van de kandidaten die zich daadwerkelijk in het doelinterval bevonden.
• F1-score - F-maat berekend op basis van de voorgaande twee punten.

We zullen ook kijken naar de statistieken van het uiteindelijke model na het verhogen van de trainingsgradiënt met extra inhoudsfuncties. Er zijn hier ook drie belangrijke statistieken:

• precisie@5 - het gemiddelde percentage producten uit de top 5 in termen van waarschijnlijkheid voor elke koper.
• respons-rate@5 - conversie van klanten van een bezoek aan de winkel naar de aankoop van minimaal één persoonlijke aanbieding (5 producten in één aanbieding).
• gemiddelde roc-auc per gebruiker - gemiddeld roc-auc voor elke koper.

Het is belangrijk op te merken dat op al deze statistieken wordt gemeten kruisvalidatie van tijdreeksen, dat wil zeggen dat de training plaatsvindt in de eerste k weken, en k+1 week wordt als testgegevens genomen. Seizoensgebonden ups en downs hadden dus een minimale impact op de interpretatie van de kwaliteit van de modellen. Verderop in alle grafieken zal de abscis-as het weeknummer aangeven bij kruisvalidatie, en zal de ordinaat-as de waarde van de gespecificeerde metriek aangeven. Alle grafieken zijn gebaseerd op transactiegegevens van één klant, zodat onderlinge vergelijkingen kloppen.

Voordat we onze aanpak beginnen te beschrijven, kijken we eerst naar de basislijn, die een ALS-getraind model is.
Statistieken voor het ophalen van kandidaten:

Laatste statistieken:

Ik behandel alle implementaties van algoritmen als een soort bedrijfshypothese. Grofweg kan elk samenwerkingsmodel dus worden beschouwd als een hypothese dat “mensen de neiging hebben te kopen wat mensen die op hen lijken, kopen.” Zoals ik al zei, hebben we ons niet beperkt tot dergelijke semantiek, en hier zijn enkele hypothesen die goed werken op basis van gegevens in de offline detailhandel:

1. Die ik al eerder heb gekocht.
2. Vergelijkbaar met wat ik eerder kocht.
3. Periode van een lang vervlogen aankoop.
4. Populair per categorie/merk.
5. Alternatieve aankopen van verschillende goederen van week tot week (Markov-ketens).
6. Soortgelijke producten voor kopers, volgens kenmerken gebouwd door verschillende modellen (Word2Vec, DSSM, enz.).

Wat heb je eerder gekocht?

De meest voor de hand liggende heuristiek die heel goed werkt in de levensmiddelendetailhandel. Hier nemen we alle goederen die de loyaliteitskaarthouder in de afgelopen K dagen (meestal 1-3 weken) of K dagen een jaar geleden heeft gekocht. Als we alleen deze methode toepassen, verkrijgen we de volgende statistieken:

Hier is het heel duidelijk dat hoe langer we de periode nemen, hoe meer herinnering we hebben en hoe minder precisie we hebben, en omgekeerd. Gemiddeld leveren de “laatste 2 weken” betere resultaten op voor cliënten.

Vergelijkbaar met wat ik eerder kocht

Het is niet verrassend dat voor de levensmiddelendetailhandel “wat ik eerder kocht” goed werkt, maar alleen kandidaten extraheren uit wat de gebruiker al heeft gekocht is niet erg cool, omdat het onwaarschijnlijk is dat de koper wordt verrast met een nieuw product. Daarom stellen we voor om deze heuristiek enigszins te verbeteren met behulp van dezelfde samenwerkingsmodellen. Uit de vectoren die we tijdens ALS-training hebben ontvangen, kunnen we vergelijkbare producten verkrijgen als wat de gebruiker al heeft gekocht. Dit idee lijkt sterk op “soortgelijke video’s” in diensten voor het bekijken van video-inhoud, maar omdat we niet weten wat de gebruiker op een bepaald moment eet/koopt, kunnen we alleen zoeken naar soortgelijke video’s als wat hij al heeft gekocht, vooral omdat we al weten hoe goed het werkt. Als we deze methode toepassen op gebruikerstransacties gedurende de afgelopen twee weken, verkrijgen we de volgende statistieken:

Hier k — het aantal vergelijkbare producten dat wordt opgehaald voor elk product dat de koper de afgelopen 14 dagen heeft gekocht.
Deze aanpak werkte vooral goed voor onze klant, voor wie het van cruciaal belang was om niets aan te bevelen dat al in de aankoopgeschiedenis van de gebruiker stond.

Late aankoopperiode

Zoals we al hebben ontdekt, werkt de eerste benadering, vanwege de hoge frequentie waarmee we goederen kopen, goed voor onze specifieke behoeften. Maar hoe zit het met goederen als waspoeder/shampoo/etc. Dat wil zeggen, met producten die waarschijnlijk niet elke week of twee nodig zullen zijn en die met eerdere methoden niet kunnen worden geëxtraheerd. Dit leidt tot het volgende idee: er wordt voorgesteld om de aankoopperiode van elk product gemiddeld te berekenen voor klanten die het product vaker hebben gekocht k eenmaal. En haal er dan uit wat de koper waarschijnlijk al op heeft. De berekende termijnen voor goederen kunt u met uw ogen controleren op toereikendheid:

En dan kijken we of het einde van de productperiode binnen het tijdsinterval valt waarin de aanbevelingen in productie zullen zijn en kijken we wat er gebeurt. De aanpak kan als volgt worden geïllustreerd:

Hier hebben we 2 hoofdgevallen die kunnen worden overwogen:

1. Is het nodig om producten te bemonsteren van klanten die het product minder dan K keer hebben gekocht?
2. Is het nodig om een ​​product te bemonsteren als het einde van de periode vóór het begin van het doelinterval valt?

De volgende grafiek laat zien welke resultaten deze methode behaalt met verschillende hyperparameters:

ft — Neem alleen klanten die het product minstens K (hier K=5) keer hebben gekocht
tm — Neem alleen kandidaten aan die binnen het streefinterval vallen

Het is niet verwonderlijk dat hij daartoe in staat is (0, 0) de grootste herinneren en de kleinste nauwkeurigheid, aangezien onder deze voorwaarde de meeste kandidaten worden teruggehaald. De beste resultaten worden echter behaald als we geen producten samplen voor klanten die een bepaald product minder dan XNUMX% hebben gekocht k tijden en uittreksel, inclusief goederen waarvan het einde van de periode vóór het doelinterval valt.

Populair per categorie

Een ander redelijk voor de hand liggend idee is om populaire producten uit verschillende categorieën of merken te testen. Hier berekenen we voor elke koper top-k “favoriete” categorieën/merken en haal “populair” uit deze categorie/merk. In ons geval zullen we “favoriet” en “populair” bepalen aan de hand van het aantal aankopen van het product. Een bijkomend voordeel van deze aanpak is de toepasbaarheid ervan in het geval van een koude start. Dat wil zeggen voor klanten die óf heel weinig aankopen hebben gedaan, óf lange tijd niet in de winkel zijn geweest, óf net een klantenkaart hebben uitgegeven. Voor hen is het gemakkelijker en beter om artikelen op voorraad te hebben die populair zijn bij klanten en een geschiedenis hebben. De resulterende statistieken zijn:

Hier betekent het getal na het woord ‘categorie’ het nestniveau van de categorie.

Over het geheel genomen is het ook niet verrassend dat smallere categorieën betere resultaten opleveren, omdat ze nauwkeurigere ‘favoriete’ producten voor het winkelend publiek opleveren.

Alternatieve aankopen van verschillende goederen van week tot week

Een interessante benadering die ik niet heb gezien in artikelen over aanbevelingssystemen is een vrij eenvoudige en tegelijkertijd werkende statistische methode van Markov-ketens. Hier nemen we 2 verschillende weken, daarna bouwen we voor elke klant productparen [gekocht in week i]-[gekocht in week j], waarbij j > i, en vanaf hier berekenen we voor elk product de kans dat we volgende week overstappen naar een ander product. Dat wil zeggen, voor elk paar goederen producti-productj We tellen hun aantal in de gevonden paren en delen door het aantal paren, waar producten was in de eerste week. Om kandidaten eruit te halen, nemen we de laatste kassabon van de koper en halen we deze uit top-k de meest waarschijnlijke volgende producten uit de transitiematrix die we hebben ontvangen. Het proces voor het construeren van een transitiematrix ziet er als volgt uit:

Uit echte voorbeelden in de transitiekansmatrix zien we de volgende interessante verschijnselen:

Hier kun je interessante afhankelijkheden opmerken die aan het licht komen in het consumentengedrag: bijvoorbeeld liefhebbers van citrusvruchten of een merk melk waarvan ze waarschijnlijk naar een ander merk zullen overstappen. Het is ook niet verwonderlijk dat ook producten met een hoge herhalingsaankoop, zoals boter, hier terechtkomen.

De statistieken in de methode met Markov-ketens zijn als volgt:

k — het aantal producten dat per gekocht product wordt opgehaald uit de laatste transactie van de koper.
Zoals we kunnen zien, wordt het beste resultaat weergegeven door de configuratie met k=4. De piek in week 4 kan worden verklaard door seizoensgedrag rond de feestdagen. 

Soortgelijke producten voor kopers, volgens kenmerken gebouwd door verschillende modellen

Nu zijn we bij het moeilijkste en interessantste deel gekomen: het zoeken naar dichtstbijzijnde buren op basis van vectoren van klanten en producten die volgens verschillende modellen zijn gebouwd. In ons werk gebruiken we 3 van dergelijke modellen:

• ALS
• Word2Vec (Item2Vec voor dergelijke taken)
• DSSM

We hebben ALS al behandeld, je kunt lezen hoe het leert hier. In het geval van Word2Vec gebruiken we de bekende implementatie van het model uit gensim. Naar analogie met de teksten definiëren wij het aanbod als een aankoopbewijs. Bij het construeren van een productvector leert het model dus de “context” van het product op de kassabon (de resterende producten op de kassabon) te voorspellen. In e-commercegegevens is het beter om de koperssessie te gebruiken in plaats van een ontvangstbewijs; de jongens van Ozon. En DSSM is interessanter om te analyseren. Aanvankelijk werd het door de jongens van Microsoft geschreven als een model voor zoeken, Het originele onderzoekspaper kunt u hier lezen. De architectuur van het model ziet er als volgt uit:

Hier Q — zoekopdracht, zoekopdracht van gebruiker, D[ik] — document, internetpagina. De invoer voor het model zijn respectievelijk de attributen van het verzoek en de pagina's. Na elke invoerlaag bevinden zich een aantal volledig verbonden lagen (meerlaagse perceptron). Vervolgens leert het model de cosinus tussen de vectoren die in de laatste lagen van het model zijn verkregen, te minimaliseren.
Aanbevelingstaken gebruiken exact dezelfde architectuur, alleen in plaats van een verzoek is er een gebruiker, en in plaats van pagina's zijn er producten. En in ons geval wordt deze architectuur omgezet in het volgende:

Om nu de resultaten te controleren, moeten we nog het laatste punt behandelen: als we in het geval van ALS en DSSM expliciet gebruikersvectoren hebben gedefinieerd, dan hebben we in het geval van Word2Vec alleen productvectoren. Om de gebruikersvector te bouwen, hebben we hier drie hoofdbenaderingen gedefinieerd:

1. Voeg gewoon de vectoren toe en voor de cosinusafstand blijkt dat we eenvoudigweg het gemiddelde hebben genomen van de producten in de aankoopgeschiedenis.
2. Vectoroptelling met enige tijdweging.
3. Goederen wegen met TF-IDF-coëfficiënt.

Bij lineaire weging van de kopersvector gaan we uit van de hypothese dat het product dat de gebruiker gisteren kocht een grotere invloed heeft op zijn gedrag dan het product dat hij zes maanden geleden kocht. We beschouwen dus de vorige week van de koper met een notering van 1, en wat er daarna gebeurde met een notering van ½, ⅓, enz.:

Voor TF-IDF-coëfficiënten doen we precies hetzelfde als bij TF-IDF voor teksten, alleen beschouwen we de koper als een document en de cheque als een aanbieding, respectievelijk het woord is een product. Op deze manier zal de vector van de gebruiker meer verschuiven naar zeldzame goederen, terwijl frequente en bekende goederen voor de koper daar niet veel aan zullen veranderen. De aanpak kan als volgt worden geïllustreerd:

Laten we nu naar de statistieken kijken. Zo zien de ALS-resultaten eruit:

Statistieken voor Item2Vec met verschillende varianten van het construeren van de kopersvector:

In dit geval wordt exact hetzelfde model gebruikt als in onze basislijn. Het enige verschil is welke k we zullen gebruiken. Om alleen samenwerkingsmodellen te gebruiken, moet u voor elke klant ongeveer 50-70 producten nemen die het dichtst in de buurt komen.

En statistieken volgens DSSM:

Hoe combineer je alle methoden?

Cool, zeg je, maar wat moet je met zo’n groot aantal kandidatenextractietools? Hoe kiest u de optimale configuratie voor uw gegevens? Hier hebben we verschillende problemen:

1. Het is noodzakelijk om op de een of andere manier de zoekruimte voor hyperparameters in elke methode te beperken. Het is natuurlijk overal discreet, maar het aantal mogelijke punten is erg groot.
2. Hoe kunt u met behulp van een kleine, beperkte steekproef van specifieke methoden met specifieke hyperparameters de beste configuratie voor uw statistiek selecteren?

We hebben nog geen definitief correct antwoord op de eerste vraag gevonden, dus gaan we uit van het volgende: voor elke methode wordt een hyperparameter-zoekruimtebegrenzer geschreven, afhankelijk van enkele statistieken over de gegevens die we hebben. Als we dus de gemiddelde periode tussen aankopen van mensen kennen, kunnen we raden met welke periode we de methode 'wat al is gekocht' en 'periode van een aankoop die al lang geleden is gedaan' moeten gebruiken.

En nadat we een bepaald adequaat aantal variaties van verschillende methoden hebben doorlopen, merken we het volgende op: elke implementatie haalt een bepaald aantal kandidaten eruit en heeft een bepaalde waarde van de belangrijkste metriek voor ons (herinnering). We willen in totaal een bepaald aantal kandidaten krijgen, afhankelijk van onze toegestane rekenkracht, met de hoogst mogelijke maatstaf. Hier valt het probleem prachtig uiteen in het rugzakprobleem.

Hier is het aantal kandidaten het gewicht van de baar en de terugroepmethode de waarde ervan. Er zijn echter nog 2 punten waarmee rekening moet worden gehouden bij de implementatie van het algoritme:

• Methoden kunnen overlap hebben in de kandidaten die ze ophalen.
• In sommige gevallen zal het correct zijn om één methode twee keer te gebruiken met verschillende parameters, en zal de kandidaat-uitvoer van de eerste geen subset zijn van de tweede.

Als we bijvoorbeeld de implementatie van de ‘wat ik al heb gekocht’-methode nemen met verschillende ophaalintervallen, dan zullen hun sets kandidaten in elkaar worden genest. Tegelijkertijd zorgen verschillende parameters bij "periodieke aankopen" bij de uitgang niet voor een volledige kruising. Daarom verdelen we de bemonsteringsbenaderingen met verschillende parameters in blokken, zodat we uit elk blok maximaal één extractiebenadering met specifieke hyperparameters willen nemen. Om dit te doen, moet je een beetje slim worden in het implementeren van het knapzakprobleem, maar de asymptotiek en het resultaat zullen niet veranderen.

Deze slimme combinatie stelt ons in staat de volgende statistieken te verkrijgen in vergelijking met eenvoudige samenwerkingsmodellen:

In de uiteindelijke statistieken zien we het volgende beeld:

Hier kunt u echter merken dat er één onbedekt punt is voor aanbevelingen die nuttig zijn voor het bedrijfsleven. Nu hebben we zojuist geleerd hoe we uitstekend kunnen voorspellen wat de gebruiker bijvoorbeeld volgende week zal kopen. Maar simpelweg korting geven op iets dat hij al gaat kopen, is niet erg cool. Maar het is cool om de verwachtingen van bijvoorbeeld de volgende statistieken te maximaliseren:

1. Marge/omzet op basis van persoonlijke aanbevelingen.
2. Gemiddelde klantencheque.
3. Frequentie van bezoeken.

Dus vermenigvuldigen we de verkregen kansen met verschillende coëfficiënten en herschikken ze zodat de producten die van invloed zijn op de bovenstaande statistieken bovenaan komen te staan. Er bestaat geen kant-en-klare oplossing voor welke aanpak het beste kan worden toegepast. We experimenteren zelfs rechtstreeks met dergelijke coëfficiënten tijdens de productie. Maar hier zijn interessante technieken die ons meestal de beste resultaten opleveren:

1. Vermenigvuldig met de prijs/marge van het product.
2. Vermenigvuldig met de gemiddelde kassabon waarop het product voorkomt. Er komen dus goederen naar boven, waarmee ze meestal iets anders meenemen.
3. Vermenigvuldig dit met de gemiddelde bezoekfrequentie van kopers van dit product, op basis van de hypothese dat dit product mensen ertoe aanzet er vaker voor terug te komen.

Na experimenten met coëfficiënten te hebben uitgevoerd, hebben we tijdens de productie de volgende statistieken verkregen:

Hier algehele productconversie — het aandeel gekochte producten van alle producten in de aanbevelingen die we hebben gegenereerd.

Een oplettende lezer zal een aanzienlijk verschil opmerken tussen offline en online statistieken. Dit gedrag wordt verklaard door het feit dat bij het trainen van het model niet met alle dynamische filters voor producten die kunnen worden aanbevolen, rekening kan worden gehouden. Voor ons is het een normaal verhaal als de helft van de gevonden kandidaten er uit kan worden gefilterd; een dergelijke specificiteit is typisch voor onze branche.

Qua omzet komt het volgende verhaal naar voren, het is duidelijk dat na de lancering van de aanbevelingen de omzet van de testgroep sterk groeit, nu is de gemiddelde omzetstijging met onze aanbevelingen 3-4%:

Concluderend wil ik zeggen dat als je niet-realtime aanbevelingen nodig hebt, er een zeer grote kwaliteitsverbetering te vinden is in experimenten met het extraheren van kandidaten voor aanbevelingen. Een grote hoeveelheid tijd voor het genereren ervan maakt het mogelijk om veel goede methoden te combineren, wat in totaal geweldige resultaten voor het bedrijf zal opleveren.

Ik zal graag in de reacties chatten met iedereen die het materiaal interessant vindt. Vragen kunt u mij persoonlijk stellen via telegram. Ook deel ik mijn gedachten over AI/startups in mijn telegram kanaal - welkom :)

Bron: www.habr.com