Polyvalent Recommendations

1©MapR Technologies - Confidential
Polyvalent Recommendations

Multiple Kinds of Behavior
for Recommending
Multiple Kinds of Things

 Contact:
– tdunning@maprtech.com
– @ted_dunning
– @apachemahout
– @user-subscribe@mahout.apache.org
 Slides and such (available late tonight):
– http://www.slideshare.net/tdunning
 Hash tags: #mapr #recommendations

A new approach to recommendation, polyvalent recommendation,
that is both simpler and much more powerful than traditional
approaches. The idea is that you can combine user, item and content
recommendations into a single query that you can implement using a
very simple architecture.

Recommendations
 Often known (inaccurately) as collaborative filtering
 Actors interact with items
– observe successful interaction
 We want to suggest additional successful interactions
 Observations inherently very sparse

Examples
 Customers buying books (Linden et al)
 Web visitors rating music (Shardanand and Maes) or movies
(Riedl, et al), (Netflix)
 Internet radio listeners not skipping songs (Musicmatch)
 Internet video watchers watching >30 s

Dyadic Structure
 Functional
– Interaction: actor -> item*
 Relational
– Interaction ⊆ Actors x Items
 Matrix
– Rows indexed by actor, columns by item
– Value is count of interactions
 Predict missing observations

Recommendation Basics
 History:
User Thing
1 3
2 4
3 4
2 3
3 2
1 1
2 1

 History as matrix:
 (t1, t2) cooccur 2 times, (t1, t4) once, (t2, t4) once
t1 t2 t3 t4
u1 1 0 1 0
u2 1 0 1 1
u3 0 1 0 1

A Quick Simplification
 Users who do h
 Also do r
Ah
AT
Ah( )
AT
A( )h
User-centric recommendations
Item-centric recommendations

 Coocurrence
t1 t2 t3 t4
t1 2 0 2 1
t2 0 1 0 1
t3 2 0 1 1
t4 1 1 1 2

Problems with Raw Cooccurrence
 Very popular items co-occur with everything
– Welcome document
– Elevator music
 That isn’t interesting
– We want anomalous cooccurrence

 Coocurrence
t1 t2 t3 t4
t1 2 0 2 1
t2 0 1 0 1
t3 2 0 1 1
t4 1 1 1 2
t3 not t3
t1 2 1
not t1 1 1

Root LLR Details
 In R
entropy = function(k) {
-sum(k*log((k==0)+(k/sum(k))))
}
rootLLr = function(k) {
sqrt(
(entropy(rowSums(k))+entropy(colSums(k))
- entropy(k))/2)
}
 Like sqrt(mutual information * N/2)

Spot the Anomaly
 Root LLR is roughly like standard deviations
A not A
B 13 1000
not B 1000 100,000
A not A
B 1 0
not B 0 2
A not A
B 1 0
not B 0 10,000
A not A
B 10 0
not B 0 100,000
0.44 0.98
2.26 7.15

Threshold by Score
 Coocurrence
t1 t2 t3 t4
t1 2 0 2 1
t2 0 1 0 1
t3 2 0 1 1
t4 1 1 1 2

Threshold by Score
 Significant cooccurrence => Indicators
t1 t2 t3 t4
t1 1 0 0 1
t2 0 1 0 1
t3 0 0 1 1
t4 1 0 0 1

Decomposition for Cooccurrence
 Can use SVD for cooccurrence
 But first one or two singular vectors just encode popularity …
ignore those
 VT projects items into concept space, V projects back into item
space
 Thresholding reconstructed cooccurrence matrix is another way to
get indicators
AT
A = USVT
( )
T
USVT
( )= VS2
VT

What’s right
about this?

Virtues of Current State of the Art
 Lots of well publicized history
– Netflix, Amazon, Overstock
 Lots of support
– Mahout, commercial offerings like Myrrix
 Lots of existing code
– Mahout, commercial codes
 Proven track record
 Well socialized solution

What’s wrong
about this?

Cross Occurrence
 We don’t have to do co-occurrence
 We can do cross-occurrence
 Result is cross-recommendation

Fundamental Algorithmics
 Cooccurrence
 A is users x items, K is items x items
 Product has general shape of matrix
 K tells us “users who interacted with x also interacted with y”
K = AT
A

Fundamental Algorithmic Structure
 Cooccurrence
 Matrix approximation by factoring
 LLR
K = AT
A
A » USVT
K » VS2
VT
r = VS2
VT
h
r =sparsify(AT
A)h

But Wait ...
Does it have to be that way?

But why not ...
Why just dyadic learning?
Why not triadic learning?Why not cross learning?
AT
A( )hBT
A( )h

For example
 Users enter queries (A)
– (actor = user, item=query)
 Users view videos (B)
– (actor = user, item=video)
 A’A gives query recommendation
– “did you mean to ask for”
 B’B gives video recommendation
– “you might like these videos”

The punch-line
 B’A recommends videos in response to a query
– (isn’t that a search engine?)
– (not quite, it doesn’t look at content or meta-data)

Real-life example
 Query: “Paco de Lucia”
 Conventional meta-data search results:
– “hombres del paco” times 400
– not much else
 Recommendation based search:
– Flamenco guitar and dancers
– Spanish and classical guitar
– Van Halen doing a classical/flamenco riff

Real-life example

Hypothetical Example
 Want a navigational ontology?
 Just put labels on a web page with traffic
– This gives A = users x label clicks
 Remember viewing history
– This gives B = users x items
 Cross recommend
– B’A = label to item mapping
 After several users click, results are whatever users think they
should be

But wait,
there’s more!

Ausers
things

A1 A2
é
ë
ù
û
users
thing
type 1
thing
type 2

A1 A2
é
ë
ù
û
T
B1 B2
é
ë
ù
û=
A1
T
A2
T
é
ë
ê
ê
ù
û
ú
ú
B1 B2
é
ë
ù
û
=
A1
T
B1 A1
T
B2
A2B1 A2B2
é
ë
ê
ê
ù
û
ú
ú
r1
r2
é
ë
ê
ê
ù
û
ú
ú
=
A1
T
B1 A1
T
B2
A2B1 A2B2
é
ë
ê
ê
ù
û
ú
ú
h1
h2
é
ë
ê
ê
ù
û
ú
ú
r1 = A1
T
B1 A1
T
B2
é
ëê
ù
ûú
h1
h2
é
ë
ê
ê
ù
û
ú
ú

Summary
 Input: Multiple kinds of behavior on one set of things
 Output: Recommendations for one kind of behavior with a
different set of things
 Cross recommendation is a special case

Now again, without
the scary math

Input Data
 User transactions
– user id, merchant id
– SIC code, amount
– Descriptions, cuisine, …
 Offer transactions
– user id, offer id
– vendor id, merchant id’s,
– offers, views, accepts

Input Data
 User transactions
– user id, merchant id
– SIC code, amount
– Descriptions, cuisine, …
 Offer transactions
– user id, offer id
– vendor id, merchant id’s,
– offers, views, accepts
 Derived user data
– merchant id’s
– anomalous descriptor terms
– offer & vendor id’s
 Derived merchant data
– local top40
– SIC code
– vendor code
– amount distribution

Cross-recommendation
 Per merchant indicators
– merchant id’s
– chain id’s
– SIC codes
– indicator terms from text
– offer vendor id’s
 Computed by finding anomalous (indicator => merchant) rates

Search-based Recommendations
 Sample document
– Merchant Id
– Field for text description
– Phone
– Address
– Location

 Sample document
– Merchant Id
– Phone
– Address
– Location
– Indicator merchant id’s
– Indicator industry (SIC) id’s
– Indicator offers
– Indicator text
– Local top40

 Sample document
– Merchant Id
– Phone
– Address
– Location
– Indicator merchant id’s
– Indicator industry (SIC) id’s
– Indicator offers
– Indicator text
– Local top40
 Sample query
– Current location
– Recent merchant descriptions
– Recent merchant id’s
– Recent SIC codes
– Recent accepted offers
– Local top40

SolR
Indexer
SolR
Indexer
Solr
indexing
Cooccurrence
(Mahout)
Item meta-
data
Index
shards
Complete
history

SolR
Indexer
SolR
Indexer
Solr
search
Web tier
Item meta-
data
Index
shards
User
history

Objective Results
 At a very large credit card company
 History is all transactions, all web interaction
 Processing time cut from 20 hours per day to 3
 Recommendation engine load time decreased from 8 hours to 3
minutes
 Recommendation quality increased visibly

 Contact:
– tdunning@maprtech.com
– @ted_dunning
 Slides and such (available late tonight):
– http://www.slideshare.net/tdunning
 Hash tags: #mapr #recommendations
 We are hiring!

Thank You

Polyvalent Recommendations

Recommandé

Recommandé

Contenu connexe

Similaire à Polyvalent Recommendations

Similaire à Polyvalent Recommendations (20)

Plus de MapR Technologies

Plus de MapR Technologies (20)

Dernier

Dernier (20)

Polyvalent Recommendations