Tere kõigile! Minu nimi on Sasha, olen CTO ja kaasasutaja ettevõttes LoyaltyLab. Kaks aastat tagasi, nagu kõik vaesed tudengid, käisin õhtuti koos sõpradega lähimas kaupluses õlut ostmas. Meid häiris väga, et jaemüüja, teades, et me tuleme õlle järele, ei paku chipside või kreekerite allahindlust, kuigi see oleks ju nii loogiline! Me ei saanud aru, miks see nii on, ja otsustasime asutada oma ettevõtte. Ja boonusena kirjutada endale reedeti allahindlusi just nendele samadele chipsidele.

Asi on jõudnud sinnamaani, et olen tehnilise osa materjaliga esinemas NVIDIA GTC. Meil on hea meel jagada oma teadmisi kogukonnaga, seega avaldan oma ettekande artikli vormis.

Sissejuhatus

Nagu kõik alguses, alustasime ülevaatest, kuidas soovitussüsteemid on tehtud. Ja kõige populaarsem osutus järgmise tüübi arhitektuur:

See koosneb kahest osast:

1. Soovituste kandidaatide proovivõtt lihtsa ja kiire mudeliga, tavaliselt koostöömudeli põhjal.
2. Kandidaatide järjestamine keerukama ja aeglasema sisumudeliga, arvestades kõiki võimalikke tunnuseid andmetes.

Siin ja edaspidi kasutan järgmisi termineid:

• candidate/kandidaat soovituste jaoks — user-product paar, mis võib potentsiaalselt saada soovituseks tootes.
• candidates extraction/extractor/kandidaatide väljavõtmise meetod — protsess või meetod, mis väljavõtab "soovituste kandidaate" olemasolevate andmete põhjal.

Esimesel sammul kasutatakse tavaliselt erinevaid koostööl põhineva filtreerimise variatsioone. Kõige populaarsem on ALS. Üllatav, et enamik artikleid soovitussüsteemide kohta paljastab ainult erinevaid koostöö mudelite täiustusi esimeses etapis, kuid teistest proovimise meetoditest ei räägita eriti. Meie jaoks ei töötanud ainult koostöömudelite kasutamine ning erinevad optimeerimised nendega oodatud kvaliteedi saavutamiseks, seega sukeldusime just selle osa uuringutesse. Artikli lõpus näitan, kui palju suutsime ALS-i, mis oli meie baasjooneks, parendada.

Enne kui ma räägin meie lähenemisest, on oluline märkida, et reaalajas soovituste puhul, kus on oluline arvestada andmeid, mis on toimunud 30 minuti jooksul, ei ole tõeliselt palju lähenemisi, mis töötaksid vajaliku aja jooksul. Kuid meie puhul tuleb soovitusi koostada mitte sagedamini kui kord päevas ja enamikul juhtudel kord nädalas, mis annab meile võimaluse kasutada keerukaid mudeleid ja oluliselt parandada kvaliteeti.

Võtame aluseks, milliseid näitajaid näitab ainult ALS kandidaatide hankimise ülesandel. Olulised näitajad, mida jälgime, on järgmised:

• Precision — õigesti valitud kandidaatide osakaal valimist.
• Recall — toimunud kandidaatide osakaal nendest, kes olid tegelikult sihtrühmas.
• F1-score — F-mõõde, mis arvutatakse eelmiste kahe punkti põhjal.

Samuti vaatame lõppmudeli näitajaid pärast gradientide tõukeõppe koolitust koos täiendavate sisuliste tunnustega. Siin on samuti kolm peamist näitajat:

• precision@5 — keskmine tõenäosustipud tooteid top-5 hulgas iga ostja jaoks.
• response-rate@5 — ostjate konversioon kaupluse külastusest vähemalt ühe isikliku pakkumise ostmisele (ühes pakkumises on 5 toodet).
• avg roc-auc per user — keskmine roc-auc iga ostja kohta.

Oluline on märkida, et kõik nimetatud näitajad mõõdetakse ajareiheline ristvalideerimine, see tähendab, et koolitus toimub esimesel k nädalal ja testandmed võetakse k+1 nädal. Seega kajastavad hooajalised tõusud/kadumised minimaalselt mudelite kvaliteedi tõlgendust. Edasi on kõikidel graafikutel horisontaaltelg nädala number ristvalideerimisel ja vertikaaltelg — nimetatud näitaja väärtus. Kõik graafikud on koostatud ühe kliendi tehinguandmete põhjal, et võrguandmete võrdlemine oleks korrektne.

Enne kui alustan meie lähenemise kirjeldamist, vaatame esmalt aluseks olevat mudelit, mis koosneb koolitatud ALS mudelist.
Kandidaatide hankimise näitajad:

Lõplikud näitajad:

Ma suhtun kõikidesse algoritmide rakendustesse kui teatud ärihypoteesi. Nii et väga üldiselt võib iga koostöömudelit vaadelda hüpoteesina, et "inimesed kalduvad ostma seda, mida ostavad neile sarnased inimesed". Nagu ma juba ütlesin, ei piirdunud me vaid sellise semantikaga ja siin on mõned teised hüpoteesid, mis töötavad andmete põhjal offline jaemüügis:

1. Mida on varem ostetud.
2. Sarnane sellele, mida on varem ostetud.
3. Ajast, mil ost tehti.
4. Populaarne kategooriate/brändide kaupa.
5. Eri kaupade korduvad ostud nädalast nädalasse (Markovi ahelad).
6. Sarnased tooted ostjate, omaduste põhjal, mis on koostatud erinevate mudelite (Word2Vec, DSSM jne) abil.

Mida on varem ostetud

Ilmselt kõige mänguheuristika, mis töötab väga hästi toidupoe jaemüügis. Siin võtame kõik tooted, mida lojaalsuskaardi omanik on ostnud viimase K päeva jooksul (tavaliselt 1-3 nädalat), või K päeva jooksul aasta tagasi. Rakendades vaid sellist meetodit, saame järgmised mõõdikud:

Siin on täiesti ilmne, et mida pikema perioodi me võtame, seda suurem on meie tagasiside ja väiksem täpsus ja vastupidi. Parimad tulemused keskmiselt klientide puhul annavad "viimased 2 nädalat".

Sarnane sellele, mida on varem ostetud

Ei ole üllatav, et toidupoe jaemüügis töötab "mida on varem ostetud" hästi, kuid kandidaatide väljavõtmine vaid sellest, mida kasutaja on juba ostnud, ei ole eriti lahe, kuna uue tootega kliendi üllatamine on peaaegu võimatu. Seetõttu pakume, et täiustame seda heuristikat koostöömudelite abil. ALS-i treeningu käigus saadud vektorite põhjal saame välja tõmmata sarnased tooted sellele, mida kasutaja on juba ostnud. See idee sarnaneb väga "sarnaste videote" teenustega videokontentide vaatamise platvormidel, kuid kuna me ei tea, mida kasutaja sel hetkel sööb/ostab, peame otsima sarnaseid tooteid vaid sellele, mida ta juba ostnud on, eriti kuna me juba teame, kui hästi see töötab. Rakendades sellist meetodit kasutajate tehingutele viimase 2 nädala jooksul, saame järgmised mõõdikud:

Siin k — sarnaste kaupade arv, mis tuvastatakse iga ostetud toote kohta ostja poolt viimase 14 päeva jooksul.
See lähenemine on meil eriti hästi töötanud kliendile, kelle jaoks oli äärmiselt oluline mitte soovitada seda, mis oli juba kasutaja ostuajaloos.

Möödunud ostu aeg

Nagu me juba oleme kindlaks teinud, selle tõttu, et tooteid ostetakse väga sageli, töötab esimene lähenemine meie spetsiifikas hästi. Aga kuidas olla toodetega nagu pesupulber/šampoon/jne? Kõige enam selliste toodetega, mida ei vajata iganädalaselt või igakuiste vahedega ja mida varasemad meetodid ei suuda tuvastada. Siit tuleneb järgmine idee — soovitatakse arvutada iga toote keskmine ostuperiood klientide seas, kes on toodet ostnud rohkem kui k kord. Edasi tuleb tuvastada, mis tõenäoliselt on kliendi puhul juba otsa lõppenud. Arvutatud perioode saab visuaalselt kontrollida mõistlikkuse osas:

Edasi vaatame, kas toote perioodi lõpp langeb kokku ajavahemikuga, mil soovitused on tootmises, ja valime need, mis sobivad. Seda lähenemist saab illustreerida järgmiselt:

Siin on meil kaks peamist juhtumit, mida kaaluda:

1. Kas on vaja soovitada tooteid klientidele, kes on toodet ostnud vähem kui K korda.
2. Kas on vaja soovitada toodet, kui selle perioodi lõpp langeb enne sihtvahemiku algust.

Järgneval graafikul on näha, milliseid tulemusi saavutab selline meetod erinevate hüperparameetritega:

ft — Võtame arvesse ainult kliente, kes on toodet ostnud vähemalt K (siin K=5) korda
tm — Võtame arvesse ainult kandidaate, kes langevad sihtvahemikku

Pole üllatav, et sellises seisundis (0, 0) on kõige suurem recall ja kõige väiksem precision, kuna selliste tingimuste korral tõstetakse kõige rohkem kandidaate. Siiski, parimaid tulemusi saavutatakse olukorras, kus me ei soovita tooteid klientidele, kes on konkreetset toodet ostnud vähem kui k korda ja lisame ka tooteid, mille perioodi lõpp langeb enne sihtvahemikku.

Populaarne kategooria järgi

Veel üks üsna ilmselge idee — soovitada populaarseid tooteid erinevate kategooriate või brändide kaupa. Siin arvutame iga kliendi jaoks top-k Meie "lemmik" kategooriad/märgid ning eraldame "populaarse" selle kategooria/märgi alt. Meie puhul määrame "lemmikud" ja "populaarsed" toodete ostude arvu alusel. Selle lähenemise täiendav eelis on, et see kehtib külma käivitamise puhul. See tähendab, et ostjate jaoks, kes on teinud kas väga väheseid oste, või pole pikka aega poes käinud, või on nad alles loonud lojaalsuskaardi. Nende jaoks on palju lihtsam ja parem soovitada tooteid, mis on populaarne ostjate seas, kellel on olemasolev ajalugu. Saame järgmised mõõdikud:

Siin sõna "category" järel olev number näitab kategooria sügavust.

Üldiselt ei ole üllatav, et paremaid tulemusi saavutavad kitsamad kategooriad, kuna need toovad ostjatele välja täpsemad "lemmik" tooted.

Erinevate toodete korduvad ostud nädalast nädalasse

Huvitav lähenemine, mida ma pole näinud soovitus süsteemide artiklites — üsna lihtne, kuid samas töötav statistiline meetod Markovi ahelatelt. Siin võtame 2 erinevat nädalat, seejärel tuletame iga ostja kohta tootepaarid. [ostetud nädalal i]-[ostetud nädalal j], kus j > i, ja sealt arvutame iga toote tõenäosuse üleminekuks teisele tootele järgmisel nädalal. See tähendab, et iga paari kaupade puhul producti-productj arvutame nende arvu leitud paarides ja jagame selle paaride arvuga, kus producti oli esimesel nädalal. Kandidaatide väljatõmbamiseks võtame viimase ostu ja leiame top-k kõige tõenäolisemad järgmised tooted üleminekude matriist, mille me saime. Üleminekute matriisi koostamise protsess näeb välja järgmiselt:

Reaalsetest näidetest üleminekute tõenäosuste matriisis näeme järgmisi huvitavaid nähtusi:

Siit võib märkida huvitavaid seoseid, mis avalduvad tarbija käitumises: näiteks tsitrusviljade armastajad või piima marki, millelt tõenäoliselt üleminekut tehakse. Samuti pole üllatav, et tooted, mille korduvad ostud on kõrge, nagu või, ilmuvad ka siin.

Markovi ahelate meetodi mõõdikud on järgmised:

k — tooteid, mis pakutakse iga ostetud toote kohta kliendi viimases tehingus.
Kuidas me näeme, näitab parim tulemus konfiguratsioon k=4. Neljanda nädala tõusu saab selgitada hooajalise käitumisega pühade ajal. 

Sarnased tooted ostjatele, nende omaduste järgi, mis on loodud erinevate mudelite poolt

Nüüd oleme jõudnud kõige keerulisema ja huvitavama osa juurde — lähimate naabrute otsimine ostjate ja erinevate mudelite põhjal loodud toodete vektorite järgi. Oma töös kasutame selliseid mudeleid 3:

• ALS
• Word2Vec (Item2Vec selliste ülesannete jaoks)
• DSSM

ALS-i oleme juba käsitlenud, võimalik on lugeda, kuidas see treenitakse siin. Word2Vec puhul kasutame kõigile tuntud mudeli teostust gensim. Sarnaselt tekstidele määratleme tehingu ostu tšekiks. Nii et toote vektori koostamisel õpib mudel prognoosima toote "konteksti" tšekis (teised tooted tšekis). E-kaubanduse andmete puhul on parem kasutada tšeki asemel ostja sessiooni, sellest on hästi kirjutanud poisid Ozon. DSSM-i uurimine on huvitavam. Esmalt kirjutasid selle poisid Microsoftist, kui mudeli otsimiseks, siit saab lugeda originaal teadusartiklit. Mudeli arhitektuur näeb välja selline:

Siin Q — päring, kasutaja otsingupäring, D[i] — dokument, veebileht. Mudelisse sisenevad päringu ja lehekülgede tunnused vastavalt. Iga sissepääsukiht järgneb teatud arv täisühendatud kihte (multilayer perceptron). Edasi õpib mudel minimeerima kosinusnurka viidatud vektorite vahel, mis saadud mudeli viimastest kihtidest.
Soovituste ülesannetes kasutatakse täpselt sama arhitektuuri, ainult et päringu asemel kasutatakse kasutajat ja lehtede asemel — tooteid. Ja meie juhtumi puhul muudetakse see arhitektuur järgmiseks:

Nüüd on tulemuste kontrollimiseks jäänud katta viimane hetk — kui ALS ja DSSM puhul on kasutajate vektorid selgelt määratletud, siis Word2Vec puhul on meil ainult tootevektorid. Siin kasutame kasutajate vektori koostamiseks 3 peamist lähenemist:

1. Lihtsalt liita vektorid, siis kosinuslikul kaugusel tuleb, et oleme lihtsalt keskmistatud tooteid ostuajaloos.
2. Vektorite summutamine mingi ajakalu järgi.
3. Kaubanduse kaalu määramine TF-IDF teguriga.

Ainult lineaarse kaalumise puhul lähtume hüpoteesist, et toode, mille kasutaja ostis eile, mõjutab tema käitumist rohkem kui toode, mille ta ostis kuus kuud tagasi. Seega hindame eelmist nädalat ostjate jaoks koefitsiendiga 1 ja seda, mis toimus edasi, koefitsiendiga ½, ⅓ jne:

TF-IDF koefitsientide puhul teeme täpselt sama, mis TF-IDF puhul tekstides, ainult et käsitleme ostjat kui dokumenti ja tšekki kui pakkumist, seega sõna — toode. Nii liigub kasutaja vektor rohkem haruldaste toodete suunas, samas kui sagedased ja kasutajale tuttavad tooted ei muuda seda eriti. Selle lähenemise illustreerimiseks võime öelda järgmist:

Vaadakem nüüd metrikaid. Sellised on ALS tulemused:

Item2Veci metrikad erinevate ostja vektori loomise variatsioonidega:

Antud juhul kasutatakse täpselt sama mudelit, mis meie baasjuhistes. Erinevus seisneb ainult selles, millist k-d me kasutame. Kuni 50-70 lähimat toodet iga ostja kohta tuleb kasutada vaid koostööalusel mudelil.

Ja metrikad DSSM-i jaoks:

Kuidas kõiki meetodeid kombineerida?

See on suurepärane, ütlete teie, aga kuidas kasutada sellist suurt tööriistade komplekti kandidaatide hankimiseks? Kuidas leida oma andmete jaoks optimaalse konfiguratsiooni? Siin tekivad meil mitmed ülesanded:

1. Peame piirama hüperparameetrite otsinguruumi igas meetodis. Sellega on muidugi igal pool diskreetne, kuid võimalike punktide arv on väga suur.
2. Kuidas valida väikese piiratud valimi põhjal konkreetsetest meetoditest ja konkreetsetest hüperparameetritest oma metrikale parim konfiguratsioon?

Ühtegi üheselt õiget vastust esimesele küsimusele me praegu ei leidnud, seetõttu lähtume järgnevast: iga meetodi jaoks on kirjutatud hüperparameetrite otsinguruumi piiraja, olenevalt mõnedest statistikast, mis meil andmete kohta on. Nii teades keskmist aega ostude vahel inimestel, saame oletada, millise perioodiga kasutada meetodit „mida on juba ostetud“ ja „aegunud ostu periood“.

Ja pärast seda, kui oleme läbi vaadanud mõistliku arvu erinevaid meetodite variatsioone, märkame järgmist: iga rakendus toob välja teatud arvu kandidaate ja sellel on teatud väärtus meie jaoks olulisel mõõdikul (recall). Me tahame kokku saada teatud arvu kandidaate, mis sõltub meie lubatud arvutusvõimsusest, maksimaalselt võimaliku mõõdikuga. Siin on ülesanne kenasti kokku tõmmatud seljakoti ülesandeks.

Siin on kandidaatide arv - ingli kaal, ja meetodi recall - selle väärtus. Kuid on veel 2 momenti, mida tasub arvesse võtta algoritmi rakendamisel:

• Meetoditel võib olla kattuvust kandidaatides, mida nad välja toovad.
• Mõnel juhul on lubatud võtta üks meetod kaks korda erinevate parameetritega ja kandidaatide väljund esimesest ei ole teise alamhulk.

Näiteks, kui võtta meetodi rakendamine "see, mida juba ostetud" erinevate vahemikega väljavõtmiseks, siis nende kandidaatide kogud on üksteisesse sisse pandud. Samas, erinevad parameetrid "perioodilistes ostudes" ei anna väljundis täielikku kattuvust. Seetõttu jagame proovide meetodid erinevate parameetritega plokkideks, nii et igast blokist tahame võtta mitte rohkem kui ühe väljavõtmisviisi konkreetsete hüperparameetritega. Selleks tuleb natuke nutikalt läheneda seljakoti ülesande rakendamisele, kuid aega ning tulemust see ei muuda.

Selline nutikas kombinatsioon võimaldab meil võrrelda järgmisi mõõdikuid lihtsalt koostöömudelitega:

Lõplikel mõõdikutel näeme järgmist pilti:

Kuid siin võib märgata, et on jäänud üks katmata hetk soovitustes, mis on äritegevusele kasulikud. Praegu oleme lihtsalt õppinud suurepäraselt ennustama, mida kasutaja ostab näiteks järgmisel nädalal. Kuid lihtsalt anda allahindlust sellele, mida ta niikuinii ostab, ei ole väga lahe. Kuid on äge maksimeerida matemaatilist ootust näiteks järgmiste mõõdikute osas:

1. Kasum/kaubavahetus isiklike soovituste põhjal.
2. Ostjate keskmine ostusumma.
3. Külastuste sagedus.

Nii me korrutame saadud tõenäosused erinevate koefitsientidega ja järjestame need nii, et tippu pääsevad tooted, mis mõjutavad kõrgemaid mõõdikuid. Siin pole ühtset lahendust, millist lähenemist paremini kasutada. Isegi meie katsetame selliste koefitsientidega otse tootmises. Kuid siin on mõned huvitavad meetodid, mis annavad meil sageli parimaid tulemusi:

1. Korrutada toote hinna/marginaaliga.
2. Korrutada keskmise arvega, kus toode esineb. Nii tõusevad esile tooted, millega tavaliselt ostetakse veel midagi.
3. Korrutada selle toote keskmise külastussagedusega, lähtudes hüpoteesist, et see toode kutsub sagedamini tagasi tulema.

Katsed koefitsientidega on andnud meile järgmised mõõdikud tootmises:

Siin toodete kogusummade konversioon — ostetud toodete osakaal kõigist soovitatud toodetest, mille oleme genereerinud.

Täpne lugeja märgib olulise erinevuse offline ja online mõõdikute vahel. Selline käitumine on seletatav sellega, et mitte kõik dünaamilised filtrid toodete osas, mida saab soovitada, ei ole mudeli koolitamisel arvesse võetavad. Meie jaoks on normaalne, et pool ekstrakteeritud kandidaatidest saab filtreeritud, see on meie valdkonnas iseloomulik eripära.

Tulu osas näeb lugu välja järgmine, on näha, et soovituste kasutuselevõtuga tõuseb testgrupi tulu märgatavalt, praegu on meie soovitustega keskmine tulu suurenemine 3-4%:

Kokkuvõtteks tahan öelda, et kui teil pole reaalajas soovitusi vaja, siis on väga suur kvaliteedikogus eksperimentide tegemisel soovituste kandidaatide ekstraktsioonis. Suur hulk aega nende genereerimiseks võimaldab kombineerida palju häid meetodeid, mis kokku annavad suurepäraseid tulemusi äri jaoks.

Olen rõõmuga avatud aruteludeks kommentaarides kõigiga, kes peavad materjali huvitavaks. Küsimusi saab esitada mulle isiklikult telegram. Samuti joonistan oma mõtteid AI/algatuste kohta oma telegrami kanalis — teretulemast 🙂

Allikas: habr.com