This is part of our series on advice for building recommender systems. For additional recsys tips, check out this post on Bayesian estimation and logistic scaling.
Imagine you’ve built a recommender system and sent some sample results to a product manager for feedback. They make a list of recommendations they think are bad and send you an email back asking why products X, Y, and Z were recommended.
Which sounds easier to fix: 1) a matrix factorization model with hundreds of latent factors (saying “the latent factors were inauspicious for this user” isn’t going to cut it), or 2) a simple graph-based model, where every link between similar items or similar users can be directly traced back to actions that various users performed?
At Mortar, in most cases we use option 2: a simple graph-based model which is easy to integrate with each client’s domain-specific knowledge and needs. The goal of this post is to explain from a business perspective the two most salient advantages of graph-based models: flexibility and simplicity.
What does it mean for a recommender model to be flexible? There are tons of concerns the recommender might need to address: an ecommerce company like Overstock.com will have rolling inventory, so out-of-stock items shouldn’t be recommended; a media company like Netflix might want to favor more popular content (i.e. Parks and Recreation), or conversely increase the discoverability of high-rated but little-known items (i.e. Party Down, also featuring Adam Scott, before it was removed by spoilsport content-owners); or there might be a wealth of metadata on each item that needs to be seamlessly integrated with the collaborative filter.
All of these concerns can be addressed with a graph-based model simply by creating, removing, or adjusting edges on graphs that relate users-to-items, items-to-items, or users-to-users. And by expressing every domain-specific concern within the framework of the graphical model, you can account for these concerns without having to touch the code that takes a generic graph and outputs recommendations. In this way, graph-based models are modular and transparent.
Of course, given top-notch data scientists and a lot of time, you could build more mathematically sophisticated systems which can also address any of these concerns. The “given” clause in that sentence shows the problem with this approach though: [top notch data scientists] * [a lot of time] = [a ton of money].
If you are at Netflix’s financial scale, spending thousands of man-hours to improve some recommendation metric by a few percent can give a good return on your investment. But you probably aren’t yet making the hundreds of millions in revenue that they are. A complicated model could take several quarters to get into production; whereas a simple graph-based model will allow you to build a viable recommender system for your product without delaying its time-to-market.
Lastly, using a simple model makes it so much easier for data scientists, engineers, product managers, and UI/UX designers to work together. Graphs can be visualized, explained, discussed, and debugged collaboratively in a way that sophisticated machine learning techniques cannot. A model that everyone who has a stake in a product can help improve will have a better chance of addressing the actual needs of your business than a black box understood only by one or two data scientists. For every percent increase in some measure of recommender quality that more math can produce, there is much more potential improvement to be found in discovering new concerns and objectives that are unique to your business, in designing innovative user interfaces, and in integrating editorial input.
For example: despite there being a multitude of ways to get automated recommendations of TV shows, I still base 80% of my TV viewing choices on Alan Sepinwall’s TV blog. Why? Because the blog gives a narrative, not just a rating, for each of its recommendations. Watching TV, reading a book, buying a product: all involve an investment on the part of the consumer, and just because one is interested in an item doesn’t necessarily mean one will invest in it. This is especially true if the item is outside the sphere of things one is usually interested in. Well-written natural language and editorial voice can effectively push one to invest oneself in new things. They can change user behavior, not just reinforce it.
How does this relate to graphs? Again, it is about the flexibility to handle changing business needs. My opinion is that the next big advances to be made in recommender systems will be made by combining automated tools with human—possibly crowdsourced—editorial judgement and writing talent. They will be made in finding more engaging ways to present recommendations to users than cloying sidebars and endlessly scrolling lists.
I don’t know exactly what these more engaging ways will be. But when someone thinks up of them, I’m confident as a data scientist and an engineer that it will be much easier to adapt a graph-based recommender system to these unexpected new use cases than it would be to adapt any complex machine-learning technique.