Applied & Classical ML · entry 03/06 · 3 min read

Recommender systems

The most economically consequential machine learning most people interact with daily — a two-stage architecture, and a feedback loop that makes evaluating it genuinely hard.

The problem, stated honestly

You have millions of items and one user with a few seconds of patience. The task is not "predict a rating" — that framing, inherited from an old competition, survives as one signal among many but is obsolete as the whole job. It is to choose a small ordered set from an enormous catalog, under a latency budget, for an objective the business has to state out loud.

Two stages, because one cannot scale

Nothing can score millions of items per request, so production recommenders split the job into stages that get progressively more expensive per item. Retrieval narrows the catalog to a few thousand candidates in milliseconds — typically a two-tower model that embeds the user and the item into the same space, the two towers never interacting until a final dot product, which is exactly what lets every item embedding be computed offline and loaded into an approximate nearest-neighbor index. That is unioned with cheap heuristic sources: recently viewed, popular in your region, same creator. A cheap pre-ranker trims those thousands to a few hundred. The heavy ranker predicts several things at once on what survives — click, watch time, purchase, increasingly "will you regret this" — and combines them into one score. A final policy pass handles what a score cannot: diversity, freshness, business rules, and not showing the same thing five times.

Collaborative, content, and the cold start

Collaborative filtering learns from behavior alone: people who liked these also liked that. It is powerful and silent about any item nobody has touched. Content-based methods use item attributes, so they handle new items and miss the taste patterns behavior reveals. Every real system is a hybrid, and cold start — new user, new item, new market — is a permanent operational concern rather than a solved problem.

Why evaluation is genuinely hard

The system chooses what the user sees, so the logs record only the consequences of its own past choices. You never observe what the user would have done with the item you did not show, which makes offline metrics systematically flattering to whatever policy generated the data — the same difficulty as learning a policy from a log. Serious teams therefore treat offline scores as a filter and settle questions with online experiments — and they log some deliberate randomization, each choice recorded with the probability it was made with, because without those probabilities no counterfactual is estimable at all.

Failure mode

Optimizing engagement and calling it satisfaction. A ranker trained on clicks learns what gets clicked, which includes outrage, thumbnails that oversell, and content that exploits a moment of weakness — and because the system shapes the next day's data, the pressure on that proxy compounds. How far it narrows what any one person sees is genuinely contested — audit studies keep finding smaller algorithmic effects than the popular account assumes — but the pressure on the objective is not in doubt. This is specification gaming with a recommendation surface. The countermeasures are known and cost money: long-horizon objectives, explicit satisfaction surveys as a training signal, diversity constraints, and holding out a population that never sees the optimized experience.