Collaborative Filtering for Recommender Systems
Recommending without understanding
Here's a strange fact: Netflix can recommend you a movie without having any idea what the movie is about. No genre tags, no plot summary, no actor list required. Collaborative filtering works entirely from the pattern of who-liked-what — it finds people whose taste overlaps with yours, or items that tend to be liked by the same people, and uses that overlap alone to make predictions.
The core assumption: if people who behaved like you in the past liked something you haven't seen, you'll probably like it too. No content understanding needed — just interaction data: ratings, purchases, clicks, watch time.
User-based collaborative filtering
User-based filtering finds users similar to you and recommends what they liked. The process:
1. Build a user-item matrix where rows are users, columns are items, and cells are ratings (or implicit signals like "watched" / "not watched").
2. For a target user, compute similarity (typically cosine similarity or Pearson correlation) to every other user, based on overlapping rated items.
3. Take the k most similar users (the "neighborhood").
4. Predict the target user's rating for an unseen item as a similarity-weighted average of that neighborhood's ratings for that item.
5. Recommend the highest-predicted items the user hasn't already interacted with.
The intuition: if you and another user both loved the same five obscure films, your remaining preferences probably correlate too.
Item-based collaborative filtering
Item-based filtering flips the question: instead of "which users are similar to me," it asks "which items are similar to the ones I already liked." Two items are considered similar if they tend to be rated similarly by the same users — not because of their content, but because of co-rating patterns.
Amazon popularized this approach because item-item similarities are far more stable than user-user similarities: a product's relationship to other products doesn't change as users come and go, whereas a user's taste profile shifts constantly and the user base itself can be orders of magnitude larger than the catalog. Precomputing and caching an item-item similarity matrix is cheaper to maintain and refresh than a user-user matrix at Amazon's scale.
Note
User-based vs. item-based collaborative filtering
| Dimension | User-based | Item-based |
|---|---|---|
| Similarity computed between | Users | Items |
| Stability over time | Low — user tastes drift | High — item relationships are stable |
| Scalability | Poor when #users >> #items | Better when catalog is smaller than user base |
| Precomputable offline | Harder (user matrix changes fast) | Yes — Amazon-style cached similarity tables |
| Explainability | "Users like you also liked..." | "Because you liked X..." |
Note
Practical considerations
Implicit vs. explicit feedback. Explicit ratings (1-5 stars) are rare in practice — most signal comes from implicit feedback: clicks, watch time, purchases, dwell time. These need to be converted into confidence-weighted preference signals rather than treated as literal ratings.
Scalability. Computing full similarity matrices is O(n²) in users or items. Production systems use approximate nearest neighbor search (e.g. FAISS, Annoy) or precomputed offline batch jobs refreshed periodically rather than real-time full recomputation.
Popularity bias. Collaborative filtering tends to over-recommend already-popular items because they have the most interaction data, which can create a feedback loop that starves the long tail of exposure.
What's next
User-based and item-based filtering compute similarity directly from the raw ratings matrix, which becomes computationally expensive and sparse at scale. Matrix Factorization for Recommender Systems solves this by learning compact latent factors for every user and item — the technique that famously won the million-dollar Netflix Prize.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.