Hei alle sammen! Mitt navn er Sasha, jeg er CTO og medgründer hos LoyaltyLab. For to år siden dro jeg og vennene mine, som alle fattige studenter, på kvelden for øl til nærmeste butikk i nærheten av huset. Vi var veldig opprørt over at forhandleren, vel vitende om at vi ville komme for øl, ikke ga rabatt på chips eller kjeks, selv om dette er så logisk! Vi forsto ikke hvorfor denne situasjonen oppstår og bestemte oss for å opprette vårt eget selskap. Vel, som en bonus, skriv ut rabatter til deg selv hver fredag for de samme sjetongene.
Og alt kom til det punktet at jeg snakker med materiale om den tekniske siden av produktet på . Vi deler gjerne arbeidet vårt med fellesskapet, så jeg legger ut rapporten min i form av en artikkel.
Innledning
Som alle andre på begynnelsen av reisen startet vi med en oversikt over hvordan anbefalingssystemer lages. Og arkitekturen av følgende type viste seg å være den mest populære:
Den består av to deler:
- Sampling av kandidater for anbefalinger ved hjelp av en enkel og rask modell, vanligvis samarbeidende.
- Rangering av kandidater etter en mer kompleks og langsommere innholdsmodell, tar hensyn til alle mulige funksjoner i dataene.
Her og nedenfor vil jeg bruke følgende begreper:
- kandidat / kandidat for anbefalinger - et par bruker-produkt, som potensielt kan komme inn i anbefalinger i produksjon.
- kandidater utvinning/ekstraktor/kandidat utvinning metode – en prosess eller metode for å trekke ut «kandidater for anbefalinger» fra tilgjengelige data.
I det første trinnet brukes vanligvis forskjellige varianter av samarbeidsfiltrering. Den mest populære - . Overraskende nok avslører de fleste artiklene om anbefalingssystemer bare ulike forbedringer av samarbeidsmodeller i det første trinnet, men ingen snakker om andre prøvetakingsmetoder. For oss fungerte ikke tilnærmingen med å bruke bare samarbeidsmodeller og ulike optimaliseringer med dem med den kvaliteten vi forventet, så vi gravde i forskningen spesifikt på denne delen. Og på slutten av artikkelen vil jeg vise hvor mye vi klarte å forbedre ALS, som var vår grunnlinje.
Før jeg går videre til å beskrive vår tilnærming, er det viktig å merke seg at med sanntidsanbefalinger, når det er viktig for oss å vurdere data som skjedde for 30 minutter siden, er det virkelig ikke mange tilnærminger som kan fungere til rett tid. Men i vårt tilfelle må vi samle anbefalinger ikke mer enn en gang om dagen, og i de fleste tilfeller - en gang i uken, noe som gir oss muligheten til å bruke komplekse modeller og multiplisere kvaliteten.
La oss ta utgangspunkt i hvilke beregninger bare ALS viser på oppgaven med å trekke ut kandidater. De viktigste beregningene vi overvåker er:
- Presisjon - andelen riktig utvalgte kandidater fra de utvalgte.
- Tilbakekalling - andelen kandidater som skjedde av de som faktisk var i målintervallet.
- F1-score - F-score beregnet på de to foregående poengene.
Vi vil også se på beregningene til den endelige modellen etter treningsgradientforsterkning med ekstra innholdsfunksjoner. Det er også 3 hovedmål:
- presisjon@5 — gjennomsnittlig prosentandel av treff fra topp 5 etter sannsynlighet for hver kunde.
- response-rate@5 — konvertering av kjøpere fra et besøk i butikken til kjøp av minst ett personlig tilbud (ett tilbud inneholder 5 produkter).
- avg roc-auc per bruker - medium for hver kjøper.
Det er viktig å merke seg at alle disse beregningene er målt på , det vil si at trening foregår de første k ukene, og k + 1 uker tas som testdata. Sesongmessige opp-/nedturer hadde således minimal effekt på tolkningen av kvaliteten på modellene. Videre, på alle diagrammer, vil abscisseaksen indikere ukenummeret i kryssvalidering, og ordinataksen vil indikere verdien av den angitte metrikken. Alle grafer er basert på transaksjonsdata fra én klient, slik at sammenligningen mellom dem er korrekt.
Før vi begynner å beskrive vår tilnærming, la oss først ta en titt på grunnlinjen, som er den ALS-trente modellen.
Beregninger for kandidatutvinning:
Endelige beregninger:
Jeg behandler alle implementeringer av algoritmer som en slags forretningshypotese. Så grovt sett kan alle samarbeidsmodeller betraktes som en hypotese om at "folk har en tendens til å kjøpe det folk liker å kjøpe". Som jeg sa, begrenset vi oss ikke til slik semantikk, og her er noen hypoteser som fortsatt fungerer kult på data i offline detaljhandel:
- Hva har du kjøpt før.
- I likhet med det jeg kjøpte før.
- Perioden for et lenge tidligere kjøp.
- Populær etter kategori/merke.
- Vekselkjøp av forskjellige varer fra uke til uke (Markov-kjeder).
- Lignende produkter til kjøpere, i henhold til egenskapene bygget av forskjellige modeller (Word2Vec, DSSM, etc.).
Hva kjøpte du før
Den mest åpenbare heuristikken som fungerer veldig bra i dagligvarehandelen. Her tar vi alle varene som lojalitetskortinnehaveren kjøpte de siste K-dagene (vanligvis 1-3 uker), eller K-dagene for et år siden. Ved å bruke bare denne metoden får vi følgende beregninger:
Det er ganske åpenbart her at jo mer vi tar perioden, jo mer gjenkalling og mindre presisjon har vi og omvendt. Bedre resultater i gjennomsnitt for klienter gir de "siste 2 ukene".
I likhet med det jeg kjøpte før
Ikke overraskende fungerer "hva har kjøpt før" bra for dagligvarehandel, men å trekke ut kandidater kun fra det brukeren allerede har kjøpt er ikke veldig kult, fordi det er usannsynlig at det vil være mulig å overraske kjøperen med et nytt produkt. Derfor foreslår vi å forbedre denne heuristikken litt ved å bruke de samme samarbeidsmodellene. Fra vektorene som vi mottok under ALS-opplæringen, kan du få lignende produkter som brukeren allerede har kjøpt. Denne ideen er veldig lik "lignende videoer" i videoinnholdsvisningstjenester, men siden vi ikke vet hva brukeren spiser/kjøper i et bestemt øyeblikk, kan vi bare se etter noe som ligner på det han allerede har kjøpt, spesielt siden vi allerede vet hvor godt det fungerer. Ved å bruke denne metoden på brukertransaksjoner i løpet av de siste 2 ukene får vi følgende beregninger:
Her k - antall lignende produkter som er hentet for hvert produkt kjøpt av kjøper i løpet av de siste 14 dagene.
Denne tilnærmingen fungerte spesielt bra for oss på en klient som var kritisk til ikke å anbefale i det hele tatt det som allerede var i brukerens kjøpshistorikk.
Lenge forbi kjøpsperiode
Som vi allerede har funnet ut, på grunn av den høye frekvensen av å kjøpe varer, fungerer den første tilnærmingen bra for våre spesifikke detaljer. Men hva med varer som vaskepulver/sjampo/osv. Det vil si med produkter som neppe er behov for hver eller annen uke og som tidligere metoder ikke kan trekke ut. Dette innebærer følgende idé - det foreslås å beregne kjøpsperioden for hvert produkt i gjennomsnitt for kjøpere som kjøpte produktet mer k en gang. Og så trekke ut det som mest sannsynlig kjøperen allerede har gått tom for. De beregnede periodene for varer kan kontrolleres med øynene for tilstrekkelighet:
Og så får vi se om slutten av produktperioden faller innenfor tidsintervallet når anbefalingene skal i produksjon og prøve hva som faller. Tilnærmingen kan illustreres slik:
Her har vi 2 hovedsaker som kan vurderes:
- Om du skal prøve produkter for kunder som har kjøpt produktet mindre enn K ganger.
- Om produktet skal prøves hvis slutten av perioden faller før starten av målintervallet.
Følgende graf viser hvilke resultater en slik metode oppnår med forskjellige hyperparametre:
ft - Ta kun kjøpere som har kjøpt produktet minst K (her K = 5) ganger
tm — Ta kun kandidater som faller inn i målintervallet
Ikke overraskende, i stand (0, 0) den største husker og den minste presisjon, siden under denne betingelsen trekkes flest kandidater ut. De beste resultatene oppnås imidlertid når vi ikke prøver produkter for kunder som har kjøpt et bestemt produkt mindre enn k ganger og trekke ut blant annet varer hvis periodeslutt faller før målintervallet.
Populær etter kategori
En annen ganske åpenbar idé er å prøve populære produkter på tvers av forskjellige kategorier eller merker. Her beregner vi for hver kunde topp-k "favoritt" kategorier/merker og trekke ut "populær" fra den kategorien/merket. I vårt tilfelle definerer vi "favoritt" og "populær" ved antall produktkjøp. En ytterligere fordel med denne tilnærmingen er dens anvendelighet i et kaldstarttilfelle. Det vil si for kunder som enten har gjort svært få kjøp, eller ikke har vært i butikken på lenge, eller generelt kun har utstedt et lojalitetskort. For dem er det enklere og best å kaste inn varer fra populære blant kjøpere med en eksisterende historie. Beregningene er som følger:
Her betyr tallet etter ordet "kategori" hekkenivået til kategorien.
Generelt er det heller ikke overraskende at smalere kategorier oppnår bedre resultater, ettersom de trekker ut mer nøyaktige "favoritt"-produkter for kjøpere.
Vekselkjøp av forskjellige varer fra uke til uke
En interessant tilnærming som jeg ikke har sett i artikler om anbefalingssystemer er en ganske enkel og samtidig fungerende statistisk metode for Markov-kjeder. Her tar vi 2 forskjellige uker, så bygger vi for hver kunde par med produkter [kjøpt i uke i]-[kjøpt i uke j], hvor j > i, og herfra beregner vi for hvert produkt sannsynligheten for å bytte til et annet produkt neste uke. Det vil si for hvert par varer produkti-produktj tell deres antall i de funnet parene og del på antall par, hvor produkti var den første uken. For å trekke ut kandidater tar vi siste sjekk av kjøper og får topp-k de mest sannsynlige neste produktene fra overgangsmatrisen vi fikk. Prosessen med å bygge en overgangsmatrise ser slik ut:
Fra virkelige eksempler i matrisen av overgangssannsynligheter ser vi følgende interessante fenomener:
Her kan du legge merke til interessante avhengigheter som avsløres i forbrukeratferd: for eksempel sitruselskere eller et merke melk, som de mest sannsynlig bytter til en annen. Det er heller ikke overraskende at varer med høye gjentatte kjøp, som smør, også havner her.
Beregningene i metoden med Markov-kjeder er som følger:
k - antall produkter som er hentet for hver vare kjøpt fra kjøperens siste transaksjon.
Som vi kan se, viser konfigurasjonen med k=4 det beste resultatet. Piggen i uke 4 kan forklares med sesongmessig atferd rundt helligdager.
Lignende produkter til kjøpere, i henhold til egenskaper bygget av forskjellige modeller
Så vi kommer til den vanskeligste og mest interessante delen - søket etter de nærmeste naboene i vektorene til kjøpere og produkter bygget i henhold til forskjellige modeller. I vårt arbeid bruker vi 3 slike modeller:
- ALS
- Word2Vec (Item2Vec for slike oppgaver)
- DSSM
Vi har allerede behandlet ALS, du kan lese om hvordan den lærer . Når det gjelder Word2Vec bruker vi den velkjente implementeringen av modellen fra gensim. I analogi med tekstene definerer vi tilbudet som en kjøpskvittering. Når man konstruerer produktvektoren, lærer modellen å forutsi sin "kontekst" for produktet i kvitteringen (resten av varene i kvitteringen). I e-handelsdata er det bedre å bruke kjøperens sesjon i stedet for en kvittering, gutta fra . Og DSSM er mer interessant å demontere. Det ble opprinnelig skrevet av gutta fra Microsoft som en søkemodell, . Arkitekturen til modellen ser slik ut:
Her Q - forespørsel, brukerens søk, D[i] - dokument, nettside. Inngangen til modellen mottar henholdsvis tegnene til forespørselen og sidene. Hvert inngangslag etterfølges av et antall fullt tilkoblede lag (flerlagsperceptron). Deretter lærer modellen å minimere cosinus mellom vektorene oppnådd i de siste lagene av modellen.
Anbefalingsoppgavene bruker nøyaktig samme arkitektur, men i stedet for en forespørsel er det en bruker, og i stedet for sider er det produkter. Og i vårt tilfelle blir denne arkitekturen forvandlet til følgende:
Nå, for å sjekke resultatene, gjenstår det å dekke det siste punktet - hvis vi i tilfelle av ALS og DSSM har eksplisitt definert brukervektorer, så har vi i tilfelle av Word2Vec bare produktvektorer. Her, for å bygge en brukervektor, har vi identifisert 3 hovedtilnærminger:
- Bare legg til vektorene, så viser det seg for cosinusavstanden at vi nettopp satte gjennomsnittet av produktene i handlehistorien.
- Summering av vektorer med noe tidsvekting.
- Veiing av varer med TF-IDF koeffisient.
Ved lineær vekting av kjøpervektoren går vi ut fra hypotesen om at produktet som brukeren kjøpte i går har større innflytelse på hans atferd enn produktet han kjøpte for seks måneder siden. Så vi vurderer den forrige uken til kjøperen med en koeffisient på 1, og hva som skjedde videre med koeffisientene på ½, ⅓ osv.:
For TF-IDF koeffisienter gjør vi akkurat det samme som i TF-IDF for tekster, bare vi anser kjøperen som et dokument, henholdsvis kvitteringen som et tilbud, ordet er et produkt. Så brukervektoren vil skifte mer mot sjeldne varer, og varer som er hyppige og kjente for kjøperen vil ikke endre det mye. Tilnærmingen kan illustreres slik:
La oss nå se på beregningene. Slik ser ALS-resultater ut:
Beregninger av Item2Vec med forskjellige varianter av konstruksjon av kjøpervektoren:
I dette tilfellet brukes nøyaktig samme modell som i vår baseline. Den eneste forskjellen er hvilken k vi skal bruke. For å kun bruke samarbeidsmodeller, må du ta ca 50-70 nærmeste produkter for hver kunde.
Og DSSM-beregninger:
Hvordan kombinere alle metoder?
Kult, sier du, men hva skal man gjøre med et så stort sett med kandidatekstraksjonsverktøy? Hvordan velge den optimale konfigurasjonen for dataene dine? Her har vi flere problemer:
- Det er nødvendig å på en eller annen måte begrense søkerommet for hyperparametere i hver metode. Det er selvfølgelig diskret overalt, men antall mulige poeng er veldig stort.
- Hvordan velge den beste konfigurasjonen for beregningen din ved å bruke et lite begrenset utvalg av spesifikke metoder med spesifikke hyperparametre?
Vi har ennå ikke funnet et utvetydig riktig svar på det første spørsmålet, så vi går ut fra følgende: for hver metode skrives en hyperparametersøkeplassbegrenser, avhengig av litt statistikk om dataene vi har. Når vi kjenner den gjennomsnittlige perioden mellom kjøp fra folk, kan vi gjette med hvilken periode vi skal bruke metoden "hva som allerede er kjøpt" og "perioden for et lenge tidligere kjøp".
Og etter at vi har gått gjennom et tilstrekkelig antall variasjoner av forskjellige metoder, legger vi merke til følgende: hver implementering trekker ut et visst antall kandidater og har en viss verdi av metrikken (gjenkalling) som er nøkkelen for oss. Vi ønsker å få et visst antall kandidater totalt, avhengig av vår tillatte datakraft, med høyest mulig metrikk. Her faller problemet fint sammen i ryggsekkproblematikken.
Her er antallet kandidater vekten av barren, og metodegjenkallingen er verdien. Det er imidlertid ytterligere to punkter som bør tas i betraktning når du implementerer algoritmen:
- Metoder kan ha overlapping i kandidatene de trekker ut.
- I noen tilfeller vil det være riktig å ta en metode to ganger med forskjellige parametere, og kandidatene ved utgangen av den første vil ikke være en delmengde av den andre.
For eksempel, hvis vi tar implementeringen av "det som allerede er kjøpt"-metoden med forskjellige intervaller for utvinning, vil deres sett med kandidater bli nestet inn i hverandre. Samtidig gir ikke forskjellige parametere i de "periodiske kjøp" ved avkjørselen et fullstendig kryss. Derfor deler vi prøvetakingsmetoder med ulike parametere inn i blokker slik at vi fra hver blokk ønsker å ta maksimalt én ekstraksjonstilnærming med spesifikke hyperparametre. For å gjøre dette må du lure litt i implementeringen av ryggsekkproblemet, men asymptotikken og resultatet vil ikke endre seg fra dette.
En slik smart kombinasjon lar oss få følgende beregninger sammenlignet med ganske enkelt samarbeidsmodeller:
På de endelige beregningene ser vi følgende bilde:
Men her kan du se at det er ett avdekket punkt for anbefalinger som er nyttige for virksomheten. Nå har vi nettopp lært hvordan vi kult kan forutsi hva brukeren vil kjøpe, for eksempel neste uke. Men bare det å gi rabatt på at han uansett vil kjøpe er ikke så veldig kult. Men det er kult å maksimere forventningene, for eksempel til følgende beregninger:
- Margin/omsetning basert på personlige anbefalinger.
- Gjennomsnittlig sjekk av kjøpere.
- besøksfrekvens.
Så vi multipliserer de oppnådde sannsynlighetene med forskjellige koeffisienter og rangerer dem på nytt slik at toppen inkluderer produkter som påvirker beregningene ovenfor. Det er ingen ferdig løsning her, hvilken tilnærming er bedre å bruke. Selv eksperimenterer vi med slike koeffisienter direkte i produksjonen. Men her er noen interessante triks som oftest gir oss de beste resultatene:
- Multipliser med prisen/marginen til varen.
- Multipliser med gjennomsnittssjekken der produktet forekommer. Så varene vil komme ut som de vanligvis tar noe annet med.
- Multipliser med den gjennomsnittlige besøksfrekvensen av kjøpere av dette produktet, basert på hypotesen om at dette produktet provoserer hyppigere returer for det.
Etter å ha eksperimentert med koeffisienter, fikk vi følgende beregninger i produksjon:
Her total produktkonvertering - andelen kjøpte produkter fra alle produktene i anbefalingene som vi genererte.
En oppmerksom leser vil merke en betydelig forskjell mellom offline og online beregninger. Denne oppførselen forklares med at ikke alle dynamiske filtre for produkter som kan anbefales kan tas i betraktning ved opplæring av modellen. Det er en normal historie for oss når halvparten av de ekstraherte kandidatene kan filtreres ut, slik spesifisitet er typisk i vår bransje.
Når det gjelder inntekter, er følgende historie innhentet, det er klart at etter lanseringen av anbefalingene vokser omsetningen til testgruppen sterkt, nå er den gjennomsnittlige økningen i inntekt med våre anbefalinger 3-4%:
Avslutningsvis vil jeg si at dersom du trenger anbefalinger uten sanntid, så finner man en veldig stor kvalitetsøkning i forsøk med å trekke ut kandidater til anbefalinger. Stor mengde tid på å generere dem gjør det mulig å kombinere mange gode metoder, som totalt sett vil gi kule resultater for virksomheten.
Jeg vil gjerne chatte i kommentarfeltet med alle som synes materialet er interessant. Du kan stille meg spørsmål personlig . Jeg deler også mine tanker om AI/startups i min – velkommen 🙂
Kilde: www.habr.com