ML Handbook

Theme

Recommender Systems

Quick overview Starting from user-item interactions, this article systematically covers collaborative filtering and matrix factorization (SVD/SVD++) to the industry's "recall → ranking → re-ranking" three-stage architecture, and provides evaluation metrics, cold start, exploration-exploitation, and complete surprise code.

Recommender Systems ​

One-line definition: a recommender system is a software system that learns user interest patterns from historical interactions between users and items, and automatically filters, ranks, and presents the items most likely to be liked by the user from a massive candidate pool. It is one of the most widely deployed and commercially valuable scenarios for machine learning in the internet industry — Netflix claims about 80% of its viewing time comes from recommendations, and YouTube's recommendation system directly influences billions of users' content consumption annually.

The essence of the recommendation problem isn't "predicting a number," but "giving the right item, in the right order, to the right person, at the right time." This hands-on article follows a main thread from classics to modern: first define the problem, then thoroughly explain collaborative filtering and matrix factorization (the two generations of classic methods), then dissect the industry's current "recall → ranking → re-ranking" three-stage architecture, and finally land on evaluation, cold start, exploration-exploitation, and runnable code. Before reading, it's recommended to first browse What is Machine Learning and Model Evaluation and Validation to build a framework.

1. The Recommendation Problem: Definition and Formalization ​

1. The user-item interaction matrix ​

Everything in a recommender system's data can be compressed into a user-item interaction matrix: rows are users, columns are items, and cells are the interactions between them. This matrix has two forms:

               Item1  Item2  Item3  Item4  Item5
   UserA         5      ?      4      ?      2
   UserB         ?      3      ?      5      ?
   UserC         4      ?      ?      1      3
   UserD         ?      ?      2      ?      4

   ? = unobserved interactions (user hasn't seen them, or has seen them but left no trace)

This matrix has two decisive statistical characteristics, which are the starting point of the entire recommender system technology stack:

  • Sparsity: observable interactions make up only a tiny fraction of all potential interactions. The density of the MovieLens 10M dataset is only about 1%; for real e-commerce platforms, this ratio is often 10⁻⁴ or even lower. What we truly need to do is infer a massive number of unobserved values from a few observations — precisely what machine learning excels at.
  • Uncertainty: a cell's value is just "some feedback that user had on this item," not the user's true inner rating. An explicit score might be 5 stars, but whether the user truly likes the item after opening the recommendation page is another question.

2. Explicit vs. implicit feedback ​

Interaction data falls into two categories by how "explicitly" the feedback is expressed:

TypeFormExamplesCharacteristics
Explicit feedbackPreferences the user actively expressesStar ratings, likes, favorites, dislikesStrong signal, clear semantics; but expensive to collect, data is sparse, and subject to rating bias (most people only rate items they like)
Implicit feedbackTraces left by behaviorClicks, browsing duration, plays, purchases, sharesMassive quantity, near-zero cost; but only positive signals are observable ("not clicking" ≠ "disliking," it might just mean they didn't see it), noisy, and reflects "accessibility" rather than pure preference

This distinction profoundly affects modeling. For explicit feedback, you can directly do "rating prediction"; for implicit feedback, the mainstream approach is binarize the behavior (interaction = 1, no interaction = 0, then weight), or use behavior intensity like viewing duration or purchase amount as confidence. The ALS-WR method proposed by Hu, Koren, and Volinsky in 2008 (see references) is a matrix factorization specifically designed for implicit feedback: it incorporates every "no-interaction" sample into training, just with very low confidence — this is the standard starting point for implicit feedback modeling.

3. Rating prediction vs. Top-N ranking ​

Recommendation tasks are often mistakenly treated as a regression problem, but they actually fall into two levels:

Task form A: Rating prediction
  Goal: estimate r̂ᵤᵢ as accurately as possible (what score would user u give item i?)
  Metrics: RMSE, MAE
  Perspective: minimize global error

Task form B: Top-N ranking (ranking / Top-N recommendation)
  Goal: produce a ranked list of length N for each user, maximizing user satisfaction
  Metrics: Recall@K, NDCG@K, AUC
  Perspective: maximize top-N ranking quality

These two objectives are not equivalent: a model that drives RMSE extremely low, guessing scores for every movie within a few points, might rank the user's most-wanted movie at position 5; while a model that "only cares about the top ranks" might have large score errors but an excellent recommendation experience. Real products (product feeds, content feeds, video feeds) are almost entirely Top-N ranking problems — users see a ranked list, not the model's output scores. This is why Section 5 separately covers ranking metrics.

4. Problem variants ​

Besides the classic two-dimensional matrix completion, recommender systems have several common variants:

  • Sequential recommendation: treat interactions as time series, predicting "the next item to watch" (session-based recommendation, Next-Item Recommendation).
  • Context-aware recommendation: incorporate time, location, device, weather into features.
  • Multi-objective recommendation: simultaneously optimize click-through rate, conversion rate, watch time, satisfaction, and other conflicting metrics.
  • Social/relational recommendation: use graph structures like friend relationships.

Most of these variants still build on the core "user × item match score" — the classic methods in the next two sections are the foundation for all variants.

2. Collaborative Filtering: The Classic "Like-minded People" ​

1. Core idea ​

Collaborative Filtering (CF) is the oldest and most central family of methods in recommender systems, with the 1994 GroupLens paper laying its foundational framework. Its idea can be summarized in one sentence:

Use the collective behavior of the group to predict individual preferences — you don't need to understand item content or user motivations; you only need "many people did similar things to you, so what they like is probably what you'll like too."

Collaborative filtering's inference loop:

  UserA likes {Item1, Item3, Item5}
  UserB likes {Item1, Item3, Item7}        ← highly similar to A
  Question: Will A like Item7?
  Inference: probably yes (B is similar to A, and B likes 7)

This is called "collaborative" filtering because prediction depends on collaborative signals between users, not on the items' own attributes. The contrasting content-based approach uses item attributes (movie genre, actors; article tags, word embeddings) to construct features, using only the user's own history without needing "other people's" data. The division of labor and fusion between these two is the norm in modern recommender systems.

2. User-based collaborative filtering (UserCF) ​

The algorithm has three steps:

① Similar users: for target user u, compute similarity between u and all other users based on interaction history, take the Top-K neighbors
② Candidate generation: collect items that neighbors have interacted with but u hasn't
③ Scoring and ranking: sum "neighbor's rating for the item × neighbor's similarity to u" weighted, rank, take top N

Prediction rating formula (using similarity weighting):

r̂ᵤᵢ = ( Σ_{v∈N(u)} sim(u,v) · rᵥᵢ ) / ( Σ_{v∈N(u)} |sim(u,v)| )

where N(u) is the set of user u's neighbors, sim(u,v) is user similarity. In practice, a mean-centered weighted version is more common: subtract each user's average rating first, then weight, to eliminate scoring scale biases ("some users habitually give high scores, others habitually give low scores").

3. Item-based collaborative filtering (ItemCF) ​

Flip the logic above: first compute how similar items are to each other (items consumed/rated by the same set of users are more similar), then recommend items similar to the user's historical items. Sarwar et al.'s 2001 paper systematically developed this method, which was then applied at large scale by Amazon and written up in the famous paper Amazon.com Recommendations: Item-to-Item Collaborative Filtering.

① Item similarity: sim(i,j) = number of users who interacted with both i and j / some normalization of users who interacted with i or j
② Candidate generation: for user u's historical item set H(u), find Top-K similar items for each item in H(u), take the union and deduplicate
③ Scoring and ranking: r̂ᵤᵢ = Σ_{j∈H(u)} sim(i,j) · rᵤⱼ, rank, take top N

ItemCF has an engineering advantage because "item similarity" becomes a static table that can be precomputed offline (similarity doesn't change per user). Online, you only need to look up the table and aggregate, without doing N full comparisons in real time. It also has strong interpretability — the sentence "because you watched Interstellar, we recommend Inception" can be shown directly to the user, which is crucial for building trust.

4. Similarity measures ​

Whether UserCF or ItemCF, "similarity" needs a quantitative definition. Three commonly used measures:

MeasureFormula (schematic)Characteristics
Cosine similaritycos(u,v) = (u·v)/(‖u‖·‖v‖)Only cares about direction, not scale; most commonly used for interaction vectors
Pearson correlation coefficientCompute cosine after subtracting the mean from each vectorEliminates scoring scale bias; more accurate for explicit ratings
Jaccard coefficientA∩B

An important engineering detail: similarity for items with fewer views is more valuable than for popular items. If two items are both watched by 10 million people, the similarity is artificially inflated but low in information content; if two items are both watched by only 50 people, and 40 people watched both, it strongly indicates they are highly related. Therefore, log inverse frequency or "downweighting popular items" is commonly used to correct: multiply similarity by 1/log(1+occurrence count). Penalizing popular items is a recurring theme in recommender systems — it serves accuracy, novelty, and fairness simultaneously.

5. Engineering tradeoffs between the two CF approaches ​

DimensionUserCFItemCF
DependencyUser-user similarity (grows with users, costly to recompute)Item-item similarity (item count is relatively stable, can be precomputed offline)
Online costHigh: need to find similar users in real timeLow: just look up precomputed similarity table
InterpretabilityWeak ("people similar to you have watched...")Strong ("because you watched X")
NoveltyBetter, can cross-domain recommendPoorer, prone to fall into a "highly homogeneous with the past" cocoon
Cold startNew users have almost no neighborsNew items have no similar items

Their shared fatal weakness is failure under sparsity: the sparser the matrix, the harder it is to find similar neighbors/items, and prediction quality drops off a cliff. Matrix factorization exists precisely to solve this.

3. Matrix Factorization: Seeing Through Preferences with Latent Factors ​

1. Background: Netflix Prize ​

In 2006, Netflix launched the Netflix Prize competition: whoever could improve rating prediction RMSE by 10% over Netflix's own Cinematch would win $1 million. The competition released 100 million real ratings and took nearly three years to be won by Bell Labs' team (BellKor's Pragmatic Chaos). This competition had two historical significance points: it pushed matrix factorization from an academic niche to the standard method for recommender systems; and it established the dominance of "ensembles of multiple models" in leaderboard competitions. Details on the winning approach and the competition itself are in the referenced "The Netflix Prize" paper and Koren et al.'s survey.

2. The latent factor idea ​

Matrix factorization starts from a structural assumption about "why the rating matrix has the shape it does":

Users' preferences and items' attributes are just different combinations of a few unobservable latent factors.

  • A "latent factor" can be crudely understood as a preference axis, e.g., "level of love for sci-fi," "tolerance for arthouse films," "acceptance of mainstream blockbusters."
  • Each user is represented by a k-dimensional vector pᵤ: their values on each axis.
  • Each item is represented by a k-dimensional vector qᵢ: its values on each axis.
  • A user's liking for an item = the dot product of the two vectors (high if aligned, low if orthogonal).
Latent factor (k-dim) interpretation schematic:

           Factor1(sci-fi)  Factor2(art)  Factor3(mainstream)
   UserA       0.9           0.2           0.6
   UserB       0.1           0.8           0.3
   "Interstellar"  0.95         0.1           0.9     → A would give high score, B would give low
   "Manchester by the Sea"  0.05   0.85        0.2     → B would give high score, A would give low

Relation to clustering (see Clustering): latent factors can be understood as a kind of "soft clustering" — users and items are assigned to k latent dimensions, but without requiring exclusivity. The difference is that clustering only does "birds of a feather flock together," while matrix factorization directly derives these dimensions by optimizing the "predict the rating" objective.

3. Mathematical form and loss function ​

Approximate the interaction matrix R with P (m×k user factor matrix) and Q (n×k item factor matrix):

R ≈ P · Qᵀ ,  i.e., r̂ᵤᵢ = pᵤᵀ qᵢ

Minimize regularized mean squared error on the observed interaction subset Ω:

L = Σ_{(u,i)∈Ω} (rᵤᵢ − pᵤᵀ qᵢ)² + λ( Σᵤ ‖pᵤ‖² + Σᵢ ‖qᵢ‖² )
       ↑ Fitting term: compute error only on observed cells         ↑ Regularization: prevent factor vectors from growing too large, causing overfitting

The significance of regularization must be understood in the generalization framework: the sparser the observed cells, the more free parameters (m×k + n×k), and the easier it is to memorize known ratings while losing predictive power for new ones. λ is a direct manifestation of regularization and the bias-variance tradeoff in the recommendation scenario (from Model Evaluation and Validation).

After introducing bias terms, the model becomes the complete form (this is the default model in the surprise library's SVD, aka the so-called Funk SVD):

r̂ᵤᵢ = μ + bᵤ + bᵢ + pᵤᵀ qᵢ

where μ is the global average rating, bᵤ is the user bias (some people habitually give high scores), and bᵢ is the item bias (The Shawshank Redemption is overall overrated). Bias terms are extremely cheap yet extremely effective — they absorb a large portion of explainable variance, letting the factor vectors focus on capturing the "user × item" interaction structure rather than the global mean.

4. Difference from classic SVD ​

SVD (singular value decomposition) in linear algebra is an exact mathematical tool: any dense matrix R can be uniquely decomposed as R = U·Σ·Vᵀ, where U, V are orthogonal matrices and Σ is a diagonal matrix. The "SVD" in the recommender field merely borrows its shell ideationally — they are fundamentally different:

DimensionClassic SVD (linear algebra)"SVD" in recommender field (Funk SVD / latent factor model)
InputDense, complete matrixExtremely sparse interaction matrix with many missing values
Missing valuesDon't existThe main problem; must never treat as 0 (user not rating ≠ rating 0)
GoalPrecisely reconstruct the entire matrixMinimize prediction error only on observed values; ignore missing values
Decomposition propertyUnique, orthogonal, full-rankNon-unique; factor vectors only follow the loss function
SolutionEigendecomposition (exact, expensive)Gradient descent / ALS (approximate, scalable)
EssenceMathematical toolRegularized statistical model

A must-remember trap: if you fill missing values with zero and directly do classic SVD, you're telling the model "hasn't watched = rating of 0," and the model will be drowned in fake zeros, with severely biased predictions. So true recommendation SVD optimizes only on the observed set Ω — this is the rationale for "using SGD to sample observed cells one by one for updates." Simon Funk wrote a few-line SGD program in 2006 exactly this way, shaking the Netflix Prize leaderboard, hence the name Funk SVD.

5. Solving: SGD and ALS ​

The matrix factorization loss is differentiable w.r.t. factor vectors, so gradient descent is the natural choice. For a single observed sample (u,i), the error is eᵤᵢ = rᵤᵢ − r̂ᵤᵢ, and the parameter updates are:

pᵤ ← pᵤ + γ( eᵤᵢ·qᵢ − λ·pᵤ )
qᵢ ← qᵢ + γ( eᵤᵢ·pᵤ − λ·qᵢ )
bᵤ ← bᵤ + γ( eᵤᵢ − λ·bᵤ )
bᵢ ← bᵢ + γ( eᵤᵢ − λ·bᵢ )

(γ is the learning rate, λ is the regularization coefficient.) Passing through all observed samples once is called an epoch; dozens of epochs usually suffice for convergence. The alternative to Stochastic Gradient Descent (SGD) is Alternating Least Squares (ALS): when Q is fixed, the loss is a convex quadratic function of P, with a closed-form solution, so we alternate between solving P and Q. ALS can be parallelized and natively adapts to distributed frameworks like Spark, which is why the industry (e.g., Yahoo! Music recommendations back then) mostly used it.

6. SVD++: feeding implicit feedback in ​

As discussed, implicit feedback contains massive information. SVD++ (Koren 2008, see references) gives an elegant fusion scheme: encode the user's implicit interactions (e.g., items browsed, clicked) into the user vector:

r̂ᵤᵢ = μ + bᵤ + bᵢ + qᵢᵀ ( pᵤ + |N(u)|^(-1/2) · Σ_{j∈N(u)} yⱼ )

where N(u) is the set of items where user u showed implicit behavior, and yⱼ is item j's "implicit factor vector." The overall expression in parentheses can be understood as a "user interest vector enriched with implicit signals." This term adds almost no computational cost but significantly improves accuracy on Netflix data — it tells us an empirical lesson: the signals that users haven't explicitly stated but whose behavior hints at deserve to be taken seriously by the model. SVD++ is a key bridge between classic matrix factorization and deep learning two-tower models: two-tower models essentially generalize "SVD++'s explicit and implicit terms" into arbitrarily complex neural network functions.

4. Modern Industrial Architecture: Recall → Ranking → Re-ranking ​

1. Why three stages are needed ​

Classic CF and matrix factorization can handle "ranking a few thousand movies"; but real platforms face millions to billions of candidate items (Taobao products, YouTube videos, TikTok content). If any model scores every candidate one by one, online latency explodes. The industry therefore splits recommendation into a funnel of three stages:

                          All items (millions to billions)
                                 │
    ┌────────────────────────────▼────────────────────────────┐
    │  ① Recall: two-tower + ANN vector retrieval              │  All → ~1000 candidates
    │     Goal: fast. Coarse-filter the subset that "might be interesting" from a massive pool |
    └────────────────────────────┬────────────────────────────┘
                                 ▼
    ┌────────────────────────────▼────────────────────────────┐
    │  ② Ranking: coarse ranking + fine ranking               │  ~1000 → ~50 items
    │     Goal: accuracy. Use more complex models to carefully score candidates |
    └────────────────────────────┬────────────────────────────┘
                                 ▼
    ┌────────────────────────────▼────────────────────────────┐
    │  ③ Re-ranking: diversity, dispersion, business rules, exploration injection │  ~50 → Top-N display
    │     Goal: experience. Make the final list more reasonable and explainable |
    └────────────────────────────┬────────────────────────────┘
                                 ▼
                            Final Top-N display

Each stage sacrifices accuracy for speed, or speed for accuracy; model complexity increases while candidate size decreases. Vectorized retrieval is the first cornerstone supporting this funnel.

2. Recall (I): two-tower models ​

In 2016, YouTube's paper Deep Neural Networks for YouTube Recommendations (arXiv:1606.07792, see references) explicitly framed recommendation as "encoding both users and videos into vectors, using dot product for matching" — this is the standard blueprint for two-tower models:

   User-side features:                  Item-side features:
   Historical viewing sequence (embedding)  Item id (embedding)
   Demographics (age/gender/location)      Item category / tags / duration / upload time
   Search queries / context(time/device)   Content features (text/image embeddings)
         │                                      │
         ▼                                      ▼
    user tower (MLP)                      item tower (MLP)
         │                                      │
         ▼                                      ▼
      u_vec (k-dim)                          v_vec (k-dim)
         └───────────────┬──────────────────────┘
                         ▼
            Match score = <u_vec, v_vec> (dot product / cosine)

The core advantage of two-towers dominating industrial recall is decoupled deployment:

  • Item tower is precomputed offline: after a model update, all items' v_vec are computed once and written to a vector database (Faiss, Milvus, etc., see FAISS paper in references).
  • User tower is computed online: the online side computes the user vector u_vec once, then performs a k-dimensional nearest neighbor search.
  • Match computation drops from "billions of model forward passes" to "one vector search," dropping latency from seconds to milliseconds.

A key detail during training is negative sample sampling. In real data, only "impressed and clicked" is positive, and the model needs to distinguish good from bad across all items, so random negative sampling supplements negatives; using "impressed but not clicked" as negatives introduces selection bias (being impressed isn't random to begin with), and random sampling over-penalizes popular items, so in practice both are combined (random negatives as primary + a moderate number of hard negatives). Loss functions typically use post-sampling softmax or binary cross-entropy. See Deep Learning Foundations.

3. Recall (II): Approximate Nearest Neighbor (ANN) Retrieval ​

After two-towers produce vectors, "finding the k most similar items" is a nearest neighbor search problem. Exact KNN is infeasible at the billion scale, so the industry uses Approximate Nearest Neighbor (ANN) across the board, with the core idea of "trading a small amount of error for 100x speed." Mainstream technologies fall into three categories:

MethodApproachRepresentatives
Hashing-basedUse random hyperplanes to bucket the vector space; same bucket = candidateLSH (Locality-sensitive hashing)
Quantization-basedQuantize the vector space into a codebook; approximate vectors with codewords, rank by lookup-table distancesPQ (Product Quantization), IVF+PQ
Graph-basedBuild a graph where "vectors are nodes, similarity is edges"; greedily walk from an entry node to the query pointHNSW (Hierarchical Navigable Small World), NSG

Among these, HNSW (Malkov & Yashunin, 2016, see references) is currently the most popular solution: it builds multi-layer graphs, with higher layers "jumping far" for coarse localization and lower layers "walking fine" for precise localization, achieving an excellent recall-speed ratio. Faiss, Milvus, and Elasticsearch all have built-in HNSW. The error introduced by ANN propagates upward, so the industry uses "vector retrieval yields 2000 items → coarse-rank model filters" as a fallback.

4. Coarse ranking and fine ranking ​

The thousands of candidates from recall are coarse in quality, entering the ranking stage for fine refinement. The ranking layer has two sub-stages:

  • Coarse ranking (candidate reranking): use a lightweight model (usually a shallow two-tower or simple tree model) to quickly score thousands of candidates, truncate to hundreds, saving precious latency budget for fine ranking. Coarse ranking pursues "not filtering out good prospects"; it needs to be more accurate than recall.
  • Fine ranking (ranking): for each of the hundreds of candidates, estimate CTR (click-through rate) / CVR (conversion rate) / watch time, etc., and sort precisely. This is where the funnel's heaviest models live.

Fine ranking is a direct application of the supervised learning standard framework: features + labels + model.

Feature system (fine ranking is the ultimate stage for "feature engineering"):
  ├── User-side: id, age/gender, historical click distribution, category preference vectors
  ├── Item-side: id, category, price, publish time, last 7 days CTR
  ├── Cross features: user-preferred category × item category, user age × item content rating
  └── Context: time, device, channel, display slot

Feature crossing is fine ranking's core competitiveness. From LR manual crossing, to FM (Factorization Machines) using implicit vectors to automatically learn second-order crossing, to DeepFM / Wide & Deep / DCN using deep networks for high-order nonlinear crossing, fine ranking models evolve along this line of "automatic feature crossing capability" (see Feature Engineering and Deep Learning Foundations). Note: the more cross-terms a model can learn, the greater its dependency on feature quality and negative sampling design — fine ranking's gains are half from model architecture and half from features and samples.

5. Re-ranking: making the list look "human-curated" ​

The scores from fine ranking are pointwise-optimal, but users see a list. A pointwise-optimal list often has three major problems, all solved by the re-ranking layer:

ProblemCauseRe-ranking solution
HomogeneitySimilar items have similar scores, filling the top ranksMMR (Maximal Marginal Relevance): penalize candidates that are "too similar to the already selected set"
Category imbalanceThe category a user clicks on most dominates the listDispersion: no more than a threshold of same-category items within adjacent k positions
Business rulesEditorial slots, rate limiting, ad insertionHard constraint insertion, usually rule engines rather than models
Exploration missingAlways recommend the most likely, users lose freshnessInject exploration traffic by probability (connected to Section 7)

The re-ranking layer also handles the critical tradeoff between diversity and accuracy: when list diversity improves, click-through rate often drops slightly first, but long-term retention and satisfaction rise — because the experience of being "fully guessed" grows tiresome. Modern re-ranking increasingly uses DPP (determinantal point processes), a "set-level" optimizer, replacing heuristics and moving from "pointwise scoring" to "sequence decisions," which already intersects with reinforcement learning.

5. Evaluation: How to Know if Recommendation Is Good ​

Recommendation system evaluation is a complete methodological problem (it's recommended to first read Model Evaluation and Validation). Its particularity is: the goal isn't to predict a number accurately, but user satisfaction — and user satisfaction can't be fully captured by any single formula. Evaluation is done in two layers: offline metrics on historical data, online validation via traffic experiments.

1. Offline evaluation setup ​

Offline evaluation first answers "on what data, and in what manner." Standard practice:

① Split: randomly split the interaction matrix by user into train/test (80/20 or 5-fold cross-validation)
         Note: split by user, not by row, to prevent the same user's info from leaking into training
② Train: fit the model only on train
③ Predict: score (u, i) in test
④ Measure: use different metrics for different task forms (see below)

An industrial-level detail is time split: recommendation is a strongly time-correlated task, so using "first 6 months for training, next 1 month for testing" often better reflects real online performance (the model serves the future). Full considerations for offline evaluation (leakage, bias, split pitfalls) are in Evals in Practice.

2. Ranking metrics: Recall@K and NDCG@K ​

Top-N recommendation uses ranking metrics. For user u, the system gives a top-K recommendation list R_u(K), and the user's truly liked item set is G_u (items with interactions in the test set):

Recall@K (coverage-oriented, also the primary metric in many papers):

Recall@K = |R_u(K) ∩ G_u| / |G_u|

It answers "of the items the user likes, how many were recommended in the top K?"

NDCG@K (ranking quality-oriented, from the IR DCG family, proposed by Järvelin & Kekäläinen in 2002, see references):

DCG@K = Σ_{i=1}^{K} ( 2^rel_i − 1 ) / log₂(i + 1)      rel_i = relevance of item at position i (0/1 or graded)
NDCG@K = DCG@K / IDCG@K                                  IDCG = DCG under ideal ranking (optimal permutation)

NDCG's cleverness: positions ranked higher get larger weights (log₂(i+1) in the denominator penalizes lower positions), and dividing by IDCG normalizes so it can be averaged across users. It captures the user's desire better than Recall@K: "what the user wants is the top ranks, not 'being in the list somewhere'."

3. Point-estimation metric: AUC ​

If recommendation is modeled as binary classification (click/no-click), use AUC. AUC's meaning is: "the probability that the model gives a higher score to a randomly drawn positive sample than to a randomly drawn negative sample." It doesn't depend on a threshold, is robust to class imbalance, and is the most universal ruler for ranking problems. AUC can also be used directly for Top-N evaluation: comparing "positives that were recommended vs. positives that weren't." Note that AUC measures overall ranking quality, and is far less sensitive to top positions than NDCG, so top-position scenarios should prioritize NDCG.

MetricQuestion it asksApplicable to
RMSE / MAEHow accurate is the score prediction?Rating prediction tasks (traditional research)
Recall@KWhat proportion of liked items were recommended in the top K?Top-N recommendation
NDCG@KDoes the recommended order put the most relevant items first?Information feed / video feed ranking
MRRAt what position does the first hit appear?Single-target search-style recommendation
AUCOverall separability of positive vs negative samples?Offline proxy for CTR estimation
Coverage / novelty / diversityDo long-tail items also get a chance?Ecosystem health, must be used in combination

4. Online evaluation: A/B testing ​

There's a systematic gap between offline metrics and real user experience: an offline 0.5% improvement in NDCG might be completely imperceptible online, or might even cause retention to drop because it's "too accurate, losing the element of surprise." Therefore, before rollout you must do A/B testing: randomly bucket traffic, run the new model in the experiment group and the old model in the control group, and compare business metrics with statistical tests (click-through rate, watch time, purchases, retention, per-user recommended contribution). Design essentials for online evaluation (sample size calculation, multiple comparison, long-term metrics) are the topic of Evals in Practice. Here we only emphasize one principle:

Offline metrics for screening, online experiments for decision-making. The model ranked highest offline doesn't necessarily win online; the definition of winning is always the online business metric.

6. Cold Start: New Users and New Items ​

Recommender systems are naturally disabled for "objects with no history" — this is the cold start problem, split into three types:

TypeScenarioTypical manifestation
User cold startNew registered userNo interaction history; CF/matrix factorization can't compute similarity or latent factors
Item cold startNewly listed product / new videoNo interactions; can't be "retrieved as a similar item"
System cold startBrand-new platformNeither user data nor item data exists; only content or attributes

Mitigation strategies fall into layers by "whether more signals can be obtained":

① Borrow content/attribute features (fusion of content-based recommendation and CF):
   New items have no interactions, but can use their attribute features (category, tags, text embedding, cover image features)
   to estimate a "content vector" as the item's vector during the cold start phase — two-tower models natively support this,
   because the item vector is always generated by features.
② Popularity backfill:
   For cold-start users, first recommend a popularity chart / editor's pick, using "mass preference" as the first prior,
   then personalize once enough interactions accumulate.
   Note: popularity backfill must be paired with exploration mechanisms, otherwise newcomers only see top content.
③ Actively gather signals (warm-up):
   During onboarding, guide users to select interest tags, or show several cover images for "implicit scoring" (user behavior = feedback),
   using these low-cost signals to quickly initialize user vectors.
④ Exploration traffic (exploration bucket):
   Inject new items into exploration traffic pools, letting "a few users sample" produce the first batch of interactions (see Section 7).
⑤ Transfer learning / cold-start models:
   Use platform-level "generic user vectors" or "item content embeddings" from pre-training, applying them directly during cold start
   (the same pre-training → fine-tuning idea as in [Large Language Models](/case-studies/llm)).

Cold start also has a commonly overlooked evaluation problem: offline evaluation naturally underestimates cold-start models — test sets rarely include "new item interactions," so you must construct separate test slices that "only include items launched within the first 7 days / users with their first 3 interactions" to validate cold-start performance. Otherwise your "cold-start optimization" may never have been tested. This is the recurring "evaluation-goal misalignment" in Common Pitfalls.

7. Exploration and Exploitation: Recommendation Isn't a One-and-Done ​

1. Why exploration is needed ​

All the models above assume "maximize user preference for known items" — this corresponds to exploitation: pushing items predicted to be most likely liked. But user preferences aren't static, and the model always has uncertainty:

  • New items and new content need to be "tested" to produce data;
  • User tastes drift (tired of genre A, shift to genre B);
  • The model has very low confidence in its predictions for long-tail items; pure exploitation means they never get exposure, creating a "Matthew effect."

A pure-exploitation recommendation system optimizes for short-term click-through rate but shrinks in the long run: users run out of novelty, long-tail supply disappears. Exploration is actively dedicating a portion of traffic to "testing the unknown," exchanging today's tiny loss for tomorrow's data dividends. Mathematically, this is the classic exploration-exploitation tradeoff from reinforcement learning. Recommendation systems are fundamentally continuous online decision-making, not one-time supervised learning.

2. Classic strategies ​

StrategyMechanismCharacteristics
ε-greedyRandomly recommend with probability ε (explore), push the optimal with probability 1−ε (exploit)Simplest; with fixed ε, converges slowly, general long-tail effect
UCB (Upper Confidence Bound)Score candidates by "expected return + uncertainty bonus"; items with higher uncertainty get more opportunitiesElegant theory, suitable for "finite, enumerable item arms" (e.g., news recommendation)
Thompson SamplingMaintain a Bayesian posterior distribution for each item; sample once from the posterior as each item's score each timeBest practical effect, simple to implement, adopted by multiple companies

An important practical constraint: exploration can't be done arbitrarily at the fine ranking layer. Placing "random items" in the top 5 of a user's homepage causes immediate experience loss. Industry's compromise:

  • Layered exploration: add an "exploration channel" at the recall layer (e.g., niche new item channel, random channel), mixed into the final list at very low ratios by the re-ranking layer;
  • Exploration budget: allocate by traffic ratio (e.g., 2% exploration traffic), and feed back the exploration objects' feedback to training in real time.

3. Online learning and model updates ​

New data produced by exploration must be absorbed by the model in time, leading to online learning:

Offline training (batch): retrain the model daily/hourly using full logs (offline full + incremental)
        ↓ Produce new parameters for online inference baseline
Online learning: incremental parameter updates for real-time streaming logs (e.g., FTRL, online SGD)
        ↓ Capture second-level, minute-level interest changes (hot events, temporary preferences)
Model serving: hot parameter updates + online inference

The mainstream approach is "offline retraining as primary, online fine-tuning as secondary": model structures are periodically retrained offline (ensuring stability), while real-time signals are absorbed quickly via online learning (ensuring timeliness). Exploration and online learning together form the closed loop of continuous evolution for recommendation systems — this is also the natural extension from supervised learning to reinforcement learning. The full framework is in Reinforcement Learning.

8. Practice: Matrix Factorization Recommendation with surprise ​

surprise (Surprise: A Python library for Recommender Systems, 2017, see references) is a Python library focused on recommendation algorithms, with built-in SVD, SVD++, KNN collaborative filtering, and standard datasets. Here we use it to run a complete pipeline.

1. Installation and data ​

bash
pip install scikit-surprise
python
from surprise import Dataset, Reader, SVD, accuracy
from surprise.model_selection import train_test_split

# Load the built-in MovieLens 100K dataset (auto-downloads on first run)
data = Dataset.load_builtin("ml-100k")
# Data format: user id | item id | rating | timestamp

trainset, testset = train_test_split(data, test_size=0.2, random_state=42)
print(f"Training samples: {trainset.n_ratings}, Users: {trainset.n_users}, Items: {trainset.n_items}")

2. Train SVD and evaluate ​

python
# SVD = μ + bᵤ + bᵢ + pᵤᵀqᵢ, i.e., matrix factorization with bias and regularization (Funk SVD)
model = SVD(n_factors=20, n_epochs=30, lr_all=0.005, reg_all=0.02)
model.fit(trainset)

predictions = model.test(testset)
print("RMSE:", accuracy.rmse(predictions))
print("MAE :", accuracy.mae(predictions))
# Typical output: RMSE ~0.94, MAE ~0.74 (reasonable for MovieLens 100K)

3. Point prediction and Top-N recommendation ​

python
# Score for (user 196, item 302)
pred = model.predict(uid="196", iid="302")
print(f"Predicted rating: {pred.est:.2f}  (true rating printed when available)")

# Manual Top-N: predict for all items the user hasn't interacted with, then rank
def top_n_recommend(model, trainset, uid, k=10):
    # Set of items the user has already interacted with (in the training set)
    inner_uid = trainset.to_inner_uid(uid)
    seen = {iid for (iid, _) in trainset.ur[inner_uid]}

    # Predict for all items, exclude already-interacted ones, take top k
    scored = []
    for inner_iid in trainset.all_items():
        if inner_iid in seen:
            continue
        raw_iid = trainset.to_raw_iid(inner_iid)
        est = model.predict(uid=uid, iid=raw_iid, verbose=False).est
        scored.append((raw_iid, est))
    scored.sort(key=lambda x: -x[1])
    return [iid for iid, _ in scored[:k]]

print("Top-10 recommendations:", top_n_recommend(model, trainset, uid="196"))

surprise also has built-in ItemCF (KNNBasic), SVD++ (SVDpp), etc. You can directly compare them or use it to compute NDCG and other ranking metrics. Note that surprise is geared toward research and teaching; industrial implementations need engineering for data scale and distributed processing, but the algorithmic ideas correspond one-to-one with the code here.

4. A 30-line hand-written matrix factorization (understanding the essence) ​

Stripping away library wrappers, the SGD solution for matrix factorization is all that this code does:

python
import numpy as np

def funk_svd(R, k=10, lr=0.01, reg=0.02, epochs=40):
    """R: (m, n) rating matrix, 0 means missing (don't use as a real rating)"""
    m, n = R.shape
    mu = R[R > 0].mean()
    P = np.random.randn(m, k) * 0.1      # User latent factors
    Q = np.random.randn(n, k) * 0.1      # Item latent factors
    bu = np.zeros(m)                     # User biases
    bi = np.zeros(n)                     # Item biases

    for _ in range(epochs):
        for u, i in zip(*np.where(R > 0)):        # Only update on observed values
            err = R[u, i] - (mu + bu[u] + bi[i] + P[u] @ Q[i])
            P[u] += lr * (err * Q[i] - reg * P[u])   # Gradient descent + L2 regularization
            Q[i] += lr * (err * P[u] - reg * Q[i])
            bu[u] += lr * (err - reg * bu[u])
            bi[i] += lr * (err - reg * bi[i])
    return P, Q, bu, bi, mu

# A tiny 4-user × 5-item rating matrix
R = np.array([
    [5, 0, 4, 0, 2],
    [0, 3, 0, 5, 0],
    [4, 0, 0, 1, 3],
    [0, 0, 2, 0, 4],
])
P, Q, bu, bi, mu = funk_svd(R, k=3)
user0_pred = P[0] @ Q.T + mu + bu[0] + bi
print("User 0's predicted ratings for all items:", np.round(user0_pred, 2))

The line "only update where R > 0" in this code is the entire secret differentiating matrix factorization from classic SVD. Tweak k, lr, reg by hand, observe the changes in RMSE and factor vectors — it's more useful than reading theory ten times. And don't forget to rigorously evaluate your changes with the methods in Evals in Practice.

9. Tradeoffs and Decision Points ​

Recommender systems are "balancing under multiple objectives" engineering — there's no free lunch. A few of the most common tensions:

  • Accuracy vs. diversity/novelty: NDCG-optimizing models tend to recommend "same-category blockbusters," creating filter bubbles and echo chambers; sacrificing a bit of top-rank accuracy for list diversity often yields better long-term retention. Use MMR/DPP for systematic balance, not post-hoc guesswork.
  • Offline metrics vs. online business: offline NDCG improvement ≠ online CTR improvement. Offline evaluation for screening candidate models, online A/B for final decision — this principle is worth repeating a hundred times.
  • Model complexity vs. service latency/cost: two-tower is fast but coarse; fine ranking is accurate but slow; the funnel layers budget between accuracy and latency. Blindly widening the fine ranking model blows the latency budget.
  • Personalization vs. popularity backfill: pure personalization fails at cold start and has weak long-tail ability; pure popularity is zero-personalization. The correct approach is adaptive by user data volume: for data-poor users, rely more on popularity; for data-rich users, rely more on personalization.
  • Exploitation vs. exploration: the tension between short-term metrics and long-term health, see Section 7. Any "pure maximization" optimizer needs an explicit exploration budget.
  • Interpretability vs. expressive power: ItemCF can say "because you watched X"; deep two-towers are a black box; in scenarios needing to explain "why this was recommended" (news, finance), interpretability itself is product value.
  • Privacy vs. personalization: the more personalized the model, the finer-grained user data it needs. Under privacy compliance pressure, federated learning, differential privacy, and localized modeling are becoming new constraints.
  • Simple models + good features vs. complex models: consistent experience from Kaggle and industry — first establish a linear/shallow baseline, confirm feature quality, then go deep. Features set the ceiling; the model just approaches it.

10. Further Reading ​

References ​