Cos’è un Recommender Engine

Lo scopo di un “Recommendation Engine” (o “Recommender System“) è di convincere l’utente a intraprendere determinate azioni su uno o più elementi di un catalogo (leggere contenuti; comprare articoli; recensire libri…) o a relazionarsi con altri utenti di un social network. Questo tentativo, tuttavia, non è percepito dall’utente come coercitivo bensì come servizio personalizzato sui propri gusti.

Un Recommender Engine è infatti una utility di frontend che suggerisce all’utente

• quali elementi potrebbe trovare interessante
• con quali utenti potrebbe volersi mettere in relazione

Perché siano davvero personalizzati, questi suggerimenti devono essere prodotti tenendo in considerazione i gusti dell’utente così come vengono desunti

• dalle sue abitudini di navigazione sul sito,
• dalle sue interazioni con altri elementi/utenti oppure
• dalle informazioni che compongono il suo profilo (account).

Questo significa che un Recommender Engine deve innanzitutto collezionare dati relativi all’utente, alle sue abitudini di navigazione e agli elementi/utenti con cui questi ha a che fare. E che l’utente deve essere autenticato e dunque riconoscibile.

Anche senza questo grado di personalizzazione, tuttavia, si può realizzare un Recommender Engine funzionante pur se basilare: è sufficiente partire dall’assunto implicito che se l’utente sta leggendo una scheda prodotto, o la descrizione di un utente, è interessato anche ad altri elementi/utenti simili.

Un simile Recommender Engine suggerirebbe dunque all’utente

• quali altri elementi condividono le caratteristiche dell’elemento visualizzato
• quali altri utenti condividono le caratteristiche dell’utente visualizzato

Si noti che in entrambi i casi (personalizzato / non personalizzato) un Recommender Engine necessita di un ampio catalogo di item/utenti da suggerire, affinché il sistema non sia limitato e dunque prevedibile. Le aziende dotate dei migliori Recommender Engine sono quelle che possiedono numerosi item da consigliare: Amazon, Google, Last.fm e Netflix.

Una soluzione potrebbe essere quella di aprire il proprio catalogo a diversi Content Provider; perché questi ritengano conveniente fornire i loro contenuti, tuttavia, esigono di poter valutare le performance del Recommendation Engine in questione. Si esce da questa empasse analizzando open data (ad esempio, Project Gutemberg in caso di libri e letteratura) e mostrando così il funzionamento dell’Engine.

Questa (necessaria) grande quantità di dati impone tuttavia che il Recommender Engine non calcoli i suggerimenti in tempo reale, bensì li generi in precedenza e poi li mostri al momento della richiesta.

Alcuni problemi:

1. Obsolescenza dei dati precedenti.

In alcuni ambiti (come ad esempio in quello della moda) il comportamento precedente dell’utente (o degli altri utenti presi come paragone) non è strumento sufficiente per valutarne i gusti, poiché i trend sono in continuo mutamento. Occorre quindi identificare dei trend-setter, ovvero quelle persone che hanno apprezzato per prime gli elementi/utenti cui anche il nostro utente si è interessato, arrivandoci dopo.

La descrizione dell’algoritmo potrebbe essere la seguente: “Trova gli elementi/utenti che sono stati [AZIONE_SOTTO_ANALISI] più di recente da quegli altri utenti che hanno compiuto le stesse azioni del nostro utente X sugli stessi elementi/utenti (o simili) ma, ogni volta, prima di lui”.

Ovvero: dapprima si identificano quegli utenti che hanno mostrato per primi gli stessi gusti del nostro, poi li si tiene sotto osservazione per intercettare il momento in cui compiranno un’azione che si consideri indicativa (e relativo elemento coinvolto). In questo modo è possibile costruire anche degli strumenti push, ovvero degli alert cui l’utente si può iscrivere affinché gli notifichino l’esistenza di qualcosa potenzialmente interessante (nel momento stesso in cui il trend-setter ha effettuato l’azione sotto osservazione).

2. Pesi diversi (o mutevoli) per i diversi parametri di giudizio.

Ogni elemento è caratterizzato da ben più di un attributo, ognuno dei quali possiede diversi livelli d’importanza per l’utente. Non solo: questo diverso peso varia di momento in momento e di elemento in elemento. Se l’utente ha valutato positivamente un filmato sulle ultime elezioni politiche, quali sono gli attributi di quel filmato che hanno pesato sul giudizio? La regia? L’argomento? La realizzazione tecnica? Il fascino del commentatore? E questi attributi possono essere utilizzati eventualmente per proporre elementi di contenuto simile ma di formato diverso dal filmato?

Questo problema è di difficile soluzione.
E’ possibile affrontarlo, anche se grossolanamente, in quei casi in cui vi è una ciclicità dell’offerta (ad esempio, le diverse collezioni di moda): istanziando un diverso motore per ogni stagione si evita quantomeno di considerare allo stesso modo i comportamenti tenuti su prodotti molto diversi tra di loro.
Allo stesso modo si possono istanziare motori diversi per formati diversi: l’utente può voler leggere di politica ma non vederne immagine satiriche (o viceversa); l’utente può voler vedere filmati sulle azioni sportive più spettacolari ma non essere interessato ad articoli che ne parlano diffusamente.

3. Più di un solo obiettivo.

Un utente può utilizzare lo stesso sito/strumento per adempiere ai compiti più diversi. Un esempio molto banale è l’acquisto di un libro: un giorno lo può intraprendere per sé stesso, il giorno dopo per fare un regalo ad una persona dotata di gusti molto differeinti dai propri.
Il tracciamento dei gusti di un utente che tenga condo di comportamenti quali la navigazione, l’acquisto o la ricerca (Recommendation Engine fortemente personalizzato) fatica a tenere in considerazione questa differenza. E’ opportuno in questi casi limitarsi a tenere in considerazione quelle azioni dell’utente che ne esplicitano l’interesse (la votazione di un libro letto, ad esempio): tuttavia anche l’espressione di un interesse può essere suddivisa in un interesse di tipo professionale, hobbistico, temporaneo o ancora molto altro.

4. Elementi non predicibili.

Esistono elementi che vengono amati oppure odiati: non vi sono vie di mezzo. Questi elementi sono difficili da suggerire o valutare poiché la reazione degli utenti tende ad essere impredicibile.

Gli elementi polarizzatori possono essere identificati calcolando la quantità dei voti intermedi ricevuti: se questa non supera una certa soglia percentuale l’elemento è marcato come “polarizzatore”; successivamente si identificano quegli utenti che hanno votato positivamente almeno un elemento polarizzatore votato positivamente dal nostro utente X. A questo punto è possibile proporgli gli altri elementi polarizzatori votati da quell’insieme di utenti.

Gli utenti polarizzatori possono essere identificati cercando se hanno votato positivamente elementi privi di relazioni tra di loro, ovvero appartenenti a due cluster molto diversi (Metallica e Masini, per dire); il sistema istituisce una relazione tra gli elementi dei due insiemi discordanti (conservando l’informazione del cluster), così che se più di un elemento di un cluster viene relazionato a uno (o più) di un elemento di un secondo cluster, è possibile proporre questi elementi a quegli utenti che ad esempio votano per un elemento del cluster “insospettabile”. “Lo sappiamo che potrebbe sembrarti strano, ma potrebbero piacerti anche questi elementi“.

La distinzione vista sopra a proposito di strumenti che personalizzano e strumenti che non personalizzano si riflette anche nelle due principali categorie di Recommendation Engine:

– Collaborative Filtering (“Gli utenti che hanno comprato questo elemento hanno comprato anche X”: Amazon, per intenderci). Si veda alla pagina http://it.wikipedia.org/wiki/Collaborative_filtering

– Basket Affinity Grouping (“Elementi che condividono tra di loro il maggior numero di caratteristiche”). Si veda alla pagina http://it.wikipedia.org/wiki/Clustering

Si noti che il primo algoritmo va spesso integrato con il secondo. Si pensi ad esempio di utilizzare un Collaborative Filtering; non appena un elemento viene introdotto nel catalogo nessun utente ha ancora avuto modo di esprimere il proprio interessamento per esso, e quindi questo non viene mai suggerito a nessuno (pur essendo, potenzialmente, di forte interesse per chi cerca le novità); si parla in questo caso di “cold-start-problem”.

La soluzione consiste nell’individuare, di ogni elemento, il cluster cui esso appartiene (per similarità di caratteristiche) e di fare quindi un confronto tra cluster, non tra elementi. L’algoritmo potrebbe essere descritto in questo modo: “Trova gli elementi/utenti che sono stati [AZIONE_SOTTO_ANALISI] da quegli utenti che hanno compiuto le stesse azioni del nostro utente X sugli stessi gruppi di elementi/utenti”.

La prossima settimana vediamo come costruire uno strumento molto basilare per ottenere un clustering di elementi (Basket Affinity Grouping) mediante poche righe di codice PHP e un DataBase MySQL. La similarità verrà calcolata su un elenco destrutturato di caratteristiche: ovvero, sulla base dei tag che descrivono ognuno degli elementi del catalogo.