Ciao a tutti! Sono Sasha, CTO e Co-Fondatore di LoyaltyLab. Due anni fa, con i miei amici, come tutti gli studenti squattrinati, andavamo a comprare birra nel negozio più vicino. Ci rattristava molto che il rivenditore, conoscendo il nostro arrivo per la birra, non offrisse uno sconto per patatine o snack, anche se sembrava così logico! Non capivamo perché succedesse e abbiamo deciso di creare la nostra azienda. E come bonus, potevamo ricevere sconti ogni venerdì su quelle stesse patatine.

E siamo arrivati al punto che, con il materiale sulla parte tecnica del prodotto, parlo a NVIDIA GTC. Siamo lieti di condividere i nostri progressi con la comunità, quindi pubblico la mia presentazione in forma di articolo.

Introduzione

Come capita all'inizio di ogni percorso, abbiamo iniziato con una panoramica su come vengono realizzati i sistemi di raccomandazione. E l'architettura più popolare si è rivelata essere del seguente tipo:

È composta da due parti:

Campionamento dei candidati per le raccomandazioni con un modello semplice e veloce, di solito collaborativo.
Ranking dei candidati con un modello di contenuto più complesso e lento, considerando tutte le possibili caratteristiche nei dati.

Da qui in avanti utilizzerò i seguenti termini:

candidate/candidato per raccomandazioni — coppia user-prodotto che può potenzialmente entrare nelle raccomandazioni in produzione.
candidates extraction/extractor/metodo di estrazione dei candidati — processo o metodo di estrazione dei “candidati per raccomandazioni” dai dati esistenti.

Nel primo passaggio si usano generalmente diverse variazioni di filtraggio collaborativo. La più popolare è ALS. È sorprendente che la maggior parte degli articoli sui sistemi di raccomandazione discuta solo vari miglioramenti dei modelli collaborativi nel primo passo, ma non si parla molto di altri metodi di campionamento. Per noi, l'approccio che utilizzava solo modelli collaborativi e varie ottimizzazioni non ha fornito la qualità che ci aspettavamo, quindi ci siamo immersi nella ricerca su questo aspetto. Alla fine dell'articolo mostrerò quanto siamo riusciti a migliorare l'ALS, che era il nostro baseline.

Prima di passare alla descrizione del nostro approccio, è importante notare che nelle raccomandazioni in tempo reale, quando dobbiamo considerare i dati che risalgono a 30 minuti fa, ci sono davvero pochi approcci che possono funzionare nel tempo richiesto. Ma, nel nostro caso, raccogliere raccomandazioni non avviene 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 di migliorare notevolmente la qualità.

Prendiamo come baseline le metriche che mostra solo ALS nel compito di estrazione dei candidati. Le metriche chiave che monitoriamo sono le seguenti:

Precision — percentuale di candidati corretti tra quelli campionati.
Recall — percentuale di candidati verificatisi tra quelli realmente presenti nell'intervallo target.
F1-score — F-misura calcolata sulle due precedenti.

Guarderemo anche le metriche del modello finale dopo l'addestramento del gradiente boosting con caratteristiche aggiuntive di contenuto. Anche qui ci sono 3 metriche principali:

precision@5 — percentuale media di prodotti inseriti nei top-5 per probabilità per ogni acquirente.
response-rate@5 — conversione degli acquirenti da visita in negozio in acquisto di almeno un'offerta personale (in un'offerta ci sono 5 prodotti).
avg roc-auc per user — media del roc-auc per ogni acquirente.

È importante notare che tutte le metriche sopra menzionate sono misurate su cross-validation su serie temporali, cioè l'addestramento avviene sulle prime k settimane, mentre i dati di test sono presi dalla settimana k+1. In questo modo, i picchi e le flessioni 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 basati su dati transazionali di un cliente, in modo che il confronto sia corretto.

Prima di iniziare a descrivere il nostro approccio, guardiamo prima la baseline, che rappresenta un modello ALS addestrato.
Metriche di estrazione dei candidati:

Metriche finali:

Considero tutte le implementazioni degli algoritmi come una certa ipotesi commerciale. Quindi, in modo molto grezzo, tutti i modelli collaborativi possono essere considerati come un'ipotesi che "le persone tendono ad acquistare ciò che acquistano le persone simili a loro". Come ho già detto, non ci siamo limitati a questa semantica ecco quali ipotesi funzionano bene sui dati nel retail offline:

Cosa hanno acquistato in precedenza.
Simile a ciò che hanno acquistato in precedenza.
Periodo di acquisto molto passato.
Popolare per categorie/marche.
Acquisti alternativi di diversi prodotti settimana dopo settimana (catene di Markov).
Prodotti simili per i clienti, in base alle caratteristiche costruite da diversi modelli (Word2Vec, DSSM, ecc.).

Cosa ha comprato in precedenza

L'euristica più ovvia, che funziona molto bene nel retail alimentare. Qui consideriamo tutti i prodotti che il possessore della carta fedeltà ha acquistato negli ultimi K giorni (di solito 1-3 settimane), oppure K giorni nell'anno precedente. Applicando solo questo metodo, otteniamo le seguenti metriche:

È evidente che, quanto più lungo è il periodo, maggiore è il nostro recall e minore è la precisione e viceversa. I migliori risultati in media per i clienti sono ottenuti con “ultime 2 settimane”.

Simile a ciò che ha comprato in precedenza

Non sorprende che per il retail alimentare “cosa ha 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 prodotto nuovo. Pertanto, proponiamo di migliorare leggermente questa euristica utilizzando gli stessi modelli collaborativi. Dai vettori ottenuti durante l'addestramento ALS, possiamo estrarre prodotti simili a quelli già acquistati dall'utente. Questa idea è molto simile ai “video simili” nei servizi di streaming video, ma dato che non sappiamo cosa stia mangiando/acquistando l'utente in un dato momento, possiamo solo cercare simili a ciò che ha già acquistato, poiché sappiamo già quanto bene funzioni. Applicando questo metodo sulle transazioni degli utenti negli ultimi 2 settimane otteniamo le seguenti metriche:

Qui k — il numero di prodotti simili estratti per ogni prodotto acquistato dal cliente negli ultimi 14 giorni.
Questo approccio ha funzionato particolarmente bene per un cliente a cui era fondamentale non consigliare ciò che era già nella storia 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 gestire prodotti come detersivi / shampoo / ecc.? Cioè con prodotti che probabilmente non sono necessari ogni settimana o due e che i metodi precedenti non possono estrarre. Da qui scaturisce la seguente idea: calcolare il periodo di acquisto di ciascun prodotto in media tra i clienti che hanno acquistato il prodotto più k volte. E poi estrarre ciò che probabilmente è già finito per il cliente. I periodi calcolati per i prodotti possono essere controllati a occhio per verificarne l'adeguatezza:

E successivamente verificheremo se la fine del periodo del prodotto rientra nell'intervallo di tempo in cui le raccomandazioni saranno in produzione e campioneremo ciò che vi si trova. Possiamo illustrare l'approccio in questo modo:

Qui abbiamo 2 casi principali che possiamo considerare:

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

Nel grafico successivo è possibile vedere quali risultati ottiene 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 tale situazione (0, 0) ci sia il più alto recall e il più basso precision, poiché in queste condizioni vengono estratti il maggior numero di candidati. Tuttavia, i migliori risultati si ottengono quando non campioniamo prodotti per i clienti che hanno acquistato un certo prodotto meno di k volte e estraiamo anche prodotti la cui fine del periodo rientra prima dell'intervallo target.

Popolare per categoria

Un'altra idea abbastanza ovvia è campionare prodotti popolari per diverse categorie o marchi. Qui calcoliamo per ciascun cliente top-k categorie/brand “preferiti” e estraiamo “popolare” da questa categoria/marchio. Nel nostro caso, definiamo “preferiti” e “popolari” in base al numero di acquisti del prodotto. Un ulteriore vantaggio di questo approccio è l'applicabilità nel caso di avvio a freddo. Cioè, per i clienti che hanno effettuato pochissimi acquisti, che non hanno fatto acquisti da molto tempo, o che hanno appena registrato la carta fedeltà. Per loro è più semplice e migliore suggerire prodotti popolari tra i clienti con una storia di acquisti esistente. Le metriche risultano essere le seguenti:

Qui il numero dopo la parola “category” indica il livello di profondità della categoria.

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

Acquisti alternati di diversi prodotti settimana dopo settimana

Un approccio interessante che non ho visto negli articoli sui sistemi di raccomandazione è il metodo statistico relativamente semplice e funzionante delle catene di Markov. Qui prendiamo 2 settimane diverse e costruiamo coppie di prodotti per ogni cliente. [acquistato nella settimana i]-[acquistato nella settimana j], dove j > i, e da qui calcoliamo per ciascun prodotto la probabilità di passare a un altro prodotto nella settimana successiva. Cioè, per ciascuna coppia di prodotti producti-productj contiamo il loro numero nelle coppie trovate e dividiamo per il numero di coppie in cui producti era nella prima settimana. Per estrarre i candidati, prendiamo l'ultimo scontrino del cliente e recuperiamo top-k i prodotti successivi più probabili dalla matrice di transizione che abbiamo ottenuto. Il processo di costruzione della matrice di transizione appare così:

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

Qui possiamo notare delle dipendenze interessanti che emergono nel comportamento dei consumatori: ad esempio, gli amanti degli agrumi o il marchio di latte, da cui c'è una grande probabilità di passare a un altro. Non sorprende nemmeno che i prodotti con alta frequenza di riacquisto, come il burro, si trovino qui.

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

k — il numero di prodotti estratti per ogni prodotto acquistato nell'ultima transazione del cliente.
Come possiamo vedere, la configurazione con k=4 mostra i migliori risultati. L'impennata nella quarta settimana può essere spiegata dal comportamento stagionale nei giorni festivi.

Prodotti simili per i clienti, basati su 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 attraverso diversi modelli. Nella nostra analisi utilizziamo 3 di questi modelli:

ALS
Word2Vec (Item2Vec per queste attività)
DSSM

Abbiamo già analizzato ALS, puoi leggere su come viene addestrato qui. Nel caso di Word2Vec, utilizziamo la famosa implementazione del modello da gensim. Analogamente ai testi, definiamo una transazione come lo scontrino di acquisto. In questo modo, nella costruzione del vettore del prodotto, il modello impara a prevedere, in base al prodotto nello scontrino, il suo 'contesto' (gli altri prodotti nello scontrino). Nei dati eCommerce è meglio utilizzare la sessione del cliente invece dello scontrino; a questo proposito hanno scritto ottimamente i ragazzi di Ozon. Analizzare DSSM è più interessante. Originariamente è stato sviluppato dai ragazzi di Microsoft come modello di ricerca, puoi leggere qui il documento di ricerca originale. L'architettura del modello appare così:

Qui Q — query, la richiesta di ricerca dell'utente, D[i] — documento, pagina web. Come input del modello vengono forniti le caratteristiche della richiesta e delle pagine, rispettivamente. Dopo ogni strato di input ci sono diversi strati completamente connessi (multilayer perceptron). Successivamente, il modello impara a minimizzare il coseno tra i vettori generati negli strati finali del modello.
Nelle attività di raccomandazione viene utilizzata esattamente la stessa architettura, solo che invece della query si tratta dell'utente e invece delle pagine — dei prodotti. E nel nostro caso questa architettura si trasforma nel seguente modo:

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

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

Nel caso del ponderamento lineare del vettore dell'acquirente, partiamo dall'ipotesi che il prodotto acquistato dall'utente ieri influisca di più sul suo comportamento rispetto al prodotto acquistato sei mesi fa. Pertanto, consideriamo la settimana precedente dell'acquirente con un coefficiente di 1, mentre ciò che è accaduto prima con coefficienti di ½, ⅓, e così via:

Per i coefficienti TF-IDF facciamo esattamente la stessa cosa che faremmo per TF-IDF nei testi, solo che consideriamo l'acquirente come documento e lo scontrino come frase, rispettivamente, la parola è il prodotto. Così, il vettore dell'utente sarà spostato maggiormente verso i prodotti rari, mentre prodotti frequenti e familiari per l'acquirente non lo modificheranno particolarmente. Questo approccio può essere illustrato così:

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

Metriche per Item2Vec con diverse variazioni nella costruzione del vettore dell'utente:

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

E metriche per il DSSM:

Come combinare tutti i metodi?

Sembra interessante, direte voi, ma come gestire un così ampio insieme di strumenti per l'estrazione dei candidati? Come scegliere la configurazione ottimale per i propri dati? Qui ci troviamo di fronte a diverse sfide:

Dobbiamo in qualche modo limitare lo spazio di ricerca degli iperparametri per ciascun metodo. Certamente, è discreto ovunque, ma il numero di punti possibili è molto grande.
Come possiamo selezionare la migliore configurazione per la nostra metrica da un piccolo campione limitato di metodi specifici con iperparametri specifici?

Non abbiamo trovato una risposta univoca alla prima domanda, quindi partiamo dal presupposto che per ogni metodo sia scritto un limitatore dello spazio di ricerca degli iperparametri a seconda di alcune statistiche sui dati che abbiamo. In questo modo, conoscendo il periodo medio tra gli acquisti delle persone, possiamo prevedere con quale periodicità utilizzare il metodo “cosa è già stato acquistato” e “periodo da molto tempo fa”.

E dopo aver esaminato un numero adeguato di variazioni di diversi metodi, notiamo quanto segue: ogni implementazione estrae un certo numero di candidati e ha un certo valore della metrica chiave per noi (recall). Vogliamo ottenere un numero specifico di candidati, a seconda delle nostre capacità computazionali ammissibili, con la massima metrica possibile. Qui il compito si riduce elegantemente a un problema dello zaino.

In questo caso, il numero di candidati è il peso del lingotto, mentre il recall del metodo è il suo valore. Tuttavia, ci sono anche altri 2 aspetti da considerare nell'implementazione dell'algoritmo:

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

Ad esempio, se utilizziamo l'implementazione del metodo "quello che è già stato acquistato" con intervalli diversi per l'estrazione, i loro insiemi di candidati saranno contenuti l'uno nell'altro. Allo stesso tempo, diversi parametri nelle “compere periodiche” non generano una sovrapposizione completa. Pertanto, suddividiamo i metodi di campionamento con parametri diversi in blocchi, in modo da prendere da ciascun blocco non più di un approccio all'estrazione con iperparametri specifici. A tal fine, è necessario un po' di ingegno nell'implementazione del problema dello zaino, ma l'asintotica e il risultato non cambieranno.

Questa combinazione intelligente ci permette di ottenere le seguenti metriche rispetto ai modelli puramente collaborativi:

Nelle metriche finali vediamo il seguente quadro:

Tuttavia, qui possiamo notare che c'è ancora un aspetto non coperto per le raccomandazioni utili per il business. Ora abbiamo semplicemente imparato a prevedere bene ciò che l'utente acquisterà, ad esempio, la prossima settimana. Ma dare semplicemente uno sconto su ciò che acquisterà non è molto interessante. Invece, è fantastico massimizzare l'aspettativa per le seguenti metriche:

Margine/volume d'affari dalle raccomandazioni personalizzate.
Spesa media dei clienti.
Frequenza delle visite.

In questo modo, moltiplichiamo le probabilità ottenute per diversi coefficienti e le riordiniamo in modo che i prodotti che influenzano le metriche superiori salgano in classifica. Non c'è una soluzione predefinita su quale approccio utilizzare. Anche noi sperimentiamo con tali coefficienti direttamente in produzione. Ma ci sono interessanti tecniche che spesso ci danno i migliori risultati:

Moltiplicare per il prezzo/margine del prodotto.
Moltiplicare per la spesa media in cui appare il prodotto. In questo modo emergeranno prodotti che di solito vengono acquistati insieme ad altro.
Moltiplicare per la media della frequenza di visite dei clienti per questo prodotto, basandosi sull'ipotesi che questo prodotto inviti 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 — percentuale di prodotti acquistati rispetto a tutti i prodotti nelle raccomandazioni che abbiamo generato.

Il lettore attento noterà una differenza sostanziale tra le metriche offline e online. Questo comportamento è spiegato dal fatto che non tutti i filtri dinamici sui prodotti che possono essere raccomandati possono essere considerati nell'addestramento del modello. Per noi è normale che metà dei candidati estratti possa essere filtrata; questa specificità è caratteristica del nostro settore.

Per quanto riguarda il fatturato, la situazione è la seguente: si nota che dopo il lancio delle raccomandazioni, il fatturato del gruppo di test aumenta notevolmente, attualmente l'aumento medio del fatturato con le nostre raccomandazioni è del 3-4%:

In conclusione, vorrei dire che, se non avete bisogno di raccomandazioni in tempo reale, c'è un notevole miglioramento della qualità negli esperimenti con l'estrazione di candidati per le raccomandazioni. Un grande investimento di tempo nella loro generazione rende possibile combinare molti buoni metodi, il che porterà a risultati straordinari per il business.

Sarei felice di interagire nei commenti con chiunque trovi interessante il materiale. Potete farmi domande personalmente a telegram. Condivido anche i miei pensieri su AI/startup nel mio canale telegram — benvenuti 🙂

Fonte: habr.com