Pursuing The Ideal Recommender

MULTIMODAL REALTIME RECOMMENDATIONS

RECOMMENDATIONS:REQUIRED

• Netflix—80% of video views

• Amazon—60% of sales

• Yahoo News—40% increase in TOS

• Search for “leather laptop bag”

• Hmm, some are ok but not quite right

• Put some in “wishlist”

• Look at recommendations

• Add and remove as you like… …things improve!

• Never knew I wanted a “Messenger bag with a leather strap”

• Didn’t know what one was so would never have searched for it

RECOMMENDATIONS CAN DO WHAT SEARCH CANNOT

TOWARDS THE IDEAL MULTIMODAL RECOMMENDER• Any number of user actions—entire user clickstream

• Metadata—from user profile or item

• Context—realtime and possible anonymous: device, referrer, location

• Content—unstructured text, tags, categories

• Personalizes recommendations even when content-based

• Mixes any number of “indicators” to increase quality or tune to specific context

• Solves the “cold-start” problem—items with too short a lifespan or new users

• Can recommend to new users in realtime

• Can use new interaction data from any user in realtime

• Can auto-detect and “micro-segment” new anonymous users

THE GOOD NEWS

• 90% of these features come from 3 technologies• Search engine (Solr, Elasticsearch)

• Mahout

• Spark

• 90% of the flexibility comes at runtime via query—not from new analytical models.

Accounting for all the data

AND NOW FOR A LITTLE MATH

ANATOMY OF A RECOMMENDATIONr = recommendationshp = a user’s history of some primary action (purchase for instance)P = the history of all users’ primary action rows are users, columns are items[PtP] = compares column to column using log-likelihood based cooccurrence

r = hp[PtP]

THE UNIVERSAL RECOMMENDER• Virtually all existing collaborative filtering type

recommenders use only one indicator of preference—one action

• But the theory doesn’t stop there

• Virtually all user actions can be used to improve recommendations—purchase, view, category view…

r = hp[PtP]

r = hp[PtP] + hv[PtV] + hc[PtC] + …

AN LLR COOCCURRENCE INDICATOR

• [PtP] is an indicator matrix for some primary action like purchase• Rows = users, columns = items, boolean data

• Compares cooccurring interactions using the log-likelihood ratio—column-wise similarity

• LLR finds important cooccurrences and filters out the coincidental#

• Down-sampling (users and items in the input) leads to much less data to process but very little quality loss so the calculation is fast* and stays O(n)

# http://tdunning.blogspot.com/2008/03/surprise-and-coincidence.html* http://ssc.io/wp-content/uploads/2011/12/rec11-schelter.pdf

CROSS-COOCCURRENCE INDICATORShi = a user’s history of an actionP, V, C = the history of all users’ history of some

action (purchase, view, category view)[PtX] = the pairwise comparison of column to column—comparison may be across two actions but is always anchored by primary

r = hp[PtP] + hv[PtV] + hc[PtC] + …

CROSS-COOCCURRENCE SO WHAT?• Comparing the history of the primary action to

other actions finds actions that lead to the one you want to recommend

• The entire user’s clickstream can be used• Purchases• Items clicked• Terms searched• Categories viewed• Items shared• People followed• Items liked or disliked• Videos watched• Locations• Items shared• …

FROM INDICATOR TO RECOMMENDATION

• This actually means to take the user’s history hp and compare it to rows of the indicator matrix [PtP] (created with Mahout)

• TF-IDF weighting of indicators would be nice to mitigate popular items

• Query the indicator with user history—a string vector

• Rank the results by strength of similarity—you have recommendations

• Sound familiar?

r = hp[PtP]

FROM INDICATOR TO RECOMMENDATION

• This actually means to take the user’s history hp and compare it to rows of the indicator matrix [PtP] (created with Mahout)

• TF-IDF weighting of indicators would be nice to mitigate popular items

• Query the indicator with user history—a string vector

• Rank the results by strength of similarity—you have recommendations

• Sound familiar?

• That is exactly what a search engine does!

r = hp[PtP]

INDICATOR TYPES• Cooccurrence and cross-cooccurrence

• Calculated from user actions as discussed

• Create with Mahout spark-itemsimilarity

• Content or metadata• Tags, categories, description text, anything describing an item

• Create with Mahout spark-rowsimilarity

• Intrinsic• Tags, genres, categories, popularity rank, geo-location,

anything describing an item

• Some may be derived from usage data like popularity rank, or hotness

• These are known or specially calculated properties of the item

CONTENT INDICATORS

• Finds similar items based on their content—not which users

preferred them

• Examples: text, tags, categories, genres

r = recommended items, based on tags

ht = a user’s history of items preferred (not tags)

T = rows are (items, list-of-tags-for item)

[TTt] = rows are (item, similar-items-based-on-similar-tags)—these are content indicators

• This personalizes content based recommendations

r = ht[T Tt]

INTRINSIC INDICATORS• Attributes of items

• Genre, subject, category, tags

• Specially calculated based on business rules• Popularity, hotness

• Based on demographics• Preferred by people using mobile access

• Preferred by city dwellers

• Preferred by people in warmer climes

• Query by value—not user history

r = v*I

THE UNIVERSAL RECOMMENDER“Universal” means one query on all indicators at once

Unified query: purchase-indicator: users-history-of-purchases view-indicator: users-history-of-views category-indicator: users-history-of-categories-viewed tags-indicator: users-history-of-purchases geo-location-indicator: users-location-history …

r = hp[PtP] + hv[PtV] + hc[PtC] + ht[TTt] + l*L …

ONE OR MANY• One query—one trip to one scalable

search engine

• Many flavors—customize in the query• Customize for content context

• Customize for user context• Profile, location, time, …

• Customize for special indicators• Trending, hot, new, popular

• All personalized

RECOMMENDER DATA

user-id

purchase-history

view-history

category-history

location-history

user-1 item-purchase-list

item-view-list

category-list

location-list

user-2 item-purchase-list

item-view-list

category-list

location-list

… item-purchase-list

item-view-list

category-list

location-list

USER COLLECTION

item-id

purchase-indicators

view-indicators

category-indicators

location-indicators

category

item-availability

item-1 item-purchase-indicators

item-view-indicators

category-indicators

location-indicators

category-list

availability-list

item-2 item-purchase-indicators

item-view-indicators

category-indicators

location-indicators

category-list

availability-list

… item-purchase-indicators

item-view-indicators

category-indicators

location-indicators

category-list

availability-list

ITEM COLLECTION

USER CONTEXTuser-id

current geo location

device

location on-site

referrer url

membership

…

PERSISTENT REALTIME

ANATOMY OF A QUERY

• User history- actions like those used to create cooccurrence indicators

• User profile- what do we know about the user

• User context- location, device, location on site, referrer, time of day, day of week, month of year, …

• Field- target of query data- for instance: user purchase history purchase indicator field of item collection

• Bias- a boost applied to a field query- for instance: current-category item category field^10 of item collection- returns recs but favoring ones from current category

• Filter- AND applied to field query- for instance: AND current-category item category field of item collection- returns recs filtered by current category

DATA STRUCTURE

EXAMPLE RECOMMENDATION PLACEMENTS

REQUIREMENT QUERY EXAMPLE

Home (personalized)

purchase-indicator: items-user-purchasedwish-list-indicator: items-user-wish-listeditems-liked-indicator: items-user-likeditems-disliked-indicator: items-user-dislikedall history and context available…

Item detail screen(more-like-this non-personalized)note: the query uses data from the item indicators

purchase-indicator: purchace-indicator-of-item-being-viewedwish-list-indicator: wish-list-indicator-of-item-being-viewedcategory: categories-of-item-being-viewed^boost (bias)tags: tags-of-item-being-viewed

Category home screen purchase-indicator: items-user-purchasedwish-list-indicator: items-user-wish-listeditems-liked-indicator: items-user-likedcategory: category-of-screen^boost (bias) alternitivelyAND category: category-of-screen (filter)

Article screen(content-based)

tags-inditator: articles-viewed-by-user

Home screen(anonymous user)note: uses “micro-segmentation” as well as trending to mitigate cold-start for new user.

location-indicators: user-locationreferrer-indicators: user-referrertime-of-day-indicators: time-of-daydevice-indicator: user-devicetrending-indicator: “hot”

RECOMMENDATIONS WITH MIX-INS

REQUIREMENT QUERY EXAMPLE

Mix-in collections(promotions, popular, etc)

purchase-indicator: items-user-purchasedwish-list-indicator: items-in-user-wishlistitems-liked-indicator: items-user-likedall history and context available…promoted-indicator: promotion-type^boost (bias)popularity-indicator: “hot”

This means we show promoted items that the user may actually prefer but a high enough boost will guarantee some promoted items are shown regardless.

This will cause popular items to be recommended along with personalized recs. If the user has no history this will still return recs

POLISH THE APPLE:OTHER HELPFUL TECHNIQUES• Dithering for auto-optimize via explore-exploit (important):

Randomize the ranking of some returned recs, if they are acted upon they become part of the new training data and are more likely to be recommended in the future

• Visibility control:• Don’t show dups or show dups at some rate

• Filter items the user has already seen

• Generate some intrinsic indicators like hotness, popularity—helps solve the “cold-start” problem

• Asymmetric train vs query management—for instance query with most recent actions, train on all ingested

• On-demand cross-validation scoring for tuning purposes

• A/B testing integration with Bayesian-Bandit sampling

Architecture Overview

THE MULTIMODAL STREAMING

RECOMMENDER

STREAMINGEVERGREENINDEX GENERATION

LAMBDA ARCHITECTURE

Web Server

Web Server

Internet

Kafka cluster

server logs or other action messages

micro-batcheduser actions

ACTION PROCESSING

realtime background

indicators

log entries

periodically batchedindicators

RecommendationsServer

Backing store:

HDFS or Database

query:user-actions

query:recommendations

Spark clusterstreaming ActionMiner

Spark cluster Periodic IndicatorGenerator

Solr or Elasticsearch

Server

STREAMING ARCHITECTURE

Search EngineWith Recommender API

ActionMiner• Application specific• Near realtime

log entries

recs query

recommendations

IndicatorGenerator• Generalized• Periodically recurring• Based on Spark Mahout

user actions indicators

item metadata

Recalculated on time window as often as resources allow

Near realtime

action DStreams

Time Window 1

Time Window 2

Time Window 3

Time Window 4

Time Window 5

STREAMING INTERACTIONS

Time Window 6

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

chna

no-b

atch

nano

-bat

ch

Update Period

Update Period

Update Period

Update Period

Update Period

Time

…

THE STREAMING ARCHITECTURE: TUNING• Time Window: should be wide enough to get lots of overlap between users

• for long lived items a wide time window may work best

• for items with a short lifetime, add in data from long lived things—like category, or tag preferences so a longer Time Window makes sense

• Update Period: small enough to get all new items into the training data• if there are very frequent catalog updates, shorten this to match

• if there infrequent catalog updates there may be no reason to make this very short

• Nano Batch Period: as close to realtime as possible—insures the level of recent user intent• the user’s history is updated at this frequency so if near realtime reaction to user

actions is needed shorten this. With Spark Streaming and Kafka the practical limit is about 1 second.

• Note: the user’s history may include actions that are not in the training data—they can even be gathered in realtime and recommendations will reflect this recency of user intent.

• Nano Batches may be archived but leaving them in the Spark Streaming Dstream that they arrive in will decrease model build time.