What is the difference between user-based and item-based collaborative filtering?
answer
- one matrix, two directions
- neighbours of a person or of a thing
- similarity-weighted average of observed ratings
- the catalog moves slower than the audience
basics
~20 sUser-based collaborative filtering finds people whose ratings resemble yours and recommends what they liked. Item-based finds items rated similarly to ones you already liked. Same rating matrix, but similarity is computed between rows instead of between columns.
solid answer
~50 sBoth work off the same user-by-item rating matrix; they differ in which axis the neighbourhoods are built on. User-based CF compares my rating row against other users' rows over the items we both rated, takes the top-k most similar users who have rated the target item, and predicts my rating as my own average plus their similarity-weighted deviations: `pred(u,i) = mean_u + sum(sim(u,v) * (r_vi - mean_v)) / sum(|sim(u,v)|)`. Item-based CF instead compares item columns over the users who rated both items, then scores a candidate item by how similar it is to the items I have already rated, weighting those ratings by similarity. Transposing the matrix turns one into the other. In production item-based usually wins: an item's column accumulates ratings from thousands of people, so its neighbour list barely moves and can be precomputed offline, and "because you rated X" is a natural explanation to show.
go deeper
Be ready to state both directions in one breath: user-based compares rows of the rating matrix, item-based compares columns, and both predict with a similarity-weighted average over a small set of neighbours.
Explain the prediction formula out loud, including why deviations from each rater's mean are used and why the denominator sums absolute similarities. Note that item-based is user-based on the transposed matrix.
Show the operational reasoning: which axis is more stable, what can be precomputed offline versus what must be read at request time, and how new ratings reach the user's recommendations without a rebuild.
Own the framing that neither choice is a rule. Argue it from the data — relative churn of catalog versus audience, the size of the neighbour table you must keep warm, and whether the product needs a displayable reason for each suggestion.
## The shared setup Both methods start from one object: a rating matrix with users as rows, items as columns, and a value only where a user actually rated an item. It is extremely sparse — in a bookstore community with 500,000 titles, a keen reader might have rated 80 of them, so well over 99.9% of the cells are empty. Neighbourhood methods make a single prediction rule out of this: **an empty cell is filled with a similarity-weighted average of nearby observed cells.** The only design choice is what "nearby" means, and there are two answers. ## User-based collaborative filtering 1. Represent user `u` by their row of ratings. 2. Compute a similarity between `u` and every other user, using only the items the pair both rated (their co-rated set). 3. Keep the `k` most similar users who have actually rated the target item `i` — a neighbour who never rated `i` contributes nothing. 4. Predict: ``` pred(u,i) = mean_u + sum_v sim(u,v) * (r_vi - mean_v) / sum_v |sim(u,v)| ``` The deviations `(r_vi - mean_v)` rather than raw ratings matter because different people use the star scale differently; adding back `mean_u` puts the answer on this user's own scale. The absolute value in the denominator keeps a negatively similar neighbour (someone whose taste is the reverse of yours) from flipping the sign of the whole estimate. ## Item-based collaborative filtering 1. Represent item `i` by its column of ratings. 2. Compute similarity between item pairs over the users who rated **both** items. 3. For a target item `i` and user `u`, take the `k` items `u` has already rated that are most similar to `i`. 4. Predict a similarity-weighted average of `u`'s own ratings on those neighbours: ``` pred(u,i) = sum_j sim(i,j) * r_uj / sum_j |sim(i,j)| ``` A mean-centred variant subtracts each item's or the user's mean before averaging and adds it back afterwards, for the same reason as above. ## Same data, different axis Algorithmically, item-based CF is user-based CF run on the transposed matrix. Both need co-rating overlap to say anything, both fail completely for a row or column with no data, and both aggregate over a truncated top-k neighbourhood rather than everybody. What differs is the consequences. **Size of the similarity table.** You must maintain a pairwise table over whichever axis you chose — quadratic in the number of users, or quadratic in the number of items. A catalog of 500,000 titles and 30 million readers gives wildly different bills for the two options, and which is smaller depends entirely on the product. **Stability.** A popular title's column holds ratings from tens of thousands of readers, so one more rating shifts its similarities by a negligible amount. A user's row may double in a single evening of activity. Item similarities are therefore a slow-changing asset you can compute on a schedule; user similarities go stale almost immediately. **Serving.** Because the item neighbour table is static between rebuilds, item-based scoring at request time needs only the user's own list of rated items — which you can read fresh, including the rating they gave thirty seconds ago. That gives instant personalisation without touching the similarity computation. User-based serving needs the requesting user's similarities to other users, which is precisely the thing that just went stale. **Explainability.** "Readers who rated this also rated…" is a sentence you can put in the interface, and it points at an item the user already knows they rated. "Users similar to you liked this" is both vaguer and more uncomfortable to display. **Failure modes they share.** Neither can score for a user with no ratings or an item nobody has rated. Neither is content-aware: an item's similarity comes entirely from who rated it, never from its description, genre or price. And on very sparse data, both fill their neighbour lists with pairs whose similarity was estimated from a handful of overlapping ratings. ## Choosing Ask which axis is more stable, which is smaller, and which supports the explanation you want to show. Catalogs that change slowly relative to the audience — books, films, board games — favour item-based. A system where the item set churns hourly but the user base is stable and small can genuinely favour user-based. It is not a universal law, and an interviewer will be pleased if you frame it as a property of the data rather than a rule.
- Once you have the neighbours, how is the predicted rating actually computed?As a similarity-weighted average, not a plain one. In user-based form: take each neighbour's rating of the target item, subtract that neighbour's own mean rating, weight by the similarity, divide by the sum of absolute similarities, and add the target user's mean back. Item-based is the mirror image over the user's already-rated items. Using absolute values in the denominator stops a negatively-similar neighbour from inverting the estimate.
- Why do production recommenders more often maintain item-item neighbour tables?Because item similarities are stable. An established title's rating column already holds thousands of ratings, so a new one barely moves its neighbours, and the table can be rebuilt on a schedule and served from cache. A user's profile can change materially in one session. Item-based scoring also only needs the user's own rated items at request time, so new ratings personalise instantly without recomputing any similarity.
- Can either form explain its recommendation to the user?Item-based can, cleanly: the neighbours driving the score are items this user rated themselves, so you can show "suggested because you rated X and Y highly". User-based explanations rest on anonymous strangers, which is vaguer and often a privacy problem — you cannot name who the similar users were. This explainability advantage is a real reason teams choose item-based even when both perform comparably.
User-based CF asks your friends what to read. Item-based CF asks the librarian what usually sits next to the book you just enjoyed.
saying these in an interview costs you the question
- Says item-based means comparing item descriptions or genres
- Thinks both approaches always produce the same recommendations
- Describes the prediction as a plain average of neighbour ratings
- Claims item-based needs no rating data at all
- Assumes there are always fewer items than users