Ciao a tutti! Mi chiamo Sasha, sono CTO e Co-Fondatore di LoyaltyLab. Due anni fa, con gli amici, proprio come tutti gli studenti poveri, andavamo a comprare birra nel negozio più vicino la sera. Ci faceva molto dispiacere che il rivenditore, sapendo che saremmo andati a prendere birra, non offrisse uno sconto su patatine o taralli, anche se sarebbe stato così logico! Non capivamo perché si verificasse una situazione del genere e abbiamo deciso di creare la nostra azienda. E come bonus, concederci sconti ogni venerdì sulle stesse patatine.

E tutto è arrivato al punto che parlo del materiale relativo all'aspetto tecnico del prodotto al NVIDIA GTC. Siamo felici di condividere le nostre scoperte con la comunità, quindi pubblicherò il mio intervento sotto forma di articolo.

Introduzione

Come tutti all'inizio del cammino, siamo partiti da una panoramica su come vengono realizzati i sistemi di raccomandazione. E l'architettura più popolare si è rivelata essere del seguente tipo:

Consiste di due parti:

Campionamento dei candidati per le raccomandazioni tramite un modello semplice e veloce, di solito collaborativo.
Rendimento dei candidati tramite un modello di contenuto più complesso e lento, tenendo conto di tutte le possibili caratteristiche nei dati.

Da qui in avanti userò i seguenti termini:

candidate/candidato per le raccomandazioni — coppia user-product, che potrebbe potenzialmente entrare nelle raccomandazioni in produzione.
candidates extraction/extractor/metodo di estrazione dei candidati — processo o metodo di estrazione dei "candidati per le raccomandazioni" dai dati disponibili.

Nel primo passaggio, si usano di solito diverse varianti di filtro collaborativo. Il più popolare è ALS. È sorprendente come la maggior parte degli articoli sui sistemi di raccomandazione trattino solo di vari miglioramenti ai modelli collaborativi nella prima fase, mentre di altri metodi di campionamento non parla quasi nessuno. Per noi, l'approccio che utilizza solo modelli collaborativi e varie ottimizzazioni non ha fornito la qualità che ci aspettavamo, quindi ci siamo immersi in ricerche specifiche su questa parte. E alla fine dell'articolo mostrerò quanto siamo riusciti a migliorare l'ALS, che per noi era il baseline.

Prima di passare alla descrizione del nostro approccio, è importante notare che nelle raccomandazioni in tempo reale, quando è fondamentale considerare i dati che risalgono a 30 minuti fa, ci sono effettivamente pochi approcci che possono funzionare nel tempo necessario. Tuttavia, nel nostro caso, le raccomandazioni devono essere raccolte non più di una volta al giorno, e nella maggior parte dei casi una volta alla settimana, il che ci consente di utilizzare modelli complessi e aumentare significativamente la qualità.

Prendiamo come baseline le metriche mostrate solo da ALS nella task di estrazione dei candidati. Le metriche chiave che stiamo monitorando sono le seguenti:

Precision — la quota di candidati scelti correttamente tra quelli campionati.
Recall — la quota di candidati effettivi rispetto a quelli che erano realmente nel intervallo target.
F1-score — la F-measure calcolata sui due punti precedenti.

Tireremo anche in considerazione le metriche del modello finale dopo l'addestramento del gradient boosting con ulteriori caratteristiche di contenuto. Anche qui ci sono 3 metriche principali:

precision@5 — la quota media di prodotti correttamente identificati tra i primi 5 in base alla probabilità per ciascun acquirente.
response-rate@5 — la conversione degli acquirenti da visita in negozio a un acquisto di almeno un'offerta personalizzata (in un'unica offerta ci sono 5 prodotti).
avg roc-auc per user — media roc-auc per ciascun acquirente.

È importante notare che tutte le metriche sopra menzionate vengono misurate su cross-validation time-series, cioè l'addestramento avviene sulle prime k settimane, e come dati di test viene presa la settimana k+1. In questo modo, i picchi e i cali stagionali influenzano minimamente l'interpretazione della qualità dei modelli. In seguito, su tutti i grafici, l'asse delle ascisse rappresenterà il numero della settimana nella cross-validation, mentre l'asse delle ordinate rappresenterà il valore della metrica indicata. Tutti i grafici sono costruiti sui dati transazionali di un singolo cliente, in modo che il confronto tra di loro sia corretto.

Prima di iniziare a descrivere il nostro approccio, diamo un'occhiata alla baseline, che consiste in un modello ALS addestrato.
Metriche per l'estrazione dei candidati:

Metriche finali:

Io considero tutte le implementazioni degli algoritmi come una sorta di ipotesi di business. Pertanto, molto grossolanamente, tutti i modelli collaborativi possono essere visti come l'ipotesi che "le persone tendono a comprare ciò che comprano persone simili a loro". Come ho già detto, non ci siamo limitati a tale semantica ecco quali altre ipotesi funzionano bene con i dati nel retail offline:

Cosa è stato comprato in precedenza.
Simile a ciò che è stato comprato in precedenza.
Periodo di acquisto di molto tempo fa.
Popolare per categorie/marche.
Acquisti alternati di diversi articoli settimana per settimana (catene di Markov).
Articoli simili per i clienti, in base a caratteristiche costruite da diversi modelli (Word2Vec, DSSM, ecc.).

Cosa è stato comprato precedentemente

La più ovvia euristica che funziona molto bene nel retail alimentare. Qui consideriamo tutti gli articoli che il titolare della carta fedeltà ha acquistato negli ultimi K giorni (solitamente 1-3 settimane), oppure K giorni un anno fa. Applicando solo questo metodo, otteniamo le seguenti metriche:

È abbastanza evidente che, più lungo prendiamo il periodo, maggiore sarà il nostro recall e minore la precisione e viceversa. I risultati migliori in media per i clienti vengono dai “ultimi 2 settimane”.

Simile a ciò che è stato comprato in precedenza

Non sorprende che per il retail alimentare “cosa è stato comprato in precedenza” funzioni bene, ma estrarre candidati solo da ciò che l'utente ha già acquistato non è molto efficace, perché sarà difficile sorprendere il cliente con un nuovo prodotto. Pertanto, proponiamo di perfezionare questa euristica con l'aiuto degli stessi modelli collaborativi. Dai vettori che abbiamo ottenuto durante l'addestramento dell'ALS, possiamo estrarre articoli simili a ciò che l'utente ha già comprato. Questa idea è molto simile ai “video suggeriti” nei servizi di streaming video, ma poiché non sappiamo cosa stia mangiando/acquistando l'utente in quel momento, dobbiamo cercare solo articoli simili a ciò che ha già acquistato, soprattutto perché sappiamo già quanto bene questo funzioni. Applicando questo metodo sulle transazioni degli utenti negli ultimi 2 settimane otteniamo le seguenti metriche:

Qui k — il numero di articoli simili che vengono estratti per ogni articolo acquistato dal cliente negli ultimi 14 giorni.
Questo approccio ha funzionato particolarmente bene per un cliente a cui era cruciale non raccomandare affatto ciò che era già nella cronologia degli acquisti dell'utente.

Periodo di acquisto passato

Come abbiamo già scoperto, a causa dell'alta frequenza di acquisto dei prodotti, il primo approccio funziona bene nella nostra specificità. Ma come comportarsi con prodotti come detersivo per bucato/shampoo/ecc.? Cioè con tali prodotti che probabilmente non sono necessari ogni una o due settimane e che i metodi precedenti non possono estrarre. Da qui deriva la seguente idea: si propone di calcolare il periodo di acquisto di ogni prodotto in media per i clienti che hanno acquistato il prodotto più k volte. E successivamente estrarre ciò che è più probabile che il cliente abbia già esaurito. I periodi calcolati per i prodotti possono essere verificati visivamente per adeguatezza:

E poi vedremo se la fine del periodo del prodotto rientra nell'intervallo di tempo in cui le raccomandazioni saranno in produzione e campionare ciò che rientra. L'approccio può essere illustrato nel modo seguente:

Qui abbiamo due casi principali che possiamo esaminare:

È necessario campionare prodotti per clienti che hanno acquistato il prodotto meno di K volte.
È necessario campionare il prodotto se la fine del suo periodo rientra prima dell'inizio dell'intervallo target.

Nel grafico seguente si possono vedere quali risultati raggiunge questo metodo con diversi iperparametri:

ft — Considerare solo i clienti che hanno acquistato il prodotto almeno K (qui K=5) volte
tm — Considerare solo i candidati che rientrano nell'intervallo target

Non sorprende che in questo stato (0, 0) il richiamo massimo e la precisione minima , poiché con tale condizione vengono estratti il maggior numero di candidati. Tuttavia, i migliori risultati si ottengono quando non campioniamo prodotti per clienti che hanno acquistato un prodotto specifico meno di volte e estraiamo anche prodotti la cui fine periodo rientra prima dell'intervallo target.Popolare per categoria k Un'altra idea piuttosto ovvia è quella di campionare prodotti popolari per diverse categorie o marchi. Qui calcoliamo per ogni cliente

top-k

Ecco una breve sintesi Per continuare ad espandere le idee Le categorie/brand "preferiti" e traiamo il "popolare" da questa categoria/brand. Nel nostro caso, definiamo "preferiti" e "popolari" in base al numero di acquisti del prodotto. Un ulteriore vantaggio di questo approccio è la sua applicabilità nei casi di avvio a freddo. Cioè, per i clienti che hanno effettuato pochissimi acquisti, non sono stati in negozio da molto tempo o hanno appena attivato la carta fedeltà. Per loro è più semplice e migliore suggerire prodotti popolari tra i clienti con una storia di acquisti. Le metriche risultano le seguenti:

Qui la cifra dopo la parola "category" indica il livello di nidificazione della categoria.

In generale, non sorprende nemmeno che i migliori risultati si ottengano da categorie più ristrette, poiché estraggono prodotti "preferiti" più precisi per i clienti.

Acquisti alternati di diversi prodotti da settimana a settimana

Un approccio interessante, che non ho visto in articoli sui sistemi di raccomandazione, è un metodo statistico abbastanza semplice e al contempo efficace delle catene di Markov. Qui prendiamo 2 settimane diverse, poi per ogni cliente costruiamo coppie di prodotti [acquistato nella settimana i]-[acquistato nella settimana j], dove j > i, e da qui calcoliamo per ogni prodotto la probabilità di passare a un altro prodotto nella settimana successiva. Cioè, per ogni coppia di prodotti prodottoi-prodottoj contiamo il loro numero nelle coppie trovate e dividiamo per il numero di coppie in cui prodottoi è stato nella prima settimana. Per estrarre i candidati prendiamo l'ultimo scontrino del cliente e tiriamo fuori Per continuare ad espandere le idee i prodotti più probabili per il successivo dalla matrice delle transizioni che abbiamo ottenuto. Il processo di costruzione della matrice delle transizioni appare così:

Da esempi reali nella matrice delle probabilità di transizione vediamo i seguenti fenomeni interessanti:

Qui si possono notare interessanti dipendenze che emergono nel comportamento dei consumatori: ad esempio, gli amanti degli agrumi o del latte, da cui è probabile che si passi a un altro. Non sorprende nemmeno che i prodotti con alta frequenza di acquisti ripetuti, come il burro, si trovino qui.

Le metriche nel metodo delle catene di Markov risultano le seguenti:

k — il numero di prodotti che vengono estratti per ogni prodotto acquistato nell'ultima transazione del cliente.
Come possiamo vedere, la configurazione con k=4 mostra il miglior risultato. L'impennata nella quarta settimana può essere spiegata dal comportamento stagionale durante le festività.

Prodotti simili per i clienti, in base alle caratteristiche costruite da diversi modelli

Siamo arrivati alla parte più complessa e interessante: la ricerca dei vicini più prossimi in base ai vettori di clienti e prodotti, costruiti utilizzando diversi modelli. Nella nostra analisi utilizziamo 3 di tali modelli:

ALS
Word2Vec (Item2Vec per tali compiti)
DSSM

Abbiamo già esaminato l'ALS, per informazioni su come viene addestrato puoi leggere qui. Nel caso di Word2Vec, utilizziamo l'implementazione ben nota del modello da gensim. Analogamente ai testi, definiamo un acquisto come la ricevuta di acquisto. Così, costruendo il vettore del prodotto, il modello impara a prevedere il "contesto" del prodotto nella ricevuta (gli altri prodotti nella ricevuta). Nei dati ecommerce è meglio utilizzare la sessione dell'utente anziché la ricevuta, su questo i ragazzi di Ozonhanno scritto molto bene. E l'analisi del DSSM è più interessante. È stato originariamente scritto dai ragazzi di Microsoft come un modello per la ricerca, qui puoi leggere l'articolo di ricerca originale. L'architettura del modello appare così:

Qui Q — query, la richiesta di ricerca dell'utente, D[i] — documento, pagina web. In ingresso al modello arrivano le caratteristiche della richiesta e delle pagine, rispettivamente. Dopo ogni strato di input ci sono alcuni strati completamente connessi (multilayer perceptron). Successivamente, il modello impara a minimizzare il coseno tra i vettori ottenuti negli ultimi strati del modello.
Nei compiti di raccomandazione viene utilizzata esattamente la stessa architettura, solo che invece della richiesta viene utilizzato l'utente, e invece delle pagine si utilizzano i prodotti. E nel nostro caso, questa architettura si trasforma in quanto segue:

Ora per verificare i risultati rimane da coprire l'ultimo aspetto: se nel caso di ALS e DSSM i vettori degli utenti sono chiaramente definiti, nel caso di Word2Vec abbiamo solo i vettori dei prodotti. Qui per costruire il vettore dell'utente abbiamo definito 3 approcci principali:

Semplicemente sommare i vettori, quindi per la distanza coseno risulterà che abbiamo semplicemente mediato i prodotti nella storia degli acquisti.
Somma dei vettori con un certo peso nel tempo.
Pesatura dei prodotti con il coefficiente TF-IDF.

Nel caso di pesatura lineare del vettore del compratore, partiamo dall'ipotesi che il prodotto acquistato dall'utente ieri abbia un'influenza maggiore sul suo comportamento rispetto a quello acquistato sei mesi fa. Così consideriamo la settimana precedente del compratore con un coefficiente di 1, mentre per quanto riguarda il passato utilizziamo coefficienti di ½, ⅓, e così via:

Per i coefficienti TF-IDF facciamo esattamente la stessa cosa che facciamo nei TF-IDF per i testi, solo che consideriamo il compratore come documento e la ricevuta come proposta, rispettivamente, la parola è il prodotto. Così il vettore dell'utente si sposterà di più verso prodotti rari, mentre quelli frequenti e abituali per il compratore non lo modificheranno particolarmente. Possiamo illustrare l'approccio come segue:

Ora diamo un'occhiata alle metriche. Ecco come appaiono i risultati di ALS:

Metriche per Item2Vec con diverse variazioni di costruzione del vettore del compratore:

In questo caso viene utilizzato esattamente lo stesso modello del nostro baseline. L'unica differenza è quale k utilizzeremo. Per utilizzare solo modelli collaborativi, è necessario prendere circa 50-70 prodotti più vicini per ogni compratore.

E le metriche per DSSM:

Come unire tutti i metodi?

Ottimo, dirai, ma cosa fare con un così grande insieme di strumenti per l'estrazione dei candidati? Come scegliere la configurazione ottimale per i propri dati? Qui ci sono diverse sfide:

Dobbiamo in qualche modo limitare lo spazio di ricerca degli iperparametri in ogni metodo. È, ovviamente, discreto ovunque, ma il numero di punti possibili è molto grande.
Come scegliere la migliore configurazione per la propria metrica da un piccolo campione limitato di metodi specifici con iperparametri specifici?

Attualmente non abbiamo trovato una risposta definitiva alla prima domanda, quindi partiamo dal presupposto che per ogni metodo è stato scritto un limite allo spazio di ricerca degli iperparametri in base a alcune statistiche sui dati che abbiamo. Così, conoscendo il periodo medio tra gli acquisti delle persone, possiamo ipotizzare quale periodo utilizzare per il metodo "cosa è già stato acquistato" e "periodo di acquisto avvenuto tanto tempo fa".

Dopo aver esaminato un adeguato numero di variazioni di diversi metodi, notiamo quanto segue: ciascuna implementazione estrae un certo numero di candidati e ha un certo valore di una metrica chiave per noi (recall). Vogliamo ottenere, in totale, un certo numero di candidati, dipendente dalle nostre capacità computazionali consentite, con la metrica massima possibile. Qui il problema si riduce elegantemente a un problema di knapsack.

Qui, il numero di candidati è il peso del lingotto, mentre il recall del metodo è il suo valore. Tuttavia, ci sono anche 2 aspetti da considerare durante l'implementazione dell'algoritmo:

I metodi possono sovrapporsi nei candidati che estraggono.
In alcuni casi, utilizzare un metodo due volte con parametri diversi sarà corretto e i candidati in uscita dal primo non saranno un sottoinsieme del secondo.

Ad esempio, se prendiamo l'implementazione del metodo "quello che già si è acquistato" con intervalli diversi per l'estrazione, i loro insiemi di candidati saranno annidati l'uno nell'altro. Allo stesso tempo, parametri diversi negli "acquisti periodici" in uscita non forniscono una sovrapposizione completa. Pertanto, dividiamo i metodi di campionamento con parametri diversi in blocchi in modo che da ciascun blocco vogliamo estrarre non più di un approccio con specifici iperparametri. Per fare ciò, è necessario un po' di ingegno nell'implementazione del problema di knapsack, ma la complessità asintotica e il risultato non cambieranno.

Questa combinazione intelligente ci consente di ottenere le seguenti metriche in confronto ai semplici modelli collaborativi:

Sulle metriche finali vediamo il seguente quadro:

Tuttavia, qui possiamo notare che rimane un aspetto non coperto per le raccomandazioni utili per le imprese. Attualmente, abbiamo semplicemente imparato a prevedere in modo efficace ciò che l'utente acquisterà, ad esempio, la settimana prossima. Ma semplicemente offrire uno sconto su ciò che comprerà comunque non è molto interessante. È molto meglio massimizzare il valore atteso, ad esempio, delle seguenti metriche:

Il margine/il fatturato dalle raccomandazioni personalizzate.
Il valore medio degli acquisti.
La frequenza delle visite.

In questo modo moltiplichiamo le probabilità ottenute per diversi coefficienti e le riordiniamo affinché i prodotti che influenzano maggiormente le metriche finiscano in cima. Non c'è una soluzione pronta su quale approccio sia meglio utilizzare. Anche noi facciamo esperimenti con questi coefficienti direttamente in produzione. Tuttavia, ecco alcune tecniche interessanti che di solito ci danno i migliori risultati:

Moltiplicare per il prezzo/margine del prodotto.
Moltiplicare per il valore medio degli acquisti in cui è presente il prodotto. In questo modo emergeranno prodotti che generalmente vengono acquistati insieme ad altri.
Moltiplicare per la frequenza media delle visite dei clienti a questo prodotto, basandosi sull'ipotesi che questo prodotto stimoli a tornare più spesso a cercarlo.

Dopo aver condotto esperimenti con i coefficienti, abbiamo ottenuto le seguenti metriche in produzione:

Qui conversione complessiva dei prodotti – la percentuale di prodotti acquistati rispetto a tutti i prodotti nelle raccomandazioni che abbiamo generato.

Il lettore attento noterà una sostanziale differenza tra le metriche offline e online. Questo comportamento è spiegato dal fatto che non è possibile considerare tutti i filtri dinamici per i prodotti che possono essere raccomandati durante l'addestramento del modello. È una situazione normale per noi quando metà dei candidati estratti può essere filtrata, questa specificità è caratteristica del nostro settore.

Ecco la situazione in merito ai ricavi: è evidente che dopo il lancio delle raccomandazioni, i ricavi del gruppo di test crescono notevolmente; attualmente, l'aumento medio dei ricavi con le nostre raccomandazioni è del 3-4 percento:

In conclusione, voglio dire che, se avete bisogno di raccomandazioni non in tempo reale, c'è un notevole aumento della qualità nei test per l'estrazione dei candidati per le raccomandazioni. Un grande quantitativo di tempo per la loro generazione consente di combinare molte buone tecniche, il che in totale darà risultati eccellenti per il business.

Sarei felice di interagire nei commenti con chiunque trovi interessante il materiale. Potete farmi domande personalmente in telegram. Inoltre, condivido le mie opinioni su AI/startup nel mio canale telegram – benvenuti 🙂

Fonte: habr.com