Why personalized recommenders exist

This curriculum is adapted from the open-source Hands-on H&M Real-Time Personalized Recommender course by Paul Iusztin and the Decoding ML team at github.com/decodingml/personalized-recommender-course. The original architecture and pedagogical sequence live there. The local stack version we will build replaces the Hopsworks coupling with Postgres, Qdrant, and MLflow so you can run everything without a cloud signup.

A small lift in click-through translates into millions of dollars on a catalogue like H&M, Netflix, or Spotify. That is why every product team that surfaces items to users is running some form of recommender, even if they call it "personalised search" or "the home feed". The architecture you will build is the same one those teams maintain.

Sparsity is the central problem and the reason recommenders look different from classification. A model that memorises customer-item pairs cannot generalise to unseen pairs. So you learn dense embeddings instead. Each customer and each item lives at a point in a shared space. Affinity becomes geometry. New pairs are scored by distance, even if you never saw them in training.

There is a second problem hiding under sparsity. A brand-new customer has zero interactions. A brand-new article has zero observations. The model has no signal to work with. That is cold start, and every production recommender has a strategy for it. Content towers, popularity priors, and contextual bandits are the usual answers. We will revisit this when we get to serving.